번역회사 용어집 관리와 초벌·교정 흐름을 Claude Code로 정리하는 법

금요일 저녁, 납품을 끝낸 매뉴얼 번역에 클레임이 들어왔습니다. “제품명 표기, 지난 호하고 다르잖아요.”

확인해 보니 정말 다릅니다. 지난번에는 “고객 계정”, 이번에는 “사용자 계정”. 용어집에는 “고객 계정”이라고 적혀 있었는데, 마감에 쫓겨 급하게 돌린 번역가가 거기를 놓쳤고, 교정자도 놓쳤습니다. 제가 3년 동안 일해 온 번역회사 현장에서 가장 흔한 재작업이 바로 이겁니다.

누가 잘못했다는 얘기가 아닙니다. 용어집은 엑셀로 200줄. 안건마다 조금씩 늘어납니다. 번역가는 마감에 쫓기고, 교정자는 전문을 눈으로 좇습니다. 사람의 주의력만으로 표기 흔들림을 전부 막는 건, 이제 무리입니다.

그래서 저는 Claude Code에 “용어 점검의 1차 필터” 역할을 맡겨 봤습니다. 판단은 사람이 그대로 쥐고, 기계로 알 수 있는 실수만 먼저 걸러낸다. 이게 생각보다 잘 들어맞아서, 번역회사 코디네이터의 시선으로 절차를 정리합니다.

핵심 요약

표기 흔들림이나 역어 불일치는 “기계로 알 수 있는 실수”가 많아, Claude Code의 1차 점검으로 대부분을 잡아낼 수 있다
용어집은 엑셀 그대로 쓰지 말고, CSV나 텍스트로 만들어 “규칙 목록”으로 AI에 건네면 정확도가 올라간다
초벌·교정 흐름은 “AI가 잡는다 / 사람이 정한다”를 나누면 재작업이 줄어든다
고객의 원문이나 용어집에는 고유명사·미공개 정보가 들어 있으므로, 전송 범위 관리가 필수다
안건 1건당 교정 전처리에서 30~~60분, 월 10건을 돌리면 수 시간~~십수 시간이 절약되는 계산이 된다

번역회사 현장에서 무슨 일이 벌어지는가

먼저 독자상을 맞춰 둡니다. 이 글이 상정하는 독자는, 번역회사에서 안건을 돌리는 코디네이터입니다. 스스로 전문을 번역하기보다, 번역가와 교정자 사이에 서서 용어집을 관리하고, 납기와 품질 사이에 끼이는 사람. 프로그래밍 경험은 거의 없거나, 있어도 매크로를 조금 만지는 정도.

번역회사의 흔한 업무 흐름은 대개 이렇습니다.

고객으로부터 원문과 과거 번역·용어집을 받는다
번역가에게 초벌 번역을 의뢰한다
교정자(체커)가 번역문을 점검한다
코디네이터가 최종 확인하고 납품한다

이 흐름의 어디에서 재작업이 생기는가. 경험상 대부분이 2와 3 사이입니다.

용어집에 있는 역어를 번역가가 쓰지 않았다(표기 흔들림)
숫자나 단위가 원문과 어긋났다(“3.5kg”가 “3.5g”가 되는 등)
번역 누락(원문의 한 문장이 번역문에 없다)
띄어쓰기나 괄호 종류가 안건 규칙과 다르다

전부 “읽으면 알아챌 법한” 실수입니다. 하지만 전문을 사람 눈으로 좇으면, 긴 안건일수록 놓칩니다. 교정자가 놓친 것은 코디네이터에게 돌아오고, 끝내는 납품 후 클레임이 됩니다. 이 “기계로 알 수 있을 실수를 사람이 찾는 시간”이, 번역회사의 숨은 비용입니다.

AI에 맡길 범위와, 사람이 반드시 판단하는 범위

여기를 먼저 분명히 하지 않으면 사고가 납니다. Claude Code는 똑똑하지만, 번역 품질의 최종 판단을 맡겨서는 안 됩니다. 선 긋기는 이렇습니다.

공정	Claude Code에 맡긴다	사람(교정자·코디네이터)이 판단한다
용어 점검	용어집과 번역문을 맞춰 보고, 불일치 부분을 목록화	그 불일치가 오류인지, 문맥상 예외인지
표기 흔들림	띄어쓰기·괄호·맞춤법 흔들림을 추출	고객 취향에 맞춘 최종 표기
숫자·단위	원문과 번역문의 수치 차이를 검출	단위 환산의 정오, 의미의 타당성
번역 누락	원문 문장 수와 번역문 문장 수의 어긋남을 보고	의도적인 통합·분할 여부
번역의 질	(맡기지 않음. 초벌 보조까지)	자연스러움·톤·오역의 최종 판단

핵심은, AI에 “정답을 정하게 하지 않는” 것입니다. AI가 하는 일은 “여기 수상합니다”라고 포스트잇을 붙이는 데까지. 떼느냐 남기느냐는 사람이 정합니다. 이 역할 분담을 무너뜨리면, AI의 오판정을 그대로 납품하는 사고가 생깁니다.

맡길 범위를 어떻게 쓸지 헷갈리면, claude-code-prompt-engineering-advanced의 프롬프트 설계가 참고가 됩니다. 지시를 모호하게 하면 AI는 멋대로 “고쳐” 버리므로, 출력 형식까지 지정하는 것이 요령입니다.

Use case 1: 용어집과의 대조

가장 효과가 큰 게 이겁니다. 용어집과 번역문을 건네고, 불일치만 표로 돌려받습니다.

먼저 용어집을 엑셀에서 CSV로 만듭니다. AI에 엑셀을 그대로 건네기보다, “원어, 역어, 비고” 3열의 텍스트로 만드는 편이 규칙으로 읽어 내기 쉽습니다. 사전 준비 프롬프트는 이렇습니다.

당신은 번역회사의 교정 어시스턴트입니다.
아래 용어집에 따라, 번역문의 용어 불일치만 지적하세요.

# 규칙
- 용어집의 "역어"가 쓰이지 않은 부분만 보고한다
- 문맥상 바꿔 쓴 표현인지 여부는 판단하지 말고, 기계적인 불일치를 전부 든다
- 고치지 않는다. 지적만 한다
- 출력은 표 형식: | 행 번호 | 원어 | 마땅한 역어 | 실제 역어 |

# 용어집(원어, 역어, 비고)
顧客アカウント, 고객 계정, 전 안건 공통
サインイン, 로그인, 이 고객은 "로그인" 표기로 통일
delete, 삭제, "소거"는 불가

# 번역문
(여기에 번역문을 붙여 넣는다)

돌아오는 것은 “수정안”이 아니라 “불일치 목록”입니다. 교정자는 그 표를 위에서부터 보고, 고칠지 말지만 정합니다. 전문을 다시 읽는 것보다 압도적으로 빠릅니다.

도입 전에는, 교정자가 엑셀 용어집을 다른 창에서 열어 둔 채 번역문을 눈으로 대조했습니다. 도입 후에는, AI가 붙인 포스트잇을 확인하는 작업으로 바뀌었다. 같은 “확인”이라도, 처음부터 찾는 것과 후보를 보고 판단하는 것은 부담이 전혀 다릅니다.

Use case 2: 초벌 번역 전처리 체크리스트

번역가에게 건네기 전, 또는 초벌이 올라온 직후에, 기계 점검을 한 번 거칩니다. 점검 항목은 이 목록을 그대로 쓰세요.

용어집의 역어가 모든 부분에서 쓰였는가
원문과 번역문에서 숫자·단위가 일치하는가
번역 누락(원문에 있고 번역문에 없는 문장)이 없는가
띄어쓰기, 괄호 종류가 안건 규칙대로인가
제품명·인명·고유명사 표기가 과거 번역과 맞춰져 있는가
금지 표현(고객이 싫어하는 말투)이 섞여 있지 않은가

이 점검을 초벌 단계에서 하면, 교정자에게 넘어가기 전에 실수가 줄어듭니다. 교정자는 “기계로 잡을 수 있는 부분은 끝났다”는 전제로, 번역의 자연스러움이나 오역 같은 사람만이 할 수 있는 판단에 집중할 수 있습니다.

초벌 자체를 AI에 돕게 하는 경우에도, 곧바로 전문을 맡기지 말고 “과거 번역과 용어집을 반영한 초벌의 밑그림”까지로 그칩니다. 최종 번역은 사람이 마무리합니다. AI를 막 쓰기 시작한 팀이라면, claude-code-for-non-engineers를 먼저 읽으면 어디까지 맡길지 감을 잡을 수 있습니다.

Use case 3: 표기 흔들림 정기 점검

안건이 오래 이어지면, 용어집 자체가 낡습니다. “전에는 ‘삭제’였는데, 이번 기부터 ‘소거’로 해도 된다”는 식의 변경이 구두로 흐르고, 용어집에 반영되지 않은 채 현장이 혼란스러워집니다.

그래서 월 1회, 과거 납품물을 한데 모아 AI에 읽혀, “같은 개념에 여러 역어가 붙은 부분”을 가려냅니다. 이걸로 용어집 관리 누락이 발견됩니다. 프로젝트의 공통 규칙을 파일에 정리해 두면 AI가 매번 그것을 참조하므로, claude-md-best-practices의 방식으로 안건마다의 규약을 한 파일에 모아 두면 운용이 편해집니다.

복붙해서 쓰는 프롬프트 템플릿

교정 1차 점검에 쓰는, 범용 템플릿을 둡니다. 안건명과 용어집만 갈아 끼우면 쓸 수 있습니다.

# 역할
번역회사의 교정 1차 점검 담당으로서, 기계적으로 검출 가능한 실수만 보고한다.

# 입력
- 용어집(원어, 역어)
- 원문
- 번역문

# 할 일(이 순서로)
1. 용어 불일치를 추출
2. 숫자·단위의 원문과의 차이를 추출
3. 번역 누락(원문 문장 수 > 번역문 문장 수)의 의심을 보고
4. 띄어쓰기·괄호 흔들림을 추출

# 하지 않을 일
- 번역문을 다시 쓰지 않는다
- 번역의 좋고 나쁨을 평가하지 않는다
- 예외 판단을 하지 않는다(판단은 사람이 한다)

# 출력 포맷
## 용어 불일치
| 해당 부분 | 마땅한 역어 | 실제 |
## 숫자·단위
| 원문 | 번역문 | 차이 |
## 번역 누락 의심
- (부분)
## 표기 흔들림
- (부분)
문제가 없으면 각 섹션에 "지적 없음"이라고 쓴다.

실행 가능한 검증 스크립트: 숫자 불일치를 기계로 잡기

AI에 건네기 전에, 확실히 기계로 알 수 있는 “숫자 어긋남”만 먼저 걸러 두면, AI에 대한 의존도가 낮아져 안전합니다. Node.js로 동작하는 작은 스크립트를 준비했습니다. 원문과 번역문을 텍스트로 건네면, 한쪽에만 있는 숫자를 목록으로 내줍니다.

import { readFile } from "node:fs/promises";

// 원문·번역문 파일 경로를 명령 인자로 받는다
const [srcPath, tgtPath] = process.argv.slice(2);
if (!srcPath || !tgtPath) {
  console.error("사용법: node check-numbers.mjs 원문.txt 번역문.txt");
  process.exit(1);
}

const src = await readFile(srcPath, "utf8");
const tgt = await readFile(tgtPath, "utf8");

// 숫자(소수·쉼표 구분 포함)를 전부 잡는다
const pick = (text) => (text.match(/\d[\d,.]*/g) || []).map((n) => n.replace(/,/g, ""));

const srcNums = pick(src);
const tgtNums = pick(tgt);

// 한쪽에만 있는 숫자를 차이로 낸다
const diff = (a, b) => a.filter((n) => !b.includes(n));

const onlyInSrc = diff(srcNums, tgtNums);
const onlyInTgt = diff(tgtNums, srcNums);

console.log("원문에만 있는 숫자:", onlyInSrc.length ? onlyInSrc.join(", ") : "없음");
console.log("번역문에만 있는 숫자:", onlyInTgt.length ? onlyInTgt.join(", ") : "없음");

if (onlyInSrc.length || onlyInTgt.length) {
  console.log("→ 숫자 어긋남이 의심됩니다. 해당 부분을 확인하세요.");
  process.exit(2);
}
console.log("→ 숫자는 일치합니다.");

저장해서 실행하기만 하면 됩니다.

node check-numbers.mjs source.txt target.txt

완벽한 검출은 아닙니다. 어순이 바뀌면 오검출도 나옵니다. 하지만 “3.5가 번역문에서 사라졌다” 같은 치명적 어긋남은, 눈으로 보는 것보다 빠르고 확실하게 찾아냅니다. AI의 판단에 기대기 전에, 이런 확정적인 점검을 먼저 두는 것이 요령입니다. Claude Code 도입이 처음이라면, claude-code-getting-started-guide의 절차로 환경을 갖춘 뒤에 시험해 보세요.

보안과 개인정보 주의점

번역회사에 이곳은 사활이 걸린 문제입니다. 원문에는 미공개 제품 정보, 계약서, 개인 이름이 들어 있습니다. 다루기를 그르치면, 효율화는커녕 신뢰를 잃습니다.

고객과의 비밀유지계약(NDA)에서, 외부 AI 서비스로의 데이터 전송이 허용되는지 반드시 확인한다
허가가 없는 안건은, 고유명사나 수치를 더미로 바꾼 뒤에 점검에 건다
개인정보(이름·주소·연락처)는 점검 전에 마스킹한다
전송한 데이터가 학습에 쓰이지 않는 설정·계약 형태를 고른다
안건마다 “AI 이용 가능/불가”를 관리표에 기록하고, 코디네이터 사이에서 공유한다

헷갈리면 “보내지 않는다”가 정답입니다. 용어집 대조는, 고유명사를 가려도 표기 규칙 점검으로서 충분히 작동합니다. 개인정보 취급에 불안이 있으면, 개인정보보호위원회의 가이드라인으로 자사의 운용이 벗어나지 않았는지 확인해 두면 안심입니다.

ROI의 기준

대략적인 어림이지만, 감각을 공유합니다. 중규모 매뉴얼 번역 1건(원문 1만 자 정도)의 교정에서, 용어 대조와 숫자 점검의 전처리에 사람이 쓰는 시간은, 지금까지 30~60분이었습니다.

1차 필터를 AI와 검증 스크립트에 맡기면, 그 전처리가 10분 전후로 줄어듭니다. 차감하면 20~50분 단축. 월 10건을 돌리는 번역회사라면, 월당 수 시간에서 십수 시간이 절약되는 계산입니다.

절약된 시간으로, 교정자는 오역이나 톤 같은 사람만이 할 수 있는 판단으로 돌아갈 수 있습니다. 단순한 시간 단축이 아니라, 품질의 최종 선에 사람 손을 모을 수 있는 것이 큽니다. 도입 효과를 더 끌어올리는 작은 습관은 claude-code-productivity-tips에 정리해 두었습니다.

자주 묻는 질문

Q. AI에 번역문을 직접 수정하게 하면 안 되나요. 권하지 않습니다. 수정까지 맡기면, AI의 오판정이 그대로 번역문에 끼어들어 오히려 교정이 늘어납니다. AI는 “지적만”, 수정은 사람이 하는 분담을 지키세요.

Q. 용어집이 500줄을 넘습니다. 전부 건넬 수 있나요. 안건과 관련된 범위로 좁혀 건네는 것이 현실적입니다. 전부 건네면 정확도가 떨어집니다. 안건 장르마다 용어집을 나눠 두면 운용하기 쉬워집니다.

Q. 기계 번역 엔진과 무엇이 다른가요. 역할이 다릅니다. 기계 번역은 번역문을 생성하는 것, 여기서 소개한 것은 생성된 번역문을 점검하는 1차 필터입니다. 둘을 조합하면, 생성과 점검의 양 끝을 커버할 수 있습니다.

Q. 교정자의 일이 없어지지 않나요. 반대입니다. 기계로 알 수 있는 실수 찾기에서 해방되어, 오역이나 뉘앙스 같은 사람만이 할 수 있는 판단에 집중할 수 있습니다. 가치 높은 공정에 시간을 모으는 이야기입니다.

Q. 회사로서 도입하고 싶은데, 어디서 시작하면 되나요. 안건 1건으로 시험하는 것이 안전합니다. 먼저 숫자 점검 검증 스크립트부터 넣고, 익숙해지면 용어 대조로 넓히세요. 팀 전체의 운용 설계가 필요하면, 연수·상담에서 구체적인 흐름까지 함께 짤 수 있습니다.

실제로 해 본 결과

수중의 모의 안건(제품 매뉴얼 일부, 원문 약 3000자)으로 실제로 돌렸습니다. 일부러 “고객 계정”을 세 군데 “사용자 계정”으로 바꾸고, 숫자를 하나 “3.5”에서 “35”로 바꿔 심어 두었습니다.

숫자 검증 스크립트는, 심어 둔 “35”를 단번에 “번역문에만 있는 숫자”로 잡았습니다. 용어 대조 프롬프트는, 세 군데 표기 흔들림을 전부 표로 내왔습니다. 한편으로, 문맥상 일부러 바꿔 쓴 한 군데도 “불일치”로 들고 왔기에, 여기는 사람이 “이건 예외”라고 판단해 남겼습니다.

확인하고 싶었던 것은, “AI가 포스트잇을 붙이고, 사람이 뗄지 정한다”는 분담이 실무에서 돌아가는가, 였습니다. 결론적으로, 기계가 잡은 후보를 사람이 확인하는 형태로 바꾸기만 해도, 처음부터 찾는 심리적 부담이 크게 줄어듭니다. 완벽한 자동화가 아니라, 사람의 최종 판단을 지키면서 전처리를 대신 짊어지게 한다. 번역회사 현장에는, 이 거리감이 딱 맞는 듯합니다.