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

오늘날 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 사무엘

Posted by 사무엘

Posted by 사무엘

우리나라의 여객용 철도 차량은 시설과 운임 체계가 기관차+객차(일반열차) 아니면 통근형 전동차(전철)로 비교적 경직되게 양분된 편이었다. 그러나 그것도 옛말이 되어 간다. 일반열차처럼 앞을 보는 좌석을 갖추고 있으면서 전동기가 바닥에 달린 동력 분산식 좌석형 고상홈용 전동 열차가 속속 도입되면서 기존의 여객 열차 운행 패러다임에 변화를 일으키고 있기 때문이다.

한국의 철덕후라면 이 점을 주목하지 않을 수 없다. 옛 EEC(우등형 전기 동차)의 뒤를 잇는 후손으로 현재 무엇이 있는지 살펴보자.

1. 공항 철도 직통열차 (2007)

서울 역-인천 공항을 무정차로 운행하는 열차로, EEC의 멸종 이후로 국내에 10여 년 만에 최초로 도입된 동력 분산식 좌석형 전동 열차이다. 좌석은 KTX와 동일한 고정식 좌석이며 따라서 역방향 좌석이 있다. 6량 1편성.
다만, KTX가 순방향과 역방향이 서로 마주보는 형태이고 중앙에 동반석이 있는 반면, 공항 철도 직통열차는 순방향과 역방향이 서로 등지고 반대쪽을 보는 형태이다. 항공 여행객이 이용하는 열차라는 특성상 짐칸도 따로 있다.

공항 철도 직통열차는 거리 당 임률이 KTX보다도 더 높아서 국내에서 가장 비싼 열차이다. 지금은 사실상 서울 역의 도심 공항 터미널에서 출국 수속을 받은 뒤 곧장 비행기 타러 공항으로 갈 사람들이나 이용하는 열차가 되었다. 좌석수에 비해서 잉여력이 너무 강해서 텅 빈 채로 운행되는 경우가 많지만, 운임이 워낙 독자적으로 비싸기 때문에 수지가 아주 안 맞는 건 아니라고 한다.

2. 누리로 (2009)

현재 가장 대중적인 인기를 ‘누리고’ 있는 전동 열차로, 무궁화호와 완전히 동일한 등급으로 기존 일반열차의 운임 체계를 따르며 운행되고 있다. 4량 1편성.
다만, 이 열차는 대놓고 서울-부산 무궁화호를 대체하는 게 아니라 현재로서는 오히려 서울-천안 급행 전동차를 대체하는 컨셉에 더 가깝다. 그래서 지금도 서울 역에서 누리로를 타는 곳은 서울-천안 급행열차가 출발하고 도착하는 제일 동쪽 끝 플랫폼이다. 운행 구간도 서울-부산이 아니라 수도권 전철 1호선을 따라 장항선으로 빠져서 신창까지 간다.

급행 전동차와 비슷한 수준으로 정차하지만, 가감속 성능이 좋아서 표정 속도가 높다. 수요가 많은 시간대에는 중련 편성하여 8량으로 달리기도 한다. 또한 명절에는 대전이나 익산 같은 더 장거리 구간을 운행하기도 하며, 서울-조치원-제천으로 충북선 구간을 달릴 때도 있다.
(참고로 누리로의 도입 이후에도 평일에 하루 3회 다니는 기존 서울-천안 급행 전동차는 여전히 건재하다)

3. ITX 청춘 (2012)

새마을호보다 명목상 ‘더 고급’ 등급인 준고속 2층 전동 열차이다. 독자적인 운임 체계를 쓰며 임률이 새마을호보다 약간 더 높다. 현재는 아직 경춘선에만 운행 중이다. (정확히는 용산-청량리-춘천 직결) 8량 1편성으로 의외로 길다.

공항 철도는 그 성격상 일반 통근형과 직통의 구분이 필수이고, 경춘선은 통근형만 굴리기에는 좀 긴 노선이며 통근 외에도 관광 기능을 무시할 수 없는 노선이다. 그러니 이런 곳에 좌석형 전동 열차를 투입한 것은 현명한 결정이다. 구닥다리 통일호가 다니고 디젤 기관차 무궁화호가 뒤를 잇던 철도 노선에 이런 최신형 전동차가 등장할 줄 누가 예상이나 했을까? 단, 이 열차 때문에 기존의 저렴한 경춘선 급행 전동차가 명맥이 끊어진 건 아쉬운 점이다.

누리로가 서울 역의 지상 전동차 승강장에서 출발하듯, ITX 청춘도 명목상 일반열차이지만 중앙선 전동차가 출발하는 그 승강장에서 1시간에 1대꼴로 출발한다. 여기는 천안 이남의 장항선 수도권 전철들만큼이나 일반열차 승객과 전동차 승객이 섞이기 쉬우며, 마음만 먹으면 부정 승차가 쉽게 가능하다. 승객 분리와 검표를 잘 해야 할 텐데 말이다.

.
.

위에서 소개된 세 열차들은 정체성이 광역전철과 일반열차 사이를 좀 오락가락하는 위치에 있다. 덕분에 20년이 넘게 한국인들의 뇌리에 각인되어 왔던 (KTX)-새마을-무궁화 열차 등급 구도가 문란해지고 있다.

이들 이후로는 중앙선 같은 험준한 간선 철도를 달리는 새마을호급 TTX 틸팅 준고속 전동차가 등장하여, 퇴역하는 기존 새마을호의 역할을 대체할 것이다. 대세는 역시 전동차이다.
KTX 산천 이후에는 사실 고속철조차도 동력 분산식으로 개발 중이다. 승강장만 고상홈으로 바뀌면 일본의 신칸센하고 형태가 완전히 같아진다.

한 우진 님께서 이 글과 거의 같은 주제로 글을 쓰신 적도 있으므로 참고하시라. (☞ 클릭)

Posted by 사무엘

1. 중앙선 6· 8량 혼합 편성

요 근래엔 수도권 전철 중앙선에 눈이 휘둥그레질 만한 광경이 펼쳐졌다.
지난달 말부터 수도권 전철에서 보기 드물게 전동차의 6· 8량 편성 혼합 운행이 시작된 것이다. 전광판에는 다음에 오는 열차의 행선지와 더불어 편성 규모까지 같이 표시되기 시작했다.
옛날엔 부산 지하철 1호선이 혼합 운행을 한 적이 있었다. 지금은 모든 전동차가 8량으로 바뀐 지 이미 오래이지만 말이다.

원래 수도권 전철 중앙선의 전신이라 할 수 있는 국철은 수도권 전철 1호선과 대등한 위상으로 간주되어, 이와 동일한 10량 편성이었다. 비록 일반열차 트래픽 + 건널목 + 합류 지점에서의 선로 용량 같은 여러 제약 때문에 배차는 뜸했지만 말이다.
그러던 것이 중앙선으로 독립하고 얼마 안 되어 8량 1편성으로 규모가 줄었다. 그러면서 보상 조치라고 코레일에서는 열차의 배차 간격을 눈꼽만치 약간 줄여 줬다.

8량까지는 그나마 봐 줄 만하다고 생각했다. 실제로 중앙선이 잉여력이 너무 충만하다고 생각되는 구간이나 시간대도 없지는 않다.
그런데 이젠 8량으로도 모자라 아예 6량으로 줄어 버렸다. 이것은 누가 봐도 명확한 병크였다. 차가 그렇게 자주 다니지도 않는 노선이 예전보다 반토막에 가깝게 수송력이 줄어든 건 우리나라의 전철 역사상 유례를 찾기 어렵다. 표면적인 이유는 수인선 전철 개통을 앞두고 전동차가 부족해서라고 한다.

서울 지하철 1호선은 1974년에 6량으로 개통했다가 8량을 거쳐 이미 1980년대부터 10량으로 증결되었는데, 중앙선은 시계가 거꾸로 갔다.
이 전철 중앙선은 앞으로 경의선과도 직결될 예정인데, 경의선도 8량이다. 중앙선에서 추가로 뻗어 나가는 형태인 경춘선도 8량이다. 그런데 이들을 이으면서 비록 번화가만 아닐 뿐 한강을 따라 서울 시내를 깊숙히 지나는 중앙선이 겨우 6량이라는 게 어디 말이나 되는 소리인가?

중앙선은 경춘선과도 연계되면서 특히 주말 오후엔 극심한 혼잡에 시달리기 시작했다. 직접 타 보면 알 수 있다. 전철은 사람들로 콩나물 시루처럼 터져 나가는데, 아래의 동부 간선 도로는 별로 안 막히고 자동차들이 쌩쌩 달리고 있는 걸 보노라면 전철을 탄 게 후회가 될 정도였다.

결국 코레일은 6· 8량 혼합이라는 결단을 내리게 되었다.
하지만 본인의 개인적인 생각은 중앙선은 헷갈릴 것 없이 다시 전량 8편성으로 어서 되돌아와야 한다. 중앙선과 직결· 접속하는 광역전철들이 전부 8량일 뿐만 아니라 앞으로는 분당선까지 왕십리 역까지 올라와서 왕십리와 만나게 되기 때문이다.

그러니 중앙선은 앞으로 더욱 터져나가게 된다. 분당선도 지금은 전량 6편성이지만 조만간 중앙선과 만날 예정이고 또 수원까지 내려가서 수인선과도 만나게 되면, 8량 증결이 불가피할 것이다. 그러면 중앙선은 두 말할 나위도 없다. (참고로 분당선 초기 구간은 아예 10량 길이를 염두에 두고 역이 만들어졌었다!)

올여름에 개통하는 수인선은 당장은 6량으로 운행을 시작한다. 수인선은 일부 구간을 4호선 안산선과 공유하나, 들리는 말에 따르면, 안산선 전동차가 수인선 구간까지 연장되거나 수인선 전동차가 안산선 구간을 운행할 계획은 없는 듯하다. 전철 운행이라는 건 가능한 한 직결 운행을 염두에 두고 계획을 수립해야 할 텐데 이건 그리 좋은 생각이라 보기 어렵다. 수인선의 개통 구간이 길어지면 운행 거리도 길어지고 전동차도 더욱 증결될 것이다.

2. 여타 서울 지하철

하긴, 옛날에 1호선 신도림 역은 승강장이 승객들로 터져 나갈 때 승강장을 열차 길이보다 훨씬 더 길쭉하게 만들어서 열차를 번갈아가며 하나는 앞쪽 끝에, 다른 하나는 뒤쪽 끝에 세워서 승객을 분산시키려 시도한 적이 있었다. 신도림 역이 유난히도 긴 이유가 이 때문이다.

그러나 나가야 하는 곳이 정해져 있는데 이는 조삼모사 미봉책에 불과했었다. 1호선이 결국 건너편에 상행 승강장을 하나 더 만들었듯이 2호선 신도림 역도 평소에는 잘 쓰이지 않는 입· 출고 열차용 승강장을 활용하여 승강장의 혼잡을 낮추려 노력 중이다.

지하철 9호선은 내가 탈 일이 없어서 잘은 모르겠지만, 정말 장사가 잘 되고 있는 걸로 안다. 특히 급행은 완전 대박이어서 차량을 추가 도입하고 배차를 더 줄인 적도 있다. 얘도 슬슬 6량 증결을 할 때도 되지 않았나 하는 생각이 든다.

서울 지하철 7호선은 잘 알다시피 서울 2기 지하철인 도철 5~8호선 중에서 서울 바깥으로 꽤 이례적인 장거리 연장을 하게 되는 노선이다. 코레일 광역전철과의 직결도 아니면서 말이다.
물론 8호선은 성남 시가지 쪽으로 가지만 노선 자체가 단거리이고 선형이 구부정하기 때문에 7호선과는 사정이 사뭇 다르다.

코레일이나 서울 메트로의 관할 노선은 서울 지하철 정기권이 칼같이 서울 내부까지만 적용된다.
그러나 도철의 관할 노선은 지역에 관계없이 서울 정기권을 쓸 수 있다. 지금 7호선은 광명 시내를 살짝 경유하며 8호선은 성남 시내를 지나지만, 거기서도 서울 정기권이 통용된다. 그래서 같은 역임에도 불구하고 분당선 모란 역에서는 서울 정기권을 쓸 수 없지만 8호선 모란 역에서는 쓸 수 있는 미묘한 차이까지 있다.

그렇다면 7호선의 부천-인천 연장 구간에서까지 서울 정기권을 쓸 수 있게 될까? 이것은 도철의 관할 구간이 길어지고 광역화하면 한 번쯤 생각해 봐야 할 문제가 될 것이다.
현 시설에서 열차 편성을 증결하거나 급행을 운행하는 것은 불가능하겠지만, 이렇게 노선이 길어지고 차내 혼잡도가 늘면 배차간격이라도 더 줄여야 할 것이고 말이다.

도철 지하철은 코레일 광역전철과의 환승에 인색한 편이었다. 그런데 7호선 상봉(경춘/중앙)이 환승역이 되고 7호선 강남구청(분당선)과 6호선도 경춘선과의 환승역이 생길 예정이니 이것도 참 오래 살고 볼 일이다.

Posted by 사무엘

1. 석사 논문 통과

한글 입력· 편집기의 통합적 설계와 구현에 관한 연구
김 용묵 (연세 대학교 대학원 언어정보학 협동과정 언어공학 전공)

석사 학위 논문이 본심까지 통과했고 난 무난히 대학원 졸업을 앞두게 됐다. 현재 나의 진학 구분은 '재학'에서 '졸업 예정'으로 바뀌었다. 당연히 기쁘다. 대선 후보가 이제 대통령 당선인이 된 거라고 생각하면 된다.
내 논문의 지도 교수(논문 주심)는 연세대 국어국문과의 한 영균 선생님. 국문과에서 이공계 감각이 가장 뛰어나고 세벌식이 뭔지, 국어 정보학 쪽이 뭔지 아시는 분이다.

나의 논문 주제는 뻔하다. <날개셋> 한글 입력기의 이론 배경과 의의, 주요 기능 명세에 대해서 썼다.
이건 뭐 1, 2년 연구해 온 게 아니기 때문에 나는 다른 석사 지망생들과는 어차피 출발선의 위치가 다른 것도 사실이었다.

논문 심사 중에는 “너 2003년에 투고했던 김 용묵· 김 진형 논문 때에 비해서 지금 달라진 게 뭐냐?”란 질문을 받곤 했다.
생각 같아서는 “그걸 질문이라고 하십니까. 당연히 넘사벽 급으로 달라졌지.. ㅜㅜ;;”라고 말해 주고 싶었다.
2003년 논문은 <날개셋> 엔진 버전이 겨우 2.x이던 시절인데.. 지금은 그때 없던 개념이 수두룩하며, 오토마타만 해도 옛날엔 지금 같은 수식도 아니고 진짜 흑역사 수준의 유치한 장난감으로 기술했었는데 지금 것하고는 비교 자체가 실례이다. =_=;;

한글 입력과 관련된 수많은 연구들은 통상적으로 그저 글쇠 배열이 어떻고 손가락 움직임이 어떻고 하는 쪽에 치우쳐 있다.
그러나 나의 관심사는 그보다 훨씬 더 fundamental한 것이다.

그 어떤 한글 입력 방식을 만들더라도 결국은 한글 조합 로직이 있어야 한다.
내 프로그램의 내부 구조와 이념을 아는 분이라면 잘 아시겠지만, 다양한 한글 입력 로직을 '기술'하는 시스템을 만들었다. 그래서 한 프로그램에서 무슨 입력 방식을 불러와서 쓰고, 편집하고 저장할 수 있게 했다. 그게 2장의 내용이다.

“한글 입력 오토마타야 이미 1980년대에 이론이 다 정립됐고 지금은 누구나 당연히 그저 그러려니 하고 쓰는 시스템인데, 그것만 전문적으로 또 연구할 게 있냐?”라고 많은 사람들이 생각할지 모르나 나는 그것만을 소재로 연구를 많이 해 냈다.

다음 3장은 내가 개인적으로 이 논문 전체를 통틀어 가장 자부심을 갖고 있는 부분이다.
2장에서 제시한 <날개셋> 한글 입력기의 컴포넌트들을 응용하여 이런 저런 입력 방식을 구현할 수 있다는 것을.. “글자판 종류별로” 분류하여 제시했다. 바로 두벌식, 두벌식과 세벌식 사이의 절충 방식, 그리고 pure 세벌식 이렇게 세 종류.

두벌식에 대해서는, 세벌식 입력 방식을 설계할 때는 거의 필요하지 않은데 두벌식이기 때문에 음절 구분과 관련해서 추가로 필요한 구성요소들을 소개했다. 초+종성 공유 낱자 결합 규칙이라든가 특수 도깨비불 규칙, 조합 종료 타이머가 여기에 속한다.
그리고 절충 방식에서는 <날개셋> 한글 입력기의 범용적인 기능을 활용하여 복벌식이라든가 신세벌식 같은 입력 방식을 구현할 수 있음을 보였다.
마지막으로 pure 세벌식은 초· 중· 종성이 모두 구분되어 있기 때문에 전통적인 모아치기부터 시작해 무한 낱자 수정, 특정 낱자 바로 지우기 등이 모두 가능함을 보였다.

이런 식으로 세 개의 케이스를 나눠서 논리를 전개하는 방식을 이번 논문 학기 때 최초로 생각해 냈는데, 개인적으로 굉장히 마음에 든다.
지금 프로그램의 도움말도 그 논문 스타일로 개편할 예정이다.

4장은 한글 입력기가 글자 입력 자체의 범위를 넘어서서 자연스럽게 연계할 수 있는 텍스트 변환이나 검색 기능을 다뤘다. 잘 알다시피 낱자 재결합이라든가 한글-영타 변환 같은 것 말이다. 한글을 입력하면서 활용 가능한 알고리즘은, 이미 입력된 한글에 대해서도 일괄 적용이 가능해야 한다는 게 지론이다.

5장은 구현체 소개로, 잘 알다시피 동일 엔진에서 편집기와 IME 모듈, 입력 패드라고 Windows 플랫폼 기준으로 생각할 수 있는 모든 프런트 엔드가 다뤄졌다.

요컨대 논문은 앞으로 그 어떤 한글 입력 방식을 만들더라도 공통적으로 적용될 기술 기반을 닦아 놓았다는 데 의의가 있다. 그리고 지금처럼 논문을 구성한 것은 내가 스스로 생각해도 내 자신에게 떳떳하고 정말 체계적으로 잘 구성했다.

마지막으로 감사의 글에는...

• 너님은 학부 출신만으로 재능을 썩히기엔 너무 아깝다며 대학원 꼭 가라고 내게 독려를 해 주신 분.
• 수많은 태클과 딴지를 통해 나의 학문적 방어력을 키워 주시고, 프로그램 매뉴얼을 일말의 논문처럼 보이게 기여해 주신 논문 지도교수님
• 야간도 아니고 일반 대학원에 불쑥 입학해 버렸는데도 괘씸하다고 날 짜르지 않고, 학위를 마칠 때까지 기다리고 직위를 유지시켜 주신 회사 관계자
• 2년간 동고동락했던 학교 입학 동기와 과 선배, 친구들

이 들어갔다. 위에 언급된 분들은 정말로 감사를 드려야 하기 때문에 말이다. 그리고 마지막 문단에는

라고 써 넣었다. 뭉클~~ 이 논문의 이념과 성향을 짐작할 수 있는 대목이라 하겠다.

글쎄, 이것도 학교나 과에 따라서는 분위기가 다소 차이가 나는 모양이다. 박사도 아니고 석사 나부랭이 주제에 뭔 학문 업적을 이룬 게 있다고, 세상사를 다 달관한 듯이 벌써부터 감사의 글을 논문에다 넣냐고 의아하게 보는 곳도 있다고 함. 하지만 우리 학교 우리 과는 안 그렇기 때문에... ㅎㅎ

논문 작성 과정이 행복하기만 한 건 아니었다.
작품은 이미 다 나와 있는데 그걸 글로 표현하는 것만으로도 어찌나 힘들었는지, 온갖 스트레스에 머리를 쥐어짜면서 날밤 새기도 했다. (물론 논문 학기 중에도 코딩이 전혀 없었던 것도 또 아님)
하물며 연구 주제도 못 잡은 채 덜컥 논문 학기를 맞이한 학생은 얼마나 고생이 심할까?

이쪽은 문과 기반인 협동과정이기 때문에 이공계 대학원처럼 연구실에 틀어박혀 사는 게 아니다. 석사 때부터 교수의 push를 받아 가며 공동 프로젝트 진행하고 학술지 논문 게재하면서 자연스럽게 학위 논문 주제까지 정하는 형태가 아니다.

그렇기 때문에 돈은 랩비가 아니라 따로 취업을 해서 일하면서 벌고, 개인 사정 때문에 논문 준비를 못 하면 졸업이 n학기 수준으로 한없이 늦어지게 된다.
그래도 난 그렇게 되지는 않았다.

다만, 창작의 고통보다 더한 걱정은...
교수님이 생각하시는 차후의 연구 방향과 내가 하고 싶어하는 연구 방향이 미묘하게 어긋난다는 점이다.
디테일한 사항을 이 자리에서 얘기하지는 않겠으나, 한 마디로 요약하자면 “지금 석사 졸업은 시켜 주지만, 앞으로도 그렇게 나랑 코드가 안 맞을 거면 넌 내 밑에서 박사는 계속 못 한다” 처럼 좀 됐다. ㅜㅜ 어이쿠..

뭐, 말은 그렇게 하셔도 설마 제자를 그렇게 내쫓지는 않으시겠지... 나중에 입시철이 됐을 때 선생님 찾아가서 또 데꿀멍 좀 하면.. =_=;;
코스웍 이수하면서야 뭘 공부할 수도 있고 선생님이 원하시는 무슨 과제나 프로젝트를 하고 무슨 학술지 논문을 쓸 수도 있지만,

다음 학위 과정에서의 최종 학위 논문은 한글 글꼴을 주제로 쓸 것이다.
입력으로 시작해서 글꼴로 공부를 끝내겠다는 마스터 플랜은 사실 대학원 석사 지원하기 전부터 분명하게 생각해 놓은 것이기 때문에 이건 타협이나 양보를 할 수 없다.

2. 나의 적성과 정체성

많은 사람들이 나보고 “넌 정말 천재다”, “네 능력에 겨우 지금 회사에서 그 연봉은 너무 아깝다”, “넌 공부 더 해야 된다.”, “대학원 꼭 가라. 유학 가라. 두 번 가라” 같은 말씀을 하셨다.
그럼에도 불구하고 내가 현재 겉보기 역량에 비해서 훨씬 작은 사회적 지위밖에 차지하지 못하고 있는 이유는 간단하다. 그 역량들이 기성 사회 조직에서는 거의 제대로 발휘되지 않는 것들이기 때문이다.

지금까지 많은 사람들이 나의 스펙을 보고는 내가 모든 것을 뭐든지 잘하는 천재인 줄로 무척 오해를 하셨다. 카이스트 출신이니까, <날개셋> 한글 입력기를 혼자서 다 만들었을 정도니까 시험만 쳤다 하면 100점 받겠지, 이런 것 개발도 잘하겠지, 뭘 잘하겠지 등등...
그래서 내가 지금까지 많은 사람들을 실망..시켰다. 나는 실제로는 지금 내가 잘하고 있는 것밖에 잘하는 게 없고 그것 말고는 안중에 없다. ^^;;;;;

고집과 외곬수도 못 말릴 정도로 아주 강하다.
<날개셋> 한글 입력기가 기존 학교나 대학(원), 회사에서 정상적으로 소속되어 일하는 사람이 상상하거나 기대하거나 만들 수 있는 프로그램이겠는가? 그건 애초에 1.0부터가 고3 때 수능 공부 다 때려치우고 만들어진 건데 말이다.

이런 집념에 비해서 나는 지금보다 더 빠른 컴퓨터를 만든다거나 SNS 데이터를 분석해서 의미 있는 동향을 뽑아 낸다거나, 수학적으로 더 엄밀한 소프트웨어 개발 환경을 만든다거나 기가 막힌 웹 표준 기술을 만든다거나, 심지어 스마트폰용으로 기가 막힌 게임 앱을 개발하는 일에는 별로 관심이 없(었)다.
그렇기 때문에 난 전산학과 대학원에는 가지 않은 것이다. 평양 감사도 저 싫으면 그만이다.

그리고 그런 진로의 특수성 고민 때문에
나의 다른 과학고/카이스트 동기들은 패스트 석· 박 통합 코스를 밟아서 지금의 내 나이가 되기도 전에 박사까지 다 마친 반면,
나는 인제 겨우 석사를 마친 수준인 것이다.

난 공무원, 대기업, 공기업 같은 조직에 못 있는다. 의사, 변호사 같은 거 못 한다.
난 오로지 내가 붙들고 있는 아이디어를 다 작품으로 옮기기 전에는 단언하건대 다른 일은 죽어도 못 할 것 같다. 오로지 이것만 미는 수밖에 없다.;;

3. 소감 & 이후의 계획

- 대학원에 있으면서 얻은 가장 큰 수확은 역시 국어 '운동꾼' 말고 실제 '학자'들이 한국어와 한글에 대해 언어학적인 관점에서 어떻게 생각하는지를 그럭저럭 배울 수 있었다는 점이다. 일부는 내가 너무 편견에 빠져 있었고, 그렇게 특수하지 않은 현상에 너무 의미를 두고 집착하기도 했다는 것을 알게 되었다..

- 아직 학부의 사고방식에서 제대로 벗어나지 못한 상태였던 입학 초기엔, “어? 한 학기에 최대 12학점밖에 못 들어? 대학원은 안 그래도 등록금도 학부보다 더 비싼데 이거 너무 적은 거 아냐?“라고 생각했었다.
지금이야 그런 생각 따위는 개나 줘 버린 지 오래이다. 한번 12학점씩 들어 본 뒤로는 다시는(앞으로 박사 마칠 때까지도!) 12학점씩이나 듣지는 않을 것이다. -_-;;

- 사전학, 텍스트 마이닝 등 언어학의 응용 분야는 역시 여러 학문 분야의 복합 성향이 짙다는 걸 느꼈다. 나의 관심 분야인 글꼴 쪽도 그럴 거라고 생각한다.

- 첫 학기 때 기본기 보충 차원에서 국문과 학부 수업을 청강했던 '국어 통사론' 과목은 나 같은 공대 출신 비전공자 입장에서 큰 도움이 됐다. 언어정보학 했다는 사람이 한국어 문법에 대해서 그래도 이 정도는 알고 있어야지.

- 그 외에 국문과 대학원 수업은 그럭저럭 강의 듣고 리포트도 안 뒤쳐질 만큼은 써 냈지만, 그릇의 크기의 부족으로 인해 내가 제대로 못 받아들인 내용도 적지 않았다.

- 우리 과에서 자체적으로 개설한 수업은 내용이 다채롭고 좋은 편이지만, 학생들이 워낙 출신이 다양하고 배경 지식 및 관심 연구 분야가 제각각이다 보니 국문과면 국문과, 전산학과면 전산학과 같은 단과 대학원 수업에 비해서 내용의 깊이가 상대적으로 떨어지는 건 불가피해 보였다. 이것은 협동과정의 단점이 될 수 있다. 하지만 코스웍과는 별개로 나처럼 똘끼 충만한 학제간 연구 주제를 이미 갖추고 있는 사람에게는, 협동과정이 장점과 기회로 작용할 수 있겠다. ㄲㄲㄲ

- 원래는 사전 연구실에서 시작해서 전산 언어학, 말뭉치 언어학, 사전학 쪽을 표방하던 이 과가 이공계 협력의 비중은 점차 줄어들고, 요즘은 점점 한국어 교육 쪽 비중만 커지는 듯한 느낌을 받았다. 내가 늘 느끼는 것이지만, 대한민국이 앞으로도 경제적으로 떵떵거리며 잘 살고, 다른 나라들에게 꿈과 희망과 롤모델을 제시해 줄 수 있어야 한국어 수요도 계속 있을 것이고 한국어 교사들도 먹고 살 수 있을 텐데.

- 그래도 나는 이런 여건에 아무리 못 하더라도, 최하 마지노선으로 석사 학위는 있어야 한다는 것에 공감한다. 앞으로 뭘 더 하든지간에 지난 2년간의 투자는 아깝지 않다. 이제 나는 개인적으로 한글 입력 소프트웨어에 대해 연구한 걸 대학원 세계에서도 당당히 어필할 수 있게 되었다.

- 올해 하반기엔 일단 회사로 전업 복귀한다. 이번 논문 학기 동안 심신이 다소 피폐해졌다. 어서 컨디션을 추스리고 <날개셋> 한글 입력기 다음 버전(일단 6.7)을 올해 중에 내놓을 생각이다. 어서 이거 작업을 계속하고 싶다.
<날개셋> 한글 입력기를 한 7.0 정도까지 만든 뒤에는 본격적으로 글꼴 연구 모드이다..

- 아니 그보다도, 앞으로 논문이 조만간 완전한 책 형태로 인쇄돼 나오면, 온갖 지인들한테 나눠 주면서 인사 드리고 만나서 노는 게 우선이다. 최하 50부 정도는 뽑아 둬야 할 듯.

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 사무엘

수치로 표현된 실험 데이터로부터 규칙를 추출하여 추세를 예측하는 것은 과학과 공학에서 아주 유용하게 쓰이는 통계 기법이다.
“input이 x1과 x3일 때 실험으로부터 얻어진 output이 각각 y1과 y3이었으니, 중간에 직접 실험을 해 보지 못한 x2에서는 결과가 아마 y2가 될 것이며(내삽), 더 나아가 범위를 벗어난 x5일 때는 결과가 y5 정도로 나올 것이다(외삽).”

n개의 실험 데이터 (x_1, y_1) 부터 (x_n, y_n)이 있다고 치자. x는 input이요, y는 output을 가리킨다. x_1...n은 꼭 균일한 등차수열 간격으로 분포해 있을 필요는 없다.
우리는 이 실험 데이터의 추세를 잘 나타내는 함수 F(x)를 얻고 싶다. F는 간단히는 그냥 직선을 나타내는 일차함수일 수도 있고 이차나 삼차, 혹은 임의의 계수를 지니는 지수나 로그 함수일 수도 있다.

그 디테일이 어떠하든 F(x_1)은 y_1과 최대한 비슷한 값이 나오고 그런 식으로 1부터 n 사이에 있는 자연수 i에 대해서 F(x_i)는 y_i와 최대한 비슷한 값이 나오면 된다. 그럼 그 F는 실험 데이터의 특성을 잘 나타내는 좋은 함수로 여겨질 것이며 내삽과 외삽에 활용될 수 있다.

최대한 비슷하다는 걸 수학적으로 어떻게 엄밀하게 표현할 수 있을까? i=1...n에 대해,  함수값과 실제 데이터의 차이인 F(x_i)-y_i가 작아야 할 것이다. 오차라는 건 양이든 음이든 절대값이 중요한데 절대값은 미분 같은 수치해석적인 처리가 어려운 연산이니 이럴 때 제곱이 쓰인다. 데이터의 분산을 구할 때와 같은 접근 방식이다. 결국 문제는

각 데이터들에 대한 오차들의 제곱의 합 = (F(x_1)-y_1)^2 + (F(x_2)-y_2)^2 + (F(x_3)-y_3)^2 … (F(x_n)-y_n)^2

이것을 최소화하는 F를 구하는 것으로 귀착된다.
그래서 이 계산법의 이름이 최소자승법/최소제곱법(least square method)인 것이다.

최소자승법이 하는 일은, 그 F(x)가 여러 함수들의 합으로 이뤄질 때, 각 함수들에 들어가는 적절한 계수를 구해 준다.
가령 F(x)가 계수가 3개 존재하는 2차함수여서 a*x^2 + b*x + c 의 형태라면, F(x) = a*f(x) + b*g(x) + c*h(x) 의 세 계수를 생각할 수 있다. 하지만 f, g, h가 실제로 무슨 함수인지는 최소자승법에서 중요하지 않다.

오차의 제곱의 합 함수를 이를 기준으로 다시 써 보면,
∑ i=1..n에 대해 ( a*f(x_i) + b*g(x_i) + c*h(x_i) - y_i )^2 가 된다.

이 식을 전개하면 제법 복잡한 항들이 줄줄이 나오겠지만, 겁먹을 필요 없다.
f, g, h는 언제든지 값을 집어넣어서 계산할 수 있는 함수이고, x_i와 y_i는 전부 상수일 뿐이다.
식에서 변수는 a, b, c이며, 제곱 버프 덕분에 오차의 제곱의 합은 a, b, c에 대한 이차식이 된다.

식의 값이 최소가 되려면, a, b, c에 대해 제각기 따로 생각했을 때, 해당 이차식의 미분계수가 0이 되는 지점에 a, b, c가 있어야 한다. 이것이 우리가 구하고자 하는 F(x)의 정체이다.
가령, x^2 + 2*x - 3 이라는 이차식을 생각해 보면, 이건 (x-1)(x+3)으로 인수분해가 되기 때문에 식의 값을 0으로 만드는 근은 1과 -3이다. 그러나 식을 x에 대해 미분하면 2*x+2가 되고 1과 -3의 중간 지점인 -1이 바로 도함수의 값을 0으로 만들어서 최소값 -4를 만들어 낸다.

우리가 풀고자 하는 문제가 다루는 식은 a, b, c 같은 여러 변수들이 존재하기 때문에, 동일한 식을 각 변수별로 편미분을 해야 한다. 그러면 다음과 같이 규칙성이 있는 3개의 연립 일차방정식이 완성된다. 세 개의 변수의 계수에 다른 변수가 포함되어서 서로 얽혀 있기도 하기 때문에, 각 변수별로 미분계수를 모두 0으로 만들 수 있는 변수들의 값은 이런 방정식을 풀어야 구할 수 있다.

2*f(x_i)*f(x_i)*a + 2*f(x_i)*g(x_i)*b + 2*f(x_i)*h(x_i)*c - 2*f(x_i)*y_i = 0 (a에 대해서)
2*g(x_i)*f(x_i)*a + 2*g(x_i)*g(x_i)*b + 2*g(x_i)*h(x_i)*c - 2*g(x_i)*y_i = 0 (b에 대해서)
2*h(x_i)*f(x_i)*a + 2*h(x_i)*g(x_i)*b + 2*h(x_i)*h(x_i)*c - 2*h(x_i)*y_i = 0 (c에 대해서)

변수가 3개보다 더 많더라도 결국은 이런 패턴의 식이 나온다! _i로 표현된 건 합계를 다 해 줘야 한다는 걸 잊지 말고.
고맙게도 양변은 2로 나눠 버리기 딱 좋게 돼 있으며, 상수항은 음수로 나와 있으니 우변으로 옮기기도 좋다.
위의 식은 결국 다음과 같은 Ax=b 꼴의 행렬로 너무나 깔끔하게 나타낼 수 있다. (행렬은 전치행렬과 자신이 서로 동일한 대칭행렬이다.)

[ F*F F*G F*H ] [ a ]   [ F*y ]
[ G*F G*G G*H ] [ b ] = [ G*y ]
[ H*F H*G H*H ] [ c ]   [ H*y ]

그리고 우리가 구하고자 하는 계수 벡터 x는 A의 역행렬에다가 b를 곱하면 구할 수 있다. 참 쉽죠?

이것이 행렬의 힘이다.
<날개셋> 타자연습에서 타자 속도 그래프를 얼추 비슷한 곡선 함수로 표시해 주는 기능,
그리고 엑셀에서 추세선을 그어 주는 기능들도 다 이 최소자승법 알고리즘을 써서 구현되어 있다.

아래의 그림은 지난 5년간 <날개셋> 한글 입력기의 전체 소스 코드 라인 수의 증가 추이와, 이를 토대로 최소자승법으로 구한 추세선(직선) 그래프이다. 2009년 상반기에 5.3 버전이 개발되었을 때 약간 가파르게 소스 코드가 증가했지만, 그 후로는 증가가 비교적 원만했음을 알 수 있다. 1년에 약 4천 줄 꼴로 코드가 증가한 것인지?

Posted by 사무엘

고속버스나 시외버스 터미널에 가 보면 행선지별로 여러 개의 플랫폼이 있다. 승객은 자기 목적지에 해당하는 플랫폼까지 걸어서 이동한 후, 그 플랫폼에 딱 90도 수직으로 들어와 있는 버스에 탑승한다. 철도역과는 달리, 버스 터미널은 버스를 타기 위해서 계단을 오르내릴 필요가 없어서 좋다.

그런데 철도역 중에도 아주 일부는 버스 터미널처럼 생긴 게 있다. 철도역이 근본적으로 계단이 존재하는 이유는 선로는 역의 앞뒤를 끝없이 관통하고 있는데 거기를 수직으로 교차하는 게 불가피하기 때문이다.
그러나 선로의 한쪽이 막혀서 더 진행하지 않는 시종착역이라면, 선로와 접객 시설이 굳이 교차하지 않아도 되므로 계단이나 육교나 지하도 따위가 없이 ‘바로타’를 실현할 수 있다.

이런 형태의 열차 승강장을 ‘두단식 승강장’이라고 한다. 이것은 어떤 노선의 시종착역이 가질 수 있는 특성 중 하나이다. 이건 물론 상대식이나 섬식 같은 선로와 승강장 배치 방식과는 약간 다른 개념이다. 이런 역에서는 승강장의 한쪽 길이에 맞춰서 선로도 정확하게 끝이 나 버리고, 선로가 끊어진 쪽의 공간을 이용해 승객이 계단 없이 다른 쪽 플랫폼을 마음대로 왕래할 수 있다.

그러나 이런 두단식 승강장 내지 선로는 승객에게는 편하지만 열차 운영자의 관점에서는 그리 좋은 디자인이 아니다.
우리나라 지하철들의 시종착역을 보면, 종점이라고 해서 선로가 곧바로 끝나는 구조가 아니다. 굳이 연장 계획이 수립된 노선이 아니라 할지라도 앞으로 더 진행해서 열차 한 편성 정도가 더 들어갈 수는 있는 공간이 있다. (요즘은 스크린도어 때문에 앞을 들여다보기가 어렵긴 하지만 말이다)

이 공간은 괜히 만들어 놓은 게 아니며, ‘인상선’이라고 한다. 한 방향(가령 상행)에서 운행을 마친 열차는 더 전진하여 인상선으로 진입하여 운행 시격을 맞추기 위해 대기하고 있다가, 시간이 되면 거기서 맞은편 선로로 분기하여 새로 운행을 시작한다.

이런 인상선이 없는 노선이라면, 열차는 그 종착역에 진입하기 전에 미리 진행 방향을 바꿔서 들어가야 한다. 시종착 열차를 받아들이는 회차 용량이 감소하며, 인상선 여유 공간이 없기 때문에 열차는 더욱 조심스럽고 천천히 승강장에 진입해야 한다. 조금만 승강장을 벗어나도(overrun) 탈선이 발생하니까.

이런 이유로 인해 일반적으로 철도를 건설할 때는, 비록 시종착역이라 해도 인상선을 확보해 놓지, 선로를 승강장 길이에 맞춰 칼같이 끊지는 않는 게 관행이다. 특히 일본이나 영국처럼 역사 깊은 철도 종주국이 아니라 한 박자 뒤에 철도를 도입한 한국에서는 두단식 승강장을 보기가 대단히 어렵다.

현재 국내에는 다음 역들이 두단식 승강장이다. 왠지 다들 서쪽에 몰려 있다는 점이 흥미롭다.

목포, 여수엑스포: 다들 영남이 아닌 서쪽 호남 지방에 있는 호남선과 전라선의 종점이며, 목포의 경우 우리나라 최서단에 있는 역이다. 여수 역은 처음엔 안 이랬다가 리모델링을 거치면서 두단식이 되었다.

인천: 지하철 매니아들에게는 진작부터 잘 알려진 유명한 두단식 승강장이다. 바다와 항구가 코앞이니 수도권 서쪽으로 최고 끝임.

개화(서울 지하철 9호선): 김포공항까지 제치고 서울에서 최고 서쪽에 있는 지하철역이다. 서울 시내에서 스크린도어가 없는 유일한 지하철역인 건 덤. 두단식인 데다 역의 번호도 통상적인 910이나 하다못해 909도 아니고, 대놓고 901로 지정되어, 9호선 개화 역 쪽은 연장 가능성이 전혀 없음을 인증했다.

지하철 덕후라면 잘 알겠지만 1990년대 중후반엔 서울 지하철 2호선이 당산 철교를 부수고 재건하느라 고리가 잠시 끊어졌으며, 지상 고가이던 당산 역이 잠시 두단식 승강장으로 바뀐 적이 있었다. 이때도 당산 역은 본선의 역 중에서는 상당히 서쪽 끝자락에 있었다는 게 흥미롭다. 한국 철도에서 두단식 승강장은 여러 모로 서쪽과 인연이 있는 것 같다.

Posted by 사무엘

전산학의 초창기이던 1950년대 후반엔 프로그래밍 언어의 조상이라 할 수 있는 코볼, 포트란 같은 언어가 고안되었다. 그리고 이때 범용적인 계산 로직의 기술에 비중을 둔 알골(1958)이라는 프로그래밍 언어가 유럽에서 만들어졌는데, 이걸 토대로 훗날 파스칼, C, Ada 등 다양한 언어들이 파생되어 나왔다.

이때가 얼마나 옛날이냐 하면, 셸 정렬(1959), 퀵 정렬(1960) 알고리즘이 학술지를 통해 갓 소개되던 시절이다. 구현체는 당연히 어셈블리어.;; 그리고 알골이 도입한 재귀호출이라는 게 함수형 언어가 아닌 절차형 언어에서는 상당히 참신한 개념으로 간주되고 있었다. 전산학의 역사를 아는 사람이라면, 컴퓨터를 돌리기 위해 프로그래밍 언어가 따로 만들어진 게 아니라, 프로그래밍 언어를 구현하기 위해 컴퓨터가 발명되었다는 걸 알 것이다.

알골 자체는 시대에 비해 언어 스펙이 너무 복잡하고 막연하기까지 하며, 구현체를 만들기가 어려워서 IT 업계에서 실용적으로 쓰이지 못했다. 그러나 후대의 프로그래밍 언어들은 알골의 영향을 상당히 많이 받았으니 알골은 가히 프로그래밍 언어계의 라틴어 같은 존재로 등극했다.

물론, 그로부터 더 시간이 흐른 오늘날은 알골의 후예에 속하는 언어인 C만 해도 이미 라틴어 같은 전설적인 경지이다. 중괄호 블록이라든가 C 스타일의 연산자 표기 같은 관행은 굳이 C++, 자바, C# 급의 언어 말고도, 자바스크립트나 PHP처럼 타입이 엄격하지 않고 로컬이 아닌 웹 지향 언어에도 그런 관행이 존재하니 말이다.

C가 먼저 나온 뒤에 거기에 OOP 속성이 가미되어 C++이라는 명작/괴작 언어가 탄생했다. C가 구조화 프로그래밍을 지원하는 고급 언어에다가 어셈블리어 같은 저급 요소를 잘 절충했다면, C++은 순수 OOP 개념의 구현보다는 역시 OOP 이념을 C 특유의 성능 지향 특성에다가 적당히 절충을 잘 했다. 그래서 C++이 크게 성공할 수 있었다.

잘 알다시피 C/C++은 모듈이나 빌드 구조가 컴파일 지향적이며, 거기에다 링크라는 추가적인 작업을 거쳐서 네이티브(기계어) 실행 파일을 만드는 것에 아주 특화되어 있다.

번역 단위(translation unit)라고 불리는 개개의 소스들은 프로그래밍에 필요한 모든 명칭들을 텍스트 형태의 다른 헤더 파일로부터 매번 include하여 참조한 뒤, 컴파일되어 obj 파일로 바뀐다.
한 번역 단위에서 참조하는 외부 함수의 실제 몸체는 어느 번역 단위에 있을지 알 수 없다. 어차피 링크 때 링커가 모든 obj 파일들을 일일이 뒤지면서 말 그대로 연결을 하게 된다.

이 링크를 통해 드디어 실행 파일이나 라이브러리 파일이 최종적으로 만들어진다. 실행 파일은 대상 운영체제가 인식하는 실행 파일 포맷을 따라 만들어지지만 static 라이브러리는 그저 obj들의 모음집일 뿐이기 때문에 lib 파일과 obj 파일은 완전히 같지는 않아도 내부 구조가 크게 차이가 나지 않는다.

이런 일련의 컴파일-링크 계층이 C/C++을 로컬 환경에서의 매우 강력한 고성능 언어로 만들어 주는 면모가 분명 있다. 또한 197, 80년대에는 컴퓨터 자원의 한계 때문에 원천적으로 언어를 그런 식으로 설계해야 하기도 했다.
그러나 오늘날은 대형 프로젝트를 진행할 때 C/C++의 그런 디자인은 심각한 비효율을 초래하기도 한다. 내가 늘 지적하듯이 C보다도 특히 C++은 안습할 정도로 빌드가 너무 느리고 생산성이 떨어진다.

그에 반해 자바는 문법만 살짝 비슷할 뿐 디자인 철학은 C++과는 완전히 다른 언어이다. 잘 알다시피 자바는 의도하는 동작 환경 자체가 native 기계어가 아니라 플랫폼 독립적인 자바 가상 기계이다. 컴퓨터 환경이 발달하고 웹 프로그래밍이 차지하는 비중이 커진 덕분에 이런 발상이 나올 수가 있었던 셈이다.

모든 자바 프로그램은 무조건 1코드, 1클래스이며(단, 클래스 내부에 또 다른 클래스들이 여럿 있을 수는 물론 있음), 심지어 소스 파일 이름과 클래스 이름이 반드시 일치해야 한다. 클래스가 곧 C/C++의 ‘번역 단위’와 강제로 대응한다. 그리고 컴파일된 자바 소스는 곧장 컴파일된 바이트코드로 바뀌며, 이것이 자바 VM이 있는 곳이라면 어디서나 돌아가는 실행 파일(EXE)도 되고 라이브러리(DLL, OBJ)도 된다. 물론, 여러 라이브러리들의 집합체인 JAR이라는 포맷도 따로 있기도 하고 말이다.

클래스 내부에 public static void main 메소드(멤버 함수)만 구현되어 있으면 곧장 실행 가능하다. C++은 C와의 호환을 위해 시작 함수가 클래스 없는 일반 main으로 동일하게 지정돼 있는 반면, 자바는 global scope이 존재하지 않고 모든 명칭이 클래스에 반드시 소속돼 있어야 하기 때문에 그렇다. javac 명령으로 소스 코드(*.java)를 컴파일한 뒤, java 명령으로 컴파일된 바이트코드(*.class)를 실행하면 된다.

다른 모듈을 끌어다 쓸 때도 import로 바이너리 파일을 곧장 지정하면 되니, 텍스트 파싱이 필요한 C++의 #include보다 효율적이다. 번거롭게 *.h와 *.lib (그리고 심지어 *.dll까지)를 일일이 따로 구비할 필요 없다.

요컨대 자바는 C++에 비해 굉장히 많은 자유도와 성능을 제약한 대신, C++보다 훨씬 더 손이 덜 가도 되고 빌드도 훨씬 빨리 되고 프로젝트 세팅도 월등히 더 간편하게 되게 만들어졌다. 함수 호출 규약, 인라이닝 방식, C++ symbol decoration, 링크 에러, CRT의 링크 방식, link-time 코드 생성 최적화 같은 온갖 골치 아프고 복잡한 개념들이 자바에는 전혀 존재하지 않는다.
C++이 벙커에 시즈 탱크에 터렛과 마인 등, 손이 많이 가는 테란이라면, 자바는 프로토스 정도는 되는 것 같다.

자바는 하위 호환성을 고려하지 않은 새로운 언어를 만든 덕분에 디자인상 깔끔한 것도 있지만, 상상도 못 할 편리함을 실현하기 위해 성능도 C++ 사고방식으로는 상상도 못 할 정도로 많이 희생한 것 역시 사실이다. 이는 단순히 메모리 garbage collector가 존재하는 오버헤드 이상이다.

그래서 요즘은 자바 바이트코드를 언어 VM이 그때 그때 실시간으로 네이티브 코드로 재컴파일하여, 자바로도 조금이라도 더 빠른 속도를 내게 하는 JIT(just in time)기술이 개발되어 있다. 비록 이 역시 한계가 있을 수밖에 없겠지만 한편으로는 구조적으로 유리한 점도 있다.

컴파일 때 모든 것이 결정되어 버리는 C++ 기반 EXE/DLL은 사용자의 다양한 실행 환경을 예측할 수 없으니 보수적인 기준으로 빌드되어야 한다. 그러나 자바 프로그램의 경우, VM만 그때 그때 최신으로 업데이트하여 최신 CPU의 명령이나 병렬화 테크닉을 쓰게 하면 그 혜택을 모든 자바 프로그램이 자동으로 보게 된다. 물론 C++로 치면 cout이 C의 printf보다 코드 크기가 작아지는 경지에 다다를 정도로 컴파일러가 똑똑해져야겠지만 말이다.

자바 얘기가 길어졌는데, 다음으로 C#에 대해서 좀 살펴보기로 하자.
C# 역시 네이티브 코드 지향이 아니라 닷넷 프레임워크에서 돌아가는 바이트코드 기반인 점, 복잡한 링크 메커니즘을 생략하고 C++의 지나치게 복잡한 문법과 모듈 구조를 간소화시켰다는 점에서는 자바와 문제 접근 방식이 같다.

단적인 예로, 클래스를 선언하면서 멤버 함수까지 클래스 내부에다 정의를 반드시 집어넣게 한 것, 그리고 생성자 함수의 호출이 수반되는 개체의 생성은 반드시 new를 통해서만 가능하게 한 것은 컴파일러와 링커가 동작하기 상당히 편하게 만든 조치이다. 이는 자바와 C#에 공통적으로 적용된다.

다만 C#은 자바처럼 엄격한 1소스 1클래스 체계는 아니며, 빌드 결과물로 엄연히 일반적인(=윈도우 운영체제가 사용하는 PE 포맷 기반인) EXE와 DLL이 생성된다. 물론 내부엔 기계어 코드가 아닌 바이트코드가 들어있지만 말이다.

C# 역시 클래스 내부에 존재하는 static void Main가 EXE의 진입점(entry point)이 된다. 그러나 C#은 자바 같은 1소스, 1클래스, 1모듈 구조가 아니기 때문에 여러 클래스에 동일한 static void Main이 존재하면 컴파일러가 어느 것을 진입점으로 지정해야 할지 판단할 수 없어서 컴파일 에러를 일으킨다. 링크나 런타임 에러가 아님. 진입점을 별도의 컴파일러 옵션으로 따로 지정해 주거나, Main 함수를 하나만 남겨야 한다.

여담이지만, C#의 진입점 함수는 자바와는 달리 첫 글자 M이 대문자이다. 전통적으로 자바는 첫 글자를 소문자로 써서 setValue 같은 식으로 메소드 이름을 지어 온 반면, 윈도우 세계는 그렇지 않기 때문이다(SetValue).
그리고 C#의 Main은 굳이 public 속성이 아니어도 된다. 어차피 진입점인데 접근 권한이 무엇이면 어떻냐는 식의 발상인 것 같다.

닷넷 실행 파일이 사용하는 바이트코드는 자바와 마찬가지로 기계 독립적인 구조이다. 그러나 그것의 컨테이너라 할 수 있는 윈도우 운영체제의 실행 파일 포맷(PE)은 여전히 CPU의 종류를 명시하는 필드가 존재한다. 그리고 32비트와 64비트에서 필드의 크기가 달라지는 것도 있다. 이것은 기계 독립성을 추구하는 닷넷의 이념과는 어울리지 않는 구조이다. 그렇다면 닷넷은 이런 상황을 어떻게 대처하고 있을까?

내가 테스트를 해 본 바로는 플랫폼을 ‘Any CPU’라고 지정하면, 해당 C# 프로그램은 명목상 그냥 가장 무난하고 만만한 x86 껍데기로 빌드되는 듯하다.
작정하고 x64 플랫폼을 지정하고 빌드하면 헤더에 x64 CPU가 명시된다. 뒤에 이어지는 바이트코드는 어느 CPU에서나 동일하게 생성됨에도 불구하고, 그 프로그램은 x86에서는 실행이 거부되고 돌아가지 않게 된다.

그러니, 64비트 네이티브 DLL의 코드와 연동해서 개발되는 프로그램이기라도 하지 않은 이상, C# 프로그램을 굳이 x64용으로 제한해서 개발할 필요는 없을 것이다. 다만, x86용 닷넷 바이너리는 관례적으로 닷넷 런타임인 mscoree.dll에 대한 의존도가 추가되는 반면 x64용 닷넷 바이너리는 그런 게 붙어 있지 않다. 내 짧은 생각으론, 64비트 바이너리는 32비트에서 호환성 차원에서 넣어 줘야 했던 잉여 사항을 생략한 게 아닌가 싶다.

DLL에 기계 종류와 무관한 리소스나 데이터가 들어가는 일은 옛날부터 있어 왔지만, 닷넷은 코드조차도 기계 종류와 무관한 독립된 녀석이 들어가는 걸 가능하게 했으니 이건 참 큰 변화가 아닐 수 없다. 네이티브 쪽과는 달리 골치 아프게 32비트와 64비트를 일일이 신경 쓸 필요가 없고, 한 코드만으로 x86(-64) 계열과 ARM까지 다 커버가 가능하다면, 정말 어지간히 하드코어한 분야가 아니라면, 월등한 생산성까지 갖추고 있는 C#/자바 같은 개발 환경이 뜨지 않을 수 없을 것 같다. C++과 자바, C#을 차례로 비교해 보니 그런 생각이 들었다.

Posted by 사무엘