Base64는 암호화인가? 아니요 — 차이는 이렇습니다

아니요 — Base64는 암호화가 아닙니다. Base64는 인코딩입니다: 어떤 데이터든 64개의 안전한 문자(A–Z, a–z, 0–9, +, /)로 다시 쓰는, 되돌릴 수 있는 표기법일 뿐입니다. 키도 비밀도 없습니다. Base64 문자열을 본 사람은 누구나 즉시 디코딩할 수 있습니다. 직접 확인해 보세요: SGVsbG8=를 Base64 인코더/디코더에 붙여 넣으면 비밀번호 한 번 묻지 않고 1초도 안 돼 Hello로 풀립니다.

인코딩 vs 암호화 vs 해싱

이 셋은 끊임없이 혼동되지만, 서로 다른 질문에 답합니다:

• **인코딩(Base64, URL 인코딩)**은 비밀성이 아니라 표현 방식을 바꿉니다. 바이너리 데이터가 텍스트 전용 채널 — 이메일 첨부, JSON 페이로드, 데이터 URL — 을 무사히 통과하도록 존재합니다. 누구나 되돌릴 수 있으며, 그것이 설계 의도입니다. (URL 인코딩은 링크에서 비슷한 형제 문제를 풉니다 — URL 인코더/디코더를 참고하세요.)
• **암호화(AES, RSA)**는 키 없이는 데이터를 읽을 수 없게 만듭니다. 되돌릴 수 있지만 키 소유자만 가능합니다. "비밀을 지키는 일"에 실제로 필요한 것이 바로 이것입니다.
• **해싱(SHA-256)**은 아예 되돌릴 수 없는 단방향 지문을 만듭니다 — 무결성 검사에 유용하지, 복원 가능한 데이터를 숨기는 용도가 아닙니다. 해시 생성기에서 동작을 비교해 보세요.

Base64의 뚜렷한 특징: =나 ==(패딩)로 끝나고, 그 64개 문자만으로 이루어진 문자열입니다. 당신이 알아볼 수 있다면 공격자도 알아봅니다.

JWT라는 실례

JSON Web Token이 이 점을 구체적으로 보여 줍니다. JWT는 불투명해 보입니다 — 점으로 구분된 알 수 없는 덩어리 세 개 — 하지만 헤더와 페이로드는 그저 Base64url로 인코딩된 JSON입니다. 아무 JWT나 JWT 디코더에 붙여 넣으면 페이로드가 그대로 열립니다: 사용자 ID, 이메일, 만료 시각, 권한이 아무 키 없이 전부 읽힙니다. 서명(세 번째 부분)은 변조를 막을 뿐, JWT 안의 그 무엇도 숨겨져 있지 않습니다. 그래서 JWT 페이로드에 비밀번호나 API 키를 넣는 것은 실제로 흔히 발생하는 취약점입니다.

왜 오해가 사라지지 않는가

Base64 출력은 사람 눈에 뒤섞인 것처럼 보이고, 그것만으로도 안전하다는 느낌을 주기에 충분합니다. 일부 레거시 시스템은 이를 "난독화"라고 부르기까지 했습니다. 하지만 모든 개발자, 브라우저, 스크립트가 아는 요령을 읽는 사람이 모르기를 바라는 보안은 보안이 아닙니다 — Base64 디코딩은 모든 언어에서 코드 한 줄, 또는 Base64 인코더/디코더에 한 번 붙여 넣기면 끝납니다.

Base64가 잘못된 선택일 때

• 무언가를 "암호화"하기. 설정 파일, URL, localStorage 속 비밀번호·토큰·개인정보 — Base64는 보호를 전혀 더하지 않습니다. 진짜 암호화를 쓰세요.
• 비밀번호 저장. 인코딩도 암호화도 아닌, 느리고 솔트를 적용한 해싱(bcrypt/Argon2)이 필요합니다.
• 용량 절약. Base64는 데이터를 약 33% 키웁니다. 압축의 정반대입니다.
• 무결성 검증. 인코딩된 데이터는 얼마든지 고쳐서 다시 인코딩할 수 있습니다. 변경을 잡아내는 것은 해시 생성기로 만든 해시입니다.

Base64는 딱 한 가지 일 — 바이너리를 텍스트 채널에서 안전하게 만드는 것 — 을 잘합니다. 그 이상을 요구하는 순간, 허공 위에 짓는 셈입니다.