세금 번호 검증: 형식 검사로 알 수 있는 것과 없는 것

세금 번호 검증은 대개 “이 번호가 쓸 수 있는 번호인가”를 묻는 작업으로 시작하지만, 실제로 형식 검사가 답할 수 있는 것은 훨씬 좁습니다. 이 글은 검사 숫자가 있는 번호와 그렇지 않은 번호가 어떻게 다른지, 검증을 왜 층으로 나눠야 하는지, 그리고 검증 실패를 “그런 회사가 없다”로 해석하면 무엇이 잘못되는지를 다룹니다.

세금 번호 검증이란 무엇을 하는 일인가요?

세금 번호는 나라마다 이름도 체계도 다릅니다. 부가가치세 목적으로 받는 번호도 있고, 소득이나 법인세를 위해 부여하는 번호도 있으며, 등록번호를 그대로 세무 목적에 함께 쓰는 나라도 있습니다. 그래서 “세금 번호”라는 한 가지 칸을 모든 나라에 똑같이 적용하기 어렵습니다.

검증이라는 말도 여러 뜻으로 쓰입니다. 어떤 사람은 글자 구성이 맞는지 확인하는 일을 뜻하고, 어떤 사람은 실제로 등록된 사업자인지 확인하는 일을 뜻합니다. 두 작업은 난이도도, 신뢰도도, 실패했을 때의 의미도 완전히 다릅니다.

이 혼동이 실무 사고의 출발점입니다. 형식만 확인하고 “검증 완료”라고 표시해 두면, 뒤에 오는 사람은 그 번호가 실제로 존재한다고 믿습니다. 표시 하나가 사실보다 강한 인상을 만드는 셈입니다.

검사 숫자가 있는 번호와 없는 번호는 어떻게 다른가요?

번호 체계는 크게 두 갈래로 나뉩니다. 한쪽은 번호 안에 검사 숫자를 넣어, 앞부분에서 계산한 값이 마지막 자리와 맞는지 스스로 확인할 수 있게 만듭니다. 다른 쪽은 등록 기관이 순서대로 부여할 뿐, 번호 자체에는 아무 계산 규칙이 없습니다.

검사 숫자가 있는 번호는 한 자리를 잘못 입력했을 때 대개 걸러집니다. 순서가 뒤바뀐 경우도 상당수 잡힙니다. 그래서 사용자가 오타를 낸 자리에서 바로 알려 줄 수 있다는 장점이 있습니다.

검사 숫자가 없는 번호는 어떤 알고리즘으로도 진위를 가릴 수 없습니다. 길이와 문자 구성만 확인한 뒤에는, 실제 등록 여부를 외부에 물어보는 수밖에 없습니다. 이 차이는 제도가 그렇게 설계되었기 때문에 생기는 것이지, 구현이 부족해서가 아닙니다.

중요한 것은 어느 번호가 어느 갈래인지 단정하지 않는 태도입니다. 같은 나라 안에서도 목적에 따라 다른 번호가 쓰이고, 제도가 바뀌면 성질도 바뀝니다. 그래서 “이 나라 번호는 반드시 검사 숫자가 있다”는 식의 가정은 오래 가지 않습니다.

검증은 왜 층으로 나눠야 하나요?

층을 나누지 않으면 느린 작업이 빠른 작업을 막습니다. 세 단계로 나누는 것이 일반적입니다.

세 층을 한 함수에 넣으면, 외부 창구가 잠깐 응답하지 않을 때 사용자가 가입 단계에서 멈춥니다. 반대로 형식 층만 남겨 두고 “검증됨”이라고 표시하면, 확인하지 않은 사실을 확인한 것처럼 보여 줍니다.

층별로 결과를 따로 기록하는 것도 같은 이유입니다. 어느 층에서 왜 막혔는지 남아 있어야, 사용자 안내도 고칠 수 있고 지표도 해석할 수 있습니다.

형식 검사가 통과했다는 것은 무엇을 뜻하나요?

여기가 가장 자주 오해되는 지점입니다. 형식 검사를 통과했다는 사실은 “이런 모양의 번호가 존재할 수 있다”는 뜻일 뿐입니다. 그 번호가 발급되었는지, 지금 유효한지, 어느 사업자의 것인지는 전혀 말해 주지 않습니다.

그래서 다음과 같은 결론은 모두 잘못입니다.

• 형식이 맞으니 실제 사업자일 것이다. 그렇지 않습니다. 아무 숫자나 규칙에 맞게 넣어도 형식은 통과합니다.
• 조회가 안 되니 그 회사는 존재하지 않는다. 조회 실패는 여러 이유로 생깁니다. 서비스가 답하지 않았을 수도 있고, 그 나라가 공개 조회를 제공하지 않을 수도 있습니다.
• 검사 숫자가 맞으니 등록된 번호일 것이다. 검사 숫자는 우연히도 맞을 수 있습니다.

이 구분을 사용자 화면에도 그대로 반영해야 합니다. “형식 확인”과 “등록 확인”은 다른 문구로 표시하고, 확인하지 못한 상태는 확인하지 못했다고 적는 편이 정직합니다.

실무에서는 어떤 순서로 처리하나요?

• 먼저 어떤 종류의 번호인지 정합니다. 등록번호와 부가가치세 번호를 섞으면 그 뒤 단계가 모두 어긋납니다.
• 그다음 나라를 정합니다. 번호의 형식 규칙은 나라에 딸려 있으므로 나라 없이는 검증할 수 없습니다.
• 형식과 검사 숫자를 확인하고, 실패하면 그 자리에서 이유를 알려 줍니다. 오타는 즉시 고치는 편이 빠릅니다.
• 등록 확인이 필요한 흐름에서만 외부 질의를 붙입니다. 모든 입력에 붙이면 속도와 비용이 모두 나빠집니다.
• 확인 결과와 확인 시각을 저장합니다. 다시 확인하지 않고도 언제 본 값인지 알 수 있어야 합니다.
• 실패를 재시도 가능한 상태로 남깁니다. 일시적인 오류와 실제 불일치는 대응이 다릅니다.

LEI 코드처럼 다른 종류의 식별자를 함께 다루는 경우에도 같은 순서가 적용됩니다. 종류를 먼저 정하고, 그 종류의 규칙을 적용합니다.

이 사이트의 도구에서는 어떻게 확인하나요?

테스트용 회사 정보 생성기에서 만든 번호는 합성 값이며 실제 등록부와 연결되지 않습니다. 우리 검증 절차가 어느 층까지 동작하는지 확인하는 시험 입력으로 쓰기에 적합하고, 실제 사업자의 등록 여부를 판단하는 자료로는 쓸 수 없습니다. 실제 확인이 필요하면 해당 국가의 공식 창구를 이용하세요. 나라별 번호 체계가 다른 이유는 회사 등록번호에서 더 자세히 다룹니다.

개발자를 위한 메모: 실패를 설명 가능하게 만들기

• 오류 코드를 층별로 나눕니다. 형식 오류, 검사 숫자 오류, 확인 불가, 확인 결과 불일치는 서로 다른 코드여야 합니다.
• 사용자 문구와 내부 로그를 분리합니다. 사용자에게는 고칠 방법을, 로그에는 판단 근거를 남깁니다.
• 확인 불가를 거절로 승격하지 않습니다. 외부 창구 장애로 정상 사용자가 막히는 것이 가장 흔한 사고입니다.
• 검증 결과에 유효 기간을 둡니다. 결과와 시각을 함께 저장하고, 기간이 지나면 다시 확인하도록 표시합니다.
• 검증 이력을 남깁니다. 언제 어떤 값이 어느 층에서 어떤 결과를 받았는지 남아 있어야 나중에 분쟁을 설명할 수 있습니다.
• 시험 자료에는 시험용임이 드러나는 표시를 넣습니다. 합성 값이 실제 값처럼 보이면 운영 데이터와 섞입니다.
• 실제 조회를 시험에서 호출하지 않도록 기본값을 닫아 둡니다. 모의 응답을 켜는 절차를 따로 둡니다.

다음 단계

우리 검증 코드가 몇 층으로 나뉘어 있는지 확인하고, 각 층의 실패가 사용자에게 어떻게 보이는지 화면에서 따라가 보세요. 그다음 테스트용 회사 정보 생성기에서 여러 나라의 값을 만들어 넣고, 어느 층에서 어떤 문구가 나오는지 비교하면 손볼 자리가 분명해집니다.

이 글은 데이터 검증 설계를 돕기 위한 일반 안내이며 세무 자문이 아닙니다. 형식 검사만으로 실제 사업자를 판별할 수 없으며, 실제 확인은 각국 공식 창구가 기준입니다.