작은 지역과 특수 코드: 두 자리 코드가 없는 지역

작은 지역과 특수 코드는 목록을 만들다 보면 반드시 걸리는 자리입니다. 인구가 적고 거래가 드물어서 먼저 눈에 띄지 않지만, 실제 주문이 한 건 들어오는 순간 목록의 빈틈이 드러납니다. 이 글은 그 경계를 어떻게 정할지 다룹니다.

작은 지역은 왜 국가 목록에 잘 들어가지 않나요?

첫째 이유는 목록마다 포함 기준이 다르기 때문입니다. 어떤 목록은 독립국만 담고, 어떤 목록은 자치 지역까지 담고, 어떤 목록은 통계 단위로 묶습니다. 같은 지역이 한 목록에는 있고 다른 목록에는 없습니다.

둘째는 값의 생김새가 다르기 때문입니다. 우편 체계가 본토를 따르기도 하고, 아예 없기도 하며, 자체 체계를 두기도 합니다. 하위 행정구역의 이름과 층위도 다릅니다. 큰 국가를 기준으로 만든 검증 규칙은 이런 지역에서 곧바로 어긋납니다.

셋째는 사용자가 부르는 이름이 여러 개이기 때문입니다. 공식 명칭, 널리 쓰이는 통칭, 본토에서 부르는 이름이 서로 다릅니다. 어느 하나를 정규명으로 정해 두지 않으면 검색과 표시가 계속 흔들립니다.

두 자리 코드가 없는 지역은 어떻게 적나요?

두 자리 코드가 없더라도 값은 저장되어야 합니다. 코드가 없으면 이름을 키로 쓰게 되고, 이름은 표기가 바뀌기 때문에 키로 쓰기에 적합하지 않습니다. 그래서 코드가 없을 때 쓸 자체 식별자를 정해 두는 편이 안전합니다.

자체 식별자는 공식 코드와 구분되어야 합니다. 같은 형식을 쓰면 나중에 공식 코드와 섞여 어느 쪽이 표준인지 알 수 없게 됩니다. 접두어를 붙이거나 자릿수를 다르게 하는 식으로 구분선을 만듭니다.

이 식별자는 외부로 내보낼 때 문제가 됩니다. 상대 시스템은 우리 목록에 없는 코드를 받습니다. 그래서 내보내기와 받기 양쪽에서 이 값들을 어떻게 다룰지 미리 정해 두어야 합니다.

코드가 있어도 사용자가 다르게 입력하면 어떻게 하나요?

코드는 정해져 있는데 사용자가 다른 표기를 입력하는 일이 흔합니다. 이때 코드를 먼저 찾고, 못 찾으면 이름과 별칭으로 넘어가는 순서가 안전합니다. 코드가 명확한 입력을 이름 검색으로 처리하면 엉뚱한 항목이 잡힐 수 있습니다.

반대로 코드처럼 보이지만 코드가 아닌 입력도 있습니다. 짧은 글자 조합이 우연히 코드와 겹치는 경우입니다. 이때는 자동으로 확정하지 말고 후보로 보여 주는 편이 안전합니다.

입력이 코드인지 이름인지 판단하는 기준은 길이만이 아닙니다. 값의 자리와 주변 항목도 함께 봅니다. 판단 기준을 문서로 남겨 두면 담당자가 바뀌어도 같은 결과가 나옵니다.

속령과 자치 지역은 본토와 같이 보나요?

같이 볼지 따로 볼지는 목적이 정합니다. 배송 경로와 세금은 따로 보는 편이 맞고, 통계나 언어 분포는 본토와 묶어 보는 편이 자연스럽습니다. 어느 쪽이 옳은지가 아니라, 무엇을 하려는지가 답을 정합니다.

문제는 이 판단을 한 곳에 몰아넣을 때 생깁니다. 한 항목에 본토 소속과 별도 취급을 함께 담으면, 화면마다 다르게 읽히고 검증마다 다르게 처리됩니다. 관계를 담는 항목과 취급 방식을 담는 항목을 나누면 이 혼동이 줄어듭니다.

이 관계는 국가 코드와 하위 행정구역 코드에서 다루는 층위 구분과도 이어집니다. 코드의 층위를 먼저 정리해 두면 속령 문제가 훨씬 단순해집니다.

작은 지역을 빼면 무엇이 깨지나요?

목록에서 빼면 그 지역의 사용자는 자기 나라를 고를 수 없습니다. 남의 나라를 고르거나, 목록 밖 입력을 시도하거나, 아예 이탈합니다. 어느 쪽이든 데이터에는 틀린 값이 남습니다.

더 큰 문제는 조용하다는 점입니다. 큰 지역의 주문만 보면 목록은 잘 동작하는 것처럼 보입니다. 그래서 목록에서 뺀 결정을 기록해 두지 않으면, 나중에 누가 왜 빠졌는지 알 수 없고 다시 넣을지도 판단할 수 없습니다.

작은 지역을 다루는 비용은 대부분 검증 규칙을 새로 만드는 데서 생깁니다. 규칙을 지역별로 나눠 두면 이 비용이 줄어듭니다. 국가별 예외를 한 함수 안에 몰아 두면 지역을 하나 더할 때마다 그 함수가 길어집니다.

코드가 서로 어긋날 때는 무엇을 먼저 보나요?

같은 지역을 가리키는 값이 여러 개 있고 서로 맞지 않는 경우가 있습니다. 이때는 어느 값이 더 정확한지를 따지기보다, 두 값이 서로 다른 층위를 가리키고 있지 않은지 먼저 확인합니다. 본토 소속을 나타내는 값과 실제 배송지를 나타내는 값은 원래 다를 수 있습니다.

층위가 같은데도 값이 다르다면 그때는 하나를 고르고 이유를 남깁니다. 고른 근거를 적어 두지 않으면 담당자가 바뀔 때마다 같은 다툼이 반복됩니다. 값이 다른 상태를 그대로 두는 것도 방법이지만, 그 경우에는 화면에서 무엇을 보여 줄지도 함께 정해 두어야 합니다.

작은 지역은 이런 불일치가 특히 자주 생깁니다. 목록이 여러 곳에서 오고, 각 목록이 서로 다른 기준으로 지역을 나누기 때문입니다. 그래서 목록을 합칠 때는 값의 개수보다 층위가 맞는지를 먼저 봅니다.

개발자를 위한 메모: 예외를 목록이 아니라 규칙에 적어라

• 작은 지역을 코드에 직접 박아 넣지 않습니다. 목록이 데이터에 있으면 지역을 하나 더할 때 배포가 필요 없습니다.
• 자체 식별자는 공식 코드와 형식이 겹치지 않게 만듭니다. 겹치면 나중에 어느 쪽이 표준인지 구분할 수 없습니다.
• 본토와의 관계를 담는 항목을 따로 둡니다. 소속과 취급 방식을 한 값에 섞으면 화면마다 다르게 해석됩니다.
• 목록 밖 입력을 받는 경로를 만들어 둡니다. 막기만 하면 사용자는 우회하고, 우회한 값은 검증 없이 들어옵니다.
• 목록에서 뺀 지역과 이유를 기록합니다. 이유 없는 제외는 다음 사람이 다시 넣거나 영영 잊습니다.

다음 단계

지금 국가 목록의 항목 수와, 그 목록을 만든 기준 문서의 항목 수를 비교해 보세요. 차이가 있다면 그 차이가 곧 제외된 지역입니다. 국경을 넘는 화면에서 이 지역들이 어떻게 다뤄지는지는 국경을 넘는 주소 시나리오에서, 목록에 무엇을 넣을지에 대한 기준은 국가 선정 기준에서 이어집니다. 이름과 코드를 확인할 때는 국가와 지역 디렉터리를 기준으로 삼습니다.

이 글의 지역 예시와 코드 예는 경계 문제를 설명하려고 지어낸 합성 데이터이며, 어떤 나라의 실제 행정 체계나 실제 코드 목록을 옮긴 것이 아닙니다.