i18n 기술 부채의 숨겨진 비용

엔지니어들이 느린 것이 아닙니다. 제품이 너무 복잡한 것도 아닙니다. 새로운 시장으로의 확장에 로케일당 6개월이 걸리는 이유는, 3년 전 누군가가 "Welcome back, {name}!"을 JSX에 하드코딩했기 때문입니다 — 그리고 수천 명의 다른 개발자들이 같은 방식을 따랐기 때문입니다.

모든 엔지니어링 팀은 기술 부채를 추적합니다. 코드 복잡성 지표, 의존성 업데이트 백로그, 테스트 커버리지 격차. 아마도 팀의 SonarQube 점수를 외우고 있을 것입니다.

그러나 대부분의 CTO에게 i18n 부채에 대해 물어보면 멍한 표정을 받게 됩니다. 추적되지 않습니다. 측정되지 않습니다. 어떤 대시보드에도 없습니다. 그리고 기술 부채 스프레드시트의 대부분의 항목보다 팀에 더 많은 비용을 조용히 초래하고 있습니다.

이 글은 그 비용에 숫자를 붙입니다. 가상의 숫자가 아니라 — 오후 한나절 만에 자신의 코드베이스에서 계산할 수 있는 숫자들입니다.

i18n 기술 부채가 실제로 어떤 모습인가

기술 부채는 명확한 정의가 있습니다: 지금 편리한 해결책을 선택함으로써 발생하는 미래 재작업의 암묵적 비용. i18n에서 그 편리한 해결책은 거의 항상 같습니다: 번역 인프라를 건너뛰고, 문자열을 하드코딩하고, "나중에 국제화하겠다"고 합니다.

명백한 부채: 하드코딩된 문자열

JSX의 모든 <p>Submit</p>은 번역되기 전에 수동으로 추출해야 할 문자열입니다. 모든 alert('Are you sure?')은 번역 시스템 외부에 있는 사용자 대면 메시지입니다.

i18n을 처음부터 고려하지 않고 구축된 50,000줄짜리 React 코드베이스에서 문자열 추출 도구를 실행해 보세요. 일반적으로 3,000~8,000개의 하드코딩된 번역 가능 문자열을 발견하게 됩니다. 각각은 다음이 필요합니다:

1. 식별 (사용자 대면인가?)
2. 번역 키로 추출
3. t() 호출로 감싸기
4. 번역 파일에 추가
5. 각 대상 로케일로 번역
6. 레이아웃 및 잘림 테스트

전체 추출 주기에 문자열당 1015분으로, 5,000개 문자열은 **8001,250 엔지니어링 시간**입니다. 그것은 개발자 한 명의 5~8개월 시간입니다. 코드가 작성될 때 외부화하는 것은 무료였던 문자열들에 대해서요.

보이지 않는 부채: 구조적 문제

하드코딩된 문자열은 명백한 부채입니다. 구조적 문제는 더 악화되는데 복합적으로 작용하기 때문입니다:

키 구조 없음. 키는 "submit_button" 및 "submit_button_2"와 같은 평면 문자열입니다. 계층 구조도, namespace 규칙도, 기능 영역별로 일괄 번역하는 방법도 없습니다. 결제 흐름을 번역해야 할 때 결제 관련 키를 필터링할 수 없습니다. 분류 체계가 없기 때문입니다.

문자열 컨텍스트 없음. 번역가는 "Total"을 보고 추측해야 합니다: 테이블 헤더인가, 버튼 레이블인가, 인보이스 항목인가? 독일어에서는 세 가지가 다른 단어입니다. 각 키에 컨텍스트 메타데이터가 없으면 번역가는 15~25%의 확률로 잘못 추측합니다.

번역 메모리 없음. "Are you sure you want to delete this?"라는 문구가 앱 전체에 12번 나타납니다. 번역 메모리 없이는 12번 따로 번역됩니다 — 잠재적으로 다른 번역가에 의해 12가지 다른 방식으로.

자동화 없음. 번역 업데이트는 개발자가 수동으로 JSON을 내보내고, 번역가에게 이메일로 보내고, 파일을 다시 받기를 기다리고, 수동으로 가져오고, PR을 만드는 과정을 포함합니다. 각 왕복에는 3~5 영업일이 소요됩니다.

조직적 부채

i18n 부채의 가장 교활한 형태는 코드에 있지 않습니다. 조직도에 있습니다.

소유권 격차. 엔지니어링은 번역을 소유하지 않습니다 — "그것은 콘텐츠 팀 일입니다." 마케팅은 기술 시스템을 이해하지 못합니다. 제품 관리자는 번역 커버리지를 지표로 추적하지 않습니다. 아무도 그 격차를 소유하지 않습니다.

번역 업데이트에 대한 SLA 없음. 새 기능이 영어로 출시되고 누군가 번역을 시작하기 전까지 2~4주 동안 영어 전용으로 유지됩니다. 국제 사용자는 모든 릴리스 후 몇 주 동안 절반만 번역된 인터페이스를 봅니다 — 독일어 레이블과 영어 버튼이 혼재합니다.

복합적 무지. 팀에 합류하는 모든 새 엔지니어는 자신이 보는 패턴을 복사합니다. 코드베이스에 하드코딩된 문자열이 있으면 그들도 문자열을 하드코딩합니다. 부채는 헤드카운트에 비례해 선형적으로 증가합니다.

지불하고 있는 비용을 정량화하는 방법

i18n 부채는 측정 가능합니다. 비용 범주와 계산 방법은 다음과 같습니다.

엔지니어링 시간 세금

Stripe의 2023년 엔지니어링 조사에 따르면 개발자들은 기술 부채 작업에 **시간의 23%**를 소비합니다. McKinsey는 IT 예산의 20~40%가 새로운 가치 창출 전에 부채 유지 관리에 들어간다고 추정합니다.

i18n에 특화하여 한 스프린트 동안 이것들을 추적하세요:

문자열 추출 시간. 개발자들이 하드코딩된 문자열을 t() 호출로 감싸는 데 몇 시간을 소비했나요? i18n을 소급 적용하는 대부분의 회사에서 마이그레이션 중 스프린트당 개발자당 4~8시간입니다.

병합 충돌 해결. 번역이 저장소의 JSON 파일로 존재한다면 로케일 파일과 관련된 병합 충돌이 몇 건 발생했나요? 각 충돌은 해결하는 데 1530분이 걸립니다 (JSON 구문 재검증, 키 순서 재확인, 번역 CI 재실행). 개발자 6명이 있으면 스프린트당 12건을 예상합니다: 30~60분.

컨텍스트 전환 비용. 개발자가 번역가에게 UI 컨텍스트를 설명하는 Slack 스레드가 몇 개나 있었나요? 각 스레드는 개발자에게 15분의 컨텍스트 전환입니다: 스프린트당 1~2시간.

배포 오버헤드. 번역 전용 변경으로 트리거되는 배포의 비율은 얼마나 되나요? 번역이 저장소에 있으면 모든 카피 수정이 전체 CI/CD 파이프라인을 트리거합니다. 한 달 동안 추적해 보세요. 보통 전체 배포의 15~25%입니다.

릴리스 지연 승수

여기서 수학이 불편해집니다.

제품에 5개의 대상 로케일이 있습니다. 각 로케일은 기능의 새 문자열을 번역하는 데 평균 2주가 걸립니다 (수동 내보내기 → 번역 → 가져오기 → QA 주기를 고려). 연간 12개 기능을 출시합니다.

5개 로케일 × 2주 지연 × 12번 릴리스 = 120 로케일-주의 지연된 가용성.

그것은 국제 사용자들이 불완전한 제품을 보는 120주입니다. 국제 수익이 40%인 SaaS 제품의 경우, 사용자 기반의 40%가 모든 릴리스 후 2주 동안 저하된 제품을 경험하는 것입니다.

복합 효과는 가혹합니다. 각 기능이 새 문자열을 추가합니다. 다음 릴리스가 출시될 때 이전 기능의 번역이 완료되지 않으면 번역가들은 이제 두 개의 백로그에서 동시에 작업합니다. 지연이 증가합니다. 품질이 떨어집니다. 팀은 지름길을 택하기 시작합니다 — "영어로 그냥 출시하고 나중에 번역하겠다." 부채가 증가합니다.

시장 기회 비용

CSA Research에 따르면 온라인 소비자의 87%가 영어 전용 웹사이트에서 구매하지 않습니다. 글로벌 소프트웨어 현지화 시장은 2025년에 62.7억 달러로 평가되며 12.4% CAGR로 성장하고 있습니다 (Meticulous Research).

3개월 먼저 프랑스어 번역을 출시한 경쟁자는 3개월 동안만 프랑스 사용자를 확보하는 것이 아닙니다. 구전 효과, 앱 스토어 리뷰, 프랑스어 검색 결과에서의 SEO 순위를 확보합니다. 3개월의 수익을 잃는 것이 아니라 — 전체 시장에서 선점 우위를 양보하는 것입니다.

$1,000만 ARR과 30% 국제 성장 잠재력을 가진 SaaS 제품의 경우, 새 로케일 출시에 3개월 지연은 로케일당 약 75만 달러의 이연 수익을 나타냅니다. 슬라이드에 올릴 가치가 있는 숫자입니다.

i18n 부채가 일반 기술 부채보다 빠르게 복리로 증가하는 이유

대부분의 기술 부채는 선형적입니다. 지저분한 함수는 그것을 건드리는 개발자들을 느리게 합니다. 오래된 의존성은 그것을 사용하는 서비스에 영향을 미칩니다. 피해 범위는 제한됩니다.

i18n 부채는 곱셈적입니다. 이유는 다음과 같습니다.

잘못된 아키텍처의 네트워크 효과

공유 컴포넌트에서 누락된 번역 키 하나는 모든 로케일의 한 페이지를 망가뜨립니다. 잘못 번역된 용어 하나가 그것을 사용하는 모든 화면에 전파됩니다. 잘못 구조화된 namespace 하나는 모든 새 키를 만드는 데 더 오래 걸리게 합니다.

곱셈 계수는: 영향받는 문자열 수 × 로케일 수 × 로케일당 사용자 수입니다.

단일 아키텍처 결정 — "namespace 없이 평면 키를 사용하자" — 는 수천 개의 문자열, 수십 개의 로케일, 번역 코드를 건드리는 모든 개발자에 걸쳐 마찰을 만듭니다.

채용 승수

새 엔지니어들은 기존 패턴을 복사합니다. 코드베이스에 500개의 하드코딩된 문자열이 있으면 신입 직원들도 문자열을 하드코딩합니다. i18n 시스템이 존재한다는 것을 모르기 때문입니다. 아무도 그들에게 온보딩을 하지 않았으니까요. 부채는 모든 채용과 함께 증가합니다.

상당한 기술 부채가 있는 엔지니어링 팀은 25~35% 높은 이직률을 보고합니다 (Haystack Analytics 2024). 이유: 개발자들은 문자열 추출과 병합 충돌 해결에 시간을 보내고 싶지 않습니다. 기능을 만들고 싶습니다. 코드베이스가 i18n 오버헤드로 인해 모든 기능이 30% 더 오래 걸린다면 최고의 엔지니어들은 그렇지 않은 코드베이스를 찾을 것입니다.

"확장 전에 수정하겠다" 함정

이것이 가장 흔한 의사결정 패턴이며 — 가장 비싼 것입니다:

1. 1년차: 제품이 영어로 출시됩니다. "확장 전에 i18n을 추가하겠다."
2. 2년차: 제품이 성장합니다. i18n은 계속 후순위로 밀립니다. 코드베이스에 5,000개의 하드코딩된 문자열이 쌓입니다.
3. 3년차: 영업팀이 독일에서 리드를 얻습니다. 리더십이 말합니다: "독일어로 얼마나 빨리 출시할 수 있나요?"
4. 엔지니어링 답변: "모든 문자열 추출, 번역 파이프라인 설정, 번역, QA에 6개월."
5. 리더십: "너무 느립니다. 가장 눈에 띄는 페이지만 수동으로 번역하세요."
6. 결과: 절반만 번역된 제품. 일관성 없는 품질. "진짜" i18n 마이그레이션은 계속 미뤄집니다.

3년차가 되면 적절한 국제화 비용은 "설정 2주"(1년차에 했다면)에서 "마이그레이션 6개월"(성숙한 코드베이스 소급 적용)로 증가했습니다. 기술 부채가 단순히 쌓인 것이 아니라 — 복리로 증가했습니다.

감사: i18n 부채 점수 찾기

한 스프린트 만에 i18n 부채를 정량화할 수 있습니다. 방법은 다음과 같습니다.

단계별 감사 프로세스

1. 추적되지 않은 번역 가능 문자열 수 세기.

코드베이스에서 AST 기반 문자열 추출 도구를 실행합니다:

# Better i18n CLI 사용
npx @better-i18n/cli scan

# 또는 i18next 프로젝트에 i18next-parser 사용
npx i18next-parser

출력은 번역 시스템 외부에 존재하는 사용자 대면 문자열의 수를 알려줍니다. 이것이 원시 추출 백로그입니다.

2. 번역 파일 구조 감사.

다음 질문에 답하세요:

• 키가 기능/컴포넌트별로 구성되어 있나요, 아니면 평면인가요?
• 가장 큰 단일 로케일 파일은 무엇인가요? (한 파일에 500개 이상의 키가 있으면 namespace 문제가 있습니다)
• 키에 컨텍스트 설명이 있나요?
• 용어집이 있나요?

3. 타입 안전성 확인.

# 가짜 키를 추가하고 빌드가 잡는지 확인
t('this.key.definitely.does.not.exist');

빌드가 통과하면 컴파일 타임 키 안전성이 없는 것입니다. 모든 키 참조는 런타임 도박입니다.

4. 번역 지연 측정.

"개발자가 새 문자열이 있는 PR을 병합"에서 "모든 로케일의 프로덕션에 번역이 라이브"까지의 시간을 추적합니다. 벤치마크:

• Green: 24시간 미만 (자동화된 파이프라인, CDN 전달)
• Yellow: 1~5일 (일부 자동화, 배치 처리)
• Red: 1주일 이상 (수동 워크플로우, 배포 연동)

부채 수준 점수 매기기

대부분 Green: i18n 인프라가 견고합니다. 최적화에 집중하세요. 대부분 Yellow: 부채가 쌓이고 있습니다. 로케일을 추가하기 전에 구조적 문제를 수정하세요. 대부분 Red: 멈추세요. 확장 전에 이것을 수정하세요. 비용은 여기서부터 올라갈 뿐입니다.

수익: i18n 부채 제거가 가져오는 것

엔지니어링 속도 회복

i18n 인프라가 견고할 때:

• 새 로케일 추가는 엔지니어링 프로젝트가 아닌 콘텐츠 작업이 됩니다. 2,000개의 번역된 영어 키가 있는 제품에 일본어 추가: 수개월(마이그레이션 시간)이 아닌 며칠(번역 시간).
• 번역 파일의 병합 충돌 제로. 키는 저장소의 JSON 파일이 아닌 플랫폼에 저장됩니다.
• 런타임 누락 키 버그 제로. TypeScript가 빌드 시간에 모든 오타를 잡습니다.
• 30초 번역 수정. 한 단어 수정이 배포 없이 CDN에 게시됩니다.

시장 출시 가속화

i18n 부채가 있는 팀과 없는 팀의 차이:

팀 사기

이것은 측정하기 어렵고 과소평가하기 쉽습니다. 번역 배관에 시간의 20%를 보내는 엔지니어들은 작업을 즐기지 않습니다. 컨텍스트 없이 작업하는 번역가들은 낮은 품질을 생산하고 더 빨리 번아웃됩니다.

인프라를 수정하면:

• 개발자들은 t('checkout.submit')을 작성하고 번역 물류에 대해 다시 생각하지 않습니다.
• 번역가들은 모든 문자열에 대한 UI 컨텍스트를 보고 첫 번째 시도에서 올바른 번역을 생산합니다.
• 제품 관리자들은 스프레드시트가 아닌 대시보드에서 번역 커버리지를 추적합니다.

90일 i18n 부채 상환 계획

1개월: 감사 및 측정 (코드 변경 없음)

• 문자열 추출 감사를 실행합니다. 숫자를 문서화합니다.
• 4개 스프린트 동안 번역 지연을 추적합니다. 평균을 문서화합니다.
• 로케일 파일과 관련된 병합 충돌 수를 셉니다. 빈도를 문서화합니다.
• 위의 공식을 사용해 비용을 계산합니다. 리더십에 숫자를 제시합니다.

이 달은 가시성에 관한 것입니다. 측정할 수 없는 것은 수정할 수 없습니다.

2개월: 출혈 멈추기

• PR에서 새로운 하드코딩된 문자열을 차단하는 ESLint 규칙을 추가합니다. 새 부채 없음.
• CI에 AST 스캔을 설정합니다. 모든 PR이 새/미사용 키를 보고합니다.
• 가장 많이 변경된 5개 파일을 올바른 i18n 키 구조로 마이그레이션합니다. 패턴이 작동함을 증명합니다.
• 가장 중요한 40개 도메인 용어로 용어집을 시작합니다.

이 달은 억제에 관한 것입니다. 마이그레이션을 계획하는 동안 새 부채 축적을 멈춥니다.

3개월: 가속화 및 자동화

• 코드베이스를 CDN 전달이 있는 번역 플랫폼에 연결합니다. 번역을 저장소에서 꺼냅니다.
• Tier 1 콘텐츠 (UI 문자열, 오류 메시지, 시스템 알림)에 AI 번역을 활성화합니다. 이것은 번역 볼륨의 60~70%를 자동으로 처리합니다.
• CI에 번역 커버리지 보고를 설정합니다. 모든 PR이 표시합니다: "이 변경 사항은 15개 로케일 중 12개에서 번역되었습니다."
• 추출 백로그를 시작합니다. 페이지 트래픽으로 우선순위를 정합니다: 트래픽이 가장 많은 페이지부터.

3개월 말에 다음을 확인해야 합니다:

• 코드베이스에 새로운 하드코딩된 문자열이 없음
• 새 문자열의 번역 지연이 24시간 미만
• 추출 백로그에 대한 명확한 번다운 차트
• 마이그레이션 지속을 정당화하는 비용 데이터

수학은 명확합니다

i18n 기술 부채는 측정할 때까지 보이지 않습니다. 그 다음에는 명백합니다.

처음부터 i18n 인프라를 설정하는 팀은 유지 관리에 주당 2시간을 소비합니다. 2년 성장 후 i18n을 소급 적용하는 팀은 마이그레이션에 6개월을 소비합니다 — 그리고 아키텍처가 역량이 아닌 제약을 중심으로 설계되었기 때문에 지속적인 유지 관리도 여전히 더 높습니다.

코드베이스에 1,000개 이상의 사용자 대면 문자열이 있고 2개 이상의 로케일을 제공하거나 제공 계획이 있다면 i18n 부채 수정의 ROI는 개월이 아닌 주 단위로 측정됩니다.

기다리는 매 스프린트마다 부채는 복리로 증가합니다.

Better i18n은 엔지니어링 팀에 i18n 부채 축적을 멈출 인프라를 제공합니다: AST 키 스캔, CDN 전달 번역, 타입 안전 SDK, 용어집 적용이 있는 AI 번역. 무료 티어에는 현재 부채를 감사하고 상환을 시작하는 데 필요한 모든 것이 포함됩니다. 10분 만에 시작하세요.