은어사전 번역 프롬프트

번역기가 가장 못하는 것은 어려운 문장이 아니라 그 조직만의 말입니다. 매장 단톡방에서 "MS"는 마이크로소프트가 아니라 오전 근무이고 메뉴 약칭과 직원들끼리의 은어는 어떤 범용 번역기도 모릅니다. 해외 매장의 왓츠앱 번역 봇을 만들며 이 문제를 은어사전의 프롬프트 주입으로 풀었습니다. 작지만 번역 품질의 체감을 가른 설계였고 그 구조를 정리합니다.

은어사전 주입의 구조

원리는 간단합니다. 번역 요청의 시스템 프롬프트에 용어 대응표를 함께 넣는 것입니다. "이 방에서 다음 표현은 이렇게 옮겨라"라는 지시와 함께 은어 대응, 근무 약어(오전·오후·마감 등 일곱 종), 언어 지정 접두 기호의 의미가 들어갑니다.

핵심은 사전이 코드가 아니라 데이터라는 점입니다. 사전은 구글 시트의 탭으로 존재하고 시스템이 주기적으로 읽어 캐시합니다. 번역 규칙 변경이 배포가 아니라 시트 편집입니다. LLM 기능의 품질을 조직 지식으로 끌어올리는 가장 값싼 방법이 이런 "지식의 데이터화 + 프롬프트 주입"이라고 생각합니다.

사전은 운영자가 키운다

이 설계의 진짜 가치는 성장 구조에 있습니다. 오역이 발견되면 운영자(사장님)가 시트에 한 줄을 추가합니다. 다음 동기화부터 그 표현은 바르게 번역됩니다. 개발자에게 "이 단어 좀 고쳐 주세요"라고 요청하는 왕복이 없습니다.

운영 두 달의 경험으로 보면, 사전은 초기 며칠에 빠르게 자라고 이후 안정화됩니다. 방에서 쓰이는 어휘의 분포가 수렴하기 때문입니다. 즉 사전 관리는 지속적인 노동이 아니라 초기 정착 + 간헐적 추가의 패턴이라, 비개발자 운영자에게 부담이 되지 않았습니다.

무엇을 사전에 넣고, 무엇을 넣지 않나

운영하며 정리된 기준입니다.

원칙은 "모델이 틀리는 것만 넣는다"입니다. 사전이 커질수록 프롬프트가 길어지고 비용과 지연이 붙으므로, 사전은 백과가 아니라 예외 목록이어야 합니다. 실제 오역에서 출발해 한 줄씩 늘어난 사전이 가장 효율적입니다.

파싱에도 같은 사전이 쓰인다

은어사전의 부수 효과는 번역 밖에 있었습니다. 직원들이 자유 양식으로 올리는 근무 일정("준하 24,25,26 11:30-23:30")을 시트로 파싱하는 워크플로가 있는데, 여기서도 근무 약어표가 같은 방식으로 주입됩니다. "OFF"가 휴무라는 것을 아는 파서와 모르는 파서의 정확도 차이는 설명이 필요 없습니다.

즉 이 사전은 번역 사전이라기보다 조직 어휘의 단일 소스입니다. 번역, 일정 파싱, 질의응답 봇이 같은 시트를 바라보므로, 어휘 지식이 기능마다 흩어지지 않고 한곳에서 자랍니다. 관리 콘솔로서의 시트 설계 전반은 구글시트 관리 콘솔 설계에서 이어집니다.

이 사전이 동작하는 번역 봇의 전체 설계는 메신저 실시간 번역 봇에서, 시스템 전체는 왓츠앱 번역 자동화 사례에서 볼 수 있습니다.

자주 묻는 질문

은어사전 주입이란 무엇인가요?

조직 특유의 은어·약어의 대응표를 번역(또는 파싱) 요청의 시스템 프롬프트에 함께 넣어 LLM이 그 조직의 언어를 아는 상태로 작업하게 만드는 기법입니다. 모델을 바꾸지 않고도 "그 조직을 위한 번역" 품질을 만드는 가장 저렴한 방법입니다.

사전 항목은 누가 관리하나요?

운영자가 직접 관리하는 구조를 권합니다. 사전을 구글 시트 같은 데이터로 두고 시스템이 주기적으로 읽게 하면, 오역 발견부터 수정까지가 시트 한 줄 추가로 끝납니다. 개발자를 거치는 왕복이 사라져야 사전이 실제로 자랍니다.

사전이 커지면 문제가 없나요?

프롬프트 길이가 늘어 비용·지연이 붙고 항목끼리 충돌할 여지도 생깁니다. 그래서 "모델이 틀리는 것만 넣는다"는 예외 목록 원칙이 중요합니다. 실제 오역에서 출발한 항목만 쌓으면 어휘 분포가 수렴하면서 사전도 안정화됩니다.

번역 외의 기능에도 쓸 수 있나요?

같은 사전을 일정 파싱, 질의응답 등 조직 어휘를 알아야 하는 모든 LLM 기능에 재사용할 수 있습니다. 조직 어휘의 단일 소스를 만들어 두면 기능이 늘 때마다 어휘 지식을 다시 가르칠 필요가 없습니다.