네트워크 통신 효율 관점에서 인코딩 바라보기

컴퓨터는 기본적으로 0과 1로 이루어진 이진 데이터를 처리합니다. 이러한 이진 데이터를 사람이 이해할 수 있는 문자로 변환하기 위해 인코딩이 사용됩니다.

아스키부터 유니코드까지

컴퓨터 인코딩의 역사는 미국에서 컴퓨터를 개발하면서 시작되었습니다. 처음에는 간단한 영어 문자를 숫자로 변환하는 아스키(ASCII) 코드가 사용되었습니다. 아스키 코드는 7비트로 표현되는데, 이는 128개의 다른 문자를 표현할 수 있음을 의미합니다. 이는 대소문자 알파벳, 숫자, 일부 특수 문자를 포함합니다.

그러나, 아스키 코드로는 다양한 언어와 특수 기호를 모두 표현할 수 없었습니다. 이를 해결하기 위해 아스키 코드를 확장하여 국제 규격에 맞게 일부 특수 기호들(pound 등)을 추가한 인코딩 코드인 ISO-8859-1이 등장하였습니다.

그럼에도 불구하고, 한글과 같은 복잡한 문자를 표현하기 위해선 더 많은 공간이 필요했습니다. 이를 위해 한글이 추가된 인코딩인 EUC-KR, KSC-5601 등이 등장했습니다. 그리고 이러한 인코딩 방식들을 통합하여 사용할 수 있는 유니코드(Unicode)가 등장하게 됩니다. 유니코드는 전 세계의 모든 문자를 일관되게 표현하고 다룰 수 있는 산업 표준으로, 우리에게 친숙한 유니코드 인코딩 방식은 대표적으로 UTF-8이 있습니다.

UTF-8이 널리 쓰이는 이유

한국을 포함한 많은 국가에서 UTF-8이 가장 널리 사용되는데, 그 이유는 비용 문제와 호환성 문제 때문입니다. UTF-8은 아스키 코드와 호환되며, 아스키 코드로 표현할 수 있는 문자는 1바이트로 표현되므로, 영어를 주로 사용하는 환경에서는 매우 효율적입니다. 알파벳을 기본으로 하는 많은 나라의 언어들을 표현하기에는 UTF-8이 메모리 효율성 측면에서도 탁월하면서, 네트워크 통신 과정에서도 영어 기준으로 봤을 때 각 알파벳을 1byte만으로 전부 표현할 수 있으니 통신 비용이 적게 들기 때문이죠.

한글에도 UTF-8이 최적의 인코딩 방식인가?

재밌는 사실은, 한글은 사실 UTF-8이 그닥 효율적이지 않다는 겁니다. 한글은 초성, 중성, 종성까지 한 글자로 표현해야 하는데, 그 조합의 경우의 수가 많아서 1byte만으로는 표현이 불가능합니다. UTF-8에서는 1byte 내로 표현되지 않는 문자는 그 다음 바이트에서 이어서 표현한다는 '구분자 bit'가 추가로 필요합니다. 결과적으로, UTF-8에서는 3 바이트로 한글 한 글자가 구성됩니다. 하지만 UTF-16에서는 2byte로 한 글자를 표현하는게 기본인데, 한글은 이 정도로는 충분히 모든 경우의 수를 커버할 수 있어서 2byte 내에서 모두 표현이 가능합니다.(중국의 한자는 너무 많아서 UTF-24를 사용한다고 합니다.) 즉, '한글'만 봤을 때에는 네트워크 통신 효율이나 메모리 효율이나 UTF-16을 사용하는게 효율적이라는 겁니다. (여담이지만, JVM에서는 기본적으로 UTF-16을 사용하고 있습니다.)하지만 일반적으로 통용되는 인코딩 방식은 모두 '영어'를 기준으로 되어 있기에 한글로도 개발을 할 순 있지만, 대부분의 개발을 영어로 하는 걸 권장하게 됩니다. (이 외에도 예기치 못한 호환성 이슈를 고려했을 때, 당연히 각 나라의 언어로 개발하겠다는 패기를 보이기보다는 영어로 개발하는게 더 안정적일 것 같다는 생각도 드네요.)