Semantic Search 만으로는 번역 품질이 해결되지 않았던 이유

채널톡 AX팀이 일본팀의 번역 리소스 문제를 AI로 풀려다 Semantic Search 접근을 버리고 검색형 에이전트로 전환한 기록이다. 벡터 검색은 의미가 비슷한 문단은 잘 찾아왔지만 정작 중요한 용어 일치는 잡지 못했다. 문제의 성질이 문단 유사도가 아니라 용어 일관성이었다는 진단이 핵심이다.

핵심 포인트

B2B SaaS 제품이라 용어 하나하나가 신뢰도와 직결돼, 이미 번역된 표현이 있으면 최대한 동일하게 써야 한다.
번역 키는 그 자체가 이미 최소 단위라 더 쪼갤 수도 없고, 여러 개를 묶으면 어떤 번역을 대표하는 chunk인지 애매해진다.
임베딩은 문장을 하나의 의미 벡터로 압축하는데, 문장이 길어질수록 전체 의미는 잡히지만 정작 중요한 용어가 그 안에 묻힌다.
"의미가 비슷한 문장을 찾는 문제가 아니라 이미 쓰인 용어를 정확히 다시 찾는 문제"로 재정의하고 키워드 생성 기반 검색 에이전트로 바꿨다.
데이터 성격에 따라 역할을 나눴다. Tolgee의 사전형 데이터는 정확한 표현 재사용에, 블로그 번역은 톤과 흐름의 참고용에 적합했다.

상세 정리

문제 상황: 번역할 때 이미 번역된 단어가 있으면 참고해야 하는데 놓치면 같은 개념이 서로 다른 단어로 번역돼 용어가 깨진다. 대소문자까지 고려해 신중히 번역하는 제품이라 더 민감했다.
가진 데이터 둘: Tolgee에 제품 UI·알림·시스템 문구가 번역 키로 관리되고 있었고(무료 플랜이라 Tolgee 자체의 AI 추천은 못 씀), 블로그에는 어떤 문장을 어떤 톤과 용어로 번역했는지가 남아 있었다.
첫 시도: OpenAI를 골랐는데 플랫폼 안에서 Vector Store를 자체 제공하고 Agent Builder로 Chat UI와 File Search Tool을 원클릭 연동할 수 있었기 때문이다.
결과: 문장이 길어질수록 유사한 문단은 나오지만 정확한 용어는 찾지 못했다. 의미는 비슷한데 용어는 다른 문장이 계속 출력됐다.
실패 원인 1 청킹: 번역 키 하나가 이미 최소 단위라 청킹이 거의 의미를 갖지 못했다. RAG의 기본 전제인 "긴 문서를 쪼개 의미 단위로 검색"이라는 구조가 이 데이터의 성질과 맞지 않았다.
실패 원인 2 임베딩: 번역에서 중요한 것은 문장 전체의 의미보다 특정 용어인데, 임베딩은 그 반대 방향으로 압축한다.
두 번째 시도: 키워드 생성 단계를 앞에 두고 그 키워드로 정확한 표현을 찾아 재사용하는 구조로 바꿨다.
데이터 역할 분리: Tolgee는 단어와 용어 단위의 사전형 데이터라 정확한 표현 재사용에 적합했고, 블로그는 문장 전체의 톤과 흐름이 중요해 동일 문장 재사용보다 유사 사례를 참고하는 용도로 적합하다고 판단했다.
저자는 Vector DB의 청킹과 인덱싱을 더 세밀하게 설계했다면 결과가 달라졌을 수도 있다고 인정하면서도, 핵심이 문단 유사도가 아니라 용어 일관성이었기 때문에 접근 자체를 바꾸는 편이 효과적이었다고 정리한다.
교훈: Semantic Search가 단어 단위 일관성이 중요한 사전형 문제에는 항상 적합한 구조가 아니며, 기술 자체의 성능보다 문제의 성질과 기술의 역할이 맞는지가 훨씬 중요하다는 것이다.
팀 성격으로 "이게 정말 AI 문제인가"부터 다시 질문하고, 필요하면 RAG를 쓰거나 Retrieval 방식을 재설계하거나 문제를 푸는 방식 자체를 바꿔본다고 밝힌다.