전화카드한장

 마이컴 1993년 12월호 - 특별 기고 

 유니코드와 국내소프트웨어 산업의 미래 

유니코드의 출현 배경

전자계산기라는 이름이 암시하듯이 컴퓨터는 그 시작이 숫자의 처리였기때문에 문자로 된 데이터를 처리하는 데는 아직도 불편한 점들이 많다. 요즘 우리가 사용하는 컴퓨터는 영어 문화권에서 개발되었기 때문에 영문 처리를 기본으로 하고 있으나, 사실 영문자 처리가 오늘날까지도 완벽하게 되고 있다고 말하기 힘들다.

예를 들어, 영어사전을 만들려면 소리의 강약과 길이를 표현하는 부호들이 필요한데 우리가 사용하는 일반적인 컴퓨터들은 이를 제대로 지원해 주지 못하는 상황을 들 수 있다. 영문이 그러한데, 그 외의 문자들을 컴퓨터에서 지원하는데는 많은 문제점들을 안고 있다.

이러한 문제점들에 대해서 가장 안타까와하는 이들은 물론, 그러한 문자를 쓰는 사용자들이겠지만 이들을 대상으로 컴퓨터나 소프트 웨어를 판매하고자 하는 업체들의 아쉬움도 그에 못지 않다. 그래서 이러한 아쉬움을 가장 크게 느끼고 있는 나라가 미국이다.

거의 모든 산업 분야에서 국제 경쟁력을 상실해 가고 있는 미국에 있어 소프트웨어 산업은, 아직도 선두 주자 자리를 유지하고 있는 몇 안되는 소중한 산업 중 하나이기 때문이다. 이미 시장 규모에 있어 미국을 능가한 유럽 시장과 아직 그 크기는 작지만 무한한 성장 가능성을 지닌 동남아 시장을 얼마나 잘 개척하느냐에 미국 소프트웨어 산업의 장래가 걸려있다해도 과언이 아니다.

그런데 여기 가장 큰 걸림돌이 되는 것은 언어 문제이다. 세계를 상대로 컴퓨터 시스템을 판매하려면, 반드시 그 나라 말을 지원하는 소프트웨어와 하드웨어를 만들어 공급해야 한다. 여기에 따르는 어려움과 비용이 미국의 컴퓨터 회사들의 세계 시장 진출을 막고 있는 것이다. 이 문제를 해결하는 방법은 세계의 모든 언어를 처리해줄 수 있는 컴퓨터 시스템을 만드는 것이다. 그래서 탄생한 것이 '유 니코드'이다.

유니코드와 다국어 지원 코드의 진화

요즘 사용되는 컴퓨터 시스템에서 언어 지원은 다음 네가지 형태로 구분될 수 있다. 첫째는 영문 전용 시스템이 되겠고, 둘째는 영어가 아닌 다른 하나의 언어 (예:그리스어)만을 지원하는 시스템이다. 대부분의 경우 두번째보다는 두개 이상의 언어 (그러나 제한된 수)를 지원하는 시스템이 많다. 

이러한 세번째의 언어 지원 형태는 대개 그 나라말과 추가로 영문을 지원하는데 우리 나라에서 사용되는 KSC 5601도 여기에 속한다고 할 수 있겠다. 네번째로는 어느 언어나 모두 지원할 수 있는 시스템으로 'ISO 10646' 이나 '유니코드'가 이러한 언어 지원 형태의 예가 되겠다.

컴퓨터에 입력된 데이터는 처음에는 숫자와 영문 대문자 수준에서 처리되었는데, 7비트 아스키(ASCII) 의 등장으로 영문 소문자 처리도 가능해졌다. 그러나 7비트 아스키를 가지고는 영어와 불어 혹은 독어를 동시에 나타낼 수는 없었다. 그래서 등장한 것이 8비트를 사용하는 'ISO8859' 였다.

하지만 8비트를 가지고도 한글이나 한자를 나타내는 데는 역부족이었다. 이런 동양 문자를 나타내려면 더블 바이트의 사용이 불가피해졌다. 그렇지만, 더블 바이트 코드의 사용은 새로운 문제를 낳았다. 그것은 KS나 JIS 코드가 한글이나 한자를 나타내는 데는 두 바이트, 영문자를 나타내는데는 한 바이트를 사용하기 때문에 데이터의 랜덤 액세스(random access)가 불가능하다는 것이었다.

예를 들면, 어떤 데이터 항목의 다섯번째 글자를 찾기 위해서는 아스키(ASCII)를 사용하는 경우 데이터가 시작하는 곳에서부터 다섯번째 바이트에 위치한 곳에 가보면 원 하는 글자를 찾을 수 있다. 그렇지만 KS나 JIS 코드의 경우는 앞에서부터 한글자씩 읽지 않는 한, 다섯번째 글자의 위치를 장담할 수 없다.

앞의 네 글자가 한글과 영문 혹은 숫자가 섞여 있을 경우 최소 네 바이트부터 최고 여덟 바이트를 차지할 수 있기 때문이다. 다음에서 보겠지만 유니코드는 이러한 문제들을 거의 완벽하게 해결하고 있다. 아스키(ASCII)를 비롯한 기존의 표준 문자 코드들과 유니코드의 관계를 나타낸 것이 <그림 1> 이다.

유니코드의 탄생과 특징

이러한 이유로 인해서 유니코드는 태어났다. <표1>은 유니코드의 역사를 간추려 놓은 것이다. 유니코드라는 이름은 유니코드의 아버지라고 부를 수 있는 조 벡커(Joe Becker)라는 제록스(Xerox)사의 프로그래머가 지은 것으로 'Unique', 'Universal', 'Uniform' 세 단어의 앞 음절을 딴 것이다.

여기서 'unique'는 각 문자마다 고유한 코드값을 갖는다는 당연한 이야기이고, 'universal'은 세계의 모든 문자를 나타낼 수 있음을 나타내며, 'uniform'은 모든 문자가 두 바이트의 고정된 길이를 갖는다는 뜻이다. 이 마지막 단어의 의미를 잘못 해석하는 사람들이 많은데 각 문자가 고정된 길이를 갖는다고 했을 때, 여기서 '문자'는 한글의 한 음절이 될 수도 있고, 자모가 될 수도 있음을 알아야 한다.

예를 들어 독일어의 'Ü'를 나타내는 방법이 둘이 있는 데 하나는 'Ü' 형태로 이미 구성되어 있는 문자를 사용하는 것이고, 또 하나는 'u'와 '"'를 조합해서 나타내는방법이다. 완성형과 조합형 한글과 비슷한 경우로서 전자는 두 바이트짜리 문자 하나로 표현이 가능하고 후자의 경우는 두 바이트짜리 문자 두 개가 필요하다.

중요한 것은 ''u' 나 '"'가 각각 두 바이트로 구성되어 있다는 것이다. 이에 비해 KS나 일본의 JIS 코드는 한글이나 한자는 두 바이트, 영문은 한 바이트로 나타내는 가변 길이의 코드 체계이다. 유니코드 에서는 '가'나 'A' 모두 두 바이트로 표현된다.

유니코드 과연 차세대 ASCII가 될 것인가?

<표1>에 나타나 있듯이 유니코드는 미국의 업계 표준으로 시작하기는 했지만 이제는 어엿한 국제표준이 되었다. 사실 1990년까지만 해도 국제 표준화기구(ISO)의 국제표준문자를 제정하는 분과인 JTC1/SC2/WG2 는 유니코드와는 전혀 다른 구조를 갖는 네 바이트짜리 멀티옥테트 코드를 국제 표준으로 추진하고 있었다.

그러던 것이 91년이 되면서 유니코드 측의 협박(?)과 회유에 의해 방향을 180도 선회해 유니코드를 그대로 수용하는 새로운 안을 만들어 1993년 5월, 정식 국제표준으로 ISO 10646 을 발표하게 되었다.

필자도 ISO WG2 회의에 몇번 참석을 한 경험이 있는데 여기에 참가하는 미국 대표단, 곧 유니코드 사람들의 뛰어난 실력과 열성에 감탄을 하지 않을 수 없었다. 그들은 대부분 중국어나 일본어 중 하나는 유창하게 하고 한자에 대한 해박한 지식을 갖고 있으며, 한글도 읽고 쓸 줄 안다.

컴퓨터에 대한 전문지식은 두말할 나위 없고. 회의에 참석할 때 가장 철저히 준비를 해오는 그들이 회의를 주도하게 되는 것은 어떻게 보면 당연한 일이라고 하겠다. 그들은 WG2의 다른 참가자들에게 유니코드를 수용하지 않는 국제표준을 만들면, 자신들이 구현하지 않을 것이기 때문에 이름뿐인 표준이 될 것이라고 겁을 줬다.

그대신, ISO가 유니코드를 기본으로 표준을 만들면, 자신들도 현재의 유니코드를 개정해 회원국들의 필요를 최대한 만족시켜 줄 수 있다는 당근을 내밀었다. 많은 나라들이 관공서에 사무기기를 납품할 때, ISO 규격 준수를 조건으로 하기 때문에 유니코드는 ISO라는 간판이 필요했던 것이다.

결국 그들은 이 간판을 따냈고, 이제 유니코드를 탑재한 차세대 운영체제와 응용 소프트웨어들을 발표하고 있다. 그러면 유니코드 사람들이 생각하는 대로 유니코드는 새 ASCII로 정착할 수 있을 것인가? 사실 미국 내에서도 유니코드에 대한 비판의 소리가 없는 것은 아니다.

그동안 한 바이트로 잘 나타내오던 글자를 갑자기 두 바이트로 나타낸다니 모든 데이터가 갑자기 두배로 늘어나는 일이 발생한다고 아우성이다. 이에 대해 유니코드 지지자들은 이렇게 답한다. 반도체 메모리나 하드디스크 같은 데이터 저장장치의 가격은 날이 다르게 줄어들고 있는데 반해, 소프트웨어를 만드는 프로그래머들의 인건비는 계속 올라가고 있다.

프로그램을 수정하는데 드는 수고를 던다면 데이터 양이 늘어나는 것은 능히 감수할 수 있다는 것이 그들의 주장이다. 그리고 현재 사용하고 있는 모든 컴퓨터의 데이터를 유니코드로 변환하자고 하지는 않는다. 대형 컴퓨터가 관리하는 큰 데이터베이스들은 지금 현재 불편이 없으면, ASCII건 EBCDIC이건 그냥 사용하면 된다.

단지, 앞으로 나오는 워크스테이션이나 PC에서 유니코드를 채용하면 된다는 것이다. 멀티미디어 시대를 맞아 이러한 시스템들은 어차피 영상이나 음성 데이터를 많이 사용할텐데 여기서 텍스트가 두배로 늘어난다고 해봤자 전체 데이터에서 차지하는 비율은 극히 미미한 것이다.

어쨌든 <표2>와 <표3>에서 볼 수 있듯이 유니코드의 회원사는 현재 세계의 소프트웨어 산업을 주도하고 있는 회사들을 총망라하고 있다. 이들은 대부분 유니코드를 지원하는 제품을 개발하고 있거나 계획하고 있다. 하드웨어 회사가 아니라 소프트웨어 회사들이 유니코드를 주도하고 있는 이유는 문자코드 문제는 이제 하드웨어의 영역이 아니라 소프트웨어의 영역으로 간주되기 때문이다.

마이크로소프트 윈도우가 그러하듯이 차세대의 컴퓨터 환경은 고해상도 화면을 갖춘 컴퓨터에서 그래픽 사용자 인터페이스(GUI)를 기본으로 하기 때문에 모든 문자 처리도 운영체제가 소프트웨어적으로 하게 된다.

유니코드를 탑재한 첫번째 운영체제(OS)인 마이크로소프트의 '윈도우 (Windows) NT'는 이미 발표됐고, 노벨(Novell)의 '네트웨어(Netware) 4.0'도 유니코드를 지원할 것이라고 한다. AT&T의 차세대 운영체제 '플랜 (Plan) 9'도 유니코드를 지원 할 것이며 내년이나 후년쯤 선보일 IBM과 Apple이 합작한 객체지향 운영체제 '텔리전트(Taligent)'도 유니코드를 기본 코드로 채택하고 있다. 유니코드가 차세대 ASCII가 될 것이라는 것은 자명한 일이다.

유니코드와 한글

그동안 우리 나라에서 사용되었던 한글 부호계는 어떤 것을 단위로 해서 부호값을 주었는지에 따라 크게, 소리마디 부호화 방식과 글자 부호화 방식으로 나눌 수 있다.

그동안 KS 제정을 놓고 많은 논란을 일으켰던 '완성형' 한글 코드가 대표적인 소리마디 부호화 방식이 되겠고, 1992년에 새롭게 KS 부호계에 포함된 '조합형' 한글 코드는 소리마디 부호화 방식과 글자 부호화 방식의 중간 형태가 된다고 볼 수 있 다.

ISO 10646와 유니코드 1.1에는 기존의 '완성형' 부호계 외에도, '완성형'과 '조합형' 부호계와는 다른 글자 부호화 방식의 부호계가 포함된다. ISO 10646에 포함된 '완성형' 한글 부호계는 6,656 소리마디를 나타내는데, 이중 2,350 소리마디와 1,930 소리마디는 기존의 KSC 5601-1987과 KSC 5657에 각각 포 함되어 있던 것이고, 2,376 소리마디가 ISO 10646 제정 과정에서 새롭게 추가 되었다. 

새로이 추가된 글자 부호화 방식의 부호계는 한글의 모든 글자(옛글자를 포함해)를 240개의 자모로 조합해 나타낼 수 있게 됨으로써, 유니코드를 채택한 시스템에서 기존의 '완성형' 부호계로 나타낼 수 없었던 한글 처리도 제약없이 할 수 있게 되어 있다.

이러한 자모 조합을 통한 한글 처리 방식은 ISO 10646에서는 'level 3 implmentation'에서 이루어지도록 되어 있어, 10646을 구현하는 모든 시스템에서 자모 조합이 이루어지기를 기대하기는 어렵다.

반면에 유니코드는 'level 3 implementation' 을 기본으로 하는, 실제적으로 'level' 구분을 하고 있지 않기 때문에 이론적으로는 유니코드 새 버전을 구현하는 시스템에서는 한글 자모 조합이 지원되야 한다.

유니코드에서 한글 처리 문제는 ISO 10646의 제정으로 어느 정도 마무리되었지만 구결*과 방점의 처리, 옛글자의 소팅 등 앞으로 해결해야 할 문제점들도 남아 있다. ISO/IECJTC1/SC2/WG와 유니코드 기술 위원회(Unicode Technical Committee) 활동에 적극 참여하여 적어도 한글 처리에 관해서는 우리가 능동적으로 방향 제시를 해야 할 것이다.

유니코드의 미래

ISO 10646과 이를 수용한 유니코드 1.1이 이제 활용 단계에 들어가고 있기는 하나, ISO JTC1/SC2/WG2 와 유니코드 기술위원회는 이 코드들이 앞으로 어떻게 발전해 나가야 할 것인지 연구를 계속하고 있다. 유니코드는 현재까지 만들었던 어떠한 코드체계보다도 많은 언어들을 지원하고 있기는 하나 월남어나 티베트어 등 아직도 무수히 많은 언어들이 포함돼 있지 않다.

또 우리나라와 중국, 일본은 현재 정의되어 있는 2만여자의 한자가 부족해 더 많은 한자를 유니코드에 포함시켜야 한다고 하고 있다. 이러한 모든 문자를 수용하려면 2 바이트 코드로는 불가능하다. 지난 11월 1일부터 5일간 미국의 워싱턴에서 열렸던 ISO WG2 회의에서는 코드 확장방법을 가지고 많은 논란이 있었지만, 결국 결론을 못내리고 내년 터어키의 앙카라 회의에서 토의를 계속하기로 했다.

유니코드 측이 그동안 유력시되던 4바이트 부호계인 UCS-4로 가는 안을 뒤엎고, 현 2바이트 체계를 조금 변형해서 백만자를 추가할 수 있는 새로운 안을 내놓아 참가자들의 의견이 양분되었 던 것이다.

유니코드와 국내 소프트웨어 산업

이대로 나가면 싫건 좋건 간에 2, 3년 안에 10646이나 유니코드를 채용한 차세대 운영체제를 우리도 사용하게 될 것이다. 또한 이를 바탕으로 한 외국 소프트웨어들이 물밀듯이 우리 시장으로 쏟아져 들어 오리라는 것은 불을 보듯 뻔한 일이다. 우리나라의 소프트웨어 개발자들이 더 이상 한글화라는 보호막에 의지할 수 없게 되는 것이다.

유니코드를 기본으로 하는 운영체제를 사용한다고 해서 모든 응용 소프트웨어에서 한글 지원이 잘 된다는 보장이 있냐고 의문을 던질 수 있다. 그동안 한글윈도우를 사용해 본 사람들은 어떤 영문 윈도우용 응용 소프트웨어는 한글윈도우에서 잘 돌아가는데, 어떤 것은 사용할 수 없었던 경험을 갖고 있을 것이다.

같은 일이 '윈도우 NT'에서 일어나지 않으리라는 보장이 어디 있느냐 할 수 있을 것이다. 한글 윈도우에서 잘 돌아가지 않는 영문 소프트웨어는 데이터의 문자 크기를 무조건 한 바이트로 가정을 하고 있거나 데이터 바이트의 최 상위 비트 (MSB:Most Siginificant Bit)에 특별한 의미를 부여해 사용하고 있는 경우가 많다.

유니코드를 채용한 운영체제에서는 영문이라도 한 바이트로 나타낼 수 없기 때문에 프로그래머들이 영문만을 위한 프로그 램을 만드는 것을 근본적으로 막아주고 있다. 그렇다 해도 "C프로그래머가 데이터에다 포인터를 들이대고 한 바이트씩 건너 뛰며 데이터를 읽거나 쓰는 것을 어떻게 막겠는가"라 는 의문을 갖는다면, 필자가 만났던 텔리전트(Taligent) 엔지니어의 이 야기를 들려 주겠다.

"우리가 만드는 객체 지향 운영체제에서는 우리가 제공하는 데이터 접근 방법을 쓰지 않고 프로그래머가 임의로 데이터에 접근할 방법이 없다. 다음 문자를 읽어라 혹은 써라 하는 'method'는 있을지 몰라도 한 바이트를 읽거나 쓰는 'method'가 텍스트 오브젝트 용으로는 제공되지 않을 것이다."

외국 소프트웨어의 한글화 과정이 지금보다 훨씬 쉬워지고 거기에 드는 시간과 수고가 지금보다 현저히 줄어들 것이라는 것은 확실해 보인다. 많은 사람들이 필요로 하는 소프트웨어는 적어도 사용설명서나 메시지 등을 한글화 하는 작업을 거쳐 국내 시장에 들어올 것이고 소수가 사용하는 소프트웨어 등은 그대로 수입해서 사용해도 한글 입출력에 별 문제가 없을 것이다.

불법복제 단속 등으로 이제 어느 정도 성장 가능성을 보이고 있는 우리의 소프트웨어 시장은 외국 소프트웨어의 집중 사격을 받을 것이다. 우리가 이에 대항할 수 있는 방법은 두 가지가 있다.

첫째는 우리의 기술력으로 한국형 차세대 운영체제를 개발하여 독자적인 노선을 걷는 것이고, 둘째는 운영체제는 외국의 것을 이용하더라도 국제 표준 코드를 지원하는 응용 소프트웨어 개발에 총력을 기울여 우리도 세계를 시장으로 한 소프트웨어 개발 선진국이 되는 것이다.

"국제 문자 코드의 표준화는 외국 소프트웨어의 한국 시장 진출을 용이하게 하지만 역으로 우리 소프트웨어의 해외 진출도 쉽게해 줄 것이다. 유니코드가 우리의 소프트웨어 산업에 몰고 올 위기를 오히려 도약의 기회로 전환시키는 것만이 우리가 살 길인 것이다. "

국제 분업화 시대에 살며 국제교역이 경제의 큰 부분을 차지하는 우리나라의 경우, 첫번째 방법은 실현 가능성이 희박한 것 같다. 그렇다면 우리나라 소프트웨어 산업의 앞날은 두번째 방법에 달려 있는 것 같다. 국제 문자 코드의 표준화는 외국 소 프트웨어의 한국 시장 진출을 용이하게 하지만 역으로 우리 소프트웨어의 해외 진출도 쉽게해 줄 것이다.

이 세상 문자들 중에는 입력된 글자를 그대로 나타내지 않고, 모아서 모양을 변형해서 나타내 주는 한글과 같은 문자들이 의외로 많다. 아랍어를 예를 들면, 조합하는 경우의 수가 우리보다 훨씬 더 많고 쓰는 방향도 오른쪽에서 왼쪽으로 가다가 숫자가 나오면 왼쪽에서 오른쪽으로 가기 때문에 컴퓨터에서의 처리가 대단히 복잡하다.

유니코드는 이러한 문제까지도 물론, 모두 운영체제 수준에서 해결하려 하고 있다. 그러나 소프트웨어 개발은 그 나라의 언어뿐 아니라 문화와도 밀접한 관계를 가지고 있다. 운영체제를 개발하는 수준말고도 날짜표시 형식, 각종 단위들, 소숫점 찍는 방법 등 소소하면서도 응용 소프트웨어들이 제대로 처리해 주어야만 하는 부분들이 많이 있다. 

유니코드 프로젝트에 참가하고 있는 미국의 소프트웨어 엔지니어들은 이러한 국제화 문제에 대한 전문가들이다. 그러나 응용 프로그램을 만드는 미국의 모든 프로그래머들도 똑같은 전문성을 갖고 있다고 볼 수는 없다. 그동안 모든 사고의 방향을 미국 국내 시장 위주로 해왔던 미국의 응용 소프트웨어 개발자들이 국제화에 필요한 의식 체계를 갖추려면 어느 정도 시간이 걸릴 것이다.

여기에 비해 우리 나라의 프로그래머들은 한글 처리 문제 때문에 많은 시간과 노력을 투자한 경험이 있다. 그 덕에 우리는 키보드에서 입력한 글자가 그대로 화면에 나타나지 않을 수도 있다는 것을 잘 알고 있다. 이러한 우리의 경험은 우리가 국제 시장에 진출 하는데 훌륭한 밑거름이 될 것이다. 유니코드가 우리의 소프트웨어 산업에 몰고올 위기를 오히려 도약의 기 회로 전환시키는 것만이 우리가 살 길인 것이다.

글이 마음에 드시면 아래 공감♡버튼 살짝 눌러주세요.

공감과 댓글은 저에게 큰 힘이 됩니다.