체크 디지트 없는 번호: 형식만 확인할 수 있는 이유

모든 번호에 검증값이 붙어 있는 것은 아닙니다. 어떤 제도는 번호 체계와 계산 규칙을 문서로 공개하고, 어떤 제도는 자릿수와 문자 구성만 알려 줍니다. 후자를 만났을 때 검증 도구가 무엇을 말할 수 있고 무엇을 말해서는 안 되는지 정리합니다.

어떤 번호에는 왜 검증값이 없나요?

검증값은 선택 사항입니다. 발급 기관이 입력 오류를 줄일 필요를 느끼면 붙이고, 그렇지 않으면 붙이지 않습니다. 번호를 쓰는 창구가 적거나 사람이 직접 확인하는 비중이 크면 굳이 계산 장치를 넣을 이유가 줄어듭니다.

또 하나의 이유는 계산 규칙을 공개하지 않으려는 판단입니다. 규칙을 공개하면 누구나 번호의 성립 여부를 확인할 수 있게 되는데, 발급 기관이 그것을 원하지 않을 수 있습니다. 어느 쪽이든 외부에서 볼 수 있는 것은 번호의 겉모습뿐이라는 결과가 됩니다.

규칙이 공개되지 않으면 무엇을 할 수 있나요?

확인할 수 있는 것은 세 가지입니다. 자릿수가 제도가 정한 범위에 들어가는지, 허용된 문자만 쓰였는지, 그리고 구분 기호를 걷어냈을 때 같은 형태로 정리되는지입니다. 이 세 가지를 통과했다는 사실은 값이 그 제도의 형식과 어긋나지 않는다는 뜻입니다.

확인할 수 없는 것은 산술적 성립 여부입니다. 마지막 자리가 앞자리에서 계산된 값인지 아닌지 판단할 근거가 없으므로, 계산을 시도해서는 안 됩니다. 없는 규칙을 추측으로 채우면 통과와 실패가 모두 근거 없는 판정이 됩니다.

형식만 확인하는 검사도 가치가 있나요?

있습니다. 형식 검사는 값이 싸고 즉시 끝나며, 명백한 입력 오류를 초기에 걸러냅니다. 자릿수가 모자란 값이나 문자 대신 기호가 섞인 값은 뒤 단계로 보내기 전에 되돌리는 편이 낫습니다. 잘못된 값이 저장되면 나중에 찾아내는 비용이 훨씬 큽니다.

형식 검사는 저장 형식을 통일하는 역할도 합니다. 공백과 구분 기호를 어디에서 걷어낼지 정해 두면 검색과 비교가 단순해집니다. 어떤 후속 처리로 보낼지 가르는 기준이 되는 것도 형식입니다. 다만 이 모든 가치는 형식과 관련된 것이며, 번호의 실체와 관련된 것은 아닙니다.

검증 실패는 번호가 없다는 뜻인가요?

아닙니다. 산술 검사를 할 수 없는 제도에서 값이 형식에 맞지 않는다는 판정은 그 값이 그 제도의 번호가 아니라는 뜻일 뿐입니다. 자릿수가 어긋난 값도 다른 제도의 번호일 수 있고, 단순한 입력 실수일 수도 있습니다.

반대 방향의 오해도 흔합니다. 형식에 맞았다는 이유로 유효한 번호라고 안내하는 것입니다. 형식이 맞는다는 사실에서 얻을 수 있는 결론은 형식이 맞는다는 것뿐이며, 그 이상을 말하려면 다른 확인 절차가 필요합니다. 이런 층 구분은 번호 검증의 원리 편에서 네 가지 상태로 정리했습니다.

결과를 어떤 문구로 보여줘야 하나요?

상태마다 문장을 따로 두는 것이 핵심입니다. 형식이 맞은 경우에는 형식 확인까지만 마쳤다는 사실을 적고, 형식이 어긋난 경우에는 어느 조건에서 어긋났는지 적습니다. 규칙이 없어 검사하지 않은 경우에는 검사하지 않았다고 적어야 합니다.

가장 흔한 실수는 두 가지 상태를 하나로 합치는 것입니다. 규칙이 없어서 판단하지 않은 값을 무효라고 표시하면, 사용자는 자기 번호에 문제가 있다고 오해합니다. 반대로 형식만 맞은 값을 유효라고 표시하면, 확인하지 않은 내용을 확인한 것처럼 전달하게 됩니다.

모르는 제도의 값을 만났을 때 할 수 있는 일은 세 가지입니다. 그 값을 처리하지 못한다고 분명히 알리거나, 규칙이 공개된 다른 제도의 값인지 확인해 보거나, 사용자가 제도를 지정할 수 있게 하는 것입니다. 가장 나쁜 선택은 아무 규칙이나 가정해서 계산하는 것입니다. 통과든 실패든 근거 없는 판정이 나오고, 그 판정이 사실처럼 남습니다.

이 상황이 자주 생긴다면 규칙 목록을 보강할 시점입니다. 어떤 제도의 문의가 반복되는지 기록해 두면 우선순위가 자연스럽게 정해집니다. 목록에 없는 제도를 등록할 때는 규칙이 없다는 사실 자체를 항목으로 추가하는 편이 좋습니다. 그래야 다음번 같은 값이 왔을 때 인식 불가와 규칙 없음을 구분해 안내할 수 있습니다.

형식 검사가 실제로 막아 주는 오류도 세어 둘 필요가 있습니다. 형식 검사는 값이 뒤 단계로 흘러가기 전에 걸러내는 자리에 놓입니다. 자릿수가 모자란 값, 문자 자리에 기호가 들어간 값, 전각과 반각이 섞인 값은 여기서 대부분 걸립니다. 이런 값은 계산 단계까지 갈 필요가 없으므로, 앞에서 막으면 뒤 단계의 오류 처리 부담이 줄어듭니다.

저장 형식을 통일하는 효과도 큽니다. 같은 번호가 공백과 하이픈을 달리해 여러 번 저장되면 검색과 중복 판정이 어긋납니다. 형식 검사와 정리 단계를 붙여 두면 저장되는 값의 모양이 하나로 정해지고, 비교 연산을 단순하게 유지할 수 있습니다. 이 모든 이득은 형식에 관한 것이며, 값의 진위에 관한 주장은 여전히 할 수 없습니다.

개발자를 위한 메모: 판정 상태 설계

• 상태를 네 가지로 나눕니다. 검증 통과, 산술 불일치, 형식만 확인, 규칙 없음은 서로 다른 문구와 다른 색을 가져야 합니다.
• 규칙이 없는 제도를 목록에서 빼지 말고 명시적으로 등록합니다. 빠뜨리면 규칙 없음과 인식 불가가 섞입니다.
• 형식 검사 실패의 사유를 자릿수, 문자, 정리 후 형태로 나눠 기록합니다. 사용자가 고칠 지점을 알 수 있습니다.
• 산술 검사를 할 수 있는 제도에만 계산 함수를 연결합니다. 빈 규칙을 억지로 채우지 않습니다.
• 화면 문구와 로그 문구를 분리합니다. 로그에는 어느 규칙 묶음을 적용했는지 남겨야 나중에 재현할 수 있습니다.

이 글에서 예로 든 형식 조건과 번호 형태는 검증 층을 설명하기 위해 구성한 것이며, 특정 국가나 기관의 실제 규칙이 아닙니다. 형식 확인 결과는 어떤 번호의 진위나 소유 관계를 판단하는 증거로 사용할 수 없습니다.

다음 단계

규칙이 공개된 번호와 그렇지 않은 번호를 번호 검증 도구에 함께 넣어 결과 문구가 어떻게 갈리는지 확인해 보세요. 서버와 클라이언트 중 어디에서 어느 검사를 맡을지는 API 경계에서의 검증 편에서 다룹니다.