영숫자 문자: 정의, 암호화 활용, 보안

62개. 누군가 "영숫자만 사용하세요"라고 했을 때 사용할 수 있는 서로 다른 기호의 총 개수입니다. 대문자 26개, 소문자 26개, 숫자 10개. 대소문자를 구분하지 않으면 개수는 36개로 줄어듭니다. 이 두 숫자는 모두 중요합니다. 왜냐하면 여러분이 입력해 본 거의 모든 디지털 식별자, 즉 지갑 주소, Wi-Fi 비밀번호, 거래 해시, GitHub 토큰 등은 모두 이 62개 기호 중 일부를 조합하여 만들어지기 때문입니다.

어떤 문자 집합을 선택하고 그 이유는 무엇인지는 대부분의 설명에서 생략되는 부분입니다. 또한 이 부분이 영숫자 문자의 백과사전적 정의와 암호화폐 지갑의 실질적인 보안을 연결하는 핵심이기도 합니다. 이 글에서는 문자 개수, 그 기준, 최신 암호화 기술에서 문자 집합의 하위 집합을 선택하는 방식, 그리고 미국 국가 암호 관리 기관의 현재 지침에 대해 살펴봅니다. 이러한 지침 중 일부는 대부분의 보안 권고 사항이 아직 따라잡지 못한 방식으로 변경되었습니다.

영숫자 문자란 무엇인가요? 정의 및 개수

먼저 정의부터 살펴보겠습니다. 영숫자 문자란 A부터 Z까지의 모든 알파벳(대소문자 구분 없음) 또는 0부터 9까지의 모든 십진수를 말합니다. 이게 전부입니다. 그다음은 계산이 간단합니다. 대소문자를 구분하는 경우 알파벳 26개와 십진수 10개를 합하면 62개의 서로 다른 문자가 되고, 대소문자를 구분하지 않는 경우 36개의 문자가 됩니다. 그 외의 것은 모두 "특별한" 문자입니다. 구두점, 공백, 수학 기호, 악센트가 있는 문자, 이모티콘 등은 영숫자 문자로 간주되지 않습니다.

엔지니어들은 일반적으로 두 가지 약식 표기법 중 하나를 통해 해당 정의를 접합니다. grep, sed, awk와 같은 POSIX 도구는 위의 62개 문자에 해당하는 `[:alnum:]`을 인식합니다. 파이썬, 자바스크립트, 자바, PCRE와 같은 대부분의 최신 정규 표현식은 `\w`를 사용합니다. `\w`의 문제점은 밑줄(_)이 슬쩍 들어간다는 것입니다. 밑줄은 공식적인 영숫자가 아닙니다. 대부분의 프로그래밍 구문에서는 밑줄을 명예로운 문자로 취급하기 때문에 Stripe 키 접두사 `sk_live_`와 AWS 키 접두사 `AKIA`는 밑줄과 대문자, 숫자를 혼합하여 사용하지만 아무도 이상하게 생각하지 않습니다.

이 용어는 어디에서 유래했을까요? 놀랍게도 펀치 카드에서 유래했습니다. 1930년대 IBM의 집계 장비는 문자와 숫자가 혼합된 코드를 나타내는 단일 단어가 필요했고, "영숫자(alphanumeric)"라는 단어가 널리 사용되기 시작했습니다. 1960년대 초 IBM 1401이 출시될 무렵에는 이 단어가 비즈니스 컴퓨터 업계에서 표준 용어가 되었습니다. 이러한 구분은 실제로도 엄격했습니다. "영숫자"로 지정된 필드는 문자 또는 숫자와 같은 모든 문자를 허용했고, "숫자 전용" 필드는 알파벳을 아예 허용하지 않았습니다. 이후 이 단어는 자동차 번호판, IBAN 은행 코드, 전화 키패드 니모닉, 제품 SKU 등 수많은 곳에 퍼져 나갔습니다.

대소문자를 구분할지 무시할지는 겉보기보다 훨씬 중요합니다. 대문자를 허용하면 비밀번호의 엔트로피가 두 배로 증가합니다. 비트코인의 Base58 주소는 의도적으로 대소문자를 모두 유지합니다. 반면 Bech32는 의도적으로 대소문자를 무시합니다. 이러한 선택들은 모두 표현력과 인간의 오류 사이의 절충안입니다. 잘못된 선택을 하면 오타로 인해 손실을 볼 수 있습니다.

ASCII에서 유니코드까지: 간략한 기술적 역사

오늘날 "Alphanumeric"은 60년간 지속된 표준 전쟁에서 살아남은 표준입니다. 대부분의 사용자는 그 중간 어디쯤에 갇혀서 알아채지도 못했습니다.

ASCII가 먼저 등장했습니다. 미국 표준 협회(ASA)에서 1963년에 발표되었고, 5년 후인 1968년에 ANSI X3.4-1968로 공식화되었습니다. 이후 1977년과 1986년에 두 차례 개정되었습니다. 1968년 버전에서는 대문자 A를 65, 소문자 a를 97, 그리고 숫자 0~9를 48~57에 할당했습니다. 지금 바로 에디터를 열어보세요. 'A'의 바이트 값은 여전히 65입니다. 60년이 지나도 변함이 없습니다.

약 40년 동안 ASCII 영숫자 세트는 표준 영숫자 세트였습니다. 그러다 글로벌 웹이 등장하면서 7비트로는 더 이상 충분하지 않게 되었습니다. 그 결과 심각한 문제가 발생했습니다. 이메일이 깨지고, 데이터베이스가 손상되고, 도쿄에서는 완벽하게 작동하는 일본 웹사이트가 미국 노트북에서는 물음표로 가득 찬 벽처럼 보이는 현상이 나타났습니다. 유니코드는 1991년, 모든 문자 체계의 모든 문자에 고유한 번호를 부여하겠다는 야심찬 목표를 가지고 등장했습니다. 그리고 1992년에는 일반 네트워크를 통해 유니코드를 실제로 전송하는 인코딩 방식인 UTF-8이 개발되었습니다. UTF-8의 핵심은 하위 호환성이었습니다. UTF-8의 처음 128개 코드 포인트는 원래 ASCII의 1968바이트와 정확히 동일합니다. 따라서 1991년 이전에 게시된 영어 텍스트는 영원히 제대로 표시되었습니다.

전환점은 2007년 12월에 찾아왔습니다. 그 달, 공개 웹 크롤링 통계에서 UTF-8이 온라인에서 가장 많이 사용되는 인코딩으로 ASCII를 제치고 올라선 것이 마침내 확인되었습니다. 이때부터 "영숫자"는 더 이상 62개의 ASCII 기호만을 의미하지 않게 되었습니다. 유니코드는 이제 키릴 문자, 그리스 문자, 아랍어, 히브리어, 그리고 CJK 문자에 대한 영숫자 블록을 목록화하고 있습니다. 각 문자 체계는 고유한 문자와 숫자를 가지고 있습니다.

하지만 실제로는 국경을 넘어야 하는 소프트웨어는 여전히 원래의 ASCII 하위 집합, 즉 라틴 문자 A~Z와 아라비아 숫자 0~9를 기본적으로 사용합니다. 그 외의 문자는 사용하지 않습니다. 이유는 간단합니다. 모든 키보드는 ASCII 문자를 출력하고, 모든 데이터베이스는 ASCII를 허용하며, 모든 정규 표현식 엔진은 ASCII를 인식합니다. 이 범위를 벗어나면 잘못된 인코딩 버그, 유사한 문자, 그리고 아래에서 다시 설명할 피싱 공격과 같은 다양한 문제가 발생할 수 있습니다.

암호화에서 영숫자 문자 사용: 주소, 해시, 시드

대부분의 일반적인 설명에서 생략되는 부분이 바로 이것입니다. 암호화폐 시스템은 62자리의 영숫자 문자열 전체를 사용하지 않습니다. 신중하게 선택된 부분 집합만 사용합니다. 각각의 부분 집합은 임의적인 미적 기준이 아니라, 문서화된 엔지니어링 타협의 결과입니다.

먼저 비트코인부터 살펴보겠습니다. 기존 비트코인 주소(1 또는 3으로 시작하는 주소)는 Base58로 인코딩됩니다. 이 알파벳은 사토시 나카모토가 직접 손으로 설계했습니다. 방법은 간단합니다. 62개의 영숫자 집합에서 네 개의 문자를 제거합니다. 숫자 0, 대문자 O, 대문자 I, 소문자 l이 제외됩니다. 왜 하필 이 네 개일까요? 포스트잇에 이 네 가지 문자를 알아보기 힘든 글씨로 적어 보세요. 잠시 자리를 비웠다가 5분 후에 돌아와서 구분해 보세요. 구분할 수 없을 겁니다. Base58이 만들어진 목적이 바로 이 문제를 해결하기 위한 것입니다. 그러면 58개의 문자가 남습니다. 일반적인 기존 주소는 26개에서 35개 정도의 문자로 구성되는데, 정말 필요하다면 손으로 직접 베껴 쓸 수 있을 만큼 짧습니다.

SegWit은 2017년 8월에 활성화되었습니다. 이와 함께 두 번째 비트코인 주소 형식인 Bech32(BIP-173에 정의됨)가 도입되었습니다. Bech32는 기존 방식과 다른 접근 방식을 취합니다. 대소문자를 구분하지 않고 모든 주소를 소문자로 사용합니다. 또한 숫자 1과 b, i, o 네 개의 문자가 생략됩니다. 나머지 32개의 문자와 숫자는 내장된 체크섬을 가지고 있어 거의 모든 문자 오타를 자동으로 잡아냅니다. 2021년 11월부터 서비스를 시작한 Taproot는 연구원들이 기존 계산 방식의 특정 오류를 발견한 후 Bech32m(BIP-350)으로 형식을 개선했습니다.

이더리움은 세 번째 방식을 택했습니다. 바로 16진수를 사용하는 것입니다. 이더리움 주소는 '0x' 뒤에 정확히 40개의 16진수 문자가 오는, 총 42개의 문자로 구성됩니다. 16진수는 영숫자를 16개로 제한합니다. 숫자 0~9와 알파벳 a~f만 사용 가능하며, 그 외의 문자는 없습니다. 2015년 당시에는 이 방식이 깔끔해 보였습니다. 하지만 2026처럼 MetaMask에서 16진수 문자열을 오랫동안 들여다봐야 했던 사용자들에게는 오히려 불편하게 느껴졌습니다. EIP-55는 이러한 문제를 해결하기 위해 개발되었습니다. 소문자 주소를 Keccak-256 해시값으로 변환하여 특정 문자를 선택적으로 대문자로 변환하는 방식입니다. 그 결과, 오타를 쉽게 감지할 수 있게 되었습니다. EIP-55는 약 99.975%의 정확도로 오타를 탐지하며, 오탐률은 약 0.0247%에 불과합니다. 0%는 아니지만, 매우 낮은 수치입니다.

해시는 가장 간단한 경우입니다. SHA-256 해시 출력은 256비트이며, 64개의 16진수 문자로 표시됩니다. 이더리움의 Keccak-256도 동일한 길이의 출력을 생성합니다. 비트코인 거래 ID(txid)는 거래 자체의 SHA-256 해시이므로, txid 역시 64개의 영숫자 16진수 문자로 구성됩니다. 블록 탐색기에서 보면 복잡해 보일 수 있지만, 실제로는 순수한 영숫자로 이루어져 있습니다.

시드 구문은 기존의 패턴을 깨뜨립니다. BIP-39 지갑 복구는 암호화폐가 영숫자에서 벗어나 순수하게 알파벳 영역으로 돌아가는 유일한 부분입니다. 이 표준은 128비트 또는 256비트의 엔트로피를 2,048개의 단어로 구성된 고정된 목록에서 추출한 12개 또는 24개의 영어 단어로 인코딩합니다. 각 단어는 소문자로만 구성되며, 숫자나 대소문자 혼합은 허용되지 않습니다. 왜냐하면 이 표준의 설계 목표는 휴대전화 배터리가 방전된 새벽 3시에 종이에 단어를 적는 사람을 가정했기 때문입니다. 숫자는 문자가 갖지 않는 모호성을 야기할 수 있습니다.

각각의 하위 집합은 매우 기술적인 시스템 안에 숨겨진 인간 중심 디자인의 한 부분입니다.

영숫자 비밀번호: 2024년 NIST의 실제 권고 사항은 무엇인가?

인터넷에 있는 대부분의 비밀번호 관련 조언은 몇 년이나 지난 것들입니다. 대소문자를 섞어 쓰고, 숫자를 넣고, 특수 문자를 하나 이상 포함하고, 90일마다 비밀번호를 바꾸라는 규칙은 20년 동안 정설처럼 여겨졌습니다. 하지만 미국 국립표준기술연구소(NIST)는 공식적으로 이러한 규칙들을 폐기했습니다.

미국 국립표준기술연구소(NIST)의 디지털 신원 확인 지침 특별 간행물 800-63B는 2024년 9월에 개정 4판을 최종 확정했습니다. 새로운 지침은 기존 규정을 대폭 수정했다는 점에서 주목할 만합니다. 단일 요소 인증의 최소 비밀번호 길이 권장 사항은 15자로 늘어났습니다. 문자 구성 규칙에 대한 지침은 "하지 말아야 한다"라는 표현으로 변경되어, 서비스는 특정 문자 종류를 요구할 수 없게 되었습니다. 모두가 싫어했던 90일 주기 비밀번호 만료 기능도 삭제되었습니다. 대신 NIST는 서비스 제공업체가 제출된 비밀번호를 유출된 것으로 알려진 비밀번호 목록과 대조하여 검사하도록 요구하고 있습니다.

이러한 변화는 엔트로피 계산으로 정당화됩니다. 62개의 영숫자 문자 풀은 문자당 약 5.95비트를 사용합니다. 전체 95개의 인쇄 가능한 ASCII 문자 풀(영숫자와 특수 문자 포함)은 6.57비트를 사용합니다. 특수 문자 전체를 추가하면 문자당 0.62비트가 증가합니다. 문자 하나를 더 추가하면 전체 5.95비트를 사용하게 됩니다. 문자 길이가 복잡도에 한 자릿수만큼 큰 영향을 미칩니다.

Verizon의 2025년 데이터 침해 조사 보고서에 따르면, 자격 증명 유출은 확인된 모든 침해 진입점 중 22%를 차지합니다. 자격 증명 스터핑(유출된 비밀번호 목록을 자동으로 재사용하는 행위)은 인증 시도의 중간값 기준 19%에서 최대 44%까지 발생합니다. 사용자 중 49%는 여러 서비스에서 비밀번호를 재사용합니다. 이러한 문제들은 비밀번호를 대문자로만 입력하도록 요구하는 것만으로는 해결되지 않습니다.

특수 문자가 없는 긴 영숫자 비밀번호는 복잡성 체크리스트를 충족하기 위해 조합된 짧은 비밀번호보다 해킹하기 어렵습니다. 만약 은행에서 여전히 대문자 하나, 숫자 하나, 특수 문자 하나를 포함하는 12자리 비밀번호를 요구한다면, 이는 이제 미국 연방 표준에 부합하지 않는 정책입니다.

영숫자가 나타나는 다른 곳은 어디인가요?

암호화 분야를 벗어나면, 사람이 입력하고 컴퓨터가 모호함 없이 해석할 수 있는 식별자가 필요한 시스템이라면 어디든 여전히 암호와 영숫자 문자열이 등장합니다.

은행 코드는 쉬운 예입니다. IBAN은 최대 34자의 영숫자로 구성되며 항상 두 글자로 된 ISO 국가 코드로 시작합니다. SWIFT/BIC 코드는 8자 또는 11자로 구성됩니다. 자동차 번호판은 국가마다 다르지만(영국 번호판은 독일 번호판과 전혀 다릅니다), 둘 다 동일한 62자 기호 풀의 영숫자 부분 집합입니다. 차량 식별 번호(VIN)는 전 세계적으로 정확히 17자로 구성되며, VIN에서는 숫자와 시각적으로 구별하기 위해 문자 I, O, Q를 의도적으로 사용하지 않습니다.

API 키는 대부분의 사용자가 신경 쓰지 않고 일상적으로 접하는 예시입니다. Stripe 라이브 키는 `sk_live_` 뒤에 영숫자 토큰이 붙어 열립니다. AWS 액세스 키는 `AKIA` 뒤에 16자리의 영숫자가 붙어 열립니다. 2021년 이후 발급된 GitHub 개인 액세스 토큰은 `ghp_`가 붙습니다. 이러한 접두사는 모두 영숫자로 구성되어 있으며, 서비스 제공업체가 공개 저장소와 로그를 스캔하여 유출된 키를 탐지할 수 있도록 선택되었습니다. 대부분의 경우 이러한 스캔을 통해 공격자가 침입하기 전에 취약점을 발견할 수 있습니다.

QR 코드에 대해 간략하게 언급하겠습니다. ISO/IEC 18004 표준은 특정 45개 문자 집합(대문자, 숫자, 공백 및 몇 가지 구두점)을 일반 바이트 모드보다 효율적으로 인코딩하는 전용 "영숫자 모드"를 정의합니다. 대문자 영숫자 콘텐츠만 포함하는 QR 코드는 동일한 콘텐츠를 일반 바이트로 인코딩했을 때보다 정사각형당 약 1.6배 더 많은 데이터를 저장할 수 있습니다.

Base32, Base58, Base64: 암호화가 부분집합을 선택할 때

이진수를 영숫자 하위 집합으로 매핑하기 위한 몇 가지 인코딩 표준이 존재합니다. 참조 문서는 2006년 IETF에서 발표한 RFC 4648이며, 이 표준은 세 가지 인코딩 방식을 정의합니다.

16진수는 그중 가장 간단합니다. 공식 명칭은 Base16이며, 0부터 9, a부터 f까지 16개의 문자로 구성됩니다. 이더리움 주소, 암호화 해시, 원시 바이트를 읽어야 하는 거의 모든 저수준 디버깅에 사용됩니다. Base32는 좀 더 흥미로운 문자 체계입니다. 32개의 문자로 이루어진 알파벳은 대소문자를 구분하지 않도록 선택되었으며, 일부 변형에서는 시각적으로 혼동을 일으킬 수 있는 숫자 0, 1, 8, 9를 생략하기도 합니다. 2단계 인증을 설정하고 구글 인증 앱에 비밀번호를 입력해 본 사람이라면 대부분 자신도 모르게 Base32를 입력했을 것입니다.

Base64는 가장 널리 사용되는 암호화 방식입니다. 62개의 영숫자와 두 개의 기호 '+'와 '/'로 구성됩니다. URL 안전 변형에서는 이 기호들을 '-'와 '_'로 바꿉니다. Base64는 이메일 첨부 파일을 전송하고, HTML 내의 데이터 URL을 인코딩하며, OAuth용 JSON 웹 토큰을 패키징하는 데 사용됩니다.

비트코인의 Base58은 RFC 4648의 범위를 벗어납니다. 사토시 나카모토가 독자적으로 개발한 것으로, 그의 목표는 문자당 바이트 효율성이 아니라 주소를 사람이 다시 입력하는 수고를 덜어주는 것이었습니다. 그 결과, 다른 누구도 사용하지 않는 독자적인 알파벳이 탄생했습니다. Base85(때로는 Ascii85라고도 함)는 이와 반대 방향으로 작동합니다. 4바이트를 5개의 문자로 압축하며, PDF나 PostScript 파일에서 사용되는데, 이러한 파일 형식에서는 높은 밀도로 인해 가독성이 다소 떨어지더라도 사용 가치가 있습니다.

흔히 발생하는 함정: 시각적 혼동 및 유사품

암호화 기술이 영숫자 하위 집합을 선택하는 이유는 누구나 실수를 저지르는 이유와 같습니다. 몇몇 문자 쌍이 대부분의 문제를 일으킵니다.

혼동하기 쉬운 대표적인 문자로는 숫자 0과 대문자 O, 숫자 1, 소문자 l, 대문자 I, 소문자 l과 대문자 I 등이 있습니다. 비트코인 Base58은 이러한 혼동을 피하기 위해 이 네 가지 문자를 모두 제거합니다. 다른 시스템들은 각기 다른 방식으로 혼동을 완화합니다. 차량 식별 번호(VIN)는 I, O, Q를 제거하고, 일부 금융 코드는 O를 아예 제거하며, 국가별 차량 번호판 규정 중에는 해당 국가의 글꼴에서 숫자 0과 가장 비슷하게 보이는 문자를 금지하는 경우도 있습니다.

더욱 까다롭고 최근에 나타난 문제는 유니코드 동형 문자 공격입니다. 이 아이디어는 2001년 예브게니 가브릴로비치와 알렉스 곤트마커의 논문에 처음 기술되었습니다. 동형 문자 공격은 시각적으로 동일한 문자를 다른 문자 체계에서 서로 바꾸는 것입니다. 예를 들어, 라틴어 'a'(U+0061) 대신 키릴 문자 'а'(U+0430)를 사용하는 것입니다. 이러한 문자 치환이 포함된 도메인 이름을 등록하면 실제 은행 웹사이트와 구별할 수 없는 피싱 페이지를 호스팅할 수 있습니다. 최신 브라우저는 도메인에 여러 문자 체계가 혼합되어 있는 경우 'xn--80akhbyknj4f'와 같은 원시 Punycode 표현을 표시합니다. 이러한 방어 체계는 대부분의 공격을 차단하지만, 모든 공격을 차단하는 것은 아닙니다.

2026에서 강력한 영숫자 비밀번호를 만드는 방법

세 가지 규칙. 모두 NIST의 수학 공식에서 직접 도출된 것입니다.

첫째, 문자 종류보다 길이가 중요합니다. 최소 16자 이상을 목표로 하세요. 이 규칙은 시스템이 문자 및 숫자만 허용하든 전체 ASCII 문자 집합을 허용하든 관계없이 적용됩니다.

두 번째: 비밀번호를 외워야 한다면, 암호를 사용하세요. 방대한 단어 목록(Diceware 목록이 대표적인 예입니다)에서 무작위로 네 단어를 뽑아 만든 암호문은 사람이 직접 만들어내는 짧은 암호보다 훨씬 안전합니다.

세 번째: 그 외의 모든 경우에는 암호 관리자를 사용하세요. 암호 관리자가 직접 읽거나 입력할 필요가 없는 긴 영숫자 문자열을 생성하도록 하세요. 암호 관리자가 출력을 처리하면 출력의 가독성은 더 이상 중요하지 않습니다.

빠른 참조: 영숫자 개수 및 예시

대소문자를 구분하면 62개, 구분하지 않으면 36개입니다. 숫자는 ASCII 코드 48~57, 대문자는 65~90, 소문자는 97~122를 사용합니다. 이 전체 집합을 정규 표현식 `[A-Za-z0-9]` 또는 POSIX 클래스 `[:alnum:]`으로 일치시킬 수 있습니다. 이 62개의 기호 풀은 이번 주에 여러분이 접하게 될 거의 모든 디지털 식별자의 기반이 됩니다. 비밀번호, API 키, IBAN, 차량 번호판, 거래 ID, 그리고 여러분이 생성하는 모든 지갑 주소까지 모두 이 기호들로 이루어져 있습니다.

Mathis Curcio

Mathis Curcio is a senior content strategist and NFT specialist at Plisio. With over 5 years of experience in the Web3 space, Mathis focuses on the evolution of NFT ecosystems, digital collectibles, and decentralized ownership models. He creates accessible, insight-driven content that bridges the gap between blockchain innovation and mainstream adoption. His expertise spans NFT market trends, use cases across art and gaming, and the infrastructure powering next-generation tokenized assets.