Localizing Life

같은 영어 문장을 두 명의 번역가에게 맡겨보자.

[Ready to get started?]

한 사람은 이렇게 번역할 수 있다.

[시작할 준비가 되셨나요?]

다른 사람은 이렇게 번역할 수도 있다.

[그럼 시작해 볼까요?]

둘 다 틀린 번역은 아니다.

하지만 같은 제품 안에서 첫 번째 문장과 두 번째 문장이 뒤섞여 나온다면 이야기가 달라진다. 어떤 화면에서는 딱딱한 존댓말을 쓰고, 다른 화면에서는 친근하게 말을 건다. 버튼에는 ‘저장’이라고 쓰다가 비슷한 기능의 다른 버튼에서는 ‘저장하기’를 쓴다. 숫자와 단위 사이에는 공백을 넣었다가 빼고, 영문 제품명은 그대로 쓰다가 어느 순간 한글로 표기한다. 문장 하나하나만 보면 문제가 없는데, 제품 전체를 보면 어딘가 어수선하다.

이런 문제를 줄이기 위해 사용하는 대표적인 언어 자산이 스타일 가이드(Style Guide)다.

*

스타일 가이드 =  맞춤법 규정집?

스타일 가이드라고 하면 가장 먼저 문법이나 맞춤법 규칙을 떠올리기 쉽다. 물론 그런 내용도 들어간다. 문장 부호는 어떻게 사용할지, 숫자와 단위는 어떻게 표기할지, 날짜는 어떤 형식으로 쓸지, 영어 고유명사를 한글로 표기할지 원문 그대로 유지할지 등을 정할 수 있다. 하지만 좋은 로컬라이제이션 스타일 가이드의 역할은 그보다 훨씬 크다.

“우리 제품은 사용자에게 어떻게 말해야 하는가?”

이 질문에 대한 답을 정리한 문서에 가깝다.

예를 들어 같은 오류 메시지도 이렇게 달라질 수 있다.

[비밀번호가 올바르지 않습니다. 다시 입력하십시오.]

[비밀번호가 맞지 않아요. 다시 입력해 주세요.]

[비밀번호를 확인해 주세요.]

세 문장 모두 의미 전달에는 문제가 없다. 하지만 은행 앱과 어린이용 게임, 운동 앱이 똑같은 방식으로 사용자에게 말을 걸 필요는 없다.

어떤 브랜드는 정확하고 전문적인 목소리를 원하고, 어떤 브랜드는 친근하고 가벼운 목소리를 원한다. 같은 브랜드 안에서도 법률 고지와 마케팅 문구의 말투가 같을 필요는 없다. 스타일 가이드는 이런 수많은 언어적 선택에 기준을 만들어준다.

또한 언어에는 하나의 정답만 존재하는 경우보다 여러 표현이 모두 가능한 경우가 훨씬 많기에, 기준이 없다면 여러 번역시과 리뷰어가 함께 작업을 할 때 리뷰는 품질 관리가 아니라 서로의 언어 취향을 교정하는 과정이 되기 쉽다. 스타일 가이드는 이때 공통의 기준점이 된다. “누가 더 자연스럽다고 생각하는가?”가 아니라 “우리가 정한 스타일은 무엇인가?”를 묻게 만드는 것이다.

스타일 가이드의 주요 내용

스타일 가이드의 내용은 제품과 회사에 따라 크게 달라진다. 하지만 몇 가지 대표적인 영역이 있다.

1. Voice & Tone

가장 중요한 부분 중 하나다. 사용자에게 어떤 목소리로 말할 것인가? 예를 들어,

• 친근하지만 지나치게 가볍지 않게
• 전문적이지만 권위적으로 들리지 않게
• 간결하고 직접적인 문장 사용
• 사용자를 탓하는 표현 피하기
• 불필요한 과장 표현 피하기

같은 원칙을 정할 수 있다. 하지만 지침에 ‘친근하게 번역하세요’라고만 써놓으면 사람마다 생각하는 친근함이 다르기에 논쟁의 여지가 되기 십상이다. 그래서 실제 예시가 중요하다.

Avoid
잘못된 값을 입력하셨습니다.

Prefer
입력한 값을 확인해 주세요.

추상적인 설명보다 이런 예시 하나가 훨씬 효과적일 때가 많다.

2. 높임말과 문체

한국어에서는 특히 중요하다. ‘합니다’체를 사용할지, ‘해요’체를 사용할지부터 결정해야 한다.

UI에서는 "설정을 완료하십시오." 라고 하면서 마케팅에서는 "새로운 기능을 만나봐요!" 라고 할 수도 있다. 버튼이나 메뉴처럼 공간이 제한된 UI에서는 완전한 문장을 사용하지 않을 수도 있다. 영어에서는 크게 고민하지 않았던 문제가 한국어로 넘어오는 순간 중요한 스타일 결정이 되는 경우가 많다.

3. UI 요소 표기

버튼, 메뉴, 체크박스, 오류 메시지처럼 반복적으로 등장하는 UI 요소에도 기준이 필요하다. 예를 들어 영어의 Save를 '저장'과 '저장하기'

중 무엇으로 번역할까? Cancel은 ‘취소’와 ‘취소하기’ 중 어느 쪽을 쓰는 게 좋을까?

버튼에는 명사형을 사용한다는 식으로 규칙을 정할 수도 있다. 한두 문장에서는 사소해 보이지만 수천 개의 문자열이 쌓이면 이런 작은 차이가 제품 전체의 인상을 좌우한다.

4. 숫자, 날짜, 시간, 단위

10km / 10 km

오전 9:00 / 오전 9시

2026년 10월 24일 / 2026. 10. 24.

어떤 표기를 사용할까? 특히 여러 플랫폼에서 같은 데이터를 표시하거나 수치가 중요한 제품이라면 이런 규칙은 생각보다 중요하다.

5. 영어와 외래어 처리

Bluetooth를 ‘블루투스’라고 할 것인가, ‘Bluetooth’라고 할까? Wi-Fi는? GPS는? 제품명과 기능명은?

이미 한국 사용자에게 영어 표현이 더 익숙한데 굳이 번역하면 오히려 어색할 수도 있다. 반대로 영어를 지나치게 남겨두면 번역된 제품인데도 한국 사용자가 이해하기 어려워진다. 중요한 것은 무조건 번역하거나 무조건 원문을 유지하는 것이 아니라 일관된 기준을 만드는 것이다.

실제 스타일 가이드 예시

온라인에서 쉽게 무료로 접근할 수 있는 가장 대표적인 예가 Microsoft Localization Style Guides다.

Microsoft는 한국어를 포함한 다양한 언어의 로컬라이제이션 스타일 가이드를 공개하고 있다. 실제 기업이 각 언어의 로컬라이제이션에서 어떤 기준을 정의하는지 볼 수 있기 때문에 로컬라이제이션을 공부하는 사람이라면 한 번쯤 살펴볼 만하다. 특히 Korean Style Guide를 열어보면 한국어의 문체와 언어 사용, UI 관련 규칙 등을 어떻게 문서화하는지 참고할 수 있다.

Microsoft Localization Style Guides:

https://learn.microsoft.com/en-us/globalization/reference/microsoft-style-guides

함께 살펴볼 만한 자료로 Google Developer Documentation Style Guide도 있다.

Microsoft의 자료처럼 언어별 번역가를 위한 Localization Style Guide라기보다는 기술 문서를 위한 Writing Style Guide에 가깝지만, 명확한 문장과 용어, Voice & Tone, UI 표기 등을 어떻게 규칙으로 만드는지 참고하기 좋다. 특히 Google은 별도로 Write for a global audience라는 항목을 두고 번역과 로컬라이제이션을 고려해 원문을 작성하는 방법도 설명한다. 좋은 스타일 가이드는 번역가에게 ‘어떻게 번역할 것인가’를 알려주는 데서 끝나지 않는다. 애초에 번역하기 좋은 콘텐츠를 어떻게 만들 것인가에도 영향을 줄 수 있다.

Google Developer Documentation Style Guide:

https://developers.google.com/style

https://developers.google.com/style/translation

그런데 아무도 읽지 않는다면?

여기까지 읽으면 스타일 가이드는 자세할수록 좋을 것처럼 보일 수도 있다. 하지만 실제 로컬라이제이션 업계에서 일하면서 나는 그 반대의 경우도 많이 봤다. 상당히 잘 만들어진 스타일 가이드가 있는데도 실제 번역에서는 거의 사용되지 않는 경우다. 프로젝트 시작 때 번역가에게 수십 페이지짜리 PDF를 전달한다. 여러 참고 문서와 함께 링크도 보내준다. 그리고 작업은 시작된다. 시간이 지나면서 새로운 번역가가 투입되고, 벤더가 바뀌고, 리뷰어도 바뀐다. 제품에는 새로운 기능이 추가된다. 그런데 스타일 가이드는 몇 년 전 그대로다. 번역가들은 바쁜 일정 속에서 수십 페이지의 문서를 매번 찾아보지 않는다. 실제 번역에서 자주 발생하는 문제는 정작 가이드에 없고, 거의 발생하지 않는 예외적인 규칙이 몇 페이지에 걸쳐 설명되어 있기도 한다. 결국 스타일 가이드는 존재하지만 실제 의사 결정에는 사용되지 않는 유명무실한 문서가 된다. 그래서 스타일 가이드에서 중요한 것은 얼마나 많은 규칙을 담고 있는가가 아니라 얼마나 자주 실제 판단에 사용되는가라고 생각한다.

스타일 가이드의 규칙 역시 실제 프로젝트에서 발견되는 문제를 따라가야 한다. 리뷰에서 같은 문제가 계속 발견된다면 매번 번역가에게 똑같은 피드백을 보내는 대신 생각해 볼 수 있다. “이건 스타일 가이드에 넣어야 하지 않을까?” 반대로 몇 년 동안 아무도 참고하지 않는 규칙이라면 정말 필요한 내용인지 다시 검토할 수도 있다. 그렇게 스타일 가이드는 완성해서 보관하는 문서가 아니라 프로젝트와 함께 계속 다듬어지는 언어 자산이 된다.

AI 시대에 더 중요해지는 스타일 가이드

AI 이야기도 빼놓을 수 없다. 단순히 ‘AI에게 스타일 가이드를 프롬프트로 주면 번역을 잘한다’는 이야기를 하려는 것은 아니다.

더 흥미로운 변화는 스타일 가이드가 사람이 읽는 문서에서 시스템이 활용할 수 있는 언어 데이터로 변하고 있다는 점이다. 기존의 로컬라이제이션 자산을 생각해 보면, 번역 메모리(Translation Memory)는 과거에 어떻게 번역했는지를 보여준다. 용어집(Glossary)은 무엇을 무엇이라고 불러야 하는지를 알려준다. 그리고 스타일 가이드(Style Guide)는 어떻게 말해야 하는지를 알려준다.

LLM 기반 번역이나 리뷰에서는 이 세 가지를 함께 Context로 제공할 수 있다.

예를 들어 스타일 가이드에 다음과 같은 핵심 규칙이 있다고 해보자.

Tone: Friendly, encouraging, concise
Formality: 해요체
UI buttons: 명사형 사용
Product names: 번역하지 않음
Error messages: 사용자의 잘못을 직접적으로 지적하지 않음

이런 정보는 번역 생성뿐 아니라 AI 기반 QA에서도 사용할 수 있다. ‘합니다’체를 사용하지 않는 제품에서 "설정이 완료되었습니다."

라는 번역이 발견되면 스타일 위반 가능성을 표시할 수 있고, 버튼에는 명사형을 사용하기로 했는데 "저장하기"가 들어왔다면 검토 대상으로 올릴 수 있다. 기존의 자동 QA가 숫자 불일치, 태그 누락, 용어 오류처럼 비교적 명확한 오류를 찾는 데 강했다면, LLM을 활용하면 문체나 Voice & Tone처럼 기존에는 자동으로 검사하기 어려웠던 영역까지 범위를 넓힐 수 있다.

그런데 여기서도 결국 같은 문제가 돌아온다. 스타일 가이드 자체가 명확해야 한다는 것. 사람이 읽어도 무슨 뜻인지 애매한 규칙은 AI에게 전달한다고 갑자기 명확해지지 않는다. “자연스럽게 번역한다.” “브랜드에 맞는 친근한 어조를 사용한다.” 같은 추상적인 문장보다,

무엇을 하고 무엇을 하지 않는지, 실제 예시는 무엇인지 명확하게 정의된 규칙이 훨씬 활용도가 높다. AI를 제대로 활용하려면 인간이 먼저 원하는 언어를 더 정확하게 정의해야 하는 셈이다.

그래서 앞으로의 스타일 가이드는 단순히 번역가에게 보내는 PDF나 Word 문서만을 의미하지 않을 가능성이 크다. 사람이 읽기 쉬우면서 동시에 필요한 규칙을 시스템이 검색하고 AI의 Context로 전달할 수 있는 형태가 점점 중요해질 것이다. 이 관점에서 보면 앞서 이야기한 ‘짧고 명확하며 실제로 도움이 되는 스타일 가이드’의 중요성은 AI 시대에 오히려 더 커진다. 수십 페이지의 규칙을 만드는 것 자체가 목표가 아니다. 번역가가 고민하는 순간 필요한 답을 찾을 수 있고, 리뷰어가 판단의 근거로 사용할 수 있고, 필요하다면 AI도 같은 기준을 활용할 수 있어야 한다.

*

다음 이야기

→ [로컬라이제이션의 세계] #8 언어 자산 - 번역 메모리(Translation Memory)와 용어집(Glossary)

“지난번과 같은 표현으로 번역해 주세요.”

클라이언트가 새로운 번역 프로젝트를 요청하며 이렇게 말한다. 지난번 프로젝트에 참여했던 번역가가 다시 배정되었고, 이전 번역도 번역 메모리에 모두 저장되어 있다. 겉으로 보기에는 같은 품질과 스타일을 유지하기 어렵지 않아 보인다.

하지만 작업을 시작하자 같은 기능이 세 가지 이름으로 나타난다. 어떤 문장에서는 ‘활동’, 다른 문장에서는 ‘액티비티’, 또 다른 곳에서는 ‘운동’이라고 번역되어 있다. 기존 번역은 ‘합니다’체와 ‘해요’체가 섞여 있고, 몇 달 전에 바뀐 제품명이 번역 메모리에는 여전히 이전 이름으로 남아 있다. LSP는 어느 표현을 따라야 할지  문의하고, 클라이언트의 로컬라이제이션팀은 제품팀과 지역 마케팅팀에 다시 확인한다. 확인하는 사람마다 기억하는 결정이 조금씩 다르다. 결국 출시를 앞두고 리뷰어가 상당수의 문장을 다시 수정한다.

실무에서 어렵지 않게 볼 수 있는 장면이다. 이 경우 문제는 번역가가 이전 번역을 보지 않았다는 데 있지 않다. 회사가 그동안 내린 언어적 결정을 한 곳에 정리하고 관리하지 못했다는 데 있다.

*

번역 프로젝트 후 남는 것들

번역 프로젝트가 끝나면 번역된 문장만 남는 것이 아니다. 제품의 핵심 기능을 무엇이라고 부르기로 했는지, 사용자에게 어떤 어조로 말하기로 했는지, 반복되는 문장을 이전에는 어떻게 번역했는지, 특정 표현을 사용하지 않기로 한 이유도 함께 남는다.

이렇게 번역 과정에서 축적된 언어적 지식과 결정을 언어 자산(linguistic assets)이라고 한다. 대표적인 언어 자산에는 스타일 가이드(Style Guide), 용어집(Glossary), 번역 메모리(Translation Memory), 그리고 부가적으로 참고 자료(Reference material)와 질의 기록(Query) 등이 있다. 흔히 이들을 번역을 도와주는 참고 파일 정도로 생각하지만, 잘 관리된 언어 자산은 그보다 훨씬 큰 역할을 한다. 새로운 번역가와 벤더가 제품의 언어를 빠르게 이해하도록 돕고, 여러 프로젝트와 언어에 걸쳐 일관성을 유지하며, 이미 내린 결정을 매번 처음부터 논의하는 일을 줄인다. 무엇보다 언어 자산은 한 회사가 사용자에게 어떻게 말해왔는지를 기억한다.

스타일 가이드

"Download the app"은 다음과 같이 여러 방식으로 번역할 수 있다.

앱을 다운로드하십시오.
앱을 다운로드하세요.
앱을 받아보세요.

세 문장 모두 의미는 맞다. 그러나 한 제품 안에서 어떤 화면은 “다운로드하십시오”, 다른 화면은 “다운로드하세요”라고 말한다면 사용자는 미묘한 불일치를 느낀다. 어느 표현이 맞는지는 사전이나 번역가 개인의 선호만으로 결정할 수 없다. 금융 서비스처럼 정확성과 신뢰감을 강조하는 제품과 가볍고 친근한 운동 앱은 사용자에게 말하는 방식이 다를 수 있기 때문이다.

스타일 가이드는 이런 선택의 기준을 정한다. 존댓말의 수준, 문장의 길이, 사용자 호칭, 능동태와 수동태, 숫자와 단위 표기, 문장부호, 외래어 표기처럼 반복적으로 필요한 원칙을 담는다. UI와 마케팅, 고객지원 콘텐츠에 서로 다른 어조가 필요하다면 그 차이도 설명한다.

좋은 스타일 가이드는 금지사항만 나열하지 않는다. 브랜드가 어떤 목소리를 지향하는지 설명하고, 권장하는 표현과 피해야 할 표현을 실제 예시로 보여준다.

지향하는 표현: 운동을 시작해 보세요.
피해야 할 표현: 운동을 시작하십시오.

이유: 전문성을 유지하되 사용자에게 명령하는 인상을 줄이지 않는다.

규칙보다 중요한 것은 그 규칙을 만든 의도다. 의도를 이해한 번역가는 가이드에 없는 새로운 문장을 만났을 때도 일관된 결정을 내릴 수 있다.

용어집

제품에는 일반 사전만으로 번역하기 어려운 단어가 많다. trip, journey, route, course 등의 단어들이 일상에서는 비슷하게 사용될 수 있지만, 하나의 내비게이션이나 운동 제품 안에서는 각각 다른 기능을 가리킬 수 있다. 이 단어들을 모두 ‘경로’라고 번역하면 사용자는 서로 다른 기능을 구분하기 어렵다. 반대로 문맥마다 자유롭게 번역하면 같은 기능의 이름이 화면에 따라 달라진다. 용어집은 이런 핵심 개념의 승인된 번역을 관리한다. 조금 더 체계적인 용어집에는 원문과 번역어뿐 아니라 다음과 같은 정보도 포함될 수 있다.

• 용어의 정의와 품사
• 승인된 번역과 사용하지 않는 번역
• 실제 사용 예시
• 관련 기능이나 제품
• 대소문자와 복수형 규칙
• 언어 또는 지역별 예외
• 용어를 승인한 사람과 변경 이력

예를 들어 activity의 승인 번역이 ‘활동’이라고 적혀 있더라도 그것만으로는 충분하지 않을 수 있다. 운동 기록을 의미하는지, 사용자의 일반적인 앱 활동을 뜻하는지, 특정 제품 기능의 공식 명칭인지에 따라 다른 번역이 필요하기 때문이다. 좋은 용어집은 단어의 번역보다 개념의 경계를 설명한다. “이 단어를 이렇게 번역하라”뿐 아니라 “이 용어는 무엇이며, 언제 이 번역을 사용해야 하는가”에 답할 수 있어야 한다.

번역 메모리

번역 메모리(Translation Memory, TM)는 이전에 번역한 원문과 번역문을 문장 또는 세그먼트 단위로 저장한다.

새로운 원문이 들어오면 번역 툴은 번역 메모리에서 같거나 비슷한 문장을 찾아 번역가에게 제안한다. 완전히 같은 문장은 100% 매치로, 일부가 다른 문장은 퍼지 매치로 나타난다. 예를 들어 이전에 다음 문장을 번역했다고 해보자.

Connect your device to the app.
기기를 앱에 연결하세요.

새 프로젝트에 Connect your watch to the app이라는 문장이 들어오면 번역 메모리는 기존 번역을 비슷한 문장으로 제안한다. 번역가는 이를 참고해 빠르게 “시계를 앱에 연결하세요”라고 번역할 수 있다.

반복이 많은 소프트웨어와 기술 문서에서는 번역 메모리가 일정과 비용을 크게 줄여준다. 버튼, 오류 메시지, 설정 안내처럼 자주 반복되는 문구의 일관성을 유지하는 데도 유용하다. 하지만 번역 메모리는 정답을 기억하는 시스템이 아니다. 이전의 결정을 기억하는 시스템이다. 과거의 번역이 잘못되었거나 제품의 스타일이 바뀌었다면 번역 메모리는 오래된 결정도 충실하게 제안한다. 기능명이 변경되었는데 기존 번역이 정리되지 않았다면, 높은 매치율을 가진 오래된 제품명이 새로운 콘텐츠에 계속 들어갈 수 있다.

실제 실무에서 지켜보면 100% 또는 하이 퍼지(High-fuzzy) 매치라는 이유로 충분한 검토 없이 번역이 승인되는 경우가 허다하다. 이후 제품 화면에서 문제가 발견되면 사람들은 새로 작업한 번역가를 의심하지만, 실제 오류의 출처는 몇 년 전에 저장된 번역일 수 있다. 번역 메모리의 크기가 곧 품질을 의미하지 않는 이유다. 오래된 번역과 중복 문장, 잘못 정렬된 원문과 번역문을 정기적으로 정리하고, 제품명이나 스타일 변경이 기존 데이터에도 반영되는지 확인해야 한다.

참고 자료

스타일 가이드와 용어집, 번역 메모리가 모두 있어도 문맥이 없으면 정확한 번역이 어려울 수 있다. 특히 소프트웨어 번역가의 경우 완성된 화면을 보면서 작업하기보다 TMS 안에 나열된 문자열을 번역하는 경우가 많다. 번역 툴에 "charge" 단어 하나만 나타났다고 생각해 보자.

배터리를 ‘충전’하라는 의미일 수도 있고, 요금을 ‘청구’한다는 뜻일 수도 있다. 명사라면 ‘충전량’, ‘요금’ 또는 ‘혐의’를 뜻할 가능성도 있다. 원문은 하나지만 제품 안에서 필요한 번역은 전혀 다르다. 스크린샷, 기능 설명, 문자열 ID, 글자 수 제한, 이전 화면과 다음 화면에 관한 정보가 있다면 번역가는 훨씬 정확한 결정을 내릴 수 있다. 예컨대 게임이라면 캐릭터의 성별과 성격, 다른 인물과의 관계, 장면의 분위기를 설명하는 자료가, 동영상 자막이라면 영상이 큰 도움이 될 수 있다.

이런 참고 자료는 부가적인 친절이 아니라 번역 품질을 결정하는 언어 자산이다. 번역가에게 더 정확하게 번역해 달라고 요구하면서 제품에 관한 정보는 거의 제공하지 않는다면, 번역가는 언어를 옮기는 동시에 제품의 맥락까지 추측해야 한다.

질의 기록

번역 과정에서는 가이드에 없는 문제가 계속 나타난다. 새로운 기능명을 번역할 것인지 영어로 유지할 것인지, 마케팅팀이 선호하는 표현을 UI에도 적용할 것인지, 글자 수 때문에 승인 용어의 축약형을 사용할 수 있는지처럼 기존 규칙만으로 답하기 어려운 질문들이다. 문제는 질문에 한 번 답하는 것으로 끝나지 않는다. 이메일이나 메신저에서 결정된 내용이 공식 자산에 반영되지 않으면 몇 달 뒤 같은 질문이 다시 등장한다. 담당자가 바뀌면 결정의 존재 자체를 알기 어렵다.

실제로 한 프로젝트에서 특정 용어를 지역팀의 요청으로 변경했더라도 그 내용이 용어집에는 반영되지 않을 수 있다. 다음 프로젝트의 번역가는 기존 승인 용어를 그대로 사용하고, 지역팀은 “지난번에 이미 바꿨는데 왜 다시 돌아왔느냐”고 묻는다. 번역가는 제공받은 자산을 정확히 따랐지만 결과적으로 잘못된 사람처럼 보인다.

따라서 중요한 질의와 결정은 검색할 수 있는 형태로 기록하고, 필요한 경우 스타일 가이드와 용어집, 번역 메모리에 반영해야 한다. 결정 기록은 최종 답변뿐 아니라 변경의 이유와 적용 범위를 함께 남길 때 더 유용하다.

모든 자산이 자산은 아니다

많은 벤더 및 클라이언트 회사들이 스타일 가이드와 용어집, 번역 메모리 등 '자산'을 이미 가지고 있다. 그러나 파일이 '존재'한다는 것과 실제로 사용할 수 있는 자산이라는 것은 다르다. 스타일 가이드는 몇 년째 업데이트되지 않았고, 텀베이스에는 현재 사용하지 않는 제품명이 남아 있으며, 번역 메모리는 서로 다른 벤더가 만든 번역으로 중복되어 있을 수 있다. 지역팀에서 승인한 변경이 본사의 중앙 자산에는 반영되지 않거나, 새 벤더가 최신 파일에 접근하지 못하는 경우도 있다.

오래되고 부정확한 자산은 아무 자료가 없는 것보다 더 위험할 수 있다. 번역가와 벤더는 공식 자료이기 때문에 신뢰하지만, 그 안의 정보가 이미 유효하지 않다는 사실은 알기 어렵기 때문이다. 언어 자산을 실제 자산으로 만들려면 최소한 다음 질문에 답할 수 있어야 한다.

• 이 자산의 소유자는 누구인가?
• 누가 변경을 승인하는가?
• 어떤 버전이 최신인가?
• 변경 사항은 번역가와 벤더에게 어떻게 전달되는가?
• 지역팀과 리뷰어의 피드백은 어디에 반영되는가?
• 더 이상 사용하지 않는 번역은 어떻게 폐기하는가?
• 회사나 벤더가 바뀌어도 자산을 계속 사용할 수 있는가?

자산 관리는 문서를 한 번 만드는 프로젝트가 아니라, 번역과 리뷰에서 나온 결정을 다시 시스템에 돌려보내는 지속적인 과정이다.

언어 자산은 번역가의 일을 줄이기 위해서만 존재하지 않는다. 번역가와 리뷰어, 벤더, 클라이언트의 로컬라이제이션, 지역팀, 제품팀이 같은 기준을 공유하도록 만드는 조직의 기억에 가깝다. 이 기억이 없다면 새로운 프로젝트를 시작할 때마다 같은 용어를 다시 논의하고, 같은 질문에 다시 답하며, 이전에 수정했던 오류를 다시 발견하게 된다. 담당자나 벤더가 바뀔 때마다 제품의 목소리도 함께 달라질 수 있다.

로컬라이제이션에서 MT와 AI의 활용이 늘어날수록 언어 자산의 중요성은 오히려 커진다. AI는 자연스러운 문장을 빠르게 만들 수 있지만, 특정 회사가 어떤 기능명을 승인했는지, 사용자에게 어떤 어조로 말해야 하는지, 과거의 어떤 번역을 더 이상 사용하지 않는지는 스스로 알지 못한다. 명확하고 최신 상태의 자산이 없으면 AI는 더 빠른 속도로 서로 다른 표현을 만들어낼 뿐이다.

좋은 번역은 하나의 프로젝트를 완성한다. 잘 관리된 언어 자산은 그다음 프로젝트가 처음부터 다시 시작되지 않도록 한다.

번역 프로젝트가 문장을 남긴다면, 성숙한 로컬라이제이션 프로그램은 기억을 남긴다.

*

다음 이야기

→ [로컬라이제이션의 세계] #7 언어 자산 - 스타일 가이드(Style Guide)