카드 번호나 사업자 번호 같은 값을 붙여넣었을 때 화면이 곧바로 판정을 내리는 것을 본 적이 있을 것입니다. 번호 검증의 원리를 알면 그 판정이 어디까지 믿을 수 있는지 스스로 가늠할 수 있습니다. 이 글에서는 검증을 문자 집합, 자릿수, 체크 디지트의 세 층으로 나눠 살펴보고, 왜 어떤 결과는 유효라고 말할 수 있고 어떤 결과는 형식만 확인했다고 말해야 하는지 구분합니다.
번호 검증이란 무엇인가요?
검증은 하나의 질문에 답하는 일이 아니라 여러 질문을 순서대로 던지는 일입니다. 첫째, 이 문자열에 허용된 문자만 들어 있는가. 둘째, 길이가 그 제도가 정한 범위 안에 있는가. 셋째, 마지막 자리가 앞의 자릿수로부터 계산한 값과 일치하는가. 세 질문은 서로 다른 오류를 잡아내므로, 하나를 통과했다고 나머지까지 통과했다고 말할 수 없습니다.
이 세 층이 모두 갖춰진 제도도 있고, 첫 두 층만 공개된 제도도 있습니다. 그래서 검증 도구는 어느 층까지 확인했는지를 결과에 함께 적어야 합니다. 통과라는 한 단어만 돌려주면 사용자는 세 층을 모두 확인한 것으로 읽습니다.
세 층이 각각 잡아내는 오류는 무엇인가요?
층마다 잡는 오류의 성격이 다릅니다. 문자 집합 검사는 숫자만 있어야 할 자리에 글자가 섞인 경우를 걸러냅니다. 자릿수 검사는 한 자리를 더 누르거나 덜 누른 경우, 그리고 서로 다른 제도의 번호가 뒤섞인 경우를 잡습니다. 체크 디지트는 앞의 두 검사를 통과한 값에서도 남아 있는 한 자리 오류를 찾아냅니다.
| 층 | 확인하는 것 | 대표적으로 잡는 오류 |
|---|---|---|
| 문자 집합 | 허용된 문자만 있는가 | 숫자 자리에 글자가 섞임 |
| 자릿수 | 길이가 범위 안인가 | 한 자리 추가, 한 자리 누락 |
| 체크 디지트 | 마지막 자리가 계산값과 같은가 | 옮겨 적는 과정의 한 자리 오류 |
세 층은 서로를 대신하지 못합니다. 자릿수가 맞아도 문자 집합이 어긋날 수 있고, 두 검사를 모두 통과해도 체크 디지트가 성립하지 않을 수 있습니다.
왜 순서를 바꾸면 안 되나요?
계산 순서를 바꾸면 결과가 아니라 설명이 망가집니다. 구분 기호를 걷어내기 전에 자릿수를 세면, 공백이 들어간 멀쩡한 번호가 길이 미달로 판정됩니다. 반대로 체크 디지트를 먼저 계산하면, 애초에 그 제도의 번호가 아닌 값에 대해 산술적으로는 맞지만 의미 없는 결론을 내놓게 됩니다.
정리, 문자 집합, 자릿수, 체크 디지트의 순서를 지키면 각 단계의 실패가 정확한 원인을 가리킵니다. 순서를 지키는 일은 성능 문제가 아니라 오류 메시지의 품질 문제입니다. 사용자가 무엇을 고쳐야 하는지 알려면 어느 단계에서 멈췄는지가 드러나야 합니다.
왜 형식이 맞다고 번호가 진짜인 것은 아닌가요?
체크 디지트가 증명하는 것은 오직 하나입니다. 그 문자열이 제도가 정한 산술 규칙을 스스로 만족한다는 사실입니다. 그 번호가 실제로 발급되었는지, 누구에게 속하는지, 지금 사용할 수 있는지는 이 계산과 아무 관계가 없습니다.
이 구분이 실무에서 중요한 이유는 판정 문구가 곧 사용자 행동을 바꾸기 때문입니다. 검증 통과를 유효하다고 적으면 사용자는 그것이 승인이나 확인을 뜻한다고 읽습니다. 확인한 범위를 문구에 그대로 적는 편이 오해가 적습니다. 이런 구분을 자세히 다룬 글로 체크 디지트가 없는 번호를 함께 읽으면 판정 문구를 고르는 기준이 분명해집니다.
한 번호가 여러 제도에 걸칠 수 있나요?
걸칩니다. 같은 자릿수의 숫자열이 서로 다른 두 나라의 번호 형식과 동시에 맞아떨어지는 일은 드물지 않고, 체크 디지트 알고리즘까지 함께 통과하는 경우도 있습니다. 이때 어느 하나만 골라 보여주면 나머지 가능성을 지운 셈이 됩니다.
그래서 검증 결과는 후보 제도를 나란히 보여주는 편이 정확합니다. 각 후보는 그 자체로 참인 진술이고, 사용자가 어느 제도의 번호를 다루는지는 사용자만 압니다. 도구가 국가를 대신 추측하면 틀렸을 때 사용자는 자기 입력을 의심하게 됩니다. 이 구조를 체크 디지트 알고리즘 편에서 알고리즘 쪽에서 다시 살펴봅니다.
네 가지 판정을 구분하려면 어떻게 해야 하나요?
검증 결과는 통과와 실패의 두 가지가 아니라 네 가지입니다. 체크 디지트가 성립하는 경우, 형식은 맞지만 체크 디지트가 성립하지 않는 경우, 그 제도가 알고리즘을 공개하지 않아 형식만 확인한 경우, 그리고 우리가 그 제도의 규칙 자체를 갖고 있지 않은 경우입니다.
마지막 두 가지를 뭉뚱그리면 안 됩니다. 알고리즘이 없어 형식만 본 값을 무효라고 적으면, 멀쩡한 입력을 사용자 잘못으로 돌리는 셈입니다. 반대로 규칙이 없다는 사실을 가짜라는 뜻으로 읽히게 적으면 도구가 없는 판단을 한 척하게 됩니다. 이 네 갈래를 구분해 보여주는 것이 검증 도구의 핵심 역할이며, 번호 검증 도구가 그 네 가지를 각각 다른 문구로 표시합니다.
개발자를 위한 메모: 검증 파이프라인의 층 나누기
- 정리 단계를 첫 번째 함수로 떼어 둡니다. 구분 기호 제거와 대소문자 통일은 이후 모든 판단의 전제이므로, 다른 검사와 섞이면 원인 추적이 어려워집니다.
- 세 층을 각각 독립된 판정으로 반환합니다. 불리언 하나로 합치면 화면에서 구분할 수 있는 정보가 사라집니다.
- 후보가 여러 개일 때는 목록으로 반환하고, 임의로 하나를 고르지 않습니다.
- 알고리즘을 모르는 제도에는 형식만 확인했다는 별도의 상태값을 둡니다. 통과도 실패도 아닌 상태를 표현할 자리가 필요합니다.
- 실패 응답에는 어느 층에서 멈췄는지를 담습니다. 사용자가 고칠 수 있는 실패와 고칠 수 없는 실패는 안내가 달라야 합니다.
다음 단계
직접 확인해 보고 싶다면 번호 검증 도구에 값을 붙여넣고 네 가지 판정이 각각 언제 나오는지 관찰해 보세요. 그다음에는 후보가 여러 개로 나오는 입력을 일부러 찾아보면, 왜 도구가 국가를 추측하지 않는지 자연스럽게 이해됩니다. 여기서 다룬 예시와 번호는 모두 검증 구조를 설명하기 위해 지어낸 합성 값이며, 실제로 발급된 번호나 계좌, 신분증과는 아무 관계가 없습니다. 실제 사람이나 기관을 사칭하거나 검증 통과를 진위의 근거로 삼는 데 써서는 안 됩니다.