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

오뚜기 3분 고기덮밥은 본인이 태어나서 최초로 접한 레토르트 파우치 식품이다. 물론 밥까지 들어있는 건 아니기 때문에 덮밥 '소스'일 뿐이라고 단서가 자그맣게 붙어 있다.
영문 명칭 Goulash에서 알 수 있듯, 얘는 유럽풍의 매콤한 쇠고기 스튜 요리에서 컨셉을 따 온 듯하다.

처음 먹었던 때가 20여 년 전 초딩 중저학년 시절이었는데, 본인은 그때부터 이걸 굉장히 좋아했다. 비슷한 상품인 3분 짜장, 카레, 하이스보다도 더.
그 시절에 고기덮밥의 개당 가격은 700얼마 정도 했었다.

그런데 어느 샌가 이 고기덮밥은 상점에서 자취를 감추기 시작해서 더는 찾아 먹을 수가 없게 됐다. 유사 상품들도 다 변함없으며, 햄버그 스테이크나 미트볼도 지금까지 멀쩡히 팔리고 있는데 유독 고기덮밥만 없어진 것이다. 펭귄 통조림은 회사가 망하면서 단종된 게 맞지만, 고기덮밥은 왜 혼자서 단종됐지..??

그러나 여기에도 반전이 있었다. 없는 게 없는 인터넷 쇼핑몰을 뒤져 보니 고기덮밥은 멀쩡히 잘 팔리고 있었다. 이에 본인은 곧바로 12개짜리 패키지를 질러서.. 오랜만에 옛날 맛을 즐겨 보았다. 냠냠~

얼마 전엔 계몽사에서 에메랄드 색 '어린이 세계 명작 전집'을 재판해서 판매하자 옛날 추억에 잠긴 독자들이 많이 주문을 했었다... 내가 바로 그런 심정이다. 단지 이번엔 동화책이 아니라 인스턴트 식품일 뿐.

유통기한이 2016년 여름일 정도로 지금까지도 멀쩡히 잘 생산되고 있는 물건인데
왜 오프라인 상점에서는 편의점부터 홈플러스/이마트 등 대형 마트까지.. 좀체 물건을 찾을 수 없는지 난 이유를 도저히 모르겠다. 3분 고기덮밥을 오프라인 상점에서 목격하신 분(증명-_-), 혹은 반대로 그게 왜 온라인으로만 판매되고 오프라인 상점에서는 사라졌는지 이유를 아시는 분은 본인에게 제보해 주시길 바란다.

* 나같은 사람이 맛집이나 음식 소개를 한다는 건 정말 이례적인 일이다.. 전선 휴게소 메기 매운탕에 이어 음식 소개는 이번이 거의 두 번째이다. ㅎㅎ

Posted by 사무엘

우리 주변에서 연료를 태워 열 내지 에너지를 만드는 도구, 기계들을 생각해 보자.
하긴, 옛날에는 불을 최초로 피우는 것조차도 여간 어려운 일이 아니어서 집집마다 한번 만들어 놓은 불씨를 잘 간수해야 했으며, 옛날까지 갈 것도 없이 무인도 같은 오지· 험지에 홀로 내던져졌다면 불을 피우는 게 매우 중요한 생존 기술 중 하나로 변모한다. 성냥, 양초 같은 물건도 주류에서 밀려난 구시대 유물일지언정 완전히 없어질 수는 없을 것이다.

이렇게 연소나 폭발을 취급하는 물건들은 어떤 형태의 연료를 쓰는지에 따라 설계 방식이나 동작의 특성이 달라진다.
연료라는 건 크게 고체 아니면 액체로 나뉜다. 고체는 나무나 석탄, 혹은 다른 고체 폭약 같은 것이고, 액체는 잘 알다시피 석유나 액화 천연가스가 대표적이다.

일반적으로 액체 연료를 다루는 기계적 메커니즘이 고체 연료보다 더 복잡하고 까다롭다.
그러나 액체 연료가 그만큼 연료를 아주 찔끔찔끔 균일하게 공급하면서 화력을 조절하기가 더 쉽다. 그리고 연소 후의 부산물도 액체 연료가 훨씬 더 깔끔하며 처리하기가 더 편하다.

고체 연료를 사용하는 연탄/화목 보일러나 난로는 불에 탈 수만 있다면 통나무건 종이 뭉치건 아무 덩어리나 집어넣어도 되니 기계 구조가 간단하고 당장 열을 만들어 내는 건 쉽다. 하지만 그 뒤부터는 여러 모로 불편한 점과 애로사항이 꽃핀다. 매캐한 연기와 냄새가 나며, 일단 불이 붙은 연료를 통제하기가 어렵다. 점화나 소화를 스위치 하나로 간편하게 할 수가 없다.

연탄은 크기와 모양이 규격화돼 있는 고체 연료라는 점은 그나마 낫지만, 여전히 점화와 소화가 불편하며 연료를 배달하기가 매우 번거롭다. 매번 연탄재를 처리하는 것도 큰일이고 말이다.
양초는 고체 연료인 것치고는 심지를 통해 연소가 균일하게 잘 일어나는 편이지만, 역시나 강약 조절을 할 수 있지는 않다.

옛날에 증기선이나 증기 기관차에는 보일러에다 석탄을 삽으로 퍼 넣는 화부가 탑승해야 했으며 즉각적인 동력 조절이 되지 않았다. 고체 연료 화통의 화력은 공기를 불어넣는 양 정도로나 조절 가능했다. 성경의 다니엘서에서 풀무불을 평소보다 일곱 배나 더 뜨겁게 하는 건 과연 기술적으로 어떻게 실현했을까? (단 3:19)

이것은 발사체인 고체 연료 로켓도 고스란히 갖는 한계이다. 한번 점화가 된 뒤에는 연료의 연소를 일시적으로 중단하거나 동력 조절을 할 수 없으며, 가능하다 해도 그 과정은 몹시 어렵다.

이런 이유로 인해 요즘은 관광용 증기 기관차도 물을 끓여서 나아갈지언정, 물을 데우는 건 석탄이 아닌 석유로 한다.
그리고 로켓에는 액체 연료 로켓이 연구되었으며, 이 바닥의 선구자는 미국의 물리학자 로버트 고다드이다. 우리말 표기로는 '더'와 '다'가 공존하면서 혼란스러운 이름인데...

공기가 없는 우주에서도 움직이는 액체 로켓은 연료 자체뿐만이 아니라 산화제까지 액체여야 하기 때문에 고체 로켓보다 만들기가 더욱 어려웠다. 증발이나 부식 같은 문제 때문에, 산화제와 연료를 주입한 채로 로켓을 장시간 발사대에 놔 둘 수 없다는 점도 대단히 번거로운 점이다. 로켓의 발사가 연기된다거나 하면 그것들을 도로 빼내야 한다.

그럼에도 불구하고 액체 연료 발사체 기술 덕분에 인간이 우주로 나갈 수도 있을 정도로 안정적이고 통제 가능한 발사체가 만들어질 수 있게 되었다.
라이트 형제가 동력 비행을 성공한 지 30년이 채 되지 않아 미국의 학계에서는 로켓의 이론적 근간이 연구되고 “달까지 가는 진지한 방법” 같은 게 논문으로 발표되고 있었다니 정말 대단한 일이 아닐 수 없다. (한때는 그랬는데 미국이 어쩌다가 스푸트니크 멘붕을 당할 정도로 잠시 주춤했는지?)

단, 고다드의 연구는 시대를 너무 앞서 있었으며, 그 당사자 역시 언플이나 사교력이 뛰어난 공돌이는 아니었던 관계로... 그의 연구는 그가 살아 있는 동안에는 딱히 인정을 못 받았다. 1920년대에 뉴욕 타임스 신문은 고다드가 불가능한 목표를 두고 아무 쓰잘데기 없는 황당한 뻘짓을 한다고 막 조롱하고 디스하고 망신 주는 사설을 게재했을 정도였다.

그러나 그로부터 수십 년이 지나고 고다드의 연구를 토대로 새턴 로켓이 발사되고 아폴로 우주선이 달까지 간 뒤에야 뉴욕 타임스는 자기네 옛날 사설을 취소하고 고인에게 사죄를 했다. “그런데 그것이 실제로 일어났습니다. 님의 연구 덕분에 후손들이 달에 진짜로 갈 수가 있었습니다. 우리의 생각이 짧았습니다.”라는 요지로.

이건 20세기의 우주 개발 역사에서 매우 유명한 일화이다. 우리나라로 치면 일제나 독재 정권에 아부하던 메이저 언론이 나중에 자기 잘못을 스스로 인정하고 사죄한 것과 완전히 같지는 않아도 비슷한 격인데, 우리나라 언론에서는 찾기 힘든 모습인 것 같다. =_=;;

이것저것 얘기가 많이 나왔는데..
여러 분야를 막론하고 액체 연료는 고체 연료에 비해 점화· 소화와 화력 제어가 용이하고 연소 결과가 깨끗하다는 많은 장점이 있음을 알 수 있다.
이제는 친구들과 삼겹살을 구워 먹으러 갈 때도 고체 연료(숯)를 쓰는 식당과 액체 연료(도시 가스)를 쓰는 식당의 구조적인 공통점과 차이점을 나눠서 생각할 수 있을 것이다. 다만, 고기를 굽는 데는 '연기와 향'이라는 변수가 추가되기 때문에 굳이 경제적으로는 더 불편한 고체 연료가 선호되기도 한다. ^^;;;

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.
지난 추석 때, 고향을 왕래하는 고속버스 차창 밖으로.. "고속국도 제1호선 언양-영천간 확장 공사" 라고 표지판이 붙고 터가 닦여 있는 걸 봤다. 경부 고속도로가 개통 이래로 지난 40여 년간 최후까지 오리지널 4차선 그대로 남아 있었던 마지막 구간까지도 드디어 확장된다니 감회가 새롭다.
이 고속도로에 대해서는 3년 남짓 전에도 글을 한번 쓴 적이 있으니 참고하시길.

경부 고속도로의 옛날 사진을 보면 중앙 분리대가 화단 형태로 된 모습이 있어서 무척 신기하게 보인다.

또한 옛날에는 일부 직선 구간(성환, 신갈)은 아예 물통 같은 임시 중앙 분리대만 만들어 놓고 유사시에 활주로로 쓸 수 있게 해 놓기도 했다. 그리고 실제로 해당 구간을 잠시 폐쇄하고서 전투기 이착륙 훈련을 한 적도 있다.
아래 사진은 신갈 활주로에서 실제로 훈련을 하던 모습이다. 신갈 일대 고속도로 좌우 모습이 저랬을 정도이면, 아니 경부 고속도로의 수도권 구간을 폐쇄하는 게 가능했을 정도이면 지금으로부터 엄청, 굉장히 먼 옛날의 일일 것이다.

화단 형태든 임시 형태든.. 경부 고속도로의 중앙 분리대가 모습이 저랬다는 것은 오늘날로서는 참 상상하기 힘든 모습이다.

경부 고속도로는 처음에는 전구간 4차선으로 건설되었다.
지금이야 88 올림픽만이 전국 유일의 겨우 2차선짜리 고속도로라고 까이지만, 옛날에는 반대로 경인과 경부 정도만이 처음 만들어질 때부터 다차선이었다. 2차선 고속도로는 여럿 있었다. 당장 호남이나 영동 등.
그런데 옛날에야 그렇다 치더라도 1990년대까지만 해도 높으신 분들이 무슨 생각을 했는지 모르겠지만, 고속도로를 마치 88 올림픽처럼 겨우 2차선으로 만들려는 시도가 있었다.

대표적인 예가 중앙 고속도로인데.. 이건 마치 21세기에 개통 예정인 철도를 표준궤가 아닌 협궤 크기로 만드는 것만큼이나 막장 행위였다. 이것은 다행히 감사원으로부터 지적을 받은 끝에 뒤늦게 4차선으로 허겁지겁 개조되었다.

감사원? 철도에서 일산선 건설도 서울 지하철 3호선처럼 우측 직류 규격으로 임의로 바꿔서 과천-안산선처럼 꽈배기굴 시즌 2가 생길 뻔한 것을 막은 그 기관 말이다. 철도뿐만 아니라 고속도로를 만들 때도 그나마 세금값을 했다.

2.
철도 경부선은 영업거리표 상으로 서울에서 부산까지 공식 거리가 441.7km이다.
옛날처럼 지금의 서울 역(그 당시엔 남대문) 이북으로 레알 서울 역이 있고, 지금의 부산 역(그 당시엔 초량) 이남으로 진짜 부산 역이 또 있었다면 거리는 지금보다 2km 남짓 더 길어졌을 것이다.
한편, 경부선 철도에 상응하는 경부 고속도로의 전체 거리는 416.4km이다. 개통 당시엔 428km가량이다가 선형 개량을 통해 더 짧아진 것이다.

그런데 여기서 의문이 생긴다.
경부 고속도로는 경주와 울산을 거쳐서 크게 우회하는데 어떻게 유사 노선의 철도보다 거리가 이렇게 짧을 수 있느냐는 것이다. 물론 경부선도 서울 구간에서는 서쪽 영등포 방면으로 우회를 좀 해서 동선이 안 좋지만, 그래도 고속도로에 비할 바는 아니기 때문이다.

하지만 해답은 생각보다 간단한데, 바로 시내 구간의 포함 여부이다.
철도는 서울 역이라는 서울 도심으로 깊숙이 들어가며, 부산 역도 부산 시내를 다 관통한 후 완전 최남단에 있다.
그러나 고속도로는 양재 IC라는 서울 남쪽 외곽에서 끝나고, 부산도 시점인 구서 IC는 부산의 북쪽 끝자락이다.
양재IC - 서울 역 내지 구서-부산 역만 쳐도 각각 직선 거리만 거의 15km에 달한다.

이걸 퉁쳐 주면 고속도로나 철도나 거리는 서로 비슷해진다.
경부선 기존선이 아니라 서울-대구 구간을 고속선으로 달리는 KTX는 서울-부산 전체 주행 거리가 408km대로 크게 감소한다. 경부고속선이 기존 선로의 구불구불하던 주름을 얼마나 폈는지를 알 수 있다.
하지만 대구 이남 구간은 고속선이 경주와 울산을 경유하기 때문에 KTX의 거리는 423.8km로 15km 남짓 증가한다.

3.
교통· 운수 업계에서는 경사로의 기울기나 차량의 등판능력을 말할 때 각도가 아니라 언제나 기울기(탄젠트)를 쓴다. 고정된 X축 거리를 이동하는 동안 높이 Y가 바뀌는 비율인 것이다.
요즘은 자동차 제원표에서 찾아보기 힘들지만 보통 등판능력이 0.3xx가 나오는데, 그것도 탄젠트이기 때문에 실제 각도는 10몇 도 정도이다. 도로 표지판에서 볼 수 있는 5% 경사, 10% 경사 이런 것도 당연히 탄젠트 값임.

우리나라 K2 전차의 홍보 영상을 보니 무슨 60도 경사를 오른다고 자랑을 하던데.. 이건 오류이다.
45도보다도 높은 60도 경사를 오른다는 건 말도 안 되는 소리이고, 사실은 탄젠트 0.6에 해당하는 거의 30도대의 오르막을 오를 수 있다는 뜻이다. 그 무거운 쇳덩어리가 그 정도 경사를 오르려면.. 엔진 힘뿐만이 아니라 무한궤도를 이용한 접지력이 정말 살인적인 수준이어야 할 것이다.

철도 차량은 일반 육상 차량보다 등판능력이 훨씬 뒤떨어지기 때문에 백분율도 아니고 천분율을 써서 '퍼밀' 단위로 표기한다. 각도로는 2도가 채 안 되는 30 퍼밀 정도의 경사도 철도 차량에게는 우리나라의 태백선 같은 산악 철도에서나 볼 수 있는 굉장한 급경사이다. 견인 중량이 가히 상상을 초월하는 데다 쇠 바퀴와 쇠 선로는 마찰도 작으니 등판능력이 쥐약일 수밖에 없다.

육상 교통수단뿐만 아니라 비행기의 상승/하강률도 기울기로 표기된다. 1000m를 이동하는 동안 고도가 몇 m 바뀌는지가 기준이다. 우주왕복선은 엔진이 없이 글라이더 활강을 하기 때문에 일반 여객기보다 하강률이 훨씬 더 높다. 정확한 숫자를 본 적이 있었는데 또 찾기는 귀찮..;;

이렇게 업계에서 각도 대신 탄젠트가 즐겨 쓰이는 이유는, 일상생활에서는 고저차를 무시한 이동 거리가 더 중요하게 다뤄지며, 또 경사각이 올라갈수록 차량에게 필요해지는 동력 같은 각종 물리량도 각도가 아니라 탄젠트에 비례해서 급격히 올라가기 때문이다. 여러 모로 탄젠트가 현실적인 의미가 더 크고 유용하다는 뜻이다.

Posted by 사무엘

1. disabled 스타일 개론

소프트웨어 GUI에서 대화상자나 메뉴 같은 구성요소를 보면, 상태를 나타내는 속성 중에 논리값으로 enabled 여부라는 게 존재한다.
이게 false여서 disable된 물건은 비록 화면에 보이긴 하지만 흐리게 표시되며 완전히 없는 물건으로 취급된다. 사용자의 키보드나 마우스 조작에 반응을 하지 않으며 선택할 수도 없다.

Windows 운영체제에서는 윈도우에서 WS_DISABLED라는 스타일 비트가 이런 역할을 한다. 기본 스타일에 이 비트가 지정되어 있는 윈도우는 키보드 포커스를 받을 수 없으며, 거기에다 대고 마우스 포인터를 움직여도 통상적인 WM_MOUSEMOVE, WM_?BUTTONDOWN 같은 메시지가 오지 않는다.

즉, availability는 어느 정도 운영체제가 직접 관리를 해 주는 예약된 속성이다.
어떤 윈도우가 enabled인지 여부를 알려면 IsWindowEnabled 함수를 호출하면 된다.
IsWindowEnabled(hWnd)는 !(GetWindowLongPtr(hWnd, GWL_STYLE)&WS_DISABLED)와 동치라고 생각하면 된다.

enabled 여부를 설정하는 함수는 EnableWindow이다. 이때 대상 윈도우는 WM_ENABLE라는 메시지를 받음으로써 자신의 availability 속성이 바뀌었다는 통지를 받는다.
Get과 마찬가지로 SetWindowLongPtr를 통해 스타일을 수동으로 바꿔 줘도 거의 같은 효과를 낼 수 있다.
단, 이 방법은 간단히 전용 함수를 호출하는 것보다 번거로우며, 이렇게 속성이 바뀌면 대상 윈도우는 WM_STYLECHANGED만을 받지 WS_DISABLED 비트에 차이가 있더라도 WM_ENABLE 메시지가 오지는 않는다.

2. 화면에 그리기

대화상자 컨트롤이라면 WM_ENABLE 메시지가 왔을 때 자신을 화면에 다시 그리는 처리를 한다.
가령, 평소에는 COLOR_WINDOWTEXT라는 시스템 색상으로 글자를 찍은 반면, disable된 뒤부터는 COLOR_GRAYTEXT 색상으로 글자를 다시 찍는다.

지금이야 Windows 8 때부터 고전 테마라는 게 사라져서 점차 과거의 유물이 돼 가지만..
옛날에 Windows UI를 보면, 메뉴나 도구모음줄에서 사용할 수 없는 항목은 글자가 단순히 회색이 아니라 흰색 위에 회색이 깔려서 뭔가 음각 엠보싱처럼 그려지곤 했다.

그거 처리를 해서 disable 상태를 화면에 표현하는 건 DrawState라는 함수 호출 한 방이면 바로 된다. 이건 딱 회색 3D 대화상자 스타일이 도입된 Windows 95와 NT4에서 첫 추가된 함수이다. 게다가 텍스트와 비트맵(아이콘) 모두 그렇게 그리는 걸 지원한다.

비트맵의 경우, 마스크 비트맵을 바탕으로 엠보싱을 만들며, 이 테크닉은 지금도 그대로 쓰인다. 그렇기 때문에 요즘은 32비트 비트맵 내부의 알파 채널이 투명색을 대신하는 지경이 되었음에도 불구하고 DrawState 함수로 disable 상태의 엠보싱 아이콘을 그리려면 비트맵에 모노크롬 흑백 배경 마스크 비트맵도 넣어 줘야 한다.
뭐, 궁극적으로는 트루컬러 아이콘이라면 구시대스러운 비트 연산이 아니라, 투명도를 높이고 채도를 낮춰서 그림을 더 엷고 탁하게 만드는 '현대적인' 방식으로 disable 상태를 그려야 하겠지만 말이다.

3. disabled 윈도우의 또 다른 용도

그러면 이런 disabled 속성은 오로지 대화상자 내부의 컨트롤 같은 WS_CHILD급 윈도우에서만 쓰이는가 하면 그렇지 않다. 타 윈도우의 자식이 아니라 top-level이 될 수 있는 WS_POPUP급 윈도우도 WS_DISABLED 속성을 줘서 생성할 수 있다. 이 윈도우는 화면이 달랑 떠 있기만 하지 사용자가 포커스를 줘서 키보드 입력을 할 수가 없게 된다.

사실, 한 프로세스 안에서 child 윈도우는 클릭했다고 해서 딱히 포커스가 자동으로 거기로 옮겨지지는 않는다. 포커스가 가는 건 해당 윈도우가 WM_LBUTTONDOWN이 왔을 때 SetFocus를 자체적으로 호출했기 때문이다.
그러나 소속된 프로세스가 다른 top-level 윈도우의 경우, 클릭하면 일단 그 창으로 WM_ACTIVATE 메시지가 가고 컨텍스트 전환이 발생한다. 이것은 프로그램의 의사와 무관하게 운영체제가 일방적으로 하는 일이었는데, disabled 윈도우는 그걸 막을 수 있다.

물론 disabled 윈도우는 앞서 말했듯이 정상적인 마우스 메시지가 오지 않는데, 그래도 이것도 받는 방법이 있다.
disabled라고 해도 top-level 윈도우에는 기본적으로 마우스 포인터 설정을 위해서 WM_SETCURSOR 메시지 정도는 온다. 이 메시지의 lParam에는 이 윈도우에 원래 오려고 한 메시지가 담겨 있기 때문에 이를 토대로 비록 disable 상태이지만 마우스 동작에 반응을 하도록 프로그래밍이 얼마든지 가능하다. child 윈도우가 아닌 top-level 윈도우이기 때문에 이런 메시지가 온다.

disabled 편법을 쓰지 않고 '클릭해도 반응만 하지 포커스가 바뀌지는 않는 간단한 윈도우'라는 개념은 비교적 늦게 등장했다. Windows 2000부터 WS_EX_NOACTIVATE라는 확장 스타일이 정식으로 도입된 것이다. 이런 윈도우는 ShowWindow에다가도 단순히 SW_SHOW가 아니라 SW_SHOWNOACTIVATE를 줘야 한다.

4. 상태 변경과 관련된 연계 작업들

대화상자에서 컨트롤을 enable/disable시키는 상황은 크게 선천적인 것과 후천적인 것으로 나뉜다. 전자는 WM_INITDIALOG에서 단 한 번 enable 여부가 결정되고 그 뒤에 대화상자가 닫힐 때까지 그 상태가 바뀔 일이 없는 경우를 말한다.
후자는 한 컨트롤의 조작 여부나 값에 따라 다른 컨트롤의 enable 상태가 인터랙티브하게 수시로 바뀌는 경우를 가리킨다. 예를 들어 라디오 버튼이 특정 항목으로 맞춰져 있을 때만 조건부로 사용 가능해지는 하부 조건 체크박스 같은 것. UI 프로그래밍을 해 본 분이라면 이 분류가 수긍이 갈 것이다.

그런데 이렇게 컨트롤들의 상태를 바꾸는 건, 단순히 한 윈도우에 대해 EnableWindow를 호출하는 것 이상으로 이와 결합된 반복 패턴이 여럿 존재한다.

(1) 첫째, 대상 컨트롤의 이전에 있는 label 컨트롤을 같이 enable/disable시키는 경우이다. 대상 컨트롤이 버튼이라면--push, check, radio 모두 포함-- 그 자체가 &로 시작하는 Alt 액셀러레이터 글쇠를 갖는다. 그러나 나머지 edit, list, combo 박스 같은 것들은 자신의 액셀러레이터가 없으며 그 이전의 static 라벨로부터 액셀러레이터를 넘겨받는 형태이다.

따라서 그런 컨트롤이 disable됐다면 자기의 앞의 컨트롤도 같이 disable되는 게 이치에 맞다. 앞의 단순 label은 보통 독자적인 컨트롤 ID가 없이 그냥 IDC_STATIC인 경우도 많으므로 핸들값을 GetWindow(hCtrl, GW_HWNDPREV)로 얻어 오는 수밖에 없다.

(2) 둘째, 대상 컨트롤을 화면에서 감출 때에도 ShowWindow(hCtrl, SW_HIDE)만 할 게 아니라 disable을 시켜 줘야 한다. 왜냐 하면 enable 상태인 컨트롤은 비록 화면에 없더라도 Alt 액셀러레이터에는 반응을 해서 사용자가 여전히 기능 접근이 가능하기 때문이다.
본인은 개인적으로는 이게 바람직한 설계가 아니라고 생각하며, Windows가 왜 그렇게 동작하는지 알지 못한다. 하지만 어쨌든 Windows 95부터 8.1에 이르기까지, 조건부로 컨트롤들을 보였다가 숨겼다가 하는 UI의 경우, 감춰지는 컨트롤은 disable도 시켜 줘야 한다.

(3) 셋째, 지금 키보드 포커스를 받고 있는 컨트롤이 disable되는 경우, 포커스를 자신의 다음 컨트롤로 옮기는 일을 해당 프로그램이 수동으로 해 줘야 한다. 이걸 안 해 주면 그 컨트롤이 disable된 뒤부터 키보드 상태가 꼬여 버린다.
이 단서의 주된 적용 대상은 push-버튼이다. 대표적인 예로는 프로퍼티 페이지에 있는 '적용' 버튼. 이 버튼을 누른 순간 이 버튼은 사용 불가 상태가 되며, 사용자가 다른 설정을 또 건드려 줘야 다시 사용 가능해지니 말이다.

본인의 개인적인 생각은 이것도 역시 운영체제가 자동으로 처리해 줘야 하는 게 아닌가 싶지만, 현실은 시궁창이다. 생각보다 자비심이 없다..;;
대화상자에서 특정 컨트롤에다 포커스를 주는 건 SetFocus를 해서는 안 되며, 대화상자 부모 윈도우에다가 WM_NEXTDLGCTL 메시지를 보내는 방식으로 해야 한다. 그렇게 해야 대화상자의 default 버튼에 굵은 테두리가 그려지는 처리가 올바르게 된다.

그래서 본인은 위의 세 시나리오를 모두 감안하여 대화상자 컨트롤을 enable/disable시키는 함수를 별도로 만들어서 사용하고 있다.
그림을 좀 더 곁들이면 전반적으로 설명하기가 더 편하겠다는 생각이 드는데.. 귀찮아서 생략한다. ㄱ-

Posted by 사무엘

2014년의 끝을 앞두고 <날개셋> 한글 입력기가 새 버전이 나왔다.
그 어느 때보다도 다방면에서 리팩터링, 기능 추가, 버그 수정이 진행되어 프로그램의 완성도가 더욱 향상되었다. 이 글은 지난달에 썼던 GUI 개선 사항에다 또 덧붙여진 주요 변화 사항에 대한 설명이다.

※ 한글 입력 관련

1. 일부 특수글쇠의 '두벌식 종성' 지원 강화

'도깨비불', 그리고 '초· 종성 교환' 특수글쇠가 두벌식 종성까지 감안해서 동작하게 했다.
전자의 경우, 두벌식 종성 글쇠로 '않' 같은 글자를 입력하고 있었다면 '안ㅎ'에서 ㅎ이 초성이 아닌 종성 형태로 분리되어 나온다. 또한 지금까지 이 글쇠는 종성이 단독으로만 있을 때는 동작하지 않았지만, 이제는 종성 단독이더라도 ㄶ 자음끼리 분리가 가능할 때는 동작하게 알고리즘을 개선했다.

후자의 경우를 설명하자면 이렇다. '강'이라는 글자를 '악'이라고 바꿔 주는데, 애초에 글자를 두벌식 종성으로 입력하고 있었다면 이때에도 '악'을 지울 때 ㅇ은 비록 지금은 초성 모양이지만 처음에 종성으로 입력한 것처럼 재현을 해 준다. 이런 변칙적인 상황에 대한 배려를 추가했다. 두벌식은 역시 세벌식보다 근본적으로 처리가 복잡한 방식임을 알 수 있다.

2. 외부 모듈에서 글쇠를 인식하는 알고리즘 개선

사용자에게는 예전 것이나 지금 것이나 큰 차이가 안 느껴지겠지만, 이번 버전에서는 외부 모듈도 글쇠를 인식하는 뼈대 부분을 다시 구현했다.
이 과정에서 외부 모듈에서는 구조적으로 Alt 조합의 인식이 지원되지 않는다는 것을 UI 차원에서 확실하게 표시하게 했다. 외부 모듈에서 단축글쇠 추가/편집 대화상자를 꺼내면 Alt에 해당하는 슬라이더가 사용 불가능 상태가 된다.

또한 우리 프로그램이 가로채지 않는 글쇠는 조합이 있는 중에도 확실하게 가로채지 않게 동작을 개선했다. 예를 들어 space 같은 글쇠는 예전까지는 한글을 조합 중일 때 누르면 우리 프로그램이 언제나 가로채지만 다음 버전부터는 그걸 가로채지 않고도 모든 구현체에서 조합 종료 처리도 매끄럽게 된다.

3. 초-종성 공유 방식의 종성 결합에 대해 가상 낱자와 낱자 치환 규칙 자동 적용

글쇠 수가 매우 적은 휴대전화 입력 방식에서는 어지간한 거센소리나 된소리 계열 자모도 2타 이상의 합성으로 만들곤 한다. 그렇기 때문에 조합 과정에서 ㄴ+ㅇ, ㄱ+ㅆ처럼 현실에서 존재하지 않는 낱자를 특히 종성에다 임시로 풀어서 표현해야 하는 일이 생긴다.

앞부분을 표현하기 위해서는 기존 가상 낱자를 쓰면 되고, 현재 글자의 경계를 넘어가는 뒷부분을 표현하기 위해서는 지난 7.4 버전에서부터 고급 입력기에다 '낱자 치환' 규칙이 추가되어 현재는 이 문제가 깔끔하게 해결되었다.
그러나 ㄴ+ㅇ을 300 같은 가상의 낱자 결합으로 등록하고, 그 300에 대해서 ㄴ과 ㅇ에 대한 표현 규칙을 일일이 등록해 줘야 하는 번거로운 문제가 여전히 남아 있었다.

이번 버전에서는 그 문제까지 싹 해결했다.
'고급 입력기'를 문자 생성기로 사용하고 '초· 종성 공유 낱자 결합' 옵션이 지정된 상태에서
종성 A+B=C에 해당하는 C라는 종성을 조합하는 상태가 됐고, C는 물리적으로 표현 가능한 낱자의 범위를 초과하는 값이고
C에 대해 다른 가상 낱자나 낱자 치환 규칙이 존재하지 않는다면...

이 복잡한 조건을 모두 만족할 경우 <날개셋> 한글 입력기는 자체적으로 C를 종성 A와 다음 글자 초성 B로 풀어서 표현해 준다.
그래서 당장 천지인, 나랏글 같은 예제 입력 방식에서도 300 이후의 수십 개의 종성 결합이 존재하지만 그에 대한 가상 낱자와 낱자 치환 규칙은 이제부터 삭제되었다. 이제 그런 추상적인 낱자는 낱자 결합 규칙에다가 한 번만 지정해 주면 되니, 휴대전화 입력 방식을 구현하기가 더욱 수월해졌다.

4. 수식 변수에 대소문자 구분 추가

예전에도 한번.. <날개셋> 한글 입력기의 글쇠 수식에서 변수의 용도 구분과 공간 부족이 앞으로 문제가 될 수 있다고 언급한 적이 있었다. 이 문제를 간단한 방법으로 깔끔하게, 완전히 해결했다. 변수는 여전히 알파벳 한 글자이긴 한데, 여기에다가 대소문자 구분을 추가함으로써 지원되는 변수의 개수를 종전의 두 배로 늘린 것이다.

그리고 이 프로그램이 버전업되어 입력 스키마 차원에서 여러 변수들이 추가로 제공되더라도, 프로그램은 언제나 오로지 대문자 변수만을 사용한다. 소문자 변수 26개는 사용자가 자신만의 내부 상태를 구현하는 용도로 얼마든지 사용하면 된다. 대소문자이니 형태를 구분하기도 아주 쉽다. 수식을 입력할 일이 있을 때 대소문자 상태만 좀 조심하면 된다.

고유한 내부 상태를 사용하는 복벌식 입력기 플러그 인은 글쇠배열에서 Q 대신 q 변수를 사용해서 수식을 생성하도록 수정되었다.

※ 동기화 관련

5. 타입간에 입력 설정 자료 보존

<날개셋> 한글 입력기의 오랜 숙원이 이뤄졌다.
빠른설정이나 예제 파일을 통해서 '기본 입력 스키마'와 '기본 입력기' 방식으로 어떤 입력 설정이 구축되었는데, 이것을 그대로 '고급 입력 스키마'와 '고급 입력기'에다 가져올 수는 없을까?

입력 항목의 기반 루틴을 넘나들면서 입력 설정을 가져오는 것은 지금 체계에서는 일반적으로 가능하지 않았다. 그래서 편법으로 입력 항목을 XML 방식으로 저장한 뒤, 텍스트 에디터로 object를 수동으로 고쳐서 다시 불러오는 것밖에 방법이 없었다. (어차피 기본이든 고급이든.. 공통 설정은 공통된 XML 형태로 저장을 하기 때문에 가능한 일)

이제는 사용자가 원한다면 이 일을 프로그램이 직접 해 준다.
입력 스키마나 문자 생성기를 변경하고 나면 '초기화' 버튼의 메뉴에 '예전 설정 가져오기'라는 명령이 사용 가능해진다. 그리고 이것을 선택하면 변경 전에 사용하던 입력 스키마/문자 생성기가 갖고 있던 설정을 지금의 입력 스키마/문자 생성기에다가 적용을 하게 된다.

앞으로 고급 입력 스키마와 고급 입력기가 많이 쓰이게 될 텐데 이것은 꼭 필요한 기능으로 자리잡을 듯하다.
당연히, 고급에서 쓰이던 설정을 기본으로 가져오는 것도 가능하다. 기본이 지원하지 않는 기능에 대한 설정치들은 물론 소실된다.

6. 처음에 무조건 지금 default로 지정되어 있는 입력 항목으로 구동

지금까지 외부 모듈의 '고급 시스템 옵션'에는 TSF 지원 확장 하나밖에 옵션이 없었는데, 다음 버전에서는 옵션이 두 개가 더 추가되었다. 하나는 위의 기능인데, 이것은 유용하다면 굉장히 유용한 옵션이다.

Windows 운영체제는 프로그램들의 GUI에 내부적으로 한영 상태를 관리하고 있다. 외부 모듈들은 그 상태를 따라 동작하며, 자신의 상태와 운영체제의 상태 중 어느 하나가 바뀌면 다른 한쪽도 알아서 동기화를 해야 한다. <날개셋> 한글 입력기 역시 외부 모듈 구현체는 그런 규격을 따르며 동작한다.
이런 공통 프로토콜이 스펙에 규정되어 있기 때문에 응용 프로그램은 자신이 지금 무슨 IME를 사용하고 있든지간에 소프트웨어적으로 한/영 상태 정도는 강제로 바꾸는 게 가능하다.

그런데 <날개셋> 한글 입력기 외부 모듈은 사용자가 직접 글자판을 강제로 전환하지 않았다면 자기가 먼저 운영체제의 상태는 절대로 바꾸지 않는.. 일종의 read-only 전략으로 개발되었다. 이것은 MS 한글 IME도 동일하게 따르는 정책이다.

그래서 입력 설정상으로 한글 글자판이 지정돼 있더라도 그 내부 상태가 영문이라면 <날개셋>도 자기 설정을 무시하고 빈 입력 스키마 계열을 기본으로 선택하며, 그런 게 없으면 자동으로 추가도 했다. 이런 동작 방식을 이상하다고 지금까지 사용자들로부터 문의도 엄청 많이 받았다.

하지만 "안 되면 되게 하라" 정신으로.. 이 옵션을 켜 주면 외부 모듈도 편집기처럼 무조건 설정대로 동작하며, 운영체제의 상태를 자신의 상태에다 강제로 맞춰 버린다. 프로그램이 실행되자마자 영문이 아닌 한글 모드에서 시작하는 것도 이제 가능하다. 운영체제의 여타 외국어 IME/글쇠배열을 <날개셋> 한글 입력기와 병행해서 쓰는 것도 좀 더 수월해질 것이다.

7. 응용 프로그램간에 <날개셋> 한글 입력기의 활성 입력 항목 동기화

Windows 8부터는 응용 프로그램간에 사용하는 키보드 로케일/IME와 내부 한영 상태가 모조리 자동 동기화되는 옵션이 추가되었으며 이 방식이 기본으로 지정되어 있다. 하지만 운영체제가 동기화해 주는 것은 한글 아니면 영문이라는 이분법적인 논리값인 반면, <날개셋> 한글 입력기는 3개 이상의 임의의 개수의 입력 항목을 가질 수 있다. '한글'이라고 분류되는 입력 방식 중에 세벌식, 두벌식, 드보락 같은 것은 여전히 응용 프로그램별로 따로 놀며, 동기화되지 않는다.

이 옵션을 켜면 <날개셋> 한글 입력기는 프로그램간에 자기가 사용하는 구체적인 입력 항목의 번호까지 동기화해 준다. 즉, 한 프로그램에서 입력 항목을 다른 걸로 전환하고 다른 프로그램으로 이동하면, 그쪽에서도 그걸로 동기화가 된다.
이 기능은 완전 만능 동기화 기능은 아니고 운영체제의 내부 상태가 맞아야만 동작하는 등 이것저것 단서와 제약이 있긴 하지만(도움말에 명시되어 있음), <날개셋> 한글 입력기를 Windows 8 스타일에 맞춰서 좀 더 매끄럽게 사용하는 데 큰 도움을 줄 것이다.

※ 기타 다른 개선

8. 버그 수정

Windows 8.1에서 권한 부족한 Metro 앱을 사용할 때, 단어 단위 한자 변환이 되지 않던 문제를 해결했다. 지난 7.4 버전에서 추가되었던 사용자 한자어 사전 연계 기능에 문제가 있음을 뒤늦게 발견했다.
권한 부족한 Metro 앱에서 동작이 실패할 때에 대한 처리를 해야 했는데 그걸 하지 않아서 내부적으로 프로그램이 죽었다가 다시 구동되곤 했다. 이런 실행 모드에서는 화면에 로그조차도 제대로 찍히지 않아서 디버깅을 상당히 특수한 방식으로 힘들게 해야 했다.

조금 더 심각한 문제로는 텍스트 조작을 온전하게 할 수 없는 TSF B급 프로그램에서 지금 글자 앞으로 이동하는 부류의 특수글쇠를 사용했을 때 단순히 거절만 되는 게 아니라 프로그램 전체가 무한 루프에 빠지는 문제가 있어서 이를 해결했다. 이 부분의 로직이 크게 바뀐 바로 직전 7.5에만 있던 문제이다.

그리고 편집기에 있는 '키 입력으로 붙여넣기' 기능이 언젠가 space를 제대로 처리하지 못해서 조합 중이던 한글이 덧난 채 붙여지던 문제를 해결했다. 이 역시 아마 이 부분 로직이 크게 바뀌었던 7.4때부터 생긴 버그가 아닌가 싶다.
Windows 7은 콘솔에서 세벌식을 사용할 때 '다다.' 이런 식으로 글자가 덧나는 문제가 있었는데 그런 것과 기술적으로 비슷한 문제이다.

이에 덧붙여 편집기의 '현재 편집 중인 문서의 경로 복사' 기능이 언제부턴가 텍스트를 클립보드에다 제대로 저장하지 않고 있던 문제, 그리고 아무 문자를 입력하지 않을 때에도 겹침 모드에서는 뒷글자를 무조건 하나씩 지우던 사소한 문제도 해결했다. 이것도 아마 7.4~7.5 사이에 슬며시 들어간 버그가 아니었나 싶다.

9. 제어판에서 설정 파일을 초기에 저장하는 위치

날개셋 제어판에서 글쇠배열, 유형, 전체 설정 등.. 뭔가 파일로 설정 데이터를 열 때는 처음엔 예제 데이터가 있는 디렉터리가 시작 위치로 표시된다. 그러다가 파일을 한번 저장하고 나면 마지막으로 저장했던 파일이 있는 디렉터리가 열 때에도 그대로 표시된다.

그런데, 최초로 저장을 할 때는 지금까지 기본 입력 설정 파일이 저장되는 생뚱맞은 이상한 디렉터리가 표시되곤 했다. 이것을 개선하여 이제는 사용자에게 친근한 '내 문서' 디렉터리가 표시되게 바꿨다. 지금까지 이게 상당히 불편한 점이었을 것 같다.
단, 전체 설정(set)은 제공되는 예제 데이터가 없기 때문에 저장뿐만 아니라 '열기'를 처음 할 때도 '내 문서'에서 시작한다.

10. 사용자 정의 후보 관련

7.0에서 첫 도입되었던 사용자 정의 후보 관련 기능에도 엔진이나 GUI에 이것저것 개선이 있었다.
(1) 외부 후보 파일을 불러왔을 때 설명문이 space 이후가 몽땅 잘려서 출력되던 어이없는 버그가 이제야 발견되어 고쳤다. (신고해 주신 분께 감사~)

(2) 그리고 후보 데이터를 추가하는 버튼을 Ctrl을 누르고 클릭하면... 후보 데이터를 한 덩어리로 등록하는 게 아니라 각 글자 단위로 독립적으로 한꺼번에 등록하는 기능을 추가했다. 즉, "☆★○●◎"이라고 입력하고 Ctrl+클릭을 하면 ☆, ★, ○, ●, ◎ 라고 5개의 후보 문자들이 떼어져서 등록되는 것이다.

(3) 이 외에도, 호환용 한글 자모 하나를 사용자 정의 후보의 key값으로 등록해 놓으면, 유니코드 표준 자모로도 그 key에 접근할 수 있게 했다.
초성 자음 중에 ㅉ은 한자 키 특수문자 변환이 전혀 존재하지 않는 유일한 낱자이다. 그리고 모음이나 종성 겹받침도 자리가 비어 있다. 그렇기 때문에 이런 자리에다가 사용자가 자주 사용하는 상용구나 특수문자를 제2 후보에 내장형으로든 외장형으로든 등록해 놓고, "한자 1 + 오름차순 포워딩" 또는 "한자 2 + 내림차순 포워딩"을 쓰면 기존 한자 변환과 내 custom 변환을 손쉽게 같이 쓸 수 있다.
물론, 낱자뿐만 아니라 한자 독음이 없는 한글, 가령 '바'나 '카' 같은 것도 유용하게 활용할 수 있다.

11. 사용자의 건의를 반영한 GUI 개선 추가분

제어판 대화상자가 대화상자 자체의 크기뿐만 아니라 좌우(분야 vs 각 항목)의 내부 크기 조절도 드디어 가능해졌다.
단, 좌우의 폭은 양쪽 모두 지금보다 키우는 것만 가능하지, 줄이는 것은 가능하지 않다.
좌우의 크기 조절이 가능하려면 먼저 대화상자의 폭부터 더 키워야 한다.

많은 사용자들의 요청에 힘입어, 글쇠배열 수식 대화상자도 가로로 크기 조절이 가능해졌다. 생각보다 길고 복잡한 수식을 고안해서 사용하는 분들이 많은 줄을 이제야 알았다. ㅎㅎ
3.0 버전 이래로 거의 10년간 S, P, N, L 등 알아보기 어렵게 돼 있던 인접글쇠 버튼들 역시 저렇게 깔끔하게 바꿨다.

12. 설명문 추가

<날개셋> 한글 입력기에서 XML 저장이 가능한 단위인 글쇠배열, 입력 항목(유형 ist), 전체 입력 설정(set)에 대해서..
자신만의 고유한 설명문을 집어넣는 기능을 추가했다. 그리고 옵션을 줄 경우, 사용자가 제어판에서 해당 파일을 불러왔을 때 그 설명문을 반드시 먼저 사용자에게 표시하게 할 수 있다.

이 입력 방식은 언제 누가 만들었고 버전과 저작권이 어떻게 되며 제작자와 연락은 어떻게 하는지 등의 정보를 설명문에다 간단히 기재해 넣을 수 있다.
또한 복잡한 글쇠배열의 수식 로직 해설을 메모해 두는 용도로도 쓸 수 있으니 여러 모로 유용하다.

Posted by 사무엘

나 같은 컴퓨터쟁이 코더에게는 '통역(사)'라고 하면 컴파일러의 반의어인 인터프리터가 바로 떠오르는 동시에, 니콜 키드먼이 통역사로 연기하는 10년 전쯤의 영화 인터프리터도 생각난다.

성경에서는 단순히 풀이/해석 말고 진짜 외국어 통역을 뜻하는 interpret은 창세기에서 이집트 총리가 된 요셉과 자기 형들 사이의 대화, 그리고 저 멀리 신약 성경에서.. 통역해 주는 사람이 없으면 외국어 방언 쓰지 말고 “그 입 다물라”라고 권면한 것 정도가 등장한다.
아울러 우리 교회의 담임목사님이 통번역 대학원 출신의 스페인어 박사급 전문가이시다. 그래서 왕년에 대학 강단에 서기도 하고 국가적으로 꽤나 높으신 분들 행사의 통역에 동원된 경력이 있으며, 관련 국가고시 문제 출제에도 참여한 적이 있으시다.

통역은.. 문자 언어를 비교적 충분한 시간 동안 고퀄리티로 옮기는 '번역'과는 다소 다른 개념이다. 오프라인 렌더링과 실시간 렌더링의 차이랄까..
그런데 통역도 방식이 크게 두 갈래로 나뉜다. 화자 먼저 한 문장을 말하고서 쉬는 동안 통역이 말하는 '순차통역'은 그나마 양반이다. 그 반면, 듣는 사람은 헤드폰을 끼고 있고 화자는 쉬지 않고 계속 말하는 걸 통역사가 딴 장소에서 부랴부랴 옮기는 '동시통역'이 있다.

당연히 동시통역이 훨씬 더 정신없고 어려우며 보수가 더 높다.
게다가 순차인 경우, 화자는 바로 옆에 있는 통역사를 의식해서 더 또박또박 천천히 말을 하는 편이며, 통역사 역시 잘 못 알아들으면 화자에게 “뭐라고요?” 이럴 기회라도 있는 반면..
동시통역의 경우 화자와 통역사는 격리되어 있으며, 화자는 통역사의 존재를 전혀 의식하지 않고 진짜 자비심 없이 자기 할 말만을 쏟아내기 때문이다.

영화 인터프리터에 나오는 것처럼 UN 회의를 동시통역하는 정도이면.. 난이도와 중요도가 정말 톱 중의 톱이며, 그야말로 최고의 정예 통역사가 최고의 보수를 받으며 일한다고 봐야 할 것이다. 물론 그 대신, 오역 때문에 무슨 국가적으로 중대한 일이 틀어지기라도 했다가는 사고를 낸 통역사는 교도소에 갈 각오도 해야 할 것이고.
단순 관광 가이드 통역 수준이 아니라, 각종 전문 분야 설교나 연설의 동시통역을 하려면 양 외국어 자체만 기똥차게 잘한다고 되는 게 아니며, 통역 이론과 방법론에 대한 추가적인 학습이 필요하다고 한다.

우리나라는 군대도 미군과의 의존성이 높다는 특성상 어학병이라는 보직이 존재한다. 물론, 날고 기는 영어 귀재들에 비해 TO는 바늘 구멍 수준이지만 말이다. 카투사야 어느 정도 이상의 공인 영어 점수만 받고 나면 그 뒤부터는 추첨이지만, 어학병이 되려면 정말로 토익 정도는 만점에 가깝게 나와야 하며, 겨우 본토에서 머리로만 주입한 수준을 초월하는 영어 실력이 필요하다. 그래도 통역을 해도 순차이지, 일개 군인이 설마 동시통역까지 맡을 일은 없을 것이다.

얼마 전에 박 근혜 대통령이 미국 의회에서 영어로 연설을 할 때 방송사들은 한국인이 구사한 영어를 동시통역해서 연설 내용을 생방송으로 내보냈었다.
아, 그나저나 먼 옛날엔 국내 방송사에서 아침 7시 뉴스를 하기 전에 '세계 뉴스'라고 해서 CNN, NHK 등 주요 외신의 하이라이트 한 토막을 자막 내지 더빙으로 내보낸 적이 있었다. 생방송은 아닐 테니 동시통역까지는 아니었을 테고. 인터넷으로 어중이떠중이 다 세계 뉴스에 접근이 가능해진 오늘날 다시 생각해 보면 정말 아련한 추억이다.

어쨌거나 외국어 잘하는 사람이 참 부럽다.

Posted by 사무엘

1. 오목은 선수(흑돌)가 굉장히 유리한 반면, 윷놀이는 잡히는 것 때문에 선수가 그다지 유리하지 않다는 게 굉장히 흥미로운 차이점이다.
특히 보드에 처음 놓이는 말이 기존 말을 잡는 거는.. FPS로 치면 개념적으로 spawn으로 인한 텔레프래깅과 동일하다.

2. 윷놀이는 자동차가 발명되기 한참 전에 고안된 게임이겠지만 말의 주행 패턴이 자동차 수동변속기와 굉장히 닮은 것 같다.
도-개-걸-윷-모는 1~5단, 빽도는 후진 1단

3. '지옥'은 윷놀이의 랜덤함과 사행성을 더욱 배가시켜 놓은 요소임이 틀림없다.

4. 옛날에.. 한 1992~94년 사이이던가..? 어떤 은행원 아저씨가 윈도 3.1용으로 윷놀이 게임을 만든 게 있어서 했던 기억이 있다. 아마추어 프로그래머일 텐데 파일 구성상으로는 비주얼 베이직은 아니고.. 나름 쌩 Windows API를 써서 C언어로 만들었지 싶다.
나름 자기 아들이 윷을 던지는 동영상까지 들어있었는데.. 그 시절에 그런 개발 환경과 동영상 촬영 장비를 생각하자면 보통 집안은 아니었던 것 같다.

5. 프로그래머의 관점에서 생각해 보자면, 윷놀이 컴터 AI를 만드는 거 생각보다 재미있을 듯하다. 일단 윷말 놓는 방식이 가짓수가 굉장히 많으며, 굽는 것, 다음에 잡힐 확률, 그리고 각 말이 빽도가 걸렸을 때 후진하는 방향 state 같은 것들도 은근히 처리하기 까다롭기 때문이다.
5m + 4n + 3 = 10 or 12 이런 거 어쩌면 선형계획법으로 모델링할 수 있을지도 모른다.
다변수 정수 연립방정식 푸는 건 지뢰찾기를 풀 때도 써먹곤 했는데 어쩌면 그것과 비슷한 논리인지도..;;

* 펜티엄 4 + 윈도 XP 초 구닥다리 똥컴에서는.. 페이스북처럼 자바스크립트가 왕창 돌아가는 페이지는 IE8로는 먹통 수준으로 너무 느려서 도저히 열람을 할 수가 없고..
역시 크롬이 정답이다.

Posted by 사무엘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘

오늘은 원래는 있었는데 국토 분단으로 인해 기능이 상실되고, 게다가 6· 25 때 흔적도 없이 사라져서 터만 남은 비운의 철도역을 심층 탐방해 보겠다. 오오오~ 흥미진진 두근두근~!
얘들은 황량한 부지만 달랑 있고 건물 실체가 없는 관계로, 주소도 도로명 주소 같은 게 없이 여전히 지번 기반이다. 이름도 '역'이 아니라 그냥 '역지'이다. 황룡사가 아니라 황룡사지인 것처럼 말이다.

1. 경의선 장단 역

장단 역은 원래는 1906년 4월에 경의선이 개통했던 당시부터 영업을 시작한 창립 멤버이다. 그때는 같은 창립 멤버인 문산 역의 바로 다음이 장단이었다. 지금 문산 이북에 있는 운천, 임진강, 도라산 같은 역은 먼 훗날 이뤄진 남북 경의선 철도 연결 작업의 산물이다. (더구나 운천은 그저 임시승강장일 뿐이고.)

장단 역이 유명해진 건 잘 알다시피 인근 선로에 반세기 동안 버려져 있던 녹슨 증기 기관차 때문이다.
1950년 12월 31일, 고 한 준기 기관사는 평양 방면으로 화물 열차를 운전하고 있었는데, 그 때는 중공군의 인해 전술로 인해 국군과 UN군은 후퇴 중이었다(서울을 북한군에게 도로 빼앗긴 1· 4 후퇴의 불과 닷새 전이었다). 그래서 이 열차는 더는 북상할 수가 없게 되었으며, 장단 역에는 전차대 같은 게 없어서 진행 중인 열차의 방향을 남쪽으로 돌릴 수도 없었다.

결국 이 열차는 북한군에게 노획되는 걸 방지하기 위해 차라리 동작 불능 상태로 파괴 대상이 되었다. 이에 명령을 받은 미군 병사들은 소총을 난사하여 기관차를 벌집으로 만들고 또 탈선까지 시켰다. 한씨는 다른 하행 열차를 갈아타고 후퇴했다. 김 재현 기관사 때처럼 열차가 무슨 북한군의 공격을 받아서 벌집이 된 건 아니다.

그렇게 긴급 상황에서 버려진 증기 기관차 화통은 2005년에 임진각으로 옮겨졌고, 녹을 벗겨내는 대공사를 거쳐서 2009년부터 임진각에 전시되고 있다. 하지만 그 난리 중에 장단 역 자체는 완전히 파괴되어 흔적도 없이 사라졌다.
위치 자체도 38선, 지금의 군사 분계선과도 너무 가까운지라 복원이나 관광지 조성 같은 건 요원하다. 민통선도 아닌 완전 비무장지대에 있으니 말이다.

장단역지의 공식 주소는 “경기도 파주시 장단면 동장리 198”이다. 지도 사이트에서 주소를 입력하면 위치가 정확하게 나온다. 도라산리도 아니고 동장리이기 때문에 도라산 역에서 1km가 넘게 북쪽으로 멀찌기 떨어져 있고, 군사 분계선이 몇백 m 코앞이다.
이 일대의 항공 사진을 보면 4차선 도로의 옆으로 경의선 단선 철길이 지나고, 주변은 온통 숲이다.
예전에 기관차가 임진각으로 옮겨지기 전에 시뻘겋게 녹슨 채 내팽개쳐져 있던 시절의 사진을 보면.. 여기 어딘가의 경의선 선로 옆에 나란히 있었던 것 같다.

남북 분단 전의 리즈 시절엔 장단 역은 제법 컸다고 그러는데 지금 저 지형을 봐서는 도저히 믿어지지 않는다. 또한 '죽음의 다리'라고 불리는 교량이 장단 역 남단 300m쯤에 지금도 있다고 하는데 항공 사진으로는 짐작을 못 하겠다.

2. 경원선 철원 역 외

철원은 남북 분단 이전에는 지금의 춘천에 맞먹는 큰 도시였으며, 철원 역도 무려 1912년에 개통한 경원선의 창립 멤버역으로서 대단히 중요한 교통 요지였다. 게다가 금강산선의 분기역이기까지 했으니 역의 덩치도 당시의 경성 역만큼이나 컸다고 한다.
철원 역 일대는 분단 직후에는 북한 치하에 있다가 6· 25가 발발하면서 건물과 시설이 모조리 초토화되었다. 그러나 이 지역은 대한민국이 수복한 후, 다행히 터와 최소한의 흔적은 건졌다. 위치도 DMZ는 아닌 단순 민통선 내부인지라 개인이 그럭저럭 찾아가서 답사하는 것도 가능하다.

안보 패키지 관광을 이용해서 이 지역을 방문하면, 철원 역은 아무래도 건물 실체가 짝퉁 형태로라도 남아 있는 월정리 역보다는 비중 있게 다뤄지지 않는다. 관광버스가 정차하지도 않고 가이드가 그냥 차창 밖으로 “여기가 철원 역 부지입니다”라고 설명하는 걸로 넘어간다.

그렇기 때문에 여기를 직접 땅밟기를 하고 살펴보고 싶으면 평일에 개인이 자가용을 끌고 민통선 안으로 들어가 봐야 한다. 물론 사전에 군부대에 연락해서 허가를 받고서 말이다. 다른 방문자의 경험담을 보자면, 원래부터 그 지대의 출입증을 갖고 있는 지역 주민으로부터 초대를 받고 같이 들어가는 게 아닌 경우(외지인의 단독 방문), 감시하는 군인이 동승· 동행을 한다고 그런다.

"사람이 가득하던 도시가 어찌 외로이 앉았는가! ..." (애 1:1)
성경의 이 애가(lamentation) 구절이 철원역지를 보면 저절로 읊어질 것 같다.
경원선은 경의선과는 달리 남북이 연결되지 않았다. 그러니 지도를 펴 놓고 옛 철길 궤적을 한번 추적해 보도록 하자.

이 그림 한 장으로 모든 게 설명된다.
좌측 최하단의 '묘장로' 인근에 있는 붉은 점은 바로 지금의 경원선 종점인 백마고지 역이다.
그리고 근처의 오른쪽 위에 있는 점은 옛 철원 역으로, 지금은 민통선 안에 빈 터만 남아 있다.
더 위로 들판과 산지의 경계에 있는 붉은 점은 월정리 역이다.

지도에 표시되어 있는 남한 쪽의 논밭 들판들은 거의 다 민통선 내부라고 생각하면 정확하다.
단, 월정리 역은 원래는 민통선 지대를 넘어 더 북쪽의 DMZ 내부에까지 걸쳐 있었으나 좀 덜 위험한 곳으로 살짝 옮겨져서 복원된 것이다.
그리고 철원 역도 지금은 국도 3호선에 딱 붙은 지점에 복원되었지만 원래 있던 곳은 그보다는 좀 더 떨어져 있었다.

그리고 북한으로 넘어가서 홀로 덩그러니 남아 있는 붉은 점이 바로 가곡 역으로 추정되는 지점이다. 북한의 월정리 역에 해당하는 버려진 역이다! 선로는 없고 역사 흔적만 있다.
다음으로 '평강군'에 걸쳐 있는 점은 평강 역으로, 오늘날 경원선의 북한 구간은 여기서부터 시작된다. 북한에서는 자기 구간을 강원선이라고 부른다.

우리나라 쪽에 있는 푸른 점은 철원에서 금강산선의 궤적이 남아 있는 곳이다. 각각 한다리, 대위교, 그리고 전선 휴게소 인근에 있는 교각이다. 위의 자료가 정확하다면, 철원 역에서 분기한 금강산선은 남쪽으로 좀 내려간 뒤에 동쪽을 향해 간다는 걸 알 수 있다.

끝으로, 군사 분계선 인근의 분홍색 점은 제2 땅굴 입구가 있는 지점인데 참고로 첨가해 넣었다.

위의 점들이 다 철길로 연결되는 날이 온다면 얼마나 아름답고 행복할까?
본인은 경주 출신임에도 불구하고 황룡사지보다도 철원역지, 장단역지 같은 이름을 들었을 때 더욱 가슴이 뭉클하고 뭔가 울컥함을 느낀다. 분단된 철도의 아픔은 곧 나의 아픔이기에.

미국의 로스엔젤레스는 잘 알다시피 '천사의 도시'라는 뜻이고, 이스라엘의 수도 예루살렘은 '평화의 도시'라는 뜻이다. 그런데 평화와는 별 관계가 없는 짓을 하는 북한 같은 또라이 반국가단체가 '평강, 평양' 등 '평'자가 들어간 지명을 갖고 있다는 건 참 역설적인 것 같다. 북한은 자기들의 악한 체제의 유지를 위해 주민들에게 절대로 자유를 주지 않으며 눈과 귀를 강제로 틀어막고 지내고 있음을 우리는 잊지 말아야겠다.

한편, 경의· 경원 라인과는 달리, 동해중부선 쪽은 일제가 한창 공사를 하다가 패망해 버렸다. 그렇기 때문에 그쪽에는 영업을 하다가 우여곡절을 겪고 파괴되고 없어진 역 같은 건 없다.

Posted by 사무엘