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

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의 세벌식으로 입력했던 공백이나 숫자, 기호가 역상(검은 배경, 흰 글씨)으로 바뀐다!

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

더욱 기괴한 건, 오피스 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 사무엘

※ 프로세서 정보 얻기

현재 컴퓨터의 CPU 아키텍처 종류를 얻는 대표적인 함수는 GetSystemInfo이다. SYSTEM_INFO 구조체의 wProcessorArchitecture 멤버의 값을 확인하면 된다.
그런데, 64비트 컴퓨터에서 64비트 운영체제를 실행하고 있더라도 32비트 프로그램은 언제나 이 값이 0, 즉 32비트 x86이 돌아온다. 이는 호환성 차원에서 취해진 조치이다. 기존의 32비트 x86용 프로그램은 새로운 API를 쓰지 않으면 자신이 64비트 x64에서 돌아가고 있다는 걸 까맣게 모르며, 전혀 알 수 없다.

자신이 돌아가고 있는 환경이 진짜 x64인지 확인하려면 GetNativeSystemInfo라는 새로운 함수를 써야 한다. 이건 Windows가 최초로 x64 플랫폼을 지원하기 시작한 윈도우 XP에서 추가되었다. 이 함수가 존재하지 않는 운영체제라면 당연히 64비트 환경이 아니다.

64비트 프로그램이라면 그냥 기존의 GetSystemInfo만 써도 x64를 의미하는 9가 돌아온다. GetNativeSystemInfo는 동일한 코드가 32비트와 64비트로 컴파일되더라도 모두 정확한 동작을 보장한다는 차이가 존재할 뿐이다.

또한, 같은 64비트라도 아이테니엄(IA64) 환경에서는 기존 GetSystemInfo도 32비트 x86 프로그램에서 아키텍처를 x86이라고 속이지 않고 정확하게 IA64라고 알려 준다. 왜냐하면 IA64는 x86과는 명백하게 다른 환경이기 때문에 다르다는 걸 알려 줄 필요가 있기 때문이다. 뭐, 지금은 IA64는 완전히 망했기 때문에 일반인이 접할 일이 없겠지만 말이다.

※ 시스템 메모리 정보 얻기

메모리 양을 얻는 전통적인 함수는 GlobalMemoryStatus이다.
그러나 32비트 프로그램이라도 현재 컴이 64비트 운영체제를 사용하여 램이 4GB보다 많이 있는 걸 제대로 감지해서 표시하려면, 윈도우 2000에서 새로 추가된 GlobalMemoryStatusEx 함수를 써야 한다.

그리고 빌드되는 실행 파일의 헤더에 large address aware 플래그가 켜져 있어야 한다. 비주얼 C++ 기준 Linker → System → Enable Large Addresses를 yes로 지정해 주면 된다. 64비트 플랫폼에서는 이 값이 기본적으로 yes이지만, 32비트 플랫폼에서는 기본값이 no이다.
large address aware이 켜져 있지 않으면 32비트에서는 사용 가능한 가상 메모리가 아예 4GB가 아닌 2GB로 반토막이 난 채 표시된다. 포인터의 최상위 1비트를 비워 준다.

그리고 64비트 바이너리에 대해서는 사용 가능한 가상 메모리의 양이야 언제나 있는 그대로 운영체제가 알려 주지만, 해당 바이너리에 이 플래그가 없으면, 운영체제는 아예 상위 32비트를 비워 줘서 DLL 같은 걸 LoadLibrary해도 언제나 32비트 영역 안에서만 주소를 잡는다. 포인터까지 4바이트짜리 int와 구분 없이 작성된 구식 코드들의 64비트 포팅을 수월하게 해 주기 위한 조치이다.

참고로 64비트 전용 프로그램이라면 Ex 대신 기존의 GlobalMemoryStatus만 써도 괜찮다. 받아들이는 구조체의 크기가 int가 아니라 SIZE_T이기 때문에, 32비트 플랫폼에서는 32비트이지만 64비트 플랫폼에서는 자동으로 64비트가 설정되기 때문이다. Ex 함수는 플랫폼의 비트 수에 관계없이 숫자의 크기가 언제나 64비트 크기를 보장해 줄 뿐이다.

※ 32비트 프로그램이 지금 내가 64비트 운영체제에서 동작하고 있는지 감지하기

딱 그 목적을 위해 IsWow64Process라는 함수가 있다. 이것 역시 윈도우 XP 이상에서 추가되었다.

※ 윈도우 시스템 디렉터리에 접근하기

64비트 운영체제는 잘 알다시피 시스템 디렉터리가 64비트용과 32비트용으로 두 개 존재한다.
32비트와 64비트 프로그램에 관계없이 GetSystemDirectory는 언제나 C:\Windows\system32를 되돌린다.
그리고 윈도우 XP에서 추가된 GetSystemWow64Directory라는 함수가 있어서 역시 32비트와 64비트에 관계없이 C:\Windows\SysWow64를 되돌린다. 다만, 운영체제 자체가 64비트가 아닌 32비트 에디션이라면, 후자의 함수는 에러를 리턴한다.

그러니 의외로 이 함수는 플랫폼에 관계없이 절대적으로 같은 결과를 되돌리는 듯한데, 문제는 64비트 운영체제는 32비트 프로그램에 대해 시스템 디렉터리를 기본적으로 redirection한다는 것이다. 즉, 64비트 운영체제는 32비트 프로그램이 C:\Windows\System32를 요청한다고 해도 SysWow64의 내용을 보여주지 진짜 64비트용 시스템 디렉터리의 내용을 보여주지 않는다.

만약 32비트 기반으로 응용 프로그램 설치 관리자나 파일 유틸리티 같은 걸 만들 생각이어서 진짜로 64비트 시스템 디렉터리에 접근을 하고 싶다면, 운영체제에다 별도의 함수를 호출해서 요청을 해야 한다. 그래서 처음에는 Wow64EnableWow64FsRedirection라는 함수가 추가되었다. 이걸로 잠시 예외 요청을 한 뒤, 내가 할 일이 끝난 뒤엔 다시 설정을 원상복귀해야 했다. 왜냐하면 64비트 시스템 디렉터리에 접근 가능하게 해 놓은 예외 동작을 그대로 방치하면, 나중에 다른 32비트 모듈들이 32비트 시스템 디렉터리에 접근하지 못하게 되기 때문이다.

그런데 MS에서는 함수 디자인을 저렇게 한 것을 후회하고, 위의 함수의 기능을 Wow64DisableWow64FsRedirection과 Wow64RevertWow64FsRedirection 쌍으로 대체한다고 밝혔다. MSDN을 읽어 보면 알겠지만, 64비트 접근 여부 설정치를 마치 stack처럼 다단계로 저장했다가 다시 원상복귀를 더 쉽게 할 수 있게 만들려는 의도이다.

※ Program Files 디렉터리에 접근하기

64비트 운영체제는 응용 프로그램 디렉터리도 64비트용과 32비트용이 두 개 존재한다.
운영체제가 사용하는 특수 디렉터리의 위치를 얻어 오는 함수의 원조는 SHGetSpecialFolderPath이며, 이것은 윈도우 운영체제의 셸의 구조가 크게 바뀌었던 인터넷 익스플로러 4 시절에 처음 도입되었다. 그때는 특수 디렉터리들을 CSIDL이라는 그냥 정수 ID로 식별했다.

그랬는데 윈도우 비스타부터는 이 함수의 역할을 대체하는 SHGetKnownFolderPath라는 함수가 추가되었고, 이제는 식별자가 아예 128비트짜리 GUID로 바뀌었다. 문자열 버퍼도 구닥다리 260자짜리 고정 배열 포인터를 받는 게 아니라, 깔끔하게 별도의 동적 할당 형태가 되었다.

64비트 운영체제에서 64비트 프로그램은 64비트와 32비트용 Program Files 위치를 아주 쉽게 얻어 올 수 있다. 32비트를 가리키는 식별자가 따로 할당되어 있기 때문이다. 그러나 32비트 프로그램이 64비트 운영체제의 64비트 위치를 얻는 것은 위의 두 함수로 가능하지 않다. SpecialFolder 함수는 64비트만을 가리키는 식별자 자체가 없으며, KnownFolder함수도 32비트 프로그램에서 FOLDERID_ProgramFilesX64 같은 64비트 식별자를 사용할 경우 에러만 돌아오기 때문이다.

32비트 프로그램이 64비트 Program Files 위치를 얻는 거의 유일한 공식적인 통로는 의외의 곳에 있다. 바로 환경변수이다.

::ExpandEnvironmentStrings(_T("%ProgramW6432%\\"), wt, 256);

위의 환경변수를 사용한 코드는 32비트와 64비트에서 동일하게 64비트용 Program Files 위치를 되돌려 준다.

결론

이렇듯 32비트에서 64비트로 넘어가면서 윈도우 API의 복잡도와 무질서도는 한층 더 높아졌음을 우리는 알 수 있다. 가능한 한 급격한 변화와 단절을 야기하지 않으면서 새로운 기능을 조심스럽게 추가하려다 보니 지저분해지는 건 어쩔 수 없는 귀결이다.

프로그램 배포 패키지를 32비트 exe 하나만 만들어서 64비트와 32비트 플랫폼에서 모두 쓸 수 있게 하면 좋을 것 같다. 32비트 플랫폼에서는 32비트 바이너리만 설치되고, 64비트 플랫폼에서는 비록 32비트 EXE라도 64비트 프로그램 디렉터리들을 모두 건드릴 수 있어야 한다. 그런 프로그램을 만들려면 이 글에서 언급된 테크닉들을 모두 알아야 할 것이다. 설치 프로그램이니 UAC 관리자 권한이 필요하다는 manifest flag도 내부적으로 넣어 주고 말이다.

아, 그러고 보니, 윈도우 9x 시절에는 시스템 디렉터리가 16비트와 32비트로 나뉘어 있지도 않았다. NT 계열로 와서야 system과 구분하기 위해서 system32가 별도로 생기긴 했지만, 16비트용 시스템 디렉터리의 위치를 얻는 별도의 API는 존재하지 않았으며, 사실 필요하지도 않았다. 16비트 프로세스는 이제 NTVDM 밑에서 돌아가는 완전 고립된 별세계로 전락했기 때문이다.

Posted by 사무엘

아문센이 선택한 경로는 스콧이 선택한 경로보다 남극점에 96km 정도, 즉 서울-천안 정도의 거리만치 더 가까운 경로였지만, 완전히 새로운 길을 개척해서 가는 것이었다. 스콧의 경로는 선배 탐험가인 어니스트 섀클턴이 갔던 경로와 동일했다. 거기에다 아문센은 스콧보다 출발도 열흘 정도 더 일찍 했다.
아문센은 1등에 대한 압박 때문에 더 일찍 출발하려 시도를 했지만 역시 맹추위와 준비 미숙 때문에 포기하고 되돌아온 적도 있었다. 그렇잖아도 아문센은 북극점을 먼저 정복하려 했는데 선두를 미국인에게 빼앗겨서 조바심이 난 상태였기 때문이다.

참고로 섀클턴은 스콧보다 먼저 남극 탐험을 갔지만, 준비 미숙과 물자로 부족으로 인한 실패를 인정하고 북극점을 약 150km 정도 앞둔 지점에서 미련 없이 진행을 포기하고 되돌아온 사람이다. 그 대신 모든 대원들이 생환하는 데 성공했다.

아문센은 남극점을 빨리 찍고 돌아온다는 그 목표에만 집중하여 대원들도 전부 항해 측량술을 알고 스키를 능숙하게 탈 줄 알며 혹한 환경에서의 생존 능력이 뛰어난 베테랑들로 뽑았다. 그러나 스콧은 겸사겸사 학술 탐사에도 큰 비중을 둬서 대원 중엔 과학자들도 있었다. 군인보다는 민간인을 선호했던 셈. 스콧은 그 힘든 와중에도 죽는 마지막 순간까지 남극에서 채취한 광물을 16kg치나 갖고 보관하고 있었다.

아문센은 북극 원주민들로부터 노하우를 전수받은 대로 남극에 갈 때도 물이 스며들지 않는 두꺼운 가죽옷을 입었고, 짐을 싣는 썰매는 개들을 이용해 운반했다. 현지에서도 수시로 바다표범들을 사냥해서 식량을 비축했고, 탐험 중에도 효용이 떨어진다 싶으면 가차없이 개들을 잡아먹고 심지어 잡은 개고기를 다른 개에게 사료로 주기도 했다.

그러나 스콧은 원주민들이나 입는 가죽옷을 저속하다고 거부하고 개고기도 안 먹었으며, 현지에서의 사냥 역시 할 생각을 않았다. 개나 말이 죽으면 잡아먹기는커녕 묻어서 장례를 치러 줬을 정도이니! 모든 물자는 대영제국에서 조달하는 것만으로 충당하려 했던가 보다. 그러나 영국제 모직물 코트는 옷이 물에 젖고 얼면서 ‘망했어요’ 상태가 되었다.

이들은 개 대신 조랑말과 스노우모빌(설상차)을 활용했는데, 말은 평범한 환경에서야 개보다 먹는 양에 비해 큰 수송력을 제공하는 게 사실이지만 별도의 사료를 챙겨 가야 하며 개들보다 추위에 훨씬 취약했고 잘못해서 크레바스에 빠지기라도 하면 답이 없었다. 스노우모빌은 매서운 추위와 험악한 지형에서 무용지물로 전락했으며, 후원사로부터 지원받은 막대한 양의 통조림도 얼어서 안 따지거나 심지어 터지기 일쑤였다.

영국이 자랑하던 자본력과 당대의 과학 기술은 남극에서만은 그들이 한낱 피지배민 루저로 치부하던 원주민들의 생활 노하우를 앞설 수 없었다.

아문센은 1911년 10월 20일부터 그 해 12월 14일까지 55일 동안 거의 1300km에 달하는 거리를 이동한 끝에 남극점에 도달하는 데 성공했다. 매일 23~24km씩 진행한 셈. 남극점 주변엔 그 어떤 인간의 흔적도 없었으니 그들이 1등을 한 게 확실했다.

아문센은 영국인들이 한 근성을 하기 때문에 스콧 팀도 아마 며칠 안으로 남극점에 곧 도착할 거라고 생각했다. 그러나 스콧 팀이 도착한 것은 그로부터 34일이나 지난 이듬해 1월 17일이었다. 출발 시기가 열흘이 차이가 나고 거리 차이가 100km 정도 났으니 두 주~보름 정도의 간극은 자연스럽지만 한 달이 넘게 차이가 났다는 건 스콧 팀이 시스템적인 비효율로 인해 진행도 더뎠음을 의미한다.

그들은 이미 하루 전인 16일부터 무수한 개들과 썰매 자국을 발견했다. 그리고 남극점에 다다르니 거기엔 역시나 노르웨이 깃발과 함께 천막이 만들어져 있었고, 약간의 물자와 쪽지가 적혀 있었다. 쪽지에 적힌 글은 대략 다음과 같은 요지였다고 한다.

아문센은 라이벌을 배려해서 정말 정중하고 대인배스러운 행동을 한 것이었지만, 이 문구는 스콧에게는 가히 자존심을 건드리고 비수를 꽂는 대목이 아닐 수 없었다. 실제로 스콧 팀은 물자가 부족해서 추위와 굶주림에 시달리면서도 아문센이 남긴 보급 물자는 거들떠보지도 않았다. 이것은 현명하지 못한 선택이었다.

아문센 팀은 1월 25일에 자기네 베이스 캠프로 무사히 귀환했다. 갔던 길의 역순으로 그대로 돌아오는 것이었고, 귀환이 42일이 걸렸으니 55일이 걸린 출발보다 기간이 두 주 정도 더 단축됐다.

그러나 개도, 말도, 설상차도 없이 터덜터덜 허탈하게 귀환하던 스콧 팀에게는 이제부터 재앙이 시작되었다. 귀환을 시작한 지 한 달이 경과한 2월 17일인데 이들은 거의 반밖에 진행을 못 했다. 그리고 이때 팀원 중 지질학자인 에드가 에반스가 가장 먼저 혼수 상태에 빠졌다가 목숨을 잃었다. 그는 이미 몇 번 추락 사고를 당해서 뇌진탕과 폐렴 증세로 인해 건강이 몹시 안 좋던 상태였다.

그리고 그로부터 또 한 달이 경과하여 3월 17일이 되었다. 귀환 60일째이고 전체 경로의 70% 정도는 완주한 시점이었다. 대원 중 로렌스 오츠는 발에 심한 동상을 입어서 이미 괴저가 발생하고 거의 걸을 수가 없는 지경이 되어 있었다. 그는 대원들이 자신을 부축하고 자신과 보조를 맞추느라 귀환이 지체되고 있는 걸 알았으며, 제발 자기를 버리고 먼저 가라고 간청했다. 그러나 스콧은 그렇게 하지 않았다.

이에 오츠는 그 날 저녁, “대장님, 밖에 좀 나갔다가 오겠습니다”란 말을 남기고는 불편한 발을 이끌고 눈보라가 휘몰아치는 캠프 밖으로 절뚝거리며 나갔고, 그 길로 자취를 감춰 버렸다. 그는 시신조차도 영영 발견되지 않았다. (눈보라가 얼마나 지독했으면, 눈에 찍힌 발자국조차 이내 사라졌던가 보다.) 스콧은 오츠가 일부러 죽음을 택했다는 걸 눈치 채고, 그가 영국 신사다운 최후를 맞이했다고 슬퍼하는 한편으로 그를 칭송했다.

그러나 이런 오츠의 살신성인도 나머지 세 명을 궁극적으로 살리지는 못했다. 살인적인 악천후 때문에 3월 19일자 캠프에서 스콧 일행은 더 나아가질 못하고 1주일이 넘게 고립되었다. 베이스 캠프까지는 약 200km쯤 남았기 때문에(이미 1000km를 넘게 이동했고, 다 와 감) 저 기간 동안 조금만 더 분발했으면 근처의 보급 기지에도 도착했을 것이고, 베이스 캠프에까지 살아서 돌아갈 가능성은 충분했을 터이나 그들은 그럴 수 없었다.

남극에 무슨 생각으로 물을 끓여야 하는 번거로운 홍차를 가져갔는지 모르겠다. 식료품과 연료는 이미 다 떨어졌고 홍차는 생잎을 뜯어먹어야 했다. 그러다가 3월 29일, 나머지 대원인 에드워드 윌슨과 헨리 바우어즈가 극심한 추위와 굶주림, 어둠, 절망으로 인한 기력 소진 때문에 목숨을 잃었고, 가장 마지막으로 탐험대장인 스콧도 같은 캠프 안에서 사망했다. 그의 일기장에 죽은 두 대원에 대한 언급도 있기 때문에 스콧이 가장 나중에 죽은 것으로 여겨진다.

익사나 추락사처럼 단번에 훅 간 게 아니라 마치 성냥팔이 소녀처럼 굉장히 처절하고 비참하게 죽은 셈이다. 스콧 일행의 시신은 그로부터 무려 8개월 뒤에 남극에 여름이 다시 찾아왔을 때 미국의 탐사대에 의해 발견되었다.

자, 다음 그림은 아문센(빨간색)과 스콧(초록색)의 남극 탐험 경로를 정리한 것이다. (출처: 영문 위키백과)

영국에서는 영국 신사의 기품을 지키면서 남극에서 장렬히 산화한 스콧을 애국자와 영웅으로 열렬히 치켜세우고 떠받드는 한편으로, 어쨌든 1등을 해 버린 아문센을 헐뜯고 잡아먹지 못해 안달이었다. 한때는 아예 대놓고 역사를 왜곡하여 스콧이 먼저 남극점에 도착했다고 가르치기까지 하다가, 국제 사회로부터의 조롱과 비웃음을 한몸에 받고서야 슬쩍 시정했다.

영국이 이런 데서 은근히 찌질한 짓도 좀 했다. 영국인 중에서 양심껏 소신껏 아문센을 지지하고 그의 업적을 인정한 사람은 스콧의 롤모델 탐험가이던 섀클턴 정도가 고작이었다. 어니스트 섀클턴은 이 글에서는 많이 다루지 않지만, 아폴로 13호 같은 ‘성공적인 실패’를 기적적으로 이룩한 덕분에 이 양반 역시 아문센만큼이나 전설이 아니라 레전드급인 위대한 탐험가로 역사에 남아 있다. 관심 있으신 분은 찾아 보기 바란다.

콩진호, 콩라인-_- 같은 예외를 빼면, 세상 역사에서 2등은 정말 너무 가혹하다 싶을 정도로 기억에 남지 못하는 게 통념이다. 허나, 남극에서만큼은 영국의 저런 집요한 로비로 인해 각종 시설물에 꼭 ‘스콧-아문센’ 브랜드가 심심찮게 남아 있다.

남극의 정복자 아문센은 거의 60년 뒤에 달에 갔다 온 닐 암스트롱만큼이나 세계의 영웅으로 등극하였고 곳곳에서 강연 요청이 쇄도했다. 노르웨이 국내에서야 물어 보면 잔소리. 지금 한국으로 치면 김 연아, 안 철수 급의 유명인사가 되었다. 듣보잡 빈곤국이던 노르웨이의 위상을 그만치 끌어올린 사람이 역사상 누가 있었겠는가?

아문센은 교통 덕후여서 이 탐사 후에도 활발히 탐험 활동을 하였으며, 특히 20세기 초는 항공기 기술이 개발되던 시기인지라 남극을 아예 비행선으로 횡단하기도 했다. 그러다 1928년에 비행선 사고로 인해 행방불명되는 걸로 최후를 맞이했다.

훗날 냉전 시절에 미국과 소련이 우주 개발 경쟁을 할 때도 인공위성을 먼저 띄우고 달에 사람을 먼저 보내려고 기싸움이 엄청 벌어지긴 했다. 그러나 우주 개발은 전적으로 자본력과 기술에 의해 승패가 기울었으며, 다행히 우주 공간에서 실종되거나 죽은 사람도 없다. 또한, 소련은 자기네 연구 과정을 워낙 폐쇄적으로 공개를 잘 안 하기도 했고 말이다. 그래서 아문센과 스콧에 필적하는 드라마틱한 이야기도 없는 듯하다.

Posted by 사무엘

인류 역사상 인간이 지구 밖으로 제일 멀리 나간 여행은 1970년의 아폴로 13호이다. 정말 다행스럽게도 세 명의 승무원이 모두 살아서 돌아오긴 했지만 예상치 못한 폭발 때문에 계획이 틀어진 후 승무원과 관제 센터 직원들은 가히 피 말리는 시간을 보냈으며, 특히 승무원들은 갈증과 추위에 떨면서 엄청난 고생을 해야 했다.

지구에서 가장 높은 산은 8848m(현재는 더 높아져서 8850이라고도 하는데)의 높이를 자랑하는 에베레스트 산이며, 인간이 역사상 최초로 공식적으로 등반 후 생환에 성공한 것은 1953년의 에드먼드 힐과 텐징 노르게이의 공동 등반이다.

지구에 있는 모든 산들은 높아 봤자 대류권의 영역을 벗어나지 않으며, 대류권에서는 고도가 1km 상승할수록 온도는 대략 6.4도 정도 떨어진다. 그래서 이런 높은 산들은 일년 내내 기온이 영하이고 눈이 녹지 않는 만년설 지대이다.
또한 해발 고도가 5천 m 정도 되면 기압도 해수면의 절반 정도로 떨어지고, 에베레스트 산의 정상 무렵에서는 아예 1/3기압이 된다. 물은 100도보다 낮은 온도에서 끓기 때문에 밥을 지어도 쌀이 잘 익지 않으며, 산소도 덩덜아 부족하기 때문에 비숙련자는 조금 걷기만 해도 지표면에서 100미터 전력질주를 한 것처럼 헉헉 숨이 차게 된다고 한다.

에베레스트 산 정도면 지형이 그렇게 험하지 않으며(특히 이웃의 콩라인 K2에 비해서) 인지도도 압도적이고, 덕분에 등산로도 개척될 대로 개척되어 있어서 찾는 사람이 연간 수백여 명에 달한다. 그래서 인근의 네팔은 등산료와 관광 수입을 톡톡히 챙기고 있다고 한다. 지금은 잘 알다시피 심지어 산소통 없이 등반한 사람까지 나왔다. 그러나 세계의 지붕인 이런 산들은 오늘날에도 만만한 곳이 아니어서 날씨가 험악할 때는 입산할 수 없으며, 해마다 최소한 국내의 철길 건널목 사망자 정도만치는 산에 오르다 죽는 사람이 꼭 나온다고 한다.

한편, 지구에서 가장 깊은 바다는 필리핀의 근처에 있는 마리아나 해구 중에서도 더욱 아래에 11034m의 깊이를 자랑하는 비티아즈 해연이다. 1957년에 이곳을 발견한 구소련의 탐사선 비티아즈 호에서 유래된 이름이다. 이 탐사선이 그렇다고 해연의 밑바닥까지 다 내려가 본 건 아니고, 일정 수준 이상의 깊이부터는 그냥 초음파만으로 깊이를 측정한 거라고. 실제로 거기 밑바닥까지 내려간 건 1960년에 미국에서 트리에스테-II 호가 해냈다.

일반 비행기가 공기 때문에 성층권도 못 벗어나고 한없이 높게 뜰 수는 없듯, 일반적인 잠수함들 역시 의외로 깊게 못 들어간다. 겨우 대륙붕 정도의 깊이밖에 못 들어가고 최첨단 핵잠수함도 500~700m 정도의 수심이 한계라고 한다. 군사 목적으로도 더 깊게는 들어갈 필요도 없고, 어차피 그 깊이 안에서 더 오래 머무르는 것만이 목적이니까 말이다. 더 깊게 들어가려면 그 용도로 특별히 제작된 심해 잠수정을 써야 한다.

1만 미터 정도의 수심에서 물체가 받는 압력은 무려 1천 기압. 1㎠당 8톤의 힘이 가해져서 주변에 있는 모든 것을 으스러뜨릴 것만 같은 살인적인 압력이다. 수심이 10미터 깊어질 때마다 대략 1기압이 증가하며(참고로 금성의 표면의 대기압이 90~95기압. 덜덜~) 덩달아 빛도 적어져서 어두워진다. 그래서 어느 수심과 압력 이상부터는 그야말로 암흑천지가 된다. 태양열이 닿지 않으니 수온 역시 영하급이다.

심해 잠수정은 실용성은 포기한 채 최대한 둥글고 작고 단단하게 만들어졌고, 트리에스테 호는 무거운 추를 잡고 가라앉은 뒤, 그 추를 바다에 버리고 다시 떠 올라오는 방법을 썼는데, 그때는 기술상의 한계로 20분 남짓밖에 못 머무르고 다시 올라와야 했다. 그러다가 타이타닉 호의 제작자인 제임스 카메론 감독이 거의 반세기 만에 비티아즈는 아니고 챌린저 해연이라고 만만찮게 깊은 밑바닥을 2012년 지난 3월 말에 탐사한 바 있다.

우주나 심해 탐사는 아무래도 전적으로 기계에 의존하지 않을 수 없다.
그러나 고산 등정은 성격이 약간 다르다. 극소수의 연구원이 최첨단 기계에 탑승해서 탐험하는 형태가 아니라 목적지를 직접 발로 걸으면서 탐험하며, 물자를 보급하는 보조 staff의 숫자도 아주 많다. 마치 영화 한 편이 배우들에 의해서만 만들어지는 게 아니듯이 말이다.

오늘날은 마음만 먹으면 항공기로 금방 에베레스트의 정상에 오를 수 있는데 왜 그렇게 힘들게 산을 오르냐는 질문은, 이건 마치 상대방을 쓰러뜨리려면 권총을 쓰면 되는데 뭣 하러 무술을 연마하냐 하는 식의 우문우답이 될 듯하다.

지구에 저런 높은 산 말고 또 남아 있는 혹독한 미지의 환경으로는 사막과 극지방이 있다. 이 중 사막은 제끼고, 지구의 자전을 느낄 수 없는 두 꼭지점인 북극점과 남극점은 18세기~19세기 초 사이에 탐험계의 성배로 여겨져 왔다. 그 당시 인류 최초로 북극점을 정ㅋ벅ㅋ한 사람은 미국의 로버트 피어리로 알려져 있었다(1909년 4월. 훗날 그건 오류로 판명되긴 했지만). 그리고 남극점을 정복한 사람은 잘 알다시피 그 이름도 유명한 노르웨이의 로알 아문센이다(1911년 12월).

산이나 해저나 우주 같은 다른 곳에 비해서는 비교적 일찍 정복된 영역이지만, 두 극점 중에서 남극점에는 다른 미지의 영역에는 없는 특이한 역사가 존재한다. 그때는 노르웨이의 아문센 팀과 영국의 로버트 스콧 팀이 남극점을 먼저 찍으려고 경쟁 중이었으며, 궁극적으로는 유럽의 듣보잡 빈민국에 불과했던 노르웨이가 물자가 월등히 더 풍부했던 대영제국을 누르고 압도적인 1등을 차지했기 때문이다.

게다가 아문센 팀은 1등을 했을 뿐만 아니라 한 명도 죽거나 다치지 않고 무사히 돌아와서(개들만 약 40마리쯤 죽었음;;) 국제적인 영웅이 된 반면, 스콧 팀은 그렇잖아도 1등 자리를 빼앗기고 우울하게 돌아오는 길에 며칠째 혹독한 눈보라 때문에 조난을 당해서 스콧 포함 5명의 팀원들이 추위와 굶주림 속에 모조리 목숨을 잃고 말았다.

두 팀의 결말이 이렇게 극과 극으로 달라진 것에는 단순히 운(날씨)보다 훨씬 더한 차이가 존재했다. 아주 간단히 요약하자면, 아문센은 원주민들의 노하우를 받아들여 극도로 최적화와 현지화를 잘 해 간데 반해 스콧은 남극 탐험을 너무 낭만적으로 생각했으며 쓸데없는 곳에서 괜히 명분과 품위만 따지다가 참혹한 낭패를 당했다. 다음 글에서는 이 사람들 얘기를 좀 해 보겠다.

Posted by 사무엘

1.

수학에서 원주율 pi와 자연상수 e는 가장 유명하고 친근한 상수임이 틀림없다. 이들은 유리수를 계수로 가지는 대수방정식의 근이 되지 않는 초월수임이 증명되어 있고, 이들의 정의나 다른 특성에 따라 값을 구하는 식이 여럿 존재한다.

pi = 4(1/1 - 1/3 + 1/5 - 1/7 + 1/9 ... )
e = lim (1 + 1/n )^n (n → 무한대)

pi의 저 공식은 정말 이보다 더 쉬울 수 있을까 싶을 정도로 너무 깔끔하고, 저게 도대체 파이와 어떻게 관계가 있을까 하는 생각이 들기도 한다. 사실, 저것은 arctan(tan의 역함수) 함수의 테일러 급수에다가 1을 대입하여 얻은 식이다. 45도일 때 기울기(=탄젠트)가 딱 1이 되니, 저 값은 pi/4가 나오고, 따라서 pi를 구하기 위해 4를 곱한 것이다.

e의 경우, 숫자를 무한대로 띄우는 n승과, 그 지수 연산의 발산 효과를 무효로 만드는 1/n (1에다가는 아무리 큰 지수 연산을 해도 그대로 1..)의 극한이 저렇게 가까워지는 게 신기하기 그지없다.

그러나 위의 두 공식은 둘 모두 n 값이나 항의 개수가 100000이 넘어가도 소숫점 겨우 네댓 자리까지밖에 일치하지 않을 정도로 수렴이 대단히 느린 게 흠이다. 이 방식으로는 소숫점 n째 자리까지 일치하려면 계산량이 n의 지수함수 형태로 증가해야 한다. 알고리즘으로 치면 엄청나게 비효율적인 알고리즘이다.
그래서 실제로 pi나 e의 값을 계산할 때는, 매 회에 좀 더 복잡한 계산이 수행되더라도 적은 횟수로도 더 빠르게 수렴하는 다른 식을 찾아 쓴다.

자연상수 e는 exp(x), 즉, 미분해도 자신과 동일한 함수의 테일러 급수로부터 얻은 식을 이용해 값을 구할 수 있다. 바로 n팩토리얼의 역수의 무한합인데, 직관적일 뿐만 아니라 수렴 속도도 아주 빠르다. 물론 팩토리얼이 숫자를 폭발적으로 키우는 연산이긴 하지만, 그만큼 정확도도 커져서 14!까지만 계산해도 소숫점 8~9자리까지 정확한 값이 나온다. 그래서 이걸로 끝이고 다른 계산법을 찾을 필요가 사실상 없다.

자연상수라는 이름엔  '자연'이라는 단어가 괜히 붙은 게 아니다. 얘는 수학의 입장에서는 특성이 매우 자연스럽고 직관적이고 사랑스럽기까지(!) 한 수이기 때문에, 초월수라는 증명도 상당히 초창기에 이뤄졌다. 리우빌 상수--10진법 기준 n!에 속하는 소숫점 자리만 1이고 나머지는 0인 좀 괴랄한 0.110001000… --처럼 초월수의 존재를 증명하기 위해 일부러 설정된 수가 아닌 수 중에서는 초월수라는 게 증명된 최초의 수가 바로 자연상수이다.

pi는 e보다 더 오묘한 수여서 초월수 증명도 10년 남짓 더 늦게 나왔으며, 더욱 복잡하고 다양한 유도식들이 존재한다. 특히 컴퓨터가 발명되고 원주율 계산이 컴퓨터의 성능을 측정하는 잣대로 통용되기 시작한 뒤부터는 컴퓨터의 입장에서 더욱 계산하기 쉬운 형태의 식이 연구되기 시작했다. 그래도 어느 것이든 e만치 형태가 간단하면서도 빨리 수렴하는 식은 존재하지 않는 것 같다.

비록 컴퓨터 시대에 발견된 식은 아니지만,
sqrt(2) / 2 라는 분수에서 시작하여
sqrt( 2+ sqrt(2) ) / 2와 같은 식으로 분자에다가만 x → sqrt(2 + x)로 변환을 하면서 생성된 수들을 계속 곱하면 2/파이 (파이의 역수의  두 배)에 수렴하는데,
이것도 e만치는 아니지만 계속되는 곱셈과 제곱근 버프 덕분인지 수렴 속도가 빠른 편이다.

2.

1부터 n까지 자연수가 있고 이들의 역수를 나열하면 조화수열이 된다. 조화수열의 무한합은 비록 무지막지하게 느리지만 무한대로 발산한다는 것이 알려져 있다.
한편 n!의 역수의 무한합은 아까 말했듯이 e가 되는데,
그럼 n^2의 역수의 무한합은 무엇이 될까?

거듭제곱의 지수가 1보다 커지는 순간부터 역수의 무한합은 유한한 값으로 수렴하긴 한다. 그러나, 그 수렴값의 특성을 알아내는 건 아주 어려운 일이어서 지금까지도 알려진 게 그리 많지 않다.
n^x의 역수의 무한합을 일반적으로 x에 대한 리만 제타 함수값이라고 한다.

그리고 그 x가 짝수일 때는 놀랍게도 pi와 관련이 있는 값으로 수렴한다는 것이 천재 수학자 오일러에 의해 밝혀졌다. 가령, 2일 때는 이렇다.

1 + 1/4 + 1/9 + 1/16 + 1/25 ... = pi^2 / 6

그러니 이것도 응당 파이를 구하는 데 쓸 수 있는 공식이다.
비록 이것 역시 아까의 1/3 1/5 1/7 공식 만만찮게 수렴 속도가 몹시 느리기 때문에 실용성은 떨어지지만 말이다.

여기서 갑자기 pi가 튀어나오는 것도 신기하지만, 이 수의 진짜 놀라운 면모는 또 다른 곳에 있다.
바로 이 수는 자연수에 존재하는 소수의 분포와 관계가 있다.

1부터 N 사이에 있는 임의의 두 자연수를 뽑았을 때 이것이 서로 소일 확률은 N이 커질수록 바로 저 수, 다시 말해 (pi^2)/6의 역수로 수렴한다! 그 확률은 대략 60.8%이다.

아니, 리만 제타 함수에서 파이가 왜 조건부로 튀어나오며, 게다가 미적분· 해석학하고는 아무 관계가 없는 정수론과 관련된 의미가 왜 이런 데서 발견되는 걸까? 이걸 알아 낸 사람도 오일러이다.

2를 포함해서 리만 제타 함수의 짝수승의 값은 그래도 pi가 얽혀 있으니 초월수라는 건 확실히 인증이다만 홀수승의 값들은 무리수인 것만 알려져 있지 다른 특성은 알려진 바가 없다. 초월수일 게 거의 확실시되고 있긴 하나, 그조차도 정식으로 증명되지는 못했다.

3일 때의 값은 '아페리 상수'라 하여 일부 공학 분야에서도 쓰인다. 이 수가 무리수라는 증명을 1978년에 한 프랑스의 수학자 아페리의 이름을 딴 것이다. 정의대로 각 자연수들을 3승한 뒤 역수를 구해서 더하면 값을 구할 수 있지만, FM 방식은 역시 수렴이 더디기 때문에 훨씬 더 복잡하지만 더 빨리 수렴하는 별도의 급수 전개를 써서 값을 구한다.

그런데 이 값의 역수는 임의의 세 자연수가 서로 소일 확률이라고 한다. 마치 가위바위보에 참여하는 인원이 많아질수록 무승부가 나올 확률이 치솟듯, 세 자연수는 두 자연수일 때보다 서로 소일 확률이 올라가서 그 값은 약 83.1%에 달한다.

작은 범위에서라도 정말 얼추 그렇게 되는지는 프로그램을 짜서 간단히 확인해 볼 수 있다.
1부터 N까지 3중 for 문을 작성해서 모든 숫자 조합에 대해서 최대공약수를 구해서 1이 나오는 경우를 세면 되는데, N이 몇천 정도만 돼도 3중 for 문은 오늘날의 최신 컴퓨터에서도 버벅대는 작업량이다.

3.

그래서 본인, 이 기회에 멀티코어 프로그래밍을 실습해 봤다.
i5 쿼드코어답게 CreateThread 함수로 스레드를 4개 만들어서 뺑뺑이를 돌리는 분량을 인위로 분할한 뒤, 계산 결과를 취합했다. 그랬더니...

809615629/973620600 0.831551 (7753)
809615629/973620600 0.831551 (3448)

코어 하나밖에 못 쓰고 고로 CPU를 최대 25%만 쓰던 싱글스레드 오리지널 코드는 7.8초가 걸린 반면,
스레드를 여러 개 만드는 코드는 CPU를 95% 가까이 점유하면서 제 속도를 내더니, 싱글스레드의 절반이 채 안 되는 3.5초 남짓한 시간 만에 처리를 다 끝내는 걸 알 수 있었다. 실제로 서로 소인 조합이 전체의 83.1%가량을 차지하는 것도 사실이었다.

요즘 세상에 CPU를 70% 이상 한꺼번에 점유하는 프로그램을 내 손으로 직접 만들 일은 없었는데 참 오랜만에 보는 광경이었다. 요즘은 단일 프로그램이 CPU 성능을 제대로 활용하려면 이런 식의 테크닉을 동원해야 한다는 걸 더욱 절실히 느끼게 됐다.

Posted by 사무엘