김 용묵의 절대공간 - 블로그

본인이 지금까지 게임 포함 고전 소프트웨어에 대해 글을 잔뜩 올린 것은 그래도 플랫폼은 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 사무엘

1.
우리나라가 옛날보다는 소프트웨어 불법복제에 대한 경각심이 좀 생겼고 불시단속도 강화된 관계로..
기업들 역시 대기업· 중소기업을 막론하고 직원들의 컴퓨터에 혹시 불법복제 소프트웨어가 깔려 있는지 자체 단속을 하는 편이다.
그런데, 그런 소프트웨어 자체를 생산하는 일을 하는 IT 기업에서는 추가적으로 민감한 물건이 더 있다.
자사가 개발하는 제품의 내부에 혹시 오픈소스 솔루션이 예기치 않게 들어가지 않느냐 하는 것이다.

당장 돈을 안 들이고 원하는 문제를 쉽고 빠르게 해결할 수 있다고 해서 출처 명시 없이, 혹은 라이선스가 요구하는 사항을 이행하지 않고 그런 솔루션들을 자기 소스 코드에다 불쑥 집어넣었다가는..
글쎄, 그 회사와 회사 제품이 완전 듣보잡 마이너 내수급이라면 별로 문제되지 않고 넘어갈지 모른다.
그러나 외국으로도 널리 널리 쓰이고 돈을 빗자루로 긁어모으는 인기 프로그램이라면 얼마 못 가 당연히 걸리고 발목 잡히게 된다.

왕년에 병역비리 내지 논문 표절을 저지른 사람이 나중에 고위 공직자가 되려 할 때 청문회에서 탈탈 털리듯이 말이다.
오픈소스를 표방하는 자유 소프트웨어라고 해서 저작권이 전혀 없는 게 아니기 때문이다. 아무나 완전히 제멋대로 고치고 이득을 챙겨도 되는 '인류 공용 자산'급인 public domain이 아니다.

방대한 분량에 복잡한 로직을 가진 소프트웨어는 설령 소스 코드가 있다 해도 누가 함부로 찔끔찔끔 고칠 수 있는 물건이 아니다. 그래서 그런지 설령 컴파일된 바이너리이고 소스 코드가 없다 하더라도, 여기에 어떤 오픈소스 솔루션이 무단으로 포함되었는지 정도는.. 오픈소스 진영에서 매의 눈으로 감시해서 다 적발해 낸다. 컴파일된 바이너리 코드의 패턴 분석을 정교하게 하는 듯.

그래서 그렇게 자기는 이윤을 챙기면서 엔진 내부에 무료 오픈소스를 무단으로 사용한 양심불량 소프트웨어는 hall of shame 같은 데에 올라서 업계에서 국제적으로 망신을 당하며,
GPL 라이선스 급의 오픈소스를 잘못 따다가는 그걸 사용한 프로그램 전체에 대해 소스 공개라는 형벌(?)을 당하게 된다. 실제로 그런 소스 공개형을 당한 사례도 몇 건 있다. 물론, 프로그램 소스만 공개이지 그 소프트웨어 제품에 사용된 각종 데이터나 리소스까지 죄다 공개는 아니기 때문에 완전한 기술 유출은 아니다.

대기업의 경우, 자사 직원들만치 꼼꼼하게 감시하지는 않는 하청업체로부터 납품받은 소스에 이런 지뢰가 들어있어서 골탕을 먹는 경우가 있는 모양이다. 그래서 납품 계약을 할 때부터 그 솔루션에 오픈소스 저작권 문제가 확실하게 없다는 걸 확인시키며, 문제가 생길 경우 이런 책임을 지우겠다는 식으로 얘기를 하는 걸 본인은 업계에서도 경험했다.

여담이지만, 요즘은 응용 언어학에서 다루는 말뭉치(코퍼스)에도 저렇게 저작권 바람이 불고 있다.
그래서 국립 국어원에서도 21세기 세종 계획 성과물로서 세종 말뭉치를 배포하다가.. 저작권이 문제가 되는 데이터를 빼고 분량이 다소 감소한 말뭉치를 새로 배포하기 시작했다. 그 얘기를 들으면서 IT업계의 오픈소스 얘기가 문득 떠올랐다.

2.
요번 학기에 학교에서 오픈소스와 관련된 세미나 수업을 들었다. 오늘날 IT 업계에서 오픈소스라는 트렌드가 차지하는 비중을 더욱 절실히 알 수 있었다. 자유 소프트웨어는 무엇이고 오픈소스 소프트웨어는 무엇인지, 그리고 리눅스 진영과 리처드 스톨먼 진영의 차이는 무엇인지 예전에는 거의 관심이 없었고 아는 게 없었는데 이제 좀 어렴풋이 알게 되었다. 유익했다.

오늘날은 정말로 거의 모든 분야에서 github, sourceforge 같은 오픈소스 진영의 저작물을 이용하지 않고는 실용적인 프로그램을 만들기가 대단히 어렵거나 가성비가 안 맞아 의미가 없는 지경이 되었다. 그 오픈소스 진영에서 활동한 이력은 만천하에 공개된 자기 스펙과 자산이 되기 때문에, 당장 소프트웨어의 무료 공개로 인한 금전 손실 이상의 이득이 돌아온다는 말에는 공감이 됐다.

확실히 IT 업계에서 경력을 쌓는 방식의 패러다임이 바뀌긴 했다. 내 지인 중에서도 이 바닥에서 워낙 유명한 사람이 있다. 그 친구는 이런 수업 따위는 들을 필요가 없거나, 아니면 나처럼 따로 자료 찾으며 과제를 낑낑대며 할 필요조차 없이, 평소에 하던 오덕질을 갖고 학점 따위 그냥 날로 먹는 게 가능했을 것이다.

내게 오픈소스라는 건, 이거 소스 코드 하나쯤은 공개해 버려도 내 밥줄에 아무 지장 없고 그것보다 더 나은 것 정도는 얼마든지 또 만들어 낼 수 있고, 이 프로그램의 UI, 데이터 파일들을 업계 표준 관행으로 굳히는 효과까지 노릴 수 있는 괴수들의 전유물일 뿐인 것 같다. =_=;; 물론 그런 진영에서 기여를 하는 프로그래머들이 매우 고마운 대인배인 건 사실이지만, 일단은 무슨 희생, 헌신, 자선 행위라기보다는 “가진 자의 여유” 구도라는 것이다.

또한, 마냥 다 공개하는 게 능사만은 아닐 텐데.. “경쟁자가 따로 이득을 보기 vs 경쟁자를 원천 견제하고 차단하기”라는 결말의 차이가 어떤 과정에서 생기는지 궁금하다. 가령, IBM은 하드웨어계의 오픈소스라 할 수 있는 PC 규격을 내놓았고 그게 결국 세계를 평정하긴 했지만, 이 때문에 정작 자기는 아무 이득도 못 보고 PC 사업에서 손을 떼게 됐단 말이다.

id 소프트웨어에서도 둠과 퀘이크의 소스를 공개하긴 했지만, 그래도 해당 세대의 기술이 충분히 한물 갈 정도로 굉장히 나중에 공개하지 않았던가. 물론, 엔진을 유료로 판매하기도 하는데 소스를 돈 주고 산 업체들이 손해를 보지 않게 하려고 좀 늦게 공개하는 것도 있긴 하지만 말이다.
오픈소스가 과연 개발자와 사용자가 모두 윈윈 할 수 있는 소프트웨어 생태계로 계속 명맥이 유지되는 게 가능할지 지켜볼 일이다.

아 그리고, 이 모든 사실에도 불구하고 <날개셋> 한글 입력기는 완성품을 복사해서 사용하는 것만 무료이지 여전히 소스 비공개 사유 소프트웨어이다. 물론 오픈소스 저작물을 사용한 것도 최소한 C++ 코드 내부엔 전혀 없다. 거기 들어있는 모든 모듈의 모든 기계어 코드는 한 치의 예외 없는 100% 자작이다.
전세계에 한국어와 한글이 쫙 퍼져 있고 세벌식 자판이 주류 글자판이 돼서 누구나 이런 응용 한글 입력 엔진의 필요를 느끼고 있고 사용자가 왕창 많고 거기에 다른 형태의 돈줄까지 있다면야 내가 거기에 공개적으로 기여를 해서 오픈소스계에 등단(?)할 수도 있겠지만.

시장과 수요 자체가 극도로 마이너한데... 공개해 봤자, 한글 IME를 연구하는 일부 극소수 오덕들에게나 좋은 일을 하게 되고, 내가 노력을 보상받는 길도 없고, 날개셋의 리눅스나 맥 버전을 뚝딱 책임감 있게 만들어 줄 사람이 있는 것도 아닌 와중에..
무작정 오픈소스화는 현실에 맞지 않는다고 여겨진다. 오픈소스 진영이 있다고 해서 모든 프로그래머가 흙 파서 먹고 살 수 있는 건 아니다.  8.0 정도가 나온 뒤부터는 내 프로그램의 장기적인 생존 방법에 대해서도 슬슬 생각을 해 봐야겠다.

3.
저건 나름 학점이 붙은 과목이기 때문에, 세미나만 있는 있는 게 아니라 과제도 있었다. 관심이 가는 오픈소스 프로젝트를 하나 선정해서 그에 대해 조사를 하고, 관심이 있으면 자그마한 오타 수정이라도 직접 하나 contribute를 해 보라는 것.

그래서 평소에 프로그래밍 언어에 대한 관심이 무진장 많으며, 나보고도 줄곧 이것저것 다른 언어를 익혀 보라고 권유를 하던 대한민국 오픈소스 진영의 거물이자 프로그래밍의 천재 T모 군의 도움을 받았다. (IOCCC 입상자 ㅋㅋㅋㅋ) 권유의 대상도 예전부터 파이썬, D, 자바스크립트로 계속 바뀌어 오다가 요즘은 Rust로 정착했다.

Rust는 모질라 재단에서 자체 개발한 새로운 절차형 시스템 프로그래밍 언어이다. Java/C# 같은 언어는 full-time 쓰레기 수집기가 갖춰진 별도의 가상 기계에서 동작하는 반면, 이 언어는 그런 형태의 쓰레기 수집기가 없이 C++과 동급의 네이티브 코드로 컴파일되는 언어이다. 메모리 관리 수준은 걍 Windows RT의 C++/CLI와 비슷한 급이 되겠다.

웹 브라우저 렌더링 엔진을 만드는 단체가 웬 PL을 새로 만들게 되었는지는 나름의 이유가 있다. 렌더링 엔진도 응당 GPU와 멀티코어의 도움을 받아야 할 터인데 여러 페이지들이 자연스럽게 멀티코어를 활용하는 게 아니라 단일 페이지가 멀티코어를 적절히 활용하게 만들자니 C/C++로 만들어진 기존 코드들은 답이 없는 지경이었나 보다.

또한 C/C++은 알다시피 빌드 시간이 매우 길고 컴파일러가 잡아 주지 못하는 메모리 관련 버그에 무방비로 노출되어 있는 등, 대형 프로젝트의 진행에 전통적인 한계와 약점도 적지 않다. 그래서 대형 프로젝트의 개발과 유지에 적당한 새로운 언어를 찾았는데 마땅한 대안이 없자 언어를 직접 고안하게 되었다.

이 언어는 모질라 재단에 소속되어 있던 개발자인 Graydon Hoare가 개인적으로 설계하던 언어를 재단이 인수하여 발전시킨 것이다. 지금은 모질라 재단뿐만 아니라 삼성전자도 Rust의 개발을 후원하고 있다고 한다.
아직도 활발하게 개발되고 있어서 0.12까지 나왔는데.. (12는 소수점이 아니라 그냥 정수. 0.2보다 최신 버전임) 긴 베타 기간을 거친 후, 가까운 미래에 Rust의 1.0 정식 버전이 나올 예정이라 한다.

즉 멀티코어 병렬 처리 편의와 자동 메모리 관리, 그리고 성능을 만족시킬 목적으로 만들어진 언어라는 뜻인데, 구글에서 비슷한 시기에 개발한 Go라는 언어하고도 경쟁 구도인 듯하다. 하지만 둘은 패러다임이 좀 다른 언어이다.

Rust에서 모든 값은 그 값이 대입된 변수나 구조체 필드, 넘겨받은 함수 인자 등의 이름에 귀속된다. 이름은 자기에게 귀속된 값에 대한 소유권을 가지며, 다른 이름으로 값을 대입하면 그 이름으로 소유권이 이전된다. 예를 들어, 다른 언어에서 a = b와 같은 대입 연산은 b의 값을 a로 복사하거나, b가 가리키던 객체를 a도 함께 가리키겠다는 의미를 갖는 데 반해, Rust에서는 b가 가지고 있던 값을 a로 이동시킨다는 의미가 된다. C++로 치면, C++11에서 첫 도입된 R-value reference type과 개념적으로 비슷하다.

만약 함수의 리턴값을 받지 않는다던가 하는 일로 인해 소유권을 넘겨주지 못한 채로 이름이 사라지게 되면, 거기에 귀속되었던 값도 함께 사라지면서 그 값을 담았던 메모리도 해제되게 된다. 프로그래밍 언어 이론의 관점에서 보자면, binding과 object의 생명 주기를 일치시킨 셈이다.

Rust 컴파일러는 컴파일 단계에서 소유권이 어떻게 이전되는지를 모두 추적할 수 있으며, 필요한 메모리 할당 및 해제 코드를 컴파일 중에 정확한 위치에 삽입한다. 이런 방법으로 Rust는 런타임 오버헤드가 없는 안전한 메모리 관리를 이루어 낸다.
일단 대충 이 정도 조사하면서 그쪽 진영에서 뜨고 있는 이슈와 작업 진행 방식들을 조사해 봤다.

Posted by 사무엘

1.
아래아한글의 역대 버전 중, 96과 97은 실행되면서 스플래시 화면이 나올 때 짤막한 효과음(음악 멜로디)이 나오던 전무후무한 버전이었다.
96은 경쾌한 사과나무.wav (도~~ 미파솔..로 시작하는)이었고 97은 그것 말고도 여러 종류의 음향이 더 추가되었다. 물론 워디안 이후 후대부터는 그런 것 없고. 이런 것도 다 일시적인 유행이었다.

오늘날은 아예 Windows조차도 8부터는 로그인 로그아웃 소리가 없어졌다.
먼 옛날 3.x 시절에 사운드 카드가 지원된 이래로, 시작 효과음은 그 유명한 tada.wav부터 시작해 뭐가 들어가도 들어갔는데.. 완전히 없어진 건 8이 처음이다.

응용 프로그램을 실행하는 게 옛날만치 그렇게 막 유세 떨 일이 아니게 되어서 그런 것 같다.
설치 프로그램이 원래 전체 화면을 차지하는 형태이다가 조그마한 마법사 대화상자로 바뀐 것도 비슷한 맥락일 것이고 말이다.

2.
지금이야 MS Office 제품들이 리본 UI를 사용하여 인터페이스가 여타 프로그램과는 완전히 다른 형태로 바뀌었지만..
먼 옛날, Office 95 시절이 문득 생각난다.
Windows 95의 출시에 맞춰서 완전히 32비트로 포팅된 첫 버전이었으며, 동시에 Office가 운영체제의 표준 메뉴 인터페이스를 사용하던 마지막 버전이었다.
다만, 약간의 애드립이 생각지 못한 곳에 있었는데.. 아래 스크린샷에서 프로그램 상단의 타이틀/캡션 바 영역을 보시라.

Office 95 프로그램들은 처음이자 마지막으로 캡션 바를 자체적으로 그렸다.
그래서 Microsoft는 그냥 일반 폰트가 아니라 그 당시 쓰이던 MS 로고타입 형태 그대로 그려졌으며, 검은색에서 짙은 군청으로 바뀌는 그러데이션이 적용되어 있었다.
잘 알다시피, 캡션 바에 그러데이션이 추가된 것은 윈도 98부터이지 95엔 아직 그런 게 없었다. 응용 프로그램이 WM_NCPAINT를 처리하여 직접 그렸던 것이다.

정말 일시적인 유행이었지만 그 시절에 외국 프로그램 중엔 캡션 바를 이 스타일을 따라 그렸던 프로그램도 소수 있었다.

3.
사실 Windows는 GUI 외형이 Mac OS에 비해 매우 단순한 편이었고, 그 대신 색상을 다양한 스타일로 지정할 수 있었다.
그러던 것이 XP 이후부터는 큰 변화가 생겼다. Luna 테마는 파랑-은색-황록이라는 세 색상표만 지원했고, Vista부터는 Aero 창틀의 색깔만 사용자 지정이 될 뿐 나머지 색상은 고정 불변이 됐다. 예전의 재래식 외형은 '고전 테마'라는 legacy로 전락했다.

시스템 색상을 customize할 일이 없어졌다. GetSysColor 함수는 원래 수십 가지의 색상 요소들을 제공하지만 응용 프로그램은 사실상 COLOR_WINDOW(TEXT), COLOR_HILIGHT(TEXT), COLOR_BTNFACE 같은 것밖에 사용할 일이 없어졌다. 그리고 사실은, 선택된 아이템을 표시할 때도 COLOR_HILIGHT나 반전(InvertRect)이 아니라 엷은 파랑 효과를 쓰는 게 유행이 됐다.

옛날에 Microsoft Plus! 같은 확장팩이 제공했던 '테마'들은 색상, 마우스 포인터, 효과음을 한데 모은 세트였지만.. 지금은 Windows도 맥 OS처럼 어찌 보면 사용자 선택의 폭을 좁히고 있다. 지금의 외형 자체가 곧 Windows의 정체성과 같다는 점을 더욱 내세우려는 것 같다. 색상표는 이제 사실상 시각 장애자 내지 전력 절약용으로나 의미가 있는 '고대비'밖에 안 남았다.

4.
Windows는 파일/디렉터리 목록을 이름 순으로 정렬해서 표시하더라도 디렉터리(폴더)와 파일은 따로 분류해서 보여주는 반면, Mac OS는 이들을 다 한데 섞어서 보여준다. 디렉터리도 특수한 형태의 파일로 볼 것이냐, 아니면 아무래도 파일과는 개념적으로 다른 존재로 보느냐의 차이 같다.
또한 마우스 휠을 인식하는 대상도 Windows는 키보드 포커스를 받고 있는 창이지만, Mac은 마우스 포인터가 놓여 있는 창이다.

참, 맥OS는 메뉴나 대화상자에 액셀러레이터 키가 전혀 없는 게 굉장히 뜻밖이다.

5.
유튜브나 스마트폰의 동영상 재생 앱 등... 요즘은 이게 유행인지 모르겠지만
대부분의 멀티미디어 재생 컴포넌트들은 Pause(||) 버튼만 있지, 완전 정지 Stop(■) 버튼이 없다.

파일을 열었으면 나중에 반드시 닫아야 한다는 프로그래머스러운 사고방식에 사로잡혀 있는 본인 같은 사람에겐 그런 디자인이 심리적으로 좀 불안하게 느껴지기까지 한다. 정말 Stop이 없어도 될까? 굳이 프로그래머가 아니더라도 옛날 카세트 및 비디오 테이프 재생기 역시 기계적인 특성 때문에 Pause와 Stop은 성격이 상당히 다르기도 했고 말이다.

하지만 리소스 제약 같은 걸 생각하지 말고, 사용자의 입장에서 오로지 틀고 싶을 때 틀고 끄고 싶을 때 끄는 것만 생각하면, 원론적으로야 둘을 굳이 구분할 필요가 없긴 해 보인다.

6.
top-to-bottom과 bottom-to-top이 헷갈릴 때가 종종 있다.
당장 좌표계만 해도 수학에서는 아래에서 위가 y축의 양의 방향이지만.. 컴퓨터 화면에서는 위에서 아래가 y축의 양의 방향이다.

Windows에는 spin, 혹은 up-down이라고 불리는 컨트롤이 있다.
얘는 언제나 위에 있는 ▲ 버튼 혹은 위(↑) 화살표 키를 눌렀을 때 숫자를 증가시키고, 그 반대의 조작을 하면 숫자를 감소시킨다.
안타깝게도 이 동작을 정반대로 바꾸는 방법은 없는 듯하다. 컨트롤의 동작을 교묘하게 서브클래싱하지 않는 이상 말이다.

저 컨트롤은 <날개셋> 한글 입력기의 제어판에서 입력 항목의 배열 순서를 바꾸는 용도로도 쓰이는데..
입력 항목들은 위에서 아래로 오름차순으로 배열되어 있다.
그래서 ↑가 아니라 ↓를 눌렀을 때 숫자가 증가하고 아래로 가게 하고 싶으나 그렇게는 못 하고 있다.
이건 솔직히 사용자를 굉장히 헷갈리게 만들 수도 있는 면모이다.

이 외에도, 노트북의 터치패드를 손가락으로 상하 드래그를 했는데, 위에서 아래로 그었을 때 화면을 위에서 아래로 스크롤시킬지, 반대로 아래에서 위로 스크롤시킬지도 보통은 옵션으로 존재한다.
본인이 선호하는 건 위에서 아래로 그었을 때 화면은 아래에서 위로, 즉, 아래 페이지의 내용을 표시하는 것이다. ↓ 키를 눌렀을 때와 같다. 손가락은 전체 내용에 대한 화면(view)의 상대적인 위치와 같은 것이다.

그러나 손가락의 위치를 지금 표시되어 있는 텍스트의 상대적인 위치와 같은 것으로 본다면.. 소프트웨어의 동작은 저것과는 반대가 되어야 직관적일 것이다. 결국 이것은 사람마다 취향이 다른 답이 없는 문제이다.

Posted by 사무엘

오늘날 PC에서 명맥을 유지하며 살아있는 데스크톱용 운영체제는 역시나 윈도우, 맥, 리눅스 3관왕이다. 다만 이들이 대등한 점유율이 절대 아니며, 셋의 점유율은 공비가 무려 10에 육박하는 등비수열을 이룬다.

맥이야 x86 계열 CPU로 갈아타고 기계의 가격도 내리면서, 옛날에 비해서야 정말 많이 대중화가 되었다. 또한 아이폰/아이패드가 모바일에서 워낙 큰 성공을 거둔 덕분에 맥북/아이맥까지 반사 이익을 보고 있기도 하다. 아이폰/아이패드에서 돌아가는 소프트웨어를 만들려면 결국 그 계열의 PC가 필요하니까 말이다.

그래도 윈도우에 비하면야 맥 사용자는 정말 10% 이내의 소수이다. 맥OS를 작정하고 써 볼 의향이 있는 게 아니라면, 맥 계열 기계는 비슷한 사양의 일반 컴퓨터보다 여전히 비싸며 구입 후에 서비스도 구리고 키보드· 마우스의 일부 동작 방식이 이질적이기 때문에 덥석 권할 게 못 된다. 솔직히 나도 지금의 맥북 살 돈으로 일반 노트북을 샀다면 아마 화면이 두 배 정도 더 큰 걸 살 수 있었지 싶다. 그러나 ‘스잡빠’, ‘앱등이’로 대표되는 굳건한 추종자도 있는 마당에, 이쪽 진영은 결코 없어지지는 않을 것이다.

맥은 소수이지만 인지도라도 있지 리눅스는 그조차도 없다. 리눅스를 서버도 아닌 데스크톱 로컬 환경의 주 운영체제로 쓰는 사람은 가히 소수 중의 소수이다. 작정하고 MS 진영을 반대하고 철저한 copyleft 정신으로 무장한 컴덕후 해커이거나, 잡스를 숭배하는 것처럼 리처드 스톨먼을 숭배하는(최소한 그의 인격이 아니면 그의 이념을) 사람 정도만이 리눅스를 쓰지 않을까 싶다.

물론, 맥이 예전보다 접근성이 개선된 것만큼이나 리눅스도 옛날에 비해서는 초보자가 쓰기 정말 편해지긴 했다. 하지만 그래도 초보자가 쓰기엔 리눅스는 인지도 있는 응용 프로그램이 부족하고, 뭘 세팅하고 바꾸려면 유닉스 명령줄을 다뤄야 하는 등 생소한 면모가 적지 않다.

(연구 목적으로 2010년 무렵에 VM을 만들어서 돌려 본 우분투 리눅스 9.x의 화면이다. 한때 리눅스의 그래픽 셸은 GNOME이냐 KDE냐로 갈라져 혼란스러운 편이었으나, 요즘은 결국 둘 다 지원하는 쪽으로 가는 추세라 한다.)

20년이 넘게 도스와 윈도우에만 길들여지고 10년이 넘게 윈도우 프로그래밍만 해 본 본인의 입장에서 맥 OS에 존재하는 주목할 만한 특징을 간추려 보면 다음과 같다.

가장 먼저, 운영체제의 시스템 메뉴와 응용 프로그램의 메뉴가 한데 완전히 통합되어 있다는 점이 매우 인상적이다.
Windows는 운영체제의 시스템 메뉴에 해당하는 시작 메뉴가 task bar에 있다. 이것은 응용 프로그램의 창에 소속된 메뉴하고는 당연히 완전히 별개이다. CreateWindowEx 함수는 창을 생성할 때 메뉴 핸들도 별개로 받는다.

그러나 맥은 화면 상단에 항상 고정되어 있는 시스템 메뉴에 응용 프로그램의 메뉴가 얹힌 형태로 나타난다. 이런 건 윈도우에서는 OLE 개체 embedding 상태에서나 어렴풋이 볼 수 있는 모습이다.

(제목은 워드패드인데 도움말에 나와 있는 건 그림판. 어?)

응용 프로그램 메뉴는 파일이나 도움말 같은 기본적인 것만 남고, 그 사이엔 개체를 제공하는 프로그램의 메뉴가 뜨는 것 말이다. 요즘은 이런 디자인도 과거 유물로 치부되어 별도의 프로그램 창이 따로 뜨는 형태로 바뀌고 있지만. (MS부터가 자기네들이 만든 표준 메뉴 인터페이스를 구닥다리로 치부하고 안 쓰려 하니 말이다)

맥에서는 시스템 전체를 통틀어 pull-down 메뉴는 하나만 있으며, 한 순간에 현재 활성화되어 있는 프로그램의 메뉴 하나만 볼 수 있다. 문서 창에 메뉴가 따로 달려 있지 않다. 그리고 맥에서 돌아가는 GUI 응용 프로그램이라면 반드시 이런 디자인을 따라야만 한다.

윈도우에서는 대화상자 하나만 달랑 띄우고 따로 메뉴를 만들기는 곤란한 프로그램의 경우, 대화상자의 시스템 메뉴를 customize해서 보통 ‘이동 / 닫기’만 있는 그 메뉴에다가 About이라든가 Always on top 같은 추가 명령을 넣는 경우가 있다. 그러나 맥은 어떤 프로그램에게라도 무조건 기본 메뉴가 주어지니 그런 식의 테크닉이 존재하지 않는다.

맥은 그런 기본적인 인터페이스가 모든 응용 프로그램에서 무조건 동일하기 때문에 윈도우처럼 무슨 오피스 200x 스타일 메뉴나 도구모음줄을 만들어 주는 GUI 툴킷이라는 게 존재하지 않는다. 윈도우에서야 보급 메뉴 대신에 그 자리에다 싸제 메뉴 창을 얹어서 보급 메뉴처럼 동작하게만 만들면 custom UI를 손쉽게 만들 수 있지만, 맥은 그렇게 할 수 없으니 말이다.

비주얼 C++의 MFC 프로젝트 마법사를 보면, GUI 응용 프로그램을 전통적으로 MDI, SDI, 대화상자라는 세 형태로 분류한다. 그런데 맥에서는 어떤 형태의 프로그램도 일단은 가장 범용적인 MDI에서 시작한다고 볼 수 있다. 실제로 문서 창은 하나밖에 생성하지 않는 프로그램이라 할지라도 말이다. ‘<날개셋> 타자연습’을 맥용으로 만든다면, 프로퍼티 페이지의 밖에 존재하는 ‘사용자 로그인’이나 ‘종합 환경설정’ 같은 명령은 응당 메뉴에서 내리는 명령으로 바뀌어야 할 것이다.

또한 맥은 동일 프로그램의 중복 실행에 대한 개념이 Windows와는 다르다. 같은 프로그램은 한 번만 실행되고 그 동일한 프로그램이 여러 문서를 담당한다는 MDI 사고방식이 맥은 더욱 엄격하다. 그래서 맥 OS의 task bar에 해당하는 dock은 프로그램이 실행됐냐 안 됐냐의 여부만 표시되어 있지만, 이 아이디어를 차용한 윈도우 7의 task bar는 프로그램의 중복 실행 개수도 살짝 표시하고 있는 것이다.

이런 디자인 때문에, 맥에서 프로젝트 단위로 문서를 다루는 프로그램은 내부 구조가 많이 복잡해진다. 개발툴이 그런 예 중 하나이다. 비주얼 C++이야 여러 개를 실행해서 제각기 프로젝트를 열면 되지만, xcode는 프로젝트별로 각각의 문서창을 차지하고 있으면서 그 내부에서 또 파일을 편집하는 창을 관리해야 한다.

맥 응용 프로그램은 마지막 문서 창이 닫혀서 문서가 하나도 없는 상태에서 키보드 포커스가 다른 프로그램으로 넘어갈 때 자동으로 종료되는 편이다. 이런 동작 방식은 Windows에서는 볼 수 없던 모습이다.
물론 모든 프로그램이 그러는 건 아니다. 대표적으로 Finder도 파일 표시(윈도우로 치면 탐색기 창 같은) 창이 하나도 없이 포커스가 바뀌더라도 종료되지 않고 언제나 실행되어 있는다. 내장 웹브라우저인 사파리도 마찬가지이다.

키보드로는 Alt+F4에 해당하는 Cmd+Q를 누르면 언제나 프로그램이 종료된다. 단, 윈도우의 Alt+F4는 그냥 창을 닫는다는 보편적인 용도도 포함하는 단축키인 반면, Cmd+Q는 언제 어디서나 해당 응용 프로그램을 완전히 종료시킨다는 의미 차이가 있다.

윈도우 프로그래머라면, 맥에서는 저런 것뿐만이 아니라 응용 프로그램의 파일 구성까지 상상도 못 할 정도로 다르다는 사실에 더욱 놀라게 될 것이다. 단순 실행 파일 말고 GUI 응용 프로그램은 아이콘, 리소스, 구성 파일이 한데 담긴 패키지 형태로 배포된다. 파일 시스템상으로는 디렉터리 구조이지만 운영체제 내부에서는 가상적인 단일 패키지 파일로 취급된다.

맥에서는 그럼 레지스트리가 없으면 응용 프로그램의 설정 저장을 위해 어떤 기법을 쓰는지? 프로그램 추가/제거는 어떻게 하는지? 동일 개발자가 만든 여러 프로그램이 동일 코드를 공유하려면 DLL 같은 건 어느 디렉터리에다 집어넣으면 되는지? 맥은 윈도우 같은 32/64비트 코드 혼용 문제는 없는지?

알고 싶은 게 한두 가지가 아닌데 그런 걸 윈도우 프로그래머의 입장에서 잘 설명해 놓은 인터넷 사이트나 책은 아직까지는 난 못 봤다. 아무래도 둘은 서로 달라도 너무 달라서 두 플랫폼의 사고방식에 모두 완전히 통달한 개발자는 거의 없으리라 예상된다.;;

이렇듯, 그토록 쉽게 다가설 수 없는 이질감에도 불구하고, 맥 OS는 좀 써 보면 윈도우에서는 느낄 수 없는 참을 수 없는 고급스러움, 미적 감각이 느껴지는 건 부인할 수 없다. 맥 같은 녀석이 존재함으로써 IT 세계가 좀 더 다양해지고 MS의 독점을 약간이나마 견제하는 효과가 난 건 인류 전체의 관점에서는 그래도 이익이긴 한 것 같다.

Posted by 사무엘

<날개셋> 한글 입력기의 개발자가 심층 분석한 MS 한글 IME 리포트.
버그를 나열하기 전에 먼저 독자의 이해를 돕기 위한 기술 설명부터 하겠다.

A. MS IME의 두벌식과 세벌식의 구현 차이 -- 오토마타

일단 좋은 말부터 꺼내자면, MS 한글 IME는 현존하는 한글 입력기들 중, 어떤 의미에서는 기본에 충실하게 가장 FM대로 만들어져 있다. 두벌식과 세벌식의 로직이 서로 확고하게 분리되어 있으며 구조가 완전히 다르다. 그리고 MS 버전의 두벌식 한글 입력기는 전산학적으로 볼 때 진정한 두벌식의 고증에 가장 충실하게 만들어져 있다.

무슨 말이냐 하면, 자음이라면 초성을 조합할 때와 종성을 조합할 때의 조합 규칙에 차이가 없다. 그래서 초성이 입력되는 상태에서도 ㄶ, ㄳ 같은 겹받침을 바로 입력할 수 있는 반면, ㄲ, ㅆ 같은 쌍자음은 연타가 아니라 반드시 Shift로만 입력할 수 있다. 이 동작 방식은 내가 알기로 윈도우 95 시절 이래로 시종일관 변함 없다.

<날개셋> 한글 입력기나 아래아한글의 두벌식 입력기는 그렇지 않다. 도깨비불 현상만 추가되었을 뿐 세벌식의 사고방식으로 두벌식을 덤으로 구현한 형태에 가깝다. <날개셋>의 경우, 이 점을 감안하여 지난 6.0 버전에서 초-종성 공유 낱자 결합 규칙이라는 개념이 추가되었으며, 이를 사용하면 두벌식 입력 방식을 좀 더 두벌식스러운 사고방식으로 설정할 수 있다.

뭐, 아래아한글도 1980년대 말에 1.0이 처음 개발되었을 때는 개발자들이 세벌식이 정확하게 뭔지 몰라서 자음만 한 벌 더 있을 뿐 여전히 도깨비불 현상이 존재하는 형태로 만들었다가, 고 공 병우 박사에게서 지적 받고 고쳤다는 일화가 전해지긴 한다만.

B. MS IME의 두벌식과 세벌식의 구현 차이 -- 글쇠 인식

표준 두벌식 글자판은 A부터 Z까지 딱 알파벳 글쇠 26개에만 한글이 배당되어 있고 나머지 글자들은 영문과 완전히 똑같다. 그렇기 때문에 MS 한글 IME는 두벌식일 때는 알파벳 글쇠만 가로채어 사용하며, 숫자, 기호, 공백 글쇠는 처리하지 않고 응용 프로그램으로 그대로 넘겨 준다.

세벌식은 그렇지 않다. 몇 가지 영문과 일치하는 기호가 있긴 하지만 일반적으로 공 병우 세벌식은 4단까지 독자적으로 사용하고 숫자와 기호 영역까지 침범한다. 그래서 MS IME는 세벌식에 대해서는 아예 공백까지 포함한 48개 글쇠 자리를 모두 가로채어 동작한다. <날개셋> 한글 입력기는 가로챌 글쇠 영역 자체를 필요에 따라 정밀하게 제어하는 옵션을 아주 최근의 6.5 버전에서야 추가했다.

이렇게 두 글자판의 구현이 제각각 따로라는 점 자체는 나쁘지 않다. 그러나 이는 MS IME에 두벌식을 쓸 때는 괜찮은데 세벌식을 쓸 때만 자잘한 버그가 존재하는 빌미를 제공하고 있다. 역사적으로 볼 때, 이런 버그는 더럽게 안 고쳐진다는 특징도 있었다. 두벌식과 세벌식의 넘사벽 급의 인지도 차이 때문이다.

10년도 더 전에 포트리스라는 대포 쏘기 게임이 인기였을 때, 세벌식으로는 한글 모드에서 Space로 대포 쏘기가 안 되어 채팅과 게임을 같이 하기가 불편하다는 이슈가 있었다. 두벌식에서는 Space가 응용 프로그램이 직접 접수한 공백이지만, 세벌식에서는 Space가 직접 오는 게 아니라, 한글 IME가 가공을 하고 보내 준 공백이라는 완성된 문자열이 오기 때문이다.

C. 윈도우 7에서의 변화

자, 앞에서 다룬 건 MS 한글 IME의 두벌/세벌 메커니즘의 차이이고, 지금 하는 얘기는 운영체제의 버전에 따른 디테일의 변화 쪽이다.

16비트 윈도우 시절에는 운영체제에 유니코드도, 국제화(I18N)도, 지역화(L10N)도 없었다. 동일 제품을 한중일 나라의 문자를 입출력할 수 있게 개량하는 것은 MS의 각 지사에서 완전히 독자 기술을 사용해서 알아서 재량껏 해야 했다.

그러다가 윈도우 95/NT4가 되면서 글꼴 쪽도 획기적으로 발전하고(내장 비트맵, 트루타입 컬렉션 등), 입력기 쪽도 한중일 통합 IME 프로토콜이 처음으로 제정되었다. 그리고 입력기 프로그램은 EXE가 아니라 여타 운영체제에서 유례를 찾기 힘든 독특한 형태인 DLL이 되었다. 그래서 윈도우만 입력기의 한영 상태가 각 프로그램별로(정확히는 스레드별로) 완전히 따로 놀지, 공유가 되지 않는다.

윈도우 2000부터는 추가 글꼴과 코드 페이지 데이터만 설치해 주면 세계 어느 나라 윈도우에서도 아무 나라 언어의 입력기를 설치할 수 있게 되었고, 윈도우 XP부터는 고급 텍스트 서비스라고 불리는 일명 TSF 기술이 도입되었다. 윈도우 비스타부터는 이제 전세계 언어의 입력기와 글꼴이 추가 설치를 할 필요도 없이 기본으로 제공되며, TSF 프로토콜이 주류가 되고 기존 IME 프로토콜은 호환성 계층을 통해서나 제공된다.

이로써 비스타에서 문자 입력 방식의 그랜드 슬램이 달성되고 해피엔딩이 된 것 같은데, 윈도우 7에 와서는 기능이 추가된 건 없으면서 뭘 또 잘못 건드렸는지 문자 입력 쪽의 안정성이 전반적으로 하락했다. MS 한글 IME만의 버그인 것도 있고 운영체제 자체의 버그인 것도 있다. 이 글에서는 지금까지 언급한 A~C를 염두에 두고, 2012년 현재 MS 한글 IME에 존재하는 것으로 알려진 버그들을 정리해 보았다.

1. 세벌식 최종 + 전각문자

맥 OS는 공 병우 박사(이분이 요즘 같았으면 전형적인 앱등이이셨다ㅋㅋㅋ)의 텃새 덕분에 전통적으로 세벌식 최종이 강세였으며, 세벌식이라 하면 곧 최종 자판을 가리켰다. 그러나 PC 쪽은 도스 시절 이래로 390이 강세였기 때문에 세벌식이라 하면 곧 390을 가리켰다. 최종은 아래아한글조차 97에 와서야 제공하기 시작했을 정도로 인지도가 미미했다.

윈도우 95 때 처음으로 세벌식 최종 글쇠배열이 있긴 했지만 그런 인지도 부족으로 인해 틀린 배열이 굉장히 많았다. 그게 98에서 좀 바로잡히긴 했지만 여전히 오류가 있었고, 그 오류는 윈도우 XP/오피스 2003에 가기까지 고쳐지지 않았다.

비록 최종 글자판은 참고표와 가운뎃점처럼 1바이트 아스키 영역에 없는 글자가 있는 게 특이점이긴 했지만, 윈도우 98부터는 어차피 한글 IME의 모든 내부 자료구조가 유니코드로 바뀌었기 때문에 큰 문제가 되지 않았다. 구조가 그러하니 내가 파워업을 개발해서 패치도 가능했던 것이고.

윈도우 비스타 + MS 오피스 2007에 와서야 드디어 100% 정확한 세벌식 최종 글자판이 제공되기 시작했다. 2003년 중반에 내가 한국 MS를 방문해서 수정을 강력하게 요청했던 것도 아마 작용하지 않았겠나 생각해 본다. 비록 그 해 가을에 발표된 오피스 2003에서 바로 반영되지는 못했지만 말이다.

그런데, 이 사람들이 일을 깔끔하게 처리하지 못했다. 전각 모드에서는 참고표와 가운뎃점이 제대로 입력되지 않는다. 얘들은 아스키 문자가 아니니 라틴 문자처럼 일괄적으로 0xFEE0를 더해서는 안 되는데 그거 처리를 추가하지 않은 듯하다. 윈도우 7+오피스 2010에서까지 변함없다. 물론 한국에서는 전각 문자를 거의 쓰지 않으니, 이건 심각한 문제는 아니다.

참고로 한중일의 MS 오피스는 XP 버전부터 운영체제의 IME를 자기 것으로 패치하는 게 관행이 됐다. 일본어 IME는 운영체제의 것과 오피스의 것이 차이가 난다는 말도 있는 듯하지만, 한글 IME는 운영체제의 것이나 오피스의 것이나 차이가 거의 없음.

2. MS 워드 2007 이상에서 세벌식을 쓸 때만 나타나는 역상 현상

워드 2007 이상에서, 오피스 2007 이상 또는 윈도우 비스타 이상이 제공하는 한글 IME로 세벌식을 써서 한글과 숫자, 기호, 공백을 입력한다. 그 뒤에 IME를 날개셋이라든가 다른 일본어· 중국어 입력기로 바꾼 뒤 글자를 입력한다. 그러면 예전에 MS 한글 IME의 세벌식으로 입력했던 공백이나 숫자, 기호가 역상(검은 배경, 흰 글씨)으로 바뀐다!

굉장히 기괴한 버그이다. 이것은 워드에서만 나타난다는 점에서 워드의 문제이기도 하지만 세벌식으로 입력한 비한글 문자에 대해서만 나타난다는 점에서 MS IME의 문제이기도 하다. B에서 언급한 기술 차이를 생각해 보라.

이 역상은 문서의 내부 서식이 아니라, 문자의 중간 조합 상태를 표현하기 위해 문자 입력기가 임시로 부여하는 시각 효과이다. 일본어 입력 중에 나타나는 점선 밑줄 같은 것 말이다. 해당 문서를 저장한 뒤에 다시 불러오면 다행히 사라지긴 하지만, 그 상태에서 조치를 취하지 않으면 인쇄도 그대로 역상 모양으로 된다. -_-

더욱 기괴한 건, 오피스 2003 같은 예전 버전의 MS IME로는 세벌식을 쓰더라도 이런 현상이 발생하지 않는다는 점이다. MS 제품 자체의 버그가 확실하다. 윈도우 7/오피스 2010에서까지 고쳐지지 않았다.

3. 윈도우 7, 한글 입력 중에 바탕 화면을 클릭했을 때

윈도우 7에서 MS 워드 2007이나 2010을 실행하여 아무 한글 IME로나 한글을 입력한 상태로 있는다. 창을 최대화하지는 않은 채로 가령, ‘아’를 조합하고 있는다. 그리고 그 상태로 마우스로 바탕 화면을 클릭했다가, 다시 워드의 제목 표시줄을 클릭하여 돌아온다.

비스타에서는 동일한 절차를 수행하고 나면 ‘아’의 조합이 종료되어 커서가 ‘아’ 뒤에 가 있다. 그러나 7에서는 커서가 여전히 ‘아’를 조합하고 있지만 실질적으로는 조합이 끝난 상태이다. 받침 ㄴ을 입력하더라도 ‘안’이 되지 않고 ㄴ이 새로 조합된다.

윈도우 7은 한글 조합 중에 창의 포커스가 바뀌었을 때의 내부적인 처리가 갑자기 좀 이상하게 혹은 엄격하게 바뀌었다. 비스타나 XP 이전에는 아무 문제가 없던 게 7에서 갑자기 문제를 일으켜서 그에 대한 방어를 해야 했다. <날개셋> 한글 입력기도 과거의 5.51과 5.52 때 이와 관련된 버그 패치가 행해졌다.

4. 윈도우 7의 콘솔에서 세벌식으로 조합을 종료할 때 글자가 덧남

윈도우 XP/비스타에서는 해당사항 없고 7에서만 발생하는 구조적인 문제이다. 서비스 팩 1에서도 고쳐지지 않았다.
명령 프롬프트에서 세벌식 자판으로 한글을 입력하다가 온점이나 스페이스처럼 비한글 문자를 입력하면서 조합을 종료시키면, 조합 중이던 한글이 덧난다. 가령, ‘다.’를 입력하다 보면 ‘다다.’가 된다.

이건 꽤 황당하고 심각한 버그인데 왜 아직까지 안 고쳐졌는지 이해가 안 된다. 게다가 윈도우 7은 출시된 지 이제 무려 3년이 다 돼 가지 않는가.
왜 세벌식일 때만 그렇냐고? 이 역시 B에서 설명되었듯, 비한글 문자를 처리하는 방식이 두벌식과 세벌식이 다르기 때문이다. 문자 입력 프로그램이 아니라 운영체제의 구조적인 버그이기 때문에 윈도우 7에서는 MS IME든 날개셋이든 동일하게 발생한다.

5. IME 2010, 콘솔에서 한자 후보 목록이 곧바로 나타나지 않음

이것은 약간 불편할 수는 있지만 그렇게 심각한 문제는 아니다. 콘솔에서 한글을 조합하는 중에 한자 키를 눌러 보면, 원래 한자 후보가 콘솔 창의 하단에 곧바로 떠야 하는데 뜨지 않는다.
물론 이 상태에서도 번호를 누르면 해당 한자로 바로 변환이 되며, 좌우 화살표 같은 페이지 전환 키를 누르면 그제서야 후보 목록이 나타난다. 뭔가 코딩 실수가 들어간 듯하다.

이 버그는 윈도우 7의 기본 한글 입력기에서도 존재하지 않으며, 한글판 MS 오피스 2010과 함께 설치된 한글 IME 2010에서만 나타나는 문제이다. 즉, 운영체제의 것을 대체하는 오피스의 IME가 오히려 버그를 포함하고 있는 셈이다.
<날개셋> 한글 입력기에는 물론 이런 문제가 없다.

Posted by 사무엘

요즘 학교나 관공서의 전산망에서는 인터넷 접속을 위해서 특정 보안 솔루션 ActiveX들과 그것도 모자라서 바이러스 백신까지 무조건 설치하라고 강요하는 걸 볼 수 있다. 그걸 안 하면 사이트 접속이 되질 않게 해 놓았다.  허나 본인은 그런 보안 솔루션들에 대해 정서적으로 굉장한 반감을 갖고 있으며, 그것들을 몸서리치게 싫어한다.

여러 보안 솔루션 중 키보드 보안 프로그램이 하는 역할은 아마도 사용자의 키 입력(비밀번호 같은)을 메시지 훅킹으로 가로챌 수 없게 하고, 반대로 없는 키 입력을 소프트웨어적으로 생성할 수 없게 하는 일일 것이다(온라인 게임에서 오토의 실행 차단). 또한, 은행 돈거래 관련 정보가 담긴 패킷은 정보가 유출되더라도 의미 파악이나 변조가 거의 불가능하게 아주 복잡한 계산을 동원한 암호화/해독이 클라이언트에서 행해져야 할 필요가 있을 것이다. 그런 기술적인 필요를 본인은 모르는 건 아니다.

다만, 웹 표준만으로 도저히 구현할 수 없는 운영체제 커널 기술 수준의 보안이 불가피하게 필요하다면, 차라리 무리해서 웹 애플리케이션을 만드는 걸 포기하고 깨끗하게 로컬 환경에서 돌아가는 exe 형태의 프로그램과 배포 패키지를 만들었으면 좋겠다.

nProtect 부류의 이상한 프로그램들은 웹브라우저를 끈 뒤에도 계속 메모리 차지하면서 남아 있는 것 정도나 보기 싫은 수준이고 그나마 ‘낫다’. 하지만 이놈의 빌어먹을 백신은 답이 없다. 바이러스나 악성 코드에 걸리지 말라고 설치하는 솔루션들이, 깔고 나면 악성 코드나 그 이상 수준으로 민폐 끼치면서 컴퓨터 성능을 쪽쪽 갉아먹기 때문이다. 좀 심하게 표현하면 컴을 완전히 병신으로 만들어 놓는다.

마치 치안과 국방을 담당해야 할 자국의 정규군이나 경찰이 하라는 일은 안 하고 자기네들부터 민폐 끼치고 민간인들을 등쳐 먹는다거나, 반공을 빌미로 공권력이 심심하면 멀쩡한 생사람을 빨갱이로 몰아서 잡아 죽인다거나 하는 상황을 생각하면 되겠다.

맥북 이전 4대 노트북을 쓰던 시절의 일이다. 본인이 다니는 학교는 내부에서 와이파이로 인터넷에 접속할 때 NetCare인지 뭔지 하는 보안 ActiveX와 바이로봇 백신을 반드시 설치하도록 강요를 하고 있다. 둘 중 하나라도 설치를 안 하면, 몇몇 사이트는 아예 접속이 되지 않거나 쿠키가 저장되지 않아서 로그인을 할 수가 없으며, 되는 사이트도 보안 솔루션들을 설치하라고 협박하는 문구가 든 프레임이 웹사이트에 제멋대로 추가되어 나오곤 했다.

그래서 본인은 어쩔 수 없이, 울며 겨자 먹기로 마지못해 깔라는 것들을 다 설치해 줬다. 그러자 저런 성가신 현상이 모두 없어지고 인터넷은 잘 되기 시작했다. 그러나 그 뒤부터 내 컴에서는 끔찍한 헬게이트가 시작되었다.

부팅 직후에 시스템이 시작 메뉴 구동 같은 각종 조작에 응답하는 속도가 눈에 띄게 느려졌고, 웹브라우저가 페이지를 여는 속도, 전반적인 파일 액세스 속도도 인내심의 한계를 느끼는 수준이 되었다. 최대 절전 모드에서 복귀하는 시간까지 예전보다 훨씬 더 길어졌다. 멀쩡하던 컴퓨터가 진짜 만신창이 장애인이 된 느낌이었다. 평상시에 운영체제의 메모리 사용량도 예전보다 수십 MB가량 늘었다.

나는 운영체제의 업데이트들은 목록만 자동으로 받게 한 뒤, 다운로드와 설치는 내가 지정한 것만 수동으로 하게 해 놓고 있었다. 그랬는데 그 보안 솔루션은 나의 설정을 씹고, 인터넷만 됐다 하면 마구잡이로 온갖 업데이트들을 제멋대로 받아서 설치했다.

언제부턴가 MS 오피스가 SP2이던 게 느닷없이 SP3으로 바뀌어 있었다. 프로그램이 버전업되어서 좋은 게 아니라 도리어 부아가 치밀었다. “이 자식, 지금까지 왜 이리 느리고 쓸데없이 디스크 액세스를 하는가 했더니, 그 수백 MB짜리 업데이트를 내 동의도 없이 제멋대로 설치하느라 그랬군.” 하는 생각에 말이다.

참다못해 하루는 넷케어고 백신이고 전부 다 모조리 지워 버렸다. 요즘은 백신도 용량이 몇백 MB 수준으로 뭘 하느라 그리도 커졌는지 모르겠다. 이것들을 다 지우고 나자 내 컴퓨터는 거짓말처럼 평화가 찾아왔다. 모든 성능이 예전 상태로 돌아갔다. 보안 솔루션들이 그들의 퇴치 대상인 악성 코드가 하는 짓을 동일하게 하고 있음이 입증된 순간이었다.

이제 맥북을 사용하면서 뜻하지 않게 얻은 큰 수확이 있다. 보안 솔루션 제약은 Windows 운영체제에만 적용되며, 맥에서는 그런 게 전혀 없이도 인터넷을 곧바로 자유롭게 이용할 수 있다는 것. 야호! 빌어먹을 넷케어니 바이로봇 따위를 설치하지 않아도 된다. 맥OS가 날 구했다. 스잡빠니 애플빠니 난 그딴 건 모르지만, 어쨌든 이거 덕분에 맥OS 호감도가 급상승했다.

한편, 고향에서도 비슷한 일을 최근에 겪었다. 고향집 컴퓨터가 언제부턴가 병신 중의 상병신이 돼 있었다. 부팅 후에 시작 메뉴를 눌러도 한참 동안 반응이 없고, 웹브라우저를 띄운 뒤에 창이 나타나기까지 몇 분이 족히 걸리고 있었다. 레지스트리나 파일 디렉터리를 살펴봐도 딱히 악성 코드에 걸린 것 같지는 않은데 영문을 모를 노릇이었다.

이 현상의 주범은 바로 V3 Lite였다. 이놈을 당장 지우자 컴퓨터는 운영체제를 갓 설치한 직후처럼 아주 쌩쌩해졌다! 그러니 난 도대체 진짜 악성 코드란 어떤 놈인지 가치관의 혼란을 겪을 수밖에 없었다.

바이러스가 묻은 메일 첨부 파일을 클릭한 것도 아니고, 이상한 사이트를 돌아다니다가 ActiveX 설치에 ‘예’를 누른 것도 아니었다. 이 V3은 어머니께서 집에서 인터넷으로 업무를 보시기 위해 어쩔 수 없이 설치한 것이었다. 이거랑 무슨 희한한 듣보잡 ActiveX들을 설치하지 않으면 직장의 업무 자동화 시스템에 접속이 되질 않기 때문이었다.

이런 일련의 사건을 겪은 뒤, 나는 더욱 더 백신 따위는 죽어도 절대로 쓰지 말아야겠다는 생각을 굳게 하게 되었다. 옛날처럼 백신이 그냥 사용자가 요청할 때만 파일이나 메모리를 스캔하면서 바이러스 검사를 해 주던 시절이 그립다. 저런 거지 같은 잉여 쓰레기 프로그램을 얹고도 작업을 원활하게 하려면, 가히 정말 최신식 최고급 컴퓨터를 써야겠다. 아니, 내 컴퓨터가 아무리 빠르고 메모리가 썩어 넘친다 해도 저런 프로그램에게 컴퓨터 자원을 내어 주기는 싫다.

보안을 빌미로 원치 않는 프로그램의 설치를 강요하는 이런 못돼먹은 풍조가 좀 없어졌으면 하는 바람이 있다. 이런 일이 계속될수록 이에 대한 반발 심리로 나의 컴퓨터 보안 위협 불감증은 더욱 커질 것이다.

Posted by 사무엘

전산학 전공자 내지 IT 분야 종사자에게는 상식으로 통용되는 당연한 개념이다만..
오늘날 범용(generic-purpose) 컴퓨터에서 돌아가는 소프트웨어는 크게 세 가지 형태로 나뉜다.

1. 로컬

흔히들 PC로 대표되는 컴퓨터에서 stand-alone으로 동작하는 전통적인 프로그램이다. Windows야 그렇다 치더라도 오피스, 비주얼 스튜디오 같은 업무용 프로그램은 아직 로컬 프로그램의 아성을 무너뜨릴 영역이 없다.
가장 역사가 길고, 가장 빠르고 효율적으로 동작하며, 특정 컴퓨터 아키텍처(기계어)와 운영체제의 실행 파일 포맷에 종속적이다. 그래서 이쪽 개발 환경은 전통적으로 C/C++ 같은 저수준 최적화 언어가 강세이다.

물론 클라이언트가 아닌 서버 프로그램은 성격이 약간 다르긴 하나, 서버 프로그램 자체는 역시 서버라는 로컬 컴퓨터 자신의 자원만을 이용하여 동작한다. 여객 운송과 화물 수송의 차이와 비슷한 맥락이다. 그리고 사실은, 다음에 설명할 2.웹 프로그램을 돌려 주는 기반도, 클라이언트든 서버든 1.로컬 프로그램들이 다 마련해 주고 있다. 그러니 로컬 프로그램은 앞으로도 없어질 수는 없다. 단지 전체 소프트웨어에서 차지하는 비중이 줄어들 뿐이다.

옛날에는 불특정 개인 사용자를 대상으로 하는 상업용 제품은 패키지 형태로 발매되곤 했지만, 오늘날은 인터넷의 발달과 극심한 불법 복제로 인해 이런 전통적인 형태의 배포의 비중이 굉장히 줄어들었다. 오늘날 국산 패키지 소프트웨어는 아래아한글과 V3 말고 있나? -_-;; 또한 보안 위협으로 인해 이런 프로그램 역시 한번 설치하고 끝이 아니라 끊임없는 보안 패치와 업데이트의 필요성이 커져 있기도 하다.

2. 웹

개인용 컴퓨터의 성능이 굉장히 향상되고 그에 따라 웹 표준이 발달하면서 웹브라우저, 정확히 말해 WWW는 단순히 그림과 하이퍼링크가 동원된 문서라기보다는 거의 프로그래밍 플랫폼처럼 오래 전부터 바뀌었다.

웹 프로그래밍의 최대 매력은 로컬을 월등히 능가하는 범용성과 기계 독립성, 생산성이다. 브라우저에서 사이트 접속만 하면 바로 실행..;; 마치 게임처럼, 클라이언트와 서버, 코딩과 디자인 등을 두루 아우르는 종합 예술처럼 보이기도 한다. 가령, 옛날에는 GWBASIC이나 LOGO로 어린 학생들에게 그래픽 프로그래밍 교육을 시켰다면, 지금은 그냥 HTML5만 써도 될 것이다.

물론, 로컬 개발에 비해서는 혼자 독립적인 작품을 만든다는 느낌이 좀 덜 들며-_-, 기술이 아직까지 안정화해있지 않은 면모가 있고, 로컬 컴퓨터 자체를 세밀하게 제어할 수 없으며 성능이 떨어진다는 한계도 있다. 가령, 오피스 제품군이 웹 애플리케이션으로 완전히 대체될 날은 과연 글쎄?
그러나 앞으로 웹 프로그래밍의 비중은 절대 무시 못 할 것이고 수요도 없어지지 않을 것이다.

3. 앱

스마트폰에서 동작하는 '로컬' 프로그램이라고 볼 수 있지만, 그 성격이 역시 1과는 사뭇 다르다.
스마트폰 자체는 PC보다 성능이 떨어지기 때문에, 로컬에서 모든 처리를 마친다기보다는 서버에다 input을 보내서 받은 output을 보여주는 형태의 앱이 많다. 또한 스마트폰은 화면이 작고 PC 같은 빠른 문자 입력을 할 수 없기 때문에, PC와는 다른 독자적인 GUI가 필요하다. 터치스크린은 마우스와 완전히 동일한 포인팅 UI가 아니다. (대표적으로 hovering이란 게 없다) 다만, PC에는 없는 기울임, 흔들림, 방향, 현재 위치 같은 특수한 입력을 받아들일 수 있다.

스마트폰은 PC만치 사용자가 컴퓨터 내부를 완전히 손쉽게 제어할 수 있는 물건은 아니다. 그래서 PC용 프로그램보다는 더 엄격한 과금 체계를 갖추고 프로그램을 배포하여 수익을 낼 수 있다.
스마트폰 앱은 역사가 짧기 때문에 PC 같은 지저분한 호환성 잔재 같은 게 덜하고, 일찍부터 자바든 C#이든 객체지향 언어와 가상 기계 바이트코드 기반의 프로그래밍 환경이 잘 구축돼 있다. 깔끔한 최신 프로그래밍 인프라가 기본으로 제공된다는 뜻이다.

오늘날 스마트폰 CPU는 ARM 아키텍처밖에 없지만, 그래도 커널 말고 다른 응용 프로그램들은 네이티브 코드가 아니다. 그런 .NET이나 자바 같은 가상 기계 자체가, 1~3(로컬, 웹, 앱) 사이의 이질감을 낮추고자 만들어진 것이기도 하고 말이다.
아울러, CPU의 성능이 좋아졌을 뿐만 아니라 LCD 디스플레이 소자가 보편화하고 통신 기술이 발달하면서 스마트폰 같은 물건도 대중화될 수 있었다.

20세기 중반까지만 해도 컴퓨터는 곧 메인프레임-단말기 모델이었다.
컴퓨터라는 게 무진장 비싼 물건이고 자원이 귀하다 보니, 모든 처리는 중앙 컴퓨터에다 맡기고 각 사용자는 단말기로 서버에 접속해서 명령 프롬프트에서 서버의 기능을 사용하곤 했다. 그때는 컴퓨터는 대학, 연구소, 정부 기관, 군대의 전유물이었고, 개인용 컴퓨터라는 개념을 감히 떠올리기조차 쉽지 않았었다. (알파넷이 미국이 아닌 소련에서 발명되었다고 생각해 보자. 그게 오늘날의 인터넷으로 발전할 수 있었을까? -_-)

그러다가 20세기 말에는 PC가 대세가 되었다. 개인용 컴퓨터 하나만으로 어지간한 일은 다 할 수 있게 되었다. 비유하자면, 만원버스에 시달리면서 출퇴근하다가 번듯한 자가용이 생긴 셈.
PC의 사고방식으로는 소위 PC 통신은 어쩌다 한 번씩만 다른 컴퓨터에 접속하는 특별한 작업이며, 웹브라우저 역시 오피스 패키지처럼 별도로 구입해서 사용하는 특수한 프로그램일 뿐이다.

그 후 오늘날 대세라고 회자되고 있는 건 일명 클라우드 컴퓨팅이다. 개인용 컴퓨터가 무진장 작아지고 통신 인프라가 발달한 덕분에, 예전처럼 부족한 자원을 공유하려고 컴퓨터들을 연결하는 게 아니라 진짜 유비쿼터스 세상이 돼서 컴퓨터들을 연결한다. PC 통신 시절에만 해도 하이텔 단말기가 있었는데 오늘날의 스마트폰에 비하면 얼마나 격세지감인가!

전세계 컴퓨터가 다 인터넷에 연결되고 클라이언트와 서버의 구분이 무의미해지고, 궁극적으로는 (거의) 모든 작업이 웹 프로그램만으로 해결되고 모든 자료가 웹에 저장되는 세상이 온다. 예전에는 PC끼리 자료 전송을 위해서 플로피 디스켓이나 USB 메모리를 썼는데, 이제는 사용자의 로컬 컴퓨터나 스마트폰 그 자체가 플로피 디스켓이나 USB 메모리와 마찬가지가 된다는 뜻.

이걸 역시 자동차에다 비유하자면 이렇다. 사람이 직접 자가운전을 하니까 교통사고가 발생하고 도로가 막히고 여러 문제가 생기다 보니, 전세계 도로가 한데 통제되고 지능형 임대 자가용이나 궤도 교통수단이 생겨서 모든 사람들이 그걸 간단히 이용하는 형태가 된 셈이다.
물론 이게 온전히 실현되려면 시스템적으로나, 보안 쪽으로나 해결해야 할 문제가 많다.

Posted by 사무엘

본인의 고향집에 있는 부모님께서 사용하시는 PC는 내가 쓰는 PC보다야 훨씬 더 구닥다리 기종이다.
몇 년 전까지만 해도 펜티엄 3에 램은 192MB인 윈도우 2000/ME급 사양이었다. 완전 골동품..;;

그런데 컴퓨터에 이상이 생겨서 서비스를 받고 났더니, 도대체 누구에게서 서비스를 받았는지는 모르겠지만 저 컴퓨터에 윈도우 XP가 깔려 있었다.;;
잘 알다시피 XP는 못해도 램이 256MB 정도는 돼야 쓸 수 있는 덩치이지 않은가. 부팅에서부터 간단한 인터넷 확인을 하기까지 걸리는 시간이 본인의 인내심의 한계를 느끼게 했다.

결국 본인은 내가 대학 학부 시절에 쓰던 펜티엄 4 + 램 512MB짜리 컴으로 PC를 교체해 드렸다. 부모님이야 진짜로 간단한 인터넷 접속 + 워드 작업밖에 안 하시기 때문에 기계가 물리적인 고장만 안 난다면 이 컴을 앞으로 10년-_-은 더 쓰실 법도 해 보였다. 한때 내가 개인 작업용으로도 쓰던 컴이었으니, 인계 당시 최적화는 잘 되어 있었고 윈도우 XP의 체감 속도는 씽씽 날아다니는 수준이었다.

그러나 행복은 오래 가지 못했다.
언제부터인가 고향에 가서 확인해 보니, 악성 코드가 덕지덕지 달라붙어서 컴의 성능을 다 깎아먹고 있었다.
부팅 직후에 시작 메뉴를 열어서 웹브라우저를 띄울 때 운영체제가 굼뜨는 모습이 꼭 옛날의 램 192MB짜리 컴을 쓰던 것과 비슷했다. 램이 그보다 두 배 이상 더 많은 컴에서 말이다.;;

시스템 정보 → '로드된 모듈'을 보면 정체 불명의 이상한 dll이 explorer.exe 내지 iexplore.exe에 달라붙어 있었고, 파일을 지우고 레지스트리를 아무리 정리해도 이런 파일은 재부팅 후에 잡초처럼 계속 생겨나곤 했다.
USB 포트로 메모리 스틱이나 외장 하드를 이 컴에다가 꽂았다가 빼서 확인해 보면, 역시나 루트 디렉터리에 이상한 exe와 autorun.inf가 생겨 있었다.

나는 이런 부류의 악성 코드들이 운영체제에 어떤 방식으로 기생하는지, 어떻게 전염되는지 기술적 디테일을 전혀 알지 못한다.
내 컴퓨터에 지금까지 그런 것들이 침입한 적이 없으며, 내가 스스로 대처한 경험이 없다. 난 내 컴에 백신도 전혀 안 깔고 지낸다.

저런 악성코드를 완전히 뿌리뽑는 방법을 모르기 때문에, 본인은 집 컴의 C:를 그냥 밀어 버리고 운영체제를 다시 설치했다. 사실, 컴퓨터의 상태가 굉장히 안 좋기도 했다.
마침 내가 대학 시절에 만들어 놨던 윈도우 XP sp0(-_-) 원본 씨디가 있어서 그걸 썼다.
XP sp2 통합 씨디 이미지를 갖고 있긴 하지만, 또 씨디 굽기가 귀찮아서..;;
허나 그것이 본인에겐 고난의 시작이었다..;;

운영체제 자체의 설치는 40분 남짓한 시간 만에 별 탈 없이 됐다.
그래픽 카드는 nVidia GeForce의 완전 구닥다리 초창기 모델이어서 그런지, 별도의 드라이버를 설치할 필요조차 없이 운영체제가 알아서 잡아 줬다.
원래 그래픽 카드가 잡혀 있지 않으면 그냥 800*600 슈퍼 VGA의 제일 기본 VBE 모드만 가능하다. 그것보다는 약간 나아진 셈이다.

그리고, XP 이전 2000 이하의 OS는 그래픽 카드 드라이버를 설정 안 하거나 안전 모드로 부팅한다거나 하면, 아예 640*480 16컬러 VGA밖에 지원되지 않았으니 그 시절은 참 어지간히도 암울했었다. 단, 덧붙이자면, 9x 계열과는 달리 2000은 원시적인 16컬러 VGA에서도 화면이 바뀌는 곳에서 마우스 포인터가 깜빡거리는 현상이 없던지라, 얘는 하드웨어 제어를 어떻게 하는지 본인은 개인적으로 궁금증이 들곤 했다. 이것이 NT 커널의 위력인가..?

악성 코드 없이 광속으로 반응하는 청정 OS를 써 보는 기쁨도 잠시. 새 OS는 인터넷이 되지 않았다. 20세기의 유물로 전락한 전화 걸기 대화상자가 뜨는 걸 보고 경악했다.
어라? 네트워크가 전혀 설정되어 있지 않았고, 장치 관리자에 가 보니 이더넷 컨트롤러의 드라이버가 정체 불명이라고 찍혀 있었다.

본인의 컴퓨터 하드웨어 지식은 “요즘은 랜 카드나 사운드 카드는 다 마더보드 내장인데 OS가 알아서 다 잡아 주지 않나?” 정도에 머물러 있었다. 그래서 생각한 두 가지 카드는 다음과 같았다.

1. 2001년에 나온 구닥다리 SP0이어서 못 잡는 것이 아닐까? SP2를 따로 설치하면 아마 자동으로 잡힐 것이다. (잘 알다시피 윈도우 XP SP3은 SP1 이상을 요구하며, SP0에서 바로 설치 못 함)
2. 아니면, 이 컴퓨터의 랜 카드의 메이커가 뭔지는 모르겠지만 Realtek 브랜드의 드라이버 아무거나 설치해 주면 될 것이다.

사실, 최신 운영체제는 무엇보다도 최신 하드웨어의 지원 능력면에서 구버전보다 우월하다. 이 점에서는 심지어 과거의 윈도우 ME도 98 SE보다 훨씬 더 낫다. 98만 해도 드라이버를 따로 설치 안 하면 USB 메모리조차 인식을 못 하기 때문이다.

그래서 250여 MB에 달하는 SP2 설치 파일을 다른 곳에서 애써 복사해 오고, 내가 아는 랜 카드 드라이버를 몇 개 구해서 설치해 봤다. 하지만 두 시도 모두 실-_-패로 끝났다. 특히 SP2는 이 운영체제가 어둠의 경로-_-로 설치된 거라는 걸 알기라도 했는지 제품 시리얼 번호를 갖고 트집을 걸면서 더 진행을 거부하였다.

이런 와중에 새 OS는 설치된 지 불과 몇십 분 만에 또 악성 코드에 감염됨으로써 나에게 충격과 공포를 안겼다. 인터넷이 아예 안 되는 컴퓨터가 어떻게 그렇게 될 수 있는가...????

범인은 아까 그 프로그램들을 복사· 설치하기 위해 꽂은 어머니의 USB 메모리였다. 그 메모리는 이미 예전 컴퓨터로부터 악성 코드가 묻을 대로 묻어 있었을 것이고, 가만히 생각해 보니 USB 메모리의 autorun을 실행하지 않게 하는 윈도우 보안 패치는 생각보다 한참 뒤에 발표되었다. 그리고 이 컴퓨터의 OS는 업데이트 하나 없는 XP sp0으로, 온갖 보안 결함에 무방비로 노출되어 있는 호구이지 않던가. 이런 우라질레이션..;; -_-;;

도대체 CD롬도 아니고, 디스켓이나 다름없는 USB 메모리를 꽂기만 하면 자동으로 autorun이 돌아가게 해 놓은 친구는 무슨 생각으로 그런 기능을 넣었는지 모르겠다.. 키보드 입력을 버퍼 크기 제한도 없이 받아들이는 C언어의 gets 함수만큼이나 보안 면에서 멍청하고 위험한 디자인이 아닌가?

그런 주제에 윈도우 XP의 설치 프로그램은 설치 도중에 자기 운영체제와 웹브라우저에 대해서 '가장 강력하고 보안이 뛰어나다'고 자화자찬을 늘어놓고 있으니 그 어이없음에 웃음이 나올 뿐이었다. 뭐, 10년 전에 그랬다는 소리니까 봐 주자.;; 9x 계열이 갖고 있던 자유도와 유닉스 계열의 엄격함과 탄탄함(robustness)은 동시에 충족될 수 없는 이율배반적인 이념이니까 말이다.

이미 시스템 정보에는 악성 코드 DLL이 올라가 있었고, 레지스트리에서는 역시 정체 불명의 실행 파일이 시작 프로그램으로 등록되어 있었다. 탐색기에서 드라이브를 열 때의 동작 방식도 이상하게 바뀌었다.
악성 코드를 없애려고 운영체제를 재설치했는데 일이 꼬여서 이렇게 되었고 랜 카드도 전혀 잡히지 않았으니, 본인은 난감하지 않을 수 없었다.

결국, SP2가 적용된 윈도우 XP 원본 씨디를 또 만들었다. 귀찮아서 안 하려 한 짓을 결국은 하게 됐다. 그리고 그걸로 XP SP0을 밀고 윈도우를 또 새로 설치했다. 그래서 악성 코드는 노아의 홍수와 같은 심판으로 또 없애 버렸지만, SP2로도 랜 카드는 여전히 잡히지 않았다.

참다못해, 이놈의 랜 카드의 정체가 뭔지 파악하기 위해 컴퓨터의 케이스를 개방해야 했다. 랜 카드는 ASUS 마더보드 내장형이었는데, 모델명별로 자기만의 랜 카드 드라이버가 따로 있는 모양이었다.
장치 관리자에서 드라이버를 이걸로 업데이트하자 드디어 네트워크 설정이 잡히고 인터넷이 되기 시작했다. 휴우... 이런 경험은 난생 처음이었다.

인터넷이 되니 이제 큰 불은 껐다. 다른 소프트웨어를 설치하기 위해 가상 CD 구동 프로그램을 설치하고, 그리고 구닥다리 IE6을 당장 IE8로 교체했다. 세상에 컴퓨터 역사상 굴지의 IT 기업들이 앞장서서 “고객님, 제발 이 버전 쓰지 말고 업그레이드 하세요!”라고 하소연을 하고, 너무 오래 살아남아서 죽지 못해 사는 좀비처럼 된 소프트웨어가 IE6 말고 또 있을까?

비주얼 C++ 6도 너무 오래 살아 있는 소프트웨어이긴 하지만, 일단 이건 불특정 다수가 쓰는 프로그램은 아니고. 그런데 요즘은 어느샌가 IE 7마저도 이제 지원 안 할 거니까 업글하라고 눈칫밥을 주는 웹사이트가 하나 둘씩 생기고 있다.

IE 7이나 8을 XP에서 첫 설치하려면 무슨 IME의 동작과 관련된 운영체제 패치부터 먼저 설치해야 한다는 걸 처음 알았다. IE는 잘 알다시피 문자 입력과 관련된 괴이한 현상이 심심찮게 존재하는데, 역시 서로 민감한 부위를 건드리긴 하는가 보다.
플래시 메모리에 묻어 있는 악성 코드도 못 걸러내는 주제에, 웹브라우저가 자동 다운로드 기능을 차단하는 건 본인은 개인적으로 굉장히 불편했고 헛다리 짚는 듯한 느낌이었다. 필요한 팝업창을 차단해서 불편한 것보다 더 불편했다.

이런 식으로 컴퓨터를 대강 세팅했다. 고향에서 맨날 밥만 얻어먹고 가는 게 아니라 이번엔 고향집 컴퓨터를 깔끔하게 정리하고, 아버지 차에다가 내 돈으로 기름도 몰래 채워 넣는 등, 이쁜 짓(?)도 좀 하고 왔다. ^^;;
허나, 내년 설날에 고향에 가 보면 또 컴퓨터에 악성 코드가 덕지덕지 묻어 있을 것 같다. -_-;;; 혹시 부모님 직장의 컴들은 이미 다 오염돼 있지는 않나 모르겠다. 여쭤 보니 운영체제도 비스타/7이 아니라 XP라던데.. 더욱 걱정된다.

글을 맺으며..;;

1. 이번 일을 계기로, 보안 패치 없는 윈도우 XP는 정말 쓰레기라는 걸 체험했으며, 컴퓨터 환경에 따라서는 랜 카드도 저렇게 잡아 줘야 한다는 걸 알게 됐다.

2. 옛날에 윈도우 9x는 설치 GUI가 아예 윈도우 3.x 엔진 기반이었다. 그리고 9x만의 특징인데, 오래 쓰다 보면 가끔 메뉴의 ▶ 모양이라든가 윈도우의 버튼들이 숫자· 문자로 바뀌는 기괴한 버그가 나타나곤 했다. 아무리 옛날에 PC 환경이 열악했다고 해도, 그런 허접하고 불안한 운영체제를 어떻게 몇 년간 썼는지 놀랍기 그지없다.

3. 악성 코드는 정말 구제역 같은 느낌이 든다. 컴퓨터 보안 쪽으로 더 알고 싶다.

4. 윈도우 비스타가 깔린 본인의 컴은 데스크톱과 노트북 모두 3~4년째 OS의 재설치 없이 악성 코드 청정 지대이며, 이상 무이다.

Posted by 사무엘

서식을 지원하지 않는 단순한 텍스트 에디터를 워드 프로세서로 발전시키려면 무슨 작업이 필요할까?
뭐니뭐니해도 글자마다 서식을 달리 지정할 수 있어야 한다. (서체, 속성, 크기, 색깔 등등)
그런데 그걸 구현하는 과정에서 개념적으로 굉장히 중요한 결정을 내려야 하는 게 있다. 바로, 장치 독립적인(device-independent) 레이아웃을 구현하는 것이다.

장치 독립이란, 표시 화면의 해상도(=확대 배율)와 관계없이 글자들의 비율과 위치가 일정하게 유지되는 걸 말한다. 쉽게 말해 위지윅(WYSIWYG)이다. 요즘 워드 프로세서에서는 필수인 이 기능을 지원하기란 장치 종속 레이아웃보다 훨씬 더 어렵다.
우리에게 잘 알려져 있는 장치 종속 레이아웃과 장치 독립 레이아웃의 예는 다음과 같다.

장치 종속적 레이아웃: 웹브라우저 화면. MS 엑셀. MS 워드의 웹/개요 모드, Draft/normal view. 워드패드
장치 독립적 레이아웃: MS 워드의 인쇄 모드(print layout) view. 아래아한글, Acrobat PDF, 그리고 모든 프로그램들의 '인쇄 미리보기 (print preview)'

차이를 아시겠는가?

WWW
iiiiiiiiiiiii

가변폭 글꼴로 두 줄에 W와 i를 비슷한 폭이 되는 개수로 찍은 뒤(당연히 i의 개수가 훨씬 더 많아짐),
화면 배율을 아주 작게 줄였다가 아주 크게 확대해 보라.
W와 i의 폭의 편차가 크면 장치 종속적인 레이아웃이고,
대체로 전반적인 배율은 잘 유지되지만 그 대신 작은 크기에서 i들끼리의 픽셀 간격이 들쭉날쭉하다면(저해상도에서 보정을 위해 어쩔 수 없이) 그건 장치 독립적인 레이아웃이다.

엑셀을 실무에서 오래 써 본 분들은 이미 아시겠지만, 엑셀은 심지어 Page layout view에서도 위지윅이 전혀 보장되지 않기 때문에 화면에서 보는 글자의 폭과 인쇄해서 보는 글자의 폭의 차이를 유의해야 한다.
화면으로 보기 좋게 글자수나 폭을 맞춰 놓은 것은 인쇄를 하거나 심지어 확대 배율만 바꿔 봐도 모조리 어긋나 버리기 때문이다.
편집 화면이 아니라 오로지 '화면 인쇄'만이 장치 독립성이 보장되는 결과를 보여준다.
엑셀은 대용량의 데이터를 수월하게 다루기 위해서, 성능상의 이유로 위지윅 편의는 희생한 셈이다.

요즘 워드 2007은 처음 시작했을 때 인쇄 모드 view로 시작하지만, 옛날, 한 97~2000 버전까지만 해도 print layout이 아니라 normal view가 기본 모드였다. 아래아한글은 비슷한 개념으로 '쪽윤곽' 옵션이란 게 있어서 둘의 차이는 화면에 용지의 여백이 나타나 보이는지의 여부가 고작이지만, 워드의 normal view는 print layout view보다 훨씬 더 이질감이 컸다. 그림이나 표 같은 틀이 제 위치에 표시되지 않고 다단(column)이나 세로쓰기 같은 건 아예 무시되었으니까...;; 그리고 근본적으로 normal view는 앞서 말했듯이 위지윅이 보장되지 않는다.

이런 view가 기본 mode였던 이유는 두말 할 나위도 없이.. normal view가 문서를 훨씬 덜 정교하게 대충 렌더링하기 때문에, 처리 속도가 훨씬 더 빠르기 때문이었다.
normal에서 신나게 긴 글을 편집하고 있다가 print layout으로 처음으로 모드를 바꾸면, 워드는 “페이지를 정돈하고 있습니다. 잠시 기다려 주십시오”라고 뜸을 들이곤 했다.

장치 독립적인 레이아웃에서는 여백이나 글자 크기 따위를 나타낼 때 픽셀이 아니라 어느 매체에서도 동일한 절대적인 단위가 쓰인다. 그래서 아래아한글이라든가 PDF 같은 문서 파일 포맷 스펙을 보면 그런 개념을 찾을 수 있으며, 아래아한글의 경우는 1/n 인치가 최소 단위였지 싶다.

운영체제 API는, 해상도가 서로 넘사벽급으로 다룬 모니터와 프린터를 모두 동일 코드만으로 수월하게 다루기 위해서 다양한 추상적인 좌표계와 확대 배율을 지원하며, WM_PAINT뿐만이 아니라 WM_PRINT 같은 (잘 알려지지 않은) 메시지도 제공하고 있다.
MFC가 OnPaint말고 OnDraw라는 화면· 프린터 통합 메소드를 제공하는 것 역시 다 이유가 있어서인 것이다
.
흠, 그러고 보니 나도 포스트스크립트나 '텍' 같은 전자 조판 언어를 공부하고 싶긴 한데, 접할 기회가 없구나.;;

Posted by 사무엘

본인은 윈도우 플랫폼용 한글 입력기의 개발자이다. 그런데 진짜 옛날 도스 시절, 텍스트 모드가 따로 있던 시절에 한글 입출력 바이오스 같은 건 어떻게 구현했는지가 무진장 궁금해질 때가 있다.
출력은 그렇다 치더라도 입력은 어떻게 구현했을까? 게다가 한글도 모자라서 한자 입력은?
그리고 한글 정도면 양반이지 도스 시절에 일본은 사정이 어땠을까? 한자 변환까지 포함한 일본어 입력이 가능했을까? -_-;;

IBM 호환 PC는 그렇게 그래픽에 최적화돼 있지도 않던 놈이었고.. 영어 아스키 코드밖에 모르는 이런 기계에다가 없는 문자를 찍기 위해서는 막대한 양의 오버헤드가 필요했다.

요즘은 잘 알다시피 사운드 카드, 랜 카드 따위는 마더보드에 통합되어 버린 지가 오래이고 GPU, PPU 같은 거나 별도로 부착하는 CPU 애드온이다. (그리고 이마저도 요즘은 본격 통합 기세-_-)
허나 한 25~30년 전에는 한글 카드라는 별도의 하드웨어가 있을 정도였다. '한글 도깨비'. 그때는 그만큼 컴퓨터의 성능이 열악했다.

한글 입출력 바이오스를 만들려면, 일단 바이오스의 글꼴을 다른 걸로 대체할 수 있을 정도로 하드웨어에 정통해야 했고 메모리 사용량이든 계산량이든 극도의 최적화 작업이 필수였다. 한글 모드에서는 텍스트의 스크롤 속도가 한 2, 30% 정도 감소하는 효과가 있었기 때문. -_-;; 더구나 기본 메모리 640KB는 그야말로 1K라도 아껴야 하는 귀중한 영역이기 때문에, 한자 글꼴 같은 건 XMS/EMS 같은 확장 메모리에다 저장하는 테크닉도 필수였다.

VGA의 기본 텍스트 모드는 잘 알다시피 가로 80글자, 세로 25글자이다. 그런데 아주 신기하게도 한 글자의 크기는 너무나 컴퓨터스럽게 잘 떨어지는 8*16이 아니라, 9*16이다. 그리고 화면 해상도는 640*400도, 640*480도 아니요 720*400이다. 정작 mode 12H 같은 그래픽 모드 중에는 640을 넘는 해상도가 없던 시절이었는데 왜 텍스트 모드만 한 글자의 폭이 8이 아닌 9였는지는 모르겠다.
한글 바이오스들은 16*16 크기의 한글· 한자 글꼴을 사용했으며 640*400 해상도의 텍스트 모드에서 동작했다.

그뿐만이 아니다. 그때 VGA 텍스트 모드에는 화면 전체의 테두리 색이라는 게 있었다! 베이직에서 COLOR문은 보통 글자색과 배경색을 의미하는 A,B만이 쓰이는데, 셋째 인자도 있어서 이걸 지정하면 화면의 테두리에도 색깔을 줄 수 있었다. 이런 기능을 누가 썼고 왜 만들었는지는 모르겠지만...
이건 DosBOX나 VMware 같은 에뮬레이터들도 지원 안 하고 있는 기능이다.
그 테두리가 차지하는 픽셀 수는 얼마나 됐을까? 이것까지 감안한 화면 해상도는 얼마였을지를 생각하면 옛날에 비디오와 관련된 하드웨어 제어는 심오함 그 자체였겠다는 생각이 든다.

텍스트 모드의 바이오스 글꼴을 다루는 테크닉을 구사한 프로그램은 흔치 않았다. 도스용 노턴 유틸리티(Norton Utility)는 이걸 환상적으로 조작해서 텍스트 모드에서 준 GUI 수준의 비주얼을 만들고 심지어 그래픽 모양의 마우스 포인터까지 구현하는 용자짓을 했다. 그리고 Screen Thief라는 캡처 프로그램은 당시로서는 흔치 않게 텍스트 모드를 색깔과 바이오스 글꼴까지 감안한 실제 그래픽 화면 픽셀 그대로 캡처하는 기능이 있었다.
뭐, 한글 바이오스가 구동된 상태에서 노턴 유틸리티 같은 프로그램을 GUI 모드로 동시에 실행했다간 '영 좋지 않은 곳에 하드웨어 접근이 일어나서' 대략 불상사가 발생했겠지만 말이다. "내 컴이 다운이라니!!"

그때는 마우스의 존재 여부를 알아오는 테크닉만큼이나 한글 바이오스의 존재 여부를 알아오는 테크닉도 있었고
이는 텍스트 모드에서 실행되는 프로그램이 선문자를 깨지지 않고 맞게 출력하기 위해서 필수였다. 도스용 V3이나 MDIR 같은 프로그램들 말이다.
그러고 보니 한글 모드에서는 아스키 번호 1~31번 제어 문자도 원래 얼굴 모양 등 각종 도형이던 게, 1바이트 선문자로 바뀌었던 것 같다.

당연한 말이지만, 한글 바이오스는 바이오스의 글자 크기가 8*16이기만 하면, 텍스트가 아닌 그래픽 모드에서도 물론 동작했다.
하지만 그래픽 모드에서까지 텍스트를 찍는 프로그램은 전혀에 가깝게 없을 테니 이건 그리 의미는 없는 기능이었다.
그래픽 모드에서 동작하던 프로그램이 crash가 발생하는 바람에 그 상태 그대로 도스로 빠져나가서 도스 프롬프트가 찍힌 게 아닌 이상 말이다.
텍스트 모드에서는 cursor가 아주 빠르게 깜빡거렸지만 그래픽 모드에서는 cursor가 깜빡이지 않는다는 중요한 차이가 있었다.

그럼, 말이 나온 김에 옛날에 접했던 도스용 한글 바이오스들을 추억 차원에서 몇 개 예나 좀 들어 보자.

1. 본인이 난생 처음으로 접했던 IBM 호환 PC는 대우 전자에 개발한 286 AT였는데, config.sys의 DEVICE 문을 통해 구동하는 자체(대우에서) 개발 소프트웨어 기반 한글 바이오스가 들어있었다. 즉, 일단 load된 후엔 메모리에서 제거하는 방법이 없어서 불편했다. (그 당시 sys 파일은 com 실행 파일과 기술적으로 비슷한 구조가 아니었겠나 싶다.)
Alt+한영을 누르면 한글 바이오스 메뉴가 떠서 영문 전용/조합형/완성형 같은 모드를 바꿀 수 있었고, Alt+한자를 누르면 일시적으로 영문 전용 모드로 전환할 수 있었다.
대우 전자에서 개발한 만큼, 조합형과 완성형뿐만이 아니라 당시 악명 높던 DH 완성형도 지원했는데, 얘는 알파벳 소문자+대문자를 묶어서 한글을 표현하는 경우도 있었던 걸로 기억한다. 물론 한글 코드의 표준화가 일단락되면서 깔끔하게 묻혀서 역사 속으로 사라졌지만.

텍스트 + 한글 모드일 때는 화면의 맨 아래에 자그마하게 현재 한글/영문 모드인지, 완성형인지 조합형인지 같은 상태가 파란 배경의 줄에다 떴다. (그래픽 모드일 때는 그런 거 없음) 텍스트 모드에서 그런 걸 어떻게 구현했는지 지금 생각하면 정말 신기하기 그지없다.
물론 아까 말했던 VGA 테두리도 그보다 더 아래에 표시되었다.

한글을 입력하다가 bksp를 누르면 그냥 바이트 단위로 지워졌다. 즉, '한'을 입력하다가 bksp를 누르면 '하'가 되는 게 아니라 그대로 조합이 끝나면서 KS 완성형 기준 '한'을 구성하는 %C7%D1 중 %C7만 남아서 깨진 문자가 보였다.
우연히 한글 초성만 입력해 놓고 한자 키를 누르니까 지금까지 듣도 보도 못한 온갖 특수문자들이 펼쳐져서 이것도 신비로움 그 자체였다.

2. 한글 MS-DOS를 판매한 MS도 응당 자체 한글 바이오스를 갖추고 있었다.
그런데 지금까지 생각해도 참 대단한 건, MS에서 만든 한글 제품은 텍스트 모드에서도 깨진 문자를 보여주는 법이 없었다.
조합 중인 문자든 조합이 끝난 문자든, 한글은 알아서 자동으로 2바이트씩 한꺼번에 지워졌다. 조합 중인 글자를 조합의 역순으로 차곡차곡 '한' -> '하' 식으로 지워 주기에는 도스 환경이 너무 열악했고, MS가 개발한 한글 바이오스는 그냥 한글을 한꺼번에 지웠다.

GWBASIC, QBASIC 같은 프로그램은 한글판이 따로 있었는데, 한글 바이오스를 구동하지 않고 한글판 프로그램을 실행하면 글자만 깨지는 게 아니라 그대로 컴퓨터가 다운됐었다!
그러나 텍스트 모드에서 GUI를 구현한 한글판 프로그램들을 잘 살펴보면, 메뉴 같은 게 배경에 있는 한글의 2바이트를 반으로 가르게 될 경우 나머지 1바이트도 알아서 지워서 표시해 줬다. 어떤 경우에도 깨진 한글의 잔해 바이트가 표시되는 일이 없었다.

아마 한글 바이오스뿐만이 아니라 응용 프로그램 차원에서 무슨 특수한 처리를 한 것 같긴 한데, 그 대신 당시 MS에서 만든 한글판 프로그램들은 한글 바이오스가 없으면 동작하지 않고, 속도도 느리고 이래저래 파워 사용자들에게서 욕 많이 먹었다. 특히 QuickBasic 한글판은 라이브러리 파일이 영문판과 호환되지 않는 등 최악의 제품이었다.

<날개셋> 한글 입력기는 현재 '마소바탕'이라고 하여 MS 한글 바이오스가 내장한 조합형 글꼴을 그대로 지원하고 있다. 조합 구조가 전통적인 8*4*4벌 도깨비 글꼴과는 다른데 이런 것까지 복원해 냈다.

3. 끝으로 태백한글이라는 프로그램이 있었다. 1994~95년까지 32비트 코드로까지 비교적 오래 개발되었고, 도깨비 글꼴을 그대로 지원한다는 점이 무척 좋았다. 얘는 아마 조합 중인 한글을 음소 단위로 지우는 기능이 있었지 싶다.

도스도 모자라서 영문 윈도우 3.x에서 한글을 구현해 냈다는 한메한글 같은 프로그램은 운영체제의 무슨 계층에서 훅킹을 해서 도대체 어떻게 만든 걸까? 파워 사용자 중에는 영문 윈도우+한메한글이 오히려 한글 윈도우보다 더 안정적이고 좋았다는 말을 할 정도였으니 말이다.
32비트 시대가 도래하기 전에 한글 IME는 DLL이 아닌 EXE이긴 했는데, 그때는 구체적으로 어떤 메카니즘을 썼는지 잘 모르겠다. 물론 그 시절에는 한 프로세스가 시스템 전체에 어떤 영향을 끼치기가 지금보다 훨씬 더 쉬웠을 테니까 그 원리가 그렇게 복잡하고 어려운 건 없었을 것이다.

이것저것 잡설이 길어졌는데, 추억에 공감하시는 분이 있다면 용자.

한글 윈도우 3.1은 실행 전에 언제나 아래와 같은 경고문이 떴었다.
보다시피 MS는 분명히 Hangeul이라는 명칭을 썼었다. 허나 지금 대세는 Hangul이 압도적으로 굳어져 버린 듯. <날개셋> 한글 입력기도 6.0부터는 표기를 Hangul로 바꿨다.

Warning: For correct execution of DOS Box in Hangeul Windows 3.1,
You should use Hangeul Windows 3.1 standard HBIOS.

Warning: Your DOS is not compatible with Hangeul MS-DOS. You may have
some problems when you use Hangeul Windows 3.1.

Press any key to continue...

Posted by 사무엘