검사 숫자 계산기: 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과 각 방식의 공개 예제로 확인했습니다. 모두 브라우저에서 실행됩니다.
사용법
- 검사 숫자 없이 번호를 입력하면 모든 방식의 검사 문자가 나오고, 완성된 번호를 입력하면 어떤 방식이 받아들이는지 알 수 있습니다.
- 필요한 방식의 완성된 번호를 확인합니다. 구분 기호는 무시하고 영문자는 대문자로 읽습니다.
- 오류 열을 비교해 방식을 고릅니다. 바로 이 번호에서 각 방식이 잡아내는 한 글자 오류와 이웃 교환의 개수입니다.
자세한 설명
펼치기접기
검사 숫자는 식별번호 끝에 붙이는 한두 글자로, 오타가 다른 유효한 번호가 되지 않고 무효한 번호가 되도록 해 줍니다. 이 계산기는 입력한 값에 아홉 가지 방식을 나란히 적용합니다. 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도 받습니다.
관련 도구
바코드 체크 디지트 계산기 (UPC, EAN)
EAN-13, UPC-A, EAN-8 바코드의 GS1 모듈로-10 체크 디지트를 계산하거나 검증합니다. 데이터 숫자를 입력하면 체크 디지트를, 전체 코드를 입력하면 유효성을 확인합니다.
개발
IBAN 검증기
국제 은행 계좌번호 검증 — 국가 코드·길이·mod-97 체크섬 확인. 75개국 이상 지원.
일상
신용카드 검증 (Luhn + 브랜드)
Luhn 체크섬으로 카드번호 검증·브랜드 식별(Visa/MC/Amex 등)·길이 확인. 로컬·네트워크 없음.
개발
CSR 디코더 (PKCS#10)
인증서 서명 요청을 보내기 전에 확인합니다. 주체, SAN, 키 길이, 서명 알고리즘, 그리고 자체 서명이 검증되는지까지.
개발
ISBN 검증기 (ISBN-10 / ISBN-13)
ISBN-10·ISBN-13 체크섬 검증 및 두 형식 간 변환. 하이픈·공백 처리.
개발
Java .properties 파서
java.util.Properties.load와 똑같이 .properties 파일을 파싱하고, 구분자·이스케이프·이어붙이기에서 놀랄 만한 줄을 짚어 줍니다.
개발