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

안녕하세요. 채널톡 AX팀에서 AI 기반 내부 자동화와 Agent 시스템을 만들고 있는 폴라입니다.AX팀은 CX, 마케팅, 프로덕트 등 다양한 팀의 실제 업무를 AI와 워크플로우로 연결하고 있어요. 저희 팀은 실제로 일하는 AI 시스템을 만드는 것을 목표로 열심히 달려가는 중이에요.

어느날 일본팀에서 번역에 너무 리소스가 많이 들고, 어려움이 있어서 AI로 해결하고 싶다는 도움 요청을 보냈어요!

이미 번역된 단어가 있다면 다시 써야 한다

채널톡은 B2B SaaS 제품이기 때문에 용어 하나하나가 제품의 신뢰도와 직결돼요. 대소문자도 고려해서 신중하게 번역 하고 있어요.

그렇기 때문에 번역 작업시 이미 번역된 단어가 있으면 최대한 동일한 표현을 참고해서 쓰는게 중요해요. 하지만 아래와 같은 문제들이 있어요.

• 기존 번역이 있는지 찾느라 오래 걸림

• 놓치면 용어가 깨짐 (서로 다른 단어로 번역할 가능성)

이 문제를 해결하기 위해 현재 채널톡이 어떤 번역 데이터를 가지고 있는지 살펴봤어요.

채널톡의 번역 데이터

1) Tolgee

Tolgee는 Lokalise와 같은 번역 관리 툴이에요. 현재 Tolgee에는 제품 UI, 알림, 시스템 문구 등 공식 용어가 번역 키로 관리되어 있어요. Tolgee에도 AI 기반 추천이 있지만 무료 플랜에서는 사용할 수 없었어요.

2) 기존 블로그 번역

채널톡 블로그에는 이미 어떤 문장을 어떤 톤과 어떤 용어로 번역했는지 모두 남아 있었어요. 다만 이것을 AI가 제대로 활용하지 못했어요.

이제 우리가 가진 데이터를 최대한 활용해서 번역의 어려움을 풀어보기로 했어요.

첫 번째 시도 - Semantic Search 기반 접근

빠른 실험을 위해 OpenAI Agent Builder를 사용했어요. OpenAI를 선택한 이유는 Platform내에서 자체적으로 Vector Store를 제공하고, Agent Builder를 사용해 Chat UI와 File Search Tool을 원클릭으로 연동할 수 있었기 때문이에요.

문장은 벡터 검색에 너무 길다

하지만 기대한 것과 다르게 결과가 만족스럽지 않았어요. 번역에서 중요한 것은 단어 단위의 일관성이에요.

agent인지, operator인지conversation인지, chat인지

하지만 벡터 DB는 문장 의미 유사도를 찾아요.

문장이 길어질수록 유사한 문단은 나오지만 정작 중요한 용어는 찾을 수 없었어요. 의미는 비슷한데, 용어는 다른 문장이 계속 출력되었어요.

청킹 & 임베딩이 근본적으로 안 맞는다

Tolgee 번역 키는 보통 아래와 같은 구조에요

이건 문서가 아니라 사전(dictionary) 인데 Vector DB는 이걸 문서처럼 취급해요. 문장을 청킹하고, 임베딩을 만들고, 의미적으로 비슷한 덩어리를 찾으려고 해요. 이 과정에서 번역 키가 원래 가지고 있던 성질이 잘 드러나지 않아요.

첫 번째 문제는 청킹이 거의 의미를 갖지 못한다는 점이에요. 번역 키 하나하나가 이미 최소 단위라서 더 쪼갤 수도 없고, 여러 개를 묶으면 어떤 번역을 대표하는 chunk인지 애매해져요.

두 번째 문제는 임베딩이 우리가 찾고 싶은 걸 잘 표현하지 못한다는 점이에요. 번역에서 중요한 건 문장 전체의 의미보다는 agent인지, operator인지, conversation인지 같은 단어 단위의 선택과 일관성이에요.

하지만 임베딩은 문장을 하나의 의미 벡터로 압축해요. 문장이 길어질수록 전체 의미는 잘 잡히지만, 정작 중요한 용어는 그 안에 묻혀버려요.

두 번째 시도 - Semantic Search 접근을 버리고 검색형 에이전트로

그래서 접근을 바꾸게 되었어요.

"이건 의미가 비슷한 문장을 찾는 문제가 아니라, 이미 쓰인 용어를 정확히 다시 찾는 문제다!”

핵심 아이디어

1. LLM이 문장을 보고

2. 필요한 키워드들을 추출

3. Tolgee API를 여러 번 호출

4. 가장 많이 매칭된 번역 키들을 조합

Input Sentence
        |
        v
      LLM
        |
        v
┌──────────── Keyword Generation ────────────┐
│  상담원 → Search → agent                     │
│  대화   → Search → conversation             │
│  종료   → Search → closed                   │
└────────────────────────────────────────────┘
        |
        v
Combine / Rank / Select
        |
        v
agent.conversation.closed

블로그 내용은 어떻게?

Tolgee에 들어 있는 번역 데이터는 단어와 용어 단위의 사전형 데이터예요. 그래서 정확한 표현을 찾아 재사용하는 데 적합했어요.

반면 블로그에 있는 번역 데이터는 문장 전체의 톤과 흐름, 표현 방식이 중요했어요. 동일한 문장을 그대로 재사용하기보다는, 필요한 상황에 유사한 블로그 번역을 참고해 톤앤매너를 맞추는 용도의 프롬프트로 사용하는 게 더 적합하다고 판단했어요.

최종 형태

맺음말

Vector DB의 청킹과 인덱싱을 더 세밀하게 설계했다면 결과가 달라졌을 수도 있어요. 다만 이 문제의 핵심은 문단 유사도가 아니라 용어 일관성이었기 때문에, 접근 자체를 바꾸는 것이 더 효과적이었어요.

이번 실험을 통해 분명하게 느낀 점이 있어요. Semantic Search는 단어 단위의 일관성이 중요한 사전형 문제를 해결하기에는 항상 적합한 구조는 아니라는 점이에요. 실제로 부딪혀 보니, 이 문제는 문장 의미를 확장하는 retrieval 문제가 아니라, 정확한 용어를 재사용하기 위한 정밀 검색 문제에 더 가까웠어요. 기술 자체의 성능보다는, 문제의 성질과 기술의 역할이 잘 맞는지가 훨씬 중요하다는 걸 깨달았어요.

AX팀은 이런 현실적인 문제를 많이 마주하고, '이게 정말 AI 문제인가?'부터 다시 질문해보는 팀이에요. 필요하다면 RAG를 쓰고, Retrieval 방식을 재설계하고, 때로는 문제를 푸는 방식 자체를 바꿔보려고 해요. 이런 채널톡의 AX팀이 궁금하다면, 언제든지 편하게 커피챗 요청 주세요