[CS] 여러 가지 문자열 인코딩 방법과 base64 인코딩

🔊 해당 포스팅은 개인적으로 구독하고 있는 널널한 개발자님의 무료 유투브 강의인 문자열 인코딩과 base64 인코딩 영상을 보고 개인적인 목적 하에 작성되는 글입니다. 포스팅에 사용되는 모든 자료는 제가 직접 재구성하였음을 알립니다.

---

최근에 C 언어와 Go 언어를 조금씩 접하기 시작하면서 원툴로 사용해오던 Python 언어에 비해 다르게 느껴지는 점이 무수히 많았다. 그 중에 하나로서 컴퓨터가 문자 또는 문자열을 표현하는 방법인 문자열 인코딩에 대해서 확실히 알아두어야 겠다는 생각이 들었다. 그리고 또 다른 자매품(?)으로 base64 인코딩이 어떻게 동작하는지, 그리고 왜 사용되는지에 대해서도 같이 공부하면 좋겠다 싶었다.

 

문자열 인코딩에 대한 이미지를 ChatGPT에게 생성해달라고 한 이미지

---

1. 문자 인코딩의 시작: ASCII(아스키) 코드

프로그래밍을 해보거나 코딩 테스트를 준비해 본 사람이라면 ASCII 코드 체계라는 것을 한 번쯤은 들어봤을 것이다. 바로 아래와 같은 표이다.

 

나무위키: ASCII 코드표

 

위 표를 보면 알겠지만 특정 숫자(10진수, 16진수, 8진수)가 어떤 문자로 매핑되는지 나타낸 표이다. 예를 들어, 소문자 알파벳 a는 10진수로 97이자 16진수로 61, 8진수로는 141이다. 바꾸어 말해서 10진수 97은 컴퓨터에게 문자 a가 되는 것이다.

 

ASCII 코드표에 나열된 개수를 보면 0부터 127까지, 총 128가지임을 볼 수 있다. 128은 $2^7$이므로 결국 7비트인 셈이다. 다시 말해서, ASCII 코드표는 문자를 7비트로 표현하는 것이다. 실제 예전 8비트 컴퓨터에서는 ASCII 코드표를 활용해서 문자를 표현했다. 엇 그런데 방금 ASCII 코드표가 7비트라고 했는데, 8비트 컴퓨터에 쓰인다면 나머지 1비트는 어디에 쓰이는 건가? 싶을 수 있다. 나머지 1비트는 통신 에러 검출을 표현하거나 ASCII 코드 표에는 없는 특수 문자를 표현하기 위해 사용하기도 했다고 한다.(나무위키)

 

이 때, ASCII 코드표를 잘 보면 모두 영어 알파벳으로 이루어진 것을 볼 수 있다. 즉, 서양 특히, 영어를 모국어로 사용하는 국가와 문화 기준으로 만들어진 체계인 셈이다. 당시만 해도 컴퓨터를 연구하고 발전시키고 있는 국가는 서양권이었다. 그래서 이 ASCII 코드표는 대한민국이나 일본, 중국 등과 같이 동아시아권 국가들의 언어 체계를 반영해야겠다는 생각조차 하지 못한 것이다.

2. 다른 국가의 언어도 반영하자: Unicode

대한민국도 컴퓨터의 존재를 점진적으로 알게되고 연구를 시작함에 따라 한글을 컴퓨터에 표현하기 위한 코드체계를 수립하기 위한 움직임이 시작되었다. 컴퓨터에 한글을 어떻게 인코딩시켜 표현할지에 대해서 초기에 조합형과 완성형에 대한 논쟁이 있었다. 조합형과 완성형의 차이가 무엇일까? 예를 들어보자.

 

조합형은 한글의 자음과 모음 각각을 하나의 숫자로 매핑한 것이다. 예를 들어, '설' 이라는 글자를 조합형으로 표현한다면 ㅅ, ㅓ, ㄹ 이렇게 총 3개의 문자로 표현하고, 각각을 하나의 숫자로 매핑하는 것이다. ㅅ을 숫자 1로, ㅓ는 숫자 20으로, ㄹ은 숫자 5로 매핑해서 '설' 이라는 글자를 (1, 20, 5) 라는 조합으로 매핑하는 것이다.(여기서 1, 20, 5라는 숫자는 임의로 예시를 든 것이며 실제 (1, 20, 5)로 매핑되지 않는다. 어떠한 다른 숫자로 매핑된다. 혹시 궁금하면 찾아보는 것도 좋을 듯 하다)

 

조합형으로 한글을 표현

 

반면에, 완성형은 '설' 이라는 글자 자체를 특정 하나의 숫자에 매핑하는 것이다. 즉, 한글의 모든 문자가 특정 하나의 숫자로 1:1 매핑되는 것이다.

 

완성형으로 한글을 표현

 

실제 '설'이라는 글자는 Unicode 한글 체계 표에 따르면 16진수 BCB3에 매핑된다. 그리고 16진수인 BCB3을 10진수로 표현하면 48307(4만7천3백7)이다.  한글을 조합형으로 할지, 완성형으로 할지 무수한 논쟁이 많았지만, 결국은 완성형으로 결정이 되었고 현재 컴퓨터는 한글을 완성형 방식을 사용해서 표현되고 있다. 이 완성형 방식의 한글 인코딩을 EUC-KR이라고 부른다.

 

ASCII 코드는 7비트(특수문자까지 하면 8비트)로 표현된다고 했다. 그러면 유니코드는 글자 하나를 몇 비트로 표현할까? 이 "몇 비트로 표현할까" 를 다른 말로 바꾸어 말하면 "한글 문자 하나를 표현하는 경우의 수는 총 몇 가지인가?" 이다. 하지만 컴퓨터는 대한민국만 사용하는 것이 또 아니다. 중국이나 일본, 기타 다른 동아시아권 국가들에서도 컴퓨터를 사용해서 자신들의 언어를 표현할 수 있다. 이러한 국가들의 언어까지 모두 포함했을 때, 몇 비트 체계로 해야 모든 국가들의 언어를 표현할 수 있게 될까?

 

이에 대해서 합의하여 결정한 비트수가 바로 16비트이다. 16비트는 $2^16$으로 대략 65,536이다. 따라서 유니코드는 문자 하나를 16비트로 표현한다.

3. Microsoft가 만든 Unicode의 또 다른 이름: MBCS

유니코드에 대한 합의가 이루어진 후, 2000년대 초반 마이크로소프트가 윈도우 운영체제를 대한민국에 널리 보급하여 모든 가정에는 대부분 윈도우 운영체제를 갖는 컴퓨터 한 대씩 갖기 시작했다. 그러면서 마이크로소프트가 유니코드 체계를 다른 용어로 부르기도 하는데, 바로 MBCS(Multi Byte Character Stream)이라고 부른다. 어려운 것은 아니고, Character인 문자를 Multi Byte 즉, 멀티 바이트로 표현한다는 의미이다. 1바이트는 8비트이다. 멀티 바이트는 1바이트 이상 즉, 2바이트인 셈인데 2바이트는 16비트이다. 다시 말해, MBCS는 문자를 2바이트 이상으로 표현한다는 것이다. 그런데 우리는 직전 목차에서 유니코드가 16비트로 표현된다고 했다. 고로 글자 하나를 16비트로 표현한다고 해서 단순히 멀티 바이트로 표현한다고 한 것이다.(일부러 어렵게 용어를 해놓은 듯..) MBCS라는 것은 유니코드랑 100% 동일한 것은 아니지만 거의 유사하다고 보면 된다.

 

MBCS를 만들고, 마이크로소프트는 한글 처리를 위해 EUC-KR을 확장하여 CP949 라는 것을 정의하기도 했다. CP는 Code Page의 줄임말인데, ASCII 코드표처럼 문자와 숫자를 매핑한 테이블을 의미하는 것이다. CP949는 현재 윈도우 운영체제에서도 자주 보이는 인코딩 형식으로, 윈도우에서 해당 인코딩 체계로 저장한 텍스트나 csv 파일을 맥북에 옮겨 파일을 열면 파일 내용이 깨지게 되는 것을 볼 수 있다.

4. 인터넷과 Web, 그리고 HTML의 등장: UTF-8

2000년대 초반이 되면서 대한민국은 인터넷의 보급화가 이루어졌다. 집 주변에 PC방이 생기고, 학창시절 학교가 끝나고 친구들과 게임이나 메신저와 같은 인터넷 공간에서 만나기 시작했다. 그리고 이 때부터 대부분은 Web 통신을 수행함에 따라, HTML 문서가 보급화되기 시작했다. 심지어 지금 보고 있는 이 블로그 글도 HTML 문서이다. 그러다 보니, 보급화된 인터넷을 이용하는 전국, 심지어 전세계 사람들이 서로 다른 웹브라우저로 접속하게 되면서 동일한 HTML 문서의 내용물을 보지만 각 웹 브라우저에 따라 HTML의 문자열들이 깨지는 현상이 발생하곤 했다.

 

결국, Web에서의 문자열은 어떠한 인코딩 체계로 통일하자가 되었는데, 그것이 바로 UTF-8 체계이다. UTF-8은 [목차 2번]에서 배운 유니코드와 거의 동일하다. 차이점은 바로 유니코드는 모든 문자를 2바이트(16비트)로 표현하기로 했었지만, UTF-8은 3바이트(24비트)로 표현하기로 했다는 점이다. 다만, UTF-8은 ASCII 코드로 표현할 수 있는 영어문자에 대해서는 1바이트(8비트)로 표현하기로 했다.

 

Unicode vs UTF-8

 

이렇게 Web에서는 문자열 표현 방식을 UTF-8 인코딩으로 통일하게 됨에 따라 URL 인코딩 방식도 UTF-8을 자동으로 사용하게 된다. 실제로 URL 인코딩 사이트에 가서  제드 라는 한글 단어를 입력하면 %EC%A0%9C%EB%93%9C 라는 인코딩된 값이 등장한다. 이 인코딩된 값의 %는 16진수 단위로 등장하는데, 이 예시에서는 EC가 16진수 1개, A0이 16진수 1개, ... 이런식이다.

 

내가 입력을 '제드'라고 한글로 입력했고, 한글 글자 하나는 3바이트라고 했다. 그러므로 EC, A0, 9C 즉, ECA09C가 바로 한글 '제'를 의미하게 된다. 여기에 들어가서 '제' 라는 글자에 대한 UTF-8 값을 보면 (236, 160, 144)의 C임을 알수 있다. 먼저 (236, 160, 144)를 16진수로 바꾸면 (EC, A0, 90)이 되고, 마지막 90에 C를 붙이면 90C 이지만, 0은 어차피 0이므로 9C가 됨을 알 수 있다. 그래서 최종적으로 EC, A0, 9C가 되고 이 값은 URL 인코딩된 값의 "%EC%A0%9C" 의 값과 동일함을 알 수 있다. 

 

나머지 글자인 '드'도 똑같이 찾아보고 값이 동일한지 살펴보자.

5. 이거 "UTF-8로 인코딩 된거야!" 라고 인증: UTF-8(BOM)

방금 Web 통신에서의 문자열 인코딩은 모두 UTF-8 인코딩으로 대동단결했다고 했었다. 그런데 막말로, 어떤 문자열 자체만 보고 이게 UTF-8로 인코딩된 거야! 라고 어떻게 증명할 수 있을까? 이런 관점에서 등장한 것이 바로 UTF-8(BOM)이다. BOM은 Byte Order Mark의 줄임말인데, 쉽게 표현하면 이 BOM이 "이 문자열 UTF-8로 인코딩 된 것임"을 증명하는 문자인 것이다. 문자열의 가장 앞부분 3바이트 만큼 공간에 이 BOM을 표현해주는 것이다. 이 3바이트의 데이터를 보고 "아 이 문자열이 UTF-8로 인코딩 된 것이구나~" 라고 인지하는 것이다.

 

이 부분을 필자 컴퓨터 MacOS에서 테스트해보려 했으나, UTF-8(BOM) 인코딩 형식이 지원이 되지 않아서, 널널한 개발자님 강의의 32분 00초부터 보면 된다.

6. 모든 문자를 16비트로 표현: UTF-16

UTF-8은 ASCII 코드는 1바이트, 그 외 문자는 3바이트로 표현한다고 했었다. 하지만 UTF-16은 모든 문자를 2바이트 즉, 16비트로 표현하는 인코딩 방식이다. 그런데 UTF-16에는 크게 BE, LE 방식이 존재한다. BE는 Big Endian이고, LE는 Little Endian이다. 예전 C 언어 관련 포스팅을 할 때, 데이터를 메모리에 저장하는 방식들에 대해 배울 때도 똑같이 등장했었다. 그 때 당시에 배운 개념이 100% 동일한 의미는 아니지만 느낌은 비슷하다. 

 

그런데 왜 UTF-16는 BE, LE 방식이 따로 존재할까? 이유는 바로 ASCII 코드에 있다. ASCII 코드는 1바이트 체계로 8비트로 표현이 가능하다고 했다. 그런데 UTF-16에서는 이 ASCII 코드도 16비트로 표현한다고 했다. 그러면 결국 8비트로 표현가능한 것을 16비트로 늘려서 표현한다는 것인데, 16비트로 늘림에 따라 빈 공간이 생길 것이다.

 

위 회색 공간이 16비트로 늘려버린 공간

 

예를 들어, 알파벳 소문자 a를 ASCII 코드로 표현하면 10진수로는 97이고 이를 8비트 이진수로 바꾸면 0110 0001이다. 이번엔 a를 UTF-16으로 인코딩한다면 8비트까지의 값은 동일하되 위 그림의 회색 부분 처럼 8비트만큼의 공간을 더 쭉 늘려버린다. 그리고 이 늘어난 8비트 추가 공간에는 null과 같은 쓰레기 값을 넣어버린다. 

 

바로 이 늘어난 공간이 위 그림처럼 뒤쪽 부분을 늘려버리면 Little Endian(LE) 방식, 앞쪽 부분을 늘려버리면 Big Endian(BE) 방식이라고 부른다. 그리고 BE 방식인지, LE 방식인지 추가로 표시하기 위해 UTF-8(BOM)처럼 맨 앞에 2바이트 만큼의 공간에 식별자를 넣어준다.

---

이렇게 해서 컴퓨터에서 문자열을 인코딩하는 대표적인 인코딩 방식들을 알아보았다. 마지막으로는 웹 통신할 때 사용하는 UTF-8 인코딩 말고도 base64 인코딩이라는 것도 존재하는데, 이에 대해서 알아보고 글을 마무리하도록 하자.

7. 문자로 표현할 수 없는 것을 문자로 표현하자: base64 인코딩

먼저 base64 인코딩이 동작하는 과정에 대해서 살펴보자. base64 인코딩은 원본 자료를 6비트씩 끊어서 처리를 수행한다. 아래 그림으로 동작 과정을 알아보자.

 

base64 인코딩 동작 원리

 

먼저 각 문자를 10진수 또는 16진수로 변환하는 과정을 거쳐 최종적으로 2진수로 변환한다. 그리고 이 2진수 값들을 쭉 이어붙힌다. 이제 6비트씩 단위로해서 끊는다. 그리고 6비트씩 끊은 값을 base64 바이너리 테이블에서 매핑되는 문자로 변환한다. 참고로, 위의 예시의 경우 CHS라는 글자가 6비트 단위로 딱 떨어져서 끊어졌지만 만약 원본 길이가 6비트 단위로 딱 끊어지지 않고 끝에 여분이 남는다면 끝에 남는 부분을 6비트로 늘린 뒤, 빈 공간을 =(등호) 기호로 채워넣는 패딩을 수행한다.(마치 [목차 6번]에서 배운 UTF-16때의 패딩이랑 비슷한 원리이다)

 

이제 동작과정을 알아보았으니, base64 인코딩을 하는 이유에 대해 되짚어보자. 그런데 이상한 점이 하나 있다. 방금 동작과정을 살펴보면 중간에 원본 문자를 6비트 단위로 쪼개었는데, 이 쪼개진 6비트 크기의 데이터를 base64 바이너리 테이블에 매핑된 문자인 8비트 크기의 데이터로 변환했다. 즉, 데이터의 사이즈가 6비트에서 8비트로 2비트만큼 더 불필요하게 더 커진 셈이다. 이것만 보면 base64 인코딩이라는 것은 데이터 사이즈만 키울 뿐이지 굳이 왜 해야하는지 이유가 잘 보이지 않는다.

 

base64 인코딩을 하는 이유는 결론부터 말하면 바이너리로 되어 있는 데이터 즉, 비트 스트림 데이터를 어떻게든 영어 문자열로 바꾸기 위함이다. 그러면 영어 문자열로 왜 바꾸는 것일까? 이에 대한 이유는 바로 웹 통신을 수행할 때, 대부분 ASCII 코드로 표현이 가능하기 때문이다.

 

웹 통신을 수행할 때, ASCII 코드로 표현할 수 없는 바이너리 데이터(ex. 불렛 포인트와 같은 특수 문자, 조그마한 이미지 등)들이 주고받아야 하는 경우가 있을 수 있다. 이러한 바이너리 데이터를 HTML 문서와 같이 웹 통신을 수행할 때 사용하는 매개체에 같이 담아내기 위해서 바이너리 데이터를 강제로 ASCII 코드 문자로 변환하는 것이다. 

 

만약 바이너리 데이터를 문자로 변환해서 담아 같이 보내지 않으면 HTML 문서와 같은 문자열 데이터를 주고받기 위한 네트워크 통신 1회, 바이너리 데이터 형식을 주고받기 위한 네트워크 통신 1회, 총 2번 통신을 수행해야 한다. 하지만 네트워크 통신은 생각보다 비싼 비용이며 속도가 CPU 연산과 같은 컴퓨팅 연산에 비해서는 매우 느리다. 결국, base64 인코딩을 활용한다면 약간의 데이터 사이즈는 커질지라도, 1회만의 네트워크 통신을 수행해서 더 빠른 속도의 서비스를 할 수 있게 되는 것이다. 이것이 바로 base64 인코딩을 사용하는 주된 이유이다.