Base64 Encoding: When to Use It and When Not To

3년 전, 나는 내 팀의 주니어 개발자가 50MB 비디오 파일을 전체를 Base64로 인코딩하여 JSON API 응답에 직접 삽입하는 모습을 지켜보았다. 애플리케이션이 멈췄다. 사용자들은 1분 이상의 로드 시간에 불만을 토로했다. 우리의 CDN 비용은 하룻밤 사이에 세 배로 증가했다. 내가 그에게 왜 그랬는지 물었을 때, 그는 "Base64가 데이터 전송을 더 안전하게 만든다고 읽었다"고 말했다.

그 순간은 내가 12년 동안 다양한 SaaS 회사에서 백엔드 인프라 엔지니어로 일하는 동안 관찰해 온 것을 응축시켰다: Base64 인코딩은 개발자의 도구 세트에서 가장 유용하면서도 가장 잘못 사용되는 도구 중 하나이다. 사람들이 망치로 사용하려고 시도하는 스위스 군용 칼과 같다.

나는 사라 첸이며, 매월 수십억 건의 요청을 처리하는 데이터 파이프라인을 구축하고 최적화하는 데 10년 이상을 보냈다. 나는 Base64가 복잡한 인코딩 문제를 해결하는 데 멋지게 사용되는 것을 보았고, 그것이 수만 달러의 비용이 드는 치명적인 성능 문제를 일으키는 것을 보았다. 오늘, 나는 Base64가 당신의 가장 좋은 친구가 되는 때와 최악의 적이 되는 때에 대해 내가 배운 것을 공유하고 싶다.

Base64가 실제로 하는 일 (그리고 하지 않는 일)

기본부터 시작하자, 왜냐하면 많은 개발자들이 Base64를 사용하는데 실제로 무슨 일이 일어나고 있는지 이해하지 않고 사용하기 때문이다. Base64는 이진 데이터를 64개의 인쇄 가능한 문자(A-Z, a-z, 0-9, +, /)를 사용하여 ASCII 텍스트로 변환하는 인코딩 방식이다. 그것이 전부이다. 그것은 암호화가 아니다. 그것은 압축이 아니다. 그것은 표현 변환이다.

대부분의 사람들이 놓치는 중요한 점은 다음과 같다: Base64는 데이터 크기를 약 33% 증가시킨다. 입력의 3바이트마다 4바이트의 출력을 얻는다. 이것은 버그가 아니다—8비트 바이트를 오직 6비트의 정보(2^6 = 64개의 가능한 문자)만으로 표현하는 수학적 현실이다.

내가 개발자들에게 이것을 설명할 때, 나는 간단한 비유를 사용한다: 당신이 집을 옮기고 있고 표준화된 종이 상자에만 물건을 운반할 수 있다고 상상해 보자. 당신의 소지품 가운데 일부는 완벽하게 들어맞지만, 다른 것들—그 이상한 모양의 램프 같은—은 더 큰 상자와 많은 패딩이 필요하다. Base64는 그 패딩이다. 당신은 데이터를 제약된 전송 형식(ASCII 텍스트)에 맞추기 위해 추가 공간이 필요한 것이다.

인코딩 과정은 세 개의 바이트(24비트)의 이진 데이터를 가져와서 네 개의 6비트 그룹으로 나눈다. 각 그룹은 Base64 알파벳의 64개 문자 중 하나에 매핑된다. 만약 입력이 3으로 완벽하게 나눌 수 없다면, 마지막 그룹을 완성하기 위해 패딩 문자(=)가 추가된다. 이것이 당신이 종종 Base64 문자열의 끝에서 하나 또는 두 개의 등호 기호를 보는 이유이다.

코드베이스를 감사하면서, 나는 약 40%의 Base64 사용이 그것이 제공하는 것에 대한 근본적인 오해에서 비롯되었다는 것을 발견했다. 개발자들은 그들이 보안을 얻고 있다고 생각한다(사실이 아니다—Base64는 쉽게 역변환 가능하다), 또는 압축(정반대가 사실이다), 또는 어떤 마법같은 데이터 정화를 얻고 있다고 생각한다. Base64가 실제로 하는 것을 이해하는 것은 적절하게 사용하는 첫 번째 단계이다.

완벽한 사용 사례: Base64가 빛나는 곳

크기 오버헤드에도 불구하고, Base64가 절대적으로 올바른 선택인 시나리오가 있다. 나는 이점이 비용을 초과하는 다섯 가지 주요 사용 사례를 파악했으며, 나는 이러한 사례를 생산 시스템에서 정기적으로 접한다.

"Base64는 암호화가 아니며, 압축도 아니다—33% 데이터 크기를 증가시키는 표현 변환이다. 이 기본 진리를 이해하는 것은 그것을 현명하게 사용하고 성능 재앙을 만드는 것의 차이다."

텍스트 기반 형식에 이진 데이터 삽입. 이는 원래의 가장 합법적인 사용 사례이다. JSON, XML 또는 HTML에 이진 데이터(이미지, 글꼴, 인증서)를 포함해야 할 때, Base64는 종종 유일한 옵션이다. 나는 최근에 작은 회사 로고(10KB 이하)를 HTML 이메일에 Base64 데이터 URI로 직접 삽입하는 이메일 템플릿 시스템에서 일했다. 이는 외부 HTTP 요청을 제거하고 사용자가 기본적으로 이미지가 비활성화 되었을 때도 로고가 표시되도록 보장했다. 33%의 크기 증가가 신뢰성 향상에 가치를 더했다.

텍스트 전용 프로토콜을 통한 이진 데이터 전송. 일부 레거시 시스템과 프로토콜은 ASCII 텍스트만 지원한다. 나는 1990년대의 메인프레임 시스템과의 통합을 유지했었는데, 이 시스템은 7비트 ASCII만 수용할 수 있었다. 우리는 모든 이진 첨부 파일을 전송하기 전에 반드시 Base64로 인코딩해야 했다. 대안이 전혀 없었다. 이 시스템은 매일 약 50,000개의 트랜잭션을 처리했으며, Base64 인코딩은 총 처리 시간에 약 2초를 추가했으나, 메인프레임의 다른 병목 현상과 비교할 때에는 미미한 수치였다.

이진 지원이 없는 데이터베이스에 이진 데이터 저장. 대부분의 현대 데이터베이스는 이진 데이터를 잘 다루지만, 나는 Base64로 인코딩된 텍스트를 저장하는 것이 BLOB 필드를 다루는 것보다 더 간단한 시스템에서 일한 경험이 있다. 특히, BLOB 처리가 복제본 간에 일관되지 않았던 분산 SQLite 설정이 있었다. Base64로 변환하는 것은 동기화 문제를 완전히 없애주었다. 우리는 평균 500바이트의 작은 이진 레코드 약 200만 개를 저장했으며, 33%의 오버헤드는 우리 인프라에서 약 0.50달러의 추가 저장 공간을 초래했다.

작은 자산에 대한 데이터 URI 만들기. 5KB 이하의 자산에 대해서는 Base64 데이터 URI로 삽입하는 것이 HTTP 요청을 줄이고 인지된 성능을 개선할 수 있다. 나는 20개의 작은 아이콘(각 2KB)이 있는 대시보드 애플리케이션의 테스트를 수행했다. 별도의 요청으로 로딩하는 데에는 연결 오버헤드 때문에 평균 340ms가 소요되었다. Base64 데이터 URI로 로딩했을 때, 전체 로드 시간은 HTML 파일 크기가 더 커짐에도 불구하고 180ms로 줄어들었다. 왕복 횟수의 감소가 대역폭 증가보다 더 중요했다.

인증 토큰 및 자격증명 인코딩. 많은 인증 시스템은 HTTP 헤더(기본 인증과 같은)에서 자격 증명을 인코딩하기 위해 Base64를 사용한다. 이는 보안을 위한 것이 아니라 호환성을 위한 것이다. HTTP 헤더는 ASCII이어야 하며, Base64는 특수 문자가 포함된 사용자 이름과 비밀번호가 프로토콜을 깨지 않도록 보장한다. 나는 수십 개의 API 인증 시스템을 구현했으며, Base64로 자격 증명을 인코딩하는 것은 표준 관행이지만, 실제 보안을 위해 항상 HTTPS와 함께 사용해야 한다.

성능 함정: Base64가 애플리케이션을 죽일 때

이제 잘못되는 경우에 대해 이야기하자. 나는 부적절한 Base64 사용으로 발생한 성능 문제를 해결한 경험이 정말 많다. 패턴은 항상 비슷하다: 개발자가 규모에서의 영향을 고려하지 않고 편의성을 위해 Base64를 선택한다.