글로벌 번역 외주 비용을 줄이는 법: 지역화 우선순위를 설계하는 인디 게임 팀의 실전 기준
번역 단가를 깎기보다 번역할 텍스트와 언어, 출시 시점을 통제하는 편이 비용 절감에 더 효과적이다. 인디 게임이 지역화 우선순위를 정하고 외주 품질을 관리하는 방법을 정리한다.
번역비는 단가보다 범위에서 결정된다
글로벌 출시를 준비할 때 번역 외주비는 대개 단어 수에 언어 수를 곱한 값에서 출발한다. 하지만 실제 예산을 크게 흔드는 요인은 단가 협상보다 번역 대상이 계속 늘어나는 일, 이미 번역한 문장이 자주 바뀌는 일, 맥락 없는 문자열 때문에 발생하는 재작업이다.
먼저 전체 텍스트를 한 덩어리로 보지 말고 플레이 경험에 따라 나눠야 한다. 스토리 중심 게임이라면 대사와 퀘스트 설명이 핵심 범위가 되지만 시스템 중심 게임이라면 조작 안내와 오류 메시지, 상점·결제 문구가 우선이다. 이 구분 없이 모든 문자열을 같은 시점에 발주하면 출시 직전 수정분까지 비싼 긴급 번역으로 바뀌기 쉽다.
대략적인 초기 예산은 다음처럼 계산할 수 있다.
여기서 대상 단어 수는 원문 전체가 아니라 이번 출시 빌드에서 실제로 노출되는 확정 문자열 수여야 한다. 미사용 텍스트, 개발용 문구, 출시 후 추가할 콘텐츠를 분리하면 계산 자체가 훨씬 정확해진다.
언어는 시장 규모만으로 고르지 않는다
언어 우선순위는 잠재 이용자 수만으로 정하면 안 된다. 해당 언어권에서 게임 장르가 통하는지 스토어 페이지와 고객 지원까지 감당할 수 있는지 이미 유입 신호가 있는지를 함께 봐야 한다.
가장 단순한 방법은 각 언어 후보를 같은 기준으로 점수화하는 것이다. 점수는 정답이 아니라 팀이 왜 특정 언어를 먼저 선택했는지 설명하는 장치다.
| 평가 항목 | 확인할 질문 | 권장 비중 |
|---|---|---|
| 수요 신호 | 위시리스트, 데모 다운로드, 커뮤니티 반응이 있는가 | 35% |
| 장르 적합성 | 해당 지역에서 비슷한 장르가 통하는가 | 25% |
| 전환 가능성 | 현지화된 스토어 자산과 가격 정책까지 준비할 수 있는가 | 20% |
| 운영 부담 | 고객 문의와 버그 제보를 처리할 경로가 있는가 | 10% |
| 구현 난이도 | 폰트, 줄바꿈, 텍스트 확장 문제가 큰가 | 10% |
예를 들어 스팀 위시리스트의 국가 분포, 데모 설문 언어, 공식 디스코드에서 반복되는 번역 요청은 유용한 수요 신호다. 다만 플랫폼 통계가 곧 구매를 보장하지는 않는다. 장르 적합성과 가격, 현지 마케팅 가능성을 함께 확인해야 한다.
flowchart TD
A[후보 언어 목록] --> B{수요 신호가 있는가?}
B -- 아니오 --> X[출시 후 재검토]
B -- 예 --> C{핵심 경험을 번역할 수 있는가?}
C -- 아니오 --> Y[기술 준비 후 보류]
C -- 예 --> D{스토어·지원 운영이 가능한가?}
D -- 아니오 --> Z[범위 축소 또는 보류]
D -- 예 --> E[1차 지역화 대상]처음부터 많은 언어를 지원하기보다 수요가 확인된 소수 언어로 1차 출시를 하고 데이터에 따라 확장하는 편이 안전하다. 특히 라이브 서비스가 아닌 소규모 팀이라면 언어 수가 늘어날수록 패치 노트, 공지, 고객 지원까지 유지 비용이 누적된다는 점을 예산에 넣어야 한다.
외주 전에 텍스트를 줄이고 고정하라
번역사에게 보내기 전의 준비가 품질과 비용을 동시에 좌우한다. 다음 항목은 외주 발주 전에 정리할 가치가 크다.
문자열을 기능 단위로 묶기
메뉴, 전투, 퀘스트, 아이템, 튜토리얼, 오류 메시지처럼 기능별로 문자열을 나눈다. 출시 시점에 필요한 묶음만 발주할 수 있고 수정이 생겨도 영향을 받는 범위를 빠르게 찾을 수 있다.
변수와 문법 정보를 명시하기
플레이어 이름이나 수치를 삽입하는 문자열은 변수의 의미와 예시를 함께 제공해야 한다. 번역사가 변수가 사람 이름인지 아이템명인지 알지 못하면 자연스러운 어순을 만들기 어렵다.
{
"quest.accepted": {
"source": "{playerName} accepted {questName}.",
"context": "Quest notification shown after accepting a quest.",
"variables": {
"playerName": "Player display name",
"questName": "Localized quest title"
},
"example": "Mina accepted The Lost Map."
}
}언어에 따라 단어 순서와 조사, 복수형 규칙이 달라진다. 원문 문장 구조에 맞춰 번역문을 억지로 조립하게 만드는 키 분할은 피하는 편이 좋다. "획득: "와 아이템명을 따로 두기보다 문장 전체를 하나의 문자열로 관리하는 방식이 일반적으로 안전하다.
재사용 문자열과 중복을 관리하기
완전히 같은 의미로 반복되는 문구는 하나의 키를 재사용할 수 있다. 하지만 원문이 같더라도 화면 맥락이 다르면 키를 분리해야 한다. 예를 들어 버튼의 닫기와 오류 안내의 닫기는 같은 번역을 쓸 수 있지만 영어의 Save는 동작인 저장과 명사인 세이브 데이터처럼 서로 다른 번역이 필요할 수 있다.
번역 메모리 할인 여부는 공급업체와 언어 조합에 따라 다르다. 견적을 받을 때 신규 문장, 반복 문장, 부분 일치 문장이 각각 어떻게 계산되는지 명시적으로 확인하자. 그보다 중요한 것은 문장 키와 원문을 불필요하게 바꾸지 않아 기존 번역을 재활용할 수 있게 만드는 일이다.
발주는 한 번에 끝내지 말고 단계로 나눈다
외주를 통째로 맡기는 방식은 편해 보이지만 초기에 용어와 문체가 어긋나면 이후 전체 범위의 수정 비용이 커진다. 짧은 파일로 시험 번역을 먼저 진행해 협업 방식을 맞추는 편이 낫다.
- 핵심 UI와 대표 대사 등 작은 범위를 시험 번역으로 보낸다.
- 용어집, 고유명사 표기, 말투 기준을 확정한다.
- 출시 빌드에 들어갈 확정 문자열을 본 번역으로 발주한다.
- 게임 안에서 문맥 검수와 화면 테스트를 수행한다.
- 수정 사항을 한 번에 모아 재번역 범위를 최소화한다.
용어집에는 단어 대응표만 넣지 말고 금지 번역과 화면상 용도를 함께 기록한다. 예를 들어 장비 등급명, 능력치명, 세계관 고유명사, 플레이어 호칭은 일관성이 특히 중요하다. 스크린샷이나 짧은 영상 링크를 문자열 묶음에 연결하면 문맥 문의와 추측 번역을 줄일 수 있다.
QA는 언어 품질과 화면 품질로 나눠 본다
번역이 문법적으로 맞아도 게임에서는 문제가 생길 수 있다. 버튼에서 글자가 잘리거나 줄바꿈이 어색하거나 변수 삽입 후 문장이 깨지거나 폰트에 필요한 글리프가 없는 경우가 대표적이다.
언어 QA에서는 용어 일관성, 오역, 원문 누락, 문체를 확인한다. 기능 QA에서는 텍스트 넘침, 잘못된 인코딩, 복수형·성별 규칙, 오른쪽에서 왼쪽으로 읽는 언어의 UI 배치, 저장 데이터와 로그의 언어 처리 등을 확인한다. 둘을 같은 체크리스트로 다루면 어느 쪽도 충분히 검증하기 어렵다.
출시 직전에는 모든 문장을 완벽하게 다듬으려 하기보다 구매와 플레이를 막는 문제부터 고친다. 스토어 설명, 첫 실행 안내, 조작 튜토리얼, 결제·가격 관련 문구, 치명적 오류 메시지는 우선순위가 높다. 수집 요소의 짧은 설명이나 출시 후 열릴 콘텐츠는 데이터가 쌓인 뒤 다음 배치로 옮길 수 있다.
적은 예산으로도 신뢰를 잃지 않는 기준
비용을 줄인다는 것은 번역사의 검수 시간을 무작정 줄이는 일이 아니다. 출시 범위를 투명하게 정하고 확정된 텍스트에 충분한 맥락을 제공하며 지원할 언어를 운영 가능한 수준으로 제한하는 일에 가깝다.
가장 실용적인 출발점은 현재 빌드의 문자열 수를 기능별로 세고 위시리스트와 데모 반응에서 언어 수요를 확인한 뒤 상위 몇 개 언어만 시험 번역으로 검증하는 것이다. 이 과정을 거치면 지역화는 막연한 글로벌 확장 계획이 아니라 다음 출시 판단에 쓸 수 있는 비용·품질 관리 체계가 된다.
