실무에서 AI 번역을 쓰다 보면 한 가지 분명한 사실을 깨닫게 돼요. 도구를 어떻게 세팅하느냐에 따라 결과물의 퀄리티가 완전히 달라진다는 것. 단순히 DeepL이냐 ChatGPT냐를 고르는 문제가 아니라, 같은 도구라도 어떤 컨텍스트를 주고 어떤 방식으로 요청하느냐에 따라 프로 번역가 수준이 나오기도 하고, 어색한 기계 번역이 나오기도 하더라고요.
저는 기획서, 기술 문서, UX 카피, 외부 발표자료까지 거의 모든 번역 업무를 AI로 처리하고 있어요. 그 과정에서 쌓인 워크플로우와 실수 포인트를 오늘 정리해 보려 합니다.
도구별 특성 먼저 파악하기: DeepL, ChatGPT, Claude는 서로 다른 도구다
AI 번역 도구를 크게 나눠보면 전용 번역 엔진과 LLM 기반 번역으로 구분돼요. 각각 잘하는 영역이 다르기 때문에 무작정 한 가지만 쓰는 건 비효율적입니다.
DeepL은 여전히 문장 단위의 자연스러운 번역에서 강점을 가져요. 특히 유럽어 ↔ 영어 조합에서는 타의 추종을 불허하고, 한영·영한도 준수한 편이에요. 빠르고 API 연동이 쉬워서 대량 문서 처리에 적합합니다. 다만 컨텍스트를 길게 이어가는 능력은 LLM에 비해 약해요. 긴 문서에서 앞 단락의 맥락을 뒤에서 일관되게 유지하는 게 쉽지 않거든요.
ChatGPT(GPT-4o)와 Claude는 반대예요. 문서 전체를 한 번에 넣고 “이 문서의 말투와 용어를 일관성 있게 유지해서 번역해줘”라고 하면 놀라울 정도로 잘 따릅니다. 특히 브랜드 가이드라인이 있거나, 특정 산업 용어를 통일해야 하는 경우에 LLM이 훨씬 유리해요. Claude는 긴 문서 처리에서 GPT-4o보다 맥락 유지가 안정적이라는 걸 실무에서 체감하고 있어요. 200K 컨텍스트 윈도우 덕분이기도 하고, 지시사항을 끝까지 잘 따르는 성격 때문이기도 한 것 같고요.
정리하자면 저는 이렇게 씁니다. 빠른 초벌 번역이 필요하거나 대량 배치 처리라면 DeepL API, 문서 전체의 일관성·톤앤매너·도메인 용어가 중요하다면 Claude나 GPT-4o에 시스템 프롬프트를 세팅해서 처리해요.
실무에서 바로 쓰는 번역 프롬프트 설계법
LLM으로 번역할 때 가장 흔한 실수가 “그냥 번역해줘”만 던지는 거예요. 이렇게 하면 LLM은 자기가 판단하는 가장 일반적인 번역 스타일을 선택해버리는데, 그게 내 문서에 맞는다는 보장이 없죠.
좋은 번역 프롬프트에는 네 가지 요소가 들어가야 해요.
- 역할 정의: “당신은 B2B SaaS 스타트업의 영문 마케팅 카피를 전문으로 하는 번역가입니다.”처럼 도메인과 용도를 명확히 설정
- 타깃 독자: “독자는 미국 시장의 IT 구매 담당자(40대 임원)입니다.”처럼 번역문을 읽을 사람을 특정
- 톤 가이드라인: “격식체, 전문적이지만 친근한 어조. 과장된 마케팅 문구는 피하고 신뢰감을 주는 표현 사용.”
- 용어 사전(glossary): “다음 용어는 반드시 아래와 같이 번역하세요: 워크스페이스 → Workspace (번역하지 않음), 알림 → Notification”
이 네 가지를 시스템 프롬프트에 한 번 세팅해두면, 이후 번역 요청은 원문만 넣어도 일관된 결과가 나와요. 특히 팀에서 공동으로 쓰는 경우라면 이 프롬프트 자체를 노션이나 컨플루언스에 문서화해두는 걸 추천해요. 누가 번역하든 동일한 기준이 적용되니까요.
한 가지 더. 번역 후 후처리 검수 프롬프트를 따로 두는 것도 효과적이에요. “위 번역문에서 어색하거나 직역 투가 남아있는 부분, 그리고 원문 의미와 달라진 부분을 찾아서 표로 정리해줘”라고 하면 LLM이 스스로 번역을 리뷰해주는 셈이 됩니다. 완벽하진 않지만, 사람이 처음부터 전체를 검수하는 것보다 훨씬 빠르게 문제 구간을 좁힐 수 있어요.
기술 문서·코드 주석 번역에서 주의할 점
개발자나 테크니컬 라이터가 가장 자주 씨름하는 게 기술 문서 번역이에요. 일반 문서와 달리 신경 써야 할 부분이 따로 있습니다.
첫째, 번역하면 안 되는 영역을 명시해야 해요. 코드 스니펫, 변수명, API 엔드포인트, CLI 명령어는 절대 번역하면 안 되는데, LLM은 지시가 없으면 이걸 한국어로 바꿔버릴 때가 있어요. “코드 블록 내부, 백틱으로 감싼 인라인 코드, 대괄호·꺽쇠로 된 파라미터명은 번역하지 말고 원문 그대로 유지해줘”라고 명시적으로 적어야 합니다.
둘째, 기술 용어의 한영 일관성이에요. ‘배포’를 deployment로 쓸 건지 release로 쓸 건지, ‘엔드포인트’를 그냥 영어로 둘 건지 한글화할 건지. 이런 결정을 번역 초반에 glossary로 정리해놓지 않으면 문서 전체에서 용어가 제각각이 돼요. 이 작업 자체도 LLM에게 맡길 수 있어요. 원본 문서를 먼저 넣고 “이 문서에 등장하는 기술 용어 목록을 추출하고, 한국어 번역 제안을 함께 표로 정리해줘”라고 하면 꽤 쓸만한 초안이 나옵니다.
셋째, 마크다운·HTML 구조 보존 문제예요. 문서를 통째로 붙여넣으면 헤더, 볼드, 링크 같은 마크업이 깨지거나 엉뚱하게 붙는 경우가 있어요. “마크다운 문법은 원본 그대로 유지하고 텍스트 내용만 번역해줘”라고 명시하면 대부분 해결되긴 하는데, 결과물은 꼭 확인해봐야 해요. 저는 중요한 문서라면 원문과 번역문을 diff 도구로 구조 비교하는 걸 습관으로 삼고 있습니다.
AI 번역 워크플로우를 시스템으로 만들기
번역 업무가 반복적으로 발생한다면, 매번 수동으로 복붙하는 방식을 벗어나야 해요. 몇 가지 자동화 접근법을 써보면서 효과적이었던 것들을 공유할게요.
DeepL API + 커스텀 글로서리 조합은 가장 세팅이 단순하면서도 효과가 확실해요. DeepL Pro API에는 글로서리 기능이 있어서 특정 단어 쌍을 등록해두면 번역 시 자동으로 적용돼요. 서비스나 제품명이 고정된 조직이라면 이것만 잘 세팅해도 품질이 눈에 띄게 올라갑니다.
n8n이나 Make(구 Integromat) 같은 자동화 툴과 LLM API를 연결하면 더 정교한 파이프라인을 만들 수 있어요. 예를 들어 구글 드라이브에 원문 파일이 올라오면 자동으로 번역을 트리거하고, 결과물을 지정된 폴더에 저장하는 식이죠. 여기에 앞서 얘기한 시스템 프롬프트를 API 호출에 고정해두면, 운영 중에 누가 번역을 돌리든 동일한 품질 기준이 유지됩니다.
번역된 결과를 사람이 최종 검토하는 구간은 없애면 안 돼요. 특히 법적 문서, 외부 공개 마케팅 문구, 기술 사양서처럼 오류가 실제 비즈니스 리스크로 이어지는 경우엔 더욱 그렇습니다. AI 번역이 아무리 좋아져도 지금 시점에서는 “초고를 AI가 만들고, 최종 판단은 사람이 한다”는 구조를 유지하는 게 현실적으로 안전해요.
AI 번역을 잘 쓴다는 건 결국 도구의 특성을 이해하고, 내 업무 맥락에 맞는 프롬프트와 파이프라인을 만들어두는 일이에요. 처음 세팅하는 데 시간이 좀 걸리더라도, 한 번 잡아두면 그다음부터는 번역에 쓰는 시간이 눈에 띄게 줄어드는 걸 느낄 수 있을 거예요. 저는 이미 꽤 오래 전에 그 전환점을 넘어온 것 같고요.