Localizing Life

#3
 

처음 프리랜서 번역가 일을 시작했을 때, 내게 로컬라이제이션 업계란 번역가와 번역 회사로 이루어진 세계였다. 클라이언트가 번역 회사에 일을 맡기면, 번역 회사가 번역가에게 파일을 보내고, 번역가는 정해진 날짜까지 번역을 마쳐 돌려준다. 적어도 당시 내가 볼 수 있었던 범위에서는 대략 그런 구조였다.
 
물론 실제로 그보다 훨씬 많은 사람이 관여한다는 사실을 알게 되는 데에는 그리 오랜 시간이 걸리지 않았다. 프로젝트를 수주하는 사람, 작업자를 섭외하는 사람, 파일과 일정을 관리하는 사람, 번역을 검수하는 사람, 품질 기준을 만드는 사람, 실제 기기에서 제품을 테스트하는 사람까지. 하나의 번역 프로젝트가 시작되어 최종 납품되기까지, 번역가에게는 보이지 않는 곳에서도 여러 사람이 움직인다.
 
나 역시 처음에는 프리랜서 번역가로 업계에 발을 들였고, 이후 한국 번역 회사에서 풀타임 링귀스트로 일했다가, 게임 로컬라이제이션을 전문으로 하는 글로벌 LSP에서 퀄리티 매니저를 맡기도 했다. 같은 벤더 사이드에 있으면서도 자리와 회사의 규모가 바뀔 때마다 전혀 다른 풍경이 보인다.
 
로컬라이제이션 업계의 플레이어들을 살펴보는 첫 번째 글에서는 그중 벤더 사이드의 이야기를 해보려 한다. 여기서 말하는 벤더란 무엇이고, 그 안에서는 누가 무슨 일을 할까.
 

*
 

번역 회사보다 조금 넓은 이름, LSP

클라이언트의 의뢰를 받아 번역과 로컬라이제이션 서비스를 제공하는 회사를 흔히 벤더(Vendor)라고 부른다. 언어 서비스 제공업체(Language Service Provider), 줄여서 LSP라는 용어도 사용한다. 일상적인 표현으로는 번역 회사라고 해도 크게 틀리지 않는다. 다만 LSP가 제공하는 서비스는 텍스트를 한 언어에서 다른 언어로 옮기는 일보다 훨씬 넓다.
 
번역된 내용을 검수하고, 번역 메모리와 용어집을 관리하고, 문서의 레이아웃을 조정하고, 제품 안에서 번역이 제대로 표시되는지 테스트한다. 프로젝트에 따라 자막과 더빙, 통역, 트랜스크리에이션, 기계 번역 후편집(Machine Translation Post-Editing, MTPE), 다국어 콘텐츠 제작과 데이터 서비스 등도 제공한다.
 
LSP의 크기와 형태 또한 천차만별이다. 대표적인 글로벌 LSP로는 RWS, TransPerfect, Welocalize 등을 꼽을 수 있다. 이들은 단순 번역을 넘어 소프트웨어와 웹사이트 로컬라이제이션, 콘텐츠 제작, 테스팅, 통역과 번역 기술 등 폭넓은 서비스를 제공하며 매출이나 회사 규모도 상당한 수준이다. 게임 분야에서는 Keywords Studios가 대표적인 예다. 게임 텍스트 번역뿐 아니라 오디오 로컬라이제이션, 더빙과 LQA 등 게임 출시 과정에 필요한 여러 서비스를 함께 제공한다. 그 밖에도 미디어, 생명과학, 법률, 특허처럼 특정 산업에 강점을 둔 업체들이 있다.

글로벌 규모의 MLV, 지역 전문 SLV

통상 수십 개 이상의 언어를 통합하여 관리하는 업체는 MLV(Multi-Language Vendor), 특정 언어나 지역을 전문적으로 담당하는 업체는 SLV(Single-Language Vendor)라고 부른다. 
 
예를 들어 미국의 게임사가 신작을 20개 언어로 동시에 출시하려 한다고 해보자. 게임사가 20개 언어의 번역가와 리뷰어를 직접 찾고, 각각 계약하고, 파일과 질문, 일정과 비용을 따로 관리할 수도 있다. 하지만 프로젝트 규모가 커지고 콘텐츠가 계속 업데이트되면 이 구조를 유지하기가 쉽지 않다.
 
이때 MLV가 중간에서 여러 언어를 통합 관리한다. 클라이언트는 하나의 MLV에 콘텐츠를 전달하고, MLV는 언어별 팀을 구성해 번역과 검수, 품질 관리와 납품을 조율한다. MLV가 내부 링귀스트나 프리랜서에게 직접 작업을 맡기기도 하고, 특정 언어는 현지 SLV에 다시 의뢰하기도 한다.
 
SLV는 한 언어나 특정 지역 시장에 깊은 전문성을 가진다. 한국어 SLV라면 한국어 번역가와 리뷰어를 직접 관리하고, 한국 시장과 문화, 언어적 특성을 바탕으로 서비스를 제공한다. 클라이언트나 MLV가 한국어 번역을 의뢰하면, SLV가 실제 언어 작업과 품질을 책임지는 구조다.
MLV의 강점이 여러 언어를 일관된 프로세스로 운영하는 규모와 관리 능력이라면, SLV의 강점은 해당 언어와 시장에 대한 깊은 지식이라고 할 수 있다.
 
물론 실제 공급망은 항상 둘 중 하나로 깔끔하게 나뉘지는 않는다. 대형 MLV가 일부 언어에 대해 사내 팀을 운영하면서 다른 언어는 SLV에 맡길 수 있다. SLV가 자체 직원과 프리랜서를 함께 활용하기도 한다. 클라이언트가 주요 언어는 SLV와 직접 작업하고, 나머지 언어는 MLV를 통해 관리하는 경우도 있다. 클라이언트가 하나의 회사에 일을 맡겼다고 해서 모든 작업이 그 회사 안에서 이루어지는 것은 아니라는 뜻이다.

SLV의 링귀스트로 처음 본 세계

내가 처음 회사에 소속되어 일한 곳은 SLV였고, 그곳에서의 직책은 링귀스트(Linguist)였다.
 
링귀스트라는 이름은 회사마다 조금씩 다른 역할을 가리킨다. 직접 번역하는 사람이기도 하고, 다른 번역가가 작업한 내용을 리뷰하는 사람이기도 하다. 클라이언트의 용어와 스타일을 관리하고, 프리랜서 번역가의 질문에 답하거나 품질 피드백을 제공하기도 한다. 내가 있던 자리에서도 번역은 업무의 중요한 일부였지만 전부는 아니었다. 여러 번역가가 작업한 결과물을 검토하고, 프로젝트 전체에서 용어와 문체가 일관되게 유지되는지 살펴야 했다. 명확하지 않은 원문은 프로젝트 매니저를 통해 클라이언트에게 질문하고, 답변이 오면 기존 번역과 앞으로의 작업에 반영했다.
 
번역가로 일할 때는 주어진 파일과 내 번역에 집중했다면, SLV의 링귀스트가 된 뒤에는 한 언어의 결과물이 만들어지는 더 넓은 과정을 보게 되었다. 내가 고친 문장 하나가 다음 프로젝트의 기준이 될 수 있었다. 리뷰에서 반복적으로 발견되는 문제가 있다면 개별 문장을 고치는 데 그치지 않고, 용어집이나 스타일 가이드를 수정해야 했다. 번역가마다 다른 표현을 사용하고 있다면 어느 하나를 선택해 전체 팀에 공유할 기준을 만들어야 했다. 사람이 바뀌고 콘텐츠가 늘어나도 같은 기준을 유지할 수 있도록 만드는 체계가 함께 필요한 것이다.

문장을 만드는 사람, 번역가

사용자가 읽는 문장의 기초를 만드는 사람은 번역가다.
번역가는 원문의 의미를 다른 언어로 옮긴다. 그러나 의미만 틀리지 않게 옮긴다고 일이 끝나는 것은 아니다. 해당 제품의 사용자에게 자연스러운 표현인지, 기존에 사용한 용어와 일치하는지, 브랜드가 추구하는 말투와 어울리는지, 화면 안에 들어갈 만한 길이인지도 고려해야 한다.
 
다루는 콘텐츠에 따라 필요한 능력도 달라진다. 법률 문서는 정확성과 전문 용어가 무엇보다 중요하다. 마케팅 문구는 원문의 단어보다 의도와 인상을 살리는 일이 중요할 수 있다. 게임 대사는 캐릭터의 성격과 세계관을 이해해야 하고, 소프트웨어 문자열은 실제 기능과 화면상의 맥락을 알아야 제대로 번역할 수 있다.
 
번역 결과물만 보면 한 문장을 만드는 일이 짧아 보인다. 그러나 좋은 문장 뒤에는 언제나 보이지 않는 조사와 판단이 있다.

또 다른 눈으로 번역을 보는 사람, 리뷰어와 랭귀지 리드

대부분의 프로젝트에서는 번역가의 작업이 끝난 뒤 다른 언어 전문가가 번역을 검토한다. 이 역할은 리뷰어(Reviewer), 에디터 등의 이름으로 불린다. 리뷰어는 오역과 누락, 문법 오류를 확인한다. 용어집과 스타일 가이드가 제대로 적용됐는지, 여러 문장 사이에 일관성이 유지되는지도 살핀다. 여러 번역가가 하나의 프로젝트에 참여했다면 각자의 표현을 조정해 전체 결과물이 하나의 목소리로 읽히도록 만드는 역할도 한다.
 
규모가 큰 프로젝트에는 랭귀지 리드(Language Lead)나 리드 링귀스트(Lead Linguist)가 한 언어의 전반적인 품질을 책임지기도 한다. 이들은 개별 프로젝트의 리뷰뿐 아니라 반복적으로 발생하는 오류를 분석하고, 용어집과 스타일 가이드를 업데이트하며, 번역가에게 피드백을 제공한다. 클라이언트의 언어 담당자와 품질 기준을 논의하거나 새로운 번역가를 평가하기도 한다.

실제 제품 안에서 언어를 확인하는 사람, LQA 테스터

번역과 리뷰가 끝났다고 해서 로컬라이제이션이 끝나는 것은 아니다. 텍스트 파일에서는 올바르게 보이던 문장도 실제 제품 안에 들어가면 문제가 생길 수 있다. 문장이 버튼 밖으로 튀어나오거나 줄바꿈 때문에 의미가 어색해질 수 있다. 번역되지 않은 영어가 남아 있기도 하고, 올바르게 번역된 문장이 엉뚱한 화면에 표시되기도 한다.
 
이런 문제를 확인하는 것이 LQA(Localization Quality Assurance 또는 Linguistic Quality Assurance) 테스터다. 게임 LQA 테스터라면 실제 게임을 플레이하며 번역의 정확성과 자연스러움을 확인한다. 캐릭터의 성별이나 상황에 맞지 않는 표현, 화면에서 잘린 문장, 잘못된 자막 타이밍과 깨진 문자 등을 찾는다. 문제가 발견되면 스크린샷과 재현 방법, 발생 위치와 심각도를 버그 추적 시스템에 기록한다. 수정 사항이 적용된 뒤 문제가 제대로 해결됐는지 다시 확인하는 리테스트도 수행한다.
 
LQA는 번역 파일을 읽고 검수하는 리뷰와 다르다. 리뷰어가 주로 원문과 번역문을 비교하며 언어 품질을 확인한다면, LQA 테스터는 실제 제품과 사용자 경험 안에서 번역을 확인한다. 번역 자체는 맞지만 화면의 기능과 어울리지 않는 문제는 LQA 단계에서야 발견될 수 있다.
 
게임이나 앱을 특정 기기에서 직접 테스트하는 업무도 있다. PC뿐 아니라 콘솔, 스마트폰과 태블릿 등 여러 플랫폼에서 제품을 실행해 언어와 화면이 올바르게 표시되는지 확인한다. 언어별 설정, 지역별 스토어와 결제 환경, 기기의 화면 크기와 운영체제에 따라 서로 다른 문제가 나타날 수 있기 때문이다. 따라서 기술적 숙련도가 더 많이 요구된다.

품질을 문장 너머에서 보는 사람, 퀄리티 매니저

SLV에서 링귀스트로 몇 년 동안 일한 후, 나는 게이밍 로컬라이제이션을 전문으로 하는 MLV로 옮겨 퀄리티 매니저(Quality Manager)로 일했다. 한 언어의 개별 문장을 가까이에서 보던 자리에서 여러 언어와 프로젝트의 품질을 더 넓게 바라보는 자리로 이동한 셈이다.
 
퀄리티 매니저의 일도 회사와 프로젝트에 따라 다르지만, 기본적으로는 번역 품질을 일정한 기준으로 관리하고 개선하는 역할이다. 납품된 번역에서 어떤 오류가 발생했는지 분석하고, 그 문제가 한 번의 실수인지 프로세스상의 반복적인 문제인지 판단한다. 클라이언트의 피드백을 언어 팀에 전달하고, 필요한 경우 시정 조치와 품질 개선 계획을 만든다. 번역가와 리뷰어의 성과를 평가하거나 테스트를 통해 새로운 작업자를 선정하기도 한다.
 
품질을 측정하는 기준을 설계하는 일도 중요하다. 오역, 용어 오류, 문법, 스타일, 일관성 등 오류의 유형을 나누고 심각도를 판단한다. 같은 오류라도 게임 진행을 막는 잘못된 안내와 눈에 잘 띄지 않는 문장 부호 오류의 영향은 같지 않다. 숫자로 나타난 품질 점수만 볼 것이 아니라, 그 오류가 실제 사용자 경험에 어떤 영향을 주는지도 살펴야 한다. 즉, 품질 문제를 직접 고치는 사람이라기보다, 문제를 발견하고 원인을 분석해 같은 문제가 반복되지 않도록 구조를 만드는 사람에 가깝다.

번역이 가능한 환경을 준비하는 사람, 로컬라이제이션 엔지니어

로컬라이제이션 결과물에서 발견되는 문제가 항상 언어의 문제인 것은 아니다. 원본 파일이 잘못 구성되어 번역할 문장이 누락될 수도 있고, 시스템이 특정 문자를 제대로 처리하지 못할 수도 있다. 번역문에 포함된 태그가 손상되거나 파일을 다시 제품에 넣는 과정에서 오류가 발생하기도 한다.

로컬라이제이션 엔지니어(Localization Engineer)는 번역할 파일을 분석하고 작업 가능한 형태로 준비한다. 번역이 필요하지 않은 코드나 태그를 보호하고, 번역이 끝난 파일을 원래 형식으로 되돌린다.
 
번역 툴과 자동화 프로세스를 관리하고, 파일에서 발생한 기술적 오류를 해결하기도 한다. 반복 작업을 줄이는 스크립트나 툴을 만들고, 클라이언트의 콘텐츠 시스템과 번역 관리 시스템을 연결하는 업무를 맡을 수도 있다. 프로세스가 자동화될수록 엔지니어의 역할이 줄어들 것 같지만, 실제로는 자동화된 시스템을 설계하고 예외를 처리할 기술적 전문성이 더 중요해진다.

프로젝트의 교차로에 서 있는 사람, 프로젝트 매니저

벤더에서 클라이언트와 번역가 사이를 가장 활발하게 오가는 사람은 대개 프로젝트 매니저(Project Manager), 줄여서 PM이다. 클라이언트로부터 작업 요청을 받으면 PM은 먼저 프로젝트의 범위를 확인한다. 어떤 콘텐츠를 몇 개 언어로 번역해야 하는지, 마감은 언제인지, 어떤 툴과 작업 지침을 사용해야 하는지 살핀다. 파일에 문제가 없는지 확인하고, 언어별 작업자를 배정하고, 견적과 일정을 관리한다.
 
작업이 시작된 뒤에도 PM의 일은 계속된다. 번역가가 보낸 질문을 클라이언트에게 전달하고, 클라이언트의 답변을 다시 여러 언어 팀에 공유한다. 원문이나 일정이 변경되면 그 영향을 파악해 관계자들에게 알린다. 작업이 늦어지거나 예상치 못한 문제가 발생하면 대안을 찾아야 한다. 번역과 리뷰가 끝난 뒤에는 모든 파일이 빠짐없이 준비됐는지 확인하고 결과물을 납품한다.
 
한 PM이 여러 프로젝트를 동시에 관리하는 경우가 많다. 오전에는 앱 업데이트 번역을 보내고, 그사이 급하게 들어온 마케팅 문구의 견적을 준비하고, 오후에는 어제 납품한 문서에서 발견된 문제의 원인을 찾아야 할 수도 있다. 클라이언트는 일정이 중요하고, 번역가는 충분한 작업 시간이 필요하다. 리뷰어는 용어가 일관되지 않다고 말하고, 엔지니어는 파일 형식에 문제가 있다고 한다. 서로 다른 요구가 PM에게 모인다. 그래서 벤더 PM의 역할은 단순히 파일을 전달하고 회수하는 것이 아니다. 여러 사람에게 흩어진 정보와 일정을 연결해 프로젝트가 멈추지 않도록 하는 일에 가깝다. 외국어를 잘하는 것만큼이나 커뮤니케이션과 문제 해결 능력이 중요한 이유다.

프로젝트보다 큰 단위를 관리하는 사람들

프로젝트가 커지면 일상적인 작업을 관리하는 PM 외에 더 넓은 범위를 책임지는 역할이 필요해진다. 프로그램 매니저(Program Manager)나 프로덕션 매니저(Production Manager)는 하나의 요청이 아니라 특정 클라이언트의 여러 프로젝트 또는 전체 로컬라이제이션 프로그램을 관리한다.
 
여러 PM과 언어 팀의 업무량을 조정하고, 장기적인 일정과 인력 계획을 세운다. 비용과 생산성, 납기와 품질 지표를 살피고 반복되는 문제를 개선한다. 새로운 프로세스나 툴을 도입하고, 클라이언트와 정기적으로 운영 성과를 검토하기도 한다. PM이 오늘 들어온 프로젝트를 무사히 납품하는 데 집중한다면, 프로그램 매니저는 앞으로도 그 프로그램을 안정적으로 운영할 수 있는 구조인지 살피는 쪽에 가깝다.
 
규모가 큰 벤더에는 여러 프로그램이나 지역 조직을 총괄하는 오퍼레이션 매니저, 포트폴리오 매니저 또는 디렉터급 역할도 존재한다. 직책의 이름과 업무 범위는 회사마다 다르지만, 올라갈수록 개별 파일보다 사람과 조직, 예산과 장기 전략을 다루는 비중이 커진다.

사람과 프로젝트를 연결하는 사람, 벤더 매니저

여러 언어와 프로젝트를 운영하려면 적절한 작업자를 미리 찾고 관리해야 한다. 이를 담당하는 역할이 벤더 매니저(Vendor Manager), 리소스 매니저(Resource Manager) 또는 탤런트 매니저(Talent Manager)다. 여기서 벤더는 LSP 전체를 의미할 때도 있지만, 회사가 업무를 맡기는 프리랜서와 외부 업체를 가리키기도 한다.
 
벤더 매니저는 프로젝트에 필요한 언어와 분야의 번역가, 리뷰어와 테스터를 찾는다. 이력과 경력을 검토하고 테스트를 진행하며, 단가와 계약 조건을 협의한다. 작업을 시작한 뒤에는 성과와 가용 인력을 관리한다. 특정 언어에 일이 갑자기 늘어날 가능성이 있다면 미리 작업자를 확보하고, 품질이나 납기 문제가 반복되는 작업자가 있다면 개선 방안을 논의하거나 다른 인력을 찾아야 한다.
 
좋은 작업자를 찾는 것만큼 그들이 계속 안정적으로 일할 수 있는 환경을 만드는 것도 중요하다. 무리한 일정과 낮은 단가, 불명확한 피드백이 반복되면 경험 많은 언어 전문가를 유지하기 어렵다. 벤더 매니지먼트는 명단에 이름을 많이 등록하는 일이 아니라, 프로젝트에 맞는 전문 인력을 장기적으로 구축하는 일이다.

클라이언트의 창구, 어카운트 매니저

벤더에는 프로젝트를 운영하는 사람만큼이나 클라이언트와의 관계를 관리하는 사람도 중요하다. 대표적인 역할이 어카운트 매니저(Account Manager)다.
 
PM이 이미 들어온 프로젝트를 일정에 맞춰 수행하는 데 집중한다면, 어카운트 매니저는 클라이언트와 더 장기적인 관계를 구축하고 비즈니스 요구를 이해하는 데 초점을 둔다. 클라이언트가 어떤 시장과 제품을 준비하고 있는지, 현재 로컬라이제이션 과정에서 무엇을 어려워하는지 파악한다. 그에 맞는 서비스와 운영 방식을 제안하고, 견적이나 계약 조건을 논의한다. 서비스 범위를 확대하거나 새로운 프로젝트를 수주하는 일도 담당한다.
 
규모가 큰 주요 고객에게는 여러 PM과 품질 담당자, 엔지니어가 하나의 팀처럼 배정될 수 있다. 어카운트 매니저는 클라이언트와 이 내부 팀을 연결하고, 문제가 커졌을 때 조정하거나 해결의 방향을 논의한다. 회사에 따라 클라이언트 서비스 매니저(Client Services Manager), 비즈니스 디벨롭먼트 매니저(Business Development Manager), 세일즈 매니저 등의 직책이 일부 비슷하거나 더 세분화된 업무를 맡는다.

벤더 사이드의 진로

로컬라이제이션 업계에 관심을 가진 사람이 가장 궁금해하는 것 중 하나는, 어떤 직업으로 시작해 어디로 성장할 수 있는가 하는 점일 것이다. 위에서 본 것처럼, 생각보다 진로는 다양하다. 
 
언어 중심의 커리어라면 프리랜서 번역가나 주니어 링귀스트로 시작해 리뷰어, 시니어 링귀스트, 랭귀지 리드 또는 랭귀지 매니저나 퀄리티 매니저로 성장할 수 있다.
 
프로젝트 운영에 관심이 있다면 프로젝트 코디네이터나 주니어 PM으로 시작해 프로젝트 매니저, 시니어 PM, 프로그램 또는 프로덕션 매니저, 오퍼레이션 매니저와 디렉터로 범위를 넓혀갈 수 있다.
 
클라이언트 관계와 비즈니스에 강점이 있다면 PM 경험을 바탕으로 어카운트 매니저, 클라이언트 서비스 매니저나 비즈니스 디벨롭먼트 역할로 이동할 수 있다.
 
테스팅 분야에서는 LQA 테스터로 시작해 시니어 테스터, 테스트 리드, LQA 프로젝트 매니저나 테스트 매니저로 성장하는 경로가 있다.
 
기술에 관심이 있다면 로컬라이제이션 엔지니어, 자동화 엔지니어나 로컬라이제이션 솔루션 설계자로 전문성을 키울 수 있다.
 
한 트랙 안에서만 움직여야 하는 것도 아니다. 번역가가 PM이 되기도 하고, LQA 테스터가 퀄리티 매니저로 이동하기도 한다. PM이 어카운트 매니저나 벤더 매니저가 될 수도 있다. 벤더에서 경험을 쌓은 뒤 클라이언트의 로컬라이제이션팀으로 옮기는 경우도 흔하다.

나 역시 프리랜서 번역가에서 출발해 SLV의 링귀스트가 되었고, 이후 MLV의 퀄리티 매니저 자리를 거쳐 클라이언트 사이드로 옮긴 경우.  그러나 다음 자리로 이동할 때마다 이전 경험이 사라지는 것이 아니라 새로운 방식으로 쓰였다.
 
그래서 로컬라이제이션의 커리어를 직선보다 지도에 가깝다고 생각한다. 언어, 프로젝트 운영, 품질, 테스팅, 기술과 클라이언트 관리라는 여러 방향이 있고, 자신의 강점과 관심에 따라 다른 길로 이동할 수 있다. 두 개 이상의 영역을 이해하는 경험이 많은 경우에는 강점이 된다고 생각한다.

벤더에서 바라본 로컬라이제이션

벤더에서 가장 가까이 보이는 것은 납기와 품질, 그리고 그 사이에서 움직이는 사람들이다. 클라이언트가 정한 출시 일정은 쉽게 바뀌지 않지만, 실제 번역에 사용할 수 있는 시간은 원문의 확정이 늦어지면서 줄어들기도 한다. 작업량은 갑자기 늘고, 중요한 참고 자료가 뒤늦게 도착하기도 한다.
 
그럴 때 벤더는 주어진 조건 안에서 답을 찾아야 한다. 작업자를 추가할지, 우선순위를 나눌지, 일부 단계를 동시에 진행할지 판단한다. 시간이 부족해질수록 더 많은 사람을 투입하고 싶어지지만, 참여자가 늘어나면 일관성을 관리하기 어려워진다. 속도와 비용, 품질 가운데 어느 하나만 생각해서는 프로젝트를 운영할 수 없다.
 
번역가로 일할 때는 번역에 필요한 정보가 왜 처음부터 충분히 제공되지 않는지 궁금했다. 링귀스트가 된 뒤에는 나 역시 클라이언트의 답변을 기다리는 중인 경우가 많다는 사실을 알게 됐다.
 
퀄리티 매니저로 일하면서는 한 프로젝트에서 발생한 오류가 반드시 그 문장을 번역한 사람만의 문제는 아니라는 점을 더 자주 보게 되었다. 불분명한 원문, 오래된 용어집, 촉박한 일정, 적합하지 않은 작업자 배정, 여러 언어에 제대로 공유되지 않은 답변이 최종 오류로 나타날 수 있었다. 품질을 개선하려면 결과물만 고칠 것이 아니라 결과물이 만들어진 과정 전체를 살펴야 했다.
 
그래도 의문은 남았다. 클라이언트는 왜 원문이 확정되기도 전에 출시일을 정할까. 번역이 진행 중인데 왜 제품은 계속 바뀔까. 로컬라이제이션팀에서 결정을 내려주면 될 것 같은 질문에 왜 여러 부서의 확인이 필요할까.
 
그 답은 클라이언트 사이드로 자리를 옮긴 뒤에야 조금 더 선명하게 보이기 시작했다. 벤더에게 하나의 작업을 보내기 전, 클라이언트 안에서는 이미 여러 사람이 움직이고 있다. 그리고 로컬라이제이션팀 역시 그 복잡한 과정의 한가운데에 있다.
 
다음 글에서는 테이블의 반대편, 클라이언트 사이드의 플레이어들을 살펴보려 한다.
 
 
 
다음 이야기
→ [로컬라이제이션의 세계] #4 로컬라이제이션 업계의 플레이어들 - 클라이언트 사이드(Client Side)

기계번역(Machine Translation, MT) 엔진이라고 하면 흔히 구글 번역이나 한국에서는 네이버 파파고를 먼저 떠올리는 경우가 많은데, 대중적으로 덜 알려진 MT 업체 중 업계의 대표주자 중 하나로 자리매김한 서비스가 있다. 바로 DeepL이다. 개인이 외국어 문장을 번역할 때 사용하는 웹 번역기로의 명성은 상대적으로 약하더라도, API나 CAT 툴에 연결해 MT 엔진으로 활용하거나 기업의 다국어 콘텐츠를 처리하는 용도로는 업계에서 상당히 유명하다. 그렇다면 DeepL은 정확히 어떤 서비스이고, 다른 번역 서비스와는 무엇이 다를까?

독일에서 시작한 번역 AI 서비스

DeepL⁠은 2017년 독일 쾰른에서 시작한 회사다. 처음에는 번역 서비스를 중심으로 출발했지만, 지금은 스스로를 단순한 ‘번역 서비스 회사’보다 Language AI 기업으로 정의하고 있다. 현재 DeepL에 따르면 전 세계 20만 개 이상의 비즈니스 팀과 수백만 명의 개인 사용자가 서비스를 이용하고 있다고 한다. 

DeepL이 초창기에 이름을 알린 가장 큰 이유는 역시 기계번역의 자연스러움이었다. 지금이야 어떤 기계번역 서비스를 사용해도 품질이 상당하지만, 과거 기계번역을 조금이라도 많이 사용해 본 사람이라면 이런 경험이 있을 것이다. 문법적으로 틀린 문장은 아닌데, 사람이 실제로는 절대 이렇게 말하지 않을 것 같은 번역 말이다. DeepL은 특히 유럽 언어를 중심으로 자연스러운 번역 결과로 좋은 평가를 받으면서 빠르게 알려졌다. 이후 지원 언어와 기능을 계속 확대했고, 현재는 한국어와 일본어, 중국어는 물론 아랍어, 힌디어, 베트남어 등 훨씬 폭넓은 언어를 지원한다. 실제로 나도 지난 몇 년 사용 경험이 꽤 있는 편인데, 한국어와 일본어 번역 수준이 매우 인상적이다. 

그러다가 난립하는 NMT(신경망 기반 전통 MT) 사이에서도 차별화하고자 했는지 현재 DeepL은 번역 모델 자체도 LLM(Large Language Model) 인프라를 기반으로 한다. DeepL은 자체 LLM을 번역에 특화해 사용하고 있으며, 특히 긴 텍스트의 번역 품질 개선을 강조하고 있다. 그래서 이제는 흔히 생각하는 ‘전통적인 기계번역’과 ‘생성형 AI 번역’ 사이의 경계도 점점 흐려지고 있다.

DeepL의 차별점 

DeepL 웹사이트에 들어가 보면 사용법 자체는 매우 단순하다. 왼쪽에 원문을 입력하고 오른쪽에서 원하는 언어를 선택하면 된다. 이 점에서는 구글 번역이나 파파고와 크게 다르지 않다.

하지만 조금 더 살펴보면 로컬라이제이션 관점에서 흥미로운 기능들이 보인다. 대표적인 것이 문서 번역(Translate files)이다.

Word 문서나 PDF, PowerPoint 등의 파일을 업로드하면 문서의 원래 형식을 최대한 유지하면서 전체 문서를 번역할 수 있다. 단순히 텍스트를 복사해서 번역기에 붙여넣는 것보다 훨씬 편하다. 

그보다 더 눈여겨볼 기능은 용어집(Glossaries) 및 스타일 가이드(Style profiles/style rules)이다.

예를 들어 우리 회사의 제품에서 특정 기능의 이름은 번역하지 않고 영어 그대로 사용해야 한다고 하거나, '십시오'체가 아닌 '세요'체를 일관되게 사용해야 할 때, 일반적인 번역기에 문장을 넣으면 번역할 때마다 일관된 용어나 스타일을 사용한다는 보장이 없다. DeepL에서는 용어집과 스타일 가이드에 원하는 번역 결과에 반영할 수 있다. 단순한 검색·치환 방식이 아니라, LLM 기반으로 대상 언어의 문법에 맞게 용어를 적용한다는 것도 특징이다. 로컬라이제이션 실무에서 용어와 스타일의 일관성은 상당히 중요한 문제이기 때문에, 일상생활에 쓰이는 번역기와 전문적인 번역 워크플로의 차이가 보이는 지점이기도 하다.

또한 DeepL API를 트라도스 같은 CAT(Computer-Aided Translation) 툴이나 TMS(Translation Management System)에 연결하면 DeepL의 번역 결과를 그대로 사용하거나 검수 및 편집을 거쳐 사용할 수 있다. 즉, DeepL은 완성된 번역을 받아보는 서비스이기도 하지만, 전문적인 로컬라이제이션 환경에서는 번역 프로세스 안에 들어가는 하나의 MT 엔진이기도 하다. 여기에 한 발 더 나아가, 최근에는 별도의 CAT 툴이나 TMS를 거치지 않고도 번역 프로젝트를 관리할 수 있는 기능을 확장하며 간소화된 TMS에 가까운 플랫폼으로 진화하려는 움직임을 보이고 있다.

그럼 DeepL이 제일 좋은 MT 서비스일까?

DeepL이 자연스러운 번역으로 유명하다고 해서 모든 언어와 모든 콘텐츠에서 DeepL이 가장 좋은 결과를 낸다는 뜻은 당연히 아니다.

MT의 품질은 언어쌍에 따라 크게 달라질 수 있다. 같은 영어 원문이라도 독일어 번역에서 좋은 결과를 내는 엔진과 한국어 번역에서 좋은 결과를 내는 엔진이 반드시 같지는 않다.

콘텐츠의 성격도 중요하다. 제품 UI인지, 기술 매뉴얼인지, 마케팅 카피인지, 고객 지원 콘텐츠인지에 따라 요구되는 번역이 다르다. 특정 기업의 용어나 과거 번역 데이터를 얼마나 잘 활용할 수 있는지도 중요하고, 기업 환경이라면 데이터 보안과 API, 비용, 기존 TMS와의 연동 가능성까지 고려해야 한다.

그래서 실제 로컬라이제이션 업계에서는 단순히 어떤 엔진이 제일 좋다고 무조건 사용하기보다, 여러 MT 엔진으로 동일한 또 다양한 콘텐츠를 번역한 뒤 언어별 품질을 평가하는 MT 테스트/평가를 진행한다. 어떤 엔진이 가장 좋은지를 결정하는 것 역시 하나의 로컬라이제이션 작업인 셈이다.

*

#2
 

"무슨 일 하세요?"

처음 만난 사람들과 이야기를 하다 보면 꼳 듣게 되는 질문이다. 이제 나는 선택의 갈림길에 선다.
"로컬라이제이션 일을 합니다."
라고 답하면, 높은 확률로 잠시 정적이 흐른다.
"...그게 무슨 일이에요?"
그러면 나는 기꺼이, 어떤 사명감까지 가지고 주절대기 시작하는 것이다. 그게 번역이랑은 조금 다르고, 글로벌 제품을 여러 언어와 문화에 맞게 현지화하는 과정이고, 번역뿐 아니라 품질 관리와 프로세스, 기술적인 부분도 함께 다루고, 어쩌고 저쩌고... 
 
하지만 듣는 사람은 별 관심이 없고 말하는 사람은 피곤한 경우를 반복해서 경험하다 보면 그 사명감도 늘 버티진 못한다. 그래서 상황에 따라 대충 간략하게 설명하고 넘길 때도 있는데, 사실 가장 효과가 좋은 답은 따로 있다. 
"번역하는 일이라고 생각하시면 됩니다."
그리고 그 경우 내가 바라던 대로 대화는 거기서 끝난다. 사실은 거기서부터 시작인데도.
 

*

번역이 시작되기 전, 그리고 끝나고 난 자리

많은 사람들이 번역과 로컬라이제이션을 같은 의미로 사용한다. 사실 이상한 일도 아니다. 사용자 입장에서는 영어가 한국어로 바뀌어 있으면 ‘번역됐네’라고 생각하는 것이 자연스럽다. 하지만 두 개념은 엄밀히 다르다.
 
번역(Translation)은 텍스트를 한 언어에서 다른 언어로 옮기는 작업을 말한다. 반면 현지화/로컬라이제이션(Localization) 또는 l10n((l과 n 사이에 알파벳이 10개)은 제품이나 서비스를 특정 국가와 문화에 자연스럽게 맞추는 전체 과정이라 할 수 있다. 번역은 그 과정에서 중요한 단계 중 하나이지만, 전체는 아니다.
 
예를 들어 미국에서 만든 새로운 운동 앱을 전 세계 시장에 출시한다고 가정해 보자. 가능한 한 많은 언어를 지원하면 좋겠지만, 현실에서는 우선순위를 정해야 한다. 어떤 국가를 먼저 출시할지, 어떤 언어를 지원할지, 앱 전체를 현지화할지 아니면 마케팅 자료나 핵심 기능부터 번역할지 같은 결정은 시장 규모, 사용자 수, 비즈니스 전략 등을 바탕으로 이루어진다.
 
이와 함께 제품은 처음부터 여러 언어를 지원할 수 있도록 설계되어 있어야 한다. 영어 텍스트를 코드에 직접 입력하지 않고 분리해 관리하고, 날짜와 시간, 숫자, 통화, 주소 형식 등이 국가마다 달라질 수 있다는 점도 고려해야 한다. 이를 국제화(Internationalization), 줄여서 i18n(i와 n 사이에 알파벳이 18개)이라고 부른다.
 
그다음에야 실제 번역이 이루어진다. 하지만 번역이 끝나도 바로 출시하지는 않는다. 앱 화면에서 문장이 잘리지 않는지, 버튼이 깨지지는 않는지, 각 언어가 화면 안에서 자연스럽게 표시되는지, 날짜나 통화 표기가 해당 국가의 관습에 맞는지 등을 테스트하는 과정이 이어진다. 문제가 발견되면 다시 수정하고, 다시 테스트를 거친 뒤에야 사용자에게 제품이 전달된다.
 

 
위의 사이클은 간단히 구성한 로컬라이제이션의 단계인데, 기본적인 예시일 뿐 제품/서비스의 특성이나 기업마다 변주는 존재한다. 그럼 이제 자연스럽게 들게 되는 의문은, 이 모든 일을 누가 하느냐이다. 
 

 
물론 실제 사례는 이보다 훨씬 다양하다. 어떤 기업은 번역부터 QA까지 하나의 로컬라이제이션 벤더에 맡기기도 하고, 어떤 기업은 번역, 리뷰, 테스트를 각각 다른 업체에 맡기기도 한다. 또한 대규모 테크 기업은 번역을 제외한 상당수 과정을 내부 팀에서 직접 수행하기도 한다. 하지만 큰 틀에서는 클라이언트가 제품과 전략을 책임지고, 벤더가 언어와 품질을 지원하는 구조를 가장 흔하게 볼 수 있다.
 
나 역시 벤더와 클라이언트 양쪽에서 모두 일해 보며, 같은 '로컬라이제이션'이라는 단어 안에서도 역할과 관점이 얼마나 달라지는지 직접 경험할 수 있었다. 다음 글에서는 이 업계를 이루는 다양한 플레이어들과 각자의 역할을 더 자세히 살펴보려고 한다.
 

*

 
 
다음 이야기
→ [로컬라이제이션의 세계] #3 로컬라이제이션 업계의 플레이어들 - 벤더 사이드(Vendor Side)