자동화 slecs

영어 문서 없는 신인 그룹도 자동으로 커버

목차

seed_groups 자동화 로직을 다루던 중, 신인(마이너) 그룹들의 자료 수집이 깨지는 케이스를 만났다. 원인은 단순했는데, 봇이 영어 Wikipedia만 참고하고 있었기 때문이다. 한국어 문서도 함께 찾도록 fallback을 추가해서 커버리지를 늘렸고, 이 과정에서 배운 몇 가지 패턴을 정리한다.

seed_groups 와 언어 커버리지의 막힘

seed_groups.py는 봇이 초기 데이터를 수집할 그룹들을 정의하고, 각 그룹의 기본 정보를 자동으로 채워넣는 모듈이다. 이전 구현은 Wikipedia를 primary source로 두고, en(영어) 문서만 찾아서 파싱하는 식으로 돌아갔다.

문제는 신인 그룹(예: 최근 데뷔한 팀, 마이너 리그 소속 등)들은 영어 Wikipedia에 아직 항목이 없거나 매우 제한적인 경우가 많다는 것이었다. 같은 정보가 ko(한국어) Wikipedia에는 더 충실할 수도 있는데, 우리는 en이 없으면 skip 했던 거다. 결과적으로 자동화 커버리지는 70% 정도로 머물렀고, 나머지는 수동으로 데이터를 입력해야 했다.

다언어 fallback 전략

해결책은 직관적이었다: en 문서를 못 찾으면, ko 문서를 찾아본다. 다시 말해 우선순위 기반의 fallback chain 을 구현하는 것이었다.

Priority order:
1. en (English Wikipedia)
2. ko (Korean Wikipedia)  ← fallback
3. (더 필요하면 다른 언어들...)

이 패턴은 multilingual service에서 흔히 쓰이는 전략이다. 보통은:
- 사용자의 locale을 기준으로 우선순위 정렬
- 메인 언어 실패 → 대체 언어들을 순서대로 시도
- 모두 실패하면 default 값이나 empty 반환

우리의 경우, seed_groups는 시스템 레벨이므로 사용자 locale이 아니라 도메인 특성 을 기준으로 우선순위를 정했다. 영어는 국제 표준이고, 한국어는 해당 서비스의 메인 사용자 베이스와 맞아떨어진다. 그래서 en → ko 순서가 자연스러웠다.

구현의 트레이드오프

언어를 추가하면서 고민한 부분들:

고려사항 결정
몇 개 언어까지 시도할 것인가 2개(en, ko)로 제한. 과하면 수렴성 낮아지고 테스트 부담 증가
문서 품질 검증 파싱 성공 여부만 확인. 데이터 품질은 이미 있는 validation layer에 위임
캐싱 전략 각 언어별로 실패 기록. 같은 그룹을 재시도할 때 불필요한 호출 줄임
로깅/모니터링 fallback 사용 여부 명시. "어느 언어로 데이터를 가져왔는가"를 추적 가능하게

가장 중요한 트레이드오프는 단순함 vs. 완성도 였다. 모든 언어를 다 시도하면 이론상 완성도는 높겠지만, 유지보수 복잡도와 API 호출 비용이 기하급수적으로 늘어난다. 우리는 "일단 2개 언어로 주요 케이스를 커버하자"는 접근을 택했다. 나중에 한 언어가 더 필요해지면 (예: ja) 그때 추가해도 늦지 않는다.

자동화 완성도 향상과 팀 임팩트

이 변경이 미치는 실질적 영향:

  • 커버리지 상향: 70% → 약 90% 수준으로 개선. 수동 처리 건수 급감
  • 일관성 강화: 신인 그룹도 표준 프로세스를 통해 초기화됨. 데이터 구조와 메타데이터 품질이 일정하게 유지
  • 운영 부담 감소: 운영자/큐레이터가 매번 "이 그룹 정보 왜 없지?" 물어보는 케이스가 줄어듦
  • 향후 확장성: fallback chain이 명확하니, 새로운 언어나 source를 추가할 때 기존 로직을 간단히 확장 가능

팀 입장에서도 점진적 개선이 보여서 좋았다. 큼지막한 기능(feature) 추가가 아니라, 자동화의 "구멍" 하나를 메우는 작업이었는데, 그것만으로 일일 업무 friction이 확 줄었다.

회고: 우선순위와 수렴성

이 작업에서 배운 가장 큰 교훈은 "모든 케이스를 완벽하게 커버하려다 보면 관성에 빠진다" 는 점이다.

많은 자동화 작업이 처음엔 간단하게 시작된다. "en만 지원하면 대부분 충분하겠지" 라는 가정에서. 그런데 서빙하다 보면 edge case들이 튀어나온다. 그때마다 "하나 더 언어 추가할까?" 하면서 scope이 자꾸 커진다.

우리가 한 접근은 다르게 생각해본 거다: "이 시점에서 가장 impact 큰 2개 언어만 지원하고, 나머지는 나중에 demand가 명확할 때 한다." 이렇게 하면:

  1. 구현이 단순하고 테스트하기 쉬움
  2. 배포 리스크 낮음
  3. 핵심 문제(신인 그룹 커버리지)는 즉시 해결
  4. 다음 phase(새 언어 추가)는 명확한 데이터를 갖고 판단 가능

다음번 유사한 자동화 개선을 할 때도, 이렇게 "가장 아픈 곳"을 집중 공략하고 여유를 남겨두는 접근을 따르려 한다.

🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

이어보기

댓글 0

첫 댓글 달아줘.