본문으로 건너뛰기
AZ Tools

검사 숫자 계산기: Luhn·Verhoeff·Damm

Luhn, Verhoeff, Damm, ISO 7064(MOD 11-2·97-10·37-2 등)로 검사 숫자를 계산·검증하고, 각 방식이 어떤 입력 실수를 잡아내는지 확인합니다.

방식검사 문자 → 완성 번호입력이 이미 유효?이 번호에서 잡아내는 오류
Luhn (mod 10)
결제 카드, IMEI, 캐나다 SIN
3
79927398713
아니요
한 글자 오류 99개 중 99개 (100%)
이웃 교환 9개 중 9개 (100%)
Verhoeff
인도 Aadhaar 번호
8
79927398718
아니요
한 글자 오류 99개 중 99개 (100%)
이웃 교환 9개 중 9개 (100%)
Damm
숫자만, 표 하나
1
79927398711
아니요
한 글자 오류 99개 중 99개 (100%)
이웃 교환 8개 중 8개 (100%)
ISO 7064 MOD 11-2
ORCID, ISNI(검사 문자 X 가능)
8
79927398718
아니요
한 글자 오류 100개 중 100개 (100%)
이웃 교환 9개 중 9개 (100%)
ISO 7064 MOD 11,10
크로아티아 OIB, 독일 납세자 번호
5
79927398715
아니요
한 글자 오류 99개 중 99개 (100%)
이웃 교환 9개 중 9개 (100%)
ISO 7064 MOD 97-10
LEI, IBAN(재배열 후)
65
799273987165
아니요
한 글자 오류 368개 중 368개 (100%)
이웃 교환 10개 중 10개 (100%)
Luhn mod 36
영숫자 코드
N
7992739871N
아니요
한 글자 오류 385개 중 385개 (100%)
이웃 교환 9개 중 9개 (100%)
ISO 7064 MOD 37-2
영숫자(검사 문자 * 가능)
G
7992739871G
아니요
한 글자 오류 386개 중 386개 (100%)
이웃 교환 9개 중 9개 (100%)
ISO 7064 MOD 37,36
ISAN, GRid
V
7992739871V
아니요
한 글자 오류 385개 중 385개 (100%)
이웃 교환 9개 중 9개 (100%)

'입력이 이미 유효?'는 입력의 마지막 글자(MOD 97-10은 두 글자)를 검사 문자로 보고, 검사 열은 입력 전체를 보호할 번호로 봅니다.

python-stdnum과 각 방식의 공개 예제로 확인했습니다. 모두 브라우저에서 실행됩니다.

사용법

  1. 검사 숫자 없이 번호를 입력하면 모든 방식의 검사 문자가 나오고, 완성된 번호를 입력하면 어떤 방식이 받아들이는지 알 수 있습니다.
  2. 필요한 방식의 완성된 번호를 확인합니다. 구분 기호는 무시하고 영문자는 대문자로 읽습니다.
  3. 오류 열을 비교해 방식을 고릅니다. 바로 이 번호에서 각 방식이 잡아내는 한 글자 오류와 이웃 교환의 개수입니다.

자세한 설명

펼치기

검사 숫자는 식별번호 끝에 붙이는 한두 글자로, 오타가 다른 유효한 번호가 되지 않고 무효한 번호가 되도록 해 줍니다. 이 계산기는 입력한 값에 아홉 가지 방식을 나란히 적용합니다. Luhn(결제 카드와 IMEI의 mod 10 알고리즘), Verhoeff, Damm, ISO/IEC 7064 순수 방식 MOD 11-2(ORCID, ISNI)·MOD 37-2·MOD 97-10(LEI, IBAN은 국가 코드를 옮긴 뒤 적용), 혼합 방식 MOD 11,10·MOD 37,36, 영숫자용 Luhn mod 36입니다. 각 방식마다 붙일 검사 문자, 완성된 번호, 입력이 이미 올바른 검사 문자로 끝나는지를 보여 줍니다. 그리고 교과서가 주장만 하는 것을 실제로 해 봅니다. 완성된 번호에서 한 글자를 바꾼 모든 경우와 이웃한 두 글자를 바꾼 모든 경우를 만들어 각 방식이 몇 개를 잡아내는지 세고, 놓치는 예를 몇 개 보여 줍니다. 대부분의 번호에서 차이가 분명히 드러납니다. Luhn은 09↔90 교환과 일부 쌍둥이 오류를 놓치고, Verhoeff와 Damm은 숫자만으로 모든 단일 오류와 인접 교환을 잡으며, MOD 11-2도 검사 문자 'X'를 허용하는 대가로 같은 성능을 냅니다. 집계는 이 두 종류만 다루며, 한 칸 건너 교환(1x3↔3x1)이나 15↔50 같은 발음 실수는 포함하지 않습니다. 공백·하이픈·점은 무시하고 영문자는 대소문자를 구분하지 않으며, 입력에 맞지 않는 방식은 '해당 없음'으로 표시합니다. MOD 97-10은 IBAN처럼 항상 02~98을 만들지만, 검증할 때는 같은 값인 00·01도 받아들입니다. 검사 숫자는 실수를 막을 뿐 위조를 막지 못합니다. 누구나 올바른 값을 계산할 수 있습니다.

자주 묻는 질문

어떤 검사 숫자 알고리즘이 가장 좋나요?

숫자만 쓴다면 Verhoeff와 Damm이 모든 한 자리 오류와 인접 교환을 잡아냅니다. Damm은 표 하나만 있으면 되고 치환이 없어 구현이 더 간단합니다. 검사 자리에 X를 허용해도 된다면 ISO 7064 MOD 11-2도 같습니다. Luhn은 더 약하지만 결제 카드의 표준이라 보통 호환성이 결정합니다.

Luhn은 왜 일부 오류를 놓치나요?

두 배를 하면 9는 18이 되고 자릿수 합이 다시 9가 되므로, 두 배 자리에 있는 0과 9를 바꿔도 합이 변하지 않아 09와 90이 같아 보입니다. 22→55, 33→66 같은 쌍둥이 오류도 상쇄될 수 있습니다. 오류 열에 입력한 번호에서 찾은 예가 나옵니다.

IBAN이나 카드 번호도 검증할 수 있나요?

카드는 Luhn을 쓰므로 Luhn 행이 바로 답입니다. IBAN은 앞 네 글자를 끝으로 옮긴 뒤 MOD 97-10을 적용하므로, 옮긴 형태로 붙여 넣거나 국가별 길이까지 확인하는 이 사이트의 IBAN 검사기를 쓰세요.

'이미 유효'는 무슨 뜻인가요?

입력의 마지막 글자(MOD 97-10은 두 글자)를 검사 문자로 보고 맞는지 확인합니다. 반면 검사 열은 입력 전체를 본문으로 보고 무엇을 붙여야 하는지 알려 줍니다.

왜 '해당 없음'으로 나오나요?

그 방식의 문자 집합이 입력을 다루지 못하기 때문입니다. Luhn, Verhoeff, Damm, MOD 11 방식은 숫자만 받고, Luhn mod 36, MOD 37-2, MOD 37,36, MOD 97-10은 영문자 A~Z도 받습니다.

관련 도구