가끔 인터넷 서핑을 하다 보면, 한국 사이트임에도, 글이 이해할 수 없는 문자로 쓰인 경우를 만나게 된다. 왜냐하면, 그 사이트에 적힌 문자를 원래 인코딩된 것과는 다르게 해석했기 때문이다. 컴퓨터가 이해할 수 있는 것은 오직 0과 1의 조합으로 이루어진 2진수뿐이다. 따라서 한글을 컴퓨터에 이해시키려면, 한글을 2진수로 코드화하는 과정이 필요하다. 또한,, 한글은 음소 문자이기 때문에, 로마자나, 히라가나처럼 각각의 자모에 코드를 붙이는 것만으로는 글자를 만들 수가 없다. 따라서 좀 더 복잡한 방식이 필요하다. 그런 어려움 때문에 컴퓨터가 우리나라에 보급되면서, 많은 기관과 기업들에서 다양한 인코딩 방식을 도입했고, 지금은 그런 방식들이 혼재되면서, 위와 같은 상황이 발생한 것이다. 따라서 한글 인코딩의 종류와 역사를 아는 것은 무척 중요하다고 할 수 있다.

  한글 인코딩은 크게 조합형과 완성형으로 분류된다. 초기의 인코딩 방식은 조합형에서 시작했다. 왜냐하면, 조합형이 기본적으로 한글 원리에 맞게 하여졌기 때문이다. 처음에는 한글을 풀어쓰기(ㅍㅜㄹㅇㅓㅆㅡㄱㅣ 처럼)해서 각각에 한 바이트를 지정하는 방식을 사용했다. 즉, 위에 '풀어쓰기'는 위 방식대로라면 9바이트를 차지하게 되는 것이다. 이 'n 바이트 코드'는 80년대 초반에 널리 사용되었다. 그러나 문자를 비교하거나 순서대로 정렬하게 될 때 한글 배열 순서와 맞지 않는 문제가 있고 또한, 로마자 한 글자를 표현하는 데는 1바이트밖에 사용되지 않는 데 비해 9바이트는 너무 비경제적이라서 사라지게 된다.

  그 후에는 한글의 초성, 중성, 종성 각각에 1바이트씩을 배정해서, 음절 1개를 나타내는 '3바이트 코드' 을 쓰게 된다. 그러나 뒤에서 설명할 2바이트 조합형 방식보다 1바이트를 더 쓰게 되므로 비경제적이기 때문에 역시 사라지게 된다.

  2바이트 조합형 방식은 글자 그대로 2바이트로 한글 한 음절을 표현하는 방식이다. 먼저, 초성, 중성, 종성 각각에 5비트씩을 배정한다. 그러면 글자를 이루는 부분은 15비트가 된다. 이때 아스키코드와의 혼동을 피하고자 최상위 비트에 1을 써서 한글임을 구분한다. (0이면 로마자) 컴퓨터 회사가 당시 활발하게 경쟁하고 있었고, 따라서 2바이트 코드는 많은 회사들이 자체적으로 개발하여 사용했다. (삼성, 금성, 도깨비 등등) 그래서 초성, 중성, 종성 또한, 특수문자나 한자를 어떻게 표기할 것인지는 인코딩마다 달랐다. 결국,은 삼보 컴퓨터가 주도하고, 몇 개 회사가 함께 개발한 상용 조합형이 가장 오래 살아남았고, 후에 표준으로 지정되었다. 기본적인 원리는 위에서 설명한 것과 같다. 이 상용 조합형 방식은 한글 인코딩 문제를 훌륭하게 해결한 좋은 방식이다. 왜냐하면, 현존하는 모든 한글을 표현하는 것이 가능하기 때문이다. 그러나 기술적으로     둘째 바이트의 최상위 비트가 0이면 컴퓨터가 아스키코드로 해석하므로, 문자를 검색할 때 문제가 발생한다. 또한,, 위에서 말했듯이 수많은 회사에서 각각 자기들만의 고유한 코드 체계를 사용하고 있어서 호환성 문제가 대두하고 있는 상황이었다. 또한, 국제적으로도 ISO-2022가 통용되었는데, 조합형 방식은 ISO-2022와 호환되지 않았고, 결국은 완성형이 도입되게 되는 계기가 된다.

  완성형 코드는 초성, 중성, 종성으로 구성되는 한글의 기본적인 구조를 무시한다. 대신에 음절 하나하나에 코드를 부여하는 방식을 쓴다. 즉, 생각할 수 있는 한글 음절들에 모두 코드를 주는 것이다. 최초의 한글 완성형 코드는 청계천 상가 등지에서 탄생했다. 최상위 비트를 사용하지 못하는 영문 프로그램에서 쓰려고 7비트로 만들어졌다. 보통의 영어 단어들의 첫 단어가 대문자이고, 나머지는 소문자인 점에 착안하여 만든 것이다. 예를 들자면 첫 1byte가 소문자이고, 뒤에 1byte가 대문자이면, 한글을 출력하는 것이다. 그러나 그런 경우가 표현하는 글자 수를 넘을 수 없어서 그 수가 1,300개로 제한되었으며, 한글이 영어로 나오기도 하는 문제점이 있었다.

  아까 위에서 언급했지만, 수많은 회사들이 자기들 고유의 코드를 사용하면서 호환성 문제가 대두하였다. 그러나 조합형 코드 자체의 장점이 있기 때문에 회사들은 계속 사용하고 싶어했다. 하지만, 각자 회사의 이익 때문에 자꾸 자기 코드 중심으로 표준화를 진행하려 했다. 정부에서는 ISO-2022 문제도 있고, 빠르게 표준화를 진행해야 했으므로, 2바이트 완성형 코드(KS 완성형 코드, KSX-1001)를 만들기로 했고, 회사들도 모두 동의했다. 1987년에 마침내 KS 완성형이 만들어지고, 행정 전산망 사업과 후에 교육용 컴퓨터 보급 사업에서 모두 KS 완성형이 채택되면서 빠르게 보급되기 시작했다. 또한, 마이크로소프트나 다른 운영체제 회사들도 KS 완성형을 쓰기로 하면서 슬슬 표준화가 되어가기 시작했다. 그러나 완성형 코드에는 본질적인 문제점이 있을 수밖에 없었다. 왜냐하면, KS 완성형은 ISO-2022의 제한 때문에 94*94 문자집합을 선택할 수밖에 없다. 그러므로 KS 완성형은 특수문자와 외국 문자를 포함하여 총 9,816자, 한글은 2,350자를 지원한다. 따라서 현대 한글 11,172자를 모두 표현하는 것이 불가능하다. 물론 2,350자가 평소 언어생활에 쓰이는 것만 추려놓은 것이라 일반적인 작업을 할 때에는 큰 문제가 발생하지 않았다. 그러나 넣지 않은 몇몇 글자들은 진짜로 사용한 것인지 조사를 안 한 것들이 많았다. 또한, 한글 보다 한자가 더 많이 (4,888자) 포함되어 있어 비판하는 때도 있었다. 예를 들자면 5개 글자(뢨, 썅, 쏀, 쓩, 쭁)의 경우에는 받침이 없는 문자가 포함되어 있지가 않았다. 그래서 이러한 특성이 없었던 입력 기에서는 위의 문자들이 써지지 않는 현상이 발생했다. 그래서 2,350자 바깥의 한글을 처리하는 과정에서 프로그램마다 인코딩 방법이 여러 개로 나뉘는 현상이 일어나서 인코딩의 호환성이 보장되지 않았다. 그래서 그런 문제점을 해결하기 위하여 1992년에 상용 조합형도 함께 표준으로 지정되었다. 그렇게 95년까지는 조합형과 완성형을 함께 사용하게 된다.

  세월이 흘러 1995년이 되고, Microsoft에서는 출시될 Windows 95에 대해 발표를 하게 된다. 처음 Microsoft의 입장은 한글 Windows 95에 2바이트 조합형을 적용하는 것이었다. 그러나 원래 Microsoft는 2바이트 완성형으로 프로그램을 제작해 오고 있었다. 또한, 당시 많은 프로그램이 완성형으로 짜졌기 때문에 호환성 문제도 고려해야 했다. 만약 새롭게 조합형으로 프로그램을 다시 짜려면 Microsoft에게 큰 손해가 되리라는 것은 분명했다. 결국, Microsoft는 기존의 KS 완성형은 그대로 두고 새롭게 자신들이 8,875자를 만들어서 추가하는 방식을 선택했다. 그 방식이 바로 확장 완성형이다. 따라서 기존의 완성형과는 호환성을 유지하면서 모든 한글을 쓸 수 있게 된다. 그러나 문제는 따로 있었다. 왜냐하면 확장 완성형은 기존의 KS 완성형과의 완벽한 호환성을 유지하고자 기존의 2,350자에 그냥 8,875자를 끼워 넣었다. 즉 한글 배열 순서가 완전히 무시되는 상황이 발생했다. 한글 배열 순서가 맞지 않는다는 것은 사전이 뒤죽박죽 된 것과 똑같은 상황이다. 따라서 정렬을 하거나 문자를 검색하는 데 심각한 문제가 생긴다. 일단 위의 문제들은 완성형 코드를 조합형으로 바꾸어서 처리하면 해결된다. 하지만, 기존 KS 완성형과 Microsoft의 확장 완성형과의 장애가 발생하면서 자질구레한 문제가 발생하게 된다. 이런 문제들은 다음에 설명할 유니코드에 의해 대부분 해결된다. 그러나 Microsoft의 확장 완성형으로 인해 조합형은 이제는 더는 쓰이지 않는 인코딩이 되고 말았다. (위의 제한적인 용도를 제외하고는) 조합형은 한글 인코딩 문제를 완벽하게 해결한 좋은 방식이라는 점에서 무척 아쉬운 일이라고 볼 수 있다.

  유니코드는 엄밀하게 말하자면 국제 표준은 아니다. 유니코드의 목표는 전 세계의 문자를 컴퓨터에서 한 가지 방식으로 다루는 것이다. 유니코드 협회에서 주관하며, 이 협회는 여러 컴퓨터 회사들이 가담하고 있다. 유니코드는 기존의 인코딩 방식과는 다른 새로운 방식으로, 다양한 원리를 동원하여 개발한 인코딩이다. 먼저 2바이트를 사용한다. 또한, 정렬 등을 고려하였으며, 글쓰기 방향과 관련된 정보도 들어가 있다. 또한, 같은 문자를 한 번만 지정하는데, 보통 한자 하나에 다양한 의미를 담고 있기 때문에 문제가 되기도 했다. 1991년 말 최초의 유니코드인, 유니코드 1.0이 발표되었다. 그러나 유니코드 1.0의 한글코드는 KS 완성형만 포함되었기에 많은 사람의 외면을 받았다. 그 후 유니코드 1.1에서는 사람들이 조합형 코드를 포함해줄 것을 요구했다. 그러나 실제로는 조합형 일부만 사용할 수 있어서 사실상 사용이 불가능했다. 왜냐하면 한글 조합형은 현대 한글 11172자를 모두 사용할 수 있었기 때문에, 그 모든 글자를 모두 포함하는 것은 어려웠기 때문이다. 그 후 1995년 유니코드 2.0이 발표되었다. 유니코드 2.0에서 한글은 완성형과 조합형 두 가지 방식이 모두 들어가게 된다. 유니코드 완성형은 기존의 KS 완성형에 비해 발전한 방식이어서 사용하기가 편하다. 유니코드 조합형은 '한글 자모'라고 불리게 된다. 유니코드의 완성형과 조합형은 서로 변환하여 처리할 수 있었다. 따라서 어떤 한글 한 글자를 나타내는 데에는 유니코드가 2가지가 존재한다는 것을 알 수 있다. 이렇게 되면 정렬을 하거나, 검색을 할 때에는 코드를 다시 분해하고 조합하는 복잡한 작업을 거쳐야 한다. 그러나 이 방식의 장점은 조합형을 통해서 우리의 옛한글도 충분히 표현할 수 있다는 것이다. 만약 완성형만으로 우리의 옛 한글까지 모두 표현하려고 했다면 50만 자가 넘기 때문에 유니코드에서 모두 수용하기가 어렵다. 한자는 한국, 중국, 일본 등에 따라 사용하는 한자가 모두 다르다. 우리나라는 일반 한자를 그대로 사용하지만, 중국은 간체 자를 쓰기 때문이다. 그래서 각 나라에서 사용하는 한자들이 모두 들어가 있다. 하지만, 각 한자마다 다른 의미로 쓰이는 것들이 있기 때문에 아직 이런 문제가 완전하게 해결된 것은 아니다. 또한, 국제 한자 위원회에서 제안한 27,486자 중 20,902자만 들어가 있어서 문제가 있다. 하지만, 유니코드는 KS 완성형보다 무척 뛰어난 방식이며, 거의 한글 인코딩 문제를 해결하는 데 성공했다. 그러나 KS 완성형과 상용조합형 사이의 논쟁이 벌어지면서 미완성자인 1,147자는 신경을 쓰지 못했다. 이 1147자는 예를 들자면 초성만 있거나 중성만 있거나 종성만 있는 그런 음절 문자들을 말하는 것이다. 그래서 이 1,147자는 현대 한글 음절 수에 포함되지 못해서 유니코드 완성형에서 처리되지 않고, 유니코드 조합형에서 처리하게 된다. 아까 말했듯이 유니코드 조합형은 옛 한글을 표현하고자 만들어 진 것이다. 또한, 우리 정부에서 초기에는 유니코드에 대해 별 관심이 없었고, KS 완성형과 상용조합형의 관계에서만 고민하고 있었기에 옛한글 음절에 대한 연구를 하지 못했다. 따라서 초기의 유니코드(유니코드 1~2까지)는 아직 모든 한글을 완벽하게 표현한다고 말할 수는 없다. 그러나 당시의 유니코드 2.0을 사용하더라도 현재 사용하고 있는 한글을 인코딩 하는 데는 큰 문제가 없는데다가, 많은 세월이 흘러 작년에 유니코드 6.0까지 개발되면서 옛한글을 표현하기 위한 자모들이 많이 추가되었다. 또한, 자체적으로 옛한글을 표현할 수 있는 인코딩도 많이 개발되었다. 현재로서는 유니코드가 한글을 표현하기에 가장 좋은 수단이라고 할 수 있다. 그러나 아직 많은 프로그램과 웹사이트들이 KS 완성형이나 Microsoft의 확장 완성형 인코딩을 지원하고 있는 경우가 많다. 따라서 현재 유니코드, KS 완성형, Micorsoft의 확장 완성형(EUC-KR)이 공존하고 있다. 보통은 웹 브라우저가 그 사이트가 어떤 인코딩을 사용하는지 파악해서 보여주지만, 실패하면 이상한 글자로 보이게 된다. 그러므로 앞으로 웹사이트나 프로그램을 개발할 때 유니코드로 하는 것은 당연한 일이며, 또한, 지금 이미 다른 인코딩으로 개발된 웹사이트나 프로그램들도 단계적으로 유니코드로 바꿔나가는 것이 필요하다. 왜냐하면 유니코드가 아까 말했듯이 한글 인코딩 문제를 거의 완벽히 해결하고 있으며, 전 세계의 문자를 표현할 수 있기 때문이다. 예를 들자면, 한글판 Windows에서는 한글이 어떤 형태로 인코딩되어 있어도 그럭저럭 모두 볼 수 있을 것이다. 그러나 다른 나라의 운영체제에는 확장 완성형이나 KS 완성형이 지원되지 않을 가능성이 크다. 그러므로 그렇게 개발된 사이트는 외국인들이 사실상 볼 수가 없을 것이며 이것은 인터넷의 특성상 무척 바람직하지 못한 일이 될 것이다.

  지금까지 옛날의 N 바이트 조합형부터 시작해서 유니코드까지 한글 인코딩의 종류와 역사를 살펴보았다. 미래의 한글 인코딩이 갖춰야 할 점은 어떤 것들이 있을까? 먼저 한글 원리를 충실하게 따라서, 현대에 사용되는 모든 문자뿐만 아니라 옛날에 사용되던 한글도 모두 표현할 수 있어야 할 것이다. 당연하지만, 한글 인코딩이 어떤 프로그램에서도 호환되어야 할 것이다. 그리고 국제적으로 통용될 수 있어야 할 것이다. 이런 모든 요건을 잘 만족하는 것은 아까도 설명했지만 유니코드라고 본다. 한 가지 아쉬운 점은 상용 조합형도 정부나 기타 기관에서 충분히 노력했더라면, 지금까지의 진통을 겪지 않고, 훌륭하게 사용될 수 있었을 것이다. 그러나 정부나 기관에서는 충분한 고민을 하지 않고, 그냥 KS 완성형을 만들어 버렸고, 이는 Microsoft가 불완전한 확장 완성형을 도입하게 되는 원인이 된다. 앞으로의 한글 코드 표준화에 정부가 앞장서서 노력을 해준다면 지난 세월 동안 있었던 수많은 논쟁과 문제는 발생하지 않을 것이다. 앞으로 한글 인코딩 문제는 기존의 KS 완성형이나 확장 완성형으로 개발된 사이트나 프로그램들을 차례차례 유니코드로 바꿔나감으로써 해결할 수 있을 것이다. 또한, 정부에서는 앞으로의 유니코드 개발에서 한글이 좀 더 정확하게 표현될 수 있도록 예산과 학자들을 동원해서 주도적으로 일을 이끌어야 할 것이다. 다행히 유니코드가 새롭게 표준코드로 지정되고 점점 많은 사이트가 유니코드를 지원하고 있다. 항상 우리가 기억해야 할 점은 우리 글자인 한글을 제대로 표현하는 것이 정보화 사회에서 우리나라의 국력을 제대로 높이는 일이라는 것이다.