🙇세상의 중심🌐

http://changho-myrepository.blogspot.com/2007/10/pragma.html

2007년 10월 17일 수요일

#pragma

아직 #pragma까진 써본적 없지만, 앞으로 필요할것 같아서 퍼왔음
#pragma는 define 이나 include와 같이 #으로 시작하는 전처리구문(precompiler)의 하나이다.
컴파일러에 종속적인 구문이라 컴파일러가 변경되었을 경우 제대로된 동작을 보장하지 못하므로 프로젝트 진행중에 서로 다른 컴파일러를 사용한다면 사용하지 않음이 바람직 하겠다.
- 대신 대체하는 문법을 사용해야 되겠다.
#pragma once
이것은 "컴파일러에게 한번만 컴파일해!" 라고 명령한다.
헤더의 중복을 막아준다.
무슨말인가 하면

a.h를 구현한 a.cpp, a.h는 독립적이다.(include가 없다.)
b.h를 구현한 b.cpp, c.h, a.h순서로 include
c.h를 구현한 c.cpp, a.h를 include

컴파일하면 b.h에서 c.h를 포함시키라고 되어있네? 하고 c.h에 들어가고 어? a.h를 포함하라고 그러네? 이러고 a.h를 포함한 c.h가 b.h로 돌아온다 그리고 a.h를 포함하라는 명령을 받고 a.h를 추가하다보면 같은 변수와 함수선언이 되어있다. 에러에러~
같은 선언이 두 번 반복되니 당연히 충돌이 난다. 컴파일러가 똑똑하여 단순히 경고 처리만 해주고 알아서 하나로 종합해줄 수도 있지만 대부분의 기본적인 컴파일러는 이건 아니잖아~ 한다.
이럴 때 써주는 것이다. pragma once
이는 c기본문법을 사용하여 구현할 수 있다.

#ifdef _MYCOMPILECK
#define _MYCOMPILECK
// 헤더 파일의 내용 선언
#endif

#pragma comment()
기본적인 pragma comment()의 형식은 다음과 같다.

#pragma comment( comment-type, ["comment string"] )

[] 안의 구문은 comment-type에 따라 필요할 경우 사용하는 것이다.
comment type에는 compiler, exestr, lib, linker, user 등이 올 수 있다.

#pragma comment( linker, "/subsystem:windows" )
#pragma comment( linker, "/subsystem:console" )

linker 를 사용하면 프로젝트를 console application인지 win32 application인지 명시해줄 수 있다.
또한 섹션의 설정을 할 수 있다.

#pragme comment( linker, "SECTION:.SHAREDATA,RWS" )

#pragma data_seg("SHAREDATA") 와 함께 사용하여 공유 메모리를 생성한다.
위의 명령어 대신 def 파일 안에 아래와 같이 해주어도 된다.

SECTIONS
SHAREDATA READ WRITE SHARED

이 중 가장 대표적인 사용법은 명시적인 라이브러리의 링크이다.

#pragma comment(lib, "xxxx.lib")

와 같이 사용하여 해당 라이브러리를 링크시켜 준다.
여러사람이 같이 수행하는 프로젝트의 경우 이와 같은 방법을 사용하여 lib를 링크하는 것이 라이브러리가 링크되어있다는 사실을 알기에도 좋고 굳이 주석다라 설명할 필요도 없어 좋지 않나 싶다. (있다는 사실은 알지만 아직 프로젝트 수행중 실제로 사용해 본적은 없음)
#pragma data_seg()
pragma data_seg()의 형식은 다음과 같다.

#pragma data_seg( ["section-name"[, "section-class"] ] )

[]는 사용하지 않아도 된다는 의미이다.

#pragma data_seg( "SHAREDATA" )
int x;
char y;
#pragma data_seg()

DLL 파일을 만들어보면서 제일 많이 사용해 보았고 가장 헷갈려 했던 부분이기도 하다.
DLL의 데이터 공유를 하기 위해 사용한다.
공유할 섹션을 만드는 것이다. 위의 명령어는 필수적으로 위에서 사용된 두 가지중 한가지 방법과 함께 사용 되어야 한다.

#pragme comment( linker, "SECTION:.SHAREDATA,RWS" )

SECTIONS
SHAREDATA READ WRITE SHARED

둘 다 해당 SECTION(SHAREDATA)의 허용 범위(?속성?)를 설정하는 것이다. READ, WRITE, SHARED 세 가지를 쓴다는 의미~
해당 사항에 대해 msdn에서 자세한 정보를 발견하지 못해 적지 못하였다(검색능력의 부족!!)
이제 변수 x와 y는 해당 dll을 사용하는 외부 파일과 같이 공유할 수 있는 변수가 되었다.(외부에서 접근 가능하게 되었다.)
이렇게 공유하는 변수는 물론 new로 메모리를 할당한 변수도 공유 가능하다.
특히 new 나 memalloc(이건 아직 미확인이지만 같은 메모리 할당이므로 가능할 것으로 본다)으로 메모리할당한 변수들은 dll외부에서도 해제(delete) 가능하다.
#pragma warning
특정 경고를 끄고 싶을 때 사용한다.
비 쥬얼 스튜디오의 버전이 다르기 때문에 뜨는 경고는 더더욱이 귀찮은 존재이다.(하지만 수정해서 손해볼 것은 없다. 그것이 곧 버그로 이어질 수 있기 때문이다. 특히 형변환의 경우 강제 캐스팅하여 확실히 명시해주는 것이 좋다. 일부러 그 값을 떼어낸다는 프로그래머의 의지를 컴파일러에게 보여주자. 부지런할수록 후에 손이 가는 일이 적어진다. 노력하자~)
형식은 이와 같다.

#pragma warning( warning-specifier : warning-number-list [; warning-specifier : warning-number-list...] )
#pragma warning( push[ ,n ] )
#pragma warning( pop )

실제 사용은 아래와 같이 한다.

#pragma warning( disable:4996 )

#pragma message()
컴파일 중에 메세지를 뿌려준다.
말이 필요없다-.-/

#pragma message("merong")

작성자: changho 위치 오전 11:18

백택 (bektekk@yahoo.co.kr)
홈페이지 : http://bektekk.wo.to

문자열(스트링) 전격 분석 2강

본강좌는 코드 프로젝트에 제가 좋아하는 프로그래머인 Michael Dunn의 강좌
The Complete Guide to C++ Strings, Part I 과 II 를 번역한 글입니다.
최대한 의역을 하려고 노력했지만, 이런쪽의 경험이 부족하다 보니 많이 모자란
강좌가 되겠지만, 많은 도움이 되셨으면 합니다.
기타 문의 사항이나 질문은 쪽지나 메일을 이용해 주셨으면 합니다.
본강좌는 제 홈페이지(위의 링크)를 통해서도 보실수 있습니다.
이번강 까지가 좀 지루하겠네요.
다음강 부터는 실제 클래스들을 다루어서 조금은 덜 지루할거라 생각됩니다.

스트링을 조작하기^^

우리는 처음 C를 배울때 부터 SBCS 스트링을 사용하는데 익숙해져 있습니다. strlen() 같은 함수는 아마 처음 C공부하실때 누구나 써보셨을 것이고 아직도 쓰시고 계실겁니다. 또한 초보티를 막 벗을때 char* 타입을 이용해 ++, -- 연산자를 이용해 가면서 문자열 조작들을 해봤을겁니다. 또한 [] 식의 배열표현법으로 캐릭터 하나씩 값을 얻어오는 것에도 이미 익숙하실 겁니다. 이런 일련의 작업들은 SBCS 나 Unicode 스트링에서는 훌륭하게 작동합니다. 왜냐하면 모든캐릭터는 같은 길이이기 때문입니다. SBCS에서는 1바이트 유니코드에서는 2바이트 이기 때문이죠.

하지만, 우리는 DBCS 즉, 2바이트이상의 캐릭터들을 사용하게 된다면 이런 습관들을 반드시 버려야 합니다. 만약 DBCS 스트링을 쓸때에는 반드시 따라야 할 두가지의 룰이 있습니다. 이 룰을 어기면 야근이 버그 잡느라 좋아하는 드라마도 못보시고, 야근 하랴, 머리 빠지랴 고생들이 많으실 겁니다. ^^ (너무 장황하게 늘어놓았네요)

첫째, Lead Byte를 채크해지 않을거면 절대 ++ 포인터 연산을 하지말것

둘째. 절대 절대 -- 포인터 연산을 하지 말것

먼저 두번째 룰을 설명하겠습니다. 왜냐하면 설명하기 쉽기때문에^^. 여러분이 설정화일을 사용하는 프로그램을 작성한다고 가정합시다. 실행하면 그 프로그램은 그 설정파일을 읽어서 작업하겟죠? 만약 프로그램의 경로가 C:\Program Files\MyCoolApp이고, 설정파일은 C:\Program Files\MyCoolApp\config.bin 에 있습니다.

그럼 설정파일의 경로를 얻어오는 함수를 이렇게 작성했다고 가정합니다.

bool GetConfigFileName ( char* pszName, size_t nBuffSize )
{
char szConfigFilename[MAX_PATH];
 
    // 인스톨된 디렉토리를 얻어온다.
    // .....

    // 만약 마지막 캐릭터가 백슬래시가 아니면 추가해 준다.
    // 우선 마지막 캐릭터를 구한다.
    char* pLastChar = strchr ( szConfigFilename, '\0' );
 
    // *** 자 한칸 앞으로 가자 ***
    pLastChar--;  
 
    // 백 슬래시 추가
    if ( *pLastChar != '\\' )
        strcat ( szConfigFilename, "\\" );
 
    // 설정파일 디렉토리 끝에 화일명 추가
    strcat ( szConfigFilename, "config.bin" );
 
    // 리턴
    if ( strlen ( szConfigFilename ) >= nBuffSize )
        return false;
    else
        {
        strcpy ( pszName, szConfigFilename );
        return true;
        }
}

이 루틴은 잘짜여졌습니다. 그러나 특정한 DBCS캐릭터에서는 제대로 작동하지 않을 것입니다. 이유는 다음과 같습니다. 만약 디렉토리 이름이 "C:\디렉토리" 와 같다고 가정해 보면. 그 메모리 구조는 다음과 같게 됩니다. :

43
3A
5C
83 88
83 45
83 52
83 5C
00

LB TB
LB TB
LB TB
LB TB

C
:
\

디

렉

토

리

EOS

GetConfigFileName() 함수가 마지막 백슬래시를 확인할때 마지막 0이 아닌 바이트를 확인하는걸 볼수가 있으실 겁니다. (--포인터 연산으로) 그리고 같이 '\\' 인지 == 연산자로 확인했지만 결과적으로는 이 루틴은 잘못된 결과를 리턴합니다.

그럼 무엇이 잘못 되었을가요? 위의 메모리 구조에서 파란색으로 표시한 두 바이트를 살펴보면 백슬래시의 값은 0x5C이고 '리'의 값은 83 5C 입니다. (무언가 눈치 채셨겠죠?.. ^^) 위의 루틴은 '리'의 TB즉 Trail Byte만을 읽고 '\\'와 같은 같으로 간주해 버리게 됩니다.

위의 코드를 수정하려면 --포인터 연산을 제거하고 그에 상응하는 DBCS를 지원하는 함수로 대체 하는 것입니다. 수정한 코드는 아래와 같습니다. :

bool FixedGetConfigFileName ( char* pszName, size_t nBuffSize )
{
    char szConfigFilename[MAX_PATH];
 
    char* pLastChar = _mbschr ( szConfigFilename, '\0' );
 
    // 자 이제 제대로 된다.
    // 이전 캐릭터로 이동한다. 이것은 1바이트 일수도 있고
    // 2바이트 일수도 있다.
    pLastChar = CharPrev ( szConfigFilename, pLastChar );
 
    if ( *pLastChar != '\\' )
        _mbscat ( szConfigFilename, "\\" );
 
    _mbscat ( szConfigFilename, "config.bin" );

    if ( _mbslen ( szInstallDir ) >= nBuffSize )
        return false;
    else
        {
        _mbscpy ( pszName, szConfigFilename );
        return true;
        }
}

위의 수정된 루틴은 한 캐릭터 전으로 가기 위해 CharPrev() API 함수를 이용했습니다. 그 한 캐릭터는 위의 예에서와 같이 2바이트를 차지할 수도 있고, 1바이트 일수도 있으나, CharPrev() 함수는 이를 스스로 확인하고 제대로 작동할 것입니다. 따라서 위의 함수는 제대로된 결과 값을 리턴할 것입니다..

이제, 여러분은 위의 1번 규칙을 깨게 될때 일어나는 부작용도 쉽게 생각하실수 있으실 겁니다. 예를 들어, 여러분이 유저가 입력한 파일경로에서 캐릭터 ':' 가 중복되서 나타나는지 아닌지를 확인하는 루틴을 짠다고 생각해 보겠습니다. 그 루틴에서 만약 CharNext() API 함수 대신에 ++ 포인터 연산을 사용하셨다면 잘못된 결과를 초래할 것입니다. 특히 2바이트를 차지하는 한글 한 글자의 Trail Byte가 ':' 와 같게 되는 경우는 100% 잘못된 연산을 하게 될겁니다.

위에서 말한 2번 규칙에 하나를 더하자면:

2a. 절대로 배열 인덱스에 마이너스 연산을 하지 말자.

아래의 코드는 2번 규칙의 예와 굉장히 흡사합니다. 예로, pLastChar 값이 이런식으로 할당되었다면 :

char* pLastChar = &szConfigFilename [strlen(szConfigFilename) - 1];

이 루틴의 결과는 위의 설명드린 --포인터 연산의 부작용예와 똑같은 상황이 벌어집니다. 왜냐 사실 배열 인덱스의 연산도 내부적으로는 포인터 연산으로 처리가 되기 때문이죠.. 헥헥, 꽤나 장황하게 설명된 파트지만 실지 내용은 간단하죠?

다시 strxxx() 와 _mbsxxx() 함수로 돌아가서

이제는 왜 _mbsxxx() 함수시리즈가 필요한지 느끼실 겁니다. strxxx() 계열의 함수는 _mbsxxx() 함수시리즈와는 다르게 DBCS에 대해 전혀 알지 못합니다. 만약 strrchr("C:\\디렉토리", '\\') 이런식으로 호출을 하셨다면 그 결과같은 잘못된 값일겁니다. 반면 _mbsrchr() 함수는 마지막의 2바이트 캐릭터를 제대로 인식하고 제대로된 리턴값을 넘겨줄겁니다.

마지막으로 한가지 추가하자면 문자열 길이를 매개변수로 받거나 리턴하는 함수들에는 주의 하실 필요가 있습니다. strlen("스트링") 의 함수는 6을 리턴할 것입니다. 하지만 유니코드 함수 wcslen(L"스트링") 이건 3을 리턴할 겁니다. 주의하게요^^.

Win32 API에서의 MBCS 와 Unicode

두 종류의 API들

아마 눈치 채셨을지도 모르고, 아닐지도 모르지만, 모든 문자열을 다루는 API들은 두 종류로 이루어져 있습니다. 한가지 버젼은 MBCS를 다루고 다른 하나는 유니코드를 다룹니다. 예로, 실제로는 SetWindowText() 라는 함수는 없습니다. 대신 SetWindowTextA() 와 SetWindowTextW() 라는 두종류의 API가 실제로 존재하는 겁니다. 마지막의 A는 (ANSI의 약어쯤)은 MBCS로 처리하는 함수를 뜻하고, W는 유니코드 버젼을 뜻합니다.

여러분이 프로그램을 빌드 하실때 여러분은 MBCS냐 혹은 유니코드냐를 선택하실 수 있습니다. 만약 VC에서 셋팅을 건드리지 않으셨다면 기본적으로는 MBCS방식으로 빌드될겁니다. 그럼 어떻게 정의되지도 않은 SetWindowText() 라는 함수를 쓸수 있느냐 궁금하시겠죠? winuser.h 헤더파일을 살펴보시면 다음과 같은 일련의 #define문들을 보실 수 있으실 겁니다.:

BOOL WINAPI SetWindowTextA ( HWND hWnd, LPCSTR lpString );
BOOL WINAPI SetWindowTextW ( HWND hWnd, LPCWSTR lpString );
 
#ifdef UNICODE
#define SetWindowText  SetWindowTextW
#else
#define SetWindowText  SetWindowTextA
#endif

MBCS로 빌드 할때에는 UNICODE 가 정의되 있지 않습니다. 따라서 전처리기는 다음으로 해석하게 됩니다.:

#define SetWindowText  SetWindowTextA

따라서 전처리기는 모든 SetWindowText() 라는 문자를 SetWindowTextA() 라고 바꾸게 됩니다. 실제로 SetWindowText() 라는 매크로로 정의된 다른이름의 함수대신 SetWindowTextA 혹은 W 로 끝나는 함수를 쓰실수 있습니다. 물론 그럴일은 거의 없겠지만요..

그럼 기본값으로 유니코드를 사용하는 함수로 싸그리 바꾸고 싶으시다면, VC설정의 preprocessor settings에서 _MBCS 값을 list of predefined symbols에서 제거해 주시고 UNICODE 와 _UNICODE를 넣어주시면 끝납니다. 주의하실 것은 두개의 값을 모두 적어주셔야 합니다. 어떤해더는 UNICODE라는 것만 사용하고 어떤건 _UNICODE를 사용하기 때문입니다. 그렇지만, 유니코드를 사용하실때 주의 하실게 있습니다. 다음 코드를 살펴보죠:

HWND hwnd = GetSomeWindowHandle();
char szNewText[] = "we love Bob!";
 
    SetWindowText ( hwnd, szNewText );

위 코드는 전처리기가 "SetWindowText"를 "SetWindowTextW"로 바꾼후에는 다음과 같습니다.:

HWND hwnd = GetSomeWindowHandle();
char szNewText[] = "we love Bob!";
 
    SetWindowTextW ( hwnd, szNewText );

무엇이 잘못되었는지 아시겠나요? 여기서 우리는 유니코드를 취하는 함수에 SBCS 즉 1바이트 케릭터를 전달했습니다. 즉 제대로된 결과를 기대할수 없겠죠? 그 첫번째 해결방법은 모든 스트링에 #define문으로 아래와 같이 정의 하는것입니다.:

HWND hwnd = GetSomeWindowHandle();
#ifdef UNICODE
wchar_t szNewText[] = L"we love Bob!";
#else
char szNewText[] = "we love Bob!";
#endif
 
    SetWindowText ( hwnd, szNewText );

아마 모든 스트링을 이런식으로 정의하다가는 미쳐 버릴겁니다. 다른 직종을 알아보시겠죠? 여기에 대한 진정한 해결책은 TCHAR 입니다.

고맙다 TCHAR!

TCHAR MBCS에서건 유니코드에서건 똑같은 코드를 사용할수 있게하는 캐릭터 타입입니다. 바로 위에서 본 #define 문들의 해결방식을 이미 MS에서는 정의해 TCHAR 라는 방식으로 정의해 놓았습니다. 아래와 같습니다.:

#ifdef UNICODE
typedef wchar_t TCHAR;
#else
typedef char TCHAR;
#endif

따라서 TCHAR 는 MBCS로 빌드할때는 char 이고, 유니코드로 빌드할때는 wchar_t 타입이 됩니다. 또한 유니코드 스트링앞에 추가해 주는 L이라는 문자를 위해 _T() 라는 마크로도 있습니다.:

#ifdef UNICODE
#define _T(x) L##x
#else
#define _T(x) x
#endif

## 는 두개의 문자열들을 하나의 문자열로 만들어 주는 전처리기 연산자 입니다. 여러분은 이 글을 보고 나면 이제 스트링을 선언 할때면 언제든지 _T 마크로를 사용하셔야 합니다. 이 마크로는 유니코드 문자열 앞에는 L문자를 추가해 줍니다.

TCHAR szNewText[] = _T("we love Bob!");

SetWindowTextA/W 를 편하게 왔다갔다 할수 있게 해주는 정의들이 있는것 처럼, strxxx() 과 _mbsxxx() 류의 스트링 처리 함수들 사이를 편하게 변경시킬수 있는 정의 들도 있습니다. 예를 들면, 여러분은 _tcsrchr 마크로를 strrchr() 이나 _mbsrchr() 혹은 wcsrchr()를 쓰는 대신 쓰실수 있습니다. _tcsrchr 함수는 SetWindowText 함수가 그러하듯 MBCS환경이냐 혹은 유니코드 환경이냐에 따라서 적절히 치환될 것입니다.

TCHAR 를 취하는 함수는 비단 strxxx() 계열의 함수만은 아닙니다. 예를 들면 _stprintf (sprintf() 와 swprintf()를 치환) 이나 _tfopen (fopen() 과 _wfopen()를 치환)과 같은 함수들도 있습니다. 이와 관련된 함수들의 전체 리스트는 MSDN의 "Generic-Text Routine Mappings" 부분을 참고하시기 바랍니다.

문자열 그리고 TCHAR 타입들

타입
MBCS환경에서
유니코드 환경에서

WCHAR
wchar_t
wchar_t

LPSTR
0으로 끝나는 char형의 문자열(char*)
0으로 끝나는 char형의 문자열 (char*)

LPCSTR
0으로 끝나는 const char형의 문자열 (const char*)
0으로 끝나는 const char형의 문자열 (const char*)

LPWSTR
0으로 끝나는 유니코드형의 문자열 (wchar_t*)
0으로 끝나는 유니코드형의 문자열 (wchar_t*)

LPCWSTR
0으로 끝나는 const 유니코드형의 문자열 (const wchar_t*)
0으로 끝나는 const 유니코드형의 문자열 (const wchar_t*) 

TCHAR
char
wchar_t

LPTSTR
0으로 끝나는 TCHAR형의 문자열 (TCHAR* -> char*) 
0으로 끝나는 TCHAR형의 문자열 (TCHAR*->wchar_t*)

LPCTSTR
0으로 끝나는 const TCHAR형의 문자열 (const TCHAR*)
0으로 끝나는 const TCHAR형의 문자열 (const TCHAR*)

언제 TCHAR 와 유니코드를 사용할 것인가

이제 여러분은 유니코드 없이도 잘 살아 왔는데 왜 유니코드를 사용하여야 하는가 의문이 들 것입니다. 유니코드 방식을 쓰면 득이 될 경우는 세가지가 되겠습니다.:

1. 프로그램이 오직 Windows NT 환경에서만 돌아간다.
2. 프로그램이 MAX_PATH 보다 긴 파일명의 문자열을 사용한다.
3. 프로그램이 Window XP등에서 소개된 오직 유니코드만 받는 함수를 사용한다.

대부분의 유니코드함수는 Windows 9x시리즈에는 구현되 있지 않습니다. 프로그램이 9x시리즈에서도 돌아가야 한다면 유니코드는 좋은 선택이 아닐겁니다. (Microsoft Layer for Unicode 라는 9x에서도 유니코드를 지원하는 라이브러리가 있긴 합니다.) 그렇지만, NT는 내부적으로는 모두 유니코드를 사용하기 때문에 유니코드 API가 아마 약간의 성능향상에 도움이 될것입니다. MBCS방식의 스트링을 NT환경에서 사용하면 운영체제는 내부적으로 그 스트링을 유니코드로 변환한 다음 그에 상응하는 유니코드 함수를 호출할 것입니다. 결과가 리턴되면 다시 MBCS방식으로 전환한 다음 리턴해 줄것입니다. 이 절차는 상당히 최적화 되있겠지만, 아마 유니코드를 직접쓸때보다는 성능의 아주 약간일지도 모르지만 감소는 피할수 없을 겁니다.

NT는 또한 아주 긴 파일명을 지원합니다. (MAX_PATH 보다 긴 파일명) 그러나 유니코드가 쓰일 때만 입니다. 하지만 무엇보다도 가장 큰 장점은 모든 언어 예를 들면 중국어, 영어 , 일어, 한국어 를 똑같은 방식으로 처리해 줄수 있다는 것일 겁니다.

마지막으로, Windows 9x 시리즈를 마지막으로 MS는 MBCS API방식을 멀리하고 유니코드 방식으로 전향하고 있습니다.  예를들면, SetWindowTheme() 이라는 API 함수는 오직 유니코드 스트링 만을 받습니다. 상응하는 MBCS버젼이 없습니다. 유니코드만을 사용하는 것은 이제 유니코드와 MBCS사이의 왔다갔다 해야하는 귀찮음을 얻에 줄겁니다.^^

그리고 지금 당장 유니코드를 사용하지 않으실 지라고, 여러분은 반드시 TCHAR 와 그와 관련된 함수들을 써주셔야 미래를 위해 좋으실 겁니다. DBCS를 보다 안전하게 사용하는것 못지않게 나중에 유니코드로 프로그램을 바꾸실때 단지 셋팅하나 바꿔주면 만사 오케이 이기 때문이죠^^

L 리터럴과 유니코드 인코딩

c++에서 문자를 저장하기 위해 8 비트 크기의 char 타입 이외에 16 비트 크기(윈도우에서는 16 비트를 유닉스 계열에서는 32 비트를 사용한다고 합니다.)의 와이드 캐릭터를 저장하는 wchar_t 타입을 제공하고 있습니다. wchar_t 타입에는 문자의 MBCS/DBCS 및 UCSUTF-16(윈도우에서는 little endian을 기본적으로 사용합니다.) 인코딩을 저장할 수 있습니다. 또, wchar_t와 함께 와이드 캐릭터/문자열 상수를 지정하기 위해 “L”을 사용합니다.

문자열의 인코딩은 소프트웨어의 globalization 을 위해 필요한 여러 이슈중 하나로 MSDN 및 구글 검색을 통해 이 내용을 다루는 많은 웹 페이지를 검색해 볼 수 있습니다. 그 중 유니코드와 캐릭터 셋의 이해를 개발자의 필수항목으로 지적하고 있는 Joel Spolsky의 글을 보는 것이 도움이 될 듯합니다. 이 글은 얼마전 jrogue님이 번역한 “조엘 온 소프트웨어”를 통해 한글로도 읽어 볼 수 있습니다.
또 The Complete Guide to C++ Strings, Part I - Win32 Character Encodings 도 참고할 만한 문서입니다. 이 문서는 한글로도 번역되어 있습니다.([1], [2])

다음은 wchar_t와 유니코드를 다루면서 생각하지도 못했던 문제로 하루를 꼬박 보내버리게 된 이야기입니다.

문제는 wcslen() 메소드를 통해 L”" 로 지정된 문자열의 문자수를 알아오는데에서 시작했습니다.

setlocale(LC_ALL, ".949");
wchar_t *wstr1 = L"abc";
printf("length: %d", wcslen(wstr1));

--- 결과 ---
length: 3

원하는 결과였습니다. 그런데 다음 코드의 결과는 이상합니다.

setlocale(LC_ALL, ".949");
wchar_t *wstr2 = L"가나다";
printf("length: %d", wcslen(wstr2));

--- 결과 ---
length: 6

분명히 타입은 wchar_t 이므로 결과는 3이 나와야 할 것 같은데 char 타입과 strlen() 함수를 사용할 때와 마찬가지로 6이 나옵니다. 그래서 메모리를 덤프해봤습니다. L”abc” 의 경우 다음과 같이 USC-16 little endian 으로 정확히 저장되었습니다.

61 00 62 00 63 00 00 00

그런데 두번째 L”가나다” 의 경우

B0 00 A1 00 B3 00 AA 00 B4 00 D9 00 00 00

(유니코드 한글 코드테이블과 KS-5601 코드테이블을 참고하세요)
“가나다”의 DBCS 인코딩을 단순히 16비트로 저장하고 있는 것이였습니다. 참고로 “가나다”의 DBCS 인코딩은 다음과 같습니다.

B0 A1 B3 AA B4 D9 00

혹시 지금 제가 사용 중인 영문 윈도우의 문제가 아닐 까 싶어, vmware를 통해 한글 윈도우 98 SE와 한글 윈도우 2000을 사용해 테스트해 봐도 같은 결과가 나오더군요.

이번에는 명시적으로 MBCS 문자열을 유니코드(USC-16 little endian)로 변환해 wchar_t에 저장해 보았습니다.

setlocale(LC_ALL, ".949");
char *str2 = "가나다";
wchar_t wstr2_uni[blocksize];
memset(wstr2_uni, 0, blocksize * sizeof(wchar_t));
mbstowcs(wstr2_uni, str2, _mbstrlen(str2));

--- wstr2_uni의 메모리 덤프 ---
00 AC 98 B0 E4 B2 00 00

이렇게하니 처음에 원했던 바 데로 USC-16 little endian 으로 저장되더군요.

결론은

• L”"상수는 문자열을 유니코드로 인코딩하지 않는다. 다만 문자열을 16비트 wchar_t로 저장할 뿐이다. (이렇게 저장되어도 영문 Ascii는 유니코드 인코딩과 같은 결과를 얻을 수 있습니다.)
• 유니코드로 인코딩된 문자열을 얻기 위해서는 MBSC로 된 문자열을 유니코드로 변환해 사용해야 된다.

그건 그렇다고 치고, 아쉬운 점은 제가 본 유니코드 관련 문서들에서는 L”" 리터럴의 이와 같은 특성에 대한 내용은 찾아볼 수 없었다는 것입니다.
아마도 정작 유니코드의 사용이 필요한 언어권의 사람들이 쓴 것이 아닌 대부분 영문(혹은 라틴계열 문자)을 사용하는 사람들이 작성한 글이거나 이 글을 번역한 글이기 때문일 것이라 생각해 봅니다.

ps) 수십년간의 소프트웨어의 역사가 흘렀지만 아직도 globalization은 달성하기 힘든 높은 수준의 요구사항이 아닐까 합니다.

update
혹시나 하고 #pragma를 조사해보다 #pragma setlocale()를 발견했습니다. 다음과 같이 지정해줬더니 L”" 리터럴 문제가 모두 해결되는 군요.

#pragma setlocale(".949")

좀 더 알아보고 포스트할 걸 그랬습니다.

/*━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━/

__wcschr

wcschr 를 직접 구현한것.

/━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━*/

wchar_t* __wcschr(wchar_t *szInput, wchar_t c)

{

    wchar_t* pstr = szInput;

    wchar_t temp;

    if(c == 0)

    {

        while(*pstr++);

        return pstr - 1;

    }

    while(temp = *pstr++)

    {

        if(temp == c)

        {

            return pstr - 1;

        }

    }

    return 0;

}

//6822906  11000   Bee Accepted    C++    0.010   2008-11-30 12:14:00
#include 

#define MAX 52 //50 3185141890
typedef unsigned int DWORD;
DWORD g_nMatrix[MAX];
DWORD g_nAddTwo[MAX];

using namespace std;

void makeFibo(DWORD* nMatrix)
{
        int i;
        nMatrix[0] = 1;
        nMatrix[1] = 1;
        
        for( i = 2 ; i < MAX ; i++)
                nMatrix[i] = nMatrix[i-1]+nMatrix[i-2];

}
void makeResult(void)
{
        int i;
        g_nAddTwo[1] = 1;
        for(i = 2 ; i < MAX ; i++)
                g_nAddTwo[i] = g_nMatrix[i-1]+g_nAddTwo[i-1];
}
int main(void)
{
        makeFibo(g_nMatrix);
        makeResult();
        while(true)
        {
                int nYear;
                cin >> nYear;
                if(nYear == -1) break;
                cout << g_nAddTwo[nYear] << " " << g_nAddTwo[nYear+1] << endl;
        }
        return 0;
}

The Joel Test: 나은 코딩을 위한 12단계

SEMA에 대해서 들어보신 적이 있습니까? 소프트웨어 팀이 얼마나 잘하는지를 재는 나름대로 복잡한 시스템입니다. 앗, 아니! 그 링크를 누르지 마세요. SEMA를 "이해"만 하는데 아마 6년정도가 걸릴것입니다. 그래서 소프트웨어 팀이 얼마나 좋은지 등급을 매길 수 있는 - 좀 무책임하고 되는대로의 - 자체적인 버젼의 테스트를 만들었습니다. 이 테스트의 장점은 3분정도밖에 걸리지 않는다는 것입니다. 절약되는 시간으로 의대에 가서 공부할 수도 있을 것입니다.

Joel Test이 특별한 점은 각 직문에 예/아니오로 바로 대답할 수 있다는 것이다. lines-of-code-per-day(하루동안 산출되는 코드의 줄수)나 average-bugs-per-inflection-point(산출 시점의 평균 버그수) 같은 것은 알 필요가 없습니다. "예"에 해당 하는 질문에 1점씬 가산됩니다. 하지만 이 테스트는 핵 원자로에 사용하는 소프트웨어가 안전한지를 검사하는등 에는 사용하지 말아주십시오.

12점은 완벽, 11은 충분한 점수이지만 10점이나 그 이하는 심각한 문제가 있다는 신호입니다. 사실은 대개의 소프트웨어 회사 들이 2~3점을 받고 있고, 심각한 도움을 필요로 하고 있습니다. Microsoft같은 회사는 12점 만점을 받고 있습니다.

당연한 이야기지만 이것들만으로 성공과 실패를 가를 수는 없습니다. 특히, 아무도 필요없는 제품을 굉장히 훌륭한 소프트웨어 팀이 만들고 있다면, 역시나 아무도 원하지 않을 것입니다. 반대로 이런 방식을 따르지 않는 명인들이 세상을 바꾸는 소프트웨어 를 만드는 경우로 생각할 수 있겠습니다. 그러나, 이 12가지 이외의 요소를 모두 동등하게 놓고 본다면, 이들만 제대로 한다면 지속적으로 좋은 결과를 내는 잘 훈련된 팀이 될 것입니다.

1. Source Control(소스 컨트롤)을 사용하십니까?

상용 소스 컨트롤 패키지들도 사용해보았고, 무료로 사용할 수 있는 CVS도 사용해보았습니다. CVS는 무료이기는 하지만 충분합니다. 그렇지만 소스 컨트롤이 없다면 프로그래머들을 조율하는 일이 상당히 피곤할 것입니다. 프로그래머들은 다른 사람들이 어떤 것을 했는지 알 수 있는 방법이 없습니다. 이를 사용하면 실수를 쉽게 롤백할 수 있습니다. 소스 컨트롤의 다른 장점은 소스코드 자체가 모든 프로그래머의 하드디스크에 체크아웃(check out)되어 있다는 것입니다. 소스 컨트롤을 사용하는 프로젝트에서 코드를 날렸다는 이야기를 들어본 적이 없습니다.

2. 한번에 빌드를 만들어낼 수 있습니까?

"최신의 소스로부터 몇단계를 거쳐서 완제품(shipping build)을 만들 수 있습니까?"라는 의미의 질문입니다. 잘 되어있는 팀인 경우라면 하나의 스크립트로 checkout부터 시작하여 각 소스를 리빌드(rebuild)하고 각 버젼, 언어, #ifdef같은 조건별로 실행파일을 만들어내어 마지막 CDROM 레이아웃, 다운로드할 수 있는 웹사이트를 만들어 내는 정도까지 되어 있을 수 있겠습니다.

만일 이 과정이 하나의 단계 이상을 거친다면, 여기서부터 에러가 발생할 확률이 생깁니다. 정해진 기일이 가까워질수록 "마지막" 버그를 수정하고 실행파일을 만드는 등을 위해 빠른 사이클을 필요로 할 것입니다. 코드를 컴파일하고 설치파일을 구성하는데에 20단계가 필요하다면 급박한 시간때문에 사소한 실수를 저지르게 될 것입니다.

필자가 마지막으로 근무했던 회사에서는 이런 이유로 WISE를 InstallShield(역자주 : 두 제품 모두 설치본을 만들기위한 도구 입니다.)로 교체하였습니다. 설치 과정을 스크립트를 통해서 NT 스케줄러로 밤새에 자동으로 실행하도록 하고자 하였는데, WISE는 스케줄러로 실행할 수 없던 이유입니다. (WISE의 친절한 분들이 최신 버젼에는 이것이 가능하다고 알려왔습니다.)

3. daily build(일별 빌드)를 만드십니까?

소스 컨트롤을 사용하다 보면 누군가가 빌드를 실패하게 만드는 코드를 체크인 할 수 있습니다. 예를 들면, 새로운 소스파일을 추가해서 그 사람의 컴퓨터에서는 잘 컴파일되지만, 이를 코드 레파지토리(repository)에는 추가를 하지 않았을 수 있습니다. 이 사람은 이를 잊고 만족한 상태에서 컴퓨터를 잠그고 집에 돌아갑니다. 그렇지만 이로 인해 다른사람들은 작업을 할 수 없게 되고 결국 찝찝하지만 결과없이 집으로 돌아갈 수 밖에 없습니다.

모르는 사이에 빌드를 실패하는 이런 컴파일 오류가 나지 않도록 daily build를 만들게 됩니다. 큰 팀에서는 이런 경우를 위해서 daily build를 매일 오후 - 점심시간등 - 에 합니다. 사람들은 점심시간 이전에 될 수 있는 한 많이 체크인을 합니다. 점심을 먹으로 갔다가 다시 돌아오면 빌드는 이루어져 있습니다. 빌드가 실패하면, 사람들은 빌드가 성공한 이전 소스로 작업을 하면 됩니다.

엑셀팀에서는 누군가 빌드를 깨면 벌칙으로 다른 사람이 다시 깰때까지 빌드를 관리하도록 벌칙을 주었습니다. 이는 빌드를 깨면 받는 벌칙으로써 뿐만 아니라 모든 이들이 돌아가면서 빌드를 관리할 수 있게하여, 어떻게 돌아가는 지를 익히게 하는 방법으로써도 좋았습니다.

daily build에 관해 더 자세히 아시려면 저의 기사 daily builds are your friend를 읽으십시오.

4. 버그 데이타베이스를 가지고 있습니까?

뭐라고 반박하셔도 확신합니다. 코드를 짜고 있다면 설령 혼자 짜더라도 정리된 버그 명세 데이타베이스를 가지고 있지 않다면 낮은 질의 코드로 제품을 출시할 것입니다. 많은 프로그래머들이 머리로 버그들을 모두 기억할 것이라고 생각합니다. 말도 안되는 이야기입니다. 제 경우에는 한번에 2~3개의 버그밖에 기억을 못하고, 다음날이 되거나 출시를 위해 급해지면 전부 잊어버리게 됩니다. 버그를 제대로 트래킹해야합니다.

버그 데이타베이스는 복잡할 수도 있고, 간단할 수도 있습니다. 최소한으로 갖추어야할 요소는 다음과 같습니다:

• 버그를 완벽하게 재현할 수 있는 과정
• 버그가 없었다면 이루어졌어야할 결과(동작)
• 버그로 인하여 생긴 결과(동작)
• 누가 이 버그에 할당되어 있는지
• 고쳐진 버그인지 아닌지

버그 데이타베이스를 사용하지 않는 이유가 제품들이 너무 복잡해서라면, 이것들을 포함한 5컬럼의 테이블을 만들어서 사용하기 시작하세요.

버그 트래킹에 관해 더 읽으려면, Painless Bug Tracking을 읽으세요.

5. 새로운 코드를 작성하기 전에 버그들을 잡습니까?

마이크로소프트 Windows용 Word의 첫 버젼은 죽음의 프로젝트였습니다. 끝이 없었습니다. 계속해서 스케줄을 펑크냈습니다. 팀 전체는 말도 안되는 시간동안 일했고, 계속해서 연기되고 또 연기되었습니다. 그 스트레스는 엄청났습니다. 빌어먹을 제품이 몇년 후에 출시되었을때, 마이크로소프트는 팀 전원을 Cancun으로 휴가보내고, 이 원인을 분석하기 시작했습니다.

그들이 깨닫게 된 것은 프로젝트 매니저들이 스케줄을 너무 강요하였기 때문에 프로그래머들은 코딩을 빨리 할 수 밖에 없었습니다. 게다가 버그를 고치는 단계는 스케줄에 아예 존재하지 않았습니다. 결과적으로 질이 아주 나쁜 코드를 만들게 되었습니다. 버그 갯수를 줄이려는 노력은 전혀 하지 않았습니다. 한 프로그래머는 텍스트의 높이를 계산하는 루틴 대신에 "return 12;"로 대체하여 버그 리포트로부터 이 값이 어떤 영향을 주었는지를 알고자 했습니다. 스케줄은 단지 버그일 수 밖에 없는 기능들을 모아 놓은 체크리스트였습니다. 나중에 이 상황을 "무한 결함 방식(infinite defects methodology)"이라고 이름지었습니다.

문제를 해결하기 위해서 마이크로소프트는 반대의 "무결함 방식(zero defects methodology)"라는 방식을 체택했습니다. 많은 프로그래머들은 경영진들의 명령에 의해서 버그 갯수를 줄일 수 있다고 생각했음직한 이 방식의 이름 탓에 이를 비웃었습니다. 하지만 실제로는 "무결함(zero defects)"이라는 이름은 주어진 시간에 가장 우선순위가 높은 것은 코딩하기전에 버그를 잡는 것이란 사실을 지칭하는 말이었습니다. 이유는 다음과 같습니다.

일반적으로 버그를 고치지 않고 방치하는 시간이 길어지면 길어질수록 고치는데 더 많은 시간과 금전이 요구된다는 것입니다.

예를 들면, 오타나 문법오류등은 컴파일러가 쉽게 잡아서 고치는데도 별로 문제가 되지 않습니다.

만일 버그가 처음 실행시에 발생하여 보이게 되면, 모든 코드가 머릿속게 생생하게 존재하기에 바로 고칠 수 있을 것입니다.

며칠전에 작성한 코드에서 버그를 찾게 되면 이를 고치기 위해 조금 시간이 더 걸릴 것입니다. 아마도 코드를 다시 보게 되면 대부분의 내용이 기억나고 적정한 시간내에 버그를 고칠 수 있을 것입니다.

하지만 몇달전에 작성한 코드에서 버그가 발견된다면 이미 그 코드에 관해서 많은 것이 이미 생각나지 않을 것이고, 고치기도 상대적으로 힘들 것입니다. 그때쯤 되면 다른 사람의 코드를 수정하고 있는 와중일지도 모르고, 그사람은 Aruba로 휴가를 떠나있을지도 모릅니다. 이렇게 된다면 버그를 고치는 것은 기술을 익히는 것같이 되어버릴 것입니다. 천천히 꼼꼼하게 그리고 주의 깊게 코드를 살펴봐야 하고, 물론 문제를 해결하는데에 얼마나 걸릴지 정확하게 판단하기 힘든 상황이 될 것입니다.

게다가 이미 출하된 코드에서 버그를 발견한다면, 이를 고치는데에 큰 대가를 치뤄야할지도 모를 것입니다.

이렇게 시간이 적게 들기 때문이라는 이유가 하나의 이유가 됩니다. 또다른 이유는 버그를 수정하는데 걸리는 시간을 예상하는 것보다는 새로운 코드를 작성하는데 걸리는 시간을 예상하기가 훨씬 쉽기 때문입니다. 예를 들면, 내가 당신에게 리스트를 소트하는 코드를 만드는데 얼마나 걸리냐고 물어본다면, 꽤 정확한 대답을 할 수 있을 것입니다. 그렇지만, 질문을 바꿔서 당신의 코드가 Internet Explorer 5.5만 설치되어있으면 동작하지 않는 버그를 고치는데 걸리는 시간을 묻는다면, 문제가 무엇인지도 모르는 상황이기 때문에 얼마나 걸릴지 추측하지도 못할 것입니다. 3일이 걸릴 수도 있을 것이고, 운좋으면 2분이 걸릴 수도 있을 것입니다.

이것이 의미하는 바는 고쳐야할 버그가 많이 존재하는 상태의 스케줄이라면 그 스케줄은 정확할 수가 없다는 것입니다. 그렇지만 이미 알고있는 버그들은 모두 고친 상태라면 그 스케줄은 상대적으로 상당히 정확하게 지킬 수 있는 스케줄일 것입니다.

버그 갯수를 0에 가깝게 하는 또하나의 좋은 점은 경쟁에서 훨씬 빠르게 대응할 수 있다는 것입니다. 어떤 프로그래머들은 이를 두고 제품을 바로 출하할 수 있는 항상 유지하는 것이라고 이야기합니다. 경쟁자가 고객들을 가로채갈만한 굉장히 좋은 기능을 새로 만들었다면 축척된 많은 버그를 수정할 필요없이 바로 이 기능을 추가할 수 있을 것입니다.

6. up-to-date(최신) 스케줄을 가지고 있습니까?

비즈니스에 당신의 코드가 조금이라도 중요한 부분이라면, 코드가 언제쯤 완성될 수 있는지를 아는 것 또한 중요하다는 것은 당연할 것입니다. 프로그래머들은 엉터리 스케줄을 만드는데 악명이 높습니다. "언젠가는 될꺼야!"하고 외칩니다.

불행하게도 그런 식으로는 해결할 수 있는것은 없습니다. 비즈니스에는 코드를 출하하기 전에 데모, 전시회, 광고등등 미리 많은 것들을 판단하여 결정해야합니다. 이를 할 수 있는 단 한가지 방법은 스케줄을 가지고 이를 계속해서 현실적으로 최신내용으로 유지하는 것입니다.

스케줄을 가져야하는 또다른 중요한 이유는 이를 통해서 어떤 기능이 필요한지를 결정하게끔 만들어준다는 것입니다. 때문에 어떤 기능이 덜 중요한지 결정해야하고 featuris 가 되기 전에 이들을 포기하도록 합니다.

스케줄을 관리하는 것이 어려울 필요는 없습니다. 제 글Painless Software Schedules 에 좋은 스케줄을 만드는 간단한 방법을 설명하였습니다.

7. spec(설계서)를 가지고 있습니까?

스펙을 만드는 것은 이빨을 쑤시는것과 같습니다: 모든 사람들이 좋다고 인정하지만, 아무도 하지 않습니다.

왜 그런 현상이 일어나는지는 정확히 모르겠습니다만, 아마도 프로그래머들이 문서를 만드는 것을 굉장히 싫어하는데에 기인하는 것 같습니다. 그 결과로, 프로그래머밖에 없는 집단에서 한가지 문제를 해결하고자 하면, 이들은 문서를 만들기 보다는 코드로 자신들의 의견을 표명하려 합니다. 스펙을 먼저 만들기보다는 차라리 코드를 짜서 보여주는 것을 택한다는 것입니다.

설계 단계에서 문제를 발견하면 몇줄을 고쳐서 이를 수정할 수 있습니다. 그렇지만 코드가 짜여진 상황이라면 이 문제를 수정하는 댓가는 감정적으로나(코드를 그냥 버리는 것을 좋아하는 사람은 없습니다) 시간적으로나 훨씬 높게 되고 더 힘든 작업이 되어버립니다. 스펙을 통해서 만들어지지 않은 소프트웨어는 대개 설계가 잘못되어 스케줄을 엉망으로 만들어놓습니다. Netscape에서도 이런 문제로 인해 브라우저의 초기 네개의 버젼이 너무 엉망이 되어 결국 관리자들이 멍청하게도 코드를 전부 버리고 다시 짜도록한 결정을 내려버리게 되는 상황이 벌어졌습니다. 거기다 한술 더 떠서 Mozilla에서 이런 실수를 다시 반복하여 겨우 Alpha 단계에 가는데 몇년이라는 시간이 걸리게 되었습니다.

필자의 지론은 이 문제는 프로그래머들이 문서를 작성하는데 거부감이 없도록 작문 강의를 듣도록 보내는 것으로 해결할 수 있다는 것입니다. 다른 해결책이라면 스펙같은 문서 작성에 능숙한 관리자를 두는 것입니다. 두 경우 모두 "스펙없는 코드는 금물"이라는 간단한 규칙을 따라야 할 것입니다.

저의 4부짜리 글에 스펙 작성하는 요령에 대해 이야기했습니다.

8. 프로그래머들이 조용한 작업환경을 가지고 있습니까?

지식 근로자에게 공간, 조용함, 프라이버시를 줌으로해서 많은 생산성 향상을 얻는다는 것은 이미 증명된 사실입니다. 소프트웨어 관리의 고전인 Peopleware에서는 이 생산성 향상에 대해 자세히 기술합니다.

문제는 여기에 있습니다. 지식 근로자는 "in the zone"상태라고도 하는 "flow"상태에 들어섬으로써 가장 최상의 상태가 되어 일에 완벽히 집중하고 외부에 개의치 않게 됩니다. 완벽한 집중으로 시간 가는 것을 잊고 좋은 결과를 내게 됩니다. 이때에 바로 대부분의 생산적인 일들을 처리하게 됩니다. 작가, 프로그래머, 과학자 그리고 심지어 농구선수들까지도 "in the zone"상태가 있음을 이야기할 것입니다.

문제는 "zone"으로 들어가는 것이 쉽지 않다는 것입니다. 측정해보면, 최상의 생산성으로 일을 하기 위해서는 평균 15분이 걸립니다. 하지만 어떤 경우에는 피곤하고 이미 많은 일을 한 상태에서 "zone"상태에 들어가지 못하고 다른 일을 하거나 웹서핑이나 테트리스로 시간을 허비하게 될 수도 있습니다.

또다른 문제는 "zone"상태에서 빠져나가는 것이 매우 쉽다는 것입니다. 잡음, 전화소리, 점심식사, 잠시 스타벅스에 5분간 갔다오는 것 그리고 특히 동료에 의한 방해등에 의해 바로 "zone"에서 빠져나가게 됩니다. 동료가 1분이라는 짧은 시간 동안이라도 질문을 하여 "zone"상태에서 빠져나간다면 다시 되돌아가기 위해서 30분이 넘는 시간이 걸려 전체 효율에 치명적인 영향을 미칠 수 있습니다. 카페인 가득한 닷컴 회사들이 좋아하는 합숙소같은 곳에 옆의 마케팅 부서에서 계속해서 오는 전화에 대고 소리지르는 그런 시끄러운 환경이라면 계속된 방해로 지식 근로자들의 생산성은 추락하여 "zone"상태에 절대 이르지 못할 수도 있습니다.

프로그래머들에게 있어서 특히 어렵습니다. 생산성은 단기적인 기억력으로 한번에 얼마나 많은 작은 세부사항들을 다루느냐에 달려있습니다. 어떠한 방해도 이런 세부사항들을 잊어버리게 할 수 있습니다. 일을 다시 재개하면 그것들을 다시 기억하지 못하여 (사용하던 지역변수나 검색 알고리즘을 만들던 중에 어디에서 멈줬었는지등) 다시 찾아보게 되고, 이로 인해 다시 속도가 붙을때까지 느려지게 됩니다.

직관적으로 계산해보면 다음과 같습니다. 만일 프로그래머가 단 1분이라도 방해를 받아서(명백한 근거에 의해) 15분의 생산성을 날려버린다고 합시다. 철수와 영희 두 프로그래머가 낮은 칸막이로 주욱 늘어선(a standard Dilbert veal-fattening farm) 열린 사각 파티션 옆자리에 앉아 있다고 합시다. 영희가 strcpy함수의 유니코드 버젼 이름을 잊었습니다. 30초면 찾아볼 수 있겠지만, 철수한테 물어보면 15초가 걸립니다. 그래서 바로 옆에 앉아 있는 철수에게 묻습니다. 철수는 산만해지고 - 영희의 15초를 아끼기 위해 - 15분을 낭비하게 됩니다.

이번에는 벽과 문으로 나뉘어진 별도의 사무실로 가정을 합시다. 여전히 영희는 함수를 기억하지 못합니다. 다시 찾아보는 것으로 30초를 보낼 수 있을 것이고 옆 방에 있는 철수에게 물어보기 위해서 (일반적인 프로그래머의 평균 물리적인 건강상태를 봐서는 쉽지 않은) 일어나서 걷는 것을 포함한 45초를 보낼 수 있을 것입니다. 결국 찾아보는 것을 선택하여 30초를 보내게 되지만 철수의 15분을 벌어주게 됩니다. 대단하죠!

9. 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까?

컴파일 되는 언어로 코드를 작성하는 것은 여전히 아무 PC에서 할 수 없는 것 중의 하나입니다. 컴파일을 하는데 몇초 이상 걸린다면 최상의 기종을 사용함으로써 시간을 절약할 수 있을 것입니다. 15초 이상 걸린다면 지루해서 그 시간동안 The Onion을 읽게 될 것이고 너무 재미있는 관계로 거기에 빠져 수시간의 생산성을 날려버릴 것입니다.

모니터 하나로 GUI코드를 디버깅한 것은 불가능하지는 않지만 고통스러운 작업입니다. GUI코드를 작성하고 있다면, 2대의 모니터로 훨씬 쉬운 작업을 할 수 있을 것입니다.

대개의 프로그래머들은 아이콘이나 툴바를 위해 비트맵을 수정해야하고 대부분의 프로그래머 역시 좋은 비트맵 에디터를 가지고 있지 않습니다. 마이크로소프트에서 기본적으로 제공하는 Paint 프로그램으로 비트맵을 수정하는 것은 웃긴 일이지만 대부분 이렇게 하고 있습니다.

필자의 가장 최근 직장에 서 시스템 관리자가 계속해서 자동적으로 스팸을 보냈습니다. 이유인 즉슨 220MB이상의 하드드라이브를 사용하고 있다는 것이었습니다. 필자는 요즘 HD가격을 본다면 이 공간의 환산된 가격은 내가 이용하는 화장실 휴지보다 싸다는 것을 지적했습니다. 디렉토리를 정리하기 위해 10분을 허비하는 정도로도 큰 생산성 저하일 것입니다.

"최고의 개발팀은 절대 그들의 프로그래머들을 고문하지 않습니다!" 후진 제품으로 인한 작은 불편함이 쌓여서 프로그래머들이 불만에 찰 수도 있습니다. 그리고 그로 인한 불만에 찬 프로그래머는 비생산적인 프로그래머이기 쉬울 것입니다.

이런 것들을 모두 종합하면 프로그래머들은 최고/최신의 것들로 쉽게 매수된다는 뜻이 됩니다. 이는 높은 연봉을 주는 것보다는 훨씬 싼 방법일 것입니다!

10. 테스터들을 고용하고 있습니까?

팀이 최소한 2~3명의 프로그래머에게 테스팅만 전담하는 테스터가 할당되어 있지 않다면, 버그가 많은 제품을 출하하고 있거나 시간당 $100짜리 프로그래머에게 시간당 $30의 일을 시키는 낭비를 하고 있는 것입니다. 테스터를 고용하는 것이 낭비로 생각하는 것은 정말 잘못된 계산을 하고 있는 것이며, 많은 사람들이 이를 깨닫지 못하고 있는데에 놀랍니다.

이에 관해 더 자세히 알고자 한다면 Top Five (Wrong) Reasons You Don't Have Testers 를 읽으십시오.

11. 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까?

마법사를 고용하는데 그의 마법을 보지 않고 고용하시겠습니까? 당연히 그렇지 않겠죠.

결혼식에 요리사를 고용하는데 요리사가 만든 요리의 맛도 모르고 고용하시겠습니까? 그렇지 않을것입니다.(역자주: 실제로 결혼식장 요리사의 맛을 보는 비유는 우리나라에 맞지 않을 것 같네요. 이 문구의 뜻만 이해하세요)

하지만 현실에서는 매일 인상적인 이력서나 면접에서 맘에 든 이유로 고용하는 일들이 일어납니다. 혹은 ("CreateDialog()와 DialogBox()의 차이점은 무엇입니까")등의 문서만 보면 알 수 있는 사소한 질문으로 채용하기도 합니다. 프로그래머를 채용하는데 있어서 중요한 것은 그런 사소한 것들을 얼마나 많이 외웠느냐가 아니고 코드를 잘 작성할 수 있느냐입니다. 혹은 "아하!"류의 질문으로 채용하기도 합니다. "아하!"류의 질문이란 답을 알면 간단하지만 모르는 경우에는 절대 맞출 수 없는 질문을 이야기합니다.

제발 이런 방식을 그만 두십시오. 면접때 무얼해도 상관없지만 반드시 코드를 작성하도록 해야합니다.(더 많은 것을 알고 싶다면 Guerrilla Guide to Interviewing를 읽으십시오)

12. hallway usability testing(무작위 사용성 테스팅)을 하십니까?

무작위 사용성 테스트(hallway usability test)는 복도를 지나가는 다음 사람을 붙잡고 방금 짠 코드를 사용하게 하는 방식입니다. 5명에게 이 테스트를 한다면 95%의 사용성 문제에 대해 배울 수 있을 것입니다.

좋은 사용자 인터페이스 설계는 생각처럼 어려운 것이 아니고 사용자들이 당신의 제품을 구입하고 사용하게 하는데 있어서 절대적으로 중요합니다. 짧은 프로그래머 입문서로 UI 설계에 관해 필자가 쓴 무료 온라인 책을 읽어보실 수 있습니다.

하지만 사용자 인터페이스에서 제일 중요한 것은 많은 사람들에게 당신의 프로그램을 보여주면(5~6명이면 충분합니다) 제일 큰 문제점을 빠른 시간에 발견할 수 있다는 것입니다. Jakob Nielsen의 글에서 그 이유에 대한 설명을 찾을 수 있습니다. UI 설계 경험이 별로 없다고 하더라도 - 비용이 전혀 들지 않는 - 무작위 사용성 테스트를 한다면 당신의 UI는 훨씬 좋아질 것입니다.

Joel Test를 사용하는 4가지 방식

1. 자신이 속한 소프트웨어 팀의 점수를 매기고 그것에 대해 언급할 수 있도록 결과에 대한 이유를 필자에게 알려주십시오.
2. 프로그래머 팀의 관리자라면, 당신의 팀이 최대한 잘 운영될 수 있는지 확인할 수 있는 지표로 사용하십시오. 12점을 받기 시작하면 프로그래머들을 간섭없이 그냥 두고 비즈니스쪽 사람들이 그들을 간섭하지 못하게 하는데에 모든 시간을 할 수 있습니다.
3. 프로그래머 일을 맡을지를 결정해야하는 상황이라면 그 팀의 친한 사람에게 이 테스트 결과가 어떤지를 물어보십시오. 결과 점수가 너무 낮다면 이를 고칠 수 있는 권한을 받을 것인지를 확인하십시오. 그렇지 않으면 불만과 스트레스에 빠질 것입니다.
4. 프로그래밍 팀을 평가하여야 하는 투자자이거나 당신의 회사가 다른 소프트웨어 회사와 합병을 한다면 이 평가가 급한대로 괜찮은 지표가 될 것입니다.

조합형/완성형/유니코드의 모든 것

이 글은 1998년 10월에 작성하여 1998년 11월 마이크로소프트웨어에 게재된 글이다. 마이크로소프트웨어 잡지에는 <표>와 <그림>이 많이 있지만 원래의 글에는 편집상 빠져 있다. 마이크로소프트웨어 잡지에는 따로 편집하여 <표>와 <그림>이 추가된 것이며, 이 글에서도 빠져 있다. 또한 마이크로소프트웨어 잡지에서 편집하는 과정에서 원래의 글과는 약간의 차이가 발생하였는데, 이 글도 마이크로소프트웨어 잡지에 게재된 내용과는 약간의 차이가 있음을 밝힌다.

(월간 마이크로소프트 1998년 11월호 특집 참조 요망)

▶ 차 례 ◀

■ 들어가는 말 - 뾼차를 타고 온 최시맨과 뉵다리 馱방각하의 만남

■ 한글 코드의 정의
....... ● 한글 코드의 종류와 원리
.............. ▶ N바이트 한글 코드
.............. ▶ 3바이트 한글 코드와 자소형 한글 코드
.............. ▶ KSC5601-1987완성형 코드
.............. ▶ 상용 조합형 코드
.............. ▶ KSC5657-1991 확장 표준 코드(필자가 편의상 지정한 이름)
.............. ▶ KSC5601-1992 조합형 코드

■ 잘 못 끼어진 첫 단추는 이렇게 끼워졌다.
....... ● KSC5601-1987이 보급되는 과정

■ KS완성형 코드의 문제점

■ 확장 완성형 코드
....... ● 확장 완성형 코드가 지닌 한계와 문제점
....... ● 확장 완성형으로 한글을 표현하는 데 문제가 있는가?
....... ● 사실상 표준으로 영향력을 미치게 될 확장완성형

■ 유니코드에서 한글 코드 배정
....... ● 유니코드 일반적인 구조와 한글 처리 원리
....... ● 유니코드에서 한자는 어떻게 되었는가
....... ● 유니코드는 한글 및 한국어를 완벽하게 처리할 수 있는가

■ 한글 윈도우98과 문서처리기에서 한글 코드 및 한글 처리

■ 한글 표준 코드는 어떻게 처리되어야 하는가

■ 코드 변환에 대하여
....... ● KS완성형 <-> 조합형(상용)
....... ● KS완성형 <-> 유니코드
....... ● 조합형 <-> 유니코드

■ 정보는 자원이자 곧 국가 경쟁력이다.

▶ 박스기사

▶ [박스] ISO-2022 규격
▶ [박스] Unicode와 ISO-10646의 관계
▶ [박스] KSC5700코드와 문제점 - 제 1차 한글 코드 표준화 위원회 회의록
▶ [박스] 유니코드에서 현대 한글 완성형 11172자를 획득하는 과정
▶ [박스] 한글 코드별 효율성 비교 검토
▶ 참고 문헌

■ 들어가는 말 - 뾼차를 타고 온 최시맨과 뉵다리 馱방각하의 만남

정 보 검색이나 인터넷 검색이라는 말이 일반인에게 알려진 것은 최근 2 ~ 3년도 채 되지 않았다. 그럼에도 불구하고 이제는 어린 유치원생부터 중년의 주부나 노년의 할아버지까지 인터넷을 따라잡기에 여념이 없다. 아마도 인터넷이 지닌 무한한 잠재성과 정보화 사회로 가는 길목에서, 정보를 어디서 얼마나 어떻게 획득하느냐가 생존을 좌우하기 때문일 것이다. 이러한 와중에서 필자에게 문득 재미있는 생각이 떠올랐다. 한때 폭발적인 인기를 끌었던 펩시콜라 광고에 나오는 최시맨과 드라마로 유명했던 馱방각하가 팔씨름을 한다면 과연 누가 이길지 궁금했다. 그래서 먼저 이들이 있을 만한 인터넷 홈페이지를 찾아보았는데 뜻밖에도 찾을 수가 없었다. 펩시맨은 있어도 [최시맨]은 찾을 수가 없었고, [馱방각하]를 찾으면 대부분 찾지 못했으며 설령 찾았다 하더라도 소가 뒷걸음 치다가 쥐잡는 격으로 얼떨결에 찾는 것을 보고서 놀라지 않을 수 없었다. 검색 결과를 보면, 시스템 장애가 발생하였으므로 회사로 연락을 하라고 하던가, 다른 단어는 멀쩡한데 이런 단어는 바빠서 항상 처리할 수 없다든가, 아니면 이런 검색어는 문법 오류가 있다고 답하던가, [馱방각하]는 [饯방각하, 깎방각하]로 바꾸어서 돌려보내고, [최시콜라]는 [钰시콜라]로 바꾸어서 보내면서 찾을 수가 없다는 것이다. 아주 재미있는 결과이지만 그다지 유쾌하지는 않았다. 필자가 검색했던 인터넷 검색 엔진들은 한글 처리 부문에서 자타가 공인하는 최고 수준의 회사라는 점에서 어떻게 이런 일 있을 수 있는지 매우 궁금했다. 아마도 이러한 문제는 필자뿐만 아니라 독자에게도 궁금하게 다가올 듯한 문제이므로 그 이유를 더듬어 보기 위해서 글을 쓰게 되었다.

이 러한 문제는 한글 코드와 밀접한 관련이 있기 때문에, 먼저 한글 코드가 무엇이며, 그러한 코드는 어떻게 변해왔는지 간단하게 살펴보고, 각각의 특징을 살펴보면서 윈도우95에 이은 윈도우98의 등장은 어떠한 관계가 있으며, 앞으로 발전 방향은 무엇인지 함께 생각해보자.

............................................................................................... ◀ 차 례

■ 한글 코드의 정의

컴 퓨터는 내부적으로 정보를 처리하기 위해서 2진수 형태로 처리되기 때문에 인간이 사용하는 언어로는 사용할 수가 없다. 그래서 인간의 언어를 컴퓨터가 사용할 수 있도록 이진수의 대응 관계를 정의한 것을 문자 코드라고 한다. 따라서 한글 코드라는 것은 한글 및 한국어를 컴퓨터 내부에서 이진수로 처리하도록 정의해 놓은 문자 집합이다. 여기서 한글 및 한국어라고 하는 이유는 한글과 함께 사용하는 숫자, 영문자, 한자, 기타 등등의 문자를 포함하기 때문이다. (앞으로는 간단하게 한글 코드라고 부르겠다.)

초 기의 컴퓨터는 영어권 문화에서 만들어진 기계였으므로 컴퓨터를 쉽게 다루기 위해서 영어로 된 명령을 사용하도록 제작되었다. 이러한 컴퓨터가 국내에 처음 들어왔을 무렵에는 소수의 전문 교육을 받은 사람들만이 컴퓨터를 다루었기 때문에 영어를 그대로 사용했다. 그러다가 컴퓨터의 보급이 점차 증가되기 시작하면서 한국어로 된 명령과 한국어를 처리할 수 있는 프로그램이 필요하게 되었다. 그런데 그 당시 컴퓨터로는 한국어를 처리하려면 여러 가지 어려운 문제가 있었는데, 가장 커다란 문제는 기본적으로 컴퓨터는 1바이트 체계로 되어 있었기 때문에 최대한 표현할 수 있는 문자는 256자였다는 점이다. 현대 한글은 11172자였으므로 256자까지 표현할 수밖에 없는 1바이트 체계로는 현대 한글을 전혀 표현할 수가 없었다. 그래서 능력있는 개인이나 기업들이 하나 둘씩 각각의 한글 처리 방법을 고안하게 되었다. 이때까지만 해도 컴퓨터에서 한글을 사용한다는 것 자체가 대단한 일이었으므로 처리 방법이나 구현 원리 같은 것은 중요한 문제가 아니었다.

그림. 한글 코드의 예

............................................................................................... ◀ 차 례

● 한글 코드의 종류와 원리

현 재 국내에서 사용하거나 사용되었던 한글 코드는 많이 있지만 현실적으로 지금 사용하거나 앞으로 사용하게 될 코드 혹은 이미 사용되었지만 중요한 의의를 지닌 것들을 중심으로 설명하는데 한글 코드를 분류하는 기준과 각각의 한글 코드에 대하여 알아보자.

한 글 코드를 분류하는 기준은 여러 가지가 있지만 가장 중요한 기준은 한글 한 음절을 표현하는데 소요되는 바이트 수와 8번째 비트를 사용 여부이며 지금까지 제정되거나 사용되었던 것은 여러 가지가 있었지만 현실적으로 사용하거나 중요한 역할을 하는 것만 다루겠다.

............................................................................................... ◀ 차 례

▶ N바이트 한글 코드

이 것은 한글을 풀어 쓴 것과 같이 각각 자음과 모음을 한 바이트씩 처리하는 것이다. 따라서 한글 한 음절을 표현하기 위해서는 길이가 2바이트부터 5바이트까지 사용한다. 그래서 보통은 멀티바이트(multi-byte)코드라고도 한다. 이것은 80년대 초반에 널리 사용되었으며 7비트 아스키 환경에서도 사용할 수 있다는 장점이 있지만 한글 처리에서는 적합하지 않아서 곧바로 사라지게 된다. 무엇보다도 가장 문제가 되었던 것은 문자를 비교하거나 순서대로 정렬(sort)할 경우에 한글 순서와 맞지 않는다는 것이다. 이렇게 문제가 많아서 사라진 코드를 설명하는 데에는 다른 이유가 있다. 그것은 현재에 정보 검색, 맞춤법 검사, 자동 색인, 형태소 분석 등등에서는 N바이트 코드방식을 이용하고 있다는 점이다. 그 이유는 완성형이나 조합형 코드로는 언어 정보를 처리할 수 없기 때문인데, 현대어는 물론이고 옛한글은 더욱 불가능하다. 물론 유니코드는 현대어와 옛한글을 거의 모두 처리할 수 있도록 되어 있으므로 유니코드에서 다시 설명하겠다.

그림. N바이트 한 음절 구성 예

나 = ㄴ + ㅏ => 2바이트

닥 = ㄷ + ㅣ + ㄱ => 3바이트

삶 = ㅅ + ㅏ + ㄹ + ㅁ => 4바이트

觫 = ㄱ + ㅗ + ㅏ + ㄹ + ㅁ => 5바이트

............................................................................................... ◀ 차 례

▶ 3바이트 한글 코드와 자소형 한글 코드

3 바이트 한글 코드는 한글 한 음절을 초성, 중성, 종성으로 나누고 각각 한 바이트씩 배정하여 처리하는 것으로 한글 한 음절을 처리하기 위해서 3바이트를 사용하여 붙여진 이름이다. 이것도 일종의 조합형 코드이지만 한글 1음절을 표현할 때 2바이트 조합형 코드보다 1바이트를 더 많이 사용하기 때문에 비효율적이어서 자취를 감추게 된다.

자 소형 코드는 특별히 제정되었거나 널리 사용된 코드는 아니지만 필자가 편의상 설명하는 코드이다. 이 코드는 한글을 표현하기 위해서 자소 단위로 처리하는 것으로 N바이트 한글 코드와 거의 똑같으며 조합형 코드로는 처리할 수 없는 언어 정보를 처리하기 위해서 필요에 따라 만들어 사용하는 코드이다. 이 코드를 설명하는 이유는 현재 인터넷 정보검색, 맞춤법 검사기, 자동 색인 등에서 이 방식을 거의 사용하고 있기 때문이다. 이 코드는 사용하는 원칙이나 방법이 공식적으로 제정된 적은 없고 필요한 분야에서 각자 만들어 사용하고 있는 실정이며, 유니코드가 제정되면서 현실화되기도 한다.[그림. N바이트 코드 참조]

............................................................................................... ◀ 차 례

▶ KSC5601-1987완성형 코드

KSC5601 에서 채택한 방식을 한글을 음절 단위로 순서대로 배치하여 각각의 코드값을 부여하는 방식이다. 구현 방식을 보면 첫 번째 바이트와 두 번째 바이트 모두 164 ~ 256까지의 영역만을 사용한다. 그래서 실제로 사용 가능한 문자는 94 * 94(8836)자이므로 현대 한글 11172자를 모두 표현할 수가 없는 문제점이 발생한다. 이와 같은 문제를 피하기 위해서 많이 사용하는 한글 음절 2350자, 한자 4888자, 특수문자 1128자, 나머지 470자를 배정한다. [그림. KSC5601코드의 글자 배치]

............................................................................................... ◀ 차 례

▶ 상용 조합형 코드

한 글 한 음절을 초성, 중성, 종성으로 나누어 각각 5비트씩 배정하고 7비트 아스키코드에서 사용하지 않는 최상위 비트(MSB)에 '1'로 배정하여 2바이트로 처리한다. 첫 번째 바이트 최상위 비트가 '1'로 되어 있으면 한글 한 음절로 해석하고, '0'으로 되어 있으면 영문자로 구분한다. 그런데 조합형 코드는 회사별로 서로 다르게 제정하였으나 KS완성형 코드가 제정되면서부터 대부분의 조합형 코드는 자취를 감추게 되었고, 상용 조합형(삼보 조합형 혹은 KSSM 조합형)만이 표준 코드 제정 이후에도 계속해서 사용되었으므로 대개 조합형 코드라는 것은 이것을 가리킨다.[그림. 조합형 코드]

............................................................................................... ◀ 차 례

▶ KSC5657-1991 확장 표준 코드(필자가 편의상 지정한 이름)

KSC5601-1987 완성형 코드의 제정과 함께 불거진 코드에 대한 문제점을 보완하기 위해서 1991년에 만들어진 것으로, 한글 1930자, 한자 2856자, 옛한글 1677자 등이 추가되었다. 그런데 앞서 표준으로 제정되었던 KSC5601 완성형 코드를 부분적으로 보완하였기 때문에 현대 한글 6892자는 빠져버린다. 하지만 확장 표준 코드에서 한자가 7744자로 늘어나고 옛한글이 표준 코드에 반영되었다는 점이 중요하다. 실제로 이 코드는 전혀 사용하지 않았기 때문에 확장 코드를 기억하는 사람이 없지만 나중에 한자와 옛한글을 표준 코드에 다루는 데 중요한 단서가 된다.

............................................................................................... ◀ 차 례

▶ KSC5601-1992 조합형 코드

KSC5601-1987 완성형 코드에서는 모든 현대 한글을 표현할 수 없다는 점에서 민족 문화의 계승 발전과 산업 및 기술적 측면에서 많은 문제점을 노출시켰다. 그래서 정부는 현대 한글을 완벽하게 표현할 수 있는 조합형의 필요성을 인식하여 1992년에 이르러 또 하나의 표준 코드(KSC5601-1992)를 제정하게 되는데, 이로 인하여 표준 한글 코드가 두 개가 되어 버린다. 또한 이미 KS완성형 코드로 작성된 문서와 데이터와는 호환성이 없어서 현실적으로는 거의 사용하지 않게 된다. 이 때 제정된 조합형은 상용 조합형 코드와 구성이 거의 비슷하지만 몇 글자의 코드는 다르게 배정되어 있으며, 현재의 몇몇 응용 프로그램에서는 상용 조합형 대신에 표준 조합형 코드를 지원하고 있는 실정이다.(1987년을 기점으로 주로 사용하는 조합형을 상용 조합형 코드라고 하며, 1992년에 제정된 조합형 코드를 표준 조합형 코드라고 한다.)

............................................................................................... ◀ 차 례

■ 잘 못 끼어진 첫 단추는 이렇게 끼워졌다.

컴 퓨터에서 한글 코드 문제를 이해하기 위해서는 한글 코드에 관한 역사적인 흐름을 이해해야 하는데, 한글 코드가 실질적인 표준으로 제정되는 1987년 전후에 상황을 살펴보고, 이어서 한글 코드의 정의와 이미 사용하거나 사용했던 한글 코드의 특징을 차례대로 알아보겠다.

1974 년 처음으로 한국 공업 규격 KSC 5601-1974가 제정되었으며, 뒤이어 1977년에 KSC 5714-1977이 제정되었다. 이 때는 한글 자모 51자와 한자 7200자를 정해놓았으며 특히 자모에 의한 처리는 한계가 많았기 때문에 조합형과 완성형 코드가 등장하게 된다. 완성형 코드로 된 KSC 5619-1982와 조합형으로 된 KSC 5601-1982가 생겨났다. 여기서 중요한 점은 각각의 코드가 국가 표준으로 제정이 되었다는 뜻이지 실제로 모두가 이렇게 사용했다는 뜻은 아니다. 당시의 컴퓨터 제조 업체는 각각의 한글 코드 체계를 사용했으며 대부분의 회사들은 조합형의 장점 때문에 조합형을 사용하고 있었다. 그러한 가운데 개인용 컴퓨터가 대중화되면서 한글 코드 문제도 본격적으로 불거지기 시작했다. 예를 들어, A라는 회사에서 사용하던 한글 문서(코드)는 B라는 회사 컴퓨터에서는 사용할 수 없고, 역으로 B에서 사용하던 한글 문서(코드)는 A라는 회사에서 사용할 수 없게 되어 버린 것이다. 이와 같은 한글 코드간의 호환성이라는 문제가 대두되면서 나름대로 노력을 시도하였지만 별다른 효과가 없었다. 이 때까지만 해도 소프트웨어는 하드웨어를 팔기 위한 하나의 수단이었으므로 일단 컴퓨터를 많이 팔아서 세력을 얻는 방법이 효과적이라고 여겼기 때문에 해결이라는 것은 애당초 생각조차 하기 힘들었던 시기였다. 시간이 지날수록 불편함이 가중되었고 그만큼 사용자들의 표준화 요구도 더욱 절실해졌다. 이러한 문제를 해결하기 위해서 업체 중심으로 한글 코드 표준화를 시도하게 되었다. 처음에는 대부분 조합형 코드를 사용하고 있었으므로 완성형보다는 조합형을 지지하게 되었다. 그러나 각각 자신의 코드를 중심으로 표준화를 시도하다 보니 아무런 결말도 낼 수 없었는데, 자신의 코드를 포기할 경우 이전에 판매했던 제품과의 호환성이 문제가 될 뿐만 아니라 판매에도 중요한 영향을 미치기 때문에 사실상 다른 회사의 코드를 지지할 수가 없었다. 당시 이십여 개의 회사가 참여했으며 시간이 지날수록 조합형 코드를 포기하는 쪽으로 결론이 나면서 최종적으로 완성형을 채택하게 되었다.(앞으로는 KSC5601-1987내지는 KS완성형 코드라고 부르겠다. 이전의 완성형 코드와는 차이가 있으며 현재의 표준 코드는 조합형도 채택되어 있기 때문에 혼동할 우려가 있으므로 주의하기 바란다.) 물론 이 때 완성형을 채택하게 되는 아주 중요한 이유가 있다. 그것은 국제 표준화 기구(ISO)에서 정한 국제 규격과 호환성 때문이었다.(ISO-2022참조)

............................................................................................... ◀ 차 례

● KSC5601-1987이 보급되는 과정

우 여곡절 끝에 1987년에 완성형을 표준으로 하는 KSC5601-1987(혹은 KS완성형 코드)이 제정되었어도 상당수의 컴퓨터 및 소프트웨어 제조 회사들은 계속해서 조합형을 사용하다가 국가에서 주도한 행정 전산망 사업에서 KS완성형을 기본 코드로 채택하면서부터 점차 보급되기 시작한다. 게다가 뒤이은 교육용 컴퓨터 보급 사업에서는 행정 전산망과 호환되는 코드를 사용한다는 원칙을 제시되면서부터 본격적으로 KS완성형 코드가 보급되었다. 더욱이 개인용 컴퓨터의 운영 프로그램인 DOS를 제작하였던 마이크로소프트사가 1989년에 이르러서는 조합형을 포기하고 KS완성형을 지원하였으며, 중대형 컴퓨터의 운영 프로그램인 UNIX 진영에서도 KS완성형을 공식적으로 지원하면서 사실상 표준으로 자리잡아 가게 된다.

여 기서 짚고 넘어가 할 중요한 부분이 있다. 현재 한국은 물론 전 세계적으로 개인용 컴퓨터 운영 프로그램 판매에서 막대한 시장 점유율을 자랑하는 마이크로소프트사는 그 당시에 조합형을 사용하고 있었으며, 국가적 표준 코드(완성형) 보급 정책과 맞물려 조합형을 포기하였다는 점이다. 그러다가 1995년 윈도우95를 발매하면서 확장(통합) 완성형 코드를 제정하여 발표하는 과정에서 여론의 비판적인 화살을 맞으면서 완성형 코드가 마치 마이크로소프트사의 산물인 양 비추어졌던 점을 상기하면서 주목하기 바란다.

또 한가지 덧붙여 주목할 점은 그 당시 한글 코드 표준화에 참여하고 오늘날까지도 컴퓨터를 판매하는 회사가 KS완성형 코드를 채택하였다는 것은 만들어냈다는 뜻과는 다르다는 것이다. 말뜻 그대로 통일된 표준 코드로써 채택된 완성형 코드를 수용하는 동시에 보급하는 역할을 하게 되었던 것이고, KS완성형 코드를 제정하는 순간에는 전산 전문가와 통신 전문가들만 참여했으며, 국어학자나 출판 문화 사업에 관계된 종사자는 없었다는 점이다.

KS 완성형이 표준 코드로 보급되면서 서서히 논쟁이 불붙기 시작한다. 1989년에 이르러서는 컴퓨터 전문 잡지를 비롯하여 일간지, 컴퓨터 통신 등을 통해서 KS완성형 코드의 문제점이 제기된다. 이 때, 제기된 문제점은 여러 가지가 있지만 무엇보다도 글자를 모두 표현할 수 없다는 점이 가장 큰 문제였다. 이렇게 문제가 불거져 나오면서 KS완성형 코드를 보완하는 개정작업에 들어갔으며 그 결과 1991년 12월에 KSC5657을 제정한다. 그러나 이것마저도 충분히 검토하지 않고 제정됨으로써 사실상 보급되지 않게 된다.

............................................................................................... ◀ 차 례

■ KS완성형 코드의 문제점

KS완성형의 문제점을 설명하기 전에 먼저 한글 코드가 지녀야 하는 기본적인 원칙이 있다.

무 엇보다도 한글 특성을 반영해야 한다는 점이다. 표현 가능한 문자는 모두 처리할 수 있어야 하며, 옛한글도 현대어처럼 다룰 수 있어야 하고, 비한글 문자(한자, 영문자, 일문자, 기타 문자)도 사용하는데 문제가 없어야 한다. 그 다음으로는 기본적으로 7비트 아스키코드로 동작하는 영문 자료와 제어 문자들과는 충돌하지 말아야 하고, 보다 중요한 정보 처리를 위해서는 음절을 넘어서 자소 단위로 처리할 수 있어야 한다. 끝으로 국제적인 표준 규격을 따라야 하며, 산업 현장에서 현실적으로 수용할 수 있어야 하며, 정부의 정책적인 지원이 있어야 한다.

이러한 기본적인 원칙을 중심으로 KS완성형을 살펴 보면 다음과 같은 문제점이 발생한다.

가 장 중요한 것은 표현 가능한 현대 한글을 모두 표현할 수 없었으므로 한글 특성을 살리지 못 한다는 점이다. KS완성형 코드는 현대 한글 11172자 중에서 2350자만을 처리할 수 있기 때문에 문제가 발생한다. 간단히 예를 들자면, "최시콜라, 최시맨, 馱방각하, 뾼차, 뉵다리"등을 표현할 수 없다. 또한 '쓩'이라는 자는 KS완성형 코드에는 있지만 '덁'라는 자가 없어서 입력할 수 없는 경우가 6자나 발견되었다. 이것은 KS완성형 코드를 표준으로 제정하는 과정에서 실제로 사용할 수 있는가에 대한 타당성을 검토하지 않은 결과였으므로 당시에는 대단한 비웃음거리가 되었다. 이것말고도 자소 정보를 추출할 수 없었으므로 한국어에 대힌 언어적인 정보를 처리하기 위해서는 조합형을 거치게 하는 결과를 낳았다. (조합형 코드를 거쳐야만 자소 단위의 정보를 처리하기 쉽기 때문이다.)

............................................................................................... ◀ 차 례

■ 확장 완성형 코드

이 것은 마이크로소프트사가 독자적으로 제정하여 사용하는 것으로 윈도우95와 함께 널리 사용되게 된다. 기본적으로는 KS완성형 코드을 그대로 사용하고 KS완성형 코드에서 표현할 수 없었던 한글 8822자를 KS완성형 코드에서 사용하지 않는 영역에 추가로 배정한 방식이다. 이 방식을 사용함으로써 조합형과의 논쟁에서 골칫거리였던 나머지 한글을 모두 표현하게 되었다는 점이 매우 중요하다. 그럼 마이크로소프트사의 당시에 발표한 내용을 보면 다음과 같다.[그림. 확장 완성형 코드 영역]

" 마이크로소프트사는 1992년 조합형 발표 이후 모든 한글을 포함하는 조합형(KSC5601-1992)을 지원하기 위해서 내부적으로 많은 노력을 해왔으나, 기존의 대부분 완성형만을 지원하는 프로그램과 자료 데이터와의 심각한 호환성 문제가 항상 걸림돌로 되어 왔다. 이에 마이크로소프트사는 기존의 프로그램 및 데이터와의 호환성을 유지하면서 모든 한글을 지원하는 데 가장 바람직한 방법은 완성형(KSC5601-1987) 코드를 그대로 두고, 나머지 한글을 남아 있는 DBCS(Double Byte Character Set) 영역으로 확장하는 방법으로 확장 완성형 코드를 개발하였다."

............................................................................................... ◀ 차 례

● 확장 완성형 코드가 지닌 한계와 문제점

확 장 완성형 코드가 지닌 한계를 알기 전에 이것을 제정하게 되는 이유와 원칙을 알아 보아야 한다. 그래야만 한계와 문제점을 쉽게 이해할 수 있기 때문이다. 확장 완성형을 제정하게 되는 가장 중요한 이유는 KS완성형 코드에서 처리할 수 없었던 현대어 8822자를 처리하기 위한 것이고, 제정 원칙은 기존의 완성형만을 지원하는 프로그램 및 데이터와의 호환성을 유지한다는 것이다. 여기서 확장 완성형이 비판을 받게 되는 이유는 호환성을 위해서 한글 순서(사전 순서)를 무시한 코드 배정에 있었다. [그림. 확장 완성형 코드 영역 참조]

즉, 기존의 KS완성형 2350자는 '가나다'순으로 배열되어 있으나, 나머지 글자들이 그 위(앞)에 배치됨으로써 전체 코드 내에서 한글의 순서가 뒤죽박죽 엉키게 되며, 정렬(sorting)이나 탐색(search)을 할 때 심각한 영향을 미치기 때문이다. 물론 이러한 문제는 개발자가 조합형으로 변환하여 사용하면 간단하게 해결할 수도 있다.

그 런데 더욱 논란이 되었던 것은 확장 완성형 코드 자체보다는 확장 완성형 코드를 발표하는 과정과 그것이 미칠 영향력 때문이었다. 확장 완성형 코드는 어느 한 기업의 제품일 수도 있지만 국내 산업 현실을 고려해보면 사실상 표준 코드로써 막대한 영향력을 미칠 수도 있는 상황이었으므로 예상 밖의 커다란 논란이 되었다. (여기서는 당시의 논쟁을 언급하지 않겠다. 독자들 중에서는 논쟁에 대하여 궁금하게 생각하는 독자도 있겠지만 이 글의 목적은 논쟁을 재현시키는 것이 아니라 지나온 과정을 살펴보고 발전적인 방향을 검토하는 것이므로 관심있는 독자들은 참고 자료를 보기 바란다.)

............................................................................................... ◀ 차 례

● 확장 완성형으로 한글을 표현하는 데 문제가 있는가?

먼 저 결론부터 말하자면 확장 완성형 코드로 한글을 어느 정도는 처리할 수 있다. 좀더 구체적으로 말해서, 미완성 음절 문자 1147자(예: 葶, 蓶, 끁)를 처리할 수 없다는 점을 빼고는 조합형만큼 처리를 잘 할 수 있다. 그러나 제대로 처리하기 위해서는 경우에 따라서 조합형으로 변환해야 하기 때문에 그에 따른 컴퓨터의 연산 속도에 영향을 미치며 이것이 전체적으로는 비효율적이라고 비판하는 사람이 적지 않다. 그런데 필자의 개인적인 생각으로는 이 정도의 연산 속도가 문제가 될 정도라면 컴퓨터는 아예 사용하기도 힘들 정도이다. 오히려 전체적인 작업에 비하면 조합형 변환에 따른 연산 속도는 거의 영향을 미치지 않는다고 보아야 할 듯하다. 전체적인 작업 시간과 비교하였을 때 문서처리기, 정보 검색, 맞춤법 검사, 으뜸꼴 인식, 기타 다른 작업에서 조합형으로 변환하는 시간은 거의 영향을 미치지 않는다고 말할 수 있을 정도이며, 실제로 조합형 코드도 한국어 정보 처리를 위해서는 자소형 코드로 변환을 거치기 때문에 똑같이 연산 속도에 영향을 미친다는 것을 생각하면 확장 완성형 코드를 가지고 정렬과 탐색에서 조합형 코드로 변환하는 시간을 문제 삼기에는 다소 이해하기 어려운 부분이다. 그러나 다른 한편으로는 정보 검색, 자동 색인, 으뜸꼴 인식, 맞춤법 검사기에서는 조합형 코드를 그대로 사용할 수가 없어서 자소형으로 변환하여 사용하고 있다는 점을 생각해보면 확장 완성형은 두 번의 변환 과정을 거쳐야 하기 때문에 그만큼 비효율적인 것은 사실이다. 어쨌든 확장 완성형으로 현대어를 입력하고 출력하는 데는 문제가 없으며, 사전식 순서를 원할 경우에는 조합형으로 변환시켜 사용하면 별다른 문제가 되지 않는다.

............................................................................................... ◀ 차 례

● 사실상 표준으로 영향력을 미치게 될 확장완성형

필 자의 개인적인 생각으로는 확장 완성형이 원래 의도하지 않았던 문제가 발생하고 있다. 이 글을 시작할 때 소개하였던 "뾼차를 타고 온 최시맨과 뉵다리 馱방각하"를 인터넷에서 찾으려면 심각한 문제가 발생한다. 앞서 지적했듯이 거의 모든 정보 검색 시스템이나 인터넷 관련 프로그램은 이것을 제대로 처리하지 못하고 있다. 심지어는 정보 검색 시스템에서 장애가 발생하였다거나 아예 글자를 엉뚱하게 바꾸어서 처리하는 경우도 있으며, 인터넷 관련 프로그램에서는 이상한 박스 문자로 나오거나 비어 있는 경우가 발생한다. 이것은 대부분의 프로그램이 기본 완성형(KS완성형) 코드만을 고려하여 개발되었기 때문에 기본 완성형 코드에 없는 확장 완성형 한글 문자를 처리하면서 문제가 발생하는 것으로 해결 방법은 크게 두 가지이다. 하나는 기본 완성형 한글 문자만 처리하고 확장 완성형 한글은 막아 버리는 것이고, 또 다른 하나는 확장 완성형 한글 문자를 추가로 처리하여 문제를 해결하는 것이다. 첫 번째의 경우는 코드 변환 부분에서 막는 것으로 해결하기 때문에 간단하며, 두 번째의 경우도 확장 완성형 한글 문자 영역에서 한글 문자를 추가로 다루면 별다른 문제 없이 해결할 수 있다. 바로 이 점이 우리가 주목해야 하는 부분이다. 별다른 어려움 없이 확장 완성형 한글 문자를 처리할 수 있으므로 새로운 표준 코드가 정착되기 전까지 대부분의 정보 검색 시스템에서는 확장 완성형 코드를 지원할 가능성이 있다.

............................................................................................... ◀ 차 례

■ 유니코드에서 한글 코드 배정

유니코드는 매우 중요한 의미를 지니고 있기 때문에 유니코드의 출현 배경을 알아 보고, 유니코드에서의 한글 코드 변천과 유니코드에서 한글 코드의 특징을 살펴 보자.

유니코드는 국제 표준화 기구는 아니며 컴퓨터 관련 업계를 중심으로, 다국어 언어를 효율적으로 처리에 필요한 코드 체계를 제정하기 위해서 1989년에 콘소시엄 형태로 설립된 회사이다.

1991 년 말에 유니코드 1.0을 발표하였는데, 여기서 한글 코드는 KSC5601-1987완성형 코드만을 포함시켰기 때문에 국내에서는 환영을 받지 못했다. 그래서 뒤이은 유니코드1.1. 개정에서는 조합형 코드를 수용해줄 것을 강력하게 요청하였지만 부분적으로만 수용하는 바람에 실제로는 전혀 사용할 수조차 없는 얼치기 한글 코드가 배정되었다. 당시에 한글 코드를 조합형으로 배정받지 못 했던 중요한 이유는 한글 조합형 코드가 다른 나라에 비하여 너무 많은 영역을 요구하였기에 심하게 반발하였던 것이다. 한편으로는 조합형 코드를 조합 방식 그대로 적용하면 대략 3만 자가 넘기 때문에 수용하기 어려운 면이 있었으며, 조합 규칙을 간소화하여 적용하여도 최소한 11172자를 사용해야 했으므로 당시로는 국제 사회에서 받아들이기 어려웠다. 이 때까지만 해도 전세계적으로 유니코드는 현실적으로 사용하지 않았기 때문에 1995년에 이르러 유니코드2.0을 제정하게 된다. 유니코드2.0에서는 한글은 두 가지 영역으로 배정받았다. 첫 번째는 현대 한글 11172자를 완성형 방식의 코드순으로 배열한 것인데, 현대 한글 11172자는 완성형처럼 완성된 음절을 기준으로 배정하였기 때문에 완성형 방식 코드라고 부르며(이 글에서는 앞으로 혼동되지 않도록 유니완성형으로 사용) KSC5601완성형 코드와는 다르게 일정한 조합 규칙을 유지하고 있어서 사용하기 편리하다. 두 번째는 초성, 중성, 종성을 자소 단위로 배정한 조합형 방식 코드로(유니코드에서는 한글자모[Hangul Jamo]라고 하지만, 이글에서는 앞으로 혼동되지 않도록 유니조합형으로 사용) 2바이트 상용 조합형이나 KSC5601-1992 표준 조합형처럼 고정된 길이가 아니라 자소 개수만큼 사용하는 N바이트 형식으로 지정하였다. 현재에는 유니코드 2.1이 최종 버전으로 발표되었으며, 국내에서는 유니코드 2.0이 발표되자마자 KSC5700이라는 이름으로 유니코드 2.0을 국가 표준 코드로 채택하게 된다.(유니코드 2.0과 KSC5700은 사실상 같으므로 같은 의미로 사용한다.)

............................................................................................... ◀ 차 례

● 유니코드 일반적인 구조와 한글 처리 원리

유 니코드에서 한글 처리 원리를 알기 전에 일반적인 원리와 알아볼 필요가 있다. 유니코드는 기존의 아스키 코드, KS완성형, 조합형(상용, 표준)형과는 근본적으로 다른 코드이다. 단지 물리적으로 코드를 배정했다는 차원에서는 비슷하지만 언어학, 디자인, 공학, 서체 등등 제반 학문적인 원리를 바탕으로 코드를 배정하였기 때문에 이러한 원리를 이해해야만 한글 처리 원리를 이해할 수 있다. 유니코드에서 사용한 원리는 매우 많고 다양하지만 이해를 돕기 위해서 필요한 요소를 중심으로 설명하므로 자세한 것은 참고 자료을 이용하기 바란다.

먼저 디자인 원리에서 16비트 크기, 의미론, 논리적 순서, 단일화, 동등 연속 등이 적용되었다.

- 16비트 크기라는 것은 말뜻 그대로 한 문자를 표현하기 위해서 16비트(2바이트) 크기로 사용한다.

- 의미적인 지식을 요구하는 파싱(parsing), 정렬, 기타 알고리즘에서 사용하는 의미론적 지식 수용한다.

- 글쓰기 방향과 관계된 논리적 순서는 왼쪽에서 오른쪽, 오른쪽에서 왼쪽으로, 위쪽에서 아래쪽으로 사용할 때 별도의 해석정보를 줄 수 있다.

- 단 일화는 같은 문자를 한 번만 지정하는 원리로 한국·중국·일본·대만 등에서 주로 사용하는 한자는 형태는 같을지라도 음이 다르거나 각각 처리하는 방식이 다르기 때문에 통일시키는 것이다. 그런데 이것은 한국은 물론 다른 국가에서도 문제가 되는 부분으로 KS완성형 코드 제정에서는 논란이 되었던 '樂'자의 경우 한국어에서 한글 음절로 표현할 때는 '락', '악', '요'로 되기 때문에 이것을 구별하려면 별도의 원리를 만들어야 한다.

- 동 등 연속(Equavalent Sequence)은 유니완성형 '각(0xac01)'자는 유니조합형으로 풀어쓴 'ㄱ(0x1100)' + 'ㅏ(0x1161)' + 'ㄱ(0x11a8)'과 같게 해석할 수 있다는 것인데, 이것으로 인하여 유니조합형으로 풀어쓴 것은 유니완성형과 섞여 있을 경우에 별도의 작업을 통하여 정렬이나 탐색에서 수행해야 한다.

코 드 배정은 크게 8영역으로 나누어졌는데, {일반 스크립 영역, 심볼 영역, CJK 음성 및 심볼 영역, CJK 한자 영역, 한글 유니완성형 영역, 대용 영역, 사적인 사용 영역, 호환 및 특별 영역}이며, 이 중에서 한글과 직접 관련된 것은 유니조합형 자모를 처리하는 [일반 스크립 영역], 한자를 처리하는 [CJK 한자 영역], 한글 완성된 글자를 처리하는 [한글 유니완성형 영역] 등이다.

유 니코드에서 눈에 띄는 특수 문자는 바이트 순서 문자(Byte Order Mark)가 있다. 바이트 순서 문자는 하드웨어마다 기록하는 방식이 다르기 때문에 발생하는 문제를 해결하기 위해서 사용하는 것이다. 예를 들어, 인텔용으로 저장한 비문자형 (int, long) 변수는 Sun, Hp에서는 바이트가 바뀌어 저장되므로 각각 해석을 다르게 해야 한다. 이러한 문제를 해결하기 위해서 바이트 순서 문자로 "0xfe, 0xff"를 연속적으로 맨 앞에 붙여서 기록한다. 이렇게 기록된 것은 인텔에서는 "0xff, 0xfe"로 읽히기 때문에 다음에 오는 모든 유니코드는 바이트 순서를 바꾸어서 해석하게 된다.

[예. 바이트 순서 해석 방법]

0xff, 0xfe -> 인텔용

0xfe, 0xff -> Sun, Hp

다 음으로는 한글 처리 원리를 알아보겠다. 유니코드에서는 한글을 완성형(유니완성형)과 조합형(유니조합형) 두 가지 모두 처리할 수 있도록 되어 있는데, 현대 한글 11172자는 완성형처럼 미리 조합했다는 뜻으로 완성형(유니완성형)이라고 하고 초성 90자, 중성 66자, 종성 82자, 채움 2자 등 모두 240자의 자모로 조합할 수 있도록 했기 때문에 조합형(유니조합형)이라고 부른다.

유 니완성형 코드는 KSC5601완성형 코드와는 다르게 일정한 조합 원리를 갖고 있어서 사용하기 편리하므로 쉽게 자소 정보를 뽑을 수가 있다. 그래서 유니완성형 코드는 유니조합형 코드로 변환이 가능하며, 역으로 유니조합형은 유니완성형으로 변환이 가능하다. 이 때, 유니완성형을 유니조합형으로 풀어 쓴 것을 해체한 코드라고 부르며, 역으로 유니조합형을 유니완성형으로 변환하여 쓴 것은 합성한(조합한 의미가 정확하지만 조합형이라는 말과 구분하기 위해서) 코드라고도 부른다. 유니조합형 코드는 초성, 중성, 종성 글자를 풀어서 사용하는 것으로 기존의 상용 조합형 코드에서 조합하는 원리와 똑같다. 단지 차이가 있다면 상용 조합형은 초성, 중성, 종성 각각 5비트씩 사용해서 2바이트를 유지하는 반면에, 글자 수만큼 크기를 2바이트씩 차지하므로 길이가 가변적이라는 것이다. 그런데 여기서 매우 중요한 점이 있다. 유니완성형 코드와 유니조합형 코드는 동일한 코드로 처리할 수 있다는 것이다. 즉, 유니완성형 '각(0xac01)'자는 유니조합형으로 해체한 'ㄱ(0x1100)' + 'ㅏ(0x1161)' + 'ㄱ(0x11a8)'자와 똑같은 글자로 처리해야 한다는 뜻이다. 이렇게 현대어 한글 한 글자를 표현하는데 두 가지로 표현하게 되므로 문제가 발생한다. 같은 글자를 두 가지로 표현하다 보니까 정렬이나 탐색에서는 별도의 조작을 수행해야만 가능하며, 옛한글이랑 섞여 있는 경우에는 더욱 복잡한 조작을 수행해야 하는 부담이 따른다. 만약에 유니코드 상태에서 유니조합형 코드와 유니완성형 코드를 섞어서 일반적인 정렬 프로그램을 사용하면 한글 순서가 뒤죽박죽 뒤엉키게 된다. 이와 비슷한 다른 예로써 'ㅘ'라는 글자도 'ㅗ' + 'ㅏ'로 해체하여 사용할 수 있으므로 더욱 복잡한 연산을 수행해야 한다. 그러면 왜 유니조합형과 유니완성형 두 코드를 동시에 수용했는지 궁금하지 않을 수 없다. 그 이유를 필자가 개인적으로 생각해보면 처리의 효율성을 높이기 위해서 결정한 듯하다. 현대어만을 다루기 위해서는 유니완성형만을 가지고도 충분하지만 현대어가 아닌 옛한글을 모두 처리하려면 이론적으로 대략 50만자가 된다. 이렇게 많은 자를 16비트 체계에서 처리한다는 것은 거의 불가능하므로 현대어처럼 유니완성형 형태로 유지하지 않고 자소별로 풀어서 240자를 배정한 것이다. 간단히 말해서 옛한글을 처리할 때와 미완성 음절 문자는 어쩔 수 없이 유니조합형을 사용해야 한다는 뜻이다.

............................................................................................... ◀ 차 례

● 유니코드에서 한자는 어떻게 되었는가

유 니코드에서 한자는 앞서 말한 대로 한국·중국·일본·대만 등에서 주로 사용하기 때문에 각 국가별로 사용되는 한자를 부수와 획수에 맞추어 배열하였다. 그런데 이러한 문자 중에서는 각국에서만 독특하게 사용하는 경우가 있으며, 어떤 문자는 두 가지 이상을 표현하는 경우도 있고, 한국에서는 사용하지 않고 중국이나 일본에서 사용하는 문자에 대하여 한글 음절을 부여하는 문제도 발생한다. 이러한 문제는 유니코드에서 확실하게 해결하지 못 하였기 때문에 한자를 사용하는 국가끼리 협의하도록 되어 있다. 또한 국내에서는 한자에 대한 한글 음절 순으로 정렬하는 테이블 갖고 있어야 하며, 하나의 글자로 되어 있는 '樂'자와 같은 경우에 한글 음으로 변환할 때는 각각 '락', '악', '요'자로 해석해야 하는 문제가 있다.

더욱이 유니코드에서 제정한 한자는 CJK영역에 20,902자를 배정하였지만 국제 한자 특별 위원회에 제안된 한자는 27486자가 있기 때문에 현실적으로 유니코드에서 제정한 한자는 표준으로 받아들이기에는 어려운 문제가 있다.

............................................................................................... ◀ 차 례

● 유니코드는 한글 및 한국어를 완벽하게 처리할 수 있는가

결 론부터 말하자면 완벽하게 처리하지는 못 한다. 현대어 처리에서는 KS완성형보다는 나을 지도 모르지만 조합형 코드보다 못한 부분이 있으며, 옛한글 처리에서도 중요한 문제가 있다. 옛한글이라고 하는 것은 크게 두 가지로 구분하는데 훈민정음 창제 이후에 사용되었으나 현재에는 사용하지 않는 한글을 말하고, 또 하나는 구결이라고 하는 것이 있는데 옛날에 한자(한문)를 우리말로 읽을 때 한문의 낱말 또는 구절 사이에 들어가는 것을 구결이라고 한다. (이 글에서는 옛한글과 구결을 구분한다.)

먼 저 유니완성형 영역에서 처리하는 현대어 음절 11172자에 문제가 있다. 즉, 현대어 음절은 11172자가 아니라 정확하게 12319자이다. 이렇게 차이가 나는 것은 미완성 음절 문자 1147자가 있기 때문이다. 이것은 과거 KS완성형과 대립하는 과정에서 조합형에서 사용하는 완성된 음절을 이루는 글자가 11172자로 보았기 때문에 차이가 발생했다. 미완성 음절 문자는 초성:채움:채움(衁), 채움:중성:채움(葡), 채움:채움:종성(葖), 채움:중성:종성(葶), 초성:채움:종성 등의 글자 형태이다. 이러한 글자들이 현대어에서 빠지게 되면서 옛한글처럼 유니조합형에서만 처리할 수 있도록 배정되는데, 이것으로 인하여 앞으로(1995년 3월 이후) 개발될 운영체제에서는 현대어를 11172자만을 처리하게끔 유도한다. 이렇게 된 근본적인 원인을 살펴보면, 유니코드 2.0이 제정되기 전까지 KS완성형과의 논쟁에 집착한 나머지 조합형에서 현대어 음절이 정확하게 몇 자인지 모르고 있었기 때문이다. 실로 어처구니없는 일이지만 이미 "엎질러진 물"처럼, 엄연한 현대어이면서 옛한글을 처리하기 위해서 만들어 놓은 유니조합형 영역에서 함께 처리되는 결과를 낳는다. 게다가 이러한 잘못된 판단으로 유니조합형에서는 현대어 자모와 옛한글 자모가 뒤엉키게 되어 정렬이나 탐색에서 심각한 문제를 불러일으킨다.[그림. 유니조합형 코드를 보면 순서 뒤죽박죽이다.]

다 음으로 옛한글을 살펴보자. 옛한글을 표현하기 위해서는 유니조합형 자모 코드 240자(초성 90자, 중성 66자, 종성 82자, 채움 2자)를 사용하면 이론적으로 약 50만 자의 음절을 표현할 수 있다. 그런데, 유니조합형 240자만으로는 옛한글을 충분히 표현할 수 없으며, 실제로는 104자(초성 124자, 중성 84자, 종성 133자)가 더 추가된 344자가 있어야지만 완벽하게 처리할 수 있다. 이러한 옛한글 자모를 조합하면 대략 139만 자를 표현할 수 있지만 실제로 문헌에 나타난 옛한글 음절은 대략 5,000자 정도밖에 안 된다는 점에 주의하기 바란다. 잠시 화제를 바꾸어서, 유니조합형(유니코드2.0)에서 104자의 자모 코드가 빠지게 되는 과정을 알아보자. 초창기 유니코드 1.x을 제정하던 시기에 한국에서는 유니코드에 대한 준비가 거의 없었으며, 게다가 그 당시에 국내에서는 표준 코드였던 KS완성형 코드를 조합형 코드로 개정하려는 데 관심이 많았던 때였다. 그러므로 옛한글 음절이나 자모에 대한 연구는 상당히 초보적인 수준이었는데 그 때까지 연구되어 발견된 자모가 대략 200자 정도였다. 이러한 상황에서 유니코드1.x가 제정되었는데, 이 때 조합형 코드로 채택된 자모 코드는 240자였다. 그런데 유니코드 1.x이 채택되자마자 옛한글 음절이나 자모를 본격적으로 연구하는 과정에서 새로운 음절과 자모를 발견하게 된다. 하지만 유니코드2.0에서는 새로 발견된 옛한글 자모를 수용하지 않았고 유니코드 1.0에서 채택된 내용만을 수용하면서 앞에서 지적한 104자의 자모가 빠지게 되었다. 여기서 한 가지 주의할 점이 있다. 유니코드 2.0이 제정된 이후에도 계속해서 옛한글 자모가 계속해서 발견되고 있으므로 유니코드 입장에서는 새로운 옛한글을 무조건 수용할 수 없었던 점도 이해해야 한다. 다시 말해서 국제 표준화 작업에 대한 충분한 대비를 하지 않고 있다가 "소 잃고 외양간 고치는 격"으로 뒤늦은 연구 작업을 하였기 때문에 우리의 잘못이 크다고 볼 수 있다. 또 다른 한 편으로는 짚고 넘어가야 할 중요한 점이 있다. 여러 가지 사정으로 인하여 유니코드1.x에서는 순서가 뒤엉킨 자모 배열를 유지하였지만 유니코드2.0에서도 이것을 고치지 않고 그대로 수용한 점은 이해하기 어려운 부분이다. 결국, 한국어에서 자모 배열을 무시한 코드가 또 다시 등장한 셈이다.

끝 으로 구결의 경우를 살펴보자. 현재 발견된 구결 문자는 276자 정도로 보고 있으며, 한자에서 모양을 빌려왔기 때문에 언뜻 보아서는 다른 문자(한자, 그림 문자, 기호 문자)를 변형시키면 어느 정도 출력은 가능하다. 그래서 구결에 관계하지 않는 사람 입장에서는 이런 정도는 빠져도 괜찮지 않을까 하는 생각을 가질 것이며, 적은 수의 국어학자들이 알아서 적당히 해결해야 하는 상황이 되었다.

앞 서 살펴본 것처럼 유니코드는 한글을 완벽하게 처리할 수 없지만, 과거 KS완성형이 지녔던 문제와 비교해보면 거의 무시할 수 있을 정도이다. 하지만 필자의 개인적인 생각으로 옛한글과 구결 문자는 빠지지 않았으면 한다. 우리가 과거 조합형을 포기하고 KS완성형을 채택한 후에 얼마나 많은 사람이 고통을 받았는지를 생각해 보면 앞으로 어떻게 해야 하는지를 알 수 있을 것이다. 문화 유산이라는 것은 한 번 포기하고 버리기는 쉬어도 되살려 복원하는 데에는 너무나 어렵고 힘든 일이기 때문이다. 지금은 옛한글과 구결이라는 것이 몇몇 학자들만의 문제이지만 먼 훗날 코드가 없기 때문에 사라져 버린다면 너무나 애석한 일이므로, 비록 옛한글과는 관계가 없더라도 많은 독자들이 관심이 가졌으면 한다.

............................................................................................... ◀ 차 례

■ 한글 윈도우98과 문서처리기에서 한글 코드 및 한글 처리

컴 퓨터에서 가장 중요한 것은 운영체제이고, 널리 사용되는 한글 윈도우 98에서는 KSC 5700 표준 한글 코드(유니코드)를 지원함으로써 현대어 한글 11,172자를 모두 표현할 수 있다. 여기서 주의할 점은 현대어 중에서도 미리 조합된 유니완성형만을 표현할 수 있다는 점이며, 또한 기존의 KS완성형과는 다르게 초성, 중성, 종성 자소 정보를 해석할 수 있다는 점이 커다란 차이점이다. 다시 말해서 한글 조합 원리를 반영한다는 뜻으로 유니완성형으로는 한국어 정보 처리에서 중요한 형태소 분석을 할 수 있다는 점이 중요하다. 그러나 현대어 한글 음절은 11172자가 아니라는 점에 유의해야 한다. 정확하게 말하자면 현대어 한글은 12391자이기 때문에, 윈도우98에서는 현대어 미완성 음절 문자 1147자와 옛한글을 표현할 수 있는 유니조합형은 처리할 수 없다.

그 럼 윈도우98에서 실질적인 조합형(유니조합형)을 지원하기 어려운 이유는 무엇일까 궁금하다. 아마도 필자의 개인적인 생각으로는 240자모를 조합할 경우에 50만자에 가까운 음절이 필요하므로 현실적으로는 모두 처리하기 어렵다. 또 한편으로는 유니완성형과 호환성을 유지하도록 되어 있는 유니조합형 글자를 사용하면 정렬이나 탐색에서 추가 작업을 해야 하는 어려움이 있으며, 데이터 용량도 2~3배 정도 늘어나는 문제가 있다. 그래서 현재 수용 가능한 11172자를 미리 조합된 유니완성형 형태로 지원하는 듯하다. 그리고 유니완성형만으로도 과거 상용조합형 코드가 자랑처럼 여기던 현대어를 모두 포함하는 동시에 초성, 중성, 종성 음소 단위의 정보를 제공할 수 있기 때문에 커다란 문제가 없기 때문인 듯하다. 그런데 필자가 여기서 관심을 두는 것은 현대어 중에서 미완성 음절 1147[초성(19) + 중성(21) + 종성(27) + (중성(21) ⁓ 종성(27)) + (초성(19) ⁓ 종성(27))]자이다. 이 글자들은 일반인은 사용하지 않고 국어 내지는 국어와 관계된 출판업에 종사하는 사람만 사용한다고도 볼 수 있다. 그러나 실제로는 일반인에게도 중요할 수도 있다. 한국어는 영어와 달라서 자료에서 음소 단위로 정보를 처리하고 싶을 때가 드물지 않게 발생한다. 예를 들어, 자료에서 종성 '葉뿐이다'를 '葉 따름이다'로 바꾸고 싶을 때 입·출력이 안 된다면 곤란한 것은 자명하다. 물론 이보다 더욱 중요한 사람들이 있다. 바로 한글 및 한국어 정보처리를 담당하는 사람들이다. 이들이 주로 하는 일들은 한국어를 형태소 분석하여 자동색인 시스템, 맞춤법 검사기, 정보검색 시스템, 기계번역 시스템 등등에서 미완성 음절 문자 1147자를 사용하기 때문이다. 미완성 음절 문자 1147자는 단순히 입력과 출력만 하는 것이 아니다. 화제를 잠시 바꾸자면, 현재 산업 현장과 학계에서는 KS완성형 코드가 표준이던 시절부터 한글 및 한국어 정보처리를 위해서 정보를 충분히 표현할 수 있는 조합형 코드 내지는 자소코드를 각자 만들어 사용해 왔으며, 그것을 가지고 만든 형태소 전자사전을 기반으로 자동색인, 정보검색, 맞춤법 검사, 기계번역 등등에서 활용하고 있다. 그런데 이렇게 각각 다른 조합형 코드나 자소코드를 가지고 형태소 전자사전을 비롯하여 정보 데이터베이스를 개발함으로써 범국가적인 정보 데이터베이스 사업을 추진하는 과정에서도 코드에 대한 호환성과 표준화 문제가 발생하므로 상당한 지연과 불편함을 초래해 왔다. 전자사전에서 사용하는 데이터는 코드상의 문제로 인하여 내부적으로 정의해서 사용해 온 것이므로 정상적인 방법으로는 입·출력을 할 수 없어서 항상 변환과정을 거쳐야 하는 문제, 제작하는 사람마다 사용했던 코드값이 달랐기 때문에 실질적인 표준코드를 정해야 하는 문제, 설령 정상적인 표준코드(유니조합형)로 개발되었어도 미완성 음절 문자는 입·출력이 불가능한 문제 등등이 발생한다. 그러한 상황에서 실 질적인 표준으로 사용할 수 있는 코드를 지원하는 운영쳬제가 보급된다면 아마도 그것을 가지고 정보처리용 자소코드에 대한 표준화가 급속하게 진전될 것이며, 그것이 범국가적인 정보 구축 사업에서는 비약적인 발전을 가져올 것이다. 필자가 미완성 음절 문자 1147자를 진정으로 중요하게 생각하는 이유가 바로 여기에 있다. 다시 윈도우98로 돌아가서, 유니조합형 코드는 이론적으로 50만 자까지 조합이 가능하므로 현실적으로는 당장 수용하기 어렵다. 이로 인하게 함께 처리되지 못하는 미완성 음절 문자 1147자는 기술적으로도 시간적으로도 그다지 어려운 일이 아니었음에도 유니코드2.0에서 현대어 음절을 잘 못 배정하였기 때문에 1147자가 빠져 버렸다는 점은 필자를 비롯하여 한국어 정보처리와 관계된 종사자들에게 아쉬움을 남기는 부분이다. 한글 윈도우98의 입장을 심정적으로는 이해할지라도 윈도우 프로그램의 업그레이드 주기를 생각해 보면 빠져 있는 조합형(유니조합형) 코드가 하루라도 빨리 지원되었으면 하는 바램을 남겨 두고 다음으로 한자의 사정을 알아보자.

윈 도우98에서 한자를 살펴보면, 유니코드에서 제정한 한자는 CJK영역에 20,902자를 배정하였다. 그러므로 유니코드를 지원하는 윈도우98에서도 약 20000자의 한자를 지원한다고 생각할 수도 있지만, 실제로는 7744자만을 지원한다. 이것 역시 나름대로 이유가 있다. 유니코드에서 제정한 한자는 한국, 중국, 일본, 대만 등 한자를 사용하는 국가의 것을 배정한 것으로, 이 중에는 우리 나라에서 사용하지 않는 한자도 있으며, 다른 한 편으로는 국제 한자 특별 위원회에 제안된 한자는 27486자가 있기 때문에 현실적으로 유니코드에서 제정한 한자는 표준으로 받아들이기에는 어려운 문제가 있다. 이와 같이 현실적으로 사용하기 어려운 상황에서 한자를 처리하기 위해서는 기존의 표준코드(KSC5601-1987 완성형[4888자]과 KSC5657-1991 확장 표준 코드[2856자])에서 사용했던 7744자를 현실적으로 수용하는 범위내에서 유니코드와 호환성이 유지되는 한자를 처리할 수밖에 없다. 아마도 이러한 이유 때문에 윈도우98에서는 7744자의 한자를 지원하는 듯하다.

앞 에서 검토한 한자와 옛한글에 대한 보완책으로 유니코드를 지원하는 응용 프로그램을 생각해 볼 수 있을 것이다. 현재 응용 프로그램 중에 가장 널리 사용되는 문서처리기에서는 유니코드를 완벽하게 지원하는 프로그램은 없으며 단순하게 현대어 한글 유니완성형 11,172자만을 지원한다. 그래서 옛한글과 미완성 음절 문자 1147자는 유니코드를 사용하지 않고 내부적으로만 조합형 코드를 이용하여 부분적으로 지원하고 있는 문서처리기가 있다. 이 부분에서 주목할 필요가 있다. 과거에는 KS완성형이 표준이었기 때문에 상대적으로 조합형 방식을 채택한 문서처리기들은 완벽한 한글 처리 능력을 자랑해 왔다. 그러면 과연 완벽한 한글 처리에 대하여 다시 한번 검토해 보자. 과거에는 현대어 음절을 충분히 표현할 수 있느냐의 문제에 초점을 맞추었으나 이제는 상황이 달라졌다. 이제 현대어는 시스템 차원에서 충분히 처리할 수 있으므로 옛한글 처리가 중요한 문제로 부각되고 있다. 국어학자 입장에서 옛한글이라고 말할 때는 한글 형태와 그렇지 않은 구결도 포함하지만 일반인이 현실적으로 이해할 수 있는 한글 형태만을 가지고 검토해 보겠다. 현재 옛한글을 처리할 수 있는 프로그램은 각각 내부적으로 특수 처리 방법을 사용하고 있으므로 여기서 사용하는 옛한글은 입·출력만 가능하다. 그래서 데이터로서는 접근할 수 없는 죽어 있는 정보에 가깝다. 좀더 이해하기 쉽게 말하자면 화면과 종이에서만 사용할 수 있고, 데이터베이스와 같은 정보 구축이나 정보검색에서는 현실적으로 사용하지 못하고 있다. 물론 이에 대한 주원인은 표준적인 코드가 아니기 때문이겠지만 이들 문서처리기에서 사용하는 데이터를 다른 분야에서 사용할 수 있도록 공개적이지 못한 점도 검토해보자. 돌이켜 보면, 과거 KS완성형 코드가 표준이었을 때도 상용조합형은 표준 코드가 아니었음에도 불구하고 데이터 형식이나 기타 정보를 공개적으로 사용했었다. 이와 마찬가지로 생각해보면 옛한글과 문서처리기에서 사용하는 한글에 관련된 다른 정보(확장 한자, 구결)에 대하여 공개적이지 못한 태도는 배려의 문제라고 볼 수 있다. 여기서 공개적이라는 말은 개발에 관련된 특수한 비법이나 회사에 치명적인 손상을 입힐 만한 정보를 말하는 것이 아니다. 이들 프로그램에서 사용하는 데이터를 보다 쉽게 개방적으로 접근할 수 있게끔 하는 공개적인 태도를 말한다. 비록 이들 회사는 공개할 어떠한 의무나 책임이 없다. 하지만 이들이 사용하는 정보는 실로 놀라우리만큼 중요한 국가적인 자산이므로, 이 정보를 사용하지 못한다면 눈에 보이지 않는 국가적인 손실이 엄청나기 때문이다. 즉, 우리의 자랑스러운 민족 문화를 정보화 사회로 이끌어 주는 다리와 같은 역할을 할 수 있기 때문에 중요하게 인식해야 한다. 필자 개인적인 생각으로는 적극적인 배려의 자세가 부족한 것은 아닌지 의문을 던져 보고, 다른 한편으로는 보다 넓은 마음으로 생각해 주었으면 하는 바램을 갖는다.

............................................................................................... ◀ 차 례

■ 한글 표준 코드는 어떻게 처리되어야 하는가

앞서 KS완성형의 문제점을 설명하면서 한글 코드가 지녀야 하는 기본적인 원칙을 설명하였다. 여기서는 현재와 앞으로의 한글 코드는 어떠한 모습을 갖추어야 하는지 살펴보자.

1. 한글 원리가 반영해야 한다는 점이다. 표현 가능한 문자는 모두 처리할 수 있어야 하며, 옛한글도 현대어처럼 다룰 수 있어야 하고, 비한글 문자(한자, 영문자, 일문자, 기타 문자)도 사용하는 데 문제가 없어야 한다.

2. 한국어 정보 처리를 위해서는 음절을 넘어서 음소 단위로 처리할 수 있어야 한다.

3. 다른 프로그램과 충돌이 없어야 한다.

4. 처리된 자료 및 기술은 산업 현장, 학계, 정부 기관에서 공유하도록 공개적이어야 한다.

5. 국제적인 표준 규격을 따라야 한다.

6. 정부의 정책적인 지원이 있어야 한다.

이 중에서도 가장 중요한 것은 뭐니뭐니 해도 한글 원리를 충실하게 반영해야 한다. 지금까지 실질적인 표준 한글 코드였던 KS완성형은 이러한 원칙을 무시하였기에 심각한 문제를 앉고 있었다. 그런데 KSC5700(유니코드2.0)은 이러한 문제를 해결할 수 있으므로 매우 바람직하다고 생각한다. 유니코드는 처리 원리상 현대어 11172자는 물론 미완성 음절 문자와 옛한글을 처리할 수 있도록 되어 있지만 실질적으로 처리되려면 어느 정도 시간이 필요할 듯하다. 이와 더불어 음소 단위로 처리할 수 있어야 하는데 유니코드는 이 부분을 완벽하게 소화할 수 있어서 기대되는 바가 크다.

다 음으로는 주목해야 할 점은 산업 현장에서 공유하도록 공개적이어야 한다는 부분이다. 이에 대한 것은 구체적인 사례를 통하여 함께 생각해보자. 지난 1995년 마이크로소프트사가 한글 윈도우95를 발매하는 과정에서 확장 완성형 코드를 발표함으로써 많은 논란을 불러 일으켰다. 그 당시 관련 업계는 물론이고 언론에서도 크게 부각시켰던 것 중에 하나는 발표되지 직전까지 확장 완성형 코드에 대한 언급이 없었다는 점이다. 업계와 언론에서 비난의 화살이 쏟아지자 이미 프로그램 개발을 완료한 시점에서 확장 완성형 코드를 포기하기 어렵다는 입장을 취하게 되고, 그것이 마이크로소프트사의 계획적인 음모로까지 비추어지게 되었다. 사실상 업계에서 시장을 주도하고 있는 회사가 새로운 표준으로 자리잡을 수도 있는 문제를 일방적으로 발표함으로써 이에 대한 반발은 물론이고 국가적으로 중요한 문제였으므로 공개적으로 공청회를 거쳐야 한다는 여론이 들끓었다. 결국 이것은 마이크로소프트사의 회사 이미지를 실추시키는 결과가 되었다. 필자 개인적인 생각으로는 확장 완성형 코드가 음모나 횡포의 결과이기보다는 그 동안 처리할 수 없었던 8822자를 KS완성형 코드와 호환성을 유지하는 범위 안에서 처리할 수 있도록 하는 것이 주목적이었으며, 마이크로소프트사도 확장 완성형 코드를 채택하는 과정에서 내부적으로는 오랫동안 많은 토론과 고민을 한 것으로 전해 들었으며, 발표하기 직전까지 국내 개발 업체와 어느 정도 협의를 해왔었다. 더욱이 상당히 오랜 기간 동안 베타 테스트를 거쳐 왔기 때문에 음모적으로 발표한 것과는 거리가 멀었다는 점이다. 하지만 직접적으로 관련이 적은 산업 현장, 학계, 정부 기관 등등 기타 관계자들과 별다른 협의나 공개적인 토론회도 없이 발표됨으로써 독점기업 의도적인 음모와 외국 회사의 일방적인 횡포로 비추어지게 되었다. 바로 이 부분이 우리에게 중요한 점을 시사한다. 국가적으로 중대한 영향력을 미칠 수 있는 한글 코드를 개정하거나 채택하는 데 있어서 산업 현장을 비롯하여 학계와 정부 기관에서 함께 고민하고 수용할 있도록 공개적으로 검증을 받으면서 전개되어야 한다는 교훈을 안겨 준 셈이다. 또 다른 사례로는 현대어는 물론 옛한글과 한자를 훌륭하게 지원하는 프로그램을 살펴보자. 이들 프로그램에서 옛한글과 확장한자(KS완성형에 없는 한자)는 입·출력을 할 수 있지만 정보로서는 사용할 수 없는 죽어 있는 데이터라는 점을 앞에서 밝혔다. 앞에서 지적했듯이 이들 프로그램이 처리하는 정보(현대어, 옛한글, 한자)는 값어치로 따지기 어려우리만큼 귀중한 자산이지만 공개적으로 자료를 접근할 수가 없어서 안타까움을 금할 수 없다. 즉, 보이지 않는 국가 재산을 썩히고 있는 셈이다. 이러한 정보를 쉽게 접근할 수 있도록 배려한다면 한국어 정보 데이터베이스 구축이라는 국가적인 사업에서 획기적인 발전을 가져왔을 텐데 하는 아쉬움이 남는다. 비록 이들 프로그램을 만드는 회사는 어떠한 책임이나 의무가 없지만 국가적인 발전을 위해서 보다 넓은 마음으로 배려하였으면 한다.

끝 으로 정부의 정책적인 지원을 살펴보자. 한글 코드 문제는 일반 상품과는 달리 사용하는 과정에서 문제점이 있거나 그것으로 인하여 다른 많은 사람에게 영향을 미칠 경우에 개개인이 나서서 해결하기가 어렵다. 특히 기업이나 표준 규약을 상대로 개인이 문제를 해결하기란 계란으로 바위를 치는 것보다 더욱 어려운 문제이다. 따라서 정부는 대한민국 국민을 대신하여 한글 코드 문제를 적극적으로 다루었으면 한다. 왜냐하면 정보화 사회에서 정보고속도로가 대동맥이라면 한글 코드는 영양분을 실어 나르는 피와 같은 구실을 하기 때문이다. 이렇게 생명처럼 소중한 한글 표준 코드에 문제가 있다면 문화의 꽃과 같은 언어를 제대로 사용할 수 없다는 것과 마찬가지이므로 정부가 앞장서서 정책적인 지도와 노력을 기울여야 하는 것은 너무나 당연하다. 흔히 잘 못 끼워진 첫 단추로 비유되던 KS완성형 코드 제정 당시에 좀더 적극적으로 문제의 본질을 파악하고 대처했더라면 지금까지 우리가 해 왔던 소모적인 논쟁은 피할 수도 있었을 텐데 하는 아쉬움을 갖는 사람이 많다. 또한 앞에서 지적했듯이 한글 코드에서 현대어는 물론 옛한글과 한자는 자랑스런 우리의 민족 문화 유산을 계승하고 발전시키는 데 중요한 역할을 하고 있음에도 불구하고 제대로 처리하지 못하고 있다. 설령 응용 프로그램 단계에서 이러한 문제를 해결한다고 하더라도 공개적으로 정보를 공유하지 못하므로 국가적으로 커다란 손실을 입고 있다. 만약 정부가 이러한 문제에 적극적으로 나서서 자원을 공유하도록 유도할 수 있는 정책을 개발하고 지원한다면 보다 나아질 수도 있을 것이다. 왜냐하면 영리를 추구하는 기업이 별다른 보상도 없이 자신만의 독특한 기술로 일구어 낸 정보를 공개한다는 것은 한 마디로 생존을 포기하는 것과 마찬가지이기 때문에 현실적으로는 거의 불가능한 일이다. 막연히 국가적인 이익을 위해서 공유하자는 것보다는 국가 발전에 기여하는 정도에 따라서 보상을 받을 수 있는 정책을 개발하고 유도한다면 현실적으로 풀어 갈 수 있으리라고 본다. 이와 같이 기업과 사용자 모두가 함께 발전할 수 있게끔 하는 것이 정부의 역할이라고 생각한다.

............................................................................................... ◀ 차 례

■ 코드 변환에 대하여

코 드 변환은 크게 세 가지 상태를 변환하는 것이다. 앞서 말한 대로 여러 종류의 코드가 있지만 실질적으로 사용하는 코드는 KS완성형, 조합형(상용, 표준)과 유니코드밖에 없기 때문에 각각의 변환 과정에 대하여 소개하겠다. 이 글에서는 조합형은 상용 조합형을 다루며, KS완성형은 윈도우95 이후에 사용되는 확장 완성형을 수용하며, 유니코드는 다른 코드와 호환이 가능한 문자 1바이트 아스키 문자와 온전하게 완성된 현대어 11,172자를 중심으로 소개한다. 유니코드에서 사용하는 한자는 20,902자이지만 앞에서 말한 것처럼 표준으로 정착되기 어려운 점과 다른 코드와 호환되지 않는 문자가 있으므로 제외하고, 유니조합형으로 부르는 자모 코드는 옛한글을 표현하지 못하므로 제외하고, 그밖의 비한글 문자 중에서 KS완성형과 호환되도록 배열된 코드가 있지만 이 글에서는 제외한다. 즉, 유니코드에서는 다른 코드와 호환하는데 문제가 있는 부분은 제외하기 때문에 1바이트 아스키 문자와 온전하게 완성한 현대어 한글 11,172자만 변환한다. 또한 이 글에서 기본적인 원리를 바탕으로 설명하는 대신에 구체적으로 변환하는 과정은 함께 제공되는 소스 코드를 참고하기 바란다.

............................................................................................... ◀ 차 례

● KS완성형 <-> 조합형(상용)

이 것은 본지를 비롯하여 다른 많은 서적에서 소개되기도 한 부분이지만, 윈도우 95이후에 사용되는 확장 완성형 한글 문자(줄여서 확장 한글이라고)에 대한 소개가 대부분 빠져 있으므로 간단하게 보충하여 설명하겠다. KS완성형은 다른 코드와 다르게 기본적인 형태소 해석 정보를 갖고 있지 않기 때문에 테이블 방식으로 다루어야 한다. 좀 더 쉽게 말하자면, 각 글자에 대응하는 꼬리표를 사용해야 하는데, 꼬리표를 모르면 변환할 수 없다. 그래서 전체적인 꼬리표 내용을 하나의(혹은 여러 개의) 표로 기억해야 한다. KS완성형은 크게 1바이트 문자와 2바이트 문자로 구분하며, 2바이트 문자는 한글 영역(기본 한글), 확장 한글, 한자 영역, 전자로 된 1바이트 문자 호환 영역, 다른 국가 문자 영역(일본어 문자, 러시아 문자, 그리스 문자 등등), 기타 기호 문자 영역으로 구분하면 이해하기 쉽다.

필자가 처리하는 방법말고도 다른 방법을 사용하는 책들이 있으므로 관심있는 독자들은 참고 자료들을 보면 되는데, 한 가지 주의할 점은 확장 완성형에 추가된 확장 한글 문자에 대한 부분이 없다는 점이다.[그림. 확장완성형 코드표]

............................................................................................... ◀ 차 례

● KS완성형 <-> 유니코드

유 니코드는 1바이트 문자와 호환되는 부분과 유니완성형 부분만을 변환한다. 유니코드를 제정하는 Unicode,inc.에서는 인터넷(www, ftp)을 비롯하여 책을 통하여 변환에 필요한 정보를 제공하고 있다. 특히 온전한 현대어 한글과 한자에 대해서는 다른 코드에 대응하는 코드값을 표기하였기 때문에 쉽게 이해할 수 있다. 여기서도 KS완성형 코드가 지닌 특성 때문에 테이블 방식으로 1:1로 변환해야 하고, 온전한 현대어 한글에 대한 대응 코드를 예로 보이겠다.

가: 0xb0a1 <-> 0xac00

각: 0xb0a2 <-> 0xac01

衣: 0x8141 <-> 0xac02 [확장 완성형 - 기본 완성형에는 대응 코드 없음]

衤: 0x8142 <-> 0xac03 [확장 완성형 - 기본 완성형에는 대응 코드 없음]

간: 0xb0a3 <-> 0xac04

...: ...

펺: 0xc64f <-> 0xd7a0 [확장 완성형 - 기본 완성형에는 대응 코드 없음]

펻: 0xc650 <-> 0xd7a1 [확장 완성형 - 기본 완성형에는 대응 코드 없음]

펼: 0xc651 <-> 0xd7a2 [확장 완성형 - 기본 완성형에는 대응 코드 없음]

펽: 0xc652 <-> 0xd7a3 [확장 완성형 - 기본 완성형에는 대응 코드 없음]

............................................................................................... ◀ 차 례

● 조합형 <-> 유니코드

유 니코드는 1바이트 아스키 문자와 온전한 현대어 한글인 유니 완성형 코드만 처리한다. 유니완성형 코드는 KS완성형 코드와는 근본적으로 다르게 형태소 정보를 사용한다. 그래서 조합형 코드처럼 초성-중성-종성 자소 정보를 쉽게 구할 수 있으며, 조합형 코드와 변화하는 과정도 매우 간단하다. 다만, 조합형에서 사용하는 미완성 음절 문자는 변환할 수 없다는 점에 유의하기 바라며, 먼저 초성-중성-종성 자소 정보를 구한 후에 각각의 구성 원리에 맞추어 합성하면 된다.

▶ 조합형 코드에서 자소 구하기

: 최상위비트(MSB)를 제외한 나머지를 차례대로 5비트씩 쪼개면 각각 초성, 중성, 종성 자소가 된다.

kssmcode(조합형 문자) = MSB(최상위 비트[1]) + ChoJaso(초성[5]) + JungJaso(중성[5]) + JongJaso(종성[5])

= (0x8000 | (ChoJaso << 10) | (JungJaso << 5) | (JongJaso))

ChoJaso = ((BYTE)((((HGCODE)(kssmcode)) >> 10) & 0x1f))

JungJaso = ((BYTE)((((HGCODE)(kssmcode)) >> 5) & 0x1f))

JongJaso = ((BYTE)(((HGCODE)(kssmcode)) & 0x1f))

▶ 유니완성형에서 자소 구하기:

유니완성형 문자: UncCode

BaseVal!(유니완성형 시작 위치) = 0xac00

ChoJamoNum(초성 문자 개수) = 19자

JungJamoNum(중성 문자 개수) = 21자

JongJamoNum(종성 문자 개수) = 28자(종성 채움 상태를 추가)

JungJongNum(중성과 종성의 합성 개수) = JungJamoNum * JungJamoNum

UncCode = ((((ChoJaso * ChoJamoNum) + JungJaso) * JungJamoNum) + JongJaso + BaseVal!)

UncInx = UncCode - BaseVal!

ChoJaso = (UncInx / JungJongNum))

JungJaso = (UncInx % JungJongNum) / JongJamoNum

JongJaso = (UncInx % JongJamoNum)

..........................................................................................◀ 차 례

■ 정보는 자원이자 곧 국가 경쟁력이다.

아 직도 인터넷이나 PC통신에서는 한글 코드 문제에 대한 노골적인 불쾌감이나 부정적인 시각이 많다. 경우에 따라서는 우리가 조합형을 사수하지 못했다는 점이 역사적으로 오점을 남기게 될 지도 모른다는 생각을 하기도 했었다. 그러나 그렇게 흥분한다고 해서 해결할 수 있는 문제가 아니었음을 차츰 깨닫게 되었다. 당시에는 한글 코드 문제가 이렇게까지 심각한 문제라고까지 받아들이기 어려운 상황이었으므로 누구를 탓하기도 어려울 듯하다. 오히려 우리 모두에게 더 큰 문제가 있을 수도 있다. 과거 KS완성형 코드가 제정될 때부터 문제를 푸는 과정에서, 해결보다는 논쟁거리로 몰아부치는 경향과 그 논쟁 자체에 집착한 것은 아닌지 반문하고 싶다. 앞에서 밝혔듯이 현대어에 대한 음절수를 정확하게 생각한 적이 없었기 때문에 유니코드 2.0에서조차 미완성 음절 문자가 현대어 영역에서 빠지게 되고 이로 인하여 현대어 자모와 옛한글 자모의 순서마저도 뒤엉키게 하는 결과를 가져왔다. 이렇게 잘못된 코드 배정은 다른 나라에서 한 것이 아니다. 우리가 직접 만들어서 제출한 것이다. 아마도 그 동안 코드 논쟁에 쏟아 부었던 노력에 3%만이라도 현대어 음절에 관한 연구를 하였더라면 이러한 결과를 자초하지는 않았을 것이다. 마치 "3%의 소금이 바다를 짜게 한다"는 말처럼, 생각을 제대로 하고 있던 몇 사람만이라도 있었더라면 똑같은 어리석음은 피할 수도 있을 텐데 하는 아쉬움이 남는다.

흔 히 지금에 와서 결과만 보고 생각해 보면, 과거 첫 단추부터 잘 끼었더라면 하는 아쉬움이 맴돌 것이다. 하지만 "역사에서는 가정이란 없다"라는 말처럼 근·현대사에서 우리가 현명하게 대처했더라면 뼈아픈 식민지 지배를 받지 않았을 텐데라고 생각하는 것과 비슷한 문제처럼 다가온다. 한국 근·현대사처럼 한글 코드도 험난한 과정을 거쳐 지금까지 왔다. 어쩌면 역사로부터 우리가 배운 진정한 교훈이라면 앞으로는 이런 일들을 되풀이하지 않도록 현재에 최선을 다하는 자세일 것이다. 그렇게 하기 위해서는 지나온 한글 코드 변천 과정과 현재의 한글 코드 성격을 살펴볼 필요성이 있고, 그런 의미에서 한글 코드에서 가장 중요한 영향을 미칠 한글 윈도우98과 널리 사용되고 있는 프로그램이 지닌 성격과 의미를 살펴보았다.

이 글은 지나온 논쟁을 재현하기보다는 현재까지의 과정과 앞으로 발전시켜야 할 방향에 맞추어 썼다. 그래서 가능한 한 객관적인 상황과 현실적인 이유들을 되짚어 보려고 노력하였으며, 또한 앞으로 해결해야 할 과제들을 점검해 보았다. 이제 한글 코드는 단순히 코드 배열의 문제가 아니다. 정보가 자원이자 국력인 정보화사회에서 한글 코드는 국가 생존을 좌우할 핵심적인 무기가 될 지도 모른다. 특히 우리 나라 산업 현실을 고려할 때, 한글 윈도우98은 단순히 어느 한 기업의 상품이기 이전에 국가 경쟁력을 좌우하는 아주 중요한 매개물일 수도 있다. 그런 의미에서 한글 윈도우98에서 처음으로 유니코드(한국어 관련)를 적극적으로 수용함으로써 시스템 차원에서 제대로 된 한글을 사용할 수 있게 된 점은 높이 평가할 만하다. 우리가 첫 단추를 잘못 끼운 지도 벌써 10년이 넘었다. 10년이면 강산도 변한다는 말처럼 한글 코드도 많이 변해 왔고, 변해 오는 과정에서 소모적인 논쟁으로 많은 시간을 허비하기도 하였다. 결국 우여곡절 끝에 유니코드라는 범세계적인 표준 코드와 함께 KSC5700이라는 한글 표준 코드로 자리 잡혀가고 있다. 아마도 조만간에 유니코드라는 이름으로 한글 코드 문제는 십여 년간의 기나긴 싸움에서 대단원을 마칠 듯하며, 그 동안의 소모적인 논쟁은 결코 헛된 것이 아니었음을 강조하고 싶다. 그 과정에서 우리들의 열정과 노력을 통하여 일구어낸 경험이야말로 훌륭한 밑거름이 되었기 때문이다.

끝으로 유니코드2.0에서 한글 코드 배정을 위해서 노력해 주신 많은 관계자 여러분께 진심으로 고맙다는 감사의 마음을 전하며, "한글 코드는 곧 국가 경쟁력"이라는 점을 다시 한 번 강조하면서 이 글을 마친다.

............................................................................................... ◀ 차 례

************** 이 부분부터는 박스로 처리됩니다.

▶ [박스] ISO-2022 규격

이 것은 아스키 부호 규격(ISO-464)의 7비트 부호를 확장하여 2바이트 부호 확장법을 정의한 것이다. 128자를 표현할 수 있는 아스키 부호 체계로는 많은 문자를 가지고 있는 동양권 국가에서는 사용할 수 없었다. 이러한 이유로 인하여 아스키 부호를 확장하여 2바이트 이상의 코드 체계를 사용할 수 있도록 만든 부호 체계 확장법을 ISO-2022라고 한다. ISO-2022의 구조를 살펴보면 다음 표와 그림과 같다.

ISO- 2022에 의하여 확장 문자 영역으로 실제 사용 가능한 공간은 D영역으로 한정되어 있다. 2바이트 문자의 각 바이트의 최상위 바이트(MSB)는 모두 같아야 한다. 그러나 D영역에서 사용할 수 있는 문자수는 8836자의 글자만 사용할 수 있으므로 여러 나라의 문자를 한꺼번에 처리할 수 없다. 그래서 각 나라별로 문자 세트를 지정하여 사용한다.

---[그림 추가 - ISO-2022 구조]를 여기다 추가합니다. ---

▶ [박스] Unicode와 ISO-10646의 관계

ISO- 10646은 국제 표준화 기구(ISO: International Standard Organization)와 국제 전자 기술 위원회(IEC: International Electrotechnical Commission)의 산하 위원회인 ISO/IEC JTC 1(Information Technology) SC 2 (Coded Character Sets) WG 2 (Multiple-Octet Codes)에서 제정 중이던 국제 표준이었다. 그에 비하여, Unicode는 Apple, Metaphor, RLG, Sun, Xerox 등이 1989년에 결성하여 만든 Unicide Working Group에서 컴퓨터에서 쉽게 사용할 수 있는 다국어 지원을 목적으로 제정하던 업계 표준이었다.

1991 년 Unicide Working Group은 Unicode ,Inc.로 조직 체계를 바꾸고, 지지부진하던 ISO-10646의 다국어 부분을 Unicide사에서 제정하는 표준을 그대로 사용할 것을 국제 표준 기구에 제안하였다, ISO-10646 중에서 UCS-2 BMP부분은 Unicide와 동일하다.

JTC: Joint Technical Committee

SC: Subcommittee

WG: Working Group

▶ [박스] KSC5700코드와 문제점 - 제 1차 한글 코드 표준화 위원회 회의록

공 업진흥청이 1995년 12월 7일 KS규격으로 제정 고시한 코드로 조합형으로 활용 가능한 한글 자모 240자와 완성형 방식으로 (완성형 코드와는 다른 의미) 사용 가능한 한글 11172자로 구성된 국제 문자 부호 체계이다. 이 규격은 완성형과 조합형을 동시에 수용할 수 있게 되어 있으며, 현대 한글 문자를 모두 표현할 수 있어서 KSC5601-1987완성형 코드가 지녔던 문제점을 해소할 수 있을 것이라고 한다. 이것은 유니코드2.0에서 배정된 한글 코드와 일치한다.

#. 한글과 한자의 정렬(Sorting) 문제

- 한 자는 한국, 중국, 대만, 일본에서 사용하는 한자들을 획순에 의해서 배정하였기 때문에 한국어에서는 사전 순으로 변환해야 만 순서대로 처리할 수 있다. 또한 중국이나 일본에서만 사용하는 한자의 경우 새로운 음을 부여해야만 사용할 수 있으며, 폰트를 만들어야 사용할 수 있다.

- '樂'자와 같이 같은 글자이지만 음이 다른 경우에 어떻게 처리할 것인가.

- 옛한글은 조합 방식만으로 표현하기 때문에 별도의 정렬 프로그램을 개발해야 한다.

#. 옛한글 문제

- 아직 발견되지 못한 옛한글은 빠져 있기 때문에 새로운 옛한글이 발견될 경우 커다란 문제가 발생한다.

- 일반 사용자는 사용하지 않는 옛한글을 국어학 연구를 위해서 모두 추가하는 것은 효율적이지 못하다.

- Window 차기 버전에서는 완성형 11172자만 지원할 것이므로 대부분의 소프트웨어에서는 완성형만 지원하게 된다.

- 조합형을 위한 한글 자모 240자의 위치가 변하면 새로운 소프트웨어를 개발해야 한다.

- 한글에 대한 명확한 정의가 없어서 옛한글, 구결, 한자까지 한글로 보아야 하는가

▶ [박스] 유니코드에서 현대 한글 완성형 11172자를 획득하는 과정

유 니코드는 1989년부터 제정되어 현재는 버전 2.1까지 발표되었으며, 현대어 한글 완성형 11172자를 배정받은 것은 1995년 버전 2.0에 이르서였다. 그 동안은 버전 1.0과 버전 1.1에서도 한글 코드에 대하여 논의는 있었는데, 현대어를 모두 표현할 수 있는 조합형 방식의 코드는 미국, 중국, 일본 등이 반대하여 배정받지 못 했다. 조합형 방식은 이론적으로 11172자를 표현하기 위해서 32768자(=2의 15승)를 수용할 수 있는 영역이 필요하다. 그런데 유니코드에서 표현 가능한 문자 65536자 중에서 절반을 한국이 사용하는 결과가 되므로 다른 국가의 심한 반발을 불러 일으켰다. 당시로는 코드 영역의 크기는 마치 영토의 문제처럼 대립하게 되었으므로 조합형 방식이 배제되고, 기존의 표준 코드인 KS완성형 위주로 배정받게 된다.

그 러나 이렇게 됨으로써 한국은 물론 국제적으로도 유니코드를 사실상 쓸모없는 코드(더미코드[Dummy-code])로 전락시키는 결과를 가져온다. 이때 때마침 윈도우95와 윈도우NT에서의 한글 지원 문제로 고심하던 마이크로소프트사도 우리 나라의 문자 코드 전문 위원회의 활동에 참가하게 되고, 1995년 3월에 가서야 버전 2.0이 채택되면서 간소화시킨 온전한 현대어 한글 완성형 11172자를 확보하게 된다. 물론 이 때에도 중국 등의 거센 반대가 있었지만 미국 등 다른 대표들의 도움으로 표결에서 한국측 의견이 최종적으로 채택된다. 이로써 한국은 유니코드에서 두 번째로 많은 문자를 배정받는 국가가 된다. 가장 많이 문자를 배정한 영역은 한자이지만 엄밀한 의미에서는 중국식 한자가 아니고, 한국·중국·일본·대만 등에서 사용하는 거의 모든 한자를 부수와 획순으로 배정하였기 때문에 한국·중국·일본·대만 등의 한자이므로 실질적으로는 한국이 가장 많은 문자를 배정받는 국가인 셈이다.

▶ [박스] 한글 코드별 효율성 비교 검토

완 성형은 기본완성형(KS완성형)과 확장완성형으로 구분하고, 조합형은 상용조합형과 표준 조합형으로 구분하지만 거의 비슷하므로 하나로 다루며, 유니코드는 완성형 방식과 조합형 방식의 차이가 나므로 구분한다. 한글 조합 원리는 음절을 이루었을 경우에 초성, 중성, 종성에 대한 정보를 구할 수 있는 정도를 말하며, 현대어 음절 표현은 표현 가능한 음절수를 말한다. 미완성 음절 문자는 현대어 중에서 초성, 중성, 종성의 구조를 유지하지 않는 한글형태를 말하고, 옛한글은 구결을 포함하지 않은 옛한글 음절을 표현 정도를 의미하고, 형태소 분석에서 효율성은 곧 바로 형태소 분석을 할 수 있는 정도를 말한다. 한자 표현은 유니코드 규정에서는 대략20000만자가 넘지만 현재로서는 실제로 지원하는 운영체제는 없지만 차츰 지원할 것으로 간주한다.

.................................................................................................... ◀ 차 례

▶ 참고 문헌

The Unicode Standard, Version 2.0, The Unicode Consortium, 1996

국어 어휘 데이터베이스 구축에 대한 연구, 정광, 국립국어연구원, 1996

국제 표준 문자 코드 제안 한자에 대한 연구, 서경호, 문화체육부, 1997.11.30.

남북한 한글코드 비교조사 및 통일방안 기초연구, 서정수, 문화체육부, 1995.12.

프로그래머 바이블, 오상문, 영진출판사, 1994.1.20.

컴퓨터 속의 한글, 이준희·정내권, (주)정보시대, 1991.

컴퓨터와 한글의 만남, 임현모, 정보문화사, 1992.

한글 정보산업의 현황과 발전 전망 - 제 7회 한글 및 한국어 정보처리 학술대회, 강태진, 1995.

한글공학, 오길록 외, 대영사, 1994.9.10.

한글코드에 관한 연구, 홍윤표, 국립국어연구원, 1995.

한글코드와 자판에 관한 기초 연구 최종 보고서, ㈜한글과 컴퓨터, 문화부, 1992.12.

확장 완성형 코드 시스템, 마이크로소프트

"KSC 5700"의 제정 의미와 전망, http://ktmp.kaist.ac.kr/~geenie/news/hangul.html, 1998.09.08.

ISO/IEC-10646 Universal Multiple Octet Coded Character Set(UCS)에 대하여, 정주원, world wide web, 1995.11.11.

KSC5700코드의 문제점, 제 1차 한글 코드 표준화 위원회 회의록world wide web, 1997.6.24.

MS사의 "확장완성형" 한글 코드에 대한 한컴의 입장(2) , world wide web, 1995.5.

MS사의 [한글 윈도우 95]에서 채택키로 한 통합형 한글 코드에 대한 ㈜한글과컴퓨터사의 입장, 한글과컴퓨터사, 1995.5.

Windows95나 NT에서의 한글 FAQ, world wide web

WWW의 국제화와 한글, http://simac.kaist.ac.kr/~jwjung/seminar/www-18n/i18n.html

공진청, KS한글코드체계 제정, http://ktmp.kaist.ac.kr/~geenie/news/hangul.html, 1998.09.08.

소프트웨어의 국제화, 방준영, http://intranet.www-kr.org/workshop/ws4/D15/

제4차 인터넷 한글표준화 협의회 회의록, http://standard.nca.or.kr/hangul/meeting4.html

한글 Windows 98에서 지원되는 Code는, http://www.microsoft.com/korea/windows98/basics/faq/default.htm, 1998.08.

한글 코드에 대하여, 정주원, world wide web, 1995.11.12.

한자·한글 변환기 원형 개발에 관한 연구, 유재수, world wide web

한컴, 유니코드기술위원회 참가, 11172자 한글 코드 영역 확보, world wide web, 1995.5.