AI Translation Tool의 내부: 23개의 Agent 도구와 Human-in-the-Loop 승인이 번역 품질을 높게 유지하는 방법

대부분의 AI translation tool은 같은 패턴을 따릅니다: 텍스트를 붙여넣고 번역을 받습니다. 이는 빠른 이메일에는 효과적이지만, 여러 언어와 브랜드 용어 사전, 그리고 배포 전에 변경 사항을 검토해야 하는 팀이 있는 프로덕션 애플리케이션에서 수천 개의 번역 키를 관리할 때는 작동하지 않습니다.

저희는 Better i18n의 AI 시스템을 다르게 구축했습니다. 단순한 번역 API 대신, 23개의 전문 도구를 갖춘 대화형 Agent, 모든 쓰기 작업에 대한 Human-in-the-Loop 승인, 그리고 실제 번역 관리 워크플로우를 위해 설계된 아키텍처를 만들었습니다.

이 글은 그 이면의 엔지니어링을 자세히 설명합니다.

번역 API가 아닌 Agent인 이유

일반적인 기계 번역 검토 워크플로우는 다음과 같습니다: 문자열 내보내기, 번역 서비스로 전송, 결과 받기, 가져오기, 수동 검토, 문제 수정, 재내보내기. 느리고 오류가 발생하기 쉬우며, 번역을 정확하게 만드는 컨텍스트에서 번역 프로세스를 분리합니다.

Agent 기반 접근 방식은 이 모델을 근본적으로 바꿉니다. 파일을 조작하는 대신, AI가 프로젝트에 직접 작동합니다 — 키를 읽고, 사전을 이해하고, 동기화 설정을 확인하고, 실시간으로 승인할 수 있는 변경 사항을 제안합니다.

핵심 인사이트는 번역 관리가 단일 작업이 아니라는 것입니다. 프로젝트 상태를 읽고, 결정을 내리고, 변경을 실행하고, 결과를 확인하는 워크플로우입니다. 여러 도구를 갖춘 Agent는 이를 자연스럽게 처리합니다. 번역 API는 그렇지 않습니다.

23개 도구 아키텍처

Agent는 매우 다른 권한 모델을 가진 두 가지 카테고리로 나뉜 23개의 전용 도구에 접근할 수 있습니다.

읽기 도구: 완전한 자율성

10개의 도구가 Agent에게 프로젝트에 대한 읽기 접근권을 부여합니다. 이들은 데이터를 수정할 수 없으므로 승인 없이 자동으로 실행됩니다:

• getTranslations — 키, Namespace, 언어, 상태별 필터링으로 번역을 가져옵니다
• getKeyDetails — 컨텍스트 노트, 태그, 언어별 상태를 포함한 개별 키의 메타데이터를 검색합니다
• getLanguages — 완성도 퍼센트와 함께 설정된 언어를 나열합니다
• getProjectStats — 프로젝트 전체 메트릭을 반환합니다: 총 키, 언어, 번역 커버리지
• getDoctorReport — 누락된 번역, 미사용 키, 복수형 문제, 용어 불일치를 식별하는 진단을 실행합니다
• getSyncs 및 getSyncDetails — GitHub/GitLab 동기화 통합과 최근 활동을 검사합니다
• getContentModels 및 getContentEntries — CMS 콘텐츠 구조와 항목을 탐색합니다
• createPlan — Agent가 여러 단계를 조율해야 할 때 실행 계획을 생성합니다

Agent는 변경을 제안하기 전에 컨텍스트를 구축하기 위해 이 도구들을 사용합니다. "모든 누락된 키를 프랑스어로 번역해"라고 요청하면, Agent는 먼저 getTranslations를 호출하여 어떤 키가 누락되었는지 정확히 파악하고, 그 다음 getProjectStats를 호출하여 범위를 이해한 후 단일 타겟 제안을 생성합니다.

쓰기 도구: Human-in-the-Loop 승인

11개의 도구가 프로젝트 데이터를 수정할 수 있습니다. 각각은 실행 전에 명시적인 인간의 승인이 필요합니다. 이것이 AI 번역 품질에 대한 접근 방식의 핵심입니다 — AI가 제안하고, 인간이 결정합니다.

번역 도구:

• proposeTranslations — 대상 언어에서 누락된 키에 대한 새 번역을 생성합니다
• proposeTranslationEdits — 컨텍스트, 사전 또는 피드백을 기반으로 기존 번역의 개선을 제안합니다
• translateBatch — 단일 작업으로 여러 언어에 걸쳐 여러 키를 처리합니다

키 관리 도구:

• proposeKeys — 코드베이스 분석을 기반으로 새 번역 키를 제안합니다
• proposeDeleteKeys — 미사용 또는 중복 키를 식별하고 정리를 제안합니다

언어 관리 도구:

• proposeLanguages — 프로젝트 요구 사항에 따라 추가할 새 언어를 권장합니다
• proposeLanguageEdits — 언어 표시 이름, 폴백 체인 또는 설정을 수정합니다

퍼블리싱 도구:

• publishChanges — 승인된 번역을 CDN에 푸시하거나 GitHub PR을 트리거합니다

콘텐츠 관리 도구:

• proposeContentEntries — CMS 콘텐츠 항목을 생성하거나 업데이트합니다
• proposeContentModel — 콘텐츠 모델에 대한 스키마 변경을 제안합니다
• proposePublishEntries — 콘텐츠 항목을 게시 대기열에 추가합니다

Human-in-the-Loop: 승인 흐름 엔지니어링

"Human-in-the-Loop"라는 용어는 AI 마케팅에서 많이 사용됩니다. 저희 시스템에서 실제로 어떻게 작동하는지 설명합니다.

쓰기 도구가 호출되면, Agent는 직접 실행하지 않습니다. 대신, 정확히 무엇이 변경될지를 보여주는 구조화된 diff인 제안을 생성합니다. 제안은 채팅 인터페이스에 검토 가능한 아티팩트로 나타납니다.

번역 제안의 경우, 다음을 볼 수 있습니다:

• 기본 언어의 소스 문자열
• 대상 언어의 제안된 번역
• 적용된 사전 용어
• 신뢰도 컨텍스트 (단순한 UI 레이블인가요, 아니면 복잡한 마케팅 문장인가요?)

그런 다음 세 가지 옵션이 있습니다:

1. 모두 승인 — 한 번의 클릭으로 모든 제안된 변경 사항을 수락합니다
2. 선택적 승인 — 일부 번역을 수락하고 나머지를 거부합니다
3. 변경 요청 — Agent에게 무엇을 수정할지 알려주면 수정된 제안을 생성합니다

쓰기 작업은 승인 후에만 실행됩니다. 이것은 "확인/취소" 대화 상자가 아닙니다 — 검사하고, 편집하고, 반복할 수 있는 진정한 검토 단계입니다.

AI 번역 품질에 이것이 중요한 이유

기계 번역 검토는 대부분의 현지화 워크플로우의 병목입니다. 팀들은 검토를 건너뛰거나 (오류를 배포하거나) 모든 것을 수동으로 검토합니다 (느리게 진행). 저희 HITL 접근 방식은 중간 지점을 찾습니다:

• AI가 간단한 번역의 80%를 처리합니다
• 인간은 판단이 필요한 20%에 검토 노력을 집중합니다
• 모든 번역에는 명확한 출처가 있습니다: AI 생성, 인간 검토, 또는 인간 편집
• 감사 추적이 누가 무엇을 승인했는지 기록하여 컴플라이언스를 간소화합니다

점진적 렌더링: 스트리밍 번역 테이블

Agent가 키 배치에 대한 번역을 생성하면, 결과가 한 번에 모두 나타나지 않습니다. 번역 테이블은 채팅 인터페이스에 점진적으로 스트리밍됩니다 — 각 행은 번역이 완료될 때 렌더링됩니다.

이것은 사용자 경험에 의해 주도되는 엔지니어링 선택입니다. 6개 언어에 걸쳐 150개의 키를 번역할 때, 그것은 900개의 개별 번역입니다. 무언가를 보여주기 전에 900개가 모두 완료될 때까지 기다리는 것은 몇 분 동안 로딩 스피너를 바라보는 것을 의미합니다. 점진적 렌더링은 첫 번째 결과를 즉시 검토하기 시작할 수 있게 합니다.

구현은 server-sent events를 사용하여 도구 결과를 채팅 인터페이스로 스트리밍합니다. 프론트엔드는 행이 도착하는 대로 추가하는 변경 가능한 번역 테이블 컴포넌트를 유지합니다.

컨텍스트 관리: 지반을 유지하기

대규모 언어 모델은 긴 대화에서 컨텍스트를 잃는 경향이 있습니다. 저희는 세 가지 메커니즘으로 이를 해결합니다:

30초 프로젝트 컨텍스트 캐시

Agent가 프로젝트 데이터를 읽으면, 결과는 30초 동안 캐시됩니다. Agent가 다단계 작업 중에 프로젝트 상태를 여러 번 참조해야 하는 경우, 중복 API 호출을 하는 대신 캐시에 접근합니다. 이는 지연 시간을 줄이고 복잡한 워크플로우 중에 Agent가 일관성 없는 상태를 보는 것을 방지합니다.

컨텍스트 축소 (slimToolResults)

Better i18n API의 도구 응답은 클 수 있습니다 — 2,000개의 키와 12개의 언어를 가진 프로젝트는 상당한 페이로드를 생성합니다. slimToolResults 시스템은 도구 응답에서 비필수 데이터가 대화 컨텍스트에 들어가기 전에 자동으로 제거합니다.

예를 들어, Agent가 getTranslations를 호출하면, 전체 응답에는 생성 타임스탬프, 버전 ID, 사용자 귀속과 같은 메타데이터가 포함됩니다. slimToolResults 패스는 Agent가 필요로 하는 데이터만 유지합니다: 키 이름, 소스 문자열, 번역. 이는 토큰 사용량을 크게 줄이고 컨텍스트 윈도우 오버플로우를 방지합니다.

50단계 대화 제한

각 대화는 최대 50개의 Agent 단계(도구 호출)를 지원합니다. 이는 복잡한 워크플로우에 충분합니다 — 전체 Namespace를 번역하고, 결과를 검토하고, 편집하고, 게시합니다 — 동시에 무한 루프를 방지합니다. 단계 카운터는 UI에 표시되므로 남은 용량을 항상 알 수 있습니다.

채팅 기록: 이중 스토리지 아키텍처

Agent 대화는 두 곳에 동시에 저장됩니다:

• IndexedDB (브라우저 로컬) — 대시보드로 돌아올 때 네트워크 지연 없이 즉각적인 대화 로딩을 제공합니다
• Postgres (서버 사이드) — 모든 Agent 상호작용의 영구적이고 검색 가능한 감사 추적을 유지합니다

이중 스토리지 접근 방식은 두 가지 경쟁하는 요구 사항을 해결합니다. 개발자들은 최근 대화에 즉각적인 접근을 원합니다 (IndexedDB는 서브밀리초 읽기를 제공합니다). 팀들은 컴플라이언스와 지식 공유를 위한 감사 추적이 필요합니다 (Postgres는 내구성 있고 쿼리 가능한 스토리지를 제공합니다).

AI 채팅을 열면, 대화는 IndexedDB에서 즉시 로드됩니다. Postgres 복사본은 백그라운드에서 동기화되며, 로컬 스토리지가 지워질 경우 진실의 원천으로 사용됩니다.

실제 워크플로우: 프로덕션 앱에 한국어 추가하기

Agent가 실제 작업을 처리하는 방법의 구체적인 예를 보여드립니다.

1단계: 요청합니다 — "프로젝트에 한국어를 추가해야 합니다. common과 settings Namespace의 모든 것을 번역해주세요."

2단계: Agent가 읽습니다 — getLanguages를 호출하여 (한국어가 설정되지 않았음을 확인), common Namespace에 대한 getTranslations를 호출하여 (89개의 키 발견), settings Namespace에 대한 getTranslations를 호출합니다 (34개의 키 발견). 합계: 번역할 123개의 키.

3단계: Agent가 언어 추가를 제안합니다 — 프로젝트에 한국어(ko)를 추가하기 위해 proposeLanguages를 호출합니다. 제안을 보고 승인합니다.

4단계: Agent가 배치로 번역합니다 — common Namespace에 대해 translateBatch를 호출하고, 그 다음 settings Namespace에 대해 호출합니다. 번역이 채팅에 점진적으로 스트리밍됩니다. 영어 소스 문자열 옆에 한국어 번역이 나타나는 것을 볼 수 있습니다.

5단계: 검토합니다 — 번역을 검토하고, 캐주얼한 앱 UI에 과도하게 격식체를 사용한 두 개를 표시하고, Agent에게 조정하라고 알립니다.

6단계: Agent가 수정합니다 — 피드백과 함께 proposeTranslationEdits를 호출하고 표시된 두 문자열에 대한 수정된 번역을 생성합니다. 승인합니다.

7단계: 게시합니다 — Agent에게 게시하라고 말하면, publishChanges를 호출하고 한국어 번역이 CDN에 라이브됩니다.

총 시간: 검토 및 게시된 123개의 번역에 약 10분. Agent 없이는 이 워크플로우가 일반적으로 내보내기-번역-가져오기-검토 사이클에 수 시간이 걸립니다.

구축하지 않기로 선택한 것들

제한 사항에 대한 투명성은 기능 문서만큼 중요합니다.

• 독점 번역 엔진 없음 — 기반 모델로 Google Gemini를 사용합니다. 맞춤형 "신경 번역 엔진"이나 독점 AI를 주장하지 않습니다.
• 번역의 자동화된 A/B 테스트 없음 — 모델은 사용자가 선택합니다. 여러 모델의 출력을 비교하는 프레임워크는 없습니다.
• Translation Memory 없음 — TM 퍼지 매칭이 아닌 사전 기반 용어 일관성을 사용합니다. TM이 필요한 경우, Better i18n은 현재 적합한 도구가 아닙니다.
• 보장된 정확도 메트릭 없음 — AI 번역 품질은 언어 쌍과 콘텐츠 유형에 따라 달라집니다. 모든 고객 대상 콘텐츠에 인간 검토를 권장합니다. 이것이 바로 HITL이 모든 쓰기 작업에 내장된 이유입니다.

사용해 보세요

AI Agent는 모든 Better i18n 플랜에서 사용할 수 있습니다. 대시보드를 열고, 채팅 아이콘을 클릭하고, 간단한 것부터 시작하세요: "이 프로젝트의 번역 상태를 보여주세요."

거기서 실제 작업을 시도해 보세요. 누락된 번역을 찾고, 생성하고, 승인 프로세스를 안내하도록 요청하세요. Agent는 대화식으로 탐색하도록 설계되었습니다 — 도구 이름이나 API 엔드포인트를 암기할 필요가 없습니다.

Better i18n 시작하기 →