체크섬의 작동 원리
카드 번호, IBAN, 세금 ID 및 암호화폐 주소에는 모두 다른 숫자들로부터 계산된 숨겨진 추가 디지트가 하나 또는 두 개 존재합니다. 한 글자를 잘못 입력하면 산술 연산 결과가 맞지 않게 되는데, 바로 이를 통해 검증기는 은행이나 블록체인에 문의하지 않고도 오프라인에서 즉시 오타를 감지할 수 있습니다.
체크섬이란 무엇인가
체크섬(또는 체크 디지트)은 의도적으로 만든 중복 데이터입니다. 숫자가 발급될 때 그 디지트 중 하나 또는 두 개는 자유롭게 선택되지 않고 고정된 방식에 따라 나머지 숫자들로부터 계산됩니다. 이 방식을 아는 사람이라면 언제든지 해당 디지트를 다시 계산하여 비교할 수 있습니다. 일치하면 숫자의 내부적 일관성이 유지되는 것이며, 일치하지 않으면 입력 오류, 읽기 오류 또는 손상이 발생한 것입니다.
이것이 체크섬이 보장하는 전부입니다. 계좌가 존재하는지, 누가 소유하는지, 어떤 자산을 보유하는지에 대해서는 아무런 정보도 제공하지 않습니다. 이 사이트의 모든 검증기가 이 점을 반복해서 강조하는 이유는 이 두 가지를 혼동하기 쉽기 때문입니다.
예시 1 — 루른, 카드 번호 알고리즘
루른 알고리즘은 비자, 마스터카드 및 대부분의 다른 결제 카드에서 사용됩니다. 대표적인 예시로 7992 7398 713을 들 수 있습니다. 가장 오른쪽에 있는 디지트부터 시작하여 두 번째마다 디지트를 두 배로 만듭니다. 두 배한 값이 두 자리 숫자이면 그 디지트들을 더해줍니다. 그 후 모든 값을 합산합니다.
| 디지트 | 오른쪽으로부터의 위치 | 두 배로 늘어났나요? | 이렇게 계산됩니다 |
|---|---|---|---|
3 | 체크 디지트 | — | 3 |
1 | 오른쪽에서 두 번째 | 1 × 2 = 2 | 2 |
7 | 세 번째 | — | 7 |
8 | 네 번째 | 8 × 2 = 16 → 1 + 6 | 7 |
9 | 다섯 번째 | — | 9 |
3 | 여섯 번째 | 3 × 2 = 6 | 6 |
7 | 일곱 번째 | — | 7 |
2 | 여덟 번째 | 2 × 2 = 4 | 4 |
9 | 아홉 번째 | — | 9 |
9 | 열 번째 | 9 × 2 = 18 → 1 + 8 | 9 |
7 | 11번째 | — | 7 |
오른쪽 열의 합은 3 + 2 + 7 + 7 + 9 + 6 + 7 + 4 + 9 + 9 + 7 = 70입니다. 70은 10으로 나누어 떨어지므로 해당 번호는 유효합니다. 숫자 하나만 바꿔도 합이 10의 배수가 되지 않습니다. 신용카드 유효성 검사기에서 직접 시험해 보세요 — 이와 동일한 연산을 사용자 기기에서 수행합니다.
예시 2 — 가중합 (ISBN-10)
많은 국가의 신분증 번호는 가중합 방식을 사용합니다: 각 숫자에 고정된 가중치를 곱한 뒤 합산하여 나머지를 확인하죠. ISBN-10이 가장 명확한 예시입니다. 0-306-40615-2의 경우 가중치는 10부터 1까지 적용됩니다:
0×10 + 3×9 + 0×8 + 6×7 + 4×6 + 0×5 + 6×4 + 1×3 + 5×2 + 2×1 = 132
132는 정확히 11 × 12이므로 모듈로 11에 대한 나머지는 0이며 해당 ISBN은 유효합니다. 브라질의 CPF, 폴란드의 PESEL를 비롯한 수십 가지 식별번호도 각각의 가중치와 모듈러스 값을 적용해 동일한 패턴을 따르는데, 바로 이 때문에 일괄 ID 유효성 검사기 하나로 1초 만에 수천 개를 확인할 수 있는 것입니다.
예시 3 — IBAN과 모듈로 97
국제 은행 계좌번호는 두 개의 체크디지트를 사용하는 더 강력한 방식인 ISO 7064 모듈로 97-10을 적용합니다. 표준 예시로 GB82 WEST 1234 5698 7654 32를 살펴보겠습니다:
- 국가별 길이를 확인하세요: 영국의 IBAN은 22자입니다. ✓
- 처음 네 자리를 끝으로 옮기면
WEST12345698765432GB82가 됩니다. - 모든 문자를 두 자리 숫자로 변환하세요 (A = 10 … Z = 35): W→32, E→14, S→28, T→29, G→16, B→11이 되어
3214282912345698765432161182가 만들어집니다. - 해당 숫자를 97로 나누면 나머지는 정확히 1이어야 하는데, 실제로 그렇습니다.
97은 소수이며 두 자리 숫자 교체보다 크기 때문에 모듈로 97은 모든 단일 문자 오류와 위치 전환 오류를 잡아낼 수 있습니다. 무작위로 생성된 문자열 중 약 1/97만이 우연히 통과할 뿐이죠. IBAN 유효성 검사기에서는 이러한 각 단계의 통과/실패 여부를 확인할 수 있습니다.
암호화폐 주소: 해시로 생성된 체크섬
비트코인과 이더리움 주소는 요구 사항이 더 까다로운데, 그 안의 오타로 인해 자금이 영구적으로 누구에게도 전송되지 않기 때문입니다. 기존 비트코인 주소(1…, 3…)는 베이스58체크를 사용합니다. 주소 페이로드를 SHA-256로 두 번 처리한 뒤 결과값의 첫 4바이트를 체크섬으로 추가하는 방식입니다. 단 하나의 잘못된 문자만으로도 해시가 완전히 바뀌므로 오타가 통과할 확률은 약 40억분의 1에 불과합니다. 더 새로운 bc1… 주소는 베치32 또는 베치32m을 사용하는데, 이는 최대 4개 문자에 발생한 오류까지 모두 감지할 수 있는 오류 수정 코드입니다. 이더리움의 EIP-55는 대문자와 소문자의 패턴 속에 체크섬을 숨깁니다.
비트코인 주소 검증기와 이더리움 주소 검증기는 브라우저 내에서 이러한 알고리즘을 구현하며, 페이지가 로드될 때마다 공식 테스트 벡터를 이용해 자체 검증을 수행합니다.
주요 방식 개요
| 방식 | 사용 분야 | 감지 가능한 오류 | 무작위 오류가 통과할 확률 |
|---|---|---|---|
| 루른 알고리즘 (mod 10) | 신용카드 및 직불카드, IMEI, 여러 국가의 신분증 | 모든 한 자리 숫자 오류와 대부분의 인접 문자 교환 오류 | 약 10분의 1 |
| ISO 7064 mod 97-10 | IBAN 및 일부 세금 번호와 사업자 등록번호 | 모든 단일 오류와 모든 문자 위치 변경 | 약 97분의 1 |
| 가중합, mod 10 또는 11 | ISBN-10, 브라질 CPF, 폴란드 PESEL 및 여러 신분증 번호 | 단일 오류와 대부분의 문자 위치 변경 | 약 10분의 1 또는 11분의 1 |
| Base58Check (더블 SHA-256, 4바이트) | 비트코인 레거시 주소 (1…, 3…) | 어떤 오타도 거의 확실히 탐지됨 | 약 40억분의 1 |
| Bech32 / Bech32m (BCH 코드) | 비트코인 SegWit 및 Taproot 주소(bc1…) | 보장됨: 최대 4개 문자에 영향을 주는 오류 | 10억분의 1 미만 |
| EIP-55 (keccak-256 대문자/소문자 처리) | 이더리움 주소 | 오타는 대문자와 소문자의 패턴을 통해 발생함 | 혼합 대소문자 입력 시 매우 낮음 |
왜 검증기는 사용자 기기에서 실행되어야 할까?
위의 모든 내용은 이미 보유한 숫자에 대한 연산입니다. 검증기가 카드 번호, 세금 ID 또는 지갑 주소를 서버로 전송할 이유는 없으며, 전송하지 않는 것이 훨씬 더 바람직합니다. 이 사이트의 모든 검증기는 로컬에서 실행되며, 오프라인 도구 목록에서 이를 확인할 수 있습니다. 또한 저희의 도구가 사용자 데이터를 업로드하는지 확인하는 방법 안내서를 통해 20초 내에 어떤 사이트든 해당 여부를 확인할 수 있습니다.
FAQ
유효한 체크섬이 있다고 해서 그 숫자가 실제 존재하거나 활성화된 것을 의미할까요?
아닙니다. 체크섬은 단지 숫자들이 내부적으로 일관성이 있음—즉, 그 숫자가 존재할 가능성이 있음을 증명할 뿐입니다. 이는 계좌가 개설되어 있는지, 누가 소유하고 있는지, 잔액이 얼마인지는 알려주지 못합니다. 이 사이트의 모든 검증기는 페이지에 이 내용을 명시하고 있는데, 이 차이점이 중요하기 때문입니다.
잘못된 숫자가 여전히 통과할 가능성은 얼마나 될까요?
방식에 따라 다릅니다. 단일 mod-10 체크 디지트는 약 10개 중 1개의 무작위 오류를 통과시키고, IBAN의 mod 97은 약 97개 중 1개를 통과시키며, 4바이트 Base58Check 체크섬은 약 40억 개 중 1개를 통과시킵니다. 중요한 점은 한 자리 숫자 오류나 두 자리 숫자 교체와 같은 흔한 사람의 실수는 이 모든 방식에서 모두 잡아낸다는 것입니다.
왜 일부 식별자는 체크섬이 전혀 없는 걸까요?
더 오래되거나 단순한 방식들은 오프라인에서 확인하기보다는 등록부에서 조회하도록 설계되었으며, 일부 번호 체계는 그런 관행보다 먼저 생겨났습니다. 이러한 경우 검증기는 길이와 형식만 확인할 수 있습니다.
제 카드 번호나 신분증 번호를 검증기에 붙여넣어도 안전할까요?
검증이 사용자 기기에서 실행되는 경우에만 안전합니다. 체크섬은 이미 가지고 있는 숫자에 대한 산술 연산이므로, 검증기가 이를 서버로 보낼 정당한 이유가 없습니다. 특정 도구가 데이터를 업로드하는지 확인하는 방법에 대한 가이드에 설명된 비행기 모드 테스트를 통해 해당 도구가 로컬에서 실행되는지 확인할 수 있습니다.
체크섬, 해시, 암호화의 차이점은 무엇인가요?
체크섬은 우발적인 오타를 잡아내기 위해 설계된 짧은 체크 디지트입니다. 암호화 해시는 의도적인 변경조차 감지할 수 있고 원본을 복원할 수 없도록 설계된 긴 지문과 같습니다. 암호화는 키가 있어야만 읽을 수 있도록 데이터를 변환합니다. Base58Check는 체크섬을 만들기 위해 해시를 사용하므로 우연히 속이기가 매우 어렵습니다.