국가와 언어의 차이: 현지화 세 계층과 테스트 조합

국가와 언어의 차이는 목록을 하나 줄이려는 순간부터 문제가 됩니다. 한 국가에 여러 공용어가 있고, 한 언어를 여러 국가가 함께 쓰기 때문에 이 둘은 어느 쪽으로도 서로를 대신하지 못합니다. 이 글은 두 축을 나눠 두는 방법과, 나눈 뒤의 조합을 어떻게 줄일지 다룹니다.

국가에서 언어를 알 수 없고 언어에서 국가를 알 수 없는 이유는 무엇인가요?

한 국가가 공용어를 여러 개 두는 경우가 흔하고, 같은 언어를 여러 국가가 공용어로 쓰는 경우도 흔합니다. 그래서 둘 사이에는 일대일 대응이 없습니다. 한쪽에서 다른 쪽을 계산하려는 순간, 목록 어딘가에 반드시 예외가 생깁니다.

이 관계를 표로 그려 보면 교차형이 됩니다. 국가 축에는 몇 개의 값이, 언어 축에는 또 다른 몇 개의 값이 있고, 두 축이 만나는 자리마다 조합이 하나씩 생깁니다. 이 가운데 실제로 쓰이는 조합은 일부지만, 어느 조합이 쓰이는지는 문화가 아니라 그 나라의 제도가 정합니다.

그래서 언어 목록과 국가 목록은 서로 다른 근거에서 관리하는 편이 맞습니다. 한쪽을 다른 쪽의 부분집합으로 두면, 나중에 국가를 하나 추가할 때 언어 목록에 없는 값이 들어오면서 구조가 무너집니다.

현지화는 어떤 계층으로 나뉘나요?

현지화는 적어도 세 계층으로 나눠 보는 편이 좋습니다.

• 화면 언어: 사용자에게 보이는 문구의 언어입니다. 같은 국가에서도 사용자가 다른 언어를 고를 수 있습니다.
• 콘텐츠 지역: 무엇을 보여 줄지에 대한 판단입니다. 같은 언어를 쓰는 여러 국가에 같은 내용을 보여 줄 수도, 다른 내용을 보여 줄 수도 있습니다.
• 값의 형식: 날짜, 숫자, 이름 순서, 주소 순서처럼 값이 어떤 모양으로 표현되는지입니다.

세 계층은 서로 다른 값을 가질 수 있습니다. 화면은 어떤 언어로 띄우면서 값의 형식은 다른 지역의 관례를 따르는 조합이 실제로 존재합니다. 이 조합을 허용하지 않으면 사용자는 화면 언어를 바꾸는 대신 값의 의미를 잃게 됩니다.

세 계층을 한 값으로 묶으면 편해 보이지만, 묶는 순간 세 계층이 함께 움직입니다. 화면 문구 하나를 고치려다 저장된 날짜의 표시 형식까지 바뀌는 식입니다.

언어 표기와 지역 코드는 역할이 어떻게 다른가요?

언어 표기는 텍스트가 어떤 언어로 쓰였는지를 나타냅니다. 지역 코드는 값이 어느 제도의 관례를 따르는지를 나타냅니다. 하나는 읽는 사람을 위한 정보이고, 다른 하나는 값을 해석하기 위한 기준입니다.

이 둘을 바꿔 쓰면 조용한 오류가 생깁니다. 값의 형식을 언어 표기로 정하면, 같은 언어를 쓰는 다른 국가의 값이 같은 규칙으로 처리됩니다. 두 지역의 규칙이 같다면 아무 문제가 없지만, 다르다면 정상 값이 오류로 판정됩니다.

표에서 보듯 값의 형식은 맨 아래 층에 있고, 다른 두 층과 독립적으로 정해집니다. 이 순서를 뒤집어 언어를 기준으로 삼으면 위의 두 층까지 흔들립니다.

언어를 보고 형식을 짐작하면 어떤 문제가 생기나요?

가장 흔한 형태는 같은 언어를 쓰는 다른 국가의 값을 같은 규칙으로 검사하는 것입니다. 언어는 맞지만 지역이 다르기 때문에, 사용자는 자기가 맞게 적은 값을 계속 고치게 됩니다. 오류 문구는 친절해도 원인은 구조에 있습니다.

두 번째는 반대 방향의 실수입니다. 국가를 기준으로 화면 언어까지 정해 버리면, 그 국가 안에서 다른 언어를 쓰는 사용자가 자기 언어를 고를 수 없게 됩니다. 이때 사용자는 이해하지 못하는 화면을 보거나, 아예 서비스를 떠납니다.

세 번째는 값의 길이와 관련됩니다. 같은 언어라도 국가에 따라 문구와 이름의 길이가 달라집니다. 버튼과 표의 열 너비를 한 국가의 값에 맞춰 정해 두면, 다른 국가에서 잘리거나 줄바꿈이 깨집니다.

이런 실수는 검증 규칙만의 문제가 아닙니다. 이름과 텍스트가 언어에 따라 어떻게 달라지는지는 지역별 이름 데이터에서 따로 다루고, 이 글은 두 축을 분리해 두는 데까지만 다룹니다.

테스트 조합은 어떻게 줄이나요?

두 축을 모두 다 조합하면 금세 감당할 수 없게 됩니다. 그래서 국가 목록과 언어 목록을 각각 몇 개로 줄이고, 두 축을 교차해 조합을 만듭니다. 이때 두 축의 대표를 서로 맞출 필요는 없습니다.

• 국가 축은 값의 형식을 보기 위한 대표로 고릅니다. 문자 체계와 값의 길이, 항목의 유무가 갈리는 지점을 고릅니다.
• 언어 축은 텍스트를 보기 위한 대표로 고릅니다. 글자 폭과 문장 길이, 방향이 갈리는 지점을 고릅니다.
• 두 축을 곱해 만든 조합 가운데, 실제로 일어날 수 없는 짝은 빼고 나머지를 남깁니다.

이렇게 하면 국가 수와 언어 수를 더한 만큼만 확인하고도 두 축에서 생기는 문제를 대부분 만나게 됩니다. 조합을 다 채우는 것보다, 각 축의 끝을 한 번씩 지나가는 편이 남는 시간 대비 효율이 좋습니다.

국가 선택 항목 자체의 동작을 확인하는 방법은 국가 선택 필드 테스트에서 이어집니다.

개발자를 위한 메모: 형식은 지역을 따라가게 하라

• 값의 형식과 검증 기준은 지역 코드에서 가져옵니다. 화면 언어는 표시에만 쓰고 검증에는 쓰지 않습니다.
• 화면 언어와 값의 형식을 각각 따로 설정할 수 있게 둡니다. 한 값으로 묶으면 둘 중 하나를 포기해야 합니다.
• 사용자가 고른 언어를 저장하더라도, 값의 기준이 되는 지역은 별도로 남깁니다. 나중에 화면 언어만 바꿔도 값의 의미가 유지되어야 합니다.
• 언어 목록과 국가 목록을 서로의 부분집합으로 두지 않습니다. 한쪽을 늘릴 때 다른 쪽에 없는 값이 들어와도 구조가 버텨야 합니다.
• 값 하나가 어느 축에서 왔는지 로그로 남깁니다. 문제가 생겼을 때 언어 때문인지 지역 때문인지 구분할 수 있습니다.

다음 단계

지금 화면에서 사용자 언어를 고르는 자리와 값의 형식을 정하는 자리가 같은 값인지 확인해 보세요. 같다면 두 축이 아직 분리되지 않은 것입니다. 국가 축의 대표를 어떻게 고를지는 국가 선정 기준에서, 국가를 여러 묶음으로 나누는 일은 지역 그룹과 시장 등급에서 이어집니다. 사용자가 고른 언어를 바꿨을 때 화면이 어떻게 반응하는지는 국가 선택 필드 테스트와 함께 보면 좋습니다. 지역별 실제 목록은 국가와 지역 디렉터리에서 확인할 수 있습니다.

이 글의 조합표와 언어·지역 짝은 두 축을 분리하는 방법을 보여 주려고 만든 합성 예시이며, 실제 사용자 분포나 실제 서비스 언어 구성을 반영하지 않습니다.