01.02 — 1월 2일인가요, 2월 1일인가요? 돈이 드는 현지화 함정

«01.02.2025»라는 날짜 표기는 한 나라에서는 2월 초를, 다른 나라에서는 1월 초를 뜻합니다. 인터넷 쇼핑몰이나 앱이 로케일을 고려하지 않고 이런 날짜를 보여 주면, 고객은 의도와 다르게 읽을 수 있습니다. 이런 사소한 부분은 기술 명세서에 잘 들어가지 않지만, 바로 이 때문에 반품, 기한 놓침, 어색한 고객 지원 답변이 생깁니다. 현지화에서 가장 흔한 함정을 살펴보고, 이를 피하는 방법을 알아보겠습니다.

날짜와 시간: 같은 날, 세 가지 읽기

날짜 구성 요소의 순서는 나라마다 다릅니다. 러시아, 독일, 그리고 유럽 대부분에서는 '일.월.년' 형식을 씁니다. 미국에서는 월이 먼저 오므로 «03/04/2025»는 4월 3일이 아니라 3월 4일을 뜻합니다. 일본, 중국, 한국에서는 순서가 반대로, 연도가 먼저 오고 그다음 월과 일이 옵니다.

시간도 마찬가지입니다. 러시아, 유럽 대부분, 라틴 아메리카에서는 24시간제가 익숙하고, 미국, 캐나다, 호주, 인도에서는 AM과 PM 표시를 붙이는 12시간제가 널리 쓰입니다. 표시 없는 «5:00»은 나라마다 다르게 읽히며, '다섯 시' 약속이 계획된 시간과 열두 시간 차이가 날 수도 있습니다.

추측하지 않으려면 데이터와 API에서는 국제 표준 ISO 8601(예: 2025-02-01T14:30)을 사용하는 것이 좋습니다. 인터페이스에 날짜를 표시할 때는 직접 입력하지 말고 로케일 기능으로 출력하세요.

숫자 구분 기호: 점이 있어야 할 자리에 쉼표

«1 500,75»(러시아식)와 «1,500.75»(미국식)는 같은 값입니다. 독일과 브라질에서는 천 단위를 점으로 구분하고 소수점은 쉼표로 씁니다: «1.500,75». 스위스에서는 아포스트로피를 씁니다: «1'500.75». 인도에서는 자릿수 묶음이 달라서 «1,00,000»은 십만을 뜻합니다.

이 오류는 특히 눈에 띄지 않습니다. 가격 «1.500»을 천오백으로 의도했는데 시스템이 1.5로 읽었다면, 고객은 결제 단계에서야 차이를 알아차립니다. 그래서 코드에서 숫자가 든 문자열을 손으로 이어 붙이지 말고, 로케일에 맞는 형식 지정을 사용하며, 파일을 가져올 때 숫자 해석을 반드시 검사하세요.

통화: 기호, 위치, 반올림

통화 기호는 사소해 보이지만 쉽게 혼동을 일으킵니다. «$» 기호는 미국, 캐나다, 호주 등 여러 나라에서 쓰이므로, 통화 코드가 없으면 어느 나라의 달러인지 알 수 없습니다. 그래서 국제적인 맥락에서는 ISO 4217에 따른 세 글자 코드(USD, EUR, RUB)를 표기하는 것이 일반적입니다.

기호의 위치도 다릅니다. 영어권 나라에서는 «$100», 프랑스에서는 줄바꿈 없는 공백을 넣어 «100 €», 러시아에서는 «100 ₽» 또는 «100 руб.»로 씁니다. 번역 과정에서도 문제가 생길 수 있습니다. '가격에 부가세 포함'이라는 문장은 어떤 언어에서는 다른 구조를 요구하므로, 금액을 끼워 넣은 조각으로 문장을 조립하면 어순이 무너집니다.

반올림도 통화에 따라 다릅니다. 일본 엔은 보통 소수점 자릿수가 없고, 쿠웨이트 디나르는 천분의 일 단위로 나뉩니다. 시스템이 모든 통화에 소수점 두 자리를 적용하면, 계산 결과가 은행 명세서와 몇 전(센트) 차이 날 수 있고, 거래 규모가 크면 그 차이도 무시할 수 없게 됩니다.

미터법과 야드파운드법

세계 대부분은 미터법을 쓰지만, 미국은 피트, 파운드, 갤런, 화씨 온도를 사용합니다. 영국에서는 도로 표지판에 마일을 쓰고 우유는 파인트 단위로 팔며, 그 파인트는 미국 파인트보다 큽니다. 약 568밀리리터 대 약 473밀리리터입니다. 갤런도 대서양 양쪽에서 다릅니다.

인터넷 쇼핑몰에서는 상품 치수, 택배 무게, 포장 부피를 구매자에게 익숙한 단위로 보여 주되 정확성을 잃지 않아야 합니다. 설명서를 번역하는 번역가는 단위를 번역해야 할지, 값을 환산해야 할지 판단할 수 있어야 합니다. 예를 들어 설명서에 «10 дюймов»(10인치)라고 되어 있다면, 러시아어판에서는 «25 см»(25cm)로 옮기는 것이 합리적입니다. 다만 기술 사양에서 원래 수치가 중요하다면 괄호 안에 원래 값을 남기는 편이 좋습니다.

폼의 전화번호, 주소, 이름

등록 양식은 대개 세 가지 필드에서 문제가 생깁니다. 전화번호의 경우, 러시아에서는 «+7 (999) 123-45-67»처럼 쓰고, 독일은 번호 길이가 일정하지 않은데 고정 마스크를 쓰는 템플릿은 많은 번호를 거부합니다. 국가 코드를 고르는 선택 상자와 번호 검증 라이브러리를 함께 사용하는 것이 낫습니다.

주소의 경우, 일본은 큰 단위에서 작은 단위로(도도부현, 시, 구, 번지 순) 적고, 러시아와 유럽은 반대로 적습니다. 미국의 우편번호는 숫자 다섯 자리이고, 영국은 문자와 숫자가 섞인 조합입니다. '숫자만 입력' 필드는 실제로 존재하는 많은 주소를 걸러 냅니다.

이름과 성의 경우, 스페인과 라틴 아메리카에서는 성이 두 개인 경우가 흔하고, 아이슬란드에서는 성 대신 부칭을 쓰며, 이름이 하나뿐인 사람도 있습니다. «O'Brien» 같은 성의 아포스트로피나 하이픈 때문에 오류가 나서는 안 됩니다. 최소 요구 사항은 간단합니다. 필요하지 않은 곳에서 두 개의 필드를 필수로 만들지 말고, 모든 유니코드 문자를 받아들이세요.

오류를 피하는 방법: 표준과 검증

형식 관리는 검증 단계가 아니라 설계 단계에서 시작됩니다. 다음이 도움이 됩니다.

날짜는 ISO 8601로, 숫자는 형식 없이, 통화는 ISO 4217 코드와 함께 저장하고, 출력은 로케일에 맡기세요.
직접 만든 템플릿 대신 ICU나 플랫폼에 내장된 표준 현지화 라이브러리를 사용하세요.
번역가에게 맥락을 전달하세요. 텍스트만이 아니라 단위, 통화, 날짜의 종류가 문장 안에서 분명해야 합니다.
01.02, 12:00, 1 000,50 같은 값으로 여러 로케일에서 인터페이스를 테스트하세요. 특히 순서가 다른 로케일을 포함하세요.
최종 검수에는 원어민을 참여시키세요. 그들은 장소에서 쓰지 않는 표현, 예를 들어 '오후 다섯 시'를 '17.00'으로 적은 부분을 더 빨리 알아챕니다.

핵심은 간단합니다. 형식도 의미의 일부입니다. 좋은 번역은 단어만이 아니라 독자가 날짜, 가격, 거리를 어떻게 이해할지까지 보존합니다. 현지화를 미리 계획에 넣으면 이런 함정은 거의 비용 없이 피할 수 있습니다. 출시 후에 발견하면, 수정 비용이 다른 모든 것보다 많이 듭니다.

함께 읽어 보세요:

전문 번역이 필요하신가요? 온라인으로 주문하세요: 언어를 선택하고 파일을 업로드하면 몇 분 안에 비용을 확인할 수 있습니다.

최신 뉴스