가이드 · 2026년 8월 21일 · 읽는 시간 8분

Base64는 암호화가 아니다 — 인코딩·암호화·해싱, 뭐가 다른가

코드 리뷰를 하다 보면 잊을 만하면 만나는 장면이 있다. 비밀번호를 Base64로 바꿔 저장해 놓고 “암호화했다”고 적어 둔 주석. API 키를 Base64로 감싸 프론트엔드에 심어 두고 “숨겼다”고 믿는 설정 파일. 결론부터: Base64는 보안 기능이 전혀 없다.누구나 1초 만에 원문으로 되돌릴 수 있다. 이 글은 인코딩·암호화·해싱이라는, 자주 섞여 쓰이지만 완전히 다른 세 가지 개념을 실무 관점에서 구분한 것이다.

Base64는 그냥 ‘표기법 변환’이다

Base64의 목적은 은닉이 아니라 운반이다. 이미지 같은 바이너리 데이터를 텍스트만 오갈 수 있는 통로(JSON, 이메일, URL)로 보내야 할 때, 데이터를 6비트씩 잘라 64개의 안전한 문자(A-Z, a-z, 0-9, +, /)로 바꿔 적는 것뿐이다. 규칙이 공개돼 있고 키도 없으니, 디코딩 함수 한 줄이면 원문이 그대로 나온다.

• 변환 규칙이 공개되어 있다 → 비밀이 아니다
• 키가 없다 → 되돌리는 데 아무 조건이 없다
• 크기가 약 33% 커진다 → 압축도 아니다
• 끝의 =는 길이를 맞추는 패딩일 뿐이다

즉 Base64로 바뀐 문자열은 “영어를 모스부호로 적은 것”과 같다. 모양이 낯설 뿐, 읽는 법을 아는 사람(=모든 개발자와 모든 도구)에게는 평문이다.

세 가지 개념 비교

그런데 왜 자꾸 헷갈릴까 — JWT라는 오해 제조기

가장 큰 혼란의 진원지는 JWT다. JWT 토큰을 열어 보면 알아볼 수 없는 문자열이라 암호화된 것처럼 보이지만, 헤더와 페이로드는 그냥 Base64URL 인코딩이다. 토큰을 디코더에 넣으면 사용자 ID, 이메일, 권한 정보가 평문으로 다 보인다. JWT의 세 번째 조각(서명)은 위·변조를탐지하는 장치일 뿐, 내용을 숨기는 장치가 아니다. 그래서 JWT 페이로드에 전화번호·주민번호 같은 민감정보를 넣는 순간 그대로 유출이다. 실제로 토큰 하나를 JWT 디코더에 넣어 보면 “암호화”라는 착각이 3초 만에 깨진다.

실무에서 만나는 잘못된 사용 3가지

1. 비밀번호를 Base64로 저장 — DB가 털리면 전 계정이 즉시 평문 노출된다. 비밀번호는 암호화도 아니고 해싱이 정답이다. 그것도 SHA-256 단독이 아니라 bcrypt·Argon2처럼 일부러 느리게 설계된 해시 + 솔트를 써야 무차별 대입을 버틴다.
2. API 키를 Base64로 ‘숨겨서’ 프론트에 배포 — 브라우저 개발자 도구를 여는 순간 끝이다. 프론트엔드에 내려간 값은 어떤 변환을 거치든 공개된 값이다. 비밀 키는 서버에만 두고, 프론트는 서버를 경유해 호출해야 한다.
3. “해시를 복호화했다”는 표현 — 해시는 원리상 되돌릴 수 없다. 인터넷의 “MD5 복호화” 사이트들은 복호화가 아니라, 미리 계산해 둔 값 목록(레인보우 테이블)에서 일치 항목을 찾아 주는 것이다. 단순한 비밀번호가 뚫리는 이유이자, 솔트가 필요한 이유다.

그럼 Base64는 언제 쓰나

• 작은 이미지를 CSS/HTML에 직접 넣을 때 (data URI)
• JSON 페이로드에 바이너리(파일, 서명값)를 실어 보낼 때
• HTTP Basic 인증 헤더 형식 (단, 반드시 HTTPS 위에서 — Base64 자체는 보호가 아니므로)
• 이메일 첨부(MIME) 등 텍스트 전용 프로토콜에 바이너리를 통과시킬 때

전부 “안전하게 숨기기”가 아니라 “깨지지 않게 운반하기”다. 이 한 문장만 기억해도 Base64를 잘못 쓸 일은 없다. 변환 결과가 궁금하면 Base64 변환 도구에서 인코딩과 디코딩이 얼마나 자유롭게 오가는지 직접 확인해 보자 — 그게 곧 “보안이 아니다”의 증명이다.

#Base64 #인코딩 #암호화 #해싱 #JWT #보안기초