Base64는 생각보다 훨씬 많은 곳에서 사용됩니다. 브라우저의 Data URL, JSON 안의 바이너리 데이터, JWT 세그먼트, 이메일 MIME 첨부까지 모두 Base64와 연결됩니다. 하지만 가장 흔한 오해도 있습니다. Base64를 보안 기술로 착각하는 것입니다. Base64는 인코딩이지 암호화가 아닙니다.
1. Base64란 무엇인가
Base64는 바이너리 데이터를 텍스트 전송에 적합한 ASCII 문자열로 바꾸는 인코딩 방식입니다. 텍스트 중심 채널에서도 데이터 손상 없이 전달하기 위해 사용됩니다.
표준 Base64 문자 집합은 A-Z, a-z, 0-9, +, /이며, 필요하면 =로 패딩합니다.
2. 왜 용량이 약 33% 증가하는가
Base64는 3바이트(24비트)를 4개의 6비트 그룹으로 나눠 문자로 매핑합니다.
- 입력 3바이트가 출력 4문자가 됩니다.
- 비율이 4:3이라 평균적으로 약 33% 커집니다.
- 길이가 3의 배수가 아니면 끝에
=패딩이 붙습니다.
따라서 큰 파일을 Base64로 만들어 JSON에 넣으면 전송량과 파싱 비용이 크게 늘 수 있습니다.
3. Base64, 암호화, 해시의 차이
| 기술 | 목적 | 역변환 | 주요 용도 |
|---|---|---|---|
| Base64 | 데이터를 텍스트로 표현 | 가능 | 바이너리 전송, Data URL, JWT 세그먼트 |
| 암호화 | 기밀성 보호 | 키가 있으면 가능 | AES, RSA 등 민감정보 보호 |
| 해시 | 요약값 생성 | 불가능 | 무결성 검증, 비밀번호 저장 |
비밀번호를 Base64로만 변환해 저장하면 보호되지 않습니다. 비밀번호는 Argon2나 bcrypt 같은 강한 해시를 사용해야 합니다.
4. Base64가 적합한 실무 상황
1. API에서 소형 바이너리 전달
짧은 서명, 작은 인증서 조각, 썸네일 같은 소형 데이터는 JSON 내 전달이 가능합니다. 대용량 파일은 multipart 업로드나 오브젝트 스토리지 URL을 권장합니다.
2. Data URL로 작은 리소스 인라인
data:image/png;base64,... 형태는 작은 아이콘에 유용합니다. 하지만 큰 이미지에는 문서 크기 증가와 캐시 비효율 문제가 생깁니다.
3. JWT의 Base64URL
JWT는 URL 안전 변형인 Base64URL을 사용합니다. +, /를 -, _로 바꾸고 보통 = 패딩을 생략합니다.
5. Base64URL이란
Base64URL은 새로운 알고리즘이 아니라 URL 친화적으로 바꾼 Base64 변형입니다.
+->-/->_- 끝의
=는 자주 생략
6. 자주 발생하는 오류와 점검 순서
- 문자 집합 불일치: Base64URL을 표준 Base64로 디코딩해 실패.
- 패딩 누락: 일부 라이브러리는
=복원이 필요. - 이중 인코딩: encode를 두 번 수행해 decode 한 번으로 복원 안 됨.
- 문자 인코딩 혼선: UTF-8/UTF-16 처리 차이로 깨짐.
문제 해결 시에는 입력 형식 확인 -> 패딩/문자 집합 검증 -> 왕복 테스트 순서가 가장 안전합니다.
7. 성능과 보안 권장사항
- 대형 바이너리를 Base64 문자열로 JSON에 직접 넣지 않기.
- 서비스 간 Base64 vs Base64URL 규약을 명확히 합의하기.
- Base64를 보안 장치로 사용하지 않기.
- 디코드 실패율을 모니터링해 연동 문제를 조기 발견하기.
마무리
Base64의 핵심 가치는 보안이 아니라 호환성입니다. 크기 증가 특성과 URL 변형 차이를 이해하면, 웹/서버 통합에서 더 안정적인 설계를 할 수 있습니다.