Base64로 바꿨더니 용량이 33% 늘어난 이유와 써야 할 곳 안 써야 할 곳

이미지 파일을 API로 보내려고 Base64로 바꿨습니다. 그런데 원본이 3MB였는데 결과 문자열이 4MB가 넘습니다. 변환인데 왜 커지는지 이해가 되지 않습니다.

설정 문제가 아닙니다. 결론부터 말하면 Base64는 압축이 아니라 표현 방식을 바꾸는 작업이고, 그 구조상 반드시 약 33% 커집니다.

왜 하필 33%인가

컴퓨터는 파일을 8비트짜리 바이트 단위로 저장합니다. 그런데 Base64는 이름 그대로 64가지 문자만 사용합니다. 64가지를 표현하는 데 필요한 비트는 6비트입니다.

여기서 어긋남이 생깁니다. 원본은 8비트 단위인데 결과는 6비트 단위입니다. 그래서 Base64는 원본을 3바이트씩 묶어 24비트로 만든 다음, 그것을 6비트씩 네 조각으로 다시 나눕니다. 각 조각이 문자 하나가 됩니다.

정리하면 이렇습니다.

원본 3바이트 → 결과 4글자

4를 3으로 나누면 약 1.33입니다. 33% 증가는 여기서 나옵니다. 파일 종류나 내용과 무관하게 항상 같은 비율입니다.

여기에 두 가지가 조금 더 붙습니다. 원본 길이가 3의 배수가 아니면 마지막 묶음을 채우려고 등호 문자가 한두 개 붙고, 일부 형식은 일정 길이마다 줄바꿈을 넣습니다.

이 비용을 감수할 만한 상황

33%가 늘어나는데도 Base64를 쓰는 이유는 하나입니다. 텍스트만 통과하는 길에 바이너리를 실어야 하기 때문입니다.

마지막 줄이 가장 중요합니다. Base64로 감싼 문자열은 디코더에 붙여넣으면 즉시 원문이 나옵니다. 보안 수단이 아닙니다.

쓰기로 했다면 순서가 중요합니다

압축과 Base64를 둘 다 해야 한다면 순서에 따라 결과가 크게 달라집니다.

1. 먼저 압축합니다. 이미지라면 형식과 품질을 조절해 파일 자체를 줄입니다.
2. 그다음 Base64로 감쌉니다. 파일 인코더에서 변환하고 결과 길이를 확인합니다.
3. 전송 한도와 비교합니다. 늘어난 크기가 API의 요청 크기 제한 안에 들어오는지 봅니다.

반대로 하면 손해입니다. Base64로 부풀린 문자열을 압축하면, 원본을 압축한 뒤 감싼 것보다 결과가 큽니다. Base64 문자열은 이미 규칙성이 흐트러져 있어 압축이 잘 듣지 않습니다.

결과가 예상보다 더 클 때

인코딩을 쓸 자리를 잘못 고르는 경우

압축 기능으로 오해합니다. Base64는 크기를 줄이지 않고 늘립니다. 이름에 인코딩이 들어가 압축과 혼동되는 경우가 많습니다.

보안 목적으로 씁니다. 되돌리는 데 아무런 자격이 필요 없습니다. 로그나 설정 파일에 Base64로 비밀번호를 넣는 것은 평문으로 넣는 것과 실질적으로 같습니다.

파일 업로드가 가능한데도 감쌉니다. 업로드 경로가 있다면 원본을 그대로 보내는 편이 33% 이득입니다.

큰 파일에 사용합니다. 수십 MB 파일을 Base64로 감싸면 메모리와 전송량 부담이 함께 커집니다. 저장소에 올리고 주소만 주고받는 방식이 대체로 낫습니다.

패딩 문자를 지웁니다. 끝의 등호가 지저분해 보여 지우면 디코딩이 실패합니다.

용도를 알면 쓸지 말지가 정해집니다

Base64를 쓸지 말지는 취향의 문제가 아니라 전송로가 텍스트만 받는가로 정해집니다. 받는 쪽이 바이너리를 받을 수 있으면 쓸 이유가 없고, 텍스트만 받으면 33%를 감수하는 수밖에 없습니다.

그리고 감수하기로 했다면 압축을 먼저 하세요. 순서 하나로 결과가 달라집니다.