전문 번역 워크플로우에 쓸 수 있는 라이브러리와 도구

1. 먼저 구분해야 할 것

“번역 라이브러리”라는 말이 너무 넓습니다. 앱 런타임, 파일 번역 CLI, 전문 CAT/TMS, LLM agent, 품질 평가 도구가 모두 다릅니다.

전문 번역에서 중요한 것은 “문장을 한국어로 바꾸는 함수”가 아닙니다.

전문 번역은 용어 일관성, 문체, 도메인 맥락, 기존 승인 번역, 지역/문화 적합성, 포맷 보존, 검수 루프까지 포함합니다. 그래서 단일 라이브러리 하나로 끝나기보다 여러 레이어를 조합합니다.

i18n runtime: 앱에서 번역문을 불러오고 plural/interpolation을 처리
Localization CLI: JSON/PO/XLIFF/ARB 같은 리소스 파일을 안전하게 번역
CAT/TMS: 전문 번역가가 TM, glossary, review 상태를 관리
LLM agent: 초벌 번역, critique, refine, tone/style adaptation
QE/evaluation: 자동 품질 측정, regression test, human review routing

잘못된 질문“한국어 번역 라이브러리 뭐 써?”

좋은 질문“우리 도메인의 용어집과 TM을 넣고, LLM이 번역→비평→수정한 뒤 QE로 걸러낼 수 있는 workflow가 뭐야?”

결론전문 번역은 library 하나보다 pipeline 설계가 더 중요합니다.

2. 전문 번역사들이 실제로 쓰는 Workflow

현업 번역사는 보통 “번역기 → 복붙”이 아니라 CAT tool 안에서 TM, termbase, QA, review package를 중심으로 일합니다.

Project intake / Brief 확인

PM 또는 클라이언트가 source file, reference, style guide, glossary, TM, deadline, 품질 기준을 전달합니다. 번역사는 먼저 지시사항과 금지사항을 확인합니다.

BriefStyle guideReference

File preparation / Analysis

Trados, memoQ, Phrase 같은 CAT tool에 파일을 넣고 word count, repetitions, 100% match, fuzzy match, new words를 분석합니다. 이 분석이 견적과 일정의 기준이 됩니다.

Analysis100% matchFuzzy match

TM / Termbase 준비

기존 승인 번역을 Translation Memory로 연결하고, 용어집을 termbase로 불러옵니다. preferred term, forbidden term, product name, do-not-translate 목록을 설정합니다.

Translation MemoryTermbaseTBXMultiTerm

Pre-translation / MTPE 준비

TM exact/fuzzy match를 먼저 채우고, 허용된 경우 DeepL, Google, custom MT, LLM output으로 나머지 segment를 pre-translate합니다. 이후 작업은 “새 번역” 또는 “MTPE”가 됩니다.

Pre-translateDeepLMTPE

Segment-by-segment translation

번역사는 CAT editor에서 segment 단위로 작업합니다. TM match, concordance search, termbase hit, client instruction, reference를 계속 확인하며 번역합니다.

CAT editorConcordanceAutosuggest

Self-review / In-tool QA

1차 번역 후 본인이 다시 읽고 CAT tool의 QA를 돌립니다. 숫자, 태그, 누락, 용어 위반, 반복 segment 불일치, punctuation, spacing을 먼저 제거합니다.

Tag checkNumber checkTerminology QA

Editing / Bilingual revision

ISO 17100 기준의 핵심 단계입니다. 두 번째 qualified linguist가 원문과 번역문을 대조하면서 오역, 누락, 의미 추가, 용어, register를 검토합니다.

ISO 17100RevisionTEP

Proofreading / Monolingual review

최종 독자가 읽는 한국어 품질을 봅니다. 원문 대조보다 자연스러움, 문장 흐름, 맞춤법, typography, style guide 준수를 봅니다.

ProofreadReadabilityNative fluency

LQA / MQM scoring

대형 LSP나 regulated industry에서는 MQM 같은 error typology로 오류를 분류하고 severity를 매깁니다. Critical/Major/Minor 기준으로 fail/pass가 정해집니다.

MQMLQACritical/Major/Minor

Delivery / TM update / Feedback loop

최종 target file을 생성하고 QA report를 첨부합니다. 승인된 segment는 TM에 반영하고, 신규 용어는 termbase 후보로 올립니다. 다음 프로젝트 품질은 이 축적에서 결정됩니다.

Return packageTM updateQA report

현업 용어	무슨 뜻인가	AI/LLM 도입 시 해석
TEP	Translate → Edit → Proofread. 전문 번역 서비스의 고전적 기본 흐름.	LLM 초벌 번역을 쓰더라도 Editing/Proofreading은 사라지지 않고, 오히려 감수 기준이 더 중요해집니다.
ISO 17100	번역 서비스 품질 표준. 번역자/감수자 역량, 프로세스, traceability를 요구.	AI output도 전문 서비스로 납품하려면 누가 검수했고 어떤 기준으로 승인했는지 기록해야 합니다.
ISO 18587	Machine Translation Post-Editing(MTPE) 프로세스 관련 표준.	LLM 번역은 MTPE의 확장으로 다루는 것이 현실적입니다. Light PE와 Full PE 기준을 나눠야 합니다.
MQM	Accuracy, Fluency, Terminology, Style, Locale convention 등으로 오류를 분류하는 품질 평가 체계.	LLM judge rubric을 만들 때 MQM 분류를 그대로 쓰면 전문 번역사와 소통하기 쉽습니다.
LQA	Linguistic Quality Assurance. 샘플링/전체 검사로 번역 품질을 수치화.	모델/프롬프트 변경 전후를 비교하고, human review가 필요한 segment를 라우팅하는 기준이 됩니다.

3. LLM을 얹은 전문 번역 파이프라인

LLM을 번역기에 직접 붙이는 수준이 아니라, 맥락 수집 → 번역 → 비평 → 개선 → 평가 → 사람 검수 → 메모리 반영까지 닫힌 루프를 만듭니다.

Source 분해와 포맷 보존

문서, JSON, PO, XLIFF, ARB, SRT 등을 segment 단위로 쪼갭니다. placeholder, HTML tag, ICU plural, 변수명은 절대 깨지면 안 됩니다.

cli-localizeJTAOkapiXLIFF

Context packet 생성

번역 대상 문장에 붙일 자료를 모읍니다. 기존 승인 번역, 제품 설명, 스크린샷, 도메인 문서, 금지어, 선호 표현, 문체 규칙이 들어갑니다.

TMGlossaryStyle guideRAG

초벌 번역

LLM이 context packet을 보고 번역합니다. 이 단계에서 “자연스러운 한국어”, “존댓말”, “제품 UI 톤”, “용어집 준수”를 명시합니다.

ClaudeGPTGeminiOllama

Critique / Reflection

다른 프롬프트 또는 다른 모델이 번역문을 비평합니다. 정확성, 누락, 과잉 번역, 용어 위반, 한국어 어색함, UI 길이를 점검합니다.

translation-agent 핵심LLM judge

Refinement

비평 결과를 반영해 개선 번역을 만듭니다. 필요하면 1~3회 반복합니다. 전문 번역 품질은 이 loop에서 많이 올라갑니다.

AphraLangGraphCustom agent

자동 품질 평가(QE)

COMET, LLM judge, rule validator로 점수를 냅니다. 낮은 점수 또는 위험 segment만 사람에게 보냅니다.

COMETDeepEvalSacreBLEU

Human review와 feedback loop

전문 번역가/리뷰어가 승인한 결과를 TM과 glossary에 다시 반영합니다. 시간이 지날수록 브랜드 언어와 도메인 일관성이 좋아집니다.

TradosmemoQPhraseCrowdin

4. 전문 번역사가 자주 쓰는 CAT/TMS/QA 도구

LLM 라이브러리를 붙이기 전에, 실제 번역사가 어떤 작업대에서 일하는지 이해해야 합니다. 이 도구들이 TM, termbase, package, review, QA의 중심입니다.

Trados Studio + MultiTerm

엔터프라이즈/대형 LSP에서 가장 자주 요구되는 데스크톱 CAT tool 계열입니다. 복잡한 파일 형식, 큰 TM, 패키지 교환, MultiTerm 용어 관리가 강점입니다.

Enterprise standardTMTermbase

공식: trados.com
LLM 연결 포인트: segment suggestion, terminology check, reviewer assistant, QA issue explanation.

memoQ

프리랜서와 technical/medical 번역가들이 선호하는 경우가 많습니다. LiveDocs, 강력한 필터, regex/QA, terminology workflow가 좋습니다.

Translator favoriteRegex QALiveDocs

공식: memoq.com
LLM 연결 포인트: fuzzy match explanation, term extraction, consistency repair, bilingual review assistant.

Phrase / Memsource

Cloud-first TMS/CAT입니다. LSP, SaaS localization, 팀 협업, MTPE workflow에서 많이 쓰입니다. 프로젝트 관리와 MT integration이 강합니다.

Cloud TMSMTPECollaboration

공식: phrase.com
LLM 연결 포인트: workflow automation, style guide enforcement, review queue triage.

Smartcat / Lokalise / Crowdin

클라우드 기반 협업과 제품 localization에서 자주 쓰입니다. 개발자 workflow와 연결하기 쉽고, reviewer/translator/PM이 한 공간에서 움직입니다.

Cloud collaborationProduct localizationAPI

링크: Smartcat · Lokalise · Crowdin
LLM 연결 포인트: GitHub sync, AI pre-translation, glossary enforcement, reviewer assignment.

Xbench

전문 번역 QA에서 자주 언급되는 독립형 QA 도구입니다. CAT tool이 놓치는 용어, 숫자, 일관성, regex rule 문제를 최종 gate에서 잡는 용도입니다.

Final QARegexTerminology

공식: xbench.net
LLM 연결 포인트: QA report 해석, 오류 cluster 정리, 반복 오류 수정 제안.

Verifika / QA Distiller

번역 QA specialist들이 쓰는 별도 QA 도구군입니다. number, tag, terminology, inconsistency, punctuation, custom rule 검사에 강합니다.

QA specialistBatch QAReports

링크: Verifika · QA Distiller
LLM 연결 포인트: 자동 QA 결과를 MQM category로 매핑하고 수정 우선순위를 정함.

전문 번역사의 산출물	내용	자동화할 수 있는 부분
Bilingual file / package	원문과 번역문 segment가 함께 들어 있는 작업 파일. 리뷰와 QA의 기준.	segment별 LLM critique, 위험 segment labeling, reviewer comment 초안.
Clean target file	Word, Excel, HTML, JSON, InDesign 등 최종 납품 파일.	format validation, placeholder/tag check, UI screenshot QA.
Updated TM	승인된 번역 segment를 누적한 메모리.	embedding 기반 TM 검색, 중복/오염 segment 감지, domain별 TM 분리.
Termbase / glossary update	새로 확정된 용어, 금지어, product naming rule.	candidate term extraction, 용어 충돌 탐지, forbidden term QA.
QA / LQA report	자동 QA 결과, MQM 오류 분류, severity, pass/fail 근거.	LLM judge + MQM rubric으로 오류 설명과 수정 제안 생성.

5. 실제로 볼 만한 라이브러리와 도구

아래는 “전문 번역 과정”에 가까운 순서로 정리했습니다. 단순 i18n runtime은 제외하고, 번역 생산/검수 과정에 직접 관여하는 것 위주입니다.

Andrew Ng translation-agent

LLM 번역의 agentic reflection workflow를 보여주는 대표 레퍼런스입니다. 번역 → 비평 → 개선 구조를 명확히 구현합니다.

핵심 레퍼런스PythonMIT

링크: github.com/andrewyng/translation-agent
X 포스트: Andrew Ng announcement
강점: 용어집, 스타일, 지역 변형, technical terms를 프롬프트로 제어하기 쉬움.
주의: README에도 mature software가 아니라고 되어 있어, 프로덕션에는 확장/검증이 필요.

Supervertaler Workbench

전문 번역가/CAT workflow에 가장 가까운 오픈소스 작업대입니다. LLM을 CAT tool 옆에 붙이는 느낌에 가깝습니다.

CAT/TMS 친화TMGlossary

링크: github.com/Supervertaler/Supervertaler-Workbench
공식 사이트: supervertaler.com
강점: GPT-4, Claude, Gemini, Mistral, Ollama, TM, glossary, memoQ/Trados/CafeTran/Phrase/Déjà Vu 연동.
추천 상황: 전문 번역가의 작업 환경에 LLM을 붙이고 싶을 때.

JTA: JSON Translation Agent

JSON i18n 파일을 위한 agentic translation CLI입니다. 제품 문자열 번역에 직접적으로 쓸 수 있는 방향입니다.

JSON i18nReflectionTerminology

링크: github.com/ckanner/jta
강점: AI가 번역→평가→개선. terminology detection, format preservation, incremental translation 지원.
추천 상황: 앱/웹 제품의 JSON localization 파일을 고품질로 관리할 때.

Aphra

문서/블로그/긴 글을 위한 multi-stage LLM translation agent입니다. glossary creation, contextual search, critique, refinement가 핵심입니다.

문서 번역Context searchCritique

링크: github.com/DavidLMS/aphra
공식 페이지: davidlms.github.io/aphra
강점: 단순 문장 치환이 아니라 translator notes, 문체 개선, 맥락 보존을 지향.
주의: 전문 번역가 대체가 아니라, 소규모 프로젝트의 고품질 보조 도구로 포지셔닝.

cli-localize

대량 localization 파일을 LLM에 안전하게 넣기 위한 CLI입니다. 품질 엔진보다는 구조 보존/배치 처리 레이어에 가깝습니다.

PO/JSON/ARB/SRTBatchingValidation

링크: github.com/yigitkonur/cli-localize
강점: token-aware batching, placeholder preservation, 5-layer validation, resumable session.
추천 상황: 번역 파일이 크고, LLM이 구조를 망가뜨리지 않게 하고 싶을 때.

Hyperlocalise

X에서 localization engineering 관점의 LLM CLI로 언급되는 도구입니다. TMS adapter와 evaluation framework 방향이 중요합니다.

확인 필요TMS adapterEvaluation

사이트: hyperlocalise.dev
X 포스트: 관련 X 포스트
언급 기능: OpenAI, Anthropic, Gemini, Ollama, Bedrock 등 LLM provider와 Crowdin/Lokalise/Phrase/Smartling/LILT adapter.
주의: GitHub repo는 이번 검색에서 확실히 특정하지 못했으므로 도입 전 직접 확인 권장.

6. 전문 번역에는 평가 라이브러리가 반드시 붙어야 한다

LLM이 그럴듯한 한국어를 만들었다고 좋은 번역은 아닙니다. 누락, 오역, 용어 위반, 과잉 의역, 문체 불일치를 잡아야 합니다.

도구	역할	링크	어떻게 쓰나
COMET	현대 번역 품질 평가 / QE	github.com/Unbabel/COMET	번역 후보 점수화, 모델/프롬프트 변경 시 regression 비교.
SacreBLEU	전통적 자동 평가 baseline	github.com/mjpost/sacrebleu	고정 test set에서 프롬프트/모델 변경 전후를 숫자로 비교.
DeepEval	LLM-as-a-judge 평가 harness	github.com/confident-ai/deepeval	정확성, 유창성, 용어 준수, 브랜드 톤, 한국어 자연스러움 rubric 구성.
Qdrant / pgvector	Translation Memory RAG	Qdrant · pgvector	기존 승인 번역 segment를 검색해서 LLM context에 넣음.
sentence-transformers	TM/용어 검색용 embedding	github.com/UKPLab/sentence-transformers	source segment와 유사한 기존 번역을 찾는 fuzzy TM 역할.

평가 rubric 예시 - Accuracy: 원문 의미가 빠지거나 바뀌지 않았는가? - Fluency: 한국어로 자연스러운가? - Terminology: 승인 용어집을 지켰는가? - Style: 제품/브랜드 톤과 맞는가? - Locale fit: 한국 사용자에게 어색한 문화/표현이 없는가? - Format safety: placeholder, HTML tag, ICU syntax가 보존되었는가? - UI constraint: 버튼/라벨/모바일 화면에 들어갈 길이인가?

7. 한국어 전문 번역에서 별도로 봐야 할 것

한국어는 “번역 정확도”만으로 끝나지 않습니다. 조사, 존댓말, 주어 생략, UI 길이, 한자어/외래어 선택이 품질을 크게 좌우합니다.

이슈	문제	대응
조사	동적 명사 뒤에 을/를, 이/가, 은/는이 달라짐.	es-hangul로 후처리. 단, 전문 번역 엔진이 아니라 한국어 문장 보정 레이어로 봐야 함.
존댓말/문체	합니다체, 해요체, 명령형, 캐주얼 톤이 섞이면 제품 신뢰도가 떨어짐.	style guide에 “버튼은 명사형”, “알림은 해요체 금지” 같은 규칙을 명시하고 LLM judge로 검사.
용어 일관성	account가 계정/어카운트/계좌로 섞이면 치명적.	glossary와 forbidden terms를 분리하고, 용어 위반은 자동 fail 처리.
UI 길이	한국어가 짧아질 때도 있고 길어질 때도 있어 버튼/탭/카드에서 깨질 수 있음.	문자 수, 픽셀 폭, 모바일 breakpoint screenshot QA를 추가.
직역/의역 균형	기술 문서는 직역이 안전하지만, 마케팅 문구는 한국어 카피라이팅이 필요.	content type별 prompt와 rubric 분리: UI, docs, marketing, legal, support.

한국어 glossary 항목 예시 { "source": "wallet", "approved_ko": "지갑", "forbidden": ["월렛", "전자지갑"], "context": "crypto product navigation label", "notes": "브랜드 톤상 짧고 쉬운 표현 사용. 금융 계좌와 혼동 금지." }

8. 목적별 추천 조합

프로젝트 성격에 따라 선택지가 달라집니다. 아래 세 가지가 가장 현실적인 출발점입니다.

제품 UI / 앱 문자열

JSON, PO, ARB, i18next 파일처럼 구조가 중요한 경우.

추천JTAcli-localize

구성: JTA 또는 cli-localize → glossary/TM RAG → translation-agent식 reflection → COMET/LLM judge → human review → es-hangul 후처리.

전문 번역가/CAT 환경

이미 Trados, memoQ, Phrase, CafeTran 같은 워크플로우가 있는 경우.

추천SupervertalerCAT

구성: Supervertaler Workbench → 기존 TM/glossary 재사용 → LLM 초벌/대안/검수 → CAT tool에서 human post-edit.

문서 / 블로그 / 리서치

문단/섹션 맥락과 문체가 중요한 긴 텍스트.

추천Aphratranslation-agent

구성: 문서 chunking → glossary 자동 추출 → contextual search → translate → critique → refine → editor review.

최종 결론

“전문 번역용 라이브러리”는 있습니다. 다만 하나의 npm package처럼 끝나는 문제가 아니라, TM + glossary + LLM agent + QE + human review를 연결하는 localization engineering 문제입니다. 지금 바로 실험한다면 Andrew Ng translation-agent로 reflection loop를 이해하고, 제품 문자열이면 JTA/cli-localize, 전문 CAT workflow면 Supervertaler부터 보는 것이 가장 빠릅니다.