이미지가 안 뜨는데 알고 보니 Base64 문제였던 썰 — 인코딩 완전 정복

이메일 템플릿 작업을 하다가 이미지가 모든 클라이언트에서 깨져 보이는 문제가 생겼어요. img 태그는 멀쩡해 보이고, URL도 이상 없어 보이고, HTML 구조도 문제없었어요. 서버도 확인하고, CDN도 확인하고, HTML도 세 번 읽었는데 원인을 못 찾겠는 거예요. 두 시간쯤 지나서 src 값을 디코더에 붙여넣어 봤더니 바로 보였어요. 표준 Base64 문자열을 URL 컨텍스트에 그냥 넣은 거였어요. + 기호가 공백으로, / 기호가 경로 구분자로 해석되면서 데이터가 조용히 뭉개졌던 거죠. 두 시간, 문자 하나. 그날 Base64를 제대로 공부했어요.

Base64가 뭔지, 그리고 뭐가 아닌지

Base64는 바이너리 데이터를 텍스트로 바꾸는 인코딩이에요. 이미지, 오디오, PDF 같은 바이트 스트림을 64개 출력 가능한 ASCII 문자로 표현해요. 그 목적이 전부예요. 텍스트만 처리할 수 있는 시스템 — 이메일, URL, HTML 속성, JSON 문자열 — 에서 바이너리 데이터를 안전하게 주고받기 위한 거예요.

64개 문자는 이렇게 구성돼요: A-Z (26개), a-z (26개), 0-9 (10개), + 와 / (2개). 합쳐서 64. 패딩에는 = 를 써요. 어떤 바이너리 데이터든 이 문자들만으로 표현할 수 있어요.

원본 텍스트:   안녕 (UTF-8)
바이트:        EC 95 88 EB 85 95
Base64 출력:   7JWI65WV

원본 텍스트:   Hello
Base64 출력:   SGVsbG8=

원본 JSON:     {"id": 1}
Base64 출력:   eyJpZCI6IDF9

알고리즘이 실제로 어떻게 동작하나

Base64는 입력을 3바이트(24비트) 단위로 처리해요. 24비트를 6비트씩 4개로 잘라서 각각 64개 문자 중 하나로 매핑하는 거예요. 그래서 입력 3바이트가 항상 출력 4문자가 되는 거고요.

'Man' 인코딩 (3바이트: 77, 97, 110):

바이너리: 01001101 01100001 01101110
         └──────────────────────┘
               24비트 합계

6비트씩 4개로 분리:
 010011 | 010110 | 000101 | 101110
   19   |   22   |    5   |   46
    T   |    W   |    F   |    u

결과: 'TWFu'

패딩 예시 — 'Ma' 인코딩 (2바이트):
바이너리: 01001101 01100001 [없는 바이트 → 0으로 채움]
 010011 | 010110 | 000100 | (패딩)
    T   |    W   |    E   |    =
결과: 'TWE='

패딩 예시 — 'M' 인코딩 (1바이트):
바이너리: 01001101 [없는 2바이트 → 0으로 채움]
 010011 | 010000 | (패딩) | (패딩)
    T   |    Q   |    =   |    =
결과: 'TQ=='

끝에 붙는 = 기호는 디코더한테 실제 데이터 바이트가 몇 개인지 알려줘요. = 하나면 마지막 그룹이 2바이트, == 이면 1바이트였다는 뜻이에요. = 없으면 입력이 3의 배수였다는 거고요.

언제 쓰면 좋고 언제 쓰면 손해인가

Base64는 도구예요. 무조건 좋거나 무조건 나쁜 게 아니라 상황에 따라 달라요. 명확하게 정리했어요:

표준 Base64 vs URL-safe Base64

표준 Base64는 알파벳에 + 와 / 를 써요. 이 두 문자가 URL, HTML 폼, 쿼리 파라미터에서 특수하게 해석돼서 데이터가 조용히 깨지는 거예요. 제가 두 시간을 날린 이유예요.

표준 Base64 알파벳:
A-Z a-z 0-9 + /  (= 패딩)

URL-safe Base64 알파벳 (RFC 4648 §5):
A-Z a-z 0-9 - _  (= 패딩, 생략 가능)

같은 데이터, 다른 인코딩:
표준:      SGVsbG8+V29ybGQ=  ← + 기호가 URL에서 깨져요
URL-safe:  SGVsbG8-V29ybGQ=  ← 어디서나 안전해요

URL-safe를 써야 하는 경우:
- JWT 토큰 (헤더.페이로드.서명 전부 URL-safe)
- 쿼리 파라미터 (?token=SGVsbG8-V29ybGQ)
- 파일명이나 URL 경로 구성 요소
- HTML 속성 값에 들어가는 경우

표준 Base64로 충분한 경우:
- 이메일 MIME 첨부 파일
- HTTP 응답 바디 (URL 아닌 경우)
- CSS/HTML 안의 data URI

크기 오버헤드 계산

33% 오버헤드라는 말을 정확히 이해하면 의사결정이 쉬워져요. 입력 3바이트 → 출력 4문자, 각 문자는 1바이트. 비율이 4/3 = 1.333이니까 항상 정확히 약 33% 커지는 거예요.

크기 오버헤드 실제 계산:

원본 크기     Base64 크기    오버헤드
1 KB          1,368 B        +344 B (+33.6%)
10 KB         13,336 B       +3,336 B (+33.4%)
100 KB        133,400 B      +33,400 B (+33.4%)
1 MB          1.33 MB        +334 KB (+33.4%)

실제 예시 — 200x200 PNG 아이콘:
원본 파일:      ~15 KB
Base64 변환:    ~20 KB
추가 용량:      ~5 KB
아낀 HTTP 요청: 1회
빠른 네트워크 왕복 시간: 20~50ms
결론: 인라인하는 게 이득. 5KB < 요청 1회.

실제 예시 — 히어로 이미지:
원본 파일:      ~250 KB
Base64 변환:    ~333 KB
추가 용량:      ~83 KB
아낀 HTTP 요청: 1회
결론: 인라인하면 손해. 83KB 다운로드 > 캐시된 요청 1회.

자주 묻는 질문