Base64는 암호화가 아닙니다 — 언제 쓰는가

Base64는 암호화가 아니라 표현 방식입니다. 누구나 원래대로 되돌릴 수 있습니다. 키가 없고 변환 규칙이 공개되어 있어서, Base64 인코딩·디코딩에서 방향을 「디코딩」으로 두고 7KCc7YKs66Gc를 넣으면 바로 제킬로가 나옵니다. 비밀번호나 토큰을 Base64로 바꿔 두는 것은 숨기는 것이 아닙니다. Base64의 목적은 바이너리 데이터를 텍스트만 지나갈 수 있는 통로로 깨지지 않게 옮기는 것입니다.

Base64가 하는 일

RFC 4648에 따르면 Base64는 입력을 3바이트(24비트)씩 묶어 6비트 네 덩어리로 나누고, 각 덩어리를 글자 하나로 적습니다. 쓰는 글자는 A–Z, a–z, 0–9, +, / 64개와 길이를 맞추는 =입니다.

입력	바이트 수	Base64
ZEKILO	6	WkVLSUxP
ZEKIL	5	WkVLSUw=
제킬로	9 (UTF-8)	7KCc7YKs66Gc
ゼキロ	9 (UTF-8)	44K844Kt44Ot

Base64가 다루는 것은 글자가 아니라 바이트입니다. 텍스트는 먼저 UTF-8 같은 문자 인코딩으로 바이트가 된 뒤에 변환되므로, 문자 인코딩이 다르면 결과도 달라집니다. 브라우저의 btoa는 U+00FF보다 큰 글자가 있으면 InvalidCharacterError를 던집니다. 한글은 TextEncoder로 UTF-8 바이트를 만든 뒤 인코딩해야 합니다.

인코딩, 암호화, 해시의 차이

구분	되돌리기	키	목적
인코딩(Base64)	누구나 가능	없음	형식 바꾸기
암호화(AES 등)	키가 있어야 가능	있음	내용 감추기
해시(SHA-256 등)	불가능(한 방향)	없음	내용이 같은지 확인

RFC 4648 12절은 Base 인코딩이 비밀번호처럼 알아보기 쉬운 정보를 눈에 띄지 않게 할 뿐, 기밀성을 주지 않는다고 적고 있습니다.

대표적인 예가 HTTP Basic 인증입니다. RFC 7617의 예시 헤더 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==의 뒷부분을 디코딩하면 Aladdin:open sesame, 곧 사용자 이름과 비밀번호가 그대로 나옵니다. 같은 문서는 이 방식을 TLS 같은 외부 보안 체계와 함께 쓰지 않으면 안전한 인증 방법으로 보지 않는다고 적습니다. JWT의 헤더와 페이로드도 Base64URL로 적혀 있을 뿐이라 누구나 읽을 수 있습니다. 자세한 내용은 JWT 디코딩과 서명 검증의 차이에서 다룹니다.

언제 쓰는가

• 이메일 첨부(MIME): 한 줄이 76자를 넘지 않게 줄을 나눕니다(RFC 2045).
• Data URL: data:text/plain;base64,WkVLSUxP처럼 작은 파일을 HTML·CSS 안에 직접 넣습니다(RFC 2397).
• JSON·XML 필드: 이미지나 서명 값 같은 바이너리를 텍스트 필드에 담습니다.
• PEM 인증서·키: 64자마다 줄을 나눕니다(RFC 7468).
• JWT와 URL 파라미터: 아래의 URL-safe 변형을 씁니다.

RFC 4648은 참조하는 규격이 따로 정하지 않는 한 줄바꿈을 넣지 말라고 합니다. 줄바꿈이 필요한지는 받는 쪽 형식에 맞추세요.

URL-safe 변형과 패딩

표준 글자 가운데 +와 /는 URL과 파일 이름에서 다른 뜻으로 쓰입니다. 그래서 RFC 4648 5절은 두 글자를 -와 _로 바꾼 변형을 정의합니다. 바이트 FB FF BF는 표준에서 +/+/, URL-safe에서 -_-_가 됩니다.

패딩 =는 출력 길이를 4의 배수로 맞춥니다. 마지막에 1바이트가 남으면 글자 2개와 ==, 2바이트가 남으면 글자 3개와 =가 붙습니다. RFC 4648은 참조하는 규격이 따로 정하지 않는 한 패딩을 붙이라고 하고, JWT가 쓰는 Base64URL(RFC 7515)은 패딩을 뺍니다. 패딩이 없어도 길이로 복원할 수 있어서 WkVLSUw는 ZEKIL로 디코딩됩니다. 길이를 4로 나눈 나머지가 1이면 올바른 Base64가 아닙니다.

디코딩이 실패하면 글자부터 확인하세요. WkVLSUxP!는 9번째 글자 !가 Base64 글자가 아니어서 오류입니다.

크기는 4/3로 늘어난다

3바이트가 4글자가 되므로, 패딩을 붙인 출력 길이는 4 × ⌈n ÷ 3⌉입니다. 약 33% 늘어납니다.

원본	Base64 길이
6바이트	8자
9바이트	12자
1 MiB (1,048,576바이트)	1,398,104자
3 MiB (3,145,728바이트)	4,194,304자 (4 MiB)

줄바꿈을 넣으면 그만큼 더 늘어납니다. 큰 파일을 Base64로 바꿔 JSON에 넣으면 전송량과 메모리 사용이 함께 늘어나므로, 큰 파일은 바이너리 그대로 보내는 방법을 먼저 검토하세요.

정리

• Base64는 형식을 바꾸는 인코딩입니다. 키가 없으므로 내용을 감추지 못합니다.
• 비밀번호, API 키, 개인 정보는 Base64로 바꿔도 그대로 드러납니다. 감추려면 암호화와 TLS를 쓰세요.
• URL과 JWT에는 -, _를 쓰는 URL-safe 변형을 쓰고, 패딩 규칙은 받는 쪽 규격에 맞춥니다.
• 크기는 약 4/3배가 됩니다.
• 값을 확인할 때는 Base64 인코딩·디코딩을 쓰세요. 입력값은 브라우저 안에서만 처리됩니다.