Base64가 뭐고 왜 계속 나타나는 거야

API 디버깅하고 있어. 응답 어딘가에 이런 게 보여:

SGVsbG8gV29ybGQh

아니면 이메일 원본 소스를 보는데 키보드 난타처럼 보이는 텍스트 덩어리를 발견해. 또는 CSS에 data:image/png;base64,로 시작하는 배경 이미지가 있고 그 뒤로 문자 벽이 펼쳐져.

그게 Base64야. 한번 보기 시작하면 어디든 있어.

Base64가 실제로 뭔지

바이너리 데이터—이미지, 파일, 일반 텍스트가 아닌 모든 것—는 텍스트용으로 설계된 시스템이랑 잘 안 맞아. 이메일은 ASCII 문자용으로 만들어졌어. URL은 제한된 문자 세트가 있고. JSON은 원시 바이너리를 처리 못 해.

Base64는 바이너리 데이터를 64개의 "안전한" 문자 문자열로 변환해: A-Z, a-z, 0-9, +, /. 어떤 바이너리 파일이든 텍스트 전용 시스템을 통과할 때 깨지지 않는 텍스트 문자열이 돼.

암호화 아니야. 압축도 아니고. 그냥 인코딩—같은 데이터를 다르게 표현하는 거야.

어디서 볼 수 있어

이메일 첨부파일. PDF를 이메일로 보낼 때 Base64로 인코딩되고, 텍스트로 전송되고, 받는 쪽에서 디코딩돼.

Data URI. data:image/png;base64,... 문법은 이미지를 HTML이나 CSS에 직접 임베드해. 별도 파일 요청이 필요 없어.

API 인증. Basic auth는 username:password를 Base64 문자열로 보내. (그래서 HTTP로 basic auth 쓰면 안전하지 않은 거야—Base64는 암호화가 아니거든.)

JWT. JSON Web Token은 점으로 연결된 세 개의 Base64 인코딩된 JSON 객체야.

JSON 안의 바이너리 데이터. JSON은 원시 바이트를 포함 못 해서 바이너리를 먼저 Base64 인코딩해.

인코딩 vs 암호화

사람들이 이걸 계속 헷갈려해.

Base64 인코딩: 누구나 되돌릴 수 있어. 키 필요 없어. 안전하지 않아. 그냥 재포맷팅.

암호화: 올바른 키로만 되돌릴 수 있어. 실제로 안전해.

비밀번호 없이 디코딩할 수 있으면 암호화가 아니야. Base64는 Base64가 뭔지 모르는 사람한테만 데이터를 "숨겨"—실제로 읽으려는 사람은 아무도 모르지 않아.

비밀번호를 Base64로 저장하지 마. API의 Base64 데이터가 비공개라고 가정하지 마. 그냥 이상하게 보이는 텍스트야.

크기 문제

Base64는 데이터 크기를 약 33% 증가시켜. 100KB 이미지가 Base64 인코딩되면 ~133KB가 돼.

이게 data URI에선 중요해. CSS에 큰 이미지를 Base64로 임베드하면 파일이 커지고 따로 캐시될 수 없어. 작은 아이콘엔 좋아. 히어로 이미지엔 나빠.

실전 사용

디버깅. API 응답에 Base64 보여? 디코딩해서 안에 뭐가 있는지 봐.

작은 이미지 임베딩. 1-2KB 이하 아이콘은 HTTP 요청을 절약하려고 data URI로 임베드할 가치가 있어.

텍스트 채널로 바이너리 전달. JSON에 파일 내용을 포함해야 해? Base64 인코딩해.

JWT 읽기. 각 섹션을 디코딩해서 헤더, 페이로드를 보고 토큰이 포함하는 클레임을 이해해.

---

Base64는 복잡하지 않아. 그냥 어떤 데이터든 텍스트 문자열로 바꾸는 방법이야. 인식하고, 필요할 때 디코딩하고, 보안은 제공하지 않는다는 걸 알아둬—그냥 호환성만.