1.
먼 옛날, 윈도 98을 쓰다가 2000으로 갈아탔을 때, 난생 처음으로 Windows NT 계열을 구경하고서 굉장히 놀랐던 기억이 지금도 선하다.

NT 계열은 일단 마의 리소스 퍼센티지 제약이 없었으며, 말로만 듣던 2바이트 문자열 기반의 유니코드 API가 잘 지원되었다. 이 둘은 매우 크게 다가온 아이템이다.
작업 관리자가 9x 계열에 비해서는 넘사벽급으로 잘 만들어져 있었고, 도스창이 아닌 정식 명령 프롬프트가 제공되었다. 이 외에도 EXE/DLL 내부의 리소스를 수정하는 API가 사용 가능한 것도 좋았다. (9x 계열은 16비트 바이너리의 리소스만 고칠 수 있었음)

윈도 95/98에서는 못 보던 파일은 ntoskrnl.exe, csrss.exe, lsass.exe, ntdll.dll, hal.dll, ntvdm.exe, svchost.exe 등이다.
그 반면, 윈도 9x의 잔재이던 파일은 msgsvr32.exe, win386.swp, system.dat, user.dat, winoa386.mod, *.vxd, win.com 같은 것이다.

윈도우 2000/XP부터는 NT 커널 덕분에 주기적으로 재부팅을 할 필요가 없어졌다.
하지만, 주기적으로 재설치도 거의 할 필요가 없어진 건 Vista 이상인 듯하다. XP는 이 범주에까지 넣기에는 좀 2% 부족한 구석이 있었다.

2.
과거에 Windows 9x 시리즈와 Windows NT는 구조적으로 여러 차이가 있었지만, 프로그래머의 관점에서 중요한 특징 중 하나는 '이식성'이었다.
NT는 하드웨어에 종속적인 계층이 철저히 분리되어 설계되었으며 커널이 대부분 어셈블리가 아니라 C/C++이라는 '고급 언어'로 작성되었다. 마치 유닉스처럼. 덕분에 인텔 x86뿐만 아니라 90년대 당시로서는 MIPS, Alpha 등 다양한 아키텍처용 윈도 NT가 나오기도 했다.

NT는 설계 차원에서 특정 하드웨어의 특성에 맞는 '타협'을 별로 안 하고 추상화 계층이 많이 존재하다 보니 깔끔함, 안정성, 범용성 등 많은 장점을 얻을 수 있었다. 게다가 그 시절에 벌써 유니코드를 염두에 두고 wide string을 기본적으로 사용하기 시작한 건 상당한 선견지명이다. 물론 그 대신 시스템 요구 사항이 당연히 1990년대의 가정용 PC가 도저히 범접할 수 없을 정도로 높았다. 메모리와 속도 모두.

이런 NT와는 달리, Windows 95는 이상이 아닌 현실을 추구하였다. 도스와 윈도 3.1을 돌릴 수 있는 정도의 램 한 자릿수 MB대 똥컴을 타겟으로 하여 Win32 API를 최대한 많이 구겨 넣었다. 이 과정에서 지금은 당연시되고 있는 유니코드 API조차도 메모리를 필요 이상으로 많이 잡아먹는 다고 판단되어 과감히 짤려 나갔다.

9x 커널의 소스에는 도스 레거시를 비롯해 오로지 x86 CPU에만 최적화된 쑤제 어셈블리 코드가 난무하였다. 그렇게까지 극도로 최적화를 하고 성능을 짜내야만 메모리 사용량을 1K라도 줄일 수 있을 테니 말이다. 9x는 NT보다 배고픈 운영체제인 것이다. 그럼에도 불구하고 OS/2를 PC 환경에서 완전히 몰아내고 Windows 천하통일을 이루는 데 기여한 일등공신은 NT가 아니라 95였음이 부인할 수 없는 사실이다.

OS/2를 개발하던 마소의 엔지니어들이 떨어져 나가서 따로 만든 게 NT라고는 하지만, OS/2 자체는 NT 같은 이식성 있는 형태라기보다는 9x에 더 가까운 어셈블리 최적화 컨셉이었다고 한다. OS/2는 NT 뺨치는 수준의 앞서 나간 최첨단 운영체제이긴 했지만, 내부 구조가 이식성보다는 역시나 x86에 너무 종속적이었다는 뜻. 그래서 다른 아키텍처로 이식은커녕, 같은 x86 컴에서 가상화 소프트웨어로도 돌리기가 곤란할 정도라고 한다.
(그래도 지금은 x86에서 맥 OS X 해킨토시까지 돌리는 세상이 됐는데 설마 OS/2를 못 돌리나 싶다.)

3.
더 옛날, 도스 시절에는 뭔가 새로운 하드웨어를 사용하려면 램 상주 프로그램을 덕지덕지 실행해 놔야 해서 몹시 불편했다. CD롬조차도!

  • 사운드: sound / unsound (굉장한 옛날 유물. 왠지 '불건전하다!'가 생각 나는 건 기분 탓. ㅋㅋㅋ)
  • 그래픽: simcga, msherc (이것도 옛날 유물. msherc의 경우, QuickBasic에도 포함돼 있었다.)
  • 마우스: mouse (단, 윈도 3.x는 별도의 램상주 드라이버 없이도 마우스를 스스로 인식하여 실행되었음!)
  • CD롬: mscdex (기본 메모리를 상당히 많이 차지했음)

아마 USB 포트가 도스 시절에 도입됐다면, 이걸 인식시켜 주는 램 상주 프로그램도 당연히 필요했을 것이다.
아, 텍스트 모드에서 한글을 구동해 주는 프로그램도 빼먹을 수 없다. hbios / mshbios(윈도 95) 같은 것.
그 외에 화면 캡처나 게임 위저드 같은 램 상주 유틸리티는 하드웨어 인식보다는 편의 기능 분야에 속한다.

요즘은 환경변수 같은 건 PATH에서나 제일 많이 쓰이고, C/C++ 프로그래머에게는 컴파일러의 동작에 필요한 include 및 라이브러리 디렉터리를 지정할 때나 쓰이는 게 고작이다.
하지만 옛날에 사운드 블래스터라는 사운드 카드가 있던 시절에는 기본 IRQ 번호던가 뭔가도 환경변수에다 지정해 놓곤 했으며, 각종 게임의 환경설정 프로그램에는 사운드 종류와 그런 세부 정보도 입력을 받곤 했다.

이것도 정말 까마득한 옛날 얘기가 됐다.
도스용 프로그램들에는 파일 메뉴에 '도스 나들이(DOS Shell)' 기능이 있던 시절이니까 말이다.
운영체제가 이렇게 방대하고 권한이 커지면서 상당수의 유틸리티들은 의미를 퇴색했으며, 전문화된 고급 셸 아니면(토탈 커맨더 같은) 더 전문적인 유지보수 유틸리티(노턴 고스트?) 내지 안티바이러스/보안 쪽으로 업종을 세분화· 전환하는 게 불가피해졌다.

4.
태초에 도스는 검은 화면에 흰 프롬프트밖에 없었을 뿐만 아니라 명령어를 입력하는 환경도 굉장히 자비심이 없었다.
삽입/삭제 모드 같은 개념이 없을 뿐만 아니라, 애초에 이미 입력된 글자를 지우지 않고서는 앞 글자로 cursor를 옮기는 것 자체가 불가능했다. 즉, 왼쪽 화살표만 눌러도 마치 bksp를 누른 것처럼 앞글자가 지워지면서 cursor가 앞으로 이동했다.

명령 히스토리는 직전의 딱 한 단계만 지원했다. F1~F3을 눌러서 직전 명령을 한 글자씩 복구하거나 첫 n 글자 또는 전체를 한꺼번에 불러오곤 했다. 그 시절을 혹시 기억하는 분이 계시는지?

그나마 doskey.com이라고 아마 도스 3~4쯤에서 추가된 걸로 추정되는 외부 명령 램 상주 유틸리티를 실행하면 위/아래 화살표로 히스토리가 가능하고 좌우 cursor 이동이 자유롭게 가능해졌다. 지금은 너무 당연하게 여겨지는 기능이 옛날에는 별도의 프로그램을 통해서만 접근 가능한 액세서리 기능이었던 것이다.

윈도 NT의 명령 프롬프트는 기본적으로 이 모드인 듯한데, 그런데 tab을 눌러서 파일/디렉터리 이름을 자동 완성하는 기능은 윈도 XP에서 처음으로 추가되었다. 세상에, NT4와 2000 시절까지만 해도 이런 기능이 없었으며, tab을 누르면 그냥 문자적인 탭이 그대로 삽입되곤 했다.

단, 기능 추가만 있는 건 아니다. 윈도 XP까지는 탐색기에서 파일이나 디렉터리를 명령 프롬프트에다 drag & drop을 하면 그 이름을 자동으로 삽입해 주는 기능이 있었는데 아마 윈도 Vista부터는 그 기능이 의도적으로 삭제되었다. 보안 때문에 취해진 조치라고 하는데 이런 편리한 기능에 도대체 무슨 보안 문제가 있는지는 나로서는 알 길이 없다.

명령 프롬프트를 전체 화면으로 실행하는 기능 역시 Vista에서부터 삭제되었다. 딱히 별 의미가 없어지기도 했으니.
어디 이 뿐이랴. 2000까지만 해도, 콘솔창 내용을 마우스로 긁는 '빠른 편집' 모드는 곧장 사용 가능했던 반면 XP부터는 먼저 속성 창을 거쳐서 강제로 켜야만 사용 가능하게 바뀌었다. 이건 보안 이유 때문은 아니고, 마우스를 지원하는 도스용 프로그램과의 호환 때문에 취해진 조치라고 한다.

제아무리 도스 기반이 아닌 NT 계열의 명령 프롬프트라 해도, 문자 인코딩부터가 2바이트 ANSI 코드 페이지와 여전히 얽혀 있고 도스의 흔적을 완전히 걷어내지는 못한 듯하다. 그래도 64비트부터는 16비트 코드 자체가 이제 지원되지 않는데 더 좀 걷어내도 되지 않나 싶다.
기존 명령 프롬프트보다 더 강력한 대체제라고 일컬어지는 PowerShell이라는 물건이 있긴 하나, 본인은 그런 게 있다는 것만 알고 이게 특별히 장점이 무엇인지는 알지 못한다.

아 그리고. 지긋지긋한 Terminal 내지 굴림체 말고 Consolas 내지 Courier, Lucida Console 같은 글꼴을 좀 쓰고 싶은데 Wndows는 공식적으로는 명령 프롬프트의 글꼴을 자유자재로 바꾸는 방법을 제공하지 않는다. 마치 uxtheme을 해금/탈옥시키듯이 레지스트리를 조작해서 글꼴을 바꾸는 방법이 인터넷에 있긴 한가 본데 본인은 성공하지 못했다.

Posted by 사무엘

2015/03/02 19:28 2015/03/02 19:28
, , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1068

뭐, 무식이 자랑이랄 수는 없겠지만,
본인은 전산학 내지 컴퓨터공학의 여러 분야들 중에서 문외한에 가깝게 제일 모르는 분야는 통신, 네트워크, 웹, 보안 쪽이다.
왜 제일 모르느냐 하면, 저건 컴퓨터 한 대만으로 독학이 가능하지 않고, 뭔가 '감'을 터득할 수 없는 분야이기 때문이다. 그래서 그런 걸 잘하는 사람들이 부럽다..

일례로 완전 최저수준 소켓 API와, 고수준 HTTP API 사이의 중간 과정에 대한 감이 전혀 없다. 후자도 분명 전자를 이용해서 구현됐을 텐데, 내부 구현이 어찌 돼 있는지 난 아는 게 없다.
그리고 네트워크 트래픽이 컴퓨터의 I/O 병목엔 어떤 영향을 끼치는지, 그 패킷이 어떻게 해서 한 운영체제 내부의 특정 응용 프로그램으로 잘 전달이 되는지, DDoS 공격이 서버 컴퓨터에 어떤 물리적인 영향을 끼쳐서 서버를 뻗게 할 수 있는지, (아님 단순히 프로세스/스레드의 무한 스폰으로 인해 소프트웨어적인 자원 고갈만으로 뻗는 건가?)

HTTP 프로토콜에서 파일 업로드는 어떤 절차를 거쳐서 되는지, 방화벽이라는 게 정확히 뭘 하는 물건인지,
왜 구닥다리 윈도 2000/XP sp0을 띄운 채로 랜선을 꽂으면 뭐가 뚫려서 어떻게 되는지..
요즘은 네트워크 패킷은 하부 계층에서 압축이나 암호화를 좀 하는 게 있는지 등등..

이런 것들은 난 하나도 모..른..다. 저런 거 하나도 몰라도 <날개셋> 한글 입력기 개발하는 덴 아무 지장이 없기 때문이다.
그렇다고 해서 내가 컴퓨터 명령어 체계나 운영체제/소프트웨어 자체의 내부 구조나 보안에 대해 전혀 모르느냐 하면 그것도 물론 아니니.. 지식의 분포가 좀 불균형하다면 불균형한 셈이다.

본인은 초딩 중고학년 때 개인용 PC, 중학교 때 모뎀과 PC 통신, 고등학교 때 인터넷과 이메일, 그리고 대학교 때 무선 인터넷과 휴대전화의 순으로 문명의 이기들을 접했다. 랜 선이라는 걸 태어나서 처음으로 구경한 게 고등학교 때부터인데, 그 기간 동안 언젠가 집도 인터넷 접속 방식이 전화 모뎀에서 전용선으로 바뀌었다. 그때가 한창 전국적으로 인터넷 전용선이 깔리던 시절이었으니까.

지금까지 통신 기술은 정말 눈부신 속도로 발전했다.
신문· 방송에서 기자의 이메일을 공개하는 게 대세가 된 게 1990년대 후반부터이다.
지금으로부터 10여 년 전엔 '블로그'라는 단어가 도전 골든벨의 마지막 문제의 답이었다는 게 믿어지시는가? (그것도 학생이 못 맞혔고 그 당시엔 내게도 생소했다)

옛날에는 인터넷 연결을 위해서도 PC 통신을 할 때처럼 먼저 전화를 걸어야 했다. 사용 시간 카운터가 올라가는 자그마한 인터넷 연결 창이 뜬 동안만 인터넷을 이용할 수 있었다.
또한, 모뎀과 마우스를 동시에 사용하려면 두 물건을 서로 COM 포트가 충돌하지 않게 배치를 해야 했다.
Windows 3.x에서는 운영체제 차원의 네트워크 지원이 전무하기 때문에 트럼펫 Winsock인지 뭔지 하는 걸 먼저 설치해야 했다.

이 모든 것들이 지금은 까마득한 옛날 이야기가 됐다.
지금은 뭔가 그렇게 상태를 확인하면서 인터넷을 해야 하는 상황은 스마트폰 태더링으로 무선 인터넷을 쓸 때 정도이고 이것도 제약, 압박감, 부담 같은 건 옛날과는 비교할 수 없이 작아졌다.
메인보드가 어떻게 공간 워프를 했는지, 요즘은 유선 랜과 무선 랜도 전부 내장되어 나온다. 따로 뭘 장착조차 할 필요 없이 바로 접속만 하면 된다.

오늘날 인터넷이라고 불리는 그 통신망은 OSI 레이어 계층 중 제3계층(네트워크 계층)을 차지하는 IP라는 프로토콜을 기반으로 동작한다. IPv4, IPv6 같은 주소 체계도 이 계층에서 규정하는 것이기 때문에 모든 인터넷 통신은 이 체계를 기반으로 구성되어 있다.

그리고 그 아래의 제4계층(전송 계층)에는 인터넷 프로토콜을 따르는 네트워크 패킷을 보내는 방식의 차이를 규정하는 프로토콜이 있는데, 크게 TCP와 UDP가 있다.
TCP는 보낸 패킷이 반드시 순서대로 도착한다는 것은 보장되지만, 보냈던 단위랄까 형태가 그대로 도착하지는 않는다.
aaa, bb, ccccc, ddd, e 이렇게 패킷을 보냈으면 받는 쪽은 aa, ab, bccc, cc, dd, d, e 뭐 이렇게 받을 수도 있고 다른 형태가 될 수도 있다. 조립은 받는 쪽에서 알아서 해야 한다.

UDP는 TCP와는 달리 보낸 패킷이 원래의 형태 그대로 간다는 보장은 되지만.. 일부 패킷이 전송 과정에서 누락될 수가 있다.
즉, 위의 경우 ddd가 누락돼서 aaa, bb, ccccc, e 이렇게 갈지도 모르지만.. 일단 간 놈은 원래 형태 그대로 간다. 패킷의 누락 여부 판단을 받는 쪽에서 알아서 해야 한다.
그래서 TCP는 일종의 스트림 지향적이며, UDP는 개개의 패킷이 모 아니면 도 형태로 가는 메시지 지향적이다.

형태도 보존되고 누락 현상도 없는 만능 프로토콜이 없는 이유야 뭐, 세상에 값도 싸고 성능도 좋은 물건은 존재하지 않기 때문인 것과 같은 맥락일 것이다.
그게 필요하면 UDP 같은 걸 기반으로 패킷 누락을 감지하고 재전송을 요청하는 로직을 응용 프로그램이 별도로 구현해 줘야 한다.

온라인 게임에서는 “기관총 난사 내지 캐릭터 이동 같은 것만 UDP이고 나머지는 다 TCP”라는 말 한 마디로 요약된다.
자주 발생하기 때문에 반응성이 중요하고 적당히 좀 씹혀도 상관 없는 것만 UDP이고.. 나머지 크리티컬한 것들은 다 TCP를 써야 한다는 뜻이다.
그러나 온라인 게임에서 발생하는 트래픽의 상당수, 대략 70% 가까이는 그래도 UDP 방식이라고 한다.

실시간으로 스트리밍되는 대용량 오디오/비디오 데이터도 자명한 이유로 인해 UDP 방식으로 전송된다.
이런 차이를 보면, TCP와 UDP의 관계는 사실상 무손실 압축과 손실 압축의 관계나 마찬가지인 것 같다.

TCP의 경우 응용 프로그램이 아니라 아래의 프로토콜 차원에서 패킷의 누락을 감지하여 누락이 있는 경우 재전송 요청을 한다.
그런데 모바일처럼 네트워크 환경이 원래 워낙 열악해서 패킷 손실이 굉장히 자주 발생하는 곳에서는
TCP 방식에서는 끝도 없이 재전송 요청을 하고 받은 데이터에 결함이 없는지 체크와 빠꾸만 반복하느라 응용 프로그램이 그 동안 멍하니 있어야만 하는 일이 발생한다고 한다.
즉, TCP가 구조적으로 오버헤드가 더 크니, 네트워크가 열악한 곳에서는 그런 동작을 감안해야 한다.

게임에서 그래픽 엔진, 물리 엔진, 동영상/캡처 엔진도 아니고 네트웍 엔진 미들웨어로 먹고 사는 분이 국내에 일단 한 분 계신다. 넷텐션의 대표이사인 배 현직 씨. 이 업계에서는 이미 유명인사이다.

난 네트워크 쪽 프로그래밍을 해 본 건 먼~ 옛날에 소켓 API 대충 뚝딱해서 오목을 만들고..
DirectPlay를 써서 스크래블 정도 보드 게임에다가 네트웍 플레이를 넣어 본 게 전부이다. 그래도 그것만으로도 굉장히 재미있는 경험이었다.
저수준에서 패킷 암호화, 각종 오류 처리 그런 건 모른다. DPlay는 나름 하드웨어 독립을 추구한 통신 API이긴 한데, 요즘은 모뎀이고 시리얼 케이블 그딴 건 다 없어졌으니 그런 추상화 계층이 필요가 없어지면서 자연스레 도태했다. 잘은 모르겠지만 제1계층(물리 계층)은 거의 획일화가 돼 버린 것 같다.

※ 여담. IPX는 어디로 갔는가?

스타크래프트에서 배틀넷 말고 그냥 LAN으로 친구들끼리 팀플을 할 때, 옛날에는 배틀넷 다음으로 위에서 둘째인 IPX를 으레 고르곤 했다. 그러나 어느 패치 때부터인가 맨 아래에 UDP가 추가되었으며 그걸 고르는 걸로 구조가 바뀌었다. IPX는 동작하지 않기 시작했다. 어찌 된 일일까?

IPX라는 프로토콜은 똑같이 이더넷 랜선으로 통신을 하지만, 오늘날의 인터넷과는 다른 방식으로 통신을 한다. 즉, IP와 대등한 제3계층에서 방식이 다른 프로토콜인 것이다. IPX는 옛날에 네트워크 솔루션으로 유명했던 노벨 사에서 개발했고 실제로 매우 널리 쓰이기도 했지만 오늘날은 IP에 밀려서 사라졌다.

Windows 95때까지만 해도 네트워크 구성요소들을 설치하고 나면 기본으로 깔리는 것은 IPX였다. TCP/IP 지원 기능은 운영체제 CD를 넣어서 별도로 설치해야 했다. 무슨 말이냐 하면, 오늘날 당연시되고 있는 이 컴퓨터의 IP 주소를 설정하는 기능이 Windows 95에는 기본으로 없었다는 뜻이다. (심지어 네트워크 기능이 설치된 컴에서도)

사용자 삽입 이미지

그 다음 1990년대 중후반, Windows 98부터는 인터넷의 중요성이 워낙 크게 부각되기 시작했으니 TCP/IP 지원도 같이 포함되었다.
여담이지만 Windows에서는 등록정보/속성을 나타내는 단축키가 R인 편인데, 95에서는 유독 저 대화상자에서만 R은 삭제이고, 등록정보는 P였다. 무척 불편했는데 이 역시 98부터는 다같이 R로 개선됐다.

하긴, 본인도 옛날부터.. Windows가 근거리 네트워크 차원에서 제공하는 컴퓨터 간의 폴더 공유 기능과, 웹브라우저로 띄우는 인터넷은 기술적으로 무슨 관계인가 궁금하긴 했다.
인터넷 열풍 앞에서 IPX는 점점 잉여로 전락했으며, Vista부터는 드디어 IPX 지원이 hlp 도움말만큼이나 짤렸다. 그래서 스타크래프트도 근거리 팀플에 인터넷 프로토콜을 사용하는 UDP 지원이 추가된 것이다.

Posted by 사무엘

2015/02/05 08:37 2015/02/05 08:37
, , , ,
Response
No Trackback , 10 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1058

본인이 지금까지 게임 포함 고전 소프트웨어에 대해 글을 잔뜩 올린 것은 그래도 플랫폼은 PC 한정인 편이었다. 운영체제는 응당 16비트 도스/윈도이다.
하지만 그보다 더 옛날 8비트.. 아무래도 롬 베이직을 빼면 롬 카트리지를 꽂아서 게임밖에 할 게 없었던 더 옛날 컴퓨터에 대한 추억도 없는 건 아니다.

본인은 난생 처음 접한 개인용 컴퓨터가 286 AT인 관계로, 저 컴퓨터는 친구 집에서 어깨 너머로 구경만 했지 개인적으로 소장한 경험은 없었다.
그런 플랫폼용으로 프로그램 개발은 어떻게 했을까? 16비트도 모자라서 8비트이면 int도 char과 크기가 같을까? 몇만 바이트밖에 안 되는 허접한 메모리로 어떻게 저런 게임을 만들 수 있었을까? 1980년대 초니까 C 컴파일러조차도 없이 그냥 기계어/어셈블리 직통 코딩을 했을까?

그런 컴퓨터와 아예 8비트 아케이드 게임기와의 관계는 어떠했을까? 그리고 MSX인지 뭔지는 무슨 규격이지? 난 그런 건 전혀 모른다.
그러고 보니 일본이 유난히도 이런 플랫폼용 게임을 많이 만들었던 것 같다. 이 글에서 소개하는 5개의 게임도 다 일제이다.
하지만 본인은 정작 일본에서 동전 품절 현상을 일으킬 정도로 대성공을 거뒀다는 슈퍼마리오는 전혀 접한 적이 없었다. 그리고 황금도끼나 보글보글도 PC 도스용을 접했지 오락실용은 접한 적이 없다. 오락실용이 더 완성도가 높고 재미있는데도 말이다.

1. 남극 탐험

사용자 삽입 이미지

영어 원제는 Antarctic Adventure로, 1984년에 일본 코나미에서 MSX용으로 개발했다.
구멍과 바다표범을 요리조리 피하면서 펭귄을 잘 달리게 하는 게 목표이다. 구멍에 빠지거나 바다표범에 부딪히면.. 주인공인 펭귄이 죽거나 다치지는 않지만.. '지연'이 발생해서 제한 시간 안에 도착을 못 하고 미스가 난다.

BGM은 잘 알다시피 다른 음악이 아니라 스케이터 왈츠라는 고전 음악이다.
그리고 레벨을 클리어하면 가상 세계가 아니라 현실에서 남극 기지를 보유하고 있는 국가들의 국기가 뜨는데, 이는 이 게임이 완전한 허구의 게임성보다는 일종의 교육용으로 개발되었기 때문이다.
늘 드는 생각이지만, 주행 거리 단위는 km를 m로 거의 1/1000에 가깝게 너프시켜도 모자랄 판에 뻥튀기가 너무 심하다.

2. 캐슬 엑설런트

사용자 삽입 이미지

1985년에 일본 아스키 사에 MSX 및 여타 플랫폼용으로 개발한.. 일단은 아케이드 게임이지만 슈파플렉스처럼 퍼즐 요소가 굉장히 강하다. "도미솔미 파레솔~~ 도미솔미 파레도" 요런 BGM이 유명하다. 참고로 아스키는 MSX 규격을 제정하는 데 동참했던 그 회사이다.

얘가 게임 메카닉면에서 여타 게임들과 다른 점은.. 점프가 단순히 일시적인 추진력으로 공중에 떴다가 즉시 떨어지는 게 아니라... 일종의 제트팩을 몇 초간 동작시키는 것과 같다는 점이다. 그리고 다른 방으로 들어가면 각종 기물이나 적들의 위치가 원상복귀되어 버린다는 것도 비현실적이다. 단, 없애 버린 기물이나 적이 다시 생기지는 않는다.

이 게임은 레벨이라는 개념이 없으며, '캐슬'을 구성하는 가로 10*세로 10 총 100개의 방 전체가 거대한 단일 레벨이다. 그리고 지형과 기물, 각종 열쇠 조합을 이용한 굉장히 까다로운 퍼즐을 풀어야 공주가 있는 방까지 갈 수 있다. 주인공은 각종 움직이는 트랩이나 적에게 걸리면 HP 없이 바로 죽는다. 그리고 무기가 없어서 적은 움직이는 기물이나 트랩을 이용해서만 죽일 수 있다.
난 당연히 엔딩은 못 보고 포기했지만, 그래도 뭔가 중세풍의 성 안에서 각종 보석을 먹는 게 잠시나마 재미있긴 했다.

3. 덱스더(Thexder)

사용자 삽입 이미지
우리말로 표기와 영어 스펠링이 굉장히 헷갈려서 그 동안 검색을 하고 싶어도 못 하곤 했다. 원제품의 로고타입을 보면 T가 영락없이 C처럼 적혀 있기도 해서 더욱 혼란스러웠다. 게다가 Dexter라는 이름도 있다.
그런데 PC용에는 포팅을 한 기업인 '1987 시에라 온라인'이라는 문구가 뜬다는 걸 기억을 되살려서 역추적 후 검색에 성공했다.

친구 집에서 패미컴용을, 그리고 나중에 초딩 시절에 개인적으로 PC DOS용도 해 봤다. PC용은 극악의 종횡비를 자랑하는 CGA 640*200 16색 그래픽 모드에서 실행되었다. 물론 원작은 1985인가 86년에 Game Arts라는 일본 기업에서 개발되었으며, 그 당시 수십~수백만 카피가 팔렸을 정도로 굉장히 히트 치고 성공한 작품이라고 한다.

게임 주인공은 이족보행과 비행 기능을 모두 갖춘 로봇이다. 아케이드 게임으로서는 아주 드물게 각도를 목표물을 자동 조준하여 총을 쏘는 기능이 있다. (이것 말고 자동 조준을 하는 게임으로는 난 툼 레이더밖에 못 봤다~!)
비행 모드에서는 덩치가 좀 더 작아지고 낙하· 추락을 안 하게 되지만 자동 조준을 못 하며 중간에 정지를 할 수 없다는 제약이 생긴다.

이런 상태에서 던전 안의 수많은 장애물· 몬스터들을 죽이거나 피하면서 던전을 빠져나가는 게 게임의 목표다. 게임을 잘 못하면 적들이 너무 많이 나와서 걔네들에게 다구리 당하다가 게임오버 된다.
SF스러운 느낌이 나면서 한편으로는 단조 특유의 구슬픈 느낌이 나는 BGM도 인상적이다.

4. 마피 (Mappy)

사용자 삽입 이미지

1983년에 일본 남코에서 개발한 아케이드 게임으로, 동작 플랫폼이 위의 둘과는 좀 다르다. 위키백과에서도 MSX가 아니라 '아케이드'라고만 소개하고 있는데, 그래서 그런지 본인 역시 이건 동전을 넣어서 사용하는 동네 문방구의 오락기로만 구경해 봤다.
주인공은 쥐이고 적들은 고양이인데, 고양이를 피하면서 아이템들을 모두 모아야 한다.

고양이를 직접 공격해서 죽일 수는 없으며, 문을 적절한 타이밍에 열어서 기절시킬 수만 있다. 그리고 굉장히 특이한 규칙이 있는데, 봉봉 패드를 타고 점프 내지 낙하 중일 때, 다시 말해 발이 땅에 닿지 않은 상태일 때는 고양이와 닿아도 죽지 않는다. 요 타이밍을 잘 이용해야 한다.
그런데 안전하다고 해서 봉봉 패드만 계속 연달아 타고 있으면 안 된다. 그러면 패드가 나중에 끊어져서 화면 아래로 떨어지기 때문이다.

E단조의 BGM 멜로디도 20년 가까이 기억 속에 봉인되어 있었는데 본인은 아직까지 정확하게 기억하고 있다. 신기하다.
그리고 정식 오락실도 아니고 마치 뽑기 기계처럼 비치된 '동네 문방구의 오락기'라고 하니까 또 추억이 돋는다. 요즘은 그런 용도의 게임은 스마트폰 게임이 다 대체해 버렸으며, 3, 40대 아저씨들이나 옛날 추억을 살리려고 에뮬레이터와 롬 파일을 구해서 PC에서 게임을 즐기는 지경이 됐다.

일본에서는 패미컴(family), 퍼스컴(personal) 등.. 한국 같았으면 그냥 알파벳 이니셜을 그대로 썼을 텐데 영어 단어를 제멋대로 뚝뚝 잘라 내서 말은 참 잘 만든다는 생각이 들었다.

5. 요술나무 (Magical Tree)

남극탐험과 마찬가지로 코나미에서 1984년에 MSX용으로 개발한 작품이다. 제목을 까맣게 잊어버린 상태였는데 구글에서 MSX tree climbing game이라고만 쳤더니.. 이거 뭐 내가 원하는 답이 즉시 튀어나와서 기억을 복원할 수 있었다. 역시 무서운 구글.

사용자 삽입 이미지

이건 깃털 달린 모자를 쓴 귀여운 인디언 소년이 주인공으로 나오고, 나무를 수직으로 끝도 없이 타고 오르는 게 목표인 게임이다. 9개의 스테이지를 거치면서 설정상 총 2004m를 올라가야 한다. 한라산보다 약간 더 높구나.
게임 BGM을 말하자면, 평소에는 F장조 파~도 파~도 파라솔파도... 요렇게 시작하는 명랑한 멜로디 6마디가 무한 반복된다. 아, 한 스테이지에는 화면의 중앙에 나무 기둥이 있는 보통 모드가 있고, 중앙 대신 좌우 양 끝에 나무 기둥이 있는 특별 모드가 있다. 특별 모드에서는 반음 간격의 뚜두뚜두...만 반복되면서 뭔가 위기 상황인 듯한 분위기가 난다.

주인공을 방해하는 건 무슨 게처럼 수평 비행을 하는 부엉이, 번개를 떨어뜨리는 먹구름, 그리고 시도 때도 없이 튀어나오는 애벌레 등이다. 아이템으로 칼과 활이 있는데 이건 점수만을 줄 뿐 무기가 아니다. 이 게임엔 주인공에게 무기를 사용한 공격은 없으며 단지 사과를 떨어뜨리고 굴려서 적을 없애는 시스템만이 존재한다.

끝도 없이 높이 솟은 나무 위에 성이 있는 게 '재크와 콩나무' 동화 같은 느낌이 든다.

Posted by 사무엘

2015/01/27 08:26 2015/01/27 08:26
, , ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1055

1.
비교적 최근에 알게 된 건데..
C/C++에서 default문은 굳이 case의 맨 마지막에 있지 않아도 된다. =_=;;;
그래서 case 1: .. default: ... case 2: 이런 식으로 라벨들이 따라오고 일부 항의 끝에 break까지 생략되어 있다면 생각보다 꽤 기괴한 로직을 구현할 수도 있다.

뭔가 발상의 전환이 느껴진다. 어떻게 활용 가능한지는 더 생각을 해 봐야겠다.
물론 파스칼의 case else문은 그렇지 않으며, 반드시 맨 마지막에 와야 한다.

2.
컴퓨터에서 부동소수점은 연산을 하는 게 까다로워서 하드웨어적인 도움을 진작부터 받아 왔다. 하지만 연산뿐만 아니라 이미 있는 수를 10진법 형태의 문자열로 나타내거나 문자열로부터 역변환하는 것도 생각보다 몹시 어렵다. 에니악 같은 초창기 컴퓨터가 괜히 굉장한 비효율을 감수하고라도 10진법 기반으로 설계되었던 게 아닌가 싶다.

이와 관련된 정보는 printing float numbers 같은 키워드로 구글링을 하면 얻을 수 있다.
이 작업은 어떤 f * 2^e에 대해서 f' * 10^e' <= f * 2^e < (f'+1) * 10^e'가 성립하는 최소의 f'/e'를 찾는 것인데, 결국 컴퓨터 프로세서가 기본 단위로 처리 가능한 범위를 넘는 big number 연산까지 필요할 정도라고 한다.

2진법 부동소수점은 1/2^n이 아닌 사실상 거의 모든 소수들이 순환소수로 표현되어 뒷부분이 잘린다. 0.1, 0.3 이런 소수도 컴퓨터에서 표현되는 형태는 순환소수라는 뜻이다. 순환소수를 화면에 출력할 때는 그래도 10진법 유한소수인 것처럼 표시하는 것이니 컴퓨터에서 부동소수점은 본질적으로 100% 정확한 정밀도가 보장되지 않는 셈이다.

3.
Visual C++ 201x는 200x에 비해서 매우 강력해진 인텔리센스, 새로 디자인된 IDE, C++1x 언어 기능 같은 게 부각되는 편이다. 하지만 그것 말고도 IDE가 매우 편리해진 면모가 최소한 둘 있는데...
이제 IDE의 버전이 올라갈 때마다 프로젝트 파일을 매번 강제로 업그레이드 하지 않아도 되고, 그리고 컴파일러 툴킷을 직접 고를 수 있게 된 점이다.

이로써 IDE가 개별 프로젝트나 빌드 툴과는 좀 더 독립한 구도가 됐다.
이것은 딱히 새로운 기능 추가가 아님에도 불구하고 옛날에 도스 시절에 멀티부팅 기능이 추가된 것만큼이나 매우 편리해진 조치이다. (autoexec.bat / config.sys에 일종의 조건부 실행 로직을 추가하여, 부팅 configuration을 직접 고를 수 있는 것)

4.
본인은 예전에 precompiled header에 대해서 글을 쓴 적이 있다. 그때에도 언급했지만, 본인은 성질이 좀 급한 관계로 PCH 없이 소스 코드가 엄청난 분량의 인클루드 반복 때문에 컴파일 속도가 굼뜨는 걸 못 참는다.
그런데, 프로젝트 전체를 분석하면서 중복 인클루드로 판단되는 파일들을 자동으로 감지해 주는 기능이 있으면 좋지 않을까? 그것들을 stdafx.h로 대체하고 그 파일에다가 인클루드들을 몰아 넣는 것이다. 물론, 빈번하게 인클루드되긴 하지만 수정도 빈번하게 되는 편이기 때문에 pch에다 넣어서는 안 되는 것 판단은 사람이 하면 된다.

이건 마치 데이터베이스에서 테이블과 쿼리들을 분석하면서 자주 쓰이는 테이블 내지 애트리뷰트는 인덱스를 넣는 최적화 기능과 비슷한 구석이 있는 것 같다.

5.
자동차의 특성이 컴퓨터 소프트웨어의 특성과 매우 비슷하다고 여겨지는 점이 몇 가지 있다.

  • 내릴 때 실내등이나 각종 라이트가 완전히 꺼졌는지 확인하고, 블랙박스는 장시간 주차시 자체 전원 차단 기능이 켜져 있는지 확인해야 한다. → 메모리 leak 예방과 개념적으로 일치한다.
  • 급발진: 아주 희귀한 상황에서 갑자기 발생하는 치명적인 버그에 해당한다.
  • 자동 vs 수동 변속기: 옛날이라면 컴파일러가 자동 생성한 코드 vs 수제 어셈블리 코드.. 정도와 대응하고, 지금이라면 managed vs native 코드와 대응하는 듯하다. 요즘은 자동 변속기도 어지간한 수동 조작에 뒤쳐지지 않을 정도로 효율이 굉장히 좋아졌으니 말이다.

6.
세상에는 분야를 불문하고 여러 단체가 공동으로 뭔가 통합 작품이나 프로토콜을 만드는 경우가 있다. 따지고 보면 킹 제임스 성경도 성공회와 청교도가 연합해서 작업한 그런 통합 작품이다.
하지만 그런 통합 작품이 실질적인 통합을 이루지 못하고 그냥 기여를 가장 많이 한 단체의 전유물로 전락해 버리는 경우도 있다. 그런 예를 몇 가지 들어 보자면 다음과 같다.

  • HFT 통합 글꼴: 지금은 아래아한글밖에 안 쓰는 완전 옛날 유물이 됐다.
  • 공동번역 성서: 에큐메니컬 성경이라지만 현실은 역시 천주교 전용 성경일 뿐이다.
  • 타이젠 OS: 당초 취지와는 달리, 컨소시엄을 구성하던 협력사들은 다 빠져나가고, 사실상 삼성 전자밖에 관심이 없는 모바일 OS가 됐다.

삼성은 예전에도 아래아한글과 MS 워드가 뻔히 있음에도 불구하고 수익성과는 별개로 훈민정음을 오랫동안 밀었다.
그런 것처럼 모바일 OS 하나 정도는 우리가 자체 기술을 갖고 있어야 한다는 차원에서 타이젠을 꾸준히 미는 듯하다. 안드로이드와 iOS의 텃새에도 불구하고 정말 막대한 자금을 투자하여 타이젠 앱 프로그래머를 육성하는 중이다.

7.
비주얼 C++이 컴파일러, IDE, 디버거 등 모든 차원에서 64비트를 완벽하게 자체 지원하기 시작한 건 2005부터이다.
그런데 나는 그 시절부터 굉장히 궁금했던 게...
devenv IDE는 예나 지금이나 32비트 프로그램임에도 불구하고 어떻게 64비트 바이너리를 아무 제약 없이 바로 디버깅 하고 메모리 내부를 잘도 들여다볼 수 있느냐 하는 것이었다.

운영체제 차원에서 64비트와 32비트가 서로 얼마나 격리되어 있는지는 이 바닥에 짬밥깨나 있는 프로그래머라면 누구나 잘 알 테고. 그러니 결론은 하나. 별도의 64비트 EXE를 띄워서 IPC(프로세스 간 통신)를 하지 않고서는 이 정도의 자연스러운 연계는 절대 가능하지 않다는 것이었다.

확인해 보니 이 예상이 맞는 듯하다. 32비트 프로그램을 디버깅 할 때는 안 그러는데 64비트 프로그램을 디버깅 할 때는 msvsmon이라는 일종의 64비트짜리 원격 디버그 호스트 프로그램이 같이 뜬다. 그리고 디버깅이 끝나면 얘도 실행이 종료된다. EXE 크기가 수MB에 달하는 결코 작지 않은 프로그램이긴 한데, 얘가 뭔가 하는 일이 많은 것 같다.

8.
끝으로.. 시간 복잡도, 공간 복잡도라고 하면 전산학에서나 다루는 무슨 뜬구름 잡는 개념처럼 들리기 쉬운데, 현실에서도 의외로 간단한 예가 있다.

먼저, 자전거를 잠그는 자물쇠로는 열쇠 방식이 있고 숫자 다이얼 방식이 있다.
전자는 열쇠만 있으면 금방 자물쇠를 딸 수 있다. 후자는 번거로운 열쇠를 챙기지 않아도 되지만 원하는 숫자까지 다이얼을 맞추고, 다시 잠김 모드로 옮기는 시간이 오래 걸린다.

나는 프로그래머로서 이걸 경험할 때마다 시간/공간의 tradeoff라는 생각이 들곤 한다. 열쇠 자물쇠는 열쇠라는 공간이 필요하고 열쇠를 분실하지 않게 주머니 관리를 잘 해야 하지만, 열고 잠그는 건 배열 테이블을 참조하듯이 O(1) 시간 만에 즉시 끝낸다.
숫자 자물쇠는 열쇠가 없어도 되어 심리적으로 편하지만, 다이얼을 맞추기 위해 마치 매번 탐색을 하고 연결 리스트의 노드를 찾듯이 O(n) 시간 작업을 매번 해야 하기 때문이다.

옛날에 브라운관 모니터가 어느 수준 이상의 대형화가 도저히 불가능하고 LCD 모니터에 밀려 도태한 주 이유가..
바로 화면 크기 n에 따른 공간 복잡도가 O(n^3)이나 되었기 때문이다. 무게나 가격까지 그 정도로 급격하게 증가했고.
색감이 좋다고는 하지만, 그래도 전자총을 뒤에서 화면 크기만큼이나 거리를 두고 쏴 줘야 하니, 화면의 크기가 커질수록 어마어마한 양의 공간을 잡아먹는 것을 감당할 수가 없었다.

그리고 지구본(지구의)도 생각난다.
알 만한 분들은 이미 다 아시겠지만, 메르카토르 도법 평면 지도에는 아프리카 대륙은 실제보다 굉장히 작게 나오고, 그린란드 내지 러시아는 말도 안 되게 면적이 부풀려져 있다.

왜곡 없이 둥근 지구 위에서 세계 각국의 위치에 대한 실질적인 공간 감각을 키우는 데는 지구본 만한 게 없다. 그리고 지구본이 비치된 책상 앞에서 누가 머리 싸매고 있으면 왠지 간지 나고 멋있어 보이기도 하나..

지구본 얘도 크기에 따른 공간 복잡도가 O(n^3)인 부피를 차지하는 물건이고, 안 쓸 때 딱히 접거나 분해해서 부피를 축소시키는 방법도 여의치 않다 보니 실용성이 떨어진다.
현실적으로는 입체 효과까지 지원하는 구글 어스 같은 지도 어플이 대안이지만.. 그래도 이런 건 실물이 아쉽기도 하다. (어플은 여러 사람이 한 지구의 여러 지점을 한데 공유하면서 서로 비교할 수 없음)

다시 프로그래밍 얘기로 돌아오자면, 현실에서는 단순무식한 알고리즘이 O(n^2) 정도의 복잡도가 나오는 게 약간 머리를 굴림으로써 O(n log n) 정도로 최적화되는 경우가 많은 듯하다. 정렬이 대표적인 예이고, 그 외에도 빠른 푸리에 변환이라든가 최장 증가 수열 찾기 문제도 이런 범주에 속한다.

그리고 단순무식하게 접근했을 때 지수함수 복잡도가 되는 게, 다이나믹 프로그래밍으로 중간 계산 결과를 저장함으로써 메모리 복잡도 O(n^2), 시간 복잡도 O(n^2) 내지 O(n^3)이 되는 경우가 많다.
아예 O(n)으로 간단하게 줄어드는 건 피보나치 수열이나 팩토리얼을 구하는 것처럼 문제 자체가 극도로 단순한 경우밖에 없을 것이다.

Posted by 사무엘

2014/11/19 08:22 2014/11/19 08:22
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1030

지금이야 고등학생이 스마트폰 앱을 뚝딱 만들고 안드로이드나 애플 사의 앱스토어에다 등록하는 소프트웨어 유통망까지 확립된 시대이다. 하지만 지금으로부터 20여 년 전에는 개인이 만든 소위 '공개 소프트웨어'라는 것들이 PC 통신을 통해 배포되곤 했다. 게임, 업무 등 분야도 엄청 많았으며, 이거 하나로 스타 개발자로 유명세 타는 사람 역시 응당 있었다.

개발자들 중엔 대학생이 많았다. 도움말이나 리드미 파일을 보면, PC 통신 ID뿐만 아니라 개발자 자신의 소속 학교, 학과, 학번(연도만)까지 밝히곤 했다. 그들은 지금은 다 어디서 뭘 하고 있을까?
더 어린 중· 고등학생이 그 정도 퀄리티의 도스용 프로그램을 만들기엔 리소스도 부족하고 컴퓨터에 대한 인식이 부족했으며 기계값이 아직 너무 비쌌다. 하물며 Windows용 프로그램을 만들려면 더 좋은 컴퓨터에 더 비싼 개발 환경이 필요했을 테고.

국내 개발자들은 당연히 자기 프로그램의 UI를 한국어로 만들었다.
그리고 세월이 흐르면서 프로그램들은 아무리 간단하고 작은 규모라 해도, 한글 바이오스에 의존하는 텍스트 모드보다는 그래픽 모드에서 '자체 한글' 기반으로 동작하는 경우가 많아졌다.
이때 자연스럽게 필요해지는 것은 그래픽 모드에서 한글을 찍어 주고 때로는 입력까지 처리해 주는 일명 '한글 라이브러리'이다.

옛날에 도스 시절에 자체 한글을 구현한 라이브러리를 만들어서 PC통신으로 뿌리고 잡지에 강좌를 올리고 책도 쓰며 유명세 타던 프로그래머들은 굉장히 날고 기는 수재들이었다.
아예 게임을 만드는 급까지는 아니더라도 나름 VGA 그래픽 하드웨어를 제어하고 여러 래스터 그래픽 알고리즘을 최적화된 어셈블리어 코드로 직접 짜는 건 쉬운 일이 아니었다. 또한 한글 입력 오토마타를 깔끔하게 짜는 것도 아무나 선뜻 할 수 있는 난이도는 아니었다(특히 두벌식은 더 어려움).

그래서 공개 소프트웨어 리드미의 '감사의 글'(acknowledgements)을 보면, “본 프로그램은 이런 한글 라이브러리를 사용하였으며, 우수한 미들웨어를 무료로 공개해 주신 누구누구에게 감사합니다” 같은 문구도 심심찮게 볼 수 있었다.

열악한 환경의 특성상, 그 시절에 한글 라이브러리는 사실상 그래픽 라이브러리나 마찬가지였다. 그리고 더 나아가면 마우스에 간단한 대화상자까지 제공하는 통합 GUI 라이브러리로 발전하곤 했다.

아래아한글의 개발사로 유명한 한글과컴퓨터 사에서는 아무래도 저런 기술의 본좌이었을 테니, 1991년엔가 <컴퓨터 속의 한글>이라는 책을 출간했다. 싸제 한글 라이브러리를 개발한 많은 프로그래머들이 이 책을 참고하여 터를 닦은 뒤, 자기만의 살을 붙이고 자신만의 방식으로 API를 설계해서 물건을 만들었다.

회사가 아닌 개인 자격으로는 PC 통신 시절에 '터보이빨'이라는 닉으로 유명하던 임 인건 씨가 있다. 이분은 그 이름도 유명한 '한라프로'라는 걸출한 물건을 개발하여 상업용으로 판매도 했으며, 아마 서울대 기계공학과 재학 시절에 터보 C 정복이라고 책도 하나 썼다. 본인 역시 아래아한글 1.x로 편집· 조판되어 있던 이 고전을 읽으면서 C언어 기초를 닦았었다.

어디 그 뿐이랴? 지금까지도 인터넷 검색을 하면 굴러다니는 '프로그래머 십계명'이라는 글도 저분 작품이다.
이 정도면 저분은 거의 프로급 소프트웨어 엔지니어 같은데... 프로필을 보면 알 수 있듯 저분은 프로그래밍이 본업이 아니다. 훗날 저분은 같은 학교에서 박사까지 마친 뒤, 업계에서 고급 엔지니어 경력을 쌓다가 지금은 '성진 C&C'라고 금속, 재료 쪽 중소기업의 부사장 자리에 올랐다.

그리고 또 '한라프로'와 더불어 한글 라이브러리의 양대 산맥이던 물건으로는 '허르미'가 있는데, 이걸 개발한 분은 한 우진 씨이다. 국내의 유명 철덕인 한 우진 씨(미래철도 DB)와는 동명이인임.

저분 역시 물건만 만들어 공개하고 끝이 아니라, 한글을 구현하는 기술 디테일을 친절하게 저술까지 해서 이름을 날렸다. 그리고 카이스트 전산학과에서 학, 석, 박을 마치면서 멀티미디어 데이터 압축 알고리즘 쪽 전문가가 되었다. 졸업 후엔 삼성 전자에서 몇 년 근무하다가 나중에는 가천 대학교 교수로 부임했다.

다들 왜 저렇게 똑똑한 거야..;;; ㅜㅜ
후대에 등장한 많은 한글 출력 라이브러리들은 한컴 사의 책이든, 위의 두 제품의 영향을 어떤 형태로든 받았다고 생각하면 된다. 1990년대 중반 이후에 만들어진 것들은 시대의 흐름답게 슈퍼 VGA를 지원하고 32비트 환경(Watcom C/C++ 내지 DJGPP)을 지원하는 식의 발전이 이뤄지기도 했다.

저런 선구자들에 비해, 본인은 도스 시절이 다 끝난 뒤에야 한글 관련 솔루션의 개발에 입문했다. 하드웨어 제어나 그래픽 알고리즘, GUI 따위를 자체 구현할 필요는 전혀 없고 내 입력기는 그렇다고 자동 완성, 상용구, 속기 같은 NLP/lexicon 기반요소가 등장하는 것도 전혀 아닌데 도대체 이 바닥에서 무슨 일을 한 걸까?

그런 것들이 없는 대신에 내 프로그램은 그야말로 한글을 자모 단위로 조작하는 기본 동작에만 초인적인 집중과 최적화를 했으며, 온갖 똘끼 넘치는 아이디어들을 구현하게 됐다.

아울러, 내 프로그램은 다른 건 몰라도 자체 편집기에서 도스 시절의 비트맵 글꼴을 출력하는 루틴만은 여전히 답습하고 있다. 옛날 추억과 한글 프로그래밍 정신 계승(?), 그리고 기술적으로는 한글 조합 자모나 옛한글 표현 같은 여러가지 이유 때문이다.
이건 한글을 가장 가볍고 단순하게, 마치 컴퓨터 속의 기계식 타자기처럼 원시적으로 출력해 주는 시스템이라는 상징적인 의미가 크다.

본인은 지금은 타자기 시절이나 도스 시절과는 다른 차원의 한글 프로그래밍이 여전히 필요하다고 생각하며, 심지어 한국어를 개입시키지 않더라도 한글 자체에 대한 엔지니어링이 연구할 여지가 있다고 생각한다. <날개셋> 한글 입력기의 개발을 다 마치고, 가까운 미래에 박사까지 다 마치고 20년쯤 뒤 먼 미래엔 뭘 하고 있을까? 한글 가지고 더 창의적으로 먹고 살 거리가 없으면 진짜로 철도로 업종 전환할지 알 수 없는 노릇이다. ㅎㅎ

Posted by 사무엘

2014/09/09 08:30 2014/09/09 08:30
, , , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1005

캡챠 이야기

요 근래부터 이 블로그에도 국내외 광고 스팸 댓글이 급증하고 있어서 대책이 좀 필요한 것 같다.
옛날에는 외국 발 스팸 트랙백이 아주 가끔 걸리는 듯했는데 요즘은 트랙백은 없고 그냥 닥치고 쓰레기 댓글뿐이다.
일단 영어만 들어있는 텍스트는 무조건 차단하고, 요주의 키워드와 IP는 블랙리스트로 등록해 추가로 차단하고 있는데도 가끔은 그런 필터를 통과한 놈들이 게시되곤 한다. 그런 건 내가 보이는 족족 수동으로 제거하는 중이다.

옛날에 제로보드 시절엔 비로그인 사용자가 댓글/답변을 올릴 때 캡챠를 입력하게 하는 플러그인 내지 소스 추가 패키지가 있어서 본인 역시 제로보드 게시판을 운영할 땐 그걸 유용하게 썼었다. PHP 코드만 돌아가는 게 아니라 리눅스용 실행 파일이 서버에서 실행되어 캡챠 이미지(PNG)를 실시간으로 생성해 냈다.
TextCube용으로도 그런 플러그인이 없을 리는 없겠지. 조만간 도입해야 할지도 모르겠다.

여기서 캡챠란 무엇인지 모르시는 분을 위해 설명하자면..
사용자가 서버로 보내는 게시물 내지 회원가입 신청이 봇/매크로/오토 같은 컴퓨터가 생성한 게 아니라 진짜 사람이 하는 게 맞음을 입증하기 위해, 사람만이 판독할 수 있게 비비 꼬아 놓은 랜덤하고 이상한 글자· 그림이 의미하는 값을 입력받는 인증 장치를 말한다.
gotcha!와 비슷한 어감 때문에 좀 얍삽하다는 심상이 느껴지는데, CAPTCHA는 나름 영단어 이니셜이다.

기계가 인식할 수 없는 이미지를 기계가 생성해 낼 수 있을까?
패턴인식 기술의 발달로 인해 어지간히 허술한 캡챠를 기계가 인식하여 뚫는 기술도 발달하고, 그에 맞서.. 진짜 사람조차 인식 못 할 정도로 난해하지 않으면서 적당히 기계만 엿먹이기에 충분할 정도로 어려운 캡챠를 생성하는 기술을 개발하는 것도 만만찮은 수준이다.

(첨언하자면, 오늘날은 무질서로부터 질서를 도로 찾아서 복구하는 기술이 매우 경이로운 수준이다.
물리적으로 어지간히 손상을 준 하드디스크로부터도 최대한 데이터를 복구해 낸다거나, 심각하게 BLUR된 이미지로부터도 놀라울 수준으로 원래 이미지를 복원한다거나. 캡챠를 뚫는 것도 그런 맥락에서 살펴볼 수 있을 듯하다.)

도스 시절에 '맥스'라는 유사 채팅 프로그램이 있었는데 혹시 기억하는 분 계시는지?
얼굴이 안 보이는 공간에서 어떤 사람이 상대방과 채팅을 했는데, 대화 상대가 패턴이 뻔한 '봇'이 아니라 진짜 사람이 맞는지를 같은 사람이 분간할 수 없었다면 그 대화를 생성한 AI는 '튜링 테스트'를 통과했다고 간주된다.
그런데 캡챠는 역으로 컴퓨터가 이 입력이 진짜 사람이 맞는지를 판단하는 것이므로, 일종의 '역방향 튜링 테스트'에 가까운 셈이다.

스팸 게시물을 막기 위해 도박, 성 등 여러 불건전한 분야의 금지어들을 지정해 놓은 게시판이 많다.
그런데 게시물에 금지어가 우연히 포함되었다고 해서 아무 설명도 없이 없이 글의 등록을 거부하면..
진짜 사람이 그런 거부를 당했을 때 그 사람을 굉장히 화나게 만들 수 있다.

또한 반대로 'xxx는 금지어입니다'라고 매번 친절하게 알려 주면.. 스패머들은 그 피드백 결과를 바탕으로 금지어만 교묘하게 피해가는 스팸 게시물을 만들어 뿌리게 된다. 이 역시 딜레마다.

따라서 둘을 절충하는 방법으로는...
일단은 캡챠 같은 거 없이 깔끔하게 글을 접수한 뒤,
본문이 금지어가 포함돼 있거나 특정 패턴을 만족하여 광고글로 의심되면... 그때는 금지어 같은 광고글 의심 판정 근거를 노출하는 대신, 가만히 캡챠만 좀 입력해 보라고 friendly하게 추가 요청을 하는 게 바람직하지 않은가 싶다. 한 마디로 말해 선패턴 후캡챠 전략인 것이다.

그게 익명 사용자에게 당장 깔끔한 첫인상을 주며,
사용자가 댓글을 올리지 않고 그냥 글을 읽기만 하는데도 복잡한 이미지 프로세싱이 필요한 캡챠를 매번 생성하는 것보다 서버 부담도 줄이는 일거양득 방법일 것이다.

특정 패턴이란 굳이 단어가 아니어도 되고 NLP 기술이 아니어도 된다. 지나치게 URL 링크가 많은 글, 특수문자가 한글과 너무 지저분하게 뒤죽박죽 섞여 있는 글만 찾아도 된다. 이 정도만 돼도 스패머가 제아무리 금지어 필터를 피하려고 잔머리를 굴린들 광고글 따위는 모조리 걸러낼 수 있다.

사이버 공간에서 이런 광고 댓글 스패머는 국제 민폐요 인터넷 트래픽을 좀먹는 공해덩어리 떨거지들이다.
하지만 겨우 얘네들 때문에 게시판을 회원만 글을 올릴 수 있게 바꾼다거나, 심지어 누가 올려 놓은 글은 관리자가 일일이 사전 검열(?)한 뒤에야 공개 게시한다거나 하는 건.. 빈대 잡으려다 초가삼간 다 불태우는 수준의 극단적인 짓일 것이다. 아무쪼록 인간과 기계의 경계를 허물기도 하고 강화하기도 하는 기술의 발달이 절실하다.

이미 널리 알려져 있기도 하겠지만, 캡챠로부터 유래된 재미있는 발상이 있다.
포털 사이트 같은 델 가입할 때, OCR 프로그램이 제대로 인식하지 못한 어떤 책 스캔 이미지 조각에 든 문자열을 캡챠하고 같이 입력하게 한다. 그래서 캡챠를 맞게 입력한 여러 사람들이 동일한 이미지 조각에 대해 일치하는 문자열을 입력했다면, 그 이미지에 담긴 텍스트는 그게 맞다고 데이터를 수집하는 것이다.

캡챠 타이핑과 동시에 real-world 캡챠도 같이 타이핑하여 전세계 네티즌들이 힘을 합쳐 문헌의 전산화(?)에 기여하게 하는 것이다. 일명 '리캡챠 프로젝트'라고 한다. 구글, 페이스북, 아마존 등 세계 유수의 사이트들이 리캡챠 엔진을 활용 중이라고 한다.

Posted by 사무엘

2014/08/16 08:22 2014/08/16 08:22
, ,
Response
No Trackback , 7 Comments
RSS :
http://moogi.new21.org/tc/rss/response/996

가끔은 컴퓨터라는 물건이 발명된 지가 아직 100년도 채 안 됐다는 게 도저히 믿어지지 않을 때가 있다. 세상을 이렇게 완전히 180도 뒤바꿔 놓은 기계가 역사가 그렇게도 짧다니! 그 내력이 최소한 전화기나 자동차의 역사 정도는 될 법도 해 보이지만 실제로는 그렇지 않다. 하긴, 텔레비전이 컴퓨터보다 약간 더 일찍 발명된 정도다.

오늘날의 컴퓨터와 비슷한 컨셉이라도 탑재된 물건이 최초로 등장한 시기는 아무리 일찍 잡아도 2차 세계 대전 이후이다. 전자식+2진법+튜링 완전+프로그램 내장형 같은 기본 중의 기본 단서만 추가해 줘도 시기는 더 늦어진다. 그리고 그것마저도 덩치와 성능은 오늘날 우리가 쓰는 노트북과 스마트폰하고는 차마 비할 바가 못 됨은 주지의 사실이다.

컴퓨터가 2차 세계 대전 이후의 산물이라는 건, 다시 말해 단군의 후손들이 역사상 컴퓨터라는 걸 접한 시기는 오로지 '대한민국' 시대가 유일하다는 뜻이다. 일제 강점기나 조선 시대엔 그런 거 없었다. 그러니, 세계의 컴퓨터 역사뿐만 아니라 그 컴퓨터를 처음으로 우리나라에 도입하고 전산망을 개설한 선구자들의 전설의 레전드를 공부해 보는 것도 전산/컴공 전공자이든 비전공자이든 흥미로운 경험이 될 것이다.

우리나라에는 이 분야의 거장으로 성 기수 박사(1934-), 전 길남 박사(1943-)가 있다. 난 성 박사는 고등학교 때 어느 인터넷 사이트를 통해 아주 아주 대단한 분이라고 우연히 알게 됐다. 전 박사는 알지도 못하다가 대학에 진학해서야 내가 다니는 학교의 학과에 소속돼 있는 만렙 명예교수 중의 한 분 정도로나 접하게 됐다.

두 분 다 업적이 워낙 전문적이고 비가시적인 곳에 있는지라 대중적으로 유명하지는 않다. (2011년 10월에 1주일 간격으로 나란히 세상을 떠났음에도 불구하고 스티브 잡스와 데니스 리치의 대외 인지도의 차이를 생각해 볼 것!)
그러나 굳이 따지자면 아무래도 전자보다는 후자가 약간 더 유명하다. 우리나라 인터넷의 아버지라고 최근에 웹툰도 올라왔고 이게 각종 SNS에 퍼날라지면서 반짝 뜨곤 했다. 독자 여러분에게도 일독을 권한다.

(1982년 5월 15일, 구미 전자 기술 연구소와 서울 대학교 사이에 국내 최초 원거리 컴퓨터 네트워크 교신에 성공. 이건 모뎀이냐 랜이냐 뭐냐? 무슨 물리 메커니즘으로? 으음...;;)

저분은 은퇴한 뒤에도 활발히 활동하고 계시고, 게다가 저 웹툰을 보고는 작가에게 고증 오류 피드백까지 친절하게 해 주셨다고 한다. 여담이지만, 저분의 배우자가 여성 운동가인 조한 혜정 교수라니 깜짝 놀랐다.

최근의 강연 내지 인터뷰에서 전 박사는 인터넷은 너무나 대중적으로 퍼진 만큼 앞으로는 좀 더 안전해져야 한다고 거듭 강조한 적이 있다. 안티바이러스 프로그램의 개발자로 유명한 카스퍼스키는 강력한 인터넷 규제와 신원 확인에 찬성하는 의견을 피력하는 사람인데 그것과도 비슷한 맥락인가 싶었다. 초창기에 인터넷의 각종 규격을 설계했던 엔지니어들은 이 비싼 통신 인프라가 어중이떠중이가 다 쓰는 보편적인 물건이 될 거라고는 감히 생각을 못 했었을 것이다. 그러니 보안보다는 성능과 효율을 훨씬 더 중요하게 생각할 수밖에 없었겠지.

난 전산학의 여러 분야 중에서도 네트워크, 보안 쪽은 제일 까막눈 문외한이다 보니..;; 저런 분을 보면 그냥 입 쩍 벌리고 대단하다는 말밖에 안 나온다.

그럼, 다음으로 성 기수 박사 얘기를 좀 하겠다.
이분도 완전 날고 기는 수재였으며 하버드 대학교에서 석· 박사를 3년 만에 뚝딱 마친 것은 오늘날까지도 유학생들 사이에 전설로 회자된다고 그런다. 원래 전공은 기계· 항공 공학 쪽이었으며 전자· 전산이 아니었다. NASA 같은 데에나 들어가서 우주선과 로켓 엔지니어가 됐을 분이 “아무래도 우리나라엔 컴퓨터가 필요하다”는 신념 하에 한국으로 돌아와 KIST 전산실 실장을 맡았다.

전 길남 박사가 라우터 등 인터넷 기술을 자체 개발하여 우리나라를 인터넷 대열에 합류시켰다면, 성 기수 박사는 그보다 옛날에 우리나라의 행정, 은행, 병원, 철도 등 각 분야의 시스템 전산화를 이끌었다. 전산학이라는 학문이 국내 학계에 제대로 정립조차 되기 전인 초창기에 하드웨어와 소프트웨어를 넘나들며 우리나라의 발전에 지대한 업적을 남긴 것이다. 워낙 옛날이기 때문에 구분이 별로 의미가 없었을지도 모르지만, 저분의 세부 관심사는 HW와 SW 중 어디에 가까웠을지가 궁금해진다.

2000년대 초반에 바둑 연구를 끝으로, 그 뒤부터는 저분은 언론에 보도되는 근황은 없이 조용히 노후를 보내고 계신 듯하다.

인터넷 검색을 하면 성 박사의 일대기를 곳곳에서 발견할 수 있다. 그런데 내 시선을 고정시키는 에피소드가 하나 있었다.
지금으로부터 40년도 더 전인 1970년, KIST 전산실에서 그의 주도하에 한글 전자 인쇄 장치를 개발해 냈다고 한다.
유니코드고 트루타입 글꼴이고 뭐고 하나도 없던 까마득한 옛날에 일종의 1세대 비스무리한 한글 기계화를 이룬 거라고 보면 되겠다.
그런데 여기서 벌써 한글 입력 방식에 대한 얘기가 나온다.

이 글을 읽을 때 유의해야 할 점은 다루는 시기가 굉장히 옛날이라는 점이고, 그럼에도 불구하고 논쟁의 대상이 흔히 생각하기 쉬운 기계식 타자기가 아니라 컴퓨터라는 점이다. 물론 시기가 시기이다 보니, 일반인이 간편하게 다룰 수 있는 오늘날의 개인용 소형 컴퓨터 얘기는 전혀 아니다. 저건 애초에 그런 범용(general-purpose) 컴퓨터도 아니다.

저 때보다 약간 전인 1969년 여름에 국가에서는 타자기용으로 네벌식 글자판을 표준으로 지정했다.
난 그 시절엔 두벌식이라는 게 전혀 없었고 그건 나중에 1980년대에 와서야 생긴 줄 알았다. 그런데 그건 아니고 그 이전부터 두벌식과 네벌식이 모두 있었던 듯하다. 사료를 모두 종합해서 고찰해 보면, 1969년에는 “타자기는 네벌식, 전자 기기는 두벌식”으로 표준이 제정됐고 나중에는 네벌식이 공식 폐기뒨 후 “기계식 타자기까지도 받침 글쇠를 넣어서 두벌식”으로 바뀐 것 같다.

또한 같은 두벌식이라 해도 그때의 두벌식은 오늘날의 '바지들고서' KSX5002 26키 배열하고는 차이가 있었을 수도 있으니까. 나의 역사 지식에 오류가 있다면 수정 지적을 환영하는 바이다.

아무튼, 성 기수 박사가 한글 전자 인쇄기를 개발하던 당시에 국가에서는 이미 네벌식과 두벌식을 밀고 있었다. 그리고 성 박사는 자신이 개발하는 기계에 들어가는 한글 입력 소프트웨어를 별다른 고민 없이 두벌식 기반으로 설계했다.
그분도 그렇게 타자기 따로, 컴퓨터 따로 식인 글자판 표준에는 문제가 있다고 판단했다. 그러나 “씁 어쩔 수 없지”였고, 그런 문제의식만으로 끝이었다.

기계식 타자기가 연극과 같다면 컴퓨터는 영화와 같은 매체이다. 기계식 타자기야 메커니즘이 복잡해서 어쩔 수 없지만, 컴퓨터에는 아무 제약이 없으니 글쇠배열은 가능한 한 간단할 수록 좋을 것이다. 자음의 초· 종성 구분은 컴퓨터 소프트웨어가 알아서 판단하게 하는 게 좋을 것이다. 사용자의 입장에서는 자동화가 되어서 좋고, 개발자의 입장에서는 오토마타 이론을 구현하면서 자신의 프로그래밍 실력을 과시할 수도 있어서 좋다..는 게, 컴퓨터쟁이가 한글 입력에 대해서 생각할 수 있는 딱 전형적인 의식 수준 그 이상도 그 이하도 아니지 않았을까?

그 시절, 공 병우 박사는 안 그래도 나라에서 자기의 세벌식 글자판을 외면한 것 때문에 심기가 불편했다. 그랬는데 마침 한글 전자 인쇄기에 네벌식 대신 두벌식 글자판이 들어간다고 하자 책임자인 성 박사를 자기 집에 초대해서 로비(?)까지 시도했다고 한다. 공 박사는 그 시절에 이미 그야말로 억만장자가 된 60대의 안과 의사였고, 성 박사는 30대 중후반으로 공 박사의 아들 연배인 파릇파릇한 공학자였다. 물론 전공은 다를지언정 두 분 다 대한민국 0.1% 이내에 드는 천재들인 건 주지의 사실이다.

공 박사는 고급 외제차를 몰고 성 박사를 데리러 홍릉 KIST를 직접 찾아갔다. 그리고 호화로운 자기 집에서 최고급 요리를 대접하면서 제안을 한 게.. “당신 같은 사람이 세벌식을 지지해 준다면 당신이 필요한 연구비는 내가 얼마든지 대 주겠소.”였다고. 여러분도 잘 아시잖는가. 공 박사는 기계덕후였으며 평생 젊은 프로그래머, 엔지니어들을 굉장히 좋아하셨다.

국가로부터 받는 예산만으로는 당장 연구실의 장비 내지 컴퓨터의 업그레이드조차 빠듯할 지경이었는데.. 그 제안에 성 박사가 귀가 솔깃해질 정도였다고 한다. 이거 뭐 “KIST에 공 병우 박사의 기증으로 슈퍼컴퓨터가 한 대 도입되었다” 같은 역사가 쓰여질 수도 있었다!

허나 설득은 잘 되지 않았던 것 같다. 공 박사의 입장에서 성 박사는 장래는 촉망되지만 한글이나 글자판에 대한 건전한(?) 소신이 없이 그냥 어용학자로 빠질 위험이 있는 인재로 보였을 것이다. 그리고 성 박사의 입장에서 공 박사는 그냥 자기 발명품만 꽉 껴안고 놓을 생각을 안 하는 고집쟁이 타자기 덕후로만 보였을 것이다. 늘어놓는 이야기가 서로 핀트가 안 맞았다.

성 박사는 공 박사로부터 융숭한 대접을 받고 세벌식 한영 타자기를 한 대 선물로까지 받았지만, 세벌식 같은 덴 애착이 별로 안 갔으며 그건 곧 그걸 갖고 싶어하는 다른 후배에게 줘 버렸다고 한다. 그리고 두 '박사'간의 만남은 그걸로 끝이었다. 저 사이트의 글도 “성 기수의 결정은 결과적으로 반공병우파의 손을 들어 준 셈이 되어 버렸다.”라고 씁쓸하게 끝난다.

그래. 하버드에서 3년 만에 박사 학위를 받은 공돌이라고 해도 그 옛날에 타자기와 컴퓨터의 글자판 통일 가능성을 생각할 수는 없었을 것이다. 글자판 일체형 직결식 글꼴이 항공· 기계 분야하고 관계가 있지는 않잖아.

물론 공 박사도 의사 겸 의학자일 뿐, 언어학이나 타이포그래피를 체계적으로 공부해서 그 분야에 학위가 있지는 않은 건 마찬가지다. 그러나 이 분야의 식견에 관한 한은 더 옛날부터 이 극로 선생으로부터 감화를 받아서 한글덕후로 개조가 끝나 있던 공 박사가 더 앞서 있었다. (그러고 보니 이 글에서 덕후 타이틀만 무려 3개가 나왔군.. -_-)

그럼에도 불구하고 저 사이트의 글에서는 꼭 공 박사가 성 박사를 무슨 불의한 일에 접대로 유혹하고 매수라도 하려 한 것처럼 묘사되어 있어서 좀 유감스럽다. 다른 사람들이 보면 오해하겠다.
이거 무슨... “통일교를 공인해 주면 내 사재로 IMF 빚 다 갚아 주겠다”도 아니고.. 뭐냐?

Posted by 사무엘

2014/08/13 08:35 2014/08/13 08:35
, , , , , , , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/995

노트북 PC에서 가장 흔하게 발생하는 잔고장의 양대 산맥은 (1) 액정 화면 접촉불량과 (2) 키캡 빠짐이라 해도 과언이 아닐 것이다.

본인이 개인용 노트북 PC를 사용한 지가 15년이 넘었고 지금 쓰는 맥북은 제 5대 컴퓨터인데,
예전에 쓰던 노트북들은 쓴 지 1년 남짓 되면 저런 잔고장이 어김없이 발생하곤 했다.
물론, 언제나 새 노트북만 쓴 게 아니라 중고나 준중고를 쓴 것도 있기 때문에, 품질이 원래부터 안 좋아서 그랬던 것일 수도 있다.

(1)은 화면을 편 각도에 따라서 붉은 세로줄이 나타났다가 사라진다거나, 화면이 아예 꺼진다거나 하는 등 굉장히 성가신 증상이다. 이것 때문에 서비스센터 들러서 수리 받느라 신경 쓰이고 시간· 돈이 낭비되는 것도 과거엔 상당한 수준이었다.

(2)도 노트북 키보드가 데스크톱 PC 키보드보다 약해서 발생하는 고질적인 문제인 듯.
자주 누르는 편인 화살표, 엔터, space, shift 같은 게 잘 빠졌으며 가끔은 문자 키가 빠지기도 했다. 키캡이 없어도 해당 키를 누르는 것 자체는 가능하지만, 빠른 타자와 원활한 컴퓨터 사용에는 애로사항이 꽃핀다.
빠진 키캡 한두 곳만 수리가 되지는 않는 경우가 많다. 그래서 키캡이 대여섯 개쯤 빠질 때까지 컴을 더 쓰다가, 나중에 한꺼번에 키보드 기판을 교체하곤 했던 것 같다. 돈 몇만 원 정도는 깨진다.

그런데.. 지금 쓰는 맥북은.. 쓴 지 2년이 넘었지만. 위의 잔고장이 지금까지 전혀 발생한 적이 없다. 엔터 키가 약~간 달랑달랑거리긴 하지만 그래도 키캡이 완전히 빠진 건 없다. 잡느님의 손길이 담긴 품질 덕분인 걸까? 놀랍다.
맥북은 한번 병원 치료를 받으면 일반 놋붉에 비해 수리비가 작살나게 깨진다는 게 겁나긴 했었지만, 아직까지 A/S를 받을 일 자체가 전혀 없었다.
(참고로 난.. 흔들리는 교통수단 안에서도 쓰고 몇 번 떨어뜨린 적도 있고, 노트북 PC를 시도 때도 없이 험악하게 혹시시키며 쓰는 편이다.)

따라서 애플케어를 구입 안 한 게 현재로서는 결과적으로 이익이었다.
난 비록 맥북으로도 95% 이상의 시간은 맥OS가 아닌 Windows만 쓰며 지내지만 맥북의 이런 품질은 만족스러우며 인정할 만하다.

다만, 세월 때문인지 배터리 용량은 예전보다 확실히 줄어들었다. 2시간 남짓이면 간당간당하다. 배터리는 아직 구경도 못 해 봤다.
그리고 얼마 전엔 맥북을 쓴 지 2년 3개월 만에 처음으로 기능 고장을 경험했다. 본체나 LCD 쪽은 아니고, 전원 어댑터가 문제가 발생했다.

여기저기서 전선의 피복이 슬슬 벗겨지면서 속의 금속선들이 드러나 보이기 시작했다. 벗겨진 부분에다가는 테이프를 감았으며, 노출 부위 때문에 감전이나 화재 사고가 날까 두려워서 잘 때나 부재 중일 때는 전원 플러그를 빼 두기 시작했다.
그러더니 나중엔 컴퓨터 본체와 연결하는 목덜미 부분이 너무 너덜너덜해진 나머지 거의 두 동강 나다시피하면서 결국 단선됐다. 전원을 연결해도 본체에 전원 공급이 되지 않기 시작했다. 컴퓨터 본체는 이제 2시간짜리 시한부 인생으로 전락했다.

어댑터 전선에 피복이 벗겨지면서 고장이 이런 식으로 발생하는 노트북 컴은 맥북이 처음이다. 그런데 다른 맥북/아이폰 사용자에게 물어 보니, 애플 제품은 그런 식으로 전원 어댑터 내지 충전기가 망가지는 건 생각보다 흔한 일이라고 한다.

어댑터 자체는 이상이 없고 전선만 망가진 건데 어째 물건을 재활용할 수는 없나 궁금하다. 물론, 콘센트 쪽 전선이 아니라 컴퓨터에다 꽂는 쪽의 전선이다 보니 어댑터와 분리가 가능하지도 않고 가능하지는 않을 것 같다.

지금은 어댑터를 새로 구입해서 상황을 마무리 지었지만, 약 3~4일 동안 내 컴을 못 쓰면서 좀 불편하게 시간을 보냈다. 다음부터는 좀 불편하더라도 컴퓨터 본체와 어댑터 선이 언제나 같은 높이와 평행한 각도가 유지되게 해 놓고 써야겠다. 목덜미 부근엔 수축 튜브를 감아 주고, 전선을 둘둘 감아서 가방에 넣는 것도 굉장히 조심해서 해야 할 것 같다.

* 다음은 여담.

1. 맥 OS가 의외로 굉장히 유용한 경우가 있는 걸 본인이 얘기한 적이 있나 모르겠다. 바로 학교 안에서이다.
Windows의 경우 컴퓨터의 속도를 한 반쯤 깎아내리는 엄청난 백신, 보안 솔루션 등을 강제로 설치해야만 교내 무선 인터넷 이용이 가능한 반면, 맥 OS는 그런 것 전혀 없이도 바로 인터넷 이용이 가능하기 때문이다. 아주 편리하고 좋다.

2. Windows 진영에서는 Metro라는 이름을 안 쓰는 게 마음에 안 들던데, 애플 진영에서는 매킨토시로도 모자라서 Mac이라는 이름까지 왜 빼 버렸나 궁금하다.. 자기 정체성을 가장 잘 분명하게 보여 주는 명칭을 빼 버리고 그냥 OS X...;;;

3. 그러고 보니, 플래시가 깔려 있지 않은 맥 OS의 사파리 브라우저에서 유튜브 동영상이 나오고 있어서 깜짝 놀라서 살펴봤더니.. 말로만 듣던 HTML5 기반 동영상이다. 우와~ 물론 비스타+IE9 구닥다리에서 실행해 보니 여전히 플래시다. 브라우저에 따라 기술을 알아서 판별하는 듯하다.

솔직히 플래시든 뭐든 인터넷으로부터 패킷을 받아서 하드웨어 가속으로 동영상을 틀어 준다는 기본 원리는 똑같다. 단지, 동영상을 해독하고 재생하는 기계어 코드가 예전에는 플래시 ActiveX라는 일종의 private한 영역에 있었던 반면, 이제는 그게 통일된 규격으로 웹브라우저에 있다는 차이만이 존재할 뿐이다. 웹 표준은 기술 자체가 아니라 기술을 담는 그릇의 규격에 대한 논쟁인 것이다.

Posted by 사무엘

2014/07/08 08:29 2014/07/08 08:29
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/982

유니코드 1.x가 제정되었을 때는 믿거나 말거나 한글도 글자마디는 완성형 몇천 자만 지금과는 딴판의 영역에 등록되어 있었다. 단, 글자마디뿐만 아니라 옛한글을 포함한 자모도 자음 134개(물론 초성과 종성의 개수는 서로 다르고 따로 등록됨), 모음 66개가 등록되어서 이 자모들을 아래아한글 2.x가 한컴 2바이트 코드에서 그대로 채택해서 썼다. 한컴 2바이트 코드는 기존 조합형 코드와 유니코드를 적당히 짬뽕한 문자 코드였던 것이다.

유니코드는 첫 도입 배경이 저렇다 보니 “유니코드 = all 2바이트 단일 문자 체계 = wide character 문자 체계”라고 혼동하는 사람이 적지 않다. 그러나 이는 개념적으로 올바른 관계가 아니다. 2바이트 문자 체계로만 치자면 한컴 2바이트 코드도 이에 해당하며, 윈도 이외에 유닉스 계열 OS에서는 wide character는 16비트가 아니라 32비트인 경우도 있다. 왜 32비트이냐 하면 6만 5천여 개라는 집합 크기도 시간이 흐르다 보니 부족해졌기 때문이다.

1996년에 유니코드 2.0이 제정되면서 유니코드는 오늘날 우리가 아는 유니코드와 같은 뼈대가 갖춰졌다. 한번 등록한 문자는 이제부터 재배치나 제거 없이 영구불변으로 굳히기로 했으며, 이때 현대 한글 글자마디 11172자가 순서대로 고스란히 등록되었다. 2바이트 조합형처럼 비트 연산은 못 쓰지만 그래도 테이블 없이 뺄셈과 나눗셈, 나머지 연산으로 한글의 자소 정보를 얻을 수 있으니, 과거 조합형 한글 코드의 장점을 유니코드에서도 물려받은 셈이다.

외국 위원들의 반대를 무릅쓰고 한글에다 유니코드의 금싸라기 영역을 이만치 할당 받기 위해 한국 위원회 사람들이 애를 많이 썼다. 사실 확장완성형도 유니코드 등록 근거를 대기 위해 급히 만들어진 것이라고 한다.
이와 더불어 유니코드 2.0에서는 중요한 개념 내지 꼼수가 추가로 도입되었는데, 바로 surrogate이다.
16비트 공간 중 일부 영역은 그대로 쓰지 말고 따로 떼어 내서 두 글자를 뭉쳐서 더 많은 종류의 글자를 표현하는 데 쓰자는 것이다.

0xD800부터 0xDBFF는 high surrogat이고, 0xDC00부터 0xDFFF까지는 low surrogate이다. high는 언제나 앞에, low는 언제나 뒤에 오는 식으로 역할이 딱 고정되어 있다. 1024개의 앞짝과 1024개의 뒷짝이 만나니, 총 2048개의 독립 글자를 희생하여 2의 20승, 약 100만여 개의 글자 공간을 추가로 확보할 수 있게 된다. 요컨대 유니코드에 U+D800 같은 글자는 없고, U+D7FF 다음에는 곧바로 U+E000이 이어진다. 그 대신 0xD800과 0xDC00이 만나면 U+10000이라는 surrogate, 즉 확장 평면이 시작될 뿐이다. 예전의 16비트 단일 영역은 '기본 다국어 평면'(BMP)이라고 불리게 되었다.

비록 과거의 1바이트/2바이트 혼합 체계보다는 사정이 훨씬 낫고 문자열 처리가 수월한 건 사실이지만, 어쨌든 유니코드도 확장으로 인해 2바이트 단일 표현(UCS2)이라는 깔끔한 장점은 포기해야 하게 되었다. 이쯤 되니 유니코드라는 개념에서 문자 코드와 인코딩을 구분해서 표현해야 할 필요가 생겼다.

유니코드 자체는 UCS, 즉 universal character set이라 불리는 단일 문자 집합이다. 얘는 '가'라는 한글 글자에다가 U+AC00이라는 코드값을 부여해 줄 뿐, 그 코드값이 메모리나 파일에 어떻게 표현되는지에 대해서는 규정하지 않는다. 이를 표현하는 방식이 바로 Unicode transfer format, 즉 인코딩이 된다.

모든 유니코드 번호를 아무 뒤끝 없이 32비트 정수 하나로 균일하게 표현하면 그것은 UTF32이다. 아까 wide character가 4바이트인 플랫폼은 바로 UTF32를 구현하는 자료형인 것이다. 가장 깔끔하고 공간도 넉넉하고 모든 글자를 하나씩 쉽게 접근할 수 있지만 한 글자가 4바이트나 차지하여 메모리 낭비가 심하다.

BMP 영역에 있는 놈은 종전대로 16비트 정수 하나로 표현하고 확장 평면에 있는 놈만 surrogate 두 개로 쪼개서 표현하는 방식은 UTF16이라고 불린다. UCS2를 개념적으로 확장한 것이기 때문에 처음부터 2바이트 wide character를 표방하며 개발된 Windows 플랫폼이 매우 사랑하는 방식이다. 비록 Windows의 wchar_t는 이제 유니코드 코드 포인트 하나를 온전히 표현할 수 있을 정도로 충분히 크지 못한데도 말이다.

끝으로, 그 이름도 유명한 UTF8이 있다. 얘는 U+007F 안에 드는 전통적인 알파벳· 숫자, 제어 문자들은 1바이트로 유지하고, 나머지 BMP 영역의 외국어들은 2~3바이트로 표현하고 surrogate는 BMP와 동일한 4바이트로 늘여 표현하는 진정한 multibyte 인코딩이다.

n째 문자를 찾는 무작위 접근은 안 되겠지만, Windows NT처럼 커널을 처음부터 16비트 문자 단위로 설계하지 않고도 기존 8비트 문자 시스템에서 유니코드를 단절감 없이 표현할 수 있다는 엄청난 장점이 있다. CPU의 엔디언(비트 배열 순서)의 영향을 받지 않으며, tail byte가 기존 영문· 숫자와 충돌을 일으키지도 않는다는 점도 좋고 말이다.
그래서 얘는 웹에서 매우 사랑받고 있고 윈도 이외의 플랫폼에서는 파일뿐만 아니라 메모리 저장용으로도 UTF8이 즐겨 쓰인다. 사실 윈도만 이례적으로 UTF16을 너무 사랑하고 있는 것이고.. ㅎㅎ

여담이지만 UTF32, 16, 8 중 유니코드의 문자 집합이 먼 미래에 또 확장되어야 할 때, 공간이 가장 넉넉하게 남아 있는 놈은 두 말할 나위 없이 UTF32이다. UTF8이야 애초부터 들쭉날쭉 가변 길이 인코딩을 표방했기 때문에 한 글자당 4바이트보다 더 긴 5~6바이트까지 약간 더 확장할 여지가 있다. 지금 당장은 그것까지는 쓰이지 않지만 말이다.

하지만 UTF16은 유일하게 확장의 여지가 전혀 없다. 지금 surrogate 영역이 다 차 버리면 surrogate의 surrogate라도 또 만들지 않는 이상 답이 없다. 그리고 그런 헛짓을 할 바에야 차라리 UTF16을 폐기하고 UTF8 아니면 UTF32로 갈아타는 게 낫지..;; 이런 미묘한 면모가 있다.

다만, 한글 표현의 관점에서는 메모리가 가장 적게 드는 인코딩이 UTF16이라는 것도 감안할 점이다. 현대 한글 글자마디의 경우 UTF8은 3바이트, UTF32는 4바이트이지만 UTF16은 2바이트다. 초-중-종성이 모두 갖춰진 옛한글이라면 UTF8과 UTF32는 각각 9바이트, 12바이트를 차지하지만 UTF16은 6바이트이니 차이가 더 벌어지게 된다. 유니코드에는 한글이 완성형(글자마디+호환용 자모) 방식과 조합형(세벌 한글 자모) 방식이 모두 등록되었으며 완성형 방식도 11172자가 순서대로 모두 등록되었으니, 예전의 조합형· 완성형 논쟁을 완전히 종결짓는 데 성공했다.

Windows NT도 처음에 개발될 때 문자 처리 단위를 wide로 무리해서 넓히느라 고생하지 말고, 그냥 UTF8만 도입했으면 어땠을까 싶지만 이제 와서는 다 지난 일이다. 아무래도 UTF8보다야 UTF16이 컴퓨터의 입장에서는 더 빠르고 간편하게 각각의 문자를 인식할 수 있으며, 이것이 메모리와 성능 소모면에서 UTF32와 UTF8 사이의 완충지대 역할을 해 온 건 부인할 수 없기 때문이다. 덕분에 Windows API의 관점에서는 UTF8조차도 native 인코딩인 유니코드 UTF16으로부터 '변환'되어야 하는 여러 multibyte 인코딩 중의 하나일 뿐이다~! ㅎㅎ

옛날에 인터넷 익스플로러의 버전이 5~6이던 시절엔 한글로 된 URL이 인식이 잘 안 돼서 맨날 “URL을 UTF8로 보냄” 옵션을 끄라는 지시가 팁처럼 공유되곤 했다. 당시엔 Unicode-aware하지 않은 웹 서버가 아직 많아서 말이다. 오늘날로 치면 UAC(사용자 계정 컨트롤)를 끄거나 팝업 창 허용 기능을 사용하는 것과 비슷한 편법이다.
하지만 요즘은 UTF8 방식 URL이 표준으로 정착한 지 오래다. 호환성을 중요시하는 IE에나 그런 옵션이 있지, 크롬 같은 브라우저는 선택의 여지 없이 무조건 UTF8이기도 하고 말이다.

유니코드는 문자 처리 기술의 발전과 함께 더욱 덩치가 커졌으며, 한편으로 더욱 복잡해지고 지저분해지고 있다.
UTF32가 아닌 인코딩으로는 어차피 메모리 배열 인덱스만으로 실제 글자 인덱스를 얻을 수 없는 것은 물론이거니와, 메모리 상으로 존재하는 글자 코드 포인트 수와, 화면에 출력되는 글자의 수도 일대일 대응이 전혀 이뤄지지 않게 되었다. 옛한글이라는 것도 유니코드 관련 기술이 방대해지면서 덤으로 같이 처리 가능해졌을 뿐이다. 진짜 미치도록 복잡한 문자에 비하면 옛한글 쯤이야 양반이지... 동일한 글자를 나타내는 방법이 여러 가지 존재하게 되어서 정규화라는 것도 필요해졌다.

코드 포인트 값만으로 정렬을 하는 것 역시 상당수 의미를 잃었다. 옛한글 자모는 유니코드 5.2 때 한양 PUA 비표준에만 존재하던 것들이 추가 등록되었는데, 이것들의 코드 포인트상의 순서를 따지는 건 부질없는 짓이다. 가뜩이나 부족한 BMP 공간의 여러 틈새에 산발적으로 간신히 등록된 것 자체를 감지덕지해야 할 판이다.

한자는 더욱 가관이다. 유니코드에서 공간을 압도적으로 제일 많이 차지하고 있는 문자인 건 두 말할 나위도 없거니와.. BMP 영역에 이미 등록돼 있고 호환용 같은 이유도 없는데 작업자의 실수로 인해 나중에 surrogate 확장 평면에 중복 등록된 글자도 있고, 일본 문자 코드의 실수 때문에 문헌에 전혀 등장한 적이 없는 유령 한자가 등재돼 있기도 하다.

이것이 오늘날의 컴퓨터 문명을 지배하고 있는 가장 원초적인 규범에 속하는 유니코드의 현실이다. ㅎㅎ
수십 년 주기로 유니코드를 전면 reset하고 코드값을 재정리하면 어떨까 싶지만 그건 기존 컴퓨터 문명이 핵 전쟁 같은 걸로 폭삭 없어지지 않는 한, 상상 속에서나 가능한 일일 것이다.

Posted by 사무엘

2013/12/16 08:25 2013/12/16 08:25
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/909

디지털 컴퓨터는 전자 신호로 0과 1만을 인식할 수 있다. 그렇기 때문에 컴퓨터에서는 문자 역시 0과 1의 조합인 숫자로 표현되며, 문자를 그런 숫자에다가 대응시키는 규칙이 바로 문자 코드이다. 정보 교환을 원활히 하기 위해서는 보내는 쪽과 받는 쪽이 모두 문자 코드가 통일돼 있어야 함은 두 말할 나위가 없다.

정보량의 최소 단위는 1비트이지만 현실적으로 컴퓨터의 기억 장치들이 한 글자로 취급하는 정보량의 최소 단위는 8비트, 즉 바이트이다. 8비트, 2^8승, 즉 256이라는 정보량은 숫자와 알파벳을 정하는 데는 충분하고 상위 1비트를 잉여화하여 오류 검출용으로까지 사용할 수 있을 정도이지만, 한글이나 한자 같은 문자를 담는 데는 턱없이 부족하다.

한자는 글자를 체계적으로 부분글자로 분해할 뾰족할 방도가 없는 상태로 글자 수가 너무 많다. 한글은 글자 생성 체계는 한자보다 훨씬 더 유리한 위치에 있지만, 실용적으로 편하게 다루려면 여전히 1만여 개의 미리 조합된 음절 형태를 그대로 배당해야 한다.

예를 들어 현실에서 '학교'라는 단어는 두 글자로 간주되지, 데이터베이스나 문서 분량 같은 데서 5글자라고 계수되는 곳은 아무도 없다. 코드 차지 영역을 줄이자니 메모리 사용량이 늘며, 그리고 오늘날로 치면 화면에 보이는 글자 길이와 메모리를 차지하는 글자 길이가 서로 완전히 따로 노는 complex script 급의 복잡한 기술이 필요해진다.

결국 한글과 한자는 1바이트만으로 표현할 수 없고 통상 2바이트로 표현된다. 그런데 기존 1바이트 영문· 숫자를 건드릴 수는 없으니 1바이트와 2바이트 문자가 공존하는 multi-byte 코드 체계가 만들어진다. 영문권에서 패리티 비트 내지 유럽 특수문자를 표현하는 데 쓰이는 최상위 1비트는, 이 문자가 1바이트로 끝인지 아니면 2바이트 문자의 첫 바이트(lead byte)인지를 판별하는 비트로 쓰인다.
공교롭게도 한글· 한자는 폭도 균일한 2글자 분량을 차지하여 비주얼 상 잘 어울린다. 전각· 반각이라는 개념이 여기서 유래된다.

그런데 lead byte는 그렇다 쳐도 2바이트의 다음 둘째 바이트인 tail byte도 기존 순수 1바이트 문자들과(영문· 숫자 같은) 전혀 겹치지 않게 할 것인지? 아니면 어차피 얘는 lead byte에 의해 변별이 됐으니 좀 문맥 의존적으로 겹치는 걸 허용할 것인지가 문제가 된다. 한글 코드의 경우 완성형은 겹치지 않으나 조합형은 겹친다.

그렇기 때문에 조합형은 tail byte가 대문자 알파벳과 소뭇자 알파벳이 제각기 따로 될 수 있고 심지어 \ 역슬래시 문자가 나올 수도 있다. 이런 이유로 인해 조합형은 1비트 + 초중성 5비트씩 한글의 구성 원리를 매우 잘 반영하여 설계된 문자 코드임에도 불구하고 당시 8.3 제약이 있던 시절에 파일 이름을 사실상 한글로 지정할 수 없었으며, 심지어 이론적으로는 // 주석을 조합형 한글로 지정한 경우 \ 때문에 2-byte aware 하지 않은 컴파일러에서는 충돌이 발생할 수도 있었다.

옛날에 한글 MS-DOS 시절에 한글 도스 셸이나 QBasic처럼 텍스트 GUI(?)를 구현한 프로그램들을 실행해 보면 한국 마소가 굉장히 잘 만든 게 있었다. 메뉴나 대화상자 같은 게 표시되어서 배경에 있던 2바이트 텍스트를 반토막 내더라도 깨진 문자열을 보여주는 법이 결코 없었다. 늘 짝수 바이트가 유지돼야 하는 한글/한자 영역이 홀수 바이트로 줄어들면 가장자리를 하나 삭제해 주면 된다.

그러나 문맥 의존적인 문자 코드로 그런 걸 구현하려면 문자열을 처음부터 읽어 봐야 하고, 두 바이트 중 하나가 소실됐을 때의 뒷처리가 문맥 독립 코드보다 더 어려우면 어렵지 쉽지는 않을 것이다. 불가능하다는 뜻은 아니지만.

조합형을 옹호하고 완성형을 까기에만 바쁜 분들의 심정이야 세벌식+한글 에반젤리스트로서 본인은 적극 이해한다. 그러나 과거의 2바이트 한글 코드의 이면엔 이런 면모도 있었음을 지적하고자 한다. 완성형은 여러 이슈가 얽혀서 그렇게 만들어졌지, 작정하고 한글을 난도질하려는 악의적인 의도로 만들어진 건 아니었다. 문맥 독립성뿐만 아니라 굉장히 보수적인 국제 규격 권장 사항을 만족하는 방식으로 문자 코드를 만들려다 보니, 한글 11172자에다 한자와 각종 특수문자들까지 넣을 절대적인 공간 자체가 부족했기 때문이다.

나중에 완성형에다 어거지로 한글 부족분을 채워 넣은 cp949 확장완성형은 어차피 조합형처럼 문맥 독립성이 깨졌다. 물론, 어차피 이렇게 만들 거면 처음부터 조합형으로 가지 하는 비판은 피할 수 없게 된 게 사실이다. 그런데, 이런 비슷한 삽질을 일본도 문자 코드를 만들면서 했으며, 이를 우리나라도 그대로 답습했을 뿐이다.

조합형과 완성형은 11172자와 2350자의 차이뿐만 아니라 한글 낱자를 표현하는 방식에서 매우 큰 차이가 있다.
조합형은 글자마디와 자모의 차이가 사실상 없다. 그냥 초 중 종성 중 한 성분만 있으면 자모이고, 초성과 중성이 갖춰졌으면 글자마디이다. 초성 ㄱ과 종성 ㄱ을 구분해서 표현할 수 있고 초성+종성이나 중성+종성 같은 '미완성 한글'도 얼마든지 표현할 수 있다.

그러나 완성형엔 그런 개념이 없다. 한글 입력을 처음 시작했을 때 쓰라고 '호환용 한글 자모'라는 게 있는데 그건 한글이 아니라 명목상으로는 '특수문자' 영역이다. 그냥 한글 자모 모양인 그림일 뿐이다. 초성+종성 구분이나 미완성 한글 표현 같은 건 없다.

메모리 1바이트가 아깝던 16비트 도스 시절에 국내에서는 조합형 한글 코드+글꼴이 쓰였지 마소의 윈도처럼 2350자 완성형 코드+글꼴로 돈지랄을 하는 프로그램은 전혀 없었다. 이런 압도적인 인지도의 차이로 인해 조합형은 1992년에 한국의 복수 표준으로 승격되어서 cp1361이라는 이름으로 나름 운영체제의 코드 페이지에 등록도 됐다.

자, 이렇게 컴퓨터는 1바이트 인코딩에다가 한중일 문화권을 위한 1+2바이트 멀티바이트 인코딩 구도가 유지되었고 마소에서는 이를 도스 시절부터 코드 페이지라고 불렀다. 그런데 이런 문자 코드들은 (1) 알파벳· 숫자 같은 공통 문자를 제외하면 같은 문자라 해도 국가마다 배당된 코드값이 같을 수가 없고, (2) 문자 집합 자체의 크기가 너무 작아서 세계 모든 문자들을 한 코드 페이지에다 담을 수 없다는 문제가 있었다.

人(사람 인)이라는 한자가 한국· 중국· 일본의 표준 코드에서의 코드값이 같을 리가 없으니 (1)은 자명한 문제다. (2)의 경우, 2바이트 코드라 해도 앞서 보았듯이 1바이트 문자와의 충돌을 피하기 위해 매우 제한된 영역의 바이트들만 묶을 수 있다. 이 때문에, 문맥 의존까지 시킨다 해도 추가로 만들 수 있는 문자는 1만여 자에 불과하다. CJK에서 쓰는 상용 한자들이나 간신히 다 집어넣을 정도이다.

그래서 1980년대 말부터 이런 발상의 전환이 이뤄졌다. “앞으로 컴퓨터의 메모리는 증가하고 소프트웨어 국제화의 중요성은 커질 테니, 글자 하나의 크기를 16비트로 쿨하게 확장하고 6만여 자의 공간에다가 전세계 언어 문자들을 집어넣고 동일 문자 동일 코드값을 실현하는 게 어떨까?”

이것이 바로 유니코드의 존재 목적 되시겠다. 컴공 전공자가 아니더라도 컴퓨터에서 '유니코드'라는 말은 한 번쯤은 다들 들어 보셨을 것이다. 이건 그야말로 컴퓨터 문자 코드계의 바벨 탑 내지 에스페란토 같은 물건이다.

마이크로소프트는 소프트웨어의 국제화에 굉장한 혜안이 있던 기업이었다. 그래서 OS/2와 결별하고 Windows NT를 첫 개발할 때, 애초부터 8비트 문자가 아니라 유니코드를 담을 수 있는 16비트 문자를 기반으로 설계했다. 심지어는 NTFS 파일 시스템까지도. 그리고는 이를 독자적으로 wide character이라고 부르기 시작했다. 어차피 8비트 문자만으로 충분하던 라틴 문화권에서는 별로 득이 되는 것도 없이 메모리 사용량만 두 배로 뻥튀기되는 대가를 감수하고라도 말이다.

Win32 API는 기존 16비트 윈도 API를 최대한 닮게 설계되었지만, 문자열을 다루는 모든 API에 A 버전과 W 버전 구분이 생겼다. 다만, 32비트 시절에 처음으로 도입된 OLE/COM 같은 기술은 처음부터 오로지 유니코드(= wide) 문자열만 취급하게 만들어졌다.

PE 방식으로 만들어진 32비트 EXE/DLL은 string 테이블, 메뉴, 대화상자 같은 리소스의 저장 포맷도 다 유니코드 방식으로 바뀌었다. 윈도 3.1에다가 Win32s를 설치하면 32비트 커널 DLL뿐만 아니라 각종 코드 페이지 변환 테이블도 설치되는 걸 볼 수 있다. 그게 바로 리소스를 변환하기 위해서이다.

윈도 NT가 3.x나 9x보다 메모리 사용량이 매우 많았던 이유 중 하나도 유니코드 때문이며, 반대로 윈도 9x가 유니코드 API를 지원하지 않았던 이유도 가정용 PC의 부족한 메모리 문제 때문이다.
이 때문에 컴파일 스위치만 바꿔서 유니코드와 기존 멀티바이트를 모두 커버할 수 있는 TCHAR, _T 같은 개념도 그때 생겼다. 두 개의 문자 포맷을 모두 지원하는 작업은 정말 엄청난 대공사였을 것 같다.

Posted by 사무엘

2013/12/13 08:24 2013/12/13 08:24
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/908

« Previous : 1 : 2 : 3 : 4 : 5 : 6 : 7 : 8 : 9 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2021/10   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            

Site Stats

Total hits:
1676164
Today:
80
Yesterday:
591