오늘 오후, 나는 또 데이터 문제로 꽤나 고생했다. 고객 쪽에서 암호화된 파일이라며 보내온 파일이 있었는데, 열리지 않았다. 그 형식을 보자마자 마음 속으로 대충 감이 왔다——이거 Base64잖아, 암호화가 아니라 그냥 겉만 번지르르한 껍데기일 뿐이지.
솔직히 말해서, Base64는 우리 업계에서 정말 애증의 대상이다. 좋아하는 이유는, 간단하고 단순해서 이진 데이터를 꽤 규칙적으로 보이는 텍스트로 바꿔주고, 어디에 보내도 깨질 염려가 없기 때문이다. 싫어하는 이유는, 항상 암호화로 오해받아서 마치 뭔가 신비한 것처럼 보이기 때문이다. 오늘 일도, 내 머릿속에 이 개념이 없었다면 고객에게 "이건 암호화가 아니라 인코딩입니다"라고 또 한참 설명해야 했을 것이다.
상황은 이랬다. 상대방이 CSV 파일을 보냈는데, 그 안에 한 열의 데이터가 전부 "U2FsdGVkX1+..."로 시작하는 문자열이었다. 고객은 이게 자기 시스템이 자동 생성한 "암호화된 비밀번호"라며, 새 시스템으로 마이그레이션하려는데 새 시스템이 인식하지 못한다고 했다. 나는 그 시작 부분을 보고 웃음이 나올 뻔했다. 이거 전형적인 Base64 특징이잖아? 나는 온라인 도구에 그냥 붙여넣고 디코딩을 눌렀다. 헐, 안에는 그냥 평범한 UTF-8 텍스트였다. 암호화 같은 건 전혀 없었다.
사실 이런 상황은 너무 많이 겪어서 이제는 흔하다. 많은 사람들이 "인코딩"과 "암호화"의 차이를 구분하지 못한다. Base64는 본질적으로 8비트 바이트를 6비트 인쇄 가능한 문자로 변환하는 인코딩 방식일 뿐이며, 어떤 키도 없어서 누구나 디코딩할 수 있다. 하지만 그 모양이 외계어처럼 보이기 때문에 자주 "가짜 암호화"로 사용된다. 오늘 일도, 내가 이 패턴을 잘 알고 있지 않았다면, 그냥 추측만 하다가 퇴근 시간까지 끌었을 것이다.
또 다른 경우, 나는 이미지 업로드 문제를 처리한 적이 있다. 프론트엔드에서 이미지를 Base64 문자열로 변환해 그냥 백엔드에 던졌는데, 백엔드가 데이터베이스에 저장할 때 그 문자열이 너무 길어서 테이블 구조가 거의 터질 뻔했다. 나중에 나는 그에게 원시 이진 스트림으로 전송하라고 가르쳐서 문제를 즉시 해결했다. Base64는 편리하지만 치명적인 단점이 있다——부피가 약 33% 증가한다는 것이다. 이미지가 크면 문자열 길이가 정말 어마어마해진다.
하지만 다시 생각해보면, 오늘 이 작업은 정말 Base64 덕분이다. 이렇게 "바보같이" 간단한 인코딩 방식이 아니었다면, 나는 데이터 내용을 빠르게 확인할 수 없었을 것이다. 심지어 스크립트를 작성할 필요도 없이, 웹페이지에서 디코딩 도구를 찾아 몇 초 만에 내용을 파악했다. 만약 진짜 암호화였다면, 오늘은 야근해야 했을 것이다.
그래서 보다시피, 도구 자체에는 좋고 나쁨이 없고, 중요한 건 당신이 그것을 이해하느냐이다. Base64는 만능 열쇠와 같아서, 문을 잠그지는 않지만 잠긴 것처럼 보이는 많은 문을 열 수 있다. 동료 여러분께 제안하건대, "겉보기에 깨진 것 같지만 규칙이 있는" 문자열을 만나면 당황하지 말고, 복사해서 Base64 디코더에 넣어보라. 십중팔구 30분의 디버깅 시간을 절약할 수 있을 것이다. 오늘, 그것은 또 내 목숨을 구했다. 다음에 여러분 차례가 되면, 이 방법을 잊지 마세요.