개념
로컬라이제이션 테스트는 번역 검수가 아니다
번역이 정확하고 자연스러운지 보는 것은 번역 검수이고 번역 업체나 현지 담당자가 한다. QA가 하는 로컬라이제이션 테스트(LQA) 는 다른 질문에 답한다. 번역된 문자열이 들어갔을 때 제품이 망가지지 않는가, 그 언어권 플레이어에게 기능이 동일하게 동작하는가, 문제가 되는 표현·자산이 남아 있지 않은가 다.
마지막 질문은 레슨 4의 등급분류·플랫폼 심의와 맞닿는다. 등급 기준 자체는 레슨 4에서 다뤘으므로, 여기서는 지역마다 다른 허용 표현에 맞춰 자산 교체가 제대로 됐는지 만 본다.
의사 로컬라이제이션 — 번역이 오기 전에 깨뜨린다
로컬라이제이션 결함의 대부분은 번역이 도착한 뒤가 아니라 코드를 쓰는 순간 만들어진다. 문자열을 하드코딩했거나, 레이아웃을 영어 길이에 맞춰 고정했거나, 문장을 조각으로 이어 붙였거나. 번역본이 온 뒤 발견하면 늦다. 그래서 번역 없이 원본을 기계적으로 변형해 미리 드러내는 기법이 의사 로컬라이제이션(pseudo-localization) 이다.
원본 Settings 를 [!!! Ŝéttíñgŝ ——————— !!!] 로 바꾼다. 양 끝 마커·악센트 치환·확장 패딩이 들어 있고, 이 한 번의 변형으로 네 종류의 결함이 보인다.
| 변형 | 드러나는 결함 |
|---|---|
| 악센트·특수문자 치환 | 글리프 누락(두부 현상), 인코딩 깨짐 |
| 길이 확장 패딩 | 버튼·라벨 잘림, 줄바꿈 실패, 겹침 |
| 양 끝 마커 | 여는 마커만 보이면 잘린 것, 마커가 문장 중간에 있으면 이어 붙인 것 |
| 변형되지 않은 문자열 | 하드코딩 — 리소스 파일 밖에 박혀 번역 대상이 아니다 |
마지막 줄이 가장 값어치가 크다. 화면을 돌며 평범한 영어로 남아 있는 텍스트 를 찾는 것만으로 번역 누락 목록이 나온다. 이 빌드는 UI가 굳는 시점에 한 번 돌리는 것이 가장 싸고, 의사 RTL을 함께 쓰면 아랍어·히브리어 대응 프로젝트의 레이아웃 반전 결함도 같이 나온다.
문자열은 얼마나 길어지는가
영어를 기준으로 하면 대부분의 유럽 언어는 길어지고, 한국어·중국어·일본어는 짧아지는 대신 글자가 넓다. 핵심 규칙은 짧은 문자열일수록 확장률이 크다 는 것이다. 단어 하나짜리 버튼 라벨이 두 배 이상 길어지는 일은 흔하고 긴 문단은 10~20%만 늘어난다. 구체적인 확장률은 W3C Internationalization 지침을 원문으로 확인해 기준으로 삼는다. QA는 버튼·탭·라벨처럼 짧고 폭이 고정된 곳 을 먼저 보고, 레이아웃이 길이에 반응하는지, 두 줄이 되며 아래 요소를 가리지 않는지, 글꼴 대체 실패 가 없는지를 본다.
자리표시자·복수형·어순 — 조립한 문장은 반드시 깨진다
번역 결함 중 가장 위험한 부류는 화면이 아니라 크래시 로 나타나고, 원인은 대개 자리표시자다.
| 문제 | 예 | 결과 |
|---|---|---|
| 자리표시자 누락 | 원본 "%s님이 %d레벨 달성" 에서 %d 가 빠짐 | 인자 불일치로 예외·크래시 |
| 순서 뒤바뀜 | 어순상 이름과 숫자 위치가 반대여야 함 | 값이 엉뚱한 자리에 들어감 |
| 번역 불가 토큰 손상 | {playerName} 을 번역가가 번역해 버림 | 치환 실패, 원문 노출 |
대응은 두 가지다. 위치 지정 자리표시자(%1$s, {0})를 쓰면 어순을 바꿔도 값이 제 자리를 찾고, 빌드 단계에서 원본과 번역본의 자리표시자 집합을 자동 비교 한다. 사람이 눈으로
볼 일이 아니다. 복수형은 더 까다롭다. 한국어·중국어·일본어는 형태가 1개, 영어·독일어는 2개(one/other), 러시아어·폴란드어는 3~4개(one/few/many/other), 아랍어는 6개(zero/one/two/few/many/other)다.
"아이템 " + 개수 + "개를 받았습니다" 처럼 문장을 조각으로 이어 붙이면 이 구조를 표현할 방법이 없다. 해결책은 문장 전체를 하나의 문자열로 두고 복수형 규칙을 지원하는 포맷을 쓰는
것이고, 그 표준 정의가 CLDR Plural Rules 다. 한국어도 조사가 받침에 따라 달라져 "{itemName}을(를) 획득" 같은 회피 표기가 나오므로, QA는 받침이 있는 이름과 없는 이름 두 개
를 테스트 데이터로 넣어 확인한다.
지역별 표기와 빌드 차이
숫자와 시간의 표기 도 지역마다 다르다. 날짜(2026-09-24 / 24.09.2026 / 9/24/2026), 숫자 구분자(1,234.5 vs 1.234,5), 통화 기호 위치, 12시간제와 24시간제가 대표적이므로
기기 지역 설정을 바꿔 가며 확인한다. 지역별 빌드가 갈리면 빌드 대조표 를 만들어, 어느 빌드에 어떤 언어 팩·자산·기능 플래그가 들어가는지 릴리스마다 대조한다.
크라우드 테스트 — 언제 쓰고 언제 쓰지 않는가
크라우드 테스트는 외부의 다수 테스터에게 과업을 주고 결함을 받는다. 내부 QA를 대체하려 들면 실패한다.
| 잘 맞는 상황 | 맞지 않는 상황 |
|---|---|
| 기기·OS·통신사 조합을 넓게 훑을 때 | 공개 전 기밀이 큰 신작 |
| 실제 가정·이동 환경의 네트워크 | 도메인 지식이 있어야 재현되는 영역 |
| 여러 언어권 원어민의 언어 품질 확인 | 개인정보·결제 실계정이 필요한 시험 |
| 짧은 기간에 대량 플레이가 필요할 때 | 같은 절차를 정확히 반복하는 회귀 |
과업 설계는 탐색적 테스트의 차터와 같다. 자유롭게 놀라고 던져 두면 로그인 화면 결함만 수백 건 들어온다. 범위(어느 기능·화면까지), 환경(요구 기기·OS·지역·언어), 과업 ("튜토리얼을 끝내고 첫 상점 구매까지"처럼 목적지를 가진 임무), 기대 산출물(리포트 형식과 필수 첨부), 금지 사항(결제 실거래, 계정 공유, 스포일러 유출)을 적는다.
리포트 품질 관리가 성패를 가른다. 보상이 건당으로 걸리면 중복과 저품질이 폭증 한다.
알려진 결함 목록을 미리 공개해 중복을 보상에서 빼고, 재현 단계·빈도·영상이 없는 리포트는 표준화된 사유로 반려하고, 트리아지는 내부 QA가 하고, 승인률·중복률·테스터별 유효 리포트 수로 다음 과업의 인원을 조정한다.
분업의 원칙은 하나다. 내부 QA가 위험 기반으로 무엇을 볼지 정하고 판정 기준을 갖고, 크라우드는 닿지 못하는 커버리지의 폭 을 담당한다. 크라우드 리포트를 내부가 재현·판정해 정식 결함으로 승격시키는 흐름이 유지되어야 그 결과가 릴리스 판단에 쓰인다.
라이브 운영 — 패치 스모크의 범위를 먼저 정한다
라이브 패치는 점검 창(maintenance window) 안에서 끝나야 한다. 새벽 2시부터 6시까지라면 배포 후 검증에 쓸 시간은 길어야 한 시간이다. 범위를 미리 정해 두지 않으면 매번 "어디까지 봤는지 모르는 채" 오픈한다. 범위는 두 덩어리로 고정한다.
[고정 스모크] 패치 내용과 무관하게 매번 — 20~30분
로그인 → 캐릭터 진입 → 핵심 전투 → 저장/재접속
상점 → 결제 플로우(샌드박스) → 재화 반영
보상 수령 → 확률형 아이템 추출 → 표시 확률 화면
공지 문구와 버전 표기
[변경 영향] 이번 패치가 건드린 영역 — 20~30분
변경 파일·테이블·API 에서 역산한 화면과 흐름
직전 패치에서 핫픽스가 났던 영역고정 스모크에 결제와 확률 표시가 들어간 이유는 레슨 6과 같다. 실패했을 때 금전과 법이 걸리므로 패치 내용과 무관하게 매번 확인한다. 배포 절차를 스테이징에서 리허설 하고 롤백도 같이 리허설 한다. 되돌릴 수 없는 마이그레이션은 그 사실이 미리 드러나야 한다.
핫픽스는 "무엇으로 막을 수 있는가"부터 묻는다
사고가 났을 때 순서는 고치는 게 아니라 막는 것 이 먼저다.
1. 영향 판정 누가 무엇을 잃는가 — 재화·결제·진행 손실이면 최우선
2. 차단 수단 서버 설정 토글로 기능만 끄기 ← 분 단위
서버 데이터·설정 수정 ← 시간 단위
서버 바이너리 배포 ← 점검 필요
클라이언트 패치 ← 스토어 심사 (일 단위)
3. 보상 범위 영향받은 계정을 로그로 특정할 수 있는가
4. 검증 차단 후 재현 시도, 보상 지급 후 총량 대조
5. 사후 회귀 추가, 스모크 고정 항목 편입 판정클라이언트 패치에 스토어 심사가 걸린다는 점이 특히 중요하다. 그래서 위험한 기능은 처음부터 서버에서 끌 수 있게 만들어 달라고 요구 하는 것이 QA의 사전 작업이다. 레슨 5의 "중요한 결과는 서버에서 결정되어야 한다"의 운영판이다.
서버 설정 토글의 함정
기능 플래그는 강력한 만큼 검증되지 않은 상태 공간을 만든다.
- 조합 폭증: 토글
n개면 이론상 상태가2ⁿ개다. 실제로 쓰이는 조합과 기본값 조합만 정의해 시험한다. - 기본값이 안전해야 한다: 설정 로드에 실패했을 때 기능이 켜진 채 열리면 사고다. 토글마다 안전한 쪽을 판정해 둔다.
- 되돌림 시험: 켰다가 끈 뒤 상태가 정상인지 본다. 켜진 동안 생성된 데이터가 꺼진 뒤 어떻게 되는지가 대표 결함 지점이다.
- 적용 시점과 이력: 즉시 반영인가 재접속 후인가, 클라이언트 캐시는 언제 갱신되는가. 이력이 남지 않는 토글은 원인 추적을 막는다.
이벤트 시간 경계 — 라이브에서 가장 자주 터지는 곳
라이브 운영 결함의 단골은 기능이 아니라 시각 이다. 이벤트는 시작하고 끝나고 일일 보상은 리셋되는데, 이 경계는 언제나 새벽이다.
| 경계 | 시험 관점 |
|---|---|
| 시작 시각 | T−1초 불가, T 가능, T+1초 정상. 배너·문구도 같은 시각에 바뀌는가 |
| 종료 시각 | T−1초 에 시작한 판이 T 이후 끝나면 보상이 나오는가 |
| 일일 리셋 | 리셋 순간에 진행 중이던 수령·구매가 중복·소실되지 않는가 |
| 기간 경계 | 월말·연말, 2월 29일, 31일이 없는 달의 "매월 31일" 설정 |
| 타임존 | 서버 기준인가 로컬 기준인가, 안내 문구에 기준이 명시됐는가 |
| 서머타임 | 전환일에 존재하지 않는 시각·중복되는 시각을 어떻게 처리하는가 |
| 기기 시간 변조 | 기기 시계를 앞당겨도 서버 판정이 흔들리지 않는가 |
서머타임은 한국 개발팀이 가장 자주 놓치는 항목이다. 한국은 서머타임을 쓰지 않으므로 코드에도 테스트 계획에도 그 개념이 없다. 그런데 글로벌 서비스라면 전환일에 존재하지 않는 한 시간 과 두 번 지나가는 한 시간 이 생긴다. 로컬 시각 기준으로 "매일 02:30 리셋"을 구현했다면 전환일에 리셋이 건너뛰거나 두 번 일어난다.
안전한 설계 규칙은 하나다. 시각은 UTC로 저장·계산하고 로컬 시각은 표시할 때만 변환한다. QA는 이 규칙이 지켜지는지 로그와 DB로 확인하고, 이벤트 일정표에 기준 타임존이 명시되어 있는지 를 검수 항목으로 둔다. 기준이 없는 일정표는 그 자체가 결함이다. 시험에는 서버 시각을 옮길 수 있는 환경이나 시작·종료 시각을 몇 분 뒤로 설정할 권한 이 필요하다. 경계 시험을 이벤트 당일 새벽에 처음 해 보는 것은 시험이 아니라 도박이다.
실무에서 왜 필요한가
이 세 가지의 공통점은 출시 이후에, 개발팀의 시야 밖에서 터진다는 것 이다. 로컬라이제이션 결함은 그 언어를 읽는 사람만 보고, 크라우드가 찾는 결함은 사내에 없는 기기에서만 나고, 라이브 사고는 새벽에 일어난다. 사내 정상 환경의 QA만으로는 구조적으로 닿지 않는다.
비용 구조도 특이하다. 이벤트 시간 경계 결함은 보통 코드 한 줄짜리 문제지만 새벽에 터지면 대응 인력이 비상 소집되고 보상이 나가고 공지가 올라간다. 작은 결함이 큰 비용으로 증폭되는 경로가 라이브에 있다. 그래서 라이브 QA는 주간·격주 패치 스모크를 돌리고, 이벤트 일정표의 시간 경계를 사전 검증하고, 핫픽스 재현과 검증을 맡고, 지역별 빌드를 대조한다. 반복이 많은 만큼 스모크를 자동화하고 시간 경계 시험을 스크립트로 만든 사람 의 가치가 빠르게 드러난다.
채용시장에서의 위치
라이브 서비스가 늘면서 게임 QA 공고에서 라이브 QA의 비중이 커졌다. 반복되는 요구는 패치 스모크 운영, 핫픽스 대응, 로그·DB 조회(SQL), 이벤트·상품 설정 검증 경험이고, 로컬라이제이션 쪽은 외주 QA 업체의 LQA 포지션에 외국어 능력이 사실상 필수로 걸린다. 면접에서 힘을 갖는 것은 절차를 세운 경험이다. "이벤트 시작 시각을 로컬 시간 기준으로 구현한 코드를 발견해 서머타임 전환일에 리셋이 두 번 일어나는 것을 막았고, 이후 일정표에 기준 타임존 명시를 검수 항목으로 넣었다" 처럼 결함 하나에서 끝나지 않은 이야기가 특히 강하다.