글로벌 SaaS 프로젝트에서 영문 단일 UI를 6개 로케일로 확장하는 작업을 맡았을 때, 저는 솔직히 "번역만 붙이면 되지 않나"라고 생각했습니다. 아메리카노 한 잔 놓고 세팅을 시작했는데, 30분이 지나도록 화면이 제대로 나오지 않았습니다. 그때서야 깨달았습니다. 번역은 시작도 아니었다는 것을.
로케일 확장, 왜 이렇게 복잡한 걸까
i18n(internationalization)이란 코드 안에 하드코딩된 텍스트·날짜·통화 형식을 모두 분리해, 언어와 지역이 바뀌어도 소스 로직을 건드리지 않고 UI를 전환할 수 있도록 설계하는 아키텍처 작업입니다. 여기서 국제화(i18n)는 '18'이 i와 n 사이의 글자 수에서 나온 약어이며, 단순 번역 작업인 l10n(localization)과는 역할이 다릅니다. l10n이 "무엇을 말할지"를 결정한다면, i18n은 "그 말을 어디에 어떻게 담을지"를 결정하는 그릇을 만드는 일입니다.
제가 직접 겪어보니 국내 서비스 상당수가 이 구분을 흐릿하게 가져갑니다. 영문 버전을 낼 때 한글 UI를 그대로 번역만 해서 붙이는 경우가 많은데, 이렇게 되면 문자열 길이·폰트 폴백·공백 규칙 같은 미시 디테일에서 어색함이 누적됩니다. 독자 여러분도 해외 서비스를 쓰다가 버튼 안에 글자가 잘렸거나, 레이아웃이 살짝 어긋난 경험이 있으시지 않으신가요? 그게 바로 i18n 설계가 빠진 결과입니다.
중요한 것은 설계 단계부터 고려해야 한다는 점입니다. 독일어는 같은 의미의 영문 문장보다 평균 15% 이상 길어지고, 아랍어와 히브리어는 텍스트 방향 자체가 오른쪽에서 왼쪽으로 바뀝니다. 이런 변수를 출시 직전에 끼워 넣으려 하면 대규모 리팩토링이 불가피합니다. 제 경험상 이건 초기 설계 비용의 서너 배를 나중에 지불하는 것과 같습니다.
RTL 설계와 로케일별 디테일, 어디까지 챙겨야 하나
제가 작업한 프로젝트에서 가장 공수가 많이 든 부분은 RTL(Right-to-Left) 지원이었습니다. RTL이란 아랍어·히브리어처럼 텍스트가 오른쪽에서 왼쪽으로 흐르는 언어 환경에서, 화면 전체 레이아웃을 좌우 반전시키는 설계 방식입니다. 단순히 dir="rtl" 속성 하나 추가하면 끝날 것 같지만, 실제로는 CSS 전반을 논리 속성(logical property)으로 재작성해야 합니다.
논리 속성이란 margin-left처럼 물리적 방향을 고정하지 않고, margin-inline-start처럼 텍스트 흐름 방향을 기준으로 간격을 지정하는 CSS 방식입니다. 이 방식을 쓰면 RTL 전환 시 별도 분기 코드 없이 레이아웃이 자동으로 미러링됩니다. 저는 이 작업에서 드롭다운 위치, 진행 단계 표시, 화살표 아이콘까지 모두 미러링 여부를 검토했습니다.
여기서 흥미로운 지점이 있습니다. Apple의 Human Interface Guidelines와 Material Design의 Bidirectionality 문서를 비교해 보면, 아이콘 미러링에 대한 권장이 일관됩니다(출처: Apple Human Interface Guidelines). 시계 방향을 나타내는 아이콘은 RTL에서도 미러링하지 않고, 진행 방향을 나타내는 화살표는 미러링합니다. 이게 글로벌 디자인의 기본 합의처럼 자리 잡혀 있는데, 처음 이 규칙을 마주했을 때 저도 "왜 시계는 안 뒤집나?"라고 한참 고민했습니다.
폰트 설계도 생각보다 까다로웠습니다. 저는 시스템 폰트 우선의 폴백 체인을 Noto Sans → Apple SD Gothic → Helvetica → Arial 순서로 구성했습니다. 이렇게 하면 모든 로케일에서 행 높이가 일정 범위 안에 들어오는데, 한국어와 일본어는 영문 대비 행 높이를 1.6으로 1.07배 늘려야 시각적으로 균형이 맞았습니다.
핵심 적용 포인트를 정리하면 다음과 같습니다.
- 텍스트 컨테이너에
max-content대신fit-content와min-width를 조합해 독일어 같은 장문 언어에서 자연스러운 줄바꿈 확보 - CSS 물리 속성 대신 논리 속성(margin-inline-start, padding-inline-end 등)으로 RTL 자동 대응
- 폴백 폰트 체인 설계로 로케일별 행 높이 편차를 ±0.05 이내로 제어
- 아이콘 미러링 기준을 "방향성 유무"로 명문화하여 디자인 시스템에 반영
현지화 파이프라인, 어떻게 자동화할 것인가
코드 아키텍처가 갖춰지면 그다음은 번역 문자열을 어떻게 흘려보내고 받아올 것인가의 문제입니다. 여기서 등장하는 개념이 TMS(Translation Management System)입니다. TMS란 번역가·개발자·로컬라이제이션 매니저가 한 플랫폼에서 협업하며, 번역 파일의 업로드·검수·배포를 자동화하는 관리 시스템입니다.
수작업으로 스프레드시트를 주고받는 방식은 파일 버전 충돌과 누락 문자열 문제를 피하기 어렵습니다. 일반적으로 자동화 파이프라인을 갖추면 신규 로케일 추가 시간이 수주에서 수일로 단축된다고 알려져 있는데, 제 경험상 이건 과장이 아닙니다. 소스 파일을 CLI 명령어 하나로 플랫폼에 밀어 넣고, 번역이 완료되면 같은 방식으로 당겨 오는 구조가 되면 개발 사이클과 번역 사이클이 분리되어 서로 블로킹하지 않습니다.
최근에는 AI 사전 번역 기능도 실무에서 쓸 만한 수준이 됐습니다. 실제 사례로, 한 이커머스 기업이 AI 번역 후 전문 번역가 검수를 거친 결과 전체 텍스트의 25%만 수정이 필요했다는 보고가 있습니다. 여기서 주목할 개념이 컨텍스트 하베스터(Context Harvester)입니다. 컨텍스트 하베스터란 소스 코드를 스캔해 각 문자열이 UI의 어느 위치에서 어떤 맥락으로 쓰이는지를 자동으로 추출·첨부하는 도구입니다. 번역가나 AI 모두 문맥 없이는 "Save"가 파일 저장인지 변경 사항 저장인지 알 수 없는데, 이 도구가 그 모호함을 해소합니다.
i18n 구현 라이브러리 선택도 중요합니다. LinguiJS 같은 라이브러리는 ICU MessageFormat을 지원합니다. ICU MessageFormat이란 복수형·성별·조건 분기 같은 언어별 문법 규칙을 하나의 문자열 템플릿 안에 정의할 수 있는 국제 표준 메시지 형식입니다. 예를 들어 "1개의 항목"과 "2개의 항목"을 언어마다 다른 규칙으로 처리해야 할 때, 문자열을 이어 붙이는 방식("총 " + count + "개")은 어순이 다른 언어에서 바로 깨집니다. ICU MessageFormat을 쓰면 번역가가 해당 언어의 복수형 규칙에 맞게 직접 템플릿을 작성할 수 있어, 개발자가 언어별 예외 코드를 따로 만들 필요가 없습니다.
W3C의 국제화 가이드라인도 이 구조적 접근을 권장합니다(출처: W3C Internationalization). 문자열 외부화, 논리 속성 사용, 로케일 감지 기반 자동 포맷팅은 접근성과 글로벌 사용성을 동시에 높이는 기본 원칙으로 명시되어 있습니다.
제가 이 작업을 마치고 6개 로케일을 동시 출시한 후 첫 한 달, 한국 가입 전환율이 18%, 독일이 23%, 사우디아라비아가 11% 올랐습니다. 숫자만 보면 "번역 효과 아닌가"라고 할 수 있지만, 이전에도 기계 번역 텍스트는 있었습니다. 달라진 건 레이아웃이 깨지지 않았고, 폰트가 어색하지 않았고, 날짜와 통화 형식이 현지 규칙과 맞았다는 점이었습니다. UI가 낯설지 않아야 사람들이 머뭅니다.
결국 i18n은 코드 품질 문제이기 전에 사용자 신뢰의 문제라고 생각합니다. 처음부터 제대로 설계된 i18n 아키텍처는 시장을 하나 추가할 때마다 드는 비용을 극적으로 줄여줍니다. 지금 서비스를 개발 중이시거나 글로벌 확장을 검토 중이시라면, 번역팀을 꾸리기 전에 코드베이스의 문자열 외부화 여부부터 점검해 보시길 권합니다. 그게 진짜 출발점입니다.