로컬라이제이션 파이프라인이 검색 증강 생성(RAG)으로 용어집 항목을 모델의 컨텍스트 윈도에 주입한다면, 아직 한 번도 제대로 측정되지 않은 검색 재현율 문제를 안고 있는 셈입니다.
패턴은 어디서나 같습니다. 입력 텍스트를 임베딩하고, 코사인 유사도로 용어집을 검색한 뒤, 상위 k개 결과를 프롬프트에 주입합니다. 출력은 문법적으로는 맞습니다. 그런데 용어는 틀립니다. 이 오류는 두 언어를 모두 알고 용어집까지 숙지한 사람이 아니면 알아채기 어렵습니다.
우리도 처음엔 이 단순한 버전부터 만들었습니다. 그리고 운영 환경의 용어집을 기준으로 검색 재현율을 측정해 보니, 실제 페이로드에서 적용 가능한 용어 대부분을 시스템이 놓치고 있다는 사실이 드러났습니다.
| 기법 | 검색 증강 로컬라이제이션(RAL) – 추론 시점에 컨텍스트 강화 |
| 핵심 해결책 | 문장 단위 임베딩이 아니라, 임베딩 전에 N-gram 분해 |
| 검색 모드 | 3가지(건너뛰기 / 프리로드 / 벡터 검색), 용어집 카디널리티에 따라 요청별 선택 |
| 임곗값 보정 | 로캘 쌍별 품질 점수를 기준으로 매주 지속적으로 수행 |
| 용어 오류 감소 | 5개 LLM 제공업체 전반에서 17–45% 감소(통제 연구, 42,000건 이상의 품질 평가) |
| 점수화 | 독립적인 크로스 모델 평가, 비동기식, 요청별 수행 |
문장 임베딩은 왜 용어집 항목을 놓칠까?#
용어집 항목은 1~3개 단어입니다. "Localization engine." "Access token." "Deployment pipeline."
입력 텍스트는 값의 길이가 두 단어(버튼 레이블)부터 이백 단어(제품 설명)까지 다양한 JSON 객체입니다. "Configure the localization engine for production deployment"라는 전체 문자열을 임베딩하면, 결과 벡터는 문장의 의미, 즉 구성과 운영 시스템에 관한 맥락을 포착합니다. 하지만 용어집과 직접 관련된 구문인 "localization engine"은 문장 수준 표현 속에 묻혀버립니다.
이 문장 벡터와 용어집 항목 "localization engine" 사이의 코사인 유사도는 0.6~0.7 수준에 머뭅니다. 검색 임곗값 아래입니다. 용어는 분명 입력에 있습니다. 그런데 검색 시스템은 그걸 놓칩니다.
문제는 세분성입니다. 문장 수준 표현으로 구문 수준 대상을 질의하고 있는 것이죠. 임베딩 모델은 문장 전체의 의미를 충실하게 표현합니다. 하지만 그 안의 개별 용어는 벡터 공간에서 독립적인 영역을 차지하지 못합니다.
우리는 이 사실을 꽤 뼈아프게 배웠습니다. 운영 환경의 페이로드, 즉 20~50개 키와 길이가 제각각인 값을 가진 중첩 JSON 객체에서 문장 수준 검색은 적용 가능한 용어집 항목 대부분을 놓치고 있었습니다. 로컬라이제이션 요청은 문제없이 완료됐습니다. 출력도 자연스럽게 읽혔습니다. 하지만 "localization engine"은 "translation tool"로 바뀌고 있었습니다. 문법적으로는 맞고 의미도 비슷하지만, 용어는 틀린 겁니다. 그런데도 파이프라인은 성공으로 보고했습니다.
N-gram 분해는 어떻게 용어집 검색을 바로잡을까?#
해결책은 임베딩 전에 입력을 구문 단위로 분해하는 것이었습니다. 모든 문자열 값은 서로 겹치는 N-gram 윈도의 집합으로 바뀝니다:
Input: "Configure the localization engine for production"
1-grams: [configure, the, localization, engine, for, production]
2-grams: [configure the, the localization, localization engine,
engine for, for production]
3-grams: [configure the localization, the localization engine,
localization engine for, engine for production]각 N-gram은 독립적인 검색 질의가 됩니다. "Localization engine"은 독립된 구문으로 용어집을 질의하고, 높은 유사도로 정확한 일치 항목을 찾아냅니다.
분해 파이프라인은 다음과 같습니다:
- 중첩 JSON 구조에서 모든 문자열 값을 재귀적으로 추출
- 문장으로 분리하고, HTML과 마크업 어노테이션 제거
- 공백 정규화, 바깥쪽 따옴표 제거, 포맷 이스케이프 해제
- 각 문장에서 겹치는 1-gram, 2-gram, 3-gram 구문 생성
50단어 분량의 문단 하나에서 대략 150개의 N-gram이 나옵니다. 키 20개로 이뤄진 일반적인 API 페이로드라면 검색 가능한 구문이 1,000~3,000개 생깁니다. 각 구문은 독립적으로 임베딩되고, 각 임베딩은 용어집의 벡터 인덱스를 대상으로 최근접 이웃 질의를 수행합니다.
우리는 원래 문제를 드러냈던 바로 그 운영 페이로드에서 차이를 측정했습니다. 이제 용어집 항목은 주변 문장 맥락과 상관없이 매칭됩니다. 200단어짜리 제품 설명 속에 묻힌 2단어 용어도 독립된 레이블과 같은 재현율로 검색됩니다.
용어집 크기에 따라 적응형 검색은 어떻게 작동할까?#
대규모 용어집에는 N-gram 분해와 배치 임베딩이 맞는 접근입니다. 반면 소규모 용어집에는 계산 비용만 커지고 비효율적이었습니다.
용어집 항목이 8개인 로컬라이제이션 엔진은 직접 주입 방식이 더 빠릅니다. 데이터베이스 질의 한 번으로 끝나고, 결정적이며, 밀리초 미만으로 처리됩니다. 반면 항목이 2,000개인 로컬라이제이션 엔진은 벡터 검색이 필요합니다. 컨텍스트 윈도 한계와 관련성 희석 때문에 전체를 그대로 주입하는 것은 불가능합니다.
요청별로 세 가지 검색 모드가 작동하며, 로캘 쌍의 용어집 카디널리티를 기준으로 선택됩니다:
| 모드 | 조건 | 동작 |
|---|---|---|
| 건너뛰기 | 일치 항목 없음 | 임베딩 없음, 검색 없음, 주입 없음 |
| 프리로드 | 카디널리티 임곗값 미만 | 단일 데이터베이스 질의로 모든 일치 항목 로드 후 직접 주입 |
| 검색 | 카디널리티 임곗값 초과 | 전체 N-gram 분해 → 배치 임베딩 → 벡터 최근접 이웃 검색 |
프리로드와 검색을 가르는 카디널리티 임곗값은 운영 트래픽 전반의 지연 시간 프로파일링을 바탕으로 정해지며, 임베딩 모델 성능, 용어집 크기 분포, 인프라 특성이 바뀌면 함께 조정됩니다. 처음 배포한 값은 텔레메트리가 조정 필요를 가리키기 전까지 약 3주간 유지됐습니다. 그 후로도 여러 차례 조정됐습니다. 엔진에 용어집 항목이 누적되고, 제공업체 업데이트에 따라 임베딩 모델 특성이 변하면서 최적의 임곗값도 계속 달라진다는 사실을 확인했기 때문입니다.
검색 지연 시간은 페이로드 크기가 아니라 용어집 복잡도에 따라 늘어납니다. 용어 10개를 가진 로컬라이제이션 엔진은 입력 길이와 관계없이 한 자릿수 밀리초 안에 처리됩니다. 용어 500개를 가진 로컬라이제이션 엔진은 전체 분해 파이프라인을 사용하지만, 안정적인 백그라운드 워크플로 단계의 지연 시간 예산 안에서 처리됩니다.
용어집 검색의 유사도 임곗값은 어떻게 보정할까?#
각 N-gram 임베딩은 유사도 임곗값을 넘는 최근접 이웃을 찾기 위해 벡터 인덱스를 질의합니다. 임곗값 아래의 일치는 노이즈로 버립니다.
이 임곗값은 검색 정밀도와 재현율을 동시에 좌우합니다:
- 너무 느슨한 경우: 관련 없는 용어가 프롬프트에 섞여 들어옵니다. 모델은 입력에 해당하지 않는 용어집 맥락을 보게 되고, 때로는 그걸 따라 전혀 다른 도메인의 용어를 사용한 출력을 생성합니다.
- 너무 엄격한 경우: 정당한 변형 표현과 형태 변화가 제외됩니다. "Deploying"이 용어집 항목 "deploy"와 매칭되지 못합니다. 재현율이 떨어집니다.
우리는 적절한 임곗값이 로캘 쌍마다 다르다는 사실을 발견했습니다. 영어→독일어 검색은 영어→일본어와 다른 유사도 분포를 보이는데, 이는 소스 N-gram과 용어집 항목 사이의 형태적 거리가 구조적으로 다르기 때문입니다. 하나의 전역 임곗값으로는 우리가 측정한 로캘 쌍 전반에서 일관된 재현율이 나오지 않았습니다.
이제 임곗값은 독립적인 점수화 파이프라인의 로캘 쌍별 품질 점수를 기준으로 지속적으로 보정됩니다. 점수화 시스템이 용어집 미준수(입력에는 있는데 출력에는 없는 용어)의 증가를 감지하면, 검색 재현율이 떨어진 것이므로 임곗값을 완화합니다. 반대로 모델이 관련 없는 용어를 적용하는 현상을 감지하면, 거짓 양성 주입이 늘어난 것이므로 임곗값을 더 엄격하게 조정합니다.
이 보정은 매주 실행됩니다. 꼭 그래야 합니다. 제공업체 업데이트 사이에 임베딩 모델의 동작이 바뀌고, 팀이 용어를 추가하면서 용어집 분포가 달라지며, 제품이 성장할수록 입력 텍스트의 특성도 함께 변하기 때문입니다.
검색된 용어집 항목은 로컬라이제이션 모델에 어떻게 주입될까?#
검색된 용어집 항목은 모델의 시스템 프롬프트 안에서 서로 다른 강제 동작을 갖는 두 가지 제약 클래스로 나뉩니다:
번역 불가 용어 – 타깃 출력에 변경 없이 그대로 들어가야 하는 소스 언어 문자열입니다. 브랜드명, 기술 식별자, 제품명이 여기에 해당합니다. 모델은 이를 원문 그대로 보존합니다.
사용자 지정 번역 – 모델 자체의 판단을 덮어쓰는 source→target 매핑입니다. "Localization engine"은 반드시 "moteur de localisation"이 되어야 합니다. 모델은 이를 타협 불가능한 어휘 제약으로 취급합니다.
두 클래스 모두 시스템 프롬프트에, 모델의 기본 동작보다 명시적으로 우선하는 규칙으로 주입됩니다. 프롬프트 계층 구조는 모델의 언어적 선호보다 용어집 준수를 우선시합니다.
이 구분은 점수화 단계에서 중요합니다. 독립적인 점수화 모델은 번역 불가 용어가 변경 없이 보존됐는지, 그리고 사용자 지정 번역이 정확히 적용됐는지를 각각 확인합니다. 제약 유형이 두 가지이므로 검증 기준도 두 가지가 필요합니다. 우리는 초기에 이 둘을 하나의 "용어집" 범주로 묶으면 점수화의 신뢰성이 떨어진다는 사실을 발견했습니다. 번역돼야 할 용어가 그대로 남았거나(혹은 그 반대의 경우여도), 통합된 검사에서는 정답으로 처리될 수 있었기 때문입니다.
모르는 언어의 로컬라이제이션 품질은 어떻게 검증할까?#
전체 검색 및 로컬라이제이션 파이프라인은 오류 없이 실행되면서도 용어적으로 잘못된 출력을 만들 수 있습니다. 용어집 항목을 놓쳐도 오류 신호는 발생하지 않습니다. 사용자 지정 번역이 잘못 적용돼도 200이 반환됩니다. 파이프라인은 성공합니다. 하지만 결과는 틀립니다.
이것이 대부분의 팀이 끝내 메우지 못하는 로컬라이제이션 관측 가능성의 격차입니다.
검색은 독립적인 비동기 점수화와 결합됩니다. 로컬라이제이션 요청이 완료되면, 별도의 점수화 모델이 로컬라이제이션 엔진의 구성에 따라 출력을 평가합니다:
- 용어집 준수 – 번역 불가 용어가 그대로 보존됐는가? 사용자 지정 번역이 정확히 적용됐는가?
- 지침 준수 – 로캘별 규칙이 지켜졌는가?
- 사용자 지정 점수화 기준 – 로컬라이제이션 팀이 엔진별로 정의한 품질 차원
채점 모델은 로컬라이제이션 모델과는 별도의 인프라에서 실행됩니다. 점수가 활성화된 로컬라이제이션 엔진을 거치는 모든 요청이 끝난 뒤 트리거되어, 백그라운드 워크플로에서 비동기적으로 동작합니다. 한 모델은 로컬라이즈하고, 다른 모델은 점수를 매깁니다. 교차 모델 평가는 자기 채점 문제를 없애줍니다.
채점 결과는 검색 보정에 다시 반영됩니다:
- 채점이 특정 로캘 쌍에서 글로서리 미준수 증가 추세를 감지합니다
- 조사 결과 검색 재현율이 떨어진 것으로 드러납니다. 즉, 현재 글로서리 분포에 비해 임곗값이 드리프트한 것입니다
- 임곗값을 조정하면 재현율이 회복되고 준수 점수도 안정화됩니다
이 루프가 시스템을 스스로 교정되도록 만드는 핵심입니다. 채점은 검색만으로는 확보할 수 없는 관측 가능성을 제공합니다. 이 장치가 없으면 팀은 자신들이 구사하지 못하는 언어로 로컬라이즈된 콘텐츠를 배포하면서도, 직접 구축한 글로서리가 실제로 적용되고 있는지 확인할 신호를 전혀 얻지 못합니다.
검색 재현율은 왜 시간이 지날수록 누적될까요?#
글로서리 용어를 정확히 적용한 모든 로컬라이제이션 요청은 제품 전반의 용어 일관성을 강화합니다. 반대로 용어를 놓친 요청은 모두 드리프트를 만들어냅니다. 한 화면에는 "로컬라이제이션 엔진"이 쓰이고, 다른 화면에는 "localization tool", 또 다른 화면에는 "localization module"이 쓰일 수 있습니다. 이런 불일치는 30개 로캘와 매주 이어지는 릴리스를 거치며 점점 누적됩니다.
높은 검색 재현율과 낮은 검색 재현율의 차이는 요청 하나하나의 품질 차이에 그치지 않습니다. 이것은 일관성이 누적되는 메커니즘입니다. 재현율이 높다는 것은 글로서리가 모든 화면, 모든 로캘, 모든 릴리스에 걸쳐 균일하게 적용된다는 뜻입니다. 재현율이 낮다는 것은 글로서리가 가끔씩만 작동한다는 뜻이며, 구조적으로는 글로서리가 없는 것과 같고 단지 무너지는 속도만 더 느릴 뿐입니다.
이것이 로컬라이제이션 엔지니어링에 의미하는 것#
여기서 설명한 검색 문제는 특정 구현에만 국한되지 않습니다. 임베딩 기반 검색으로 글로서리 인식 로컬라이제이션을 시도하는 모든 시스템에 구조적으로 존재하는 문제입니다. 문장 수준 입력 표현과 구 수준 글로서리 대상 사이의 세분성 불일치는 어떤 임베딩 모델을 쓰든, 어떤 벡터 데이터베이스를 쓰든, 어떤 LLM이 출력을 생성하든 그대로 존재합니다.
로컬라이제이션 자동화를 구축하는 팀 앞에는 선택지가 있습니다. 보이지 않는 재현율 격차를 감수한 채 문장 수준 검색을 받아들이거나, 그 격차를 메우는 분해 및 보정 인프라를 구축하거나입니다. 두 번째 길에는 세 가지 시스템이 필요합니다. n-그램 분해, 적응형 검색, 그리고 임곗값 관리에 다시 반영되는 채점 루프입니다. 각 시스템은 저마다의 운영 주기를 가집니다. 분해 로직은 입력 형식이 바뀌면서 발전하고, 검색 임곗값은 글로서리가 커질수록 달라지며, 채점 기준은 로컬라이제이션 팀이 자사 콘텐츠에서 무엇이 중요한지 배워가며 정교해집니다.
프로덕션 수준 품질의 검색 증강 로컬라이제이션은 일회성 구현이 아니라 지속적인 엔지니어링 실천입니다. 즉, 구축하고, 계측하고, 관찰하고, 계속 튜닝해야 하는 시스템입니다. 이 작업을 중심으로 새롭게 형성되는 로컬라이제이션 엔지니어링이라는 분야는 운영의 현실을 그대로 보여줍니다. 로컬라이제이션 인프라는 백엔드 서비스, CI/CD 파이프라인, 관측성 스택과 마찬가지로 지속적인 관리가 필요합니다.
다음 단계#
FAQ#
검색 증강 로컬라이제이션(RAL)이란 무엇인가요? 검색 증강 로컬라이제이션은 각 로컬라이제이션 요청에 추론 시점에서 글로서리 용어, 브랜드 보이스 규칙, 로캘별 지침을 더해주는 방식입니다. 즉, RAG의 기반이 되는 동일한 retrieve-inject 패턴을 로컬라이제이션에 적용한 것입니다. 5개 LLM 제공업체와 5개 유럽 언어를 대상으로 한 통제된 연구에서 RAL은 컨텍스트 보강이 없는 동일 모델 대비 용어 오류를 17–45% 줄였습니다.
왜 문장 수준 임베딩은 글로서리 용어를 놓치나요? 글로서리 용어는 보통 1~3개 단어로 이루어집니다. 이 용어가 전체 문장의 일부로 임베딩되면 문장 수준 의미 벡터 안에 녹아들어 갑니다. 임베딩은 문장 전체의 의미를 포착하기 때문에, "Configure the localization engine for production" 안의 "localization engine"은 독립적으로 인식되지 않습니다. 그 결과 문장 벡터와 글로서리 항목 사이의 코사인 유사도가 검색 임곗값 아래로 떨어집니다.
n-그램 분해는 어떻게 검색 재현율을 높이나요? 전체 입력 문자열을 그대로 임베딩하는 대신, 시스템은 임베딩 전에 텍스트를 서로 겹치는 1-그램, 2-그램, 3-그램 구문으로 분해합니다. 각 구문은 독립적인 검색 쿼리가 됩니다. 200단어짜리 문단에 묻혀 있는 2단어 글로서리 용어도 독립된 레이블과 같은 재현율로 매칭됩니다. 주변 문맥과 분리해 별도로 질의하기 때문입니다.
시스템은 몇 가지 검색 모드를 사용하나요? 세 가지입니다. Skip(글로서리 항목 0개 – 검색 불필요), preload(카디널리티 임곗값 미만 – 모든 항목 직접 로드), vector search(임곗값 초과 – 전체 n-그램 분해 및 임베딩)입니다. 모드는 해당 로캘 쌍의 글로서리 카디널리티를 기준으로 요청별로 선택됩니다.
유사도 임곗값은 어떻게 유지되나요? 임곗값은 독립적인 채점 파이프라인의 로캘 쌍별 품질 점수를 바탕으로 매주 보정됩니다. 글로서리 미준수 추세가 올라가면 재현율을 높이기 위해 임곗값을 낮추고, 관련 없는 용어가 프롬프트에 섞여 들어오기 시작하면 임곗값을 높입니다. 형태론적 거리의 차이 때문에 로캘 쌍마다 필요한 임곗값도 다릅니다.
로컬라이제이션 품질을 위한 교차 모델 채점은 어떻게 작동하나요? 각 로컬라이제이션 요청이 완료되면, 다른 인프라에서 실행되는 별도의 모델이 글로서리 용어가 올바르게 적용되었는지, 로캘별 지침이 지켜졌는지, 사용자 정의 품질 기준이 충족되었는지를 평가합니다. 한 모델은 로컬라이즈하고, 다른 모델은 점수를 매깁니다. 이를 통해 자기 채점 편향을 없애고, 검색만으로는 확보할 수 없는 관측 가능성을 만들어냅니다.
글로서리 검색 재현율이 낮으면 어떻게 되나요? 검색 재현율이 낮다는 것은 글로서리가 일관되지 않게 작동한다는 뜻입니다. 어떤 화면에는 올바른 용어가 적용되지만, 다른 화면에는 그렇지 않습니다. 30개 이상의 로캘와 매주 이어지는 릴리스를 거치며 이런 불일치는 용어 드리프트로 누적됩니다. 글로서리는 존재하지만 강제되지 않습니다. 몇 달이 지나면 이는 구조적으로 글로서리가 없는 것과 다를 바 없습니다.
로컬라이제이션 관측 가능성 격차란 무엇인가요? 로컬라이제이션 파이프라인은 오류 없이 실행되면서도 용어적으로 잘못된 출력을 만들 수 있습니다. 놓친 글로서리 용어는 어떤 오류 신호도 발생시키지 않습니다. API는 200을 반환하고 번역도 문법적으로는 유효합니다. 관측 가능성 격차란 "파이프라인은 성공했다"와 "용어는 정확하다" 사이의 간극입니다. 독립적인 채점은 모든 요청에서 글로서리 준수를 측정함으로써 이 간극을 메웁니다.
