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

1. 총이 발명되면서 활은 전투 병기에서 완전히 은퇴하고, 레저 내지 스포츠용으로나 전락했다. 그런데 활이 총에 비해 독보적으로 갖는 장점은 바로 조용하다는 것.
이런 이유로 인해, 현대전에서도 일부 아주 특수한 임무를 수행하는 저격수는 활까지는 아니어도 석궁을 써서 요인을 암살하기도 한다고 들었다.
물론, 어지간하면 저격용 소총에다 소음기를 달겠지만, 더 조용해야 할 필요가 있을 때 말이다.

2. 증기 기관차는 동력원이 있으면서(마차나 글라이더나 돛단배와는 달리) 전기 에너지를 전혀 쓰지 않는 유일한 교통수단이다. 디젤 전기 기관차는 말할 것도 없고, 기름을 이용하는 내연 기관도 시동 걸 때는 배터리로부터 전기 플러그의 점화가 필요하지만, 증기 기관차는 진짜로 전기 안 쓴다. (그래서 EMP 공격에 전혀 영향을 받지 않는다고 한다 -_-)

3. 오늘날까지도 구닥다리 모래시계를 볼 수 있는 곳은 바로 사우나.. -_-;;
기온이 90~100도에 달하고 물로 축축하기까지 한 곳에서 시간 측정용으로 이것보다 더 좋은 물건은 없기 때문이다. ^^;;
그러고 보니 전자 기기가 무용지물인 곳에서는 쿼츠 시계가 아닌 태엽 시계를 다시 꺼내 써야 할지도 모르겠다.

4. 전기를 전혀 쓰지 않으면서 흔들림이 심한 곳에서 일관된 자형의 글씨를 쉽게 찍을 수 있는 기계는 역시 기계식 타자기밖에 없다.
하지만, “여행 중이거나 오랫동안 주거지를 떠나 있을 때든지, 기차나 배, 자동차, 전철 등 흔들리는 장소에서도 언제 어디서든 글을 찍어서 소식을 전하거나 기록을 남길 수 있습니다”는 오늘날 현실적으로 스마트폰이 그 역할을 대체하게 된 게 사실이다. ^^;;

5. 자전거는 동력원이 없고 가축의 힘을 쓰지도 않는 교통수단 중에서는 속도가 가장 빠르고 에너지 효율도 매우 좋다. 자전거와 타자기는 분야별로 차지하는 위상이 서로 비슷하면서 인류가 만든 대단히 훌륭한 발명품임이 틀림없다.

6. 우리나라에서도 '지멘스 옥타브'를 전파하면서 현역으로 활동 중인 8200호대 전기 기관차는 내부에 인텔 80386 CPU가 들어있다고 한다. 그나마 원래 스펙상으론 80286이 들어있었는데 한국 측의 요구로 로컬라이즈 과정에서 한 단계 업그레이드된 CPU가 들어갔다고. 개인용 PC에서는 10년도 더 전에 도태한 놈이지만, 이런 구닥다리들이 임베디드 환경에서는 꽤 오래 살아 있어 왔다. ATM 기기나 키오스크 같은 데서는 아직까지 윈도우 2000/NT, 심지어 윈도우 3.x 머신까지 살아 있기도 하니 말이다.

7. 80286이면 그나마 양반이다. 지금 이미 명왕성의 궤도도 넘어서 태양계의 끝에 도달했다고 알려져 있는 파이어니어 내지 보이저 탐사선은 무려 1970년대 말, 인텔 마이크로프로세서가 갓 발명되었던 시절에 발사되었으며, 여기에는 겨우 1.6MHz 램 4KB의 8비트짜리 컴퓨터가 장착되어 있었다. 2006년에 발사된 New Horizon 호에 장착된 컴퓨터와는 가히 넘사벽의 차이일 것이다.

그래도 저 옛날 컴퓨터도 지구로부터 받은 지령을 수행하고 우주에서 사진을 찍어 지구로 보내는 등 할일은 다 해 냈다. ^^;; 특히 보이저 호는 지금까지도 지구와 교신을 주고받으면서 살아 있는데, 이런 옛날 탐사선을 제어하는 것이야말로, 겨우 Y2K 문제 해결용 코볼 프로그래밍과는 비교가 안 되는 하드코어 legacy 프로그래밍의 진수일지도 모르겠다.

어차피 인간이 다루는 컴퓨터의 똑똑한 성능은 상당수가 그냥 현란한 비주얼 이펙트를 보이는 데나 쓰이고 있으며-_-, 임베디드 환경에 들어가는 컴퓨터는 닥치고 전력 소모 적고 발열 적고 우주선과 방사능에 강하고 튼튼한 놈이 짱이니까...;; 그런 곳에서는 성능보다는 신뢰성이 훨씬 더 중요하다고 하겠다.

듣자하니 목성 근처에서는 컴퓨터들을 죄다 짜부러뜨릴 강력한 방사선이 나오고 있었다고 하는데, 여기 근처를 처음으로 탐사한 파이어니어 10호가 튼튼하게 잘 버텼다고 한다.
일반 양민은 목성에 착륙 시도를 했다간, 뜨겁지만 않을 뿐이지 마치 지옥의 행성 금성에 착륙하는 것만큼이나 고압 유독가스 폭풍과 방사선으로 인해, 도착도 하기 전에 끔살..;;

물론, 태양과 지극히 먼 춥고 캄캄한 우주를 외로이 날아가는 탐사선이 이렇게까지 오래 장수할 수 있는 것은 근본적으로 인간이 태양이 아닌 근원으로부터 막대한 양의 에너지를 얻는 방법을 개발해 냈기 때문이다. 그 이름도 유명한 원자력. 이렇게 생각하니까 대단하지 않은가? 탐사선 역시 방사선 원소를 이용한 소형 발전기로부터 수십년 간 전력을 공급받고 있으며, New Horizon 호는 본격 활동을 시작하는 명왕성 근처까지 갈 때까지는 아예 최대 절전(하이버네이션) 모드로 더욱 에너지를 아끼면서 가고 있다.

8. 컴퓨터는 음식이나 악기나 심지어 자동차와도 달리, 수제· 명품 같은 소위 '장인정신' 근성이 존재하지 않는 물건이다. 그런 근성이 존재하지 않는 정도가 아니라 아예 존재할 수가 없다. 반도체· 집적 회로라는 게 애초에 사람 손으로는 도저히 만들 수 없는 넘사벽급 기계니까.
(세상에 사람 손만으로는 어설프게나마도 절대로 전혀 만들 수 없는 물건은 흔치 않다. 건물만 해도 결국 사람 손으로 만드는 것인데!)

- 장인의 손맛이 살아 있는 독일제 저전력 CPU
- 3대째 그래픽 카드만 만드는 명문 가문..
이런 게 있을 리가..;; 컴퓨터 분야에는 롤스로이스, 포르쉐, 벤츠 같은 성격의 브랜드도 없다. 닥치고 인텔, AMD, nVIDIA 같은 메이커만 존재할 뿐이다. ^^;; 단순히 역사가 짧아서 그런 전통이 없는 건 아니라는 뜻이다.

사실, 외국의 자동차 명문 브랜드는 해당 회사의 창업자 이름을 딴 게 많다. 심지어 비행기를 만드는 보잉 사도 창업자 이름을 딴 사명이니까...
하지만 컴퓨터계에서는 그런 넘사벽급 엔지니어의 이름은 간판에서는 찾을 수 없고 오히려 무어의 법칙, 황의 법칙 같은 괴랄한 법칙-_- 이름에서나 간간히 등장하는 듯하다.

컴퓨터는 인간이 수천 년간 축적한 물리, 화학, 수학 지식의 결정체요 총아이다. 정말 대단한 발명품이 아닐 수 없다. 비단 기술뿐만이 아니라 사회· 정치적으로도 충분한 배경이 마련되지 않았다면 결코 발명될 수 없었다(전쟁 같은).

그런데 전기가 맛이 갔거나 컴퓨터가 돌아갈 수 없는 곳에서는 증기 기관차, 모래 시계와 더불어 “수판”이 되살아날 가능성은 있으려나 모르겠다. ^^;;
숫자는 자연어 문자와는 달리 엔트로피가 편중됨이 없이 균일한 문자이다 보니, 빠르고 정확하게 치기가 은근히 힘들다. TV 생활의 달인 편에도 잘 나오다시피, 능숙한 수판의 달인은 일반인이 계산기 키를 다 두드리기도 전에 어지간한 사칙연산은 말끔히 해치워 버린다.

Posted by 사무엘

칠레처럼 아주 길쭉한 국가가 있다고 치자. 이 국가에는 지형을 따라 거대한 간선 철도가 놓여 있고 n개의 역이 있으며, n개의 역에 모두 정차하는 완행 열차가 일정 간격으로 다닌다.

이 설정을 좀 극단적으로 확장하여 역 수가 수백, 수천, 수만-_-개에 달한다고 가정하자. 그렇다면 급행 열차를 운행할 필요가 응당 생긴다. 2000개역쯤 떨어진 지역에 가려고 하는데 전역정차 열차를 탈 수는 없는 노릇 아닌가. 그렇게 여행 거리가 길어지면, 급행 열차가 서는 곳까지 가서 환승하는 불편 정도는 급행의 빠른 속도가 충분히 보상하고도 남게 된다.

자, 이를 일반화하면.. 급행도 등급이 필요해서 특급, 쾌특 등 n차원의 급행을 생각할 수 있게 된다. 등급이 올라갈수록, 서는 역 수가 무척 적어서 타기 힘든 대신에 일단 타기만 하면 엄청난 이동성이 보장된다. 급행과 완행은 배차 간격은 모두 동일하다고 치자.

여기서 문제가 생긴다.
각 등급의 급행 열차들은 정차역 수를 얼마로 설정하는 게 좋을까?
또한, 철도역 수 n에 대해서, 최대 몇 등급의 급행이 존재하는 게 적당할까?

n개의 역이 모두 똑같이 중요하고 이용객 수가 균일하다고 가정할 때,
어떻게 급행을 운영하는 게 승객의 평균 표정속도를 최대화하고 반대로 평균 환승 대기 시간을 최소화할 수 있을까?
선로 수는 충분하기 때문에, 완급 결합으로 인한 대피 대기 오버헤드라든가 선로 용량 걱정은 할 필요 없다고 가정하겠다. ^^

역 수가 10개 남짓이라면 급행이 있을 필요가 없겠지만, 역 수가 100개쯤 된다면 3~4개역을 건너뛰는 1차 급행에 이어서 한 10~12개쯤 역을 쉬엄쉬엄 건너뛰는 2차 급행이 있어도 좋을 것 같다.

전산학을 전공한 친구라면, 이런 부류의 문제를 생각하면서 비슷한 형태의 아주 유명한 알고리즘을 하나 떠올리게 될 것이다.
바로 '쉘 정렬'이다!

쉘 정렬은 삽입 정렬을 원소별로 띄엄띄엄 적용하되 나중에 그 간격을 촘촘히 좁히는 방식이다.
삽입 정렬은 시간 복잡도가 O(n^2)이지만, n의 크기가 작아서 띄엄띄엄일 때는 오버헤드가 크지 않으며, 또 편차가 커서 리스트가 상당수 정렬되어 있을 때는 매우 빠르게 수행되기 때문에 그 특성을 이용한 것이다.
쉘 정렬은 알고리즘의 특성상 실제로 코딩해 보면 루프가 3중, 4중으로 들어가기 때문에 무거울 것 같지만 돌려 보면 성능이 매우 좋다. 프로그래밍 언어라고는 아직 어셈블리밖에 없던 1950년대에 고안된 알고리즘이다.

여타 정렬 알고리즘들이 O(n^2), O(n log n) 아니면 심지어 O(n) 같은 식으로 시간 복잡도가 딱 파악되는 반면, 이 쉘 정렬은 비록 O(n^2)보다야 훨씬 빠르긴 하지만 시간 복잡도가 제대로 분석되어 있지 않다.
삽입 간격을 설정해서 좁히는 방식을 어떻게 설정하냐에 따라서 성능이 크게 달라지기 때문이다.

완행 다음으로 급행을 겨우 1역 균일 통과, 특급을 2역 균일 통과처럼 정말 무식하기 짝이 없게 운행하지는 않는다. 급행 등급이 하나 올라갈 때마다 급행은 최소한 기하급수적으로 통과역 수가 늘어야 이치에 맞다.
쉘 정렬도 그와 마찬가지이다. 23, 10, 4, 1 같은 급으로 큼직하게 수가 바뀌고, 이 수들이 가능한 한 서로소가 되게 하는 게 정렬 효율에 좋다고 알려져 있다. 16, 8, 4, 2, 1처럼 정확하게 컴퓨터스럽게 배수· 약수 관계로 포개지는 간격은 매우 비효율적이며, 그런 나쁜 수열을 쓰면 쉘 정렬의 시간 복잡도가 최악의 경우 도로 O(n^2)로 치솟는다고 한다.

우리나라의 급행 전철이 정차역 수가 여전히 너무 많다는 지적이 있긴 하지만, 이것은 환승을 싫어하는 국민 정서 내지 환승이 불편한 구조, 급행도 어차피 최대 속도는 동일하고 완행보다 그렇게 많이 빠르지 않은 것, 역마다 weight가 현실적으로 차이가 나는 것, 급행의 소극적인 운행(긴 배차 간격) 같은 다른 환경적인 요인 때문에 그런 것이다. (현실에서는 환승역이냐 그렇지 않느냐의 여부 하나만으로도 역별 weight가 크게 벌어질 수밖에 없다)

이상, 철도와 전산학을 융합한 뻘글이었다.
쉘 정렬의 수열 설정 방식이 철도 운영에서도 이론상 효율적이라 말할 수 있을까? ^^;; (급행은 4역씩 건너뛰고 특급은 10개역, 쾌특은 23개역.. ㄲㄲ)
참고로 쉘 정렬은 수열을 제일 잘 설정했을 때 시간 복잡도가 O(n (log n)^2) 까지는 떨어진다고 한다.


* 덧붙이는 말:
어제는 KTX 열차가 개통 사상 처음으로 탈선 사고를 일으켰다고 한다.
여기에 대해 철도 덕후 사무엘 님의 공식 입장을 말하자면, 이건 두말 할 나위도 없이 선로 시설 문제이지 차량 문제가 아니라는 것이다.
차량이 떼제베가 아닌 산천이었다고 하는데, 지금까지 늘 말썽을 일으켜 온 것처럼 차량이 고장을 일으킨 거라면, 그대로 차가 멈춰서는 걸로 끝나지 지가 무슨 능력으로 탈선까지 하겠는가?

더구나 이 차는 보기 드문 광명 시종착 KTX였다. 광명이 단순 경유역이 아닌 종착역이기 때문에 여타 열차와는 다른 선로로 건너가야만 했다. 그래서 선로 분기기가 열차를 새 선로로 유도하고 있었는데, 열차가 다 건너기 전에 선로 분기기가 전산 착오 내지 추위로 인해 오작동한 것 같다. 그래서 뒷부분 객차의 진로를 막았고, 이것 때문에 찌이이이익 소음+타는 냄새+탈선이 야기된 것으로 추정된다.

열차가 고속으로 쌩쌩 달리다가 교량이 붕괴했다거나 차량이 자폭이라도 한 것과는 전혀 다른 부류의 사고이다. 오히려 열차는 종착역 진입을 앞두고 위와 같은 이유로 인해서 아주 천천히 달리면서 신호를 기다리고 있는 상태였을 것이다. 그리고 그 사고도 그런 특수한 상황에서나 발생한 사고이다. 이 사고가 KTX 차량 시스템 전반에 대한 불신풍조로 이어지기는 않기를 본인은 바란다.

이 사고로 인해 이 열차를 바로 뒤따라오던 상행 KTX는 평택쯤에서 다시 천안아산-_- 역으로 역주행하여 돌아가야만 했고, 대전-서울 구간의 고속선이 폐쇄되는 바람에 다른 KTX들은 아예 경부선 기존선으로 우회해서 다녀야 했다. 주말 임시 열차는 아예 선로 용량 부족으로 인해 운행 중단. 코레일의 입장에서는 손해가 그야말로 막심했을 것이다. 이로 인해 수원-천안 구간에서 KTX 산천이 보이는 진풍경이 연출되기도 했다.

Posted by 사무엘

별개의 분야 이야기들이 또 한데 컬렉션 형태가 됐다.

1. Personalization of Windows

이건 아무나 쉽게 할 만한 건 아니지만, 아마 윈도우 파워 유저들은 한번쯤 시도해 봤지 싶다.

콘솔(명령창)의 글꼴 바꾸기
솔직히 나도 Terminal 기본 서체는 이제 지긋지긋해서.. 똥 묻은 파르페 다음으로 싫다.. -_- 과거 윈 9x는 도스 프롬프트의 코드 페이지를 영문 437로 바꾸면 Courier New나 Lucida Console이라도 나와서 괜찮았으나, 2000/XP의 콘솔 글꼴은 너무 단조롭기 그지없다.
특정 레지스트리 부위에다 00이라는 키를 추가해서 원하는 글꼴을 지정한 뒤 재부팅을 하면 된다고 하는데, 난 여러 사이트들에서 시키는 대로 해도 안 되더라...;; 잘 모르겠다.

XP의 경우, uxtheme 패치
자세한 배경 설명은 생략하고. 요지는.. XP의 트레이드마크라고 할 수 있는 Luna 테마 대신 다른 시각 테마를 쓰는 것이다. 그런데 테마를 바꾼다는 건 단순히 색깔이나 이미지 같은 데이터뿐만이 아니라 각종 화면 요소를 그리는 실행 코드 자체를 바꾸는 것이기 때문에, 운영체제의 안정성 및 보안에 영향을 끼칠 수 있다. 그래서 운영체제는 기본적으로 디지털 서명이 존재하는 테마만 고를 수 있게 돼 있다.
그러나, 개인 테마 제작자가 일일이 자기 작품에 대해서 $를 지불하고 번거롭게 디지털 서명 인증을 받는 건 쉽지 않은 노릇이고.. 결국 디지털 서명이 없는 테마도 지정 가능하게 아예 운영체제 자체를 크랙하는 테크닉이 나돌게 됐다. 아이폰으로 치면 탈옥 정도 되겠다.

난 XP의 파란 Luna가 예뻐서 거기에다 custom 글꼴 & 그림만 붙여서 잘 썼다. 테마를 바꿀 필요는 느끼지 않는다. 비스타로 갈아탄 지 3년이 넘었지만 여전히 XP Luna가 그리울 때가 있다. 하긴, 비스타에서 Luna 커스텀 테마를 일부러 구해다 쓰는.. 흠좀무스러운 사람도 있다고는 하더라...

2. Phone number as the hyperlink

남이 내게 문자 메시지로 다른 전화번호를 알려 줬다. 이렇게, 발신자 그 자체가 아니라 본문에 포함돼 있는 전화번호를 번거롭게 암기하거나 수첩에 적지 않고 그대로 저장하거나 전화를 걸 수는 없을까?
마치 http로 시작하는 문자열이 인터넷 주소이고 "@ ." 같은 패턴이 이메일 주소이듯, 전화번호를 나타내는 정규 표현식이 통용되어 이런 건 전화기가 마치 클릭 가능한 하이퍼링크처럼 본문에다 표시해 주는 기능이 있으면 좋겠다.

자동으로 링크를 못 만든다면 최소한 번호를 마우스로 긁어서 복붙 정도는 되어야겠지.
간단하기 때문에 스마트폰에는 이미 구비되어 있는 기능일지도 모르겠다?
아래아한글 도스용에 있던 전화번호부와 팩시밀리 기능이 불현듯 떠오른다. COM 포트를 통해 컴퓨터가 모뎀으로 전화를 걸어 주던 시절이었다.. ^^;;

3. 디렉터리 생성을 좀 더 똑똑하게

컴퓨터의 파일 시스템에서 지우기 명령에 하위 디렉터리를 재귀적으로 몽땅 다 지우는 기능이 있다면,
디렉터리 생성 명령에도 중간의 다단계 디렉터리를 한꺼번에 생성하는 기능이 있어야 한다.
또한, 디렉터리를 생성한 후 바로 거기로 가는(change directory) 기능 내지 옵션도 있으면 편하지 않을까?
이건 114로 치면 전화번호를 물은 후 그 전화번호로 바로 거는 기능에 해당한다.

다단계 디렉터리를 한꺼번에 생성하는 기능은 있지만 생성한 디렉터리로 바로 가는 기능은 프로그래밍 API라든가, 각종 유틸리티 프로그램이나 명령으로도 내가 본 기억이 없는 듯하다.
요즘은 옛날에 비해 디스크/파일을 다루는 유틸리티에 대한 필요성이 훨씬 덜해지긴 했지만.. 특정 디렉터리나 드라이브로 곧바로 이동 가능하고 특정 프로그램을 단축키 하나로 바로 실행해 주고 한 화면에서 압축 파일이라든가 FTP 연동이 바로 되는 유틸리티가 있으면 컴퓨터 생활이 정말 편해진다.

토탈 커맨더, NexusFile 같은 프로그램이 유명하긴 한데 본인은 단축키가 완전히 손에 익어 버려서.. 개발이 중단된 구닥다리 WinM을 못 버리고 있다.

4. DR만 들어가면 다 박사?

DR이라는 약어가 하도 '닥터'라고 통용되니까, 과거에는 이로 인해 재미있는 오해가 발생한 컴퓨터 소프트웨어가 있었다.
MS-DOS의 경쟁자 중 하나이던 DR-DOS는 그래도 다 대문자로 쓰고 MS-DOS도 '엠에스'라고 읽다 보니, '디알'이라고 통용되었던 것 같다. MS-DOS를 설마 '미스 도스'이라고 하지는 않잖아? 도스의 모에화ㄲㄲㄲㄲㄲ 훗날 나온 노벨 도스의 전신이 DR-DOS인 줄은 모르고 있었네..;;

그러나 그래픽 소프트웨어인 '닥터할로'는 답이 없다..;; Dr. Halo라고 쓰면.. 누구에게라도 영락없이 '할로 박사님'처럼 보일 수밖에 없지 않은가. 설마 개발자가 박사 학위 소지자이기라도... 한지는 모르겠지만 Dr은 그냥 '드로잉'을 줄인 말이라고 한다.

5. 스마트폰 OS 에뮬레이터

PC에서 안드로이드 에뮬레이터가 실행되는 속도는 실제 기계에 비해서... "꽤", 훨씬 더 느리다. 난 약간 느릴 줄 알았는데 이 정도까지 차이가 날 줄은 몰랐다.

하긴, 도스박스조차 200x년대의 컴에서 같은 x86 아키텍처용 도스용 프로그램을 펜티엄급으로밖에 실행을 못 하는데, x86와 ARM은 인스트럭션 구조가 근본적으로 다르다. 게다가 요즘 스마트폰은 CPU와 메모리로만 치면 이미 최하 윈도우 98/2000 정도는 너끈히 돌리는 성능이다. 무슨 고전 게임도 아니고, PC와의 격차가 의외로 높지 않으니 PC에서 에뮬레이팅이 버거울 수밖에 없다.
게다가 애플리케이션들은 그나마 네이티브 코드도 아니고 잘 알다시피 자바 기반.

그리고 마지막 복병이 있는데 바로 그래픽 가속이다. OpenGL 같은 통일된 인터페이스가 있다지만 그래픽 가속은 워낙 민감한 부위여서 그런지 가상화가 더디다. 가상 머신에서 돌아가는 윈도우 비스타/7이 Aero 효과를 내지는 못하며, 에뮬레이터에서 돌아가는 스마트폰 OS는 실물만치 현란한 비주얼을 선보이지는 못한다.

그러나 PC+에뮬레이터가 디스크 I/O만은 실물보다 훨씬 더 빠르게 수행한다.
이런 식으로 스마트폰 앱은 에뮬레이터에서 돌릴 때와 실물에서 돌릴 때의 성능 편차가 의외로 크며, PC에서 개발하더라도 수시로 실물에서 올려서 확인이 필요하다고 한다.

Posted by 사무엘

1. 망했어요

사례 1: USB 플래시 메모리를 ‘안전하게 제거’하지 않고 그냥 뺌 → 어느 날 그걸 꽂으니까 “뭘 스캔해서 수정하시겠습니까?”라고 물음 → 예 → 뭐 오류가 있는 파일 조각을 따로 정리했다고 하는데, 그 후 작업하던 문서 파일이 날아가 버림

사례 2:자기가 작업하던 파일을 인터넷에 올림 → 다른 컴에서 그걸 그대로 엶 (인터넷 임시 파일 디렉터리에서) → 작업을 임시 파일에다 마저 다 해 놓고 저장 → 나중에 그 파일을 찾아보니 없음

이번 학기에 학교에서 주변에 실제로 있었던 낭패 사례이다. 조심하자. 본인이 겪었다는 건 아니고. -_-
PC가 발전하는 걸 도스 시절부터 그 디테일을 쫙 봐 오지 않은 사람이라면 쉽게 저지를 만도 한 실수인 것 같다. 디스크 캐시와 flush의 필요성, 인터넷 임시 파일의 개념과 원리에 대한 이해가 필요하니까 말이다.

USB로 연결하는 플래시 메모리의 경우, 평소에 그냥 쑥 제거해도 별 문제가 없는 듯하다가 어느날 갑자기 FAT 구조가 망가졌다고 그러면...;; 정말 사용자들 패닉에 빠뜨리기 딱 좋을 것 같다.
안전하게 제거를 하지 않는 것은 과거에 플로피 디스크 드라이브에 불이 들어와 있는데 디스크를 강제로 꺼내는 것이라든가, 하드디스크를 파킹하지 않는 것만큼이나 위험할 수가 있다.

다만, CD롬은 일단 쓰기가 없는 읽기 전용 매체인 데다가, eject 버튼을 누르면 아무 때나 디스크를 물리적으로 꺼내는 게 아니라 자기가 꺼낼 준비를 다 마치고 나서 eject를 시켜 주기 때문에 다소 예외적인 존재이다.

2. 하드디스크 파킹의 추억

옛날에 컴퓨터에 하드디스크라는 게 처음으로 등장하던 시절엔(도스+윈도우 3.x) 컴퓨터를 끄기 전에 하드디스크 파킹이 안전을 위해 필수적인 절차였다. 파킹을 하지 않는 것 자체가 문제는 아니지만, 파킹을 하지 않은 채로 나중에 하드디스크가 외부로부터 충격이라도 받았을 때, 헤드가 자기 아래의 디스크 영역을 건드리거나 긁는 게 문제가 되었기 때문이다. 헤드와 디스크 사이의 간격은 아마 몇 마이크로미터 정도밖에 되지 않았지 싶다. 하드디스크는 그 당시로서는 그만치 첨단 정밀 기기였던 것이다.

파킹은 하드디스크의 헤드를 디스크가 아닌 다른 안전한 위치로 옮기는 동작을 말하는데, MS 도스 인터럽트를 날려 주면 수행되었다(INT 13, 19h). 286 AT급 이상부터 추가된 명령이다. 도스 시절에 컴퓨터의 C:\Util에 가 보면 park.com/exe는 꼭 한둘씩 있었다.

그런데 이 파킹 유틸리티의 비주얼이라는 게, 오늘날로 치면 마치 화면 보호기의 비주얼만큼이나 아주 잉여스럽게 발달했다.
그냥 파킹만 하면 재미없으니까 좋아하는 볼거리, 미소녀 그림-_- 따위가 뜨는 파킹 프로그램들이 우후죽순처럼 등장한 것이다.

당시 여러 파킹 프로그램이 있었지만 본인의 기억에 가장 남는 건 일명 Princess maker 파킹이라고 아래와 같은 소녀 그림이 나오는 프로그램이었다. 어렸을 때는 정말 환상적이기 그지없는 그림이었다.

본인은 도스 시절에 하드웨어 제어 프로그래밍을 경험한 적은 없지만, 그때는 각종 인터럽트 레퍼런스가 지금으로 치면 윈도우 API 레퍼런스나 마찬가지였다. ^^;; 그걸로 마우스를 직접 제어하고, 한글 바이오스가 설치돼 있는지 감지하는 등의 작업을 했는데 오늘날은 다 필요 없어진 셈.

또한, 전원이 끊어지는 순간에 자동으로 파킹이 되는(auto-parking) 하드디스크가 이내 등장하고, 도스에서 윈도우로 PC 환경이 바뀌고, 또 요즘 같은 복잡한 운영체제는 아무 때나 바로 끄면 안 되고 어차피 시스템 종료라는 걸 요구하게 되면서 customized 파킹 프로그램이라는 유행은 역사 속으로 사라지게 됐다. 지금은 파킹 프로그램뿐만 아니라 화면 보호기도 LCD 모니터가 대세가 되면서 취지가 무색해지긴 했다.

3. 당신이 사용하는 소프트웨어는?

서식 없는 텍스트 작성
컴 초보: 메모장이나 일반 워드 프로세서로 낑낑댐
나: EditPlus나 AcroEdit, <날개셋> 편집기^^ 잘 다룸
전산과 덕후: vim, emacs 등..;;

서식 있는 텍스트
컴 초보: 닥치고 아래아한글
나: 아래아한글이나 워드를 평균 이상으로 그럭저럭 활용
전산과 덕후: TEX이나 그냥 메모장으로 html 코딩..;; 리눅스 용자는 OpenOffice를 쓰기도 함 ㅋㅋㅋ

뭔가 자동화 작업을 반복 수행할 때
컴 초보: 직접 손으로..;; 아니면 프로그램 검색하거나 남에게 부탁
나: 적당한 프로그램이 없으면 그냥 비주얼 C++로 프로그램 자작
전산과 덕후: 파이썬이나 쉘 스크립트

위의 것보다는 더 규모 있고 성능이 중요하고 남에게 실행 파일을 전달해 주는 프로그램을 짠다면?
컴 초보: 그냥 선생이 지정해 준 툴로... 과제만 내고 나면 다 잊어버림
나: 닥치고 비주얼 C++ 짱
전산과 덕후: 커맨드 라인에서 gcc -_-;;

난 소프트웨어 개발자치고는 MS의 종속도가 높으며, 전산과 덕후의 문화를 너무 모른다. -_-;;;

Posted by 사무엘

오랜만에 알고리즘 얘기.
정보 올림피아드 공부를 한 적이 있는 분이라면, 제목에 등장한 용어가 아주 친숙할 것이다. 앞으로 LIS라고 줄여 일컫겠다.

어떤 수열이 왼쪽에서 오른쪽으로 나열돼 있으면, 그 배열 순서를 유지하면서 크기가 점진적으로 커지는 가장 긴 부분수열을 추출하는 것이 목표이다.
가령, {3, 2, 1, 4, 5, 2, 3, 5, 3, 6, 4} 같은 수열이 있으면
1, 2, 3, 5, 6이 가장 긴 solution이 된다. {3, 2, 1, 4, 5, 2, 3, 5, 3, 6,  4} OK?
정렬만큼이나 알고리즘 기초를 다지는 데 도움이 되는 흥미로운 문제이다.

이 문제는 간단하게 생각하면 다이나믹 프로그래밍(동적 계획법)을 적용한 O(n^2)의 시간 복잡도로 풀 수 있다. 작은 set에 대한 답을 구한 뒤 그 결과를 저장해 놓고, 그 set의 크기를 차츰 키우면서 작은 solution들을 종합하여 최종 solution을 구하는 방식.

매 원소에 대해서 자기까지 왔을 때 존재 가능한 subsequence의 최대 길이와, 그 subsequence 상에서 자기 앞 원소의 위치를 적어 놓는다. 그러면 다음 원소 차례가 됐을 때는 자기 앞 원소들을 일일이 탐색하여, 자기보다 값이 작으면서 잠재적 subsequence 길이가 최장으로 설정되어 있는 원소에다 자기를 연결해 놓는다. 물론 자기의 subsequence 길이는 1 증가시켜 놓고 말이다.

위와 같은 표가 완성되고 나면, 그 후 개수가 5로 가장 큰 9번 오프셋부터 시작하여 이전 참고 위치를 따라 역추적을 하면 LIS가 구해진다.

그런데 이걸 구하기 위해서 꼭 O(n^2)이나 되는 계산량이 필요할까? 더 효율적인 알고리즘은 없을까?
답은 ‘있다’이다. 물론 메모리 복잡도도 아까처럼 O(n)으로 완전히 동일하고 말이다.
이 새로운 알고리즘은 역시 길이가 n인 버퍼에다가 작업을 하는데, 버퍼의 용도가 아까와는 살짝 다르다.

이 버퍼 A[i](1<=i<=n)의 의미는, 길이가 i인 LIS를 구한다고 쳤을 때 존재 가능한 가장 작은 LIS 마지막 원소(와 그 원소의 위치)이다. 즉, 이 버퍼는 구해진 LIS의 길이만큼만 사용된다.

위의 예제 수열에서 매 원소가 들어올 때마다 버퍼는 다음과 같이 바뀌게 된다. 뒤에 새로운 원소가 추가되거나 이미 있는 값의 업데이트만 발생하지(O(1)), 배열 원소들을 전부 하나씩 밀어야 하는 삽입이나 삭제(O(n))가 발생하지는 않음을 염두에 두기 바란다.
3: 3
2: 2
1: 1
4: 1 4
5: 1 4 5
2: 1 2 5
3: 1 2 3
5: 1 2 3 5
3: 변화 없음
6: 1 2 3 5 6
4: 1 2 3 4 6

즉, 버퍼가 가리키고 있는 것은 각 길이별로 가장 작은 수일 뿐이다. 그러나 버퍼가 가리키는 순서대로 배열을 참조하면 수열이 언제나 오름차순, 즉 정렬이 돼 있다는 게 보장된다.
최소값을 갱신할 위치를 찾는 것은 이분 검색(binary search)으로 할 수 있다. 이 덕분에 작업이 O(n^2)에서 O(n log n)으로 줄어들 수 있게 된다. 정확하게 말하면 O(n log k)(k는 LIS 길이)이니 더욱 빠르다. worst case로 증가 수열을 만들 수가 없는 내림차순 수열을 던져 주면, 거의 O(n)이나 다름없는 속도로 금방 실행이 끝난다는 뜻이다.

물론, 이 버퍼에는 각 길이별로 가장 작은 증가 수열을 구하는 힌트만 들어있을 뿐, 가장 긴 LIS를 추적하는 정보는 전혀 들어있지 않다. 그렇기 때문에 추적 순서는 역시 별도의 배열에다 따로 보관해 놔야 하며 이 역시 그리 어렵지 않게 구현할 수 있다. 심심하신 분은 이 알고리즘을 직접 코딩해 보기 바란다.

정보 올림피아드를 공부하던 시절엔 이런 유형의 문제도 재미있었다. 뭐, 본인은 머리싸움에 쥐약인 타입인지라 경시 부문에서는 별 재미를 못 보고, 대박은 공모 부문에서 다 냈지만 말이다.

- 양수와 음수가 뒤섞인 n개의 수열이 있을 때 합이 가장 큰 구간을 O(n) 시간 만에 구하기
- 위와 비슷한 예로, 0.x와 n.x가 뒤섞인 n개의 수열이 있을 때 곱이 가장 큰 구간을 역시 O(n) 시간 만에 구하기
- x*y 2차원 배열이 있을 때, 이런 조건을 만족하는 가장 넓은 면적을 구하기 (1999년도 IOI의 공항 건설 부지 찾기 같은)

알고리즘이라는 게 OR(operations research)과 밀접한 관계가 있는 것 같다. 선형 계획법, 동적 계획법 같은 개념도 원래는 그 분야에서 유래되었기 때문에 용어에서 그다지 전산학적인 어원은 찾을 수 없다.
덧. algorithm인데 왜 다들 알고리듬이라고 적지 않고 알고리즘(=algorism?)이 보편화해 있는 걸까?

Posted by 사무엘

우리는 C/C++ 언어에 대해 배울 때, 이 언어는 근본적으로 컴파일과 링크를 거쳐 결과물이 만들어지며, 이 과정에서 소스 코드가 obj 파일로 바뀐다는 말을 듣는다. 그런데 이런 중간 파일들의 내부 구조는 어떨지, 최종 결과물인 실행 파일의 형태와 중간 파일 사이의 관계는 어떨지 등에 대해서 궁금하게 생각해 본 적은 없는가?

물론 obj 파일에는 컴파일된 기계어 코드가 잔뜩 들어있을 것이고 lib는 그냥 이미 컴파일된 obj 파일의 컬렉션에 불과하다. 하지만 그걸 감싸는 컨테이너 포맷 자체는 필요할 것이다.
C++의 경우, 함수의 이름을 prototype대로 decorate하는 방식이 표준으로 제정된 적이 없어서 그 방식이 컴파일러마다 제각각인 것으로 악명 높다. 그렇다면 이런 obj, lib 파일 포맷도 언어마다, 혹은 컴파일러마다 제각각인 것일까?

결론부터 말하자면, 정답은 ‘No’이다. obj, lib 같은 파일 포맷은 실행 파일의 포맷과 더불어 굉장히 시스템스러운 포맷이고, 일반적인 응용 프로그램의 개발자가 거의 관심을 가질 필요가 없는 분야임이 틀림없다. 컴파일러를 만든다거나, 골수 해커 같은 부류가 아니라면 말이다.

이런 건 그렇게까지 다양한 파일 포맷이 존재하지 않으며, 다양하게 만들 필요도 없다.
인텔 x86 기계에서는 전통적으로 인텔 사가 고안한 OMF(object module format이라는 아주 평이한 단어의 이니셜) 방식의 obj/lib 포맷이 독자적으로 쓰였다. 굉장히 역사가 긴 포맷이며, 볼랜드, 왓콤, MS 등의 컴파일러에서 다 호환됐기 때문에 서로 다른 컴파일러나 언어로 만든 obj 파일끼리도 이론적으로는 상호 링크가 가능했다. 물론, 언어별로, 특히 C++의 경우 아까 언급했듯이 decoration 방식이 다르면 명칭이 일치하지 않아 혼용이 곤란하겠지만, 이건 파일 포맷 자체의 문제는 아니었다.

그런데, 32비트 시대가 도래하면서 사정이 약간 달라졌다.
machine word의 크기가 커지고 CPU의 레지스터 구조도 달라지고.. 그에 따라 obj/lib 파일의 포맷도 일부 필드의 크기가 확장되는 등 변화를 겪게 되었으며, 인텔 사에서는 OMF 포맷을 32비트로 확장한 업그레이드 버전을 내놓았다. 마치 지금 윈도우의 PE 실행 파일도 64비트에서는 기본적인 뼈대는 그대로 유지하되, 규격이 확장된 것과 같은 이치이다.

컴파일러들은 대체로 그 규격을 따르기 시작했으나, 이때 MS에서는 꽤 과감한 결정을 내렸다.
기왕 32비트로 갈아타는 김에, 자기네가 만드는(OS/2의 밑천으로? ㄲㄲ) 순수 32비트 운영체제인 윈도우 NT에서는 공식 사용하는 실행 파일과 obj/lib 파일의 포맷을 싹 바꾼 것이다.
어디 그뿐일까? 메모리가 귀하던 1990년대에 그때 이미 유니코드를 고려하여 딱 16비트 wide string을 내부 자료 구조로 채택했다. 본인이 보기에 윈도우 NT는 출발이 굉장히 대인배스러웠다.

새로운 포맷은 단순히 구조체 필드만 32비트에 맞게 키운 게 아니라, 더 보편적인 이식성과 확장성을 고려해서 설계되었다. 코드, 데이터 등 용도별로 다양한 chunk를 둘 수 있고, CPU 정보도 넣어서 굳이 x86뿐만이 아니라 어느 플랫폼 코드의 컨테이너로도 활용할 수 있게 했다. 또한 어차피 똑같은 기계어 코드가 들어있는 파일인데 obj/lib/exe 사이의 구조적 이질감을 낮춰서 일단 컴파일된 코드의 링크 작업을 더욱 수월하게 할 수 있게 했다.

그래서 MS는 32비트 컴파일러에서는 AT&T가 개발한 COFF(Common Object File Format) 방식을 약간 변형한 obj/lib를 사용하기 시작했고, 32비트 실행 파일은 잘 알다시피 COFF의 연장선에 가까운 PE(Portable Executable) 방식을 채택했다. 이 컨벤션이 오늘날의 64비트에까지 고스란히 전해 내려오는 중이다.

그렇게 MS는 과거 유물을 미련 없이 내버렸지만, 볼랜드 컴파일러는 32비트 윈도우용도 여전히 OMF 방식을 사용했고, 왓콤처럼 당시 16비트/32비트 도스/윈도우를 모두 지원하던 컴파일러는 OMF와 COFF 방식을 혼용까지 해서 당시 개발자들에게 상당한 혼란을 끼쳤다고 한다. 윈도우 운영체제가 16비트에서 32비트로 넘어가면서 이런 것까지도 정말 넘사벽에 가깝게 세상이 바뀐 것이다. 참고로 DJGPP는 도스용 컴파일러이지만 32비트 기반이고 COFF 방식 파일을 사용한다.

1985년에 나온 윈도우 1.0 이래로 16비트 윈도우가 사용하던 NE 포맷은 chunk 같은 게 없었다. 정보 자체를 식별하는 방법이 없이 요 정보 다음엔 무슨 정보, 다음에는 무슨 정보.. 딱 용도가 고정되어 있었고, 뭔가 확장을 할 수가 없었다. 상당히 원시적인 포맷이었다는 뜻. 개인적으로 그 시절에는 컴파일과 링크가 어떻게 이뤄졌고 DLL import/export가 어떤 방식으로 되었는지 무척 궁금하다.

또 생각나는 게 있는데, 과거에 똑같은 베이직 컴파일러이지만 MS가 개발한 퀵베이직은 굉장히 C언어에 가깝고, 파워베이직은 파스칼에 가까운 빌드 모델을 사용했다. 전자의 경우 헤더 파일을 인클루드하고 소스 파일을 obj로 컴파일하고, 각종 라이브러리와 링크하고... C와 똑같지 않은지? obj/lib 파일 포맷은 당연히 인텔 OMF 방식이었다.

그 반면, 파워베이직은 파스칼처럼 unit이라는 패키지를 만들고, 그걸 간단하게 use하는 것만으로 여타 모듈의 루틴을 사용할 수 있었다. 자바, C#, D 같은 요즘 언어들이야 비효율적인 인클루드(text parsing이 필요!) 방식이 아닌 패키지 import를 선호하는 추세이지만, 그 당시 파워베이직을 개발한 Bob Zale은 분명 파스칼 언어에서 이 아이디어를 따 왔을 것 같다. 물론 그렇다고 해서 파워베이직도 기존 obj 파일과 링크하는 방식이 없는 건 아니었다.
Bob Zale과, 터보 파스칼을 개발한 필리페 칸과는 어떤 사이일지 궁금하다.

C/C++에 전처리기가 있다면, 베이직이나 파스칼 같은 언어는 주석 안에다가 메타커맨드를 넣는 방식을 써 온 것도 흥미로운 점.
아울러, tpu, pbu 같은 저런 unit 파일은 분명 컴파일된 기계어 코드가 들어있는 라이브러리에 가깝지만, 당연히 컴파일러 vendor마다 파일 포맷이 제각각이다. 마치 퀵베이직의 QLB(퀵라이브러리) 파일이 아주 독자적이고 특이한 실행 파일인 것처럼 말이다.

Posted by 사무엘

컴퓨터가 글자가 아닌 그림을 처리하기에는 능력이 한참 부족하던 시절에, 벌써부터 포인팅 장비라는 개념이 있는 게 사용자 인터페이스 차원에서 좋겠다는 생각을 한 선구자가 있었다. 그게 한 196~70년대의 일이다.
포인팅 장비는 2차원 평면에서의 속도감 내지 곡률을 표현할 수 있기 때문에, 컴퓨터에서 키보드와는 또 다른 영역을 개척한 중요한 입력 장치이다.

마우스: x, y 축의 재빠른 이동과 클릭을 지원하는 대표적인 포인팅 장비. 옛날에는 버튼이 3개였으나 요즘은 2버튼으로 통일되었고, 대신 휠이 달려 나온다. 또한 볼 마우스이던 것도 다 광 마우스로 대체. 3버튼이나 트리플 클릭이 없는 것은 인간이 심리적으로 3회 이상의 동일 동작 반복을 싫어한다는 증거가 될 수도 있다. 마우스를 쓰는 프로게이머는 있어도 트랙볼이나 터치패드를 쓰는 변-_-태는 없다. 하지만 인체공학적으로 잘 만들어지지 못한 마우스를 오래 사용할 경우 사용자의 손목에 굉장한 무리를 주므로 주의 필요.

트랙볼: 볼 마우스의 볼을 직접 굴리는 방식으로, 마우스와 기능면에서는 동일하다. 마우스의 쾌적한 이동성은 다소 희생했지만, (1) 좁은 공간에서 사용 가능하고 (2) 손가락만 까딱이면 되지 손목 전체를 움직일 필요가 없어서 피로감이 덜하다는 장점이 있다. 그래서 노트북에 전통적으로 트랙볼 류의 포인팅 장비가 탑재되는 경향이 있었다.
트랙볼은 x, y뿐만 아니라 마우스로는 가능하지 않은 z축 이동을 이론적으로 표현할 수 있다. (볼 자체를 좌우로 굴리기!!) 나름 3차원 장비라는 뜻. z축을 휠로 사용해도 될 것 같은데.

터치패드: 역시 노트북용 마우스 대체 장비로 손가락을 마우스처럼 이동한다. 트랙볼의 장점을 어느 정도 가지면서 이동의 편의성이 트랙볼보다 낫지만 여전히 마우스보다는 못하며, 이동 중에 클릭이나 휠 조작을 동시에 하기가 어렵다는 단점이 있다. 터치패드에 영 적응을 못 해서 늘 마우스를 지참하는 노트북 사용자도 있으나, 본인은 터치패드로 스타도 할 정도로 이놈을 아주 능숙하게 다룬다. 노트북 사용 10+년 경력.

IBM 노트북에만 있는 거시기: 이름이 뭔지 모르겠다. 트랙볼보다도 더욱 홀쭉한 bar를 한 손가락으로 어루만지고 있으면, 손가락이 닿은 지점에 따라 마우스 포인터가 직선 내지 매끄러운 곡선 궤적을 그리면서 이동한다. 공간 활용성은 최적이고 어떻게 만들었는지 정말 신기하기 그지없는 물건이긴 하나, 이동성은 그리 좋지 못하다고 봐야겠다.

아울러, 마우스를 제외한 다른 대체 포인팅 장비들은 휠을 굴리는 것까지는 표현하는 방법이 있는 반면, ‘휠을 누르는’ 동작은 표현하지 못하는 경우가 많다. 보통 휠을 누르면 동그란 앵커가 포인팅 지점에 나타나면서 문서를 위나 아래로 자동으로 스크롤하는 모드가 된다. ^^;;

터치스크린: 이건 마우스와는 성격이 약간 다른 장비이기 때문에 마우스의 대체품이 되지는 못한다. 말 그대로 화면을 터치할 수 있는데 여러 곳의 동시 터치가 가능하고 장비에 따라서는 터치하는 압력을 표현할 수 있다. 그래서 여러 손가락을 동시에 써서 그림을 그리거나 문자를 입력하거나, 건반악기의 화음 표현까지도 가능하다.

다만, 터치스크린은 딱히 스타일러스 펜을 사용하지 않는다면 좌표의 정밀도가 크게 떨어지며, 마우스로 치면 늘 click이나 drag만 존재하지 포인터를 움직이기만 하는 hovering을 표현할 수 없다는 게 문제이다. 즉, UI 요소에 대해서 ‘이게 뭐지?’ 하는 tooltip을 구현하기 어렵다. 또한 좌클릭/우클릭 구분도 할 수 없기 때문에 마우스와는 근본적으로 다른 방식의 UI 설계가 필요하다.

태블릿: 옛날에 본인이 어렸을 때는 디지타이저라고 배웠던 것 같다. 웹툰 작가 같은 그래픽 디자이너에게 필수인 물건이다. 모니터가 아니라 종이처럼 생긴 납작한 물건 위에다가 펜으로 그린다. 그래픽용으로 쓰는 물건인 만큼 압력을 표현할 수 있다.

※ 덧붙이는 말

1. 도스 시절에는 마우스를 모뎀과 같은 COM port에다 꽂았다. 추억의 mouse.com 프로그램. 무슨 인터럽트 서비스를 호출해 주면 하드웨어? 차원에서 아주 자그마한 마우스 포인터가 나타났었다. 그런데 마우스 포인터를 유지하는 게 도스 시절엔 꽤 부담스러운 일이었다. 화면을 고칠 때마다 포인터를 숨기고 다시 그려 줘야 했기 때문이다. 안 그러면 화면에 잔상이 남음.

1990년대 중반에 그래픽 카드의 성능이 발달하면서 윈도우 3.1 시절부터 flicker-free 포인터가 나타나기 시작했다. 하드웨어 차원에서 마우스 포인터의 모양을 입체적으로 보존해 준다는 뜻이다. 그것도 처음에는 시스템 기본 포인터라든가 monochrome(단색) 포인터만 지원되던 것이 2000년대부터 아무 포인터에 대해서도 OK가 되기 시작한 것이다.
윈도우 2000은 안전 모드로 부팅해서 허접한 일반 VGA 16컬러 모드에서 구동될 때도 마우스 포인터가 flicker-free가 보장되는 게 인상적이었다. 9x는 그렇지 않기 때문에.

2. 초창기에 마우스를 지원하던 프로그램은 마우스 포인터라는 게 없었고, 위· 아래로 마우스를 움직이면 선택 막대가 움직이는... 오늘날로서는 아주 기괴한 인터페이스를 제공하기도 했다.

3. 그나저나 마우스 휠이라는 건 1997년 무렵에 MS가 적극적으로 홍보하면서 널리 퍼졌다. WM_MOUSEWHEEL이라는 메시지가 운영체제 차원에서 추가된 것은 윈도우 98부터이다.
그때는 나중에 휠이 연속적이고 부드러운 rolling도 표현 가능할 것을 염두에 두고 메시지의 스펙을 설계했지만 지금 휠이 실제로 그런 방향으로 바뀐 것 같지는 않다.

일반적으로 마우스 휠 메시지는 다른 마우스 메시지와는 달리, 마우스 포인터가 가리키고 있는 윈도우가 아니라 현재 키보드 포커스를 받고 있는 윈도우로 날아간다. 그래서 원래 휠 메시지는 마우스 포인터가 어디 있든지 관계없이 받을 수 있는데 예외가 있다. 웹브라우저 창에서 굴리는 휠은 키보드 포커스도 있고 포인터 역시 그 창에 있어야 인식된다. 한 브라우저 창 안에 여러 프레임이라든가 심지어 글자 입력란처럼 여러 윈도우가 존재할 수 있기 때문에 그렇게 디자인된 것 같다.

4. 옛날 컴퓨터에는 컴퓨터의 동작 전체를 멈출 수 있는 pause 키가 존재했다. 그리고 컴퓨터가 동작 중일 때 키를 자꾸 눌러서, 처리되지 못한 키 버퍼가 꽉 차면 컴퓨터 차원에서 ‘삑삑’ 경고 beep음이 났다. 이거 기억하는 분 계시는가?

이 경고음을 마지막으로 들은 게 언제인지 기억도 안 난다. 하긴, 윈도우 9x의 BSOD도 아련한 추억이 돼 간다. 그 시절엔 그만큼 컴퓨터도, 운영체제의 구조도 단순했으며 컴퓨터의 전체 자원을 특정 프로그램이 순식간에 전부 장악하는 게 가능했다. 일부 게임을 실행하면 하드웨어를 이상하게 제어해서 pause 키가 안 먹히고 ctrl+alt+del도 안 먹히고, 심지어 caps/num lock 같은 키의 램프의 toggle도 안 되게 바뀌기도 했다.
지금은? 그렇게 한 프로그램에게 덥석 줘 버리기에는 컴퓨터의 성능과 자원이 너무 커졌고, 또 그걸 과거 컴퓨터와의 하위 호환성까지 최대한 유지하면서 제공하느라 구조가 더욱 복잡하기 짝이 없게 돼 있다.

Posted by 사무엘

본인이 학부를 졸업한 후, 카이스트는 서 남표 총장을 주축으로 하여 내부 시스템이 굉장히 많이 바뀌었다. 나 같은 학생에게 굉장히 불리하게 바뀐 제도도 꽤 되기 때문에, 병특도 휴학이 아니라 일찌감치 졸업을 해 버리고 간 것을 본인은 천만다행으로 생각한다. -_- (본인은 최 덕인· 홍 창선 원장에서 시작해서 러플린 총장으로 끝난 세대이다.)

본인의 전공인 전산학과의 경우, 시간이 흐르면서 그때 조교수였던 분이 부교수가 되고 부교수가 드디어 정교수로 진급해 있는 것을 홈페이지를 통해 보곤 했다. 또한 ICU가 진통 끝에 카이스트와 결국 합병되면서, 그쪽 인력의 유입으로 인해 예전에 못 보던 교수들 얼굴이 크게 늘었다. 정보통신부가 없어진 게 크게 작용했으리라.

200X년도에 스탠퍼드, MIT 등 굴지의 학교에서 박사 학위를 받은 뒤 곧장 카이스트로 온 젊은 신임 교수들을 보면 부럽기 그지없다.
하지만 이제는 교수가 돼도 정년 보장이 옛날만치 쉽지 않고, 주변에 온통 널린 게 천재들 뿐이니 연구 실적에 대한 스트레스도 만만찮을 것이다. 서 총장이 학생뿐만 아니라 교수들도 엄청 쪼아대고 있다는 소문은 익히 들었다.

그래서인지 어느 샌가 카이스트를 떠난 교수도 보인다.
얼마 전엔 우연히 졸업생 조회 웹사이트에서 본인의 이름을 검색해 봤다.
그랬는데, 본인의 학부 졸업 논문 지도교수였던 분이 지금은 카이스트 교수 명단에서 보이지 않았다.

뭐, 학부 졸업 논문은 진짜 형식적이었고, 교수님이 내 리포트를 읽어는 봤을까 싶은 생각이 들 정도로 얼렁뚱땅 통과가 되긴 했다. 그래서 요즘은, 학부 수준에서는 졸논을 좀더 실무 위주인 현장 실습이나 졸업 프로젝트로 대체하는 게 카이스트를 비롯한 국내 대학들의 전산과의 추세이다.
처음에 본인의 지도교수는 다른 분이었는데, 나중에 졸논을 쓸 무렵에 여차여차 하다 보니 저 교수로 바뀌었다. 어째서 하필 그분으로 배정됐는지는 그 과정에 대해서는 지금은 기억이 가물가물하다.

좀더 검색을 해 보니까, 그 교수님은 고려대로 전근을 가 계셨다. 오홋;;;
호기심에 옛날 교수들 검색을 더 해 봤는데, 굉장히 놀라운 결과를 발견했다.

성균관대에 전직 카이스트 교수가 네 명이나 있었기 때문이다. 2008~09년 무렵에 한꺼번에 저기로 간 것이었다. 본인은 학부 시절에 그 교수 4인 중 3인의 수업을 들은 적이 있다.

어이쿠, 게다가 이것도 나 혼자 뒷북이었다. 성균관 대학교는 스마트폰 열풍 속에서, (그리고 아마도 이 건희 본좌님의 입김으로) 소프트웨어학과를 신설하기로 결정을 내렸다. 하드웨어인 반도체에 이어서 소프트웨어까지 특성화?? 본격 IT 대학으로 거듭나려는 듯. 그리고 그 과정에서 성대는 카이스트 전산학과 교수를 한꺼번에 네 명이나 스카웃해 갔으며, 이것은 이미 그 당시에도 큰 뉴스거리로 떠올랐다고 한다.

아마 대전 생활에 신물을 느꼈거나, 서 총장의 정책이 마음에 안 들거나, 반대로 성균관대의 파격적인 처우 제안에 끌렸거나... 그런 이유로 인해서 그분들이 전근 간 게 아닌가 싶다.

덧붙이는 말:

1.
본인은 군대를 현역으로 갔다 오지 않았고 병특 중에도 딱히 군대와 관련된 안 좋은 일을 겪은 적은 없기 때문에, 군대에 다시 끌려가는 꿈-_-;;; 같은 건 안 꾼다.
하지만 한때는 아래와 같은 판타지 같은 꿈도 자다가 몇 번 꾸긴 했다.
- <날개셋> 한글 입력기로 ISEF에 또 출전하는 꿈 (10년 도 더 전 일을..;; ㅋㅋㅋ)
- 병특을 마친 뒤에 카이스트로 3년 만에 복학하여 졸업 이수 요건 채우느라 고민하는 꿈 (아놔 나 3년 전에 졸업했어-_-)

2.
본인은 주임 교수가 국문과 소속인 협동 과정 대학원에 갔지만 학위 논문의 지도교수는 국문과가 아닌 컴퓨터과학과(전산과의 연세대 학과 명칭) 교수가 될 공산이 크다. 그래서 이곳의 교수들은 어떤 분이 있는지 틈틈이 찾아보고 있다. 본인의 코스와는 정반대로 학부는 연세대에서, 석· 박사를 카이스트에서 마친 교수가 한 분 계시는구나. 뭐 학번 차이는 본인과는 이미 까마득한 수준이지만 말이다.;;
내년부터는 국어학뿐만 아니라 컴퓨터과학과의 대학원 수업도 들을 예정이다. 본격 공학관에도 드나들게 되겠구나.

3.3.
그나저나 내 홈페이지 메인의 공개 사진을 바꿀 때가 되긴 했다. 공중파 TV에 출연한 화면이고, 분장도 아주 잘 돼 있는 데다 자막 내용-_-까지 여러 모로 아주 간지나는 모습이긴 하나.. 벌써 5년도 더 되어 너무 오래 됐고, 결정적으로 본인은 이제 카이스트 학생이 아니기 때문이다.
내가 TV에 출연한 게, 2006년에 한글 관련 다큐에 출연한 게 마지막이니, 다음엔 철도 관련 다큐에서.. (ㅎㄷㄷㄷ) 자막은 당당하게 '연세대 언어정보학과'라고 말이다. 그런 화면이라도 하나 만들어야 할 듯.

그래도 대전과 카이스트도 언제까지나 내게 제 2의 고향과 같은 곳으로 남을 것이다. 일반 대학들에서는 경험할 수 없는 카이스트만의 그 학교 분위기와 프라이드(불이 꺼지지 않는 연구실-_-)는 개인적으로 참 좋아했다.

Posted by 사무엘

오늘의 얘깃거리는 컴퓨터와 음악이다. 이 두 분야와 관계가 있는 옛날 소프트웨어들에 대한 추억도 곁들어질 것이다. 쓰다 보니 글이 꽤 길어졌다. ㄲㄲ

여기서 음악 파일이란, 말 그대로 음표 정보를 기반으로 음악을 연주하는 데이터를 말한다. 과거의 컴퓨터는 어마어마한 양의 waveform 데이터를 실시간으로 읽어들여(심지어 압축을 풀면서) 재생하면서 게임까지 원활하게 돌릴 정도의 성능을 갖추지 못했다. 그렇기 때문에 이런 가벼운 음표 기반 음악 파일이 각광을 받았다. 이런 파일은 크기가 아주 작은 데다, 또 음악은 반복되는 멜로디나 리듬이 많다는 특성상 압축률도 높았다.

※ 애드립 ROL, IMS

일명 FM(주파수 변조 방식) 사운드이다.
sound.com, unsound.com, 그리고 CGA 640*200이라는 흠좀무스러운 그래픽 모드에서 실행되던 애드립 Visual Composer (무려 1987년도 프로그램이다!).
standard.bnk, 이야기, implay 이런 것들을 기억한다면 당신은 진정 old timer 인증이다.

피아노, 바이올린, 색소폰 같은 현실의 악기와 비교했을 때는 분명 모자란 게 있지만 이 FM 음악은 나름 자신만의 개성과 색깔이 있었다. 단적인 예로, 과거 <그 날이 오면 3>의 환상적인 애드립 음악을 아직도 못 잊는 분들이 적지 않다.

FM 음악의 음색은 뱅크 파일에 별도로 담겨 있었다. 수백 개의 악기 음색이 100~200KB대 크기에 담겨 있던 걸로 기억한다. 음악에서의 악기는 문자 문서에서 일종의 폰트와 같은 존재인 셈이다.
PC 통신의 음악 자료실에는 최신 유행가, 팝송, 게임 음악 따위의 ROL/IMS 파일들로 넘쳐났다. 누군가가 악보를 구해다가 노가다로 열심히 입력해서 만들었을 것이다. IMS 파일은 당시 PC 통신 프로그램의 최강자이던 <이야기>가 지원했으니 인지도 면에서 더 말이 필요없었다.

이에 덧붙여 ISS라고 해서 가사 파일이란 게 국내에서 제정되었는데, 곡이 진행되면서 글자색이 점진적으로 변하게 할 수 있었기 때문에 일종의 노래방 효과도 낼 수 있었다. 동영상으로 치면 자막 파일과 같은 존재이다.

※ 모듈 S3M, MOD

모듈 음악 파일은 기본적으로 음표 정보 기반 음악 파일 포맷이긴 한데, FM 방식과는 중요한 차이가 있다. 악기의 음색이 waveform 오디오 형태로 파일에 내장되어 있다는 것. 문서로 치면 폰트를 일일이 내장하고 있는 셈이다. 그래서 평균적인 파일 크기는 기본이 수백 KB는 먹고 들어가기 때문에 mid나 애드립 사운드보다는 큰 편이지만, 당시로서는 가격 대 성능비가 아주 우수하고 음질이 좋은 음악을 만들어낼 수 있었다.

다만 모듈 음악은 여전히 음악보다는 컴퓨터 지향적인 방식이고, 미디처럼 세계 균일 표준으로까지 승격되지는 못해서 오늘날은 WinAmp나 VLC 같은 일부 매니악한 프로그램이나 재생을 지원하는 마이너 포맷으로 명맥을 유지하게 됐다.

애드립 음악에 Visual Composer가 있다면, 모듈 음악 분야에는 Scream Tracker라는 금색 UI를 갖춘 유명한 소프트웨어가 본좌이다. 그리고 재생기로는 Inertia player이라고 전설적인 도스용 프로그램이 있었다. 개발자가 밝히기를 100% 어셈블리만 써서 작성했다고 하니 흠좀무.

※ 대세는 미디

그 반면 오늘날 대세는 역시 국제 표준인 미디이다. 본인은 윈도우를 쓰기 전에 도스 시절에는 애드립이나 모듈 음악만 접했지 미디 파일도, 재생기도 전혀 접하지 못했다. 하지만 미디라는 표준 자체는 굉장히 오래 전에 제정된 것이다.

심지어 1989-90년대를 풍미했던 페르시아의 왕자의 midisnd.dat 같은 파일을 들여다 봐도, 내부는 윈도우 미디어 플레이어로 재생 가능한 표준 미디 파일들의 모음이다! 그래서 인트로/엔딩 음악, 죽었을 때의 음악 따위를 쉽게 추출할 수 있다.

도스용 둠 1, 2의 배경 음악도 내부적으로는 미디 포맷이다. 사실, 그 전작인 울펜슈타인 3D도 데이터 파일을 들여다보지는 않았지만, 음악을 딱 들어 보면 미디인게 티가 난다.

미디에는 구체적인 음색에 대한 규정은 전혀 없기 때문에, 과거 애드립으로 허접하게 재생되던 음악도 미디인가 하면 오늘날 최첨단 노래방 기기에서 코러스까지 곁들여져 나오는 음악도 죄다 미디이다. 과거에는 미디 음악을 컴퓨터에서 제대로 들으려면 미디 카드가 필수였지만, 컴퓨터의 성능이 향상되면서 2000/ME부터는 윈도우 운영체제가 좀 그럴싸한 미디 신시사이저 소프트웨어를 내장하게 되었다.

하지만 요즘 게임들은 음악도 닥치고 wav나 mp3 통째로 내장이다. DirectMusic이 괜히 개발이 중단된 게 아니다. 현업 게임에서 쓰이질 않고 있는 컴포넌트이기 때문.

※ 애드립 음악 관련 추억: 옹 컴포저

1998년의 일이다. 옹 언욱 씨라고, 본인보다 나이는 한 학년 위이고 당시 고등학생이던 분이 <옹 컴포저(Ong Composer)>라는 프로그램을 개발했다. 쉽게 말해 애드립 음악 파일 편집기이다. 그런데 이분은 프로그래밍은 물론이고 음악, 그래픽까지 두루 본인과는 비교가 안 되는 진정한 엄친아였다. 그 열악한 16비트 볼랜드 C++로 슈퍼 VGA 그래픽(선 그리기, 점 찍기, 비트맵 -_-)과 사운드 제어 루틴을 어셈블리로 다 자체 제작하고 GUI 라이브러리에 심지어 스킨까지 혼자 다 만들었다... ㅎㄷㄷㄷㄷ;; 난 그런 쪽은 쥐뿔도 실력이 없으니 전적으로 공개 라이브러리에 의존했는데 말이다. ㅋㅋ

참고로, 컴퓨터 음악 프로그램은 Noteworthy Composer처럼 작정하고 위지윅에 최적화된 프로그램이 아닌 이상, 우리가 흔히 생각하는 것처럼 오선지에 콩나물을 그려 넣는 형태가 아니다. 스프레드시트에다가 가로줄 길이로 음표를 표현하는 아주 기계 친화적인 모습을 하고 있다. 아까 언급한 Visaul Composer나 Scream Tracker도 마찬가지. 이는 프로그래밍 언어 소스 코드에 우리가 종이에다 쓰는 수학식이 그대로(근호, 분수 등) 들어가는 게 아닌 것과 같은 이치이다.

그런데 본인도 응시했던 1998년 제 15회 정보 올림피아드 공모 부문에서 옹 컴포저는 입상을 못 했다. 이런 어마어마한 프로그램이 왜 입상을 못 했는지는 모르겠다. 그러나 이듬해, 16회 대회에서 이분은 옹 컴포저를 윈도우용으로 포팅한 옹 컴포저 2를 출품하여 금상을 받는다. 그 후의 이분 근황은 본인도 알지 못한다. 프로그래밍에다가 탁월한 예체능(그래픽/음악) 쪽 재능을 갖춘 전문가이다 보니, 게임 개발에 뜻이 있는 분이던 걸로 기억한다.

덧붙이자면 15회와 16회 대회 때는 고등부에 대상 수상작이 없었다. 그 후 17회에서 본인이 출품한 한글 입력기 1.0 버전이 대상을 차지했다.

※ 모듈 음악 관련 추억: BWSB 라이브러리

BWSB (Bells, Whistles, and Sound Boards)라고 어느 영국의 프로그래머가 개발한 프로그래밍 라이브러리가 있었는데, 이게 정말 물건이었다. 퀵베이직, 파워베이직, 볼랜드 C/C++, 볼랜드 파스칼 등에서 모듈 음악을 재생해 줬다. 셰어웨어이긴 하지만 공개용도 프로그램 종료 시에 copyright 메시지가 뜨는 것 말고는 별다른 제약이 없었다. 굉장히 잘 만들었고 문서화도 서양식 유머가 가미된 재미있는 문체로 되어 있었다. "이런 주의사항을 지키지 않으면 외계인이 쳐들어와 당신의 컴퓨터를 가져가 버릴 것이다" 식.

이 분야에서는 거의 독보적인 라이브러리가 아니었나 싶다. 하지만 왓콤이나 DJGPP 같은 32비트 컴파일러를 지원하지 못했던 게 아쉬운 점으로 남아 있다. 어셈블리 튜닝 코딩이 많다 보니, 소스의 이식성이 떨어져서 포팅이 어려웠던 듯하다.
하긴, DJGPP용으로는 알레그로라는 만능 게임 라이브러리가 있긴 했는데 이건 모듈 음악은 지원 안 하고 미디만 지원했다. 알레그로도 영국 사람이 만들었다.

Posted by 사무엘

지난 9월 13일, 본인은 손전화를 교체함과 동시에 전화번호도 드디어 010 기반으로 바꿨다.
스마트폰은 아니지만 인터넷, 카메라 등 될 건 다 되는 햅틱 급의 터치폰이 본인의 제 4대 손전화로 취임했다. (참고로 노트북도 현 기종이 제 4대이다)
고등학교를 졸업한 직후인 2001년 초에 처음으로 개인용 휴대전화를 접한 이래로, 지금까지 폰을 총 세 번 바꿨다는 뜻이다.

본인은 전화번호는 개인적으로 가깝게 지내고 아는 사이인 사람에게만 공개하지, 홈페이지 같은 공개적인 장소에서는 알리지 않음을 밝힌다. 불특정 다수에게는 메일 주소만 공개하며, 이 블로그에서도 전화번호 자체는 공개하지 않고 전화번호가 바뀌었다는 사실만 알리는 것이다. 혹시 본인의 지인이면서 전화번호가 바뀌었다는 문자 연락을 받지 못한 분이 있다면 본인에게 알려 주기 바란다.

1990년대에는 PC의 발전 속도가 가히 폭발적이었다. XT/286급 컴퓨터가 무려 윈도우 98/2000을 돌리는 성능으로 발전하면서 20세기가 끝났다. 우유, 라면 값이나 버스 요금, 공중전화 요금 따위는 20년 전에 비해 지금이 3배 이상 올랐고 심지어 자동차 가격도 인플레의 영향을 받았지만, 컴퓨터의 가격만은 보편적인 생필품 물가를 역행해도 한참 역행해 왔다.

이와 같은 맥락으로 2000년대에는 전화기가 무서운 속도로 발전했다. 전국민이 손전화를 소지하면서 삐삐는 마치 인터넷 앞에서 PC 통신이 도태하듯이 역사 속으로 사라졌다. 공중전화도 마치 우체통만큼이나 아주 없앨 수는 없지만, 경영자의 입장에서는 천덕꾸러기 같은 존재가 됐다. 자동차용 고급 액세서리이던 카폰도 닥버하게 됐다.

단색 액정 화면은 컬러로 바뀌고 단색 멜로디는 애드립 멜로디를 거쳐 자연적인 사운드로 바뀌었다. 전화기에 웬 카메라 기능이 추가되고 영상 통화가 가능해지고 인터넷 접속이 가능해졌다. 비트맵 글꼴도 윤곽선 글꼴로 바뀌었다. 나중에는 아예 프로그램을 자유자재로 만들고 설치할 수 있는 스마트폰까지 등장하면서 지금까지 존재하던 각종 개인용 정보 열람/처리 기기의 기능을 흡수하게 되었다.
(관련 글: http://moogi.new21.org/tc/208 )

본인은 안드로이드와 아이폰의 싸움이 앞으로 어떻게 될지 좀 더 지켜본 뒤에 다음 전화기는 스마트폰으로 도입할 계획이다. -_-;;

초대 손전화 시절에 본인의 번호는 017이었다. 그러던 것이 대학 시절에 제 2대 손전화를 도입하면서 번호를 016 기반으로 바꿨고, 이 번호를 2003년부터 2010년까지 거의 7년 반 동안 사용했다. 그러니 본인이 애착이 갈 만도 하지 않은지? 2대와 3대 전화기는 한글 입력이 모두 나랏글 방식이었기 때문에 본인은 7년이 넘게 사용한 나랏글 방식에 아주 능숙하다.

이미 아시는 분도 있겠지만 본인은 전임인 3대 전화기(LG 싸이언)를 거의 집착에 가까운 수준으로 오래 썼다. 2004년 말부터 지금까지 거의 5년 9개월을 사용했다. 2년을 채 못 쓰고 분실한 2대 전화기와는 아주 대조적이다. 왜냐하면 본인은 손전화로는 오로지 통화와 문자밖에 안 쓰고 부가적으로 알람이나 주소록 정도밖에 사용하지 않기 때문에, 기능이 복잡한 전화기는 전혀 필요하지 않았기 때문이다. 다른 정보 처리 기능은 늘 들고 다니는 노트북을 이용하는 것으로 충분했다.

그래서 나중에는 이 구닥다리 전화기는, 자동차로 치면 마치 아직까지 포니나 스텔라 같은 차를 몰고 다니는 것과 비슷한 것처럼 보이게 되었다. “쟤 전산학 전공한 친구 맞어?” 경악이 나오기에 충분할 정도. 요즘 IT계에서는 안드로이드나 아이폰 개발자가 없어서 일손이 부족해 난리라는데, 본인은 그런 것과는 전혀에 가깝게 관계가 없는 삶을 살아 왔다.

그러다가 결국은 전화기를 바꾸게 됐다. 그건 전적으로 전임 전화기가 낡고 고장이 나서 전화기로서의 기능을 제대로 못 하고, 수리를 받아도 별 진전이 없기 때문이었다. 일종의 자연사인 셈이며, 정말로 불가피한 이유 때문에 바꾼 것이었다. ^^;;

언제부턴가 갑자기 전화 연결이 잘 안 되고, 통화 중에 전화가 끊어지고, 문자도 받는 건 잘 되는데 보내는 게 되지 않았다. 툭하면 ‘통화권 이탈’ 에러가 났다. 나 혼자 불편한 건 상관이 없는데, 이 때문에 본인에게 연락을 하는 다른 사람이 불편을 겪을 수 있기 때문에 단호하게 조치를 취한 것이었다.

10년 가깝게 폴더를 펼치는 일에 익숙해져 있다가 버튼 누르기, 화면 길게 누르기(터치폰을 activate하는 방식) 동작을 하는 것이라든가..
예전 폰으로는 꽤 금방 꺼냈던 기능을 지금 폰으로는 몇 차례 터치를 더 해야 되는 것에 대해서 좀더 연습이 필요해 보인다.
마치 도스용 아래아한글의 달인이던 사람이 윈도우용 아래아한글이나 MS 워드의 각종 마우스 동작에 적응하는 과정과 비슷한 맥락인 것 같다.

문자 메시지는 시간이 오래 걸리는 본문부터 먼저 입력하고 나서 수신자 번호를 입력받는 것이 심리적으로 무척 안정감을 줘서 좋다. (예전 폰은 수신자 번호 다음에 본문 순서여서 불편했음)

드디어 개인용 기계에서 천지인 입력 방식을 쓰게 됐는데... 모음을 분해하는 과정이 좀 복잡한 것, 그리고 음절 모호성 때문에 자음 연속 입력이 안 되는 경우가 있는 게 무척 불편하긴 하다.
하지만 나랏글도 일부 자음은 가획이 만만찮게 복잡하고, 그런 게 천지인에서는 반대로 편하게 되는 것도 있으니 일장일단이 있는 듯하다. 게다가 나랏글은 * #까지 12키를 모두 사용하지만, 천지인은 10개만으로 문자를 입력하고 * #키는 문장 부호 입력용으로 쓴다는 특징도 있다.

전화기를 개통해서 나오니까 꼭 자가용을 한 대 뽑아서 몰고 나오는 기분이었다. 교통 수단 대신 통신 수단이라는 차이만 있을 뿐.

다음은 관련 잡설들이다.

1. 본인 전화기의 컬러링이나 벨소리는 Looking for You, Oh Glory Korail 같은 걸로 했으면 좋겠다. ㅋㅋㅋ

2. 본인은 무선 인터넷이란 걸 접한 게 2003년에 학교 안에서였다. 그러던 게 불과 몇 년 사이에 무선 인터넷이 폭발적으로 보급되고 대중화했으며, 성능마저도 과거의 어지간한 유선 인터넷 회선의 속도를 따라잡았다. 손전화와 무선 인터넷이 없던 시절에 대학 캠퍼스 생활은 과연 어땠을까 상상이 안 된다.

3. 본인은 01x 번호에다가 3G 전화 서비스 같은 건 바라지도 않았다. 아직까지 기계 대체나 번호 변경에 관심이 없는 사람들은 그냥 있는 2G 전화만으로 만족하고 잘만 쓰려는 사람들이다. 단지, 개인의 선택권인 번호나 제멋대로 바꾸지 말고 이미 있는 서비스나 잘 제공해 줬으면 좋겠다.
사실상 4천만 명이 넘는 전국민이 손전화에 가입해 있는데 010 번호+겨우 8자리는 공간이 많이 모자라지 않나 하는 생각도 든다.

4. 오늘날 지메일은 구글이 2006년 만우절에 거짓말처럼 서비스를 시작한 이래로, 웹메일 서비스의 지존의 위치를 차지하고 있다. 지메일에 익숙한 사람은 다른 포털 사이트 메일은 너무 불편해서 못 쓴다는데, 본인은 10년도 더 전에 가입한 드림위즈 메일 계정을 아직까지 사용 중이다.
뭐, 본인도 지메일 계정이 없는 건 물론 아니다. 그 당시에 지메일은 초대장을 퍼뜨리는 방식으로 자기네 서비스를 홍보하고 사용자를 끌어모았던 걸로 기억한다. 한 사람당 기가바이트 급의 계정 용량을 준다고 했고 지금은 그 용량이 더욱 커져 있기도 하다.

Posted by 사무엘