웹 개발자 면접 단골 질문 2 | Base64 인코딩의 개념

원하시는 기업에 꼭 합격하시길 기원하겠습니다 :) 면접 연습에 스크립트가 필요하신 분들은 아래를 참고해주세요. ### Base64 인코딩에 대해 설명해주세요 Base64 인코딩은 이진 데이터를 ASCII 문자열로 변환하는 인코딩 방식입니다. 이진 데이터를 앞에서부터 3 바이트 단위로 나눈 뒤, 다시 6 비트 단위로 ASCII 문자열에 매핑하여 문자열로 표현하는 방식이죠. 이 때, 원본 데이터가 3 바이트보다 작을 경우에는 패딩 문자를 추가합니다. Base64로 인코딩된 문자열을 받는 쪽에서는 각 숫자에 매핑되는 이진 데이터로 다시 디코딩하여 데이터를 활용할 수 있기 때문에, 원본 데이터의 손실을 방지할 수 있는 것입니다. ### ASCII 코드는 총 128자인데, 어떻게 6비트 단위로 인코딩할 수 있나요? Base64에서 사용하는 ASCII 코드는 제어 문자가 제외되어, 총 64자만을 사용하기 때문입니다. 알파벳 대소문자와 0부터 9까지의 숫자, 그리고 플러스 사인 (+)과 슬래쉬 (/)까지 합하면 총 64개 문자로 테이블을 구성할 수 있습니다. 바이너리 데이터를 6비트씩 읽은 후, 값에 해당하는 문자로 치환하는 것이죠. 만약 현재 인코딩 중인 바이트의 길이가 3이 안되면 매핑할 수 없기 때문에, 이퀄 사인 (=)이 이 공백을 채우게 됩니다. ### Base64 인코딩 방식은 어떤 경우 사용할 수 있나요? 일반적으로, 작은 아이콘이나 이미지를 서버에 요청하는 과정없이, 브라우저에서 직접 불러오기 위해 사용합니다. Webpack과 같은 번들러에서도 일정 크기 이하의 이미지는 Base64 방식으로 변환하여 인라인으로 처리될 수 있도록, 번들링 옵션을 제공하죠. 또한, 원본 데이터의 손실없이 안전한 문자열로 인코딩하기 위해 사용하기도 합니다. 예를 들어, JWT 인증 방식에서 토큰에 담긴 정보를 문자열로 인코딩하는 과정에서 원본 데이터의 손실을 방지하기 위해 Base64 방식을 사용합니다. ### JWT는 어떤 이유로 Base64 인코딩을 사용하는 것인가요? JWT는 서버에서 발급되어 HTTP 헤더나 URL 파라미터를 통해 브라우저로 전달됩니다. JWT는 헤더, 페이로드, 서명 총 세 부분으로 구성되는데, 헤더와 페이로드는 JSON 데이터로 이루어져 있습니다. HTTP 헤더와 URL 파라미터는 문자열만 처리할 수 있기 때문에 원본 데이터가 손실되지 않는 선에서 JWT를 문자열로 안전하게 변환해야 합니다. 이러한 이유로 Base64 인코딩을 적용하는 것이죠. 또한, URL 파라미터에는 플러스 사인 (=)과, 슬래쉬 (/), 그리고 이퀄 사인 (=) 과 같은 특수 문자가 포함되면 안되기 때문에, JWT를 인코딩할 때는 이 문자들을 제외한 URL-safe가 적용된 Base64 인코딩을 사용합니다. JWT는 Base64로 인코딩해야 한다는 명세는 RFC 7519 문서에서 확인할 수 있습니다. ### Base64 인코딩 방식의 단점은 무엇인가요? 먼저, 원본 데이터보다 약 33% 정도 데이터 크기가 증가한다는 단점이 있습니다. Base64는 이진 데이터를 3바이트 씩 분리한 뒤, 6비트 씩 읽어 ASCII 코드에 매핑되는 문자열로 치환합니다. 즉, 3바이트가 4바이트로 변환되기 때문에 전체 데이터가 약 33% 증가하는 것입니다. 이로 인해, 원본 데이터가 큰 이미지를 Base64 인코딩하여 문서 내에 임베딩하면, Base64를 적용하지 않았을 때에 비해 로딩 속도가 크게 떨어질 수 있습니다. 또한, 리소스 캐싱은 파일 단위로 이뤄지는데, 이미지를 Base64로 인코딩한 뒤 HTML 문서 내에 삽입하면, 이미지 단위 캐싱은 불가능합니다.