Base64 인코딩의 원리와 실전 활용법

웹 개발을 하다 보면 Base64를 자주 마주칩니다. 이미지를 문자열로 바꾸거나, API 인증 헤더를 만들거나. 근데 정확히 왜 필요한 걸까요?

문제: 이진 데이터를 텍스트로 전송하고 싶다

컴퓨터의 모든 데이터는 결국 0과 1입니다. 이미지, 음악 파일, 압축 파일 모두 이진(binary) 데이터죠.

문제는 이메일이나 JSON 같은 시스템은 텍스트만 다룬다는 겁니다. 이진 데이터를 그대로 넣으면 깨지거나 문제가 생깁니다.

해결책? 이진 데이터를 안전한 텍스트 문자로 변환합니다. 그게 Base64입니다.

Base64의 원리

"Base64"라는 이름은 64개의 문자를 사용한다는 뜻입니다.

A-Z (26) + a-z (26) + 0-9 (10) + '+' + '/' = 64

그리고 패딩용 =도 있습니다.

변환 과정

원본 데이터를 비트(0과 1)로 변환
6비트씩 끊어서 그룹화 (8비트가 아니라 6비트!)
각 6비트 그룹을 Base64 문자로 변환
3바이트(24비트) 단위로 처리. 남으면 =로 패딩

"Hi" 변환 예시:

H = 01001000, i = 01101001

연결: 01001000 01101001

6비트씩: 010010 | 000110 | 1001(패딩필요)

→ SGk=

실제 활용 사례

1. Data URL (이미지 인라인)

작은 이미지를 HTTP 요청 없이 HTML/CSS에 직접 넣을 수 있습니다.

장점: HTTP 요청 감소. 단점: HTML 파일 크기 증가, 캐싱 불가

2. HTTP Basic 인증

사용자명:비밀번호를 Base64로 인코딩해서 헤더에 넣습니다.

Authorization: Basic dXNlcjpwYXNz

(user:pass를 Base64 인코딩한 결과)

⚠️ 주의: Base64는 암호화가 아닙니다! 누구나 디코딩할 수 있어요. 반드시 HTTPS와 함께 사용하세요.

3. 이메일 첨부파일

이메일은 텍스트 프로토콜(SMTP)을 사용합니다. 첨부파일은 Base64로 인코딩되어 전송됩니다.

4. JWT 토큰

JWT의 header와 payload는 Base64Url로 인코딩됩니다. (Base64와 비슷하지만 URL에 안전한 문자 사용)

Base64의 단점

크기 증가: 원본보다 약 33% 커집니다 (3바이트 → 4문자)
암호화 아님: 난독화일 뿐, 누구나 디코딩 가능
처리 오버헤드: 인코딩/디코딩에 CPU 사용

언제 쓰고 언제 쓰지 말아야 할까?

O 쓰면 좋은 경우	X 쓰지 말아야 할 경우
작은 이미지 인라인	큰 파일 전송 (느리고 비효율)
JSON에 바이너리 포함	민감한 정보 숨기기 (암호화 아님!)
텍스트 프로토콜 호환	대용량 데이터 (크기 33% 증가)

JavaScript에서 사용하기

// 인코딩

btoa("Hello") // "SGVsbG8="

// 디코딩

atob("SGVsbG8=") // "Hello"

참고: btoa/atob는 ASCII만 지원합니다. 한글 등 유니코드는 추가 처리가 필요해요.