국제화 컨설팅: 문제를 해결하고, 미래를 계획하세요
i18n이 어렵다는 건 이미 알고 계실 겁니다. 저는 이런 증상들을 봤습니다: 무너지는 RTL 레이아웃, 버튼을 넘쳐흐르는 독일어 텍스트, 잘못된 언어로 된 API 응답, 그리고 출시 후 몇 주 내에 동기화가 깨지는 번역들. 저는 만병통치약을 팔지 않습니다. 저는 여러분의 팀이 처한 특정 문제를 해결하도록 돕고, 같은 방식으로 두 번 깨지지 않을 시스템을 구축합니다.
"우리가 이것을 더 일찍 계획했어야 했습니다"
지금 지불하고 있는 아키텍처 비용
영어로 출시했습니다. 잘 작동했죠. 그러고 나서 "랜딩 페이지용으로만" 프랑스어를 추가했습니다. 이제 여기 계신 이유는:
코드베이스에 47개의 파일에 lang= 확인이 흩어져 있습니다
제품 관리자들은 "A/B 테스트 문구를 테스트할 수 있습니까?"라고 묻고 엔지니어링은 "다시 작성하지 않고는 안 됩니다"라고 말합니다
여러분은 세 가지 다른 번역 워크플로우를 가지고 있으며 그 중 어느 것도 안정적으로 작동하지 않습니다
제가 본 문제들:
- 문자열이 구성요소에 하드코딩되었기 때문에 Next.js 앱에 i18n을 개조하는 데 6개월 이상을 소비하는 팀
- 개발자들이 어떤 파일을 업데이트해야 할지 알지 못해서 번역 파일들이 동기화되지 않습니다.
- 아무도 번역 파이프라인을 신뢰하지 않기 때문에 릴리스 전에 "현지화 동결" 기간이 있습니다.
- 워크플로우가 너무 고통스러워서 번역된 어떤 내용이든 변경하는 것에 대한 저항이 있습니다
제가 도와드릴 수 있는 것:
- i18n 도입을 점진적으로 진행하도록 허락하는 리팩토링 전략 ("모든 것을 멈추고 다시 작성하세요"라고 요구하지 않습니다)
- 개발을 방해하지 않고 번역을 동기화 상태로 유지하기 위한 프로세스 디자인입니다.
- 현재 접근 방식이 10개 이상의 언어로 확장할 때 어디서 문제가 발생할지 파악하기 위한 아키텍처 검토
i18n은 기능이 아니라 아키텍처입니다. 나중에 추가하려는 건 집을 다 지은 후에 지하실이 필요하다고 결정하는 것과 같습니다.
제가 그 지하실을 파는 것을 돕거나, 실제로 필요한지 판단하도록 도와드립니다.
RTL은 모든 것을 깨뜨립니다
UI는 아랍어, 히브리어 또는 우르두어를 위해 디자인되지 않았습니다
dir="rtl"로 전환하고 레이아웃이 망가지는 것을 보셨습니다:
제가 본 것:
- 200개 이상의 구성요소를 가진 디자인 시스템 중 12개만이 RTL을 제대로 다룹니다
- 논리적 속성 대신 float: left를 사용하여 모든 새로운 기능에서 RTL 버그를 생성하는 팀
- 구성요소별 RTL 재정의를 필요로 하는 팝오버 및 모달
- 레이아웃 방향만 뒤집고 배치 논리를 깨뜨리는 "RTL 지원"을 주장하는 프레임워크
제가 도와드릴 수 있는 것:
- CSS 논리적 속성 마이그레이션 (margin-left 대신 margin-inline-start)
- 출시되기 전에 RTL 문제를 찾기 위한 디자인 시스템 감사
- RTL-우선 스타일링을 위한 프레임워크별 지침 (Tailwind, shadcn, MUI)
모든 구성요소에서 RTL 버그를 수동으로 수정하는 것은 지속 불가능합니다. 저는 RTL 지원을 끊임없는 싸움이 아니라 체계적으로 만듭니다.
"독일어 텍스트가 저희 버튼을 깨뜨렸습니다."
번역을 위해 구축되지 않은 UI
영어는 맞습니다. 독일어는 맞지 않습니다. 디자인이 다음을 가정했습니다:
그러고 나서 독일어, 핀란드어 또는 태국어로 번역했고 다음을 발견했습니다:
버튼들이 단어 중간에 잘립니다
모든 행에 가로 스크롤이 있는 테이블
읽을 수 없는 블록으로 래핑되는 텍스트
컨테이너의 너비가 고정되어 있기 때문에 라틴어 외 텍스트가 잘립니다
제가 도와드릴 수 있는 것:
- 내용 길이에 따라 유연하게 변하는 UI 패턴
- 문자 예산 계획 (독일어는 30% 확장되고, 태국어는 공백을 사용하지 않습니다)
- CJK, 아랍어, 데바나가리어를 깨지지 않고 다루는 타이포그래피 시스템
제가 번역을 견딜 수 있는 UI를 구축하는 것을 돕습니다—맞지 않는 10,000 단어에 대해 비용을 지불하기 전에 말입니다.
i18n이 왜 중요한지에 대한 강의는 필요하지 않습니다. 2 AM에 RTL 팝오버를 디버깅하고, 문자 예산에 대해 제품팀과 논쟁했으며, 실제로 작업하는 번역 파이프라인을 설계한 사람이 필요합니다.
아무도 경고하지 않은 예상치 못한 문제들
그곳에 있었던 팀들의 전쟁 이야기
이것들은 이론적인 것이 아닙니다. 이것들은 프로덕션 환경에서 발생한 실제 문제들입니다:
복수형 지옥
영어: "1 item" 대 "2 items"
폴란드어: "1 przedmiot" / "2 przedmioty" / "5 przedmiotów" (3개의 복수형)
아랍어: 6개의 복수형
count === 1 ? 'item' : 'items' 논리가 더 이상 작동하지 않습니다.
날짜/시간 혼돈
toLocaleDateString()로 날짜를 포맷했습니다. 그러자 일본의 사용자들은 CSV 내보내기에서 "2025년 2월 9일"을 보았고 Excel이 작동을 멈췄습니다.
API 언어 불일치
프런트엔드는 프랑스어를 요청합니다. 인증 토큰에 로케일이 포함되어 있지 않기 때문에 API는 영어를 반환합니다. 이제 혼합 언어 UI가 생기고 사용자들은 이것이 버그라고 생각합니다.
의사 로케일 테스트
생산으로 가기 전에 [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30%]으로 테스트하지 않았습니다. 이제 귀하의 폴란드어 사이트는 사용할 수 없습니다.
보이지 않는 가정
문자열만이 번역이 필요한 유일한 것이라고 가정했습니다. 그러다가 날짜, 숫자, 통화, 정렬, 검색—모든 것이 로케일별 동작을 가지고 있다는 것을 알게 되었습니다.
제가 도와드릴 수 있는 것:
- ICU MessageFormat 구현 (복수형, 성별, 맥락을 다룹니다)
- API i18n 패턴 (언어 협상, 대체 전략)
- 번역 에이전시보다 먼저 이러한 문제들을 잡아내는 QA 프로세스입니다.
워크플로우가 어려운 부분입니다
매일 배포할 때 8개 언어를 어떻게 동기화를 유지하나요?
기술은 파악했습니다. 이제 프로세스에서 막혔습니다:
개발자들이 새로운 영어 문자열과 함께 코드를 병합합니다. 번역은 2주 지연됩니다. 사용자들은 반만 번역된 UI를 봅니다.
어떤 문자열을 안전하게 삭제할 수 있는지 알지 못합니다 (사용되고 있습니까? 번역되었습니까? 에이전시와 진행 중입니까?)
제품 팀은 문구를 업데이트하고 싶어 합니다. "Submit"을 "Send"로 변경하는 것이 12개 언어를 깨뜨릴지 아무도 모릅니다.
번역 파일들이 한 번에 몇 주 동안 프로덕션과 동기화되지 않은 상태로 있습니다
팀들이 저에게 묻는 질문:
제가 본 문제들:
- 프로덕션 문자열과 다른 Git에 체크인된 번역 파일들
- '스페인어 파일을 건드리지 마세요' 경고는 아무도 무엇을 변경하는 것이 안전한지 알지 못하기 때문입니다
- 기능이 영어로 출시된 다음, 6개월 후에 (만약 번역된다면) 번역됩니다
제가 도와드릴 수 있는 것:
- 번역 파이프라인 디자인 (언제 i18n 라이브러리를 사용해야 하는지, 언제 TMS를 사용해야 하는지, 언제 AI를 사용해야 하는지)
- 원본 문자열과 번역을 동기화된 상태로 유지하기 위한 Git 워크플로우
- 새 문자열이 번역으로 표시되지 않은 경우 PR을 차단하는 자동화
기술은 해결할 수 있습니다. 워크플로우가 방해 요소입니다. 저는 유지보수에 영웅적인 노력이 필요하지 않은 워크플로우를 디자인합니다.
제가 함께 일했던 팀들
글로벌 제품, 지역 전문 지식
LINE (일본, 대만, 태국)
3개의 주요 동아시아 시장에서 운영되는 메시징 플랫폼입니다. CJK 문자 처리, 플랫폼 생태계 통합, 그리고 일본, 대만, 태국에서 다른 사용자 경험 기대치와 관련된 도전 과제를 작업했습니다.
카카오톡 (대한민국)
한국의 지배적인 메시징 플랫폼입니다. UI의 언어 격식 기대치 및 플랫폼 통합 필요사항을 포함한 한국 시장 특정 제품 요구사항을 해결했습니다.
Change.org (196개 국가, 20개 이상의 우선 언어)
콘텐츠 속도와 품질 모두 중요한 글로벌 청원 플랫폼입니다. 다양한 시장에 걸쳐 사용자 생성 정치/사회 콘텐츠에 대한 번역 워크플로우를 탐색하도록 도왔습니다.
에어비앤비 (220개 이상의 국가, 60개 이상의 언어)
복잡한 i18n 요구사항을 가진 글로벌 마켓플레이스입니다. 여러 언어에서 신뢰/안전과 관련된 도전 과제 및 시장 전반에 걸친 플랫폼 개념의 문화적 적응에 대해 자문했습니다.
Intercom (30개 이상의 언어, 글로벌 B2B SaaS)
글로벌 기업 고객에게 제공하는 고객 커뮤니케이션 플랫폼입니다. 실시간 지원 도구 및 지식 기반 현지화를 위한 제품 국제화를 작업했습니다.
릴리스 게임즈 (중국, 일본, 한국, 미국, EU)
전 세계적으로 타이틀을 배포하는 모바일 게임 퍼블리셔입니다. 내용 현지화 및 지역 플랫폼 요구사항과 관련된 시장별 도전 과제를 해결했습니다.
제가 출시한 시장:
동아시아 (일본, 한국, 중국):
CJK 타이포그래피, 플랫폼 생태계 통합, 세로 텍스트 지원
동남아시아 (태국, 베트남, 인도네시아):
다중 스크립트 지원, 모바일 우선 사용자 기대치
MENA (아랍어 사용 지역):
RTL 레이아웃 요구사항, 격식체 대 구어체 언어 기대치, 문화적 콘텐츠 적응
유럽:
24개 공식 언어, 다국가 제품 출시
아메리카:
지역별 언어 변형 (라틴 아메리카 스페인어 대 스페인어, 브라질 포르투갈어), 이중 언어 시장
저는 이 시장에서 무엇이 성공하고 무엇이 실패하는지 보았습니다—이론에서가 아니라, 실제 사용자들이 의존하는 제품을 출시하면서 말입니다.
깨지는 것을 고칩시다
i18n이 왜 중요한지에 대한 강의는 필요하지 않습니다. 2 AM에 RTL 팝오버를 디버깅하고, 문자 예산에 대해 제품팀과 논쟁했으며, 실제로 작업하는 번역 파이프라인을 설계한 사람이 필요합니다.
아키텍처 및 전략 검토 (1-2주):
다음 3개의 언어를 추가할 때 무엇이 깨질지, 그리고 수정하는 데 드는 비용이 얼마인지 알려드립니다
시장 출시 지원 (4-8주):
일본 / MENA / EU에서 출시하시려는군요. 이전에 경험이 있는 전문가가 필요하실 겁니다.
진행 중인 파트너십:
2개의 언어에서 20개의 언어로 확장함에 따라 임베디드 컨설팅
저는 이론가가 아닙니다. 분류하고, 로드맵을 짜고, 출시합니다.