CPF CNPJ 검증: 브라질 두 가지 세금 번호

브라질에서는 개인과 법인이 서로 다른 형식의 세금 번호를 씁니다. 두 번호 모두 검증값을 갖고 있지만 계산에 쓰이는 매개변수가 달라서, 한쪽 규칙을 다른 쪽에 그대로 적용하면 판정이 어긋납니다. 이 글에서는 두 번호의 차이와 검증값 계산의 공통 골격, 그리고 자주 발생하는 함정을 정리합니다.

CPF와 CNPJ는 각각 무엇을 가리키나요?

두 번호는 대상이 다릅니다. 하나는 자연인, 즉 사람에게 붙는 번호이고 다른 하나는 법인, 즉 회사나 단체에 붙는 번호입니다. 이름도 자릿수도 다르지만, 둘 다 같은 목적을 가집니다. 즉 과세 대상 하나를 다른 대상과 구별하고, 옮겨 적는 과정의 실수를 스스로 드러내는 것입니다.

이 구분은 검증 도구를 쓸 때 바로 영향을 줍니다. 사용자가 입력한 값이 어느 쪽인지에 따라 적용할 규칙이 달라지고, 두 규칙의 계산 결과가 일치하지 않기 때문입니다. 그래서 하나의 검증 절차로 두 번호를 함께 처리하려면 어느 매개변수 묶음을 쓸지 먼저 정해야 합니다.

두 번호의 구조는 어떻게 다른가요?

두 번호는 모두 숫자로 이루어지지만 길이가 다르고, 끝에 붙는 검증값의 개수는 두 개로 같습니다. 즉 검사를 통과하려면 두 번의 계산을 모두 만족해야 합니다. 첫 번째 검증값을 계산해 붙인 다음, 그 값을 포함한 앞부분으로 두 번째 검증값을 다시 계산하는 순서가 일반적입니다.

길이가 다르므로 자릿수 검사를 먼저 통과하지 못한 값은 어느 쪽 계산도 시도할 필요가 없습니다. 또 하나 기억할 점은 두 번호 모두 표시할 때 점, 슬래시, 하이픈 같은 구분 기호를 끼워 넣는다는 것입니다. 이 기호는 사람이 읽기 위한 것이고 계산 대상이 아니므로, 검사 전에 반드시 걷어내야 합니다.

검증값은 어떤 방식으로 계산되나요?

두 번호 모두 같은 골격을 씁니다. 앞의 자릿수에 자리마다 다른 가중치를 곱해 모두 더하고, 그 합계를 정해진 수로 나눈 나머지를 구한 뒤, 나머지를 이용해 한 자리 값을 만듭니다. 이 값을 첫 번째 검증값으로 붙이고, 붙인 결과를 다시 재료로 삼아 두 번째 검증값을 같은 방식으로 계산합니다.

두 번호가 갈리는 지점은 가중치의 배열과 나누는 수, 그리고 나머지를 값으로 옮기는 규칙입니다. 그래서 겉으로 보이는 계산 절차는 비슷한데 매개변수를 섞으면 전혀 다른 답이 나옵니다. 이런 가족 관계는 브라질 번호만의 특성이 아니라 검증값을 쓰는 체계 전반의 공통점이며, 체크 디지트 알고리즘 편에서 갈래별로 비교했습니다. 나머지가 한 자리로 떨어지지 않을 때의 표기 문제도 그 글에서 다룹니다.

왜 같은 숫자가 반복된 값은 따로 걸러내나요?

모든 자리가 같은 값으로 채워진 번호를 생각해 봅시다. 이런 값은 가중치를 어떻게 잡아도 계산 결과가 우연히 규칙과 맞아떨어지기 쉽습니다. 즉 산술적으로는 통과하지만 실제로는 아무 정보도 담고 있지 않은 값입니다.

그래서 정식 규칙은 이런 형태를 명시적으로 제외합니다. 검증 절차를 구현할 때도 이 예외를 함께 넣어야 하며, 빠뜨리면 명백히 성립할 수 없는 값이 통과로 표시됩니다. 예외 조건을 어디에 두느냐도 문제입니다. 계산 함수 안에 숨기기보다 별도의 검사 단계로 두면, 통과와 실패 사이에 놓이는 세 번째 사유를 설명할 수 있습니다. 이런 예외가 필요한 이유는 규칙이 잡으려는 대상이 값의 우연한 일치가 아니라 실제 입력 오류이기 때문입니다.

검증 통과는 등록되어 있다는 뜻인가요?

아닙니다. 통과는 그 숫자열이 정해진 산술 규칙을 만족한다는 사실만 말해 줍니다. 그 번호가 실제로 발급되었는지, 지금도 유효한 상태인지, 어느 사람이나 회사에 속하는지는 별개의 확인 절차가 필요합니다.

이 차이를 흐리면 두 가지 사고가 납니다. 하나는 통과한 값을 유효한 등록 번호라고 안내하는 것이고, 다른 하나는 실패한 값을 존재하지 않는 대상이라고 단정하는 것입니다. 후자는 특히 위험합니다. 등록 상태는 조회 시점에 따라 달라질 수 있고, 조회 자체가 실패할 수도 있기 때문입니다. 형식 확인과 등록 확인을 다른 문구로 나눠 보여주는 이유가 여기에 있습니다. 검증 결과를 네 갈래로 나누는 원칙은 번호 검증의 원리에서 자세히 다룹니다.

계산에 들어가기 전에 짚어 둘 것이 남아 있습니다. 입력값은 대개 사람이 손으로 옮겨 적은 형태로 들어옵니다. 가운데에 구분 기호가 있고, 앞뒤에 공백이 붙고, 전각 숫자가 섞이기도 합니다. 계산 절차는 이런 형태를 다루지 않으므로 정리 단계를 앞에 두어야 합니다.

정리 순서는 정해 두는 편이 좋습니다. 앞뒤 공백을 제거하고, 구분 기호를 모두 걷어내고, 숫자를 반각으로 통일하고, 빈 값을 걸러냅니다. 이 과정을 거친 값이 자릿수 조건을 통과해야 계산을 시도합니다. 정리한 값과 원본 값을 함께 보관해야 나중에 입력 원천을 손볼 수 있습니다.

정리한 뒤에는 두 번호 중 어느 쪽인지 가르는 문제가 남습니다. 정리한 값의 자릿수가 다르므로 길이만으로도 대개 갈립니다. 다만 길이만 보고 단정하면 경계에 놓인 값에서 오판이 생기므로, 자릿수 조건을 통과한 후보들에 대해 각각의 계산을 돌려 보는 방식이 안전합니다. 두 계산을 모두 통과하는 값은 어느 쪽으로도 확정하지 않고 두 결과를 함께 보여줍니다.

사용자가 대상을 지정할 수 있다면 그 선택을 우선합니다. 개인 번호 자리에 법인 번호가 들어오는 일은 흔하고, 시스템이 길이만으로 바로잡으려 하면 사용자가 자기 입력을 오해하게 됩니다. 지정과 추측이 다를 때는 두 사실을 함께 알려 주고 어느 쪽으로 진행할지 사용자가 정하게 하는 편이 낫습니다.

개발자를 위한 메모: 정리, 마스크, 오류 문구

• 입력 정리 함수를 가장 앞에 둡니다. 구분 기호를 걷어내고 공백을 제거한 값 하나만 검사 대상으로 삼습니다.
• 두 번호의 규칙을 매개변수 묶음으로 분리하고, 어느 묶음을 쓸지 결정하는 판단을 바깥으로 뺍니다. 나중에 규칙이 바뀌어도 판단 코드는 그대로 둘 수 있습니다.
• 반복 숫자처럼 산술적으로만 통과하는 형태를 별도 단계로 검사합니다. 계산 함수에 섞으면 실패 사유가 뭉개집니다.
• 화면에 보여줄 때만 구분 기호를 다시 넣습니다. 표시 형식과 저장 형식을 분리하면 검색과 비교가 단순해집니다.
• 오류 문구를 사유별로 나눕니다. 자릿수가 어긋난 경우와 검증값이 어긋난 경우는 사용자가 취할 행동이 다릅니다.

이 글에 나오는 번호 예시와 계산 설명은 검증 절차를 보여 주기 위해 구성한 것으로, 실제 자연인이나 기업의 세금 번호가 아니며 등록 상태와도 무관합니다. 실제 사람이나 회사를 사칭하거나 검증 통과를 신원이나 자격의 증명으로 사용해서는 안 됩니다.

다음 단계

구분 기호가 섞인 값과 그렇지 않은 값이 같은 판정을 받는지 번호 검증 도구에서 확인해 보세요. 나라마다 규칙이 어떻게 다른지 더 알고 싶다면 국가별 신분증 검증을 이어서 읽어 보시길 권합니다.