핵심 요약
Base64 인코딩은 8비트 기반의 바이너리 데이터를 네트워크 전송에 안전한 64개 표준 ASCII 문자로 바꾸는 변환 방식이다. RFC 4648 표준에 따르면 이는 텍스트나 이미지가 시스템 간 이동할 때 데이터 손실을 막기 위해 고안되었으며, 암호화가 아닌 단순한 표현 형식 변환에 해당한다. 이 글에서는 3바이트의 데이터가 어떤 수학적 과정을 거쳐 4글자의 텍스트로 변환되는지 비트 단위의 계산 근거를 상세히 설명한다.
계산 공식과 비트 단위 변환 원리
Base64의 핵심 메커니즘은 8비트(Byte)와 6비트(Index) 사이의 최소공배수를 활용하는 데 있다. 컴퓨터가 데이터를 처리하는 기본 단위인 1바이트는 8비트이며, Base64 인덱스 테이블은 0부터 63까지 총 64개의 표현을 위해 6비트()를 사용한다.
데이터를 변환할 때는 3개의 바이트를 묶어서 총 24비트의 연속된 비트열로 만든다. 이 24비트 스트림을 다시 6비트씩 4개의 조각으로 나누어 각각 Base64 색인표에 대입한다. 변환 공식의 구조는 다음과 같다.
- 입력 데이터 단위: 3바이트 = 24비트 ()
- 출력 데이터 단위: 4글자 = 24비트 ()
- 데이터 용량 변화: 데이터 용량 변환 원리에 따라 원본 대비 약 33% 증가
실제 계산 예시: 문자열 'Cat'의 변환 과정
세 글자로 이루어진 문자열 'Cat'을 예로 들어 실제 비트가 어떻게 쪼개지는지 계산한다. ASCII 코드 기준으로 각 문자의 8비트 이진수는 다음과 같다.
- 문자 'C': 01000011
- 문자 'a': 01100001
- 문자 't': 01110100
이 세 바이트를 이어 붙이면 총 24비트의 데이터 스트림이 완성된다.
01000011 01100001 01110100
이제 이 24비트 스트림을 정확히 6비트씩 4개로 분할한다.
- 첫 번째 6비트:
010000(십진수 16) - 두 번째 6비트:
110110(십진수 54) - 세 번째 6비트:
000101(십진수 5) - 네 번째 6비트:
110100(십진수 52)
각각의 십진수 인덱스를 Base64 인코더 / 디코더 표준 색인표에 대입하면 알파벳 문자로 치환된다. 16은 'Q', 54는 '2', 5는 'F', 52는 '0'에 해당하여 최종 결과는 'Q2F0'가 된다.
패딩 문자의 계산과 예외 처리
모든 입력 데이터가 정확히 3바이트로 나누어떨어지는 것은 아니다. 데이터의 남은 바이트 수가 1바이트나 2바이트일 때 Base64 규격은 빈자리를 0으로 채우는 패딩(Padding) 규칙을 적용한다.
남은 바이트가 2개인 경우, 16비트가 되므로 6비트씩 나누면 2비트가 남는다. 이 남은 공간을 0으로 채워 세 번째 6비트 조각을 만들고, 마지막 네 번째 자리는 '=' 기호로 채운다. 남은 바이트가 1개인 경우, 8비트가 되므로 6비트 조각 하나를 만들고 남은 4비트를 0으로 채워 두 번째 조각을 만든 뒤, 나머지 세 번째와 네 번째 자리는 '==' 기호로 채운다.
이러한 패딩 규칙 덕분에 디코더는 원본 데이터의 정확한 바이트 길이를 역산해 복원한다.
자주 헷갈리는 부분과 오해
Base64를 다룰 때 가장 흔하게 발생하는 오해는 이를 데이터 보안을 위한 암호화 수단으로 취급하는 것이다. 인코딩은 단지 데이터의 표현 형태를 바꿀 뿐이며, 키(Key)나 복잡한 알고리즘 없이 누구나 원본으로 되돌릴 수 있다. 민감한 비밀번호나 개인토큰을 단순히 Base64로 감싸는 것은 보안상 아무런 보호 효과가 없다.
또한 Base64 인코더 / 디코더 같은 도구를 사용할 때, 한글이나 유니코드는 UTF-8 기준으로 문당 바이트 수가 늘어난다는 점을 유의해야 한다. 영문자는 1글자가 1바이트이지만 한글은 1글자가 보통 3바이트를 차지하므로 인코딩 후 결과물이 예상보다 길어지게 된다.