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

벌써 10년도 더 묵은 고전 게임이 되어 버린 스타크래프트.
거기에는 테란이라는 종족이 있고, 테란 건물 중에는 아카데미라는 건물이 있다.
이건 설정상 사관학교이며, 잘 알다시피 마린 이상으로 파이어뱃, 메딕, 고스트 같은 고급 보병 유닛을 생산하는 데 필요한 건물이다.

그런데 아카데미를 클릭하면 굉장히 괴상한 소리가 나오는 걸로 잘 알려져 있다.
행진곡? 군가 소리와 함께 “이에에에에에~!” 하는 남자의 비명 소리가 들리는데...

이건 졸업하는 사관 생도들이 지르는 감격의 소리라고 받아들이기에는 기괴한 감이 적지 않다. 그래서 스팀팩 개발 과정에서의 공밀레 내지 피실험자가 고문 당하는 비명 소리일 가능성이 더 높다는 억측이 나돌곤 했다. 내가 스타를 즐기던 시절엔 말이다.

하지만 “이에에에에~” 소리 자체는 Howie Long scream이라고 하여 영미권에서 잘 알려져 있는 stock sound effect이다. 이름은 아마 저 소리를 최초로 연기한 배우의 이름에서 유래된 걸로 추정. 이미 1980년대부터 쓰였고 여러 영화에서 주로 남자 주인공이 유리창 깨고 높은 데서 떨어질 때의 비명 소리로 자주 나온다. (☞ 관련 링크)

개그만화 보기 좋은 날 3기 8화 <사랑의 계절! 큐피드 군>을 보면,
“당신은 앞으로 연애 실패를 비관하여 국회의원들을 모두 암살하게 됩니다. 그 뒤 결국 잡힌 당신은, 교도소에서 '여자친구 주셈!'이라고 소리칠 겁니다”-_-라는 큐피드의 대사가 나오는데, 그때도 교도소에 갇힌 주인공의 모습과 함께 남자의 비명 소리가 흘러나온다. 이 비명 소리도 Howie Long scream이다. 동일 소스이므로, 아카데미 소리와 비슷한 게 맞다.

하긴, 우리나라에는 한 달쯤 전엔, 국회의원을 모두 죽이려고 했는데 그건 삼엄한 경비 때문에 차마 못 하고 대신 초등학교로 쳐들어가서 흉기 난동을 벌이다 잡힌 사람이 있었다!
세상이 뒤숭숭하면 정치인들을 상대로 분노가 표출되는 게 사실이긴 한가 보다. (☞ 관련 링크)

Posted by 사무엘

1. 액체

흔히 화학적으로 물질의 상태는 플라즈마 같은 특수한 상태를 제외하면 통상 기체(gas), 액체(liquid), 고체(solid)라는 세 상태 중 하나로 분류된다. 그 중 기체와 액체는 고유한 형체가 없으며 고체와는 다른 공통점을 공유하기 때문에, 유체(fluid)라고 한데 분류되기도 한다. 내부에 부력과 양력이란 게 있을 수 있기 때문에 이를 논하는 '유체 역학'이라는 물리 분야도 있다.

그런 유체 역학의 관점에서는 고체가 아웃사이더이다. 하지만 액체를 아웃사이더로 보는 관점도 충분히 가능하다. 그리고 액체에는 액체 그 자체라고 봐도 될 정도로 너무나 상징적이고 대표적인 ‘물’이라는 물질이 있다. 물이 얼마나 흔해 빠진 물질이면서 한편으로 얼마나 특이한 물질인지는 화학을 전공한 사람이 본인보다 더 잘 알고 있을 것이다. 고체 얼음이 액체 물보다 부피가 더 크고 밀도가 작아진다는 것 하나만 생각해도 말이다.

물이 특이한 점은 지구의 특이한 점과도 결부된다. 물은 인간이 살 수 있는 '상온'이라는 기온대에서 액체 상태로 존재하는 매우 드문 물질 중 하나이다. 생각을 해 보시라. 물과의 혼합물 말고 화학적인 순물질(원소 또는 화합물) 중에서 액체인 놈이 또 뭐가 떠오르는지? 아주 없는 건 아니지만 수은 같은 것 말고는 선뜻 떠오르는 게 없을 것이다.

그리고 지구 역시 전우주적인 관점에서 봤을 때 표면의 대부분이 바다라는 '액체'로 뒤덮여 있는 매우 희귀한 행성이다! 다른 행성들은 혹독한 저온 또는 고온 때문에 표면 전체가 고체 아니면 기체이다. 착륙할 땅이 없는 목성 같은 행성의 경우, 표면과 가까워질수록 방사능과 유독가스의 농도 및 압력이 겉잡을 수 없이 짙어지면서, 접근하는 모든 물질을 파괴하고 으스러뜨리게 된다.

2. 알코올

지구상에는 물 말고도 '기름'이라는 액체가 있다. 기름은 (1) 물보다 가볍고 (2) 물과 섞이지 않으며 (3) 불에 잘 타는 액체의 총칭으로, 화학적인 특성만을 규정할 뿐, 화학적으로 특정 성분을 지칭하지는 않는다.
저 세 속성 중 일부만을 만족하는 물질은 지구상에 거의 없기라도 한지? 어떻게 저 세 특징을 한데 '기름'이라고 싸잡을 수 있는지는 잘 모르겠다. 어렸을 때부터 궁금했던 점이다.

(1)과 (2) 때문에 기름에 붙은 불은 물을 뿌려서 꺼서는 안 된다. 또한 (2)는 '물과 기름'이라는 관용구까지 만들어 냈을 정도로 유명한 특성이며, 씻어 내는 것도 물만으로는 안 되고 비누나 세제를 필요하게 만드는 더티한 주범이다. 그리고 (3) 때문에 기름은 '연료'로서 차지하는 비중이 대단히 높은 게 사실이다.

그런데 이런 기름의 통상적인 특성에 비해 알코올은 좀 색다른 면모가 있는 물질이다. 분명 물보다 가볍고 불에 잘 타는 액체인데.. (2)는 아니다. 물과 잘 섞인다! 끓는점의 차이를 이용해 물과 섞인 알코올의 분별 증류가 가능할 정도이다. 세상에 물과 잘 섞이는 액체 연료가 알코올 말고 또 있나..?

이 때문에 알코올은 천연 가스만치 위험하지는 않으면서도 다른 연료에 비해서 깨끗하다는 심상을 주며, 이는 실제로 맞는 말이다. 물만큼이나 쉽게 증발하여 흔적 없이 잘 사라진다. 에탄올을 괜히 소독용으로까지 쓴 게 아니다. (피부에 묻은 에탄올이 증발하면 물이 증발할 때보다 더 시원한 느낌이 든다.)

또한 연소 과정에서도 알코올은 그을음 없고 높은 온도를 잘 낸다. 이게 유용한 면모여서인지, 알코올 램프(+비커+삼발이..^^)는 테란전에서 캐리어가 프로토스의 상징인 것처럼 과학 실험의 상징이다. 가스나 석유 대신 알코올을 쓴다는 뜻. 물론, 굉장한 고온이 필요할 때는 가스를 연료로 쓰는 토치나 분젠 버너가 동원되겠지만.

파라핀 촛불의 노란 겉불꽃이 1400~1500도 정도인 반면, 알코올 램프의 파란 겉불꽃은 1700도를 넘어서 더 뜨겁다. 양초에 비해 알코올 램프의 심지는 더 굵직하다. 촛불은 불기만 해도 꺼지지만 알코올 램프는 불어서 끌 수 없으며 이는 위험한 시도이다. FM은 불길 위에다 램프 뚜껑을 확 씌워서 공기 공급을 끊어서 끄는 것이다. 불을 끈 뒤, 뚜껑을 다시 열어서 알코올 증기를 내보낸 뒤, 다시 닫아야 한다.

알코올은 상온에서 액체이긴 하지만 알코올이 너무 적은 상태로 램프가 장시간 방치되면, 증발한 알코올 가스가 램프 안에 고이게 되고, 이게 나중에 램프를 켜는 불꽃에 닿는 순간 한꺼번에 퍽 폭발할 수 있다. 이게 무슨 어지간한 도시가스 누출 사고처럼 실험실을 다 박살 낼 정도의 비극을 부르지는 않겠지만, 램프 주변 사람들을 놀라게 하거나 다치게 할 수준은 된다. 그렇기 때문에 실험실 안전 수칙에는 어딜 봐도 “알코올 램프에는 알코올을 최소한 2/3 이상의 양으로 충분히 채워 둘 것”이 명시되어 있다.

3. 술

알코올은 수산화(OH) 기질을 담고 있는 여러 탄화수소 화합물의 총칭이기 때문에 한 종류만 있는 게 아니라 여러 종류가 있다. 하지만 우리에게 친숙한 건 역시 분자 구조가 간단한 에탄올과 메탄올. 둘 중에서는 메탄올(CH3OH)이 에탄올보다((C2H5OH)도 더 단순한 가장 간단한 구조이며, 이게 알코올 램프를 포함해 연료로 공업적인 용도로 쓰이는 물질이다.

그러나 알코올은 연료로만 유명한 물질이 아니다. 알코올은 그 이름도 유명한 '술'의 주성분이기 때문이다.
일단 메탄올은 그야말로 샤악이나 마찬가지인 맹독성 물질로, 인체에 들어가면 장기를 심각하게 손상시킨다. 10ml남짓만 섭취해도 눈이 멀어 버리고, 30~40ml가 체내에 들어갔다간 죽는다. 주사기나 스포이트 하나를 차지할 만한 적은 양만 먹어도 그 정도의 참극이 벌어진다는 뜻이다. 그리고 독약을 먹고 죽는 건 뭘 먹든 굉장히 고통스러운 죽음이다.

그런데 알코올에 속하는 화합물 중 유일하게 에탄올은 얘기가 좀 다르다. 물론 무슨 식용유 같은 부류가 아니며, 많이 먹어서 몸에 좋을 건 절대 없지만... 그래도 먹는다고 메탄올처럼 저렇게 곧바로 몸이 망가지고 죽는 건 아니며, 신체를 약간 각성시키고 기분을 전환시키는 효과가 있다. 왜 하필 에탄올만 그런 걸까?

물론, 술은 그 약간의 순기능만 논하기에는, 사람을 개로 만들어서 인류에게 역사적으로 끼친 해악도 솔직히 너무 크다. 인류 역사상 세상의 그 어떤 마약보다도 많은 무고한 사람을 죽이고 가정을 파괴한 약물이 바로 알코올이다. 각종 종교라든가 종교 수준의 엄격한 도덕을 요구하는 집단에서 술을 괜히 절대적으로 죄악시· 금기시하는 게 아니다. 술만 처먹으면 괴물로 변해서 부인이나 아이들을 때리는 가장을 둔 가정 구성원의 피눈물은 당사자가 아니면 정말 이해할 수 없을 것이다.

또한 지난 여름엔, 만취 상태에서 정신줄 놓은 어느 운전자가 공항 고속도로에서 시속 거의 180에 가까이 과속을 하다가 앞서 가던 승용차를 추돌시켰었는데 그 사고 기억하시는가? 뒷부분을 추돌 당한 승용차는 화재가 났고, 일가족 네 명이 차에서 빠져나오지도 못한 채 몽땅 몰살을 당했다! 도대체 정체도 없이 고속도로를 멀쩡히 잘 달리던 차가 중앙선 침범 정면충돌도 아니고 추락도 아니고, 어떻게 추돌을 당해서 일가족이 몰살 당할 수 있는지 모르겠다. 재수가 없으면 뒤로 넘어져도 코가 깨지는 게 가능한 정확한 사례가 아닐 수 없다.

보험사들도 바보는 아니니, 음주운전 교통사고는 자해나 다름없다고 봐서(=불의의 사고가 아니라 쌤통이라는 뜻) 자차 보상은 안 해 준다. 대인· 대물 보상은 가해자가 최대 200만원까지는 부담해야 하고, 그 이상 넘어가는 액수만 원래는 보상을 안 하다가 하기 시작했다. 음주운전은 교통사고 처리 특례법에서 열외되는 11대 중과실에 당연히 속하며, 각종 벌금이나 징역 같은 행정 처분에 대해서는 보험사도 면책이다. 아마 저 운전자는 차도 내 기억으로 제네시스이던데 자비로 수리하거나 폐차해야 하고, 면허 취소에 100% 구속에 몇 년간 교도소에서 징역 살면서 술로 인한 패가망신을 경험하게 될 것이다. 그래 봤자 피해자 유족들의 입장에서는 사형에 처해도 분이 안 풀리겠지만.

제아무리 “술은 취하지만 않을 정도로 마시면 된다”라고 술에 관대한 사람이라 해도, 사람의 생명이 왔다갔다 하는 음주운전에 대해서까지 관대한 사람은 없다. 얼굴 안 뻘개져도 한 잔을 마셨으면 한 잔만치 소량이나마 취한 것이고, 자기가 스스로 생각하는 것과는 달리 신체와 머리의 대처 능력이 감소해 있다. 그리고 술을 금지하는 종교는, 동일한 맥락에서 음주운전이 아니라 아예 “음주생활”을 하지 말자는 차원에서 술을 금지하는 거라고 생각하면 된다. 우리 같은 일반인이 먼저 술을 입에도 안 대야, 진짜 알코올 중독자 개차반들도 술을 끊게 될 테니까.

그런데 이놈의 술은 아무리 얄밉다 해도 아주 없앨 수는 없다. 세속의 관점에서 술은 안타깝게도 사회와 문화 전반에 현실적으로 너무 깊게 뿌리박혀 있다. 제아무리 혼자 의롭고 유능한 통치자, 아니 독재자가 나타난다 해도 술은 못 없앤다. 우리나라의 서슬 퍼런 독재 정권도 관습상의 음력 설(구정)은 결국 못 없앴으며, 이스라엘의 선한 왕도 산당들을 못 없앴듯이 말이다. 조선 영조 때의 금주령, 20세기 초 미국의 금주법도 성공하질 못했다. 법으로 금지해도 술 마실 사람들은 결국 어둠의 경로로 구해다 마시면서 사회 구조는 더 망가져 왔다.

술을 금지할 수는 없으니 결국 높으신 분들이 선택하는 방법은, 담배와 마찬가지로 술도 유통을 합법화는 하되 세금을 왕창 매기는 것이다. 이건 꼼수가 아니라 합리적이고 불가피한 선택이다. 그리고 솔직히 술· 담배로 거둬들이는 세금 수익보다, 술· 담배 때문에 건강 망쳐서 발생하는 의료보험 추가 지출, 각종 사고 수습 비용이 여전히 더 “많다”. 술· 담배 많이 소비해 주는 건 국가의 입장에서도 세금 셔틀 애국(?) 행위가 아니다! ㅎㅎ

우리나라도 못 살던 시절엔 의료 소독용 에탄올을 몰래 빼내서 물에다 섞어서 술이랍시고 마시는 일도 있었다. 게다가 의료· 공업용으로 쓰이는 알코올은 주류용 알코올 같은 세금이 붙어 있지도 않으니 일거양득. 그러니 요즘은 그런 짓 하지 말라고 비주류용 알코올은 에탄올이라 해도 색소나 메탄올이나 여타 독극물을 약간씩 섞어서 공급되며, 당연히 사람이 먹어서는 안 된다. 천연 가스는 누출을 감지하기 쉬우라고 냄새 나는 물질이 가미되어 공급되는데 알코올에는 이런 사연과 후처리가 있는 셈이다.

4. 맺는 말

자동차에 기름을 넣고(휘발유)을 넣고, 식용유로 튀김을 만들어 먹다가 액체의 본질에 대해서 생각하고 알코올의 특성에 대해서 생각을 하게 됐고, 이 글까지 쓰게 됐다.
물과 섞이면서 불에도 잘 타는 알코올 같은 물질이 세상에 흔하지는 않은 것 같다. 게다가 그런 부류에 속하는 물질이 하필 술을 만드는 데도 쓰인다니.

알코올은 분명 유용한 연료이며 여러 용도로 쓰인다. 하지만 그 자체의 폭발력이나 화력, 쉽게 말해 옥탄가가 천연 가스나 석유에 비할 수준은 아니라고 한다. 그랬으면 진작에 자동차용 연료로도 개발됐겠지. 어차피 알코올 자체도 공업적으로 합성할 때는 석유의 추출물로부터 만들어지기도 하니 아주 별개의 물질도 아니다.

한국어의 외국어 표기법은 모음이 연달아 오는 것을 싫어하며 특히 장모음을 표기에 반영하지 않는다. 그런데 왜 '알콜'이 아니라 '알코올'이 됐을까? alcohol이라는 단어의 구조에서 볼 수 있듯, 사실 원래 단어는 '알코홀'에 가깝다. 음절이 하나 더 들어있기 때문에 '알콜'로까지 줄이지는 않고 '알코올'로 적는 듯하다.

이 단어는 이례적으로 어원이 아랍어이다. 아랍어에 유난히 '알'자가 많은데, 이는 영어로 치면 the와 비슷한 아랍어의 관사이다. '알코올'의 '알' 역시 같은 용도의 형태소이다. 심지어 알고리즘, 대수학(algebra) 같은 수학스러운 용어들도 어원이 아랍어 내지 아랍의 고유명사이다.

Posted by 사무엘

※ 의식주

인간이 살기 위해 없어서는 안 되는 핵심 요소를 가리키는 용어로 '의식주'라는 유명한 말이 있다.

먼저 의(의복).
사람은 누구나 알몸으로 태어나지만, 아무리 가난한 사람이라 해도 최소한의 옷 한 벌은 무조건적으로 갖추고 있다. 신기하지 않은가?
우주 공간이나 사막이나 극지방 같은 극도의 악천후에서 살지 않는 이상, 벌거벗고 지낸다고 해서 당장 생물학적으로 목숨이 위태로워지지는 않는다. 옷이 무슨 물이나 산소나 음식 같은 물질도 아닌데 말이다.

그럼에도 불구하고 사람은 옷이 없으면 다른 사람들과 결코 제대로 생활할 수 없다. 다른 동물들과는 달리 오직 인간만 말이다. 성경은 그렇게 된 이유를 제시하고 있다.

또한 옷은 착용자의 신분과 격식을 나타내는 역할도 하기 때문에, 옷차림은 문화와 예절에서도 매우 중요한 위치를 차지하고 있다. 특정 상황에서 적절한 의상이 갖춰져 있지 못하면 사회적으로 상당히 난감해진다. 오죽했으면 성경에서도 결혼식 예복을 갖춰 입지 못한 사람이 예식장에서 강퇴 당하는 비유가 등장한다(마 22:11-13). 교리적으로 담고 있는 메시지는 따로 있다는 걸 감안하더라도 말이다.

다음으로 식(음식)이다.
사람은 일차적으로는 물론 체력을 얻어 생명을 유지하기 위해 밥을 먹는다. 그러나 식생활은 단순한 연명 활동을 넘어 입을 심심하지 않게 하고 좋은 기분과 컨디션을 유지시키는 등, 사회생활과 대인관계에서 의외로 매우 중요한 역할을 차지한다. 그래서인지 문명이 존재하는 사회에는 식사 예절이라는 것도 문화에 따라 아주 정교하게 발달해 있다.

인간이 하루에 두어 차례 일과 활동을 중단하고 식사를 해야 하는 건 사실 생산성이라는 관점에서만 보면 비효율과 손해인지도 모른다. 그러나 과학 기술의 발달로 인해 인간에게 필요한 열량과 영양분을 단번에 주입할 수 있는 알약 같은 게 개발된다 하더라도 수천 년간 지속되어 온 인간의 전통적인 식사 관행이 근본적으로 바뀌지는 않을 것이다.

그리고 사실은, 인터넷과 스마트폰이 발명되고 달과 화성으로 우주선을 보내는 오늘날 21세기에조차도 인류의 식량 문제의 해결은 요원하다. 전세계에는 여전히 굶주리는 사람이 많으며, 인간의 식량은 수천 년 전이나 지금이나 여전히 땅의 소출, 다시 말해 농업에 전적으로 의존하고 있다. 그리고 농업은 예나 지금이나 하늘을 바라보고 의지해야만 돌아갈 수 있는 산업이다. 이는 우리에게 시사하는 바가 크다.

끝으로 주(집)이다.
요즘 젊은이들이 집 문제 때문에 결혼조차 엄두를 못 내게 될 정도로 이와 관련된 사회적 병폐가 심각하다. 땅의 절대적인 면적이 좁은 건 아니지만 사람들이 너무 좁게 사는 게 문제이다. 아무 곳에나 덥석 정착해서 사는 게 아니라 여기저기 입지 조건을 안 따질 수가 없기 때문이다.

하지만 성경은 의와 식에 비해서 '주'는 상대적으로 덜 강조하는 것 같다. 산상수훈인 마 6:25라든가 만족을 명령하는 딤전 6:8을 봐도, 의와 식은 명시되어 있지만 주는 누락이다. 예수님 역시 변변한 거처가 없이 사셨다(마 8:20).

이는 다른 이유는 없고, 크리스천들이 세상에서는 영적으로 나그네· 순례자로 산다는 사상이 반영되어서 그런 것 같다. 진짜 본향은 하늘에 따로 있으니까. 집이 그렇게도 중요하다면, 누구 말마따나 성경도 이렇게 기록되었을 것이다. “그러므로 남자가 자기 아버지와 어머니를 떠나 '집을 장만하고,' 자기 아내와 연합하여 그들이 한 육체가 될지니라.” (창 2:24 패러디)

※ 휴대용 식량

그럼 이제부터는 의식주 중에서 '식'에 대한 이야기를 계속하겠다.
전통적으로 인간의 식사는 현장에서 갓 조리된 따끈한 음식을 충분히 가까운 곳(동일 건물)에서 바로 느긋하게 먹는 형태였다. 사실 여건이 허락한다면 그게 가장 바람직하다.

그러나 학교나 일터에서, 혹은 야외에서는 일일이 음식을 조리해서 먹을 수가 없기 때문에 근처에 식당조차 없다면 남는 선택은 도시락밖에 없다. 남의 행동이나 생각을 무슨 일이 있어도 반드시 저지시키고 싶을 때, “도시락 싸 들고 다니면서 말리겠다”라는 관용구가 쓰이는데, 이게 도시락의 어떤 특성을 반영하여 만들어진 표현이겠는지를 잘 생각해 보자. ㅋㅋ

그나마 학교는 이제 전부 급식 체제로 바뀌었고 그걸로도 모자라서 무료 급식까지 시행되고 있다 하니, 학부모의 입장에서는 도시락을 일일이 싸 줘야 하는 부담은 덜게 되었다. 저게 무슨 돈으로 가능하겠는지에 대한 정치적 견해의 차이는 차치하고라도 말이다.

아무래도 도시락은 정식으로 차려 먹는 밥보다야 덜 따뜻하고 덜 신선하며, 원하는 형태의 요리를 마음껏 먹을 수 없다는 제약이 존재한다. 더구나 단순히 점심 한 끼나 그렇게 때우는 정도가 아니라 뱃사람이나 군인의 식단은 어땠을까? 지금 같은 냉동이나 식품 보존 기술이 발달하기 전에는 고기 같은 건 닥치고 소금에 절이는 수밖에 없었을 것이고, 보존성을 위해 맛을 크게 희생한 식품만 맨날 섭취해야 하는 건 당사자들에게 큰 고역과 스트레스였을 것이다.

오늘날 단순 도시락 이상의 위상으로 통용되는 휴대용 식량으로는 다음과 같은 것들이 있다.

1. 비행기 기내식

주행 속도가 느리고 공간이 넉넉한 배야 장거리 여객선에는 주방이 있다. 열차에도 식당칸이 있다. 고속버스는 그냥 휴게소에 들르면 끝..;; 그러나 비행기는 그런 것까지 갖출 여건은 안 되니, 8시간 이상 장거리 노선을 뛰는 여객기에서는 미리 납품받은 기내식을 승객들에게 공급하게 된다.

기내식을 받아 먹는 느낌은 참 독특하다. 비록 비행기에서 직접 조리를 한 음식은 아니지만, 그렇다고 일회용 용기에 달랑 담긴 한솥 도시락이나 예비군 점심 도시락 수준의 '대충'도 아니다. 기내식은 항공사의 이미지와도 큰 관련이 있다 보니, 세계 각국의 항공사들은 기내식을 최대한 맛있고 싸구려 티 안 나고 실제 식사와 비슷하게 만들려 애쓴다.

하지만 공중에서는 단순히 데우는 수준 이상의 조리를 하기가 힘들고, 또 기내에 배기는 냄새와 뒷처리도 고려해야 하기 때문에 기내식을 한없이 고급화할 수도 없는 노릇이다.

기내식은 일반 식사보다 의도적으로 고지방· 고칼로리를 추구하며 제조된다. 사고가 발생했을 때 극단적인 상황에서 승객의 생존율을 높이기 위해서이다. 한 끼가 거의 1000kcal에 달한다니 말 다 했다. 그리고 지상보다 더 기압과 습도가 낮은 곳에서 먹는 걸 염두에 두기 때문에, 입맛을 돋우려고 조미료와 기름도 더 많이 넣고, 더 짜거나 더 달게 만든다. 보기와는 달리, 기내식만 많이 먹으면 건강에 별로 안 좋을 것 같다.

2. 전투 식량

식량의 조달은 식욕이 왕성한 수많은 장정들을 거느리는 군대를 운영하는 데 결코 소홀히 할 수 없는 중요한 요소이다.
군대에서도 주둔 중이나 평시에는 실시간으로 조리된 밥과 국과 반찬을 식판으로 퍼서 먹는 '일반 식사'가 나온다. 그러나 야전에서 훈련이나 작전 수행 중일 때는 역시 portable한 전투 식량이 배급된다.

야전에서 음식을 취급하는 속도는 행군 속도와도 직접적인 관련이 있다. 전투 식량은 휴대성과 보존성이 좋아야 하고 최소한의 물이나 불로 조리가 가능하며, 정 사정이 여의치 않으면 그냥 날로도 먹을 수 있어야 한다. 체력 소모가 극심한 병사들이 먹는 음식이니, 굉장한 고열량이어야 하는 건 두 말할 나위도 없고.

그러고도 전투 식량은 병사들의 입맛에 착 맞고 절대적으로 맛있어야만 한다. 참혹한 전장에서 병사들에게 일말의 즐거움을 선사하고 사기를 진작시킬 수 있는 거의 유일한 수단은, 밥이라도 잘 먹여 주는 것뿐이기 때문이다. 그러니 알고 보면 총포의 기술 발달에 만만찮게, 식품 가공 기술의 발달도 군의 선진화와 현대화에 굉장히 큰 기여를 한 셈이다.

그러니 전투 식량은 앞서 언급한 기내식만큼이나 조미료가 많이 들어가고, 일반인들이 많이 먹으면 비만에 걸릴 요소가 듬뿍 가미된다. 한국군에서는 굳이 야전에 안 나가고 내무 생활을 하는 중에도 이따금씩 정규 식사 대신에 전투 식량이 병사들에게 식사로 지급되는 때가 있는데, 이는 유통기한이 임박한 전투 식량 재고분을 소진하기 위해서이다.

밀덕 중에는 국군이나 미군의 전투 식량을 구해 먹으려고 벼르는 사람도 있다. 일반 음식보다 열악한 여건에서 먹으라고 만들어진 음식을 일부러 찾아서 먹는 이유는, 자신이 민간인이 아닌 군인이라는 특권 의식을 경험하고 싶어서인 것 같다. 전투 식량은 포장과 내용물 등 봐야 할 게 여럿 있기 때문에, 링크를 하나 소개하는 걸로 그림 소개를 대신하겠다.

참고로 전투 식량은 진짜 비상 식량과는 다른 개념이다. 비상 식량은 추락한 비행기의 조종사나, 조난 당한 선원이 구조될 때까지 무인도나 망망대해에서 생존을 위해서 섭취하는 고농축 영양제 같은 음식이다. 단순히 야전에서 작전 수행 중에 먹는 게 아니라, 작전 수행 중에 돌발상황이 불가피하게 생겼을 때 먹는 것이다. 비상 식량은 먹게 될 일이 없기를 바라면서 만들어지기 때문에 오로지 보존성과 휴대성만이 강조될 뿐, 맛은 고려 대상이 아니다.

3. 우주 식량

우주인은 군인만치 그렇게 격렬한 육체 활동을 하지는 않으므로, 우주 식량은 전투 식량만치 고열량을 추구해야 할 필요는 없다. 하지만 무중력 내지 우주 공간에서는 지상에서처럼 음식 맛이 잘 느껴지지 않기 때문에 우주식은 역시 기내식 만만찮게 조미료 도배가 되어야 한다. 또한 무중력 공간에서 인체가 잃기 쉬운 칼슘 같은 영양소를 우주식이 특별히 보충해 줘야 할 필요도 있다.

다음으로 물리적인 형태를 살펴보면, 우주식은 같은 영양 성분이면 무게와 부피를 줄이는 게 중요하다. 그러기 위해서는 진공 건조가 잘 되어야 하며, 그리고 가루· 부스러기가 날리는 형태여서는 절대로 안 된다. 무중력 상태에서 음식 파편이 날리면 심각하게 골치 아파지기 때문. 그런 게 기계 내부로 빨려들어가 기계의 고장을 야기할 수도 있다.

그러니 초기의 우주식은 닥치고 튜브+빨대 형태였다. 먹을 때 입을 크게 안 벌려도 되고, 파편 유출 사고(?)가 일어날 위험이 가장 적었기 때문이다. 그러나 기계와 영양학적 효율을 위해 맛을 크게 희생한 초기의 우주식은 우주 비행사들의 불만을 야기할 수밖에 없었으며, 기술의 발달 끝에 지금은 어지간한 형태의 음식들은 다 우주식으로 개량이 가능해졌다. 김치, 라면, 불고기, 비빔밥, 미역국 같은 것도 모두 우주에서 먹을 수 있다.

우주식은 무중력 상태에서도 음식과 식기가 흩어지지 않게 식판에 이례적으로 벨크로(찍찍이)와 자석이 붙어 있다.
이렇듯, 비행기 기내식과 군대 전투 식량, 그리고 우주 식량은 대체로 영양이 보강되어 있고 휴대성과 보존성이 강화되어 있다는 큰 공통점이 있으면서 세부적인 조건은 살짝 차이가 있음을 알 수 있다.

Posted by 사무엘

※ 셸 프로그램

명령 프롬프트 하나만 달랑 떠 있는 게 아니라 최소한의 GUI를 갖춘 컴퓨터 운영체제에는 셸이라는 게 존재하며, 그 셸을 구동하는 역할을 하는 프로그램이 있다. 그것이 맥 OS는 Finder이고, 윈도우는 95 버전 이래로 Explorer(탐색기)가 셸 역할을 하고 있다.
리눅스는 저 두 상업용 OS만치 셸과 커널이 일심동체인 형태가 아니기 때문에, 딱 떨어지는 단일 셸 브랜드가 없다.

95 이전 3.x 시절에 윈도우 운영체제의 셸은 도스 계열과 NT 계열 모두 그 이름도 유명한 '프로그램 관리자'(ProgMan.exe)라는 MDI 프로그램이었다. 알록달록한 32*32 크기의 16색 프로그램 아이콘들은 초등학생이던 본인에게 굉장히 아름다운 기억으로 남아 있다.

하지만 잘 알다시피 프로그램 관리자는 운영체제의 셸로서는 그리 잘 만들어진 프로그램이 아니었다. 기능이 무척 빈약하고 이것 자체도 여러 프로그램들 중 하나일 뿐, 운영체제 전체를 아우른다는 느낌을 사용자에게 못 줬다. 그룹 안에 다단계 그룹도 못 만들었고..-_-;;
또한 범용적인 파일 관리 유틸리티 기능이 전무했기 때문에 이건 또 '파일 관리자'라는 별도의 프로그램을 통해서 해야만 했다.

게다가 윈도우는 win.ini라는 환경 설정 파일에서 [boot] 섹션에 있는 shell=progman.exe라는 문장을 다른 것으로 고치면, 전통적인 프로그램 관리자 대신에 다른 것으로 셸 프로그램을 손쉽게 대체할 수 있었다.

그래서 윈도우 3.x는 프로그램 관리자를 대체하는 별도의 셸 유틸리티가 존재하기도 했다. 시작 메뉴, 내 컴퓨터, 탐색기 등을 통해 운영체제의 셸로서 explorer.exe의 지위가 확고해진 오늘날에는 이것은 꽤나 상상하기 힘든 모습이다.

당장 떠오르는 건 20여 년 전에 명성을 떨쳤던 Norton Desktop이라는 프로그램이다. 그 당시 도스용 노턴 유틸리티는 버전이 6~7 사이였고 노턴 커맨더라는 도스용 셸도 현역이었는데, 그 회사에서는 한편으로 윈도우용으로도 그런 걸출한 프로그램을 만들었다.

노턴 데스크탑은 화면 보호기도 자체적으로 운영하고 모든 프로그램들의 시스템 메뉴에다 특수한 기능을 추가하기도 했으며, 독자적인 바탕 화면을 구동하면서 윈도우 3.x를 전반적으로 매킨토시와 비슷한 형태로 만들어 줬다. 16비트 윈도우는 오늘날의 운영체제보다는 한 프로그램이 시스템 전체에 영향을 끼치가 훨씬 더 쉽기도 했으니 말이다.

※ 한컴 셸과 윈도우용 아래아한글 초창기 버전

국내에서는 1990년대 중반에 한컴에서 '한컴 셸'이라는 프로그램을 개발한 적이 있다. 화면의 한쪽 귀퉁이에 여러 프로그램들의 아이콘이 나열되는 게 마치 오늘날 맥 OS의 Dock과 비슷했다. 이것으로 기존 프로그램 그룹/폴더에 접근이 가능하고 제어판이나 탐색기도 띄우고, 운영체제를 종료할 수도 있었기 때문에 이것만 있으면 다른 셸 프로그램이 필요하지 않았다.

사진은 아래아한글 3.0b 기준이지만, 내 기억으로 아래아한글 97에도 한컴 셸이 있었다. 윈도우 95/NT4의 셸에 더 친화적인 기능들이 추가되고 버튼들도 90년대 말의 유행이던 flat 스타일로 바뀌었다. (마우스 포인터가 가리키고 있는 버튼에만 3D 테두리가 얇게 생기는 그 형태)

그런데 이 역시 97 초기판에만 있었고, 8· 15 특별판(1998)이나 국제판/기능 강화판(1999)에서는 사라졌다. 윈도우 9x 이래로 탐색기 셸 자체가 기능이 굉장히 강력해졌기 때문에 그때부터는 별도의 셸 유틸리티에 대한 수요와 의미가 없어졌기 때문일 것이다. 특히 IE4와 통합을 이루면서 윈도우 운영체제의 셸은 완전히 환골탈태를 했으니 말이다.

아마 아래아한글 3.0b나 기껏해야 96까지만 해당일 것이다.
그 당시 이 프로그램에는 한컴 셸 동반용으로 추정되는 나침반, 시계, 계산기처럼 워드 프로세서와 직접적인 관계가 없는 액세서리 프로그램도 포함돼 있었다. 지금의 운영체제에서는 제대로 실행이 안 되는 듯한데, 예전에 분명히 돌려 봤던 기억이 난다.

시간이 흐르면서 그런 것들은 거의 다 역사 속으로 사라졌다. 그나마 21세기에까지 장수한 보조 유틸리티는 아래아한글 97과 함께 도입된 '한컴 쪽지'가 유일하다. 그것도 윈도우 7부터는 스티커 메모라는 대체 프로그램이 운영체제 차원에서 생겼으니 필요가 없어진 상태.

옛날에 윈도우용 아래아한글 3.0은 Windows에서도 도도하게 완전 독자적인 GUI와 독자적인 GUI 글꼴, 독자적인 문자 입출력 체계를 쓴 데다, 기술적으로도 Win32s + 별도의 메모리 서버까지 요구하는 등 군계일학 유아독존 포스가 압권이었다.

도스용 아래아한글만 만들던 개발팀이 단기간에 프로그래밍 공부를 얼마나 해야 윈도우 운영체제의 구조를 완전히 마스터하여 방대한 도스용 프로그램을 윈도우용으로 그것도 그런 기술 수준으로 포팅할 수 있었을까? 혹시 공밀레?

이때는 한컴이 금방이라도 독자적인 운영체제를 새로 만들기라도 할 것처럼 보였다. 사실, 비슷한 타이밍 때 나왔던 큰사람의 이야기 7.0 도스용도 도움말을 잘 뒤져 보면 개발팀이 한국형 32비트 운영체제를 자체 개발하겠다는 포부를 밝힌 대목이 있었다. 지금 생각하면 그때 사람들이 참 순진/순수했던 것 같다.. ^^

물론, 윈도우용이 처음 나왔던 3.0, 그리고 에디팅 엔진을 다 갈아엎었던 워디안 때 아래아한글이 버그 때문에 정말 욕을 많이 얻어먹은 건 사실이다. 까일 건 까여야 마땅하지만 그 첫 삽을 뜨기가 얼마나 힘들고 어려웠을지 본인은 프로그래머로서 이해는 한다.

아, 아래아한글 3.0x가 사용했던 그 특유의 GUI 디자인은 이미 아시는 분도 있겠지만 NeXTSTEP에서 따 온 것이다. 아이폰이 나오기 훨씬 전부터 아래아한글이 나름 스티브 잡스 진영에서 만든 디자인을 수용한 적이 있다는 뜻 되겠다. 다만, 메뉴에 카테고리를 구분하는 separator가 없던 것은 좋은 디자인이 아닌 것 같다.

그리고 대화상자의 GUI 컨트롤 중엔, 콤보 상자와 용도가 비슷하지만 콤보 상자보다 더 static하면서 개수가 그리 많지 않은 컨텐츠 중 하나를 선택할 수 있는 '콤보 버튼'이 있다. 예를 들어 글꼴 리스트는 사용자의 컴퓨터에 설치된 글꼴이 무엇이냐에 따라서 dynamic하게 바뀔 수 있지만, 워드 프로세서가 제공하는 문단 정렬 방식 '왼쪽, 중앙, 오른쪽, 혼합' 같은 것은 수가 그리 많지 않으면서 내용이 절대 고정불변이지 않은가. 그런 것을 선택할 수 있다.

또한 스크롤 막대의 좌우, 상하 버튼이 한데 붙어 있는 것도 이 GUI의 특징 중 하나이다.

※ 여담

하긴, 도스 시절에도 셸 유틸리티가 당연히 있었다. 이때의 셸은 윈도우처럼 초보자들을 위한 GUI 기능을 강화한 놈, 아니면 파일 관리 유틸리티에 더 특화된 놈으로 나뉘었다. 후자에 속하는 것이 바로 노턴 커맨더나 MDIR 같은 유명한 프로그램임.

도스 시절에는 아무래도 컴에 대한 접근성이 지금보다는 다소 떨어졌으며, 그래픽 셸을 찾아 쓸 정도의 사람이라면 이미 그래픽 셸이 필요치 않은 파워 유저였다. 그렇기 때문에 도스용 셸 유틸은 GUI보다는 아무래도 매니악한 파일 관리 기능 특화로 더 가는 경향이 있었다.

사실, MS-DOS 자체도 한 4.0부턴가 5.0부터 도스 셸이라는 잉여에 가까운 파일 관리 유틸리티가 있었다. 그냥 밋밋한 UI에 기능도 평범한 편이지만 나름 드래그 드롭 기능이 있었으며, 그리고 하드디스크에 존재하는 모든 파일들을 한 리스트로 뽑아 주는 기능은 윈도우 파일 관리자에도 없고 이놈만의 전매특허였다. 물론, 이건 하드디스크 전체에 존재하는 파일 수가 수천~수만 정도에 불과했던 옛날이니까 가능했던 일이다.

이런 맥락을 이어받아 오늘날의 GUI 시대에도, 비록 운영체제의 기본 셸을 대체하려는 프로그램은 맥이 끊어졌지만, 전문 파일 관리 유틸리티는 건재하다. 토탈 커맨더라든가 넥서스 파일 같은 프로그램이 있다. 여러 단축키를 통해 기본 셸 프로그램보다 원하는 프로그램이나 파일, 폴더에 훨씬 더 빨리 접근할 수 있고, 한 프로그램 안에서 압축 파일도 쉽게 다루고 FTP 연계도 되는 편리한 기능에 대한 수요가 없지 않기 때문이다.

끝으로, 옛날 글들을 보면 알 수 있듯, 난 한동안은 shell을 '쉘'이라고 표기해 왔다. 도스 시절부터 프로그램이나 PC 잡지들이 다 그렇게 표기했기 때문이다. 그때 쉘 대신 셸을 쓴 프로그램은 한글 MS-DOS가 제공하던 '도스 셸'밖에 없었다. 진짜 그거 딱 하나밖에 못 봤다.
그랬는데, 외래어 표기법상 '셸'이 맞다고 하니 이 글부터 시작해서 앞으로는 셸을 쓰도록 하겠다. 틀렸으면 고치면 되지. ㅎㅎ

Posted by 사무엘

1. conime가 conhost로

윈도우 NT 계열 운영체제에는 전통적으로 시스템 디렉터리에 conime.exe라는 자그마한 프로세스가 있었다.
이 프로그램의 타이틀은 Console IME로, 말 그대로 명령 프롬프트(콘솔이라고 불리는)라는 특수한 환경에서 한글이나 일본어의 입력을 지원하기 위해 운영체제와 명령 프롬프트 사이의 통신을 담당하는 듯하다.

conime는 명령 프롬프트를 여러 개 연다고 여러 인스턴스가 중복 실행되지는 않는다. 하지만 한번 실행되고 나면 나중에 명령 프롬프트를 모두 닫아도 종료되지 않고 남아 있는다. 그래서 명령 프롬프트에서 <날개셋> 한글 입력기를 사용하다가 나중에 <날개셋>을 버전업/제거한다거나 하면 conime 프로세스를 강제 종료시켜야 한다고 설치 프로그램이 징징대는 걸 볼 수 있다.

뭐, 작업 관리자로 이 프로세스를 강제 종료시키더라도 운영체제에 악영향은 (전혀) 없다. 나중에 명령 프롬프트를 열면 운영체제가 그걸 알아서 또 실행해 준다.

그런데 윈도우 7에서는 시스템 프로세스 중에 conime.exe가 사라졌다는 걸 본인은 아주 뒤늦게 확인했다. 명령 프롬프트에다 IME 기반 문자 입력을 제공하는 계층이 다른 걸로 바뀌었다는 뜻인데, 어쩌면 이런 변화 때문에 콘솔에서 조합 중인 한글이 덧나는 버그('다다.' 같은)도 덩달아 들어간 게 아닌가 하는 추측도 할 수 있을 것 같다.

관찰해 보니, 윈도우 7에서 콘솔과 관련하여 대신 등장한 프로세스는 conhost.exe이다. 콘솔에서 <날개셋> 한글 입력기를 사용하고 있는 채로 해당 프로그램을 제거하거나 변경하려고 시도하면 conhost 때문에 안 된다는 경고가 뜬다.

그럼 conhost는 cmd.exe 자체와 일대일 대응하는 자매 프로세스냐 하면 꼭 그렇지는 않다.
명령 프롬프트에서 또 cmd라고 치면 그 동일한 창 안에서 명령 프롬프트가 또 구동되는데(exit를 치면 종료 가능한), 이때는 conhost가 또 생기지는 않는다. start cmd라고 쳐서 독립된 콘솔 창이 생성되어야 conhost도 중첩 생성된다. 관계가 이해되시겠는가?

conime와는 달리, 이놈은 명령 프롬프트 창의 인스턴스와 일대일 대응하고, 창이 닫히면 이 프로세스도 종료되어서 IME 프로그램 파일에 걸렸던 lock이 풀린다. 예전에는 콘솔 디버깅 후에는 conime를 강제로 죽여 줘야 했는데 윈7에서는 그럴 필요가 없어진 건 편해진 점이다.

2. 윈도우 7의 kernel32.dll 리모델링

이뿐만이 아니라, 윈도우 운영체제의 시스템 프로그래밍 내지 파일 해킹에 관심이 많은 분이라면 윈도우 7의 under the hood에서 일어난 흥미로운 변화를 하나 알고 있을 것이다.
운영체제의 근간을 이루는 시스템 DLL 중 하나인 kernel32.dll이 내부적으로 여러 분야로 리모델링을 거치기 시작했다는 점이다.

시스템 디렉터리에 가 보면 api-ms-win-core-*.dll이라는 수십여 개의 DLL들이 보일 것이다.
이것들은 kernel32.dll이 제공하는 1000개가 넘는 윈도우 API를 스레드, 힙 메모리, 동기화 오브젝트, 파이프 등으로 세부 분류한 껍데기들이다.

전통적으로 kernel32.dll은 윈도우 9x 계열의 것은 100% 순수 자체 코드로만 이뤄져서 그런지 외부 DLL에 의존하는 게 아무것도 없었다.
NT 계열의 것은 운영체제 커널보다 먼저 로딩되는 ntdll.dll에만 의존도가 있었다. 그리고 그 ntdll이 외부 DLL에 전혀 의존하지 않는 원초 프로그램이었다.

영원무궁토록 변하지 않을 것 같은 kernel32.dll의 내부 구조가 윈도우 7에서 이렇게 바뀐 걸 처음 봤을 땐 무척 흥미로움을 느꼈다.
지금은 그냥 뭔가 더 큰 변화를 위한 준비 수준일 뿐인 것 같은데, 윈도우 8에서는 변화가 얼마나 더 진행될지가 궁금하다.

3. 콘솔의 시각 테마 적용

윈도우 7로 넘어가면서 콘솔에 미묘하게 생긴 재미있는 변화가 또 있다.
전통적으로 명령 프롬프트 창은 윈도우 XP에서부터 도입된 '시각 스타일', 혹은 시각 테마가 적용되지 않는 딱딱한 창으로 처리되었다.

물론, 공용 컨트롤 6.0 매니페스트가 명시되어 있지 않은 구형 프로그램은 각종 컨트롤이나 child window의 테두리가 구닥다리 고전 테마로 나오긴 했지만, 그래도 프로그램의 제목 표시줄 같은 non-client 영역은 모서리가 둥글게 다듬어지기도 하고 최소한의 시각 테마가 자동으로 적용되었다.

그런데 명령 프롬프트는 그런 게 전혀 없이 완전 사각형 모양에 제목도 여전히 윈도우 98/2000식의 그러데이션이고 100% 고전 테마 스타일로 나왔다.
이렇게 100% 구닥다리로 뜨는 프로그램은 (1) 명령 프롬프트, (2) ntvdm 밑에서 돌아가는 16비트 윈도우 프로그램, 그리고 (3) 사용자가 호환성 옵션에서 '시각 테마 사용 안 함' 옵션을 명시한 프로그램 이렇게 세 종류로 한정되곤 했다.

윈도우 비스타/7의 Aero를 사용하면 100% 구닥다리 프로그램도 제목 표시줄이나 창 프레임 자체는 다른 창과 똑같은 형태로 나오기 때문에 이를 구분하기가 쉽지 않다. 고전 테마 말고 Basic 테마를 고르면 한눈에 구분이 가능해진다. 이게 과거의 윈도우 XP Luna와 기술 수준이 동일한 테마이기 때문이다.

그랬는데 윈도우 7부터는 (1) 명령 프롬프트 창도 시각 테마가 적용되는 창으로 바뀌었다. (2)에 해당하는 16비트 윈도우 프로그램은 64비트 운영체제에서는 아예 존재하지도 않으니, 남은 건 이제 (3)뿐이다.

윈도우 비스타/7이 제공하는 한국어/일본어 입력기는 그렇게 시각 테마 열외 프로그램 밑에서 동작하면 가/A, 漢 같은 아이콘이 흰색이 아닌 검은색으로 표시된다. 고전 테마가 아니라 Basic이나 Aero 같은 일반 테마에서 동작할 때 말이다.
본인은 한글 IME의 개발자로서 그 차이를 눈여겨보고 있었고, 그냥 얘네들이 명령 프롬프트에서 동작할 때만 아이콘 글자색을 검게 처리하는가 보다 하고 넘어갔었다.

그랬는데 윈도우 7에서는 명령 프롬프트에서도 글자색이 변하지 않았고, 이에 의문을 느껴 좀 더 관찰을 해 보니 차이를 만드는 요인은 '시각 테마'의 적용 여부라는 사실을 발견하게 되었다.
왜 일부러 그런 차이를 만들었는지는 나로서는 알 길이 없다. 문자 입력기가 응용 프로그램의 시각 테마 적용 여부에 따라 달리 동작해야 할 요인이 있을 리도 없을 텐데 말이다.

자, 다음 그림은 Basic 테마일 때 윈도우 비스타의 명령 프롬프트 화면과 7의 명령 프롬프트 화면이다. 창 프레임의 모양과 입력기 도구모음줄 아이콘의 색깔에 차이를 주목하시길. 내가 지금까지 설명한 것들이 이해가 될 것이다.

4. 도스에서 명령 프롬프트로의 변화

윈도우 9x 계열이야 전용 명령 프롬프트 터미널이라는 게 없이 도스창이 명령 프롬프트의 역할도 겸해 왔다. 그리고 거기서는 아예 도스용 한글 바이오스 프로그램이 따로 쓰이니 conime 같은 컴포넌트는 필요하지 않다.

사실, 16비트 윈도우 시절에 운영체제가 쓰던 전용 실행 파일 포맷(New Executable)은 GUI 환경 전용이었지, 콘솔용은 있지도 않았다. 어차피 똑같은 16비트 기반이고 윈도우 운영체제 자체가 파일 접근 같은 요청은 여전히 도스에다 요청을 해서 처리를 하고 있었으니, 콘솔용 실행 파일을 따로 만드는 건 아무 의미가 없고 필요하지도 않았다.

사실, 매킨토시와는 달리 윈도우 계열 OS에만 존재하는 독특한 ANSI/OEM 인코딩, 코드 페이지 같은 개념은 그 기원을 도스의 명령 프롬프트에서 찾을 수 있을 것이다. 걔네들은 원래 철저하게 1바이트 기반 인코딩을 썼었기 때문이다. 그에 반해 매킨토시는 시작부터가 명령 프롬프트가 전혀 없는 GUI였으니 그런 잔재가 없는 셈일 테고.

5. 윈도우 운영체제의 문자 입력 관련 보조 프로세스

처음에 얘기가 나왔던 conime.exe처럼, Windows에서 문자 입력 프로그램과 관계가 있는 시스템 프로세스를 더 나열하자면...
과거에 윈도우 95~2000/ME까지는 internat.exe라는 프로그램이 있었다. 시스템 트레이에다 현재 선택되어 있는 입력기의 언어와 종류를 띄워 주는 역할을 했다.

그러다가 2001년에 윈도우 XP와 함께 COM 인터페이스 기반의 고급 텍스트 서비스(TSF)가 도입되면서 그 역할은 ctfmon.exe가 대체하게 되었고 그게 오늘날의 비스타/7까지 변함없이 내려오는 중이다. internat이나 ctfmon은 언제나 상주해 있으며, 운영체제를 업데이트하지 않는 한 사용자가 강제 종료할 일도 없는 프로그램이다.

하지만 TSF의 도입 초기이던 오피스/윈도우 XP 시절에는 그게 운영체제의 안정성을 떨어뜨리기도 했기 때문에, 딱히 고급 문자 입력 기능에 관심이 없던 사용자 사이에는 운영체제의 버그를 고친답시고 TSF 기능을 완전히 끄고, 심지어 ctfmon 프로그램을 죽여서 문제를 해결하는 방법이 운영체제 팁으로 공유될 정도였다.

6. MS IME가 등록해 놓는 정체 불명의 유틸리티

MS가 제공하는 한중일 IME는 시작 프로그램에다가 정체를 알 수 없는 이상한 migration 유틸리티 같은 걸 등록하여, 운영체제가 시작될 때 매번 그게 실행되게 해 놓곤 했다. HKLM\Software\Microsoft\Windows\CurrentVersion\Run 아래에 말이다.

일본어나 중국어도 아니고 한국어 IME는 무슨 사용자 데이터를 관리하는 것도 아닌데 도대체 이게 하는 일이 무엇이며 왜 이런 과정이 필요한지는 본인으로서는 알 길이 없다. 그냥 일본어 IME 따라 관례적으로 이런 것도 따라 한 것이기라도 할까?

Posted by 사무엘

옛날에 나의 기억 속에 남아 있는 매킨토시는 가히 꿈의 컴퓨터였다. 여기서 옛날이라 함은 대략 1990년대를 말한다.

그때 우리의 IBM 호환 PC는 아키텍처가 다 공개되어 있기도 했으니 ‘행정 전산망용’ 내지 ‘교육용’이라는 타이틀을 달고 국내 대기업이 로컬라이즈까지 해서(일본의 로컬라이즈 방식을 따라한 것이겠지만) 보급되고 있었다. 그러니 맥에 비해 희귀하다는 느낌이 덜했다. 그리고 이 기계는 그래픽 성능이 맥보다 훨씬 시원찮았다.

그에 비해 매킨토시는 희귀함과 화려함 그 자체였다. IBM PC가 겨우 도스 명령 프롬프트에서 16색, 256색 VGA를 논하는 동안 매킨토시 화면에서는 화려한 GUI 운영체제에다 천연색 사진 그래픽과 각종 전자 출판물 편집 장면이 나오고 있었다. 듣자 하니 매킨토시 컴퓨터에는 텍스트 모드라는 게 아예 없다는데? (물론, PC에서도 텍스트 모드는 컴퓨터 켠 직후에나 잠깐 보이는 과거 유물 잉여가 된 지 오래이지만.)

이미지 출처는 모 블로그.

기계의 모양을 봐도 모니터와 본체 일체형에, 하드웨어와 소프트웨어도 다 무조건 자기네 순정만 쓰이는 게 고급스러움과 간지 그 자체였고, 웬지 지구인이 만든 물건 같지가 않은 티가 역력했다. 엘렉스 컴퓨터가 총판을 맡던 시절에, 매킨토시는 가격도 억소리 나게 크고 아름다웠기 때문에 딱히 전자출판· 그래픽 분야 종사자나 유학파 얼리어답터들이 아니면 쓸 엄두를 내기 어려웠다.

(물론, 그때 컴퓨터 덕질을 안 하고 그 돈 더 모아서 서울 강남에다 집을 사 놨으면, 지금쯤 떼부자가 됐을 거라고 자조 섞인 말투로 회상하는 얼리어답터도 있다고 카더라)

매킨토시 진영은 서비스 구리고 하위 호환성에 자비심 없는 것으로도 잘 알려져 있다. ‘윈텔’ 진영과는 성향이 달라도 너무 다르다. MS 윈도우야 API의 하위 호환성은 정말 경악스러울 정도이고, x86 아키텍처 자체도 호환성에 목숨 거느라 그 지저분함이 말도 못 할 수준이지 않던가.

그런데, 그 간지 최강 귀족 컴퓨터에서 돌아가는 맥 OS도, X 이전의 클래식 버전은 사실 선점형 멀티스레딩도 없이 기술적으로는 윈도우 95보다도 뒤쳐진 물건이었다고 한다.
하긴, 어렸을 땐 난 시커먼 도스 프롬프트에서 그 허접한 윈도우 3.1이 시동되는 모습만 보고도, 화려한 그래픽에 동심이 매료되고 가슴이 두근거렸는데 하물며 매킨토시는 어땠을까?

그로부터 세월이 흘러 매킨토시 진영의 역사상 있었던 대단히 큰 사건들을 요약해 보자면 다음과 같다. 200x년대에 굵직한 일들이 많았다.

1. 엘렉스 대신 애플 코리아가 직접 한국으로 진출 (1999)
2. 맥 OS X 출시 (2001)
3. 인텔 아키텍처 기반으로 전향 (2005-2006)
4. 아이폰의 흥행 대성공(과 국내에 드디어 시판) (2007, 2009)
(5. 그리고 아마, 잡느님의 사망. 2011)

매킨토시가 옛날에 비해서는 정말 가격도 많이 떨어지고 보급도 많이 된 건 사실이지만, 서비스의 품질은 오히려 엘렉스 시절보다도 못한 면모도 있다는 성토가 여전히 나돈다.
또한 최강의 장사꾼 기질로 한글화를 꼬박꼬박 친절하게 하는 MS 윈도우 진영과는 달리, 맥 진영은 소프트웨어의 한글화도 좀 투박한 구석이 있다. 기본 제공되는 한글 서체의 품질이 저질이라고 폭풍처럼 까여 온 것 역시 그런 맥락일 테고.

맥은 하드웨어 배경이 완전히 다르다 보니 640KB 메모리 제한이라든가 16비트/32비트 썽킹 같은 흑역사는 없다.
다만, PowerPC에서 x86으로 갈아탄 것은 워낙 여파가 너무 큰 변화이기 때문에 제작사인 애플에서도 어떤 형태로든 호환 레이어를 제공하지 않을 수가 없었다. 그래서 CPU 에뮬레이터인 '로제타'를 만들고, 그리고 한 프로그램 바이너리에 아예 x86 코드와 PowerPC 기계어가 같이 들어있는 Universal binary라는 포맷도 제정했다.

물론 지금은 시간이 충분히 지났기 때문에 Snow Leopard던가 Lion이던가 버전부터는 PowerPC 지원은 완전히 끊겼다. 그리고 Universal binary는 PowerPC/x86이 아니라 같은 x86 계열 안에서 32비트와 64비트 코드를 동시에 내장하기 위한 용도로 쓰이고 있다. 앞으로는 ARM과 x86(-64) 사이의 동시 지원이 필요해질 듯.

가만히 생각해 보면 이게 옛날에 MS가 윈도우 NT 시절에 제정한 Portable Executable과 일맥상통하는 개념이 아닌가 여겨진다. 당시에 윈도우 NT는 x86, PowerPC 등 다양한 CPU를 target으로 개발되고 있었기 때문에, 비록 기계어 코드는 공유를 못 하더라도 동일한 헤더로 실행 파일 바이너리들을 식별하고 관리 가능하게 할 필요는 있었다. 하지만 정작 PE는 한 바이너리에 다양한 아키텍처의 기계어 코드를 한꺼번에 담는 건 지원하지 않는다.

세월이 흘러 지금이야 PC의 역량도 충분히 매우 발전하여, 매킨토시를 사실상 다 따라잡은 지가 오래이다. (그런 비주얼 쪽의 발전을 주도한 건 다 게임이라 해도 과언이 아닐 듯.) 기계어까지 가상 바이트코드로 대체하려는 발칙한 시도가 가능해졌을 정도이니 컴퓨터가 얼마나 성능이 좋아진 셈인가?

그랬는데, 지금 나는 그 시절의 매킨토시보다 훨씬 더 성능이 좋은 매킨토시 노트북 PC를 아무렇지도 않게 갖고 다니며 쓰고 있고, 사실 그 기계로 맥OS보다 윈도우를 여전히 훨씬 더 많이 쓰고 지낸다. 격세지감이 아닐 수 없다!

(폭풍간지 사과 무늬...ㅋㅋ)

Posted by 사무엘

한국

• 반도에 자리잡은 유일한 분단 국가. 징병제. 분단되지 않고 남북을 합쳐도 인구나 면적이 CJK 중 가장 작은데 하물며 지금은.. 안습
• 한글! (한자어에 대한 의존도가 높지만 이례적으로 한자는 거의 안 쓰는 아주 특별한 국가)
• 미국과 비슷한 대통령 직선제
• 성탄절이 유일하게 공휴일임. 넘사벽급의 교회 인프라
• 과학 분야의 노벨 상 수상자가 유일하게 전무-_-함

중국

• 압도적인 영토 면적과 인구. 대륙의 기상-_-
• (명목상의) 공산당
• 고립어. 한국어나 일본어와는 달리 S+V+O형 언어
• 국기의 모양도 한국-일본보다는 이질감이 더 큼
• 훨씬 더 강경한 마약 단속. 많은 사형 집행

일본

• 섬 나라. 한국보다 남쪽에 있지만, 북쪽 끝도 북한을 넘어 러시아와 만날 정도로 영토가 은근히 넓다.
• 유일하게 좌측통행, 협궤, 그리고 110V 전압 (근대화· 산업화를 일찍 한 흔적이다. 얘들도 아주 장기적으로 승압을 찔끔찔끔 하고 있다고는 함)
• 전범 국가. 정규군 대신 자위대
• 세계에서 가장 복잡한 축에 드는 문자 체계. 세로쓰기 (하지만 일본에서도 젊은 세대들은 점점 가로쓰기에 더 익숙해지고 있다고 함)
• 영국과 비슷한 입헌 군주제

결국 한국과 일본이 비슷한 건 사회주의 체계가 아닌 것과 언어 구조요,
한국과 중국이 비슷한 건 차량 통행 방향이나 전압 같은 산업 인프라 및 일본에 대한 피해의식이며,
일본과 중국이 비슷한 건 한자 의존도 정도로 요약된다.

Posted by 사무엘

1. 병시나 산소 / 문과 출신인 나도 알고 있음

2007년 말, 디씨를 통째로 빵터지게 만들었던 유럽연합 님의 희대의 말실수 사건. 잠이 좀 덜 깬 채로 댓글을 달았는가 보다. 더 이상의 자세한 설명은 생략한닼ㅋㅋㅋㅋㅋㅋ.
지금은 검색을 해 보면 저 원본 스샷보다도, H2O가 산소라는 걸 풍자하는 대사가 담긴 온갖 만화 패러디 그림들이 더 많이 나돌고 있다.

요즘은 최악의 올림픽 오심 병크 때문에 H2O도 모자라서 1초의 정의마저 바뀌게 생긴 듯. 화학에 이어 물리까지

2. 안드로메다 행 열차

2008년 7월경에 서울 메트로 소속 4호선 모 전동차에서 직원이 LED 전광판을 테스트하느라, 승객이 보고 있는 줄도 모른 채 순간 저런 문구를 집어넣어서 승객들을 뒤집어 놓았다.
안드로메다는 어느 샌가 사람들이 개념을 냅다 보내 버리는 안습한 장소...;;로 전락해 있다.

3. 섯!

정지도 아니고, 멈춤도 아니고, STOP은 더욱 아니고, 북한에서는 교통 표지판에 저렇게 써져 있다고 한다..;;

비문도 아니고 의미 전달에 아무 결격사유가 없는 표현이 남한에서는 황당함과 웃음을 선사하는 이유는 언어학에서는 격식의 충돌 때문으로 분석한다. 북한이 평소에도 자기 특유의 우악스럽고 과격한 언어 활용을 공식 매체에서 즐겨 하기 때문에, 이를 풍자하여 “천하의 개쌍놈들” 합성 짤방이 나돌기도 하는 것이고 말이다.

4. 개미를 죽입시다 개미는 나의 원수

초등학생이 어지간히도 슬프고 화가 났던가 보다. 진정한 적개심(...)을 느낄 수 있는 글인데 읽다 보면 웬지 웃긴다. 이것도 이제는 왕년의 “나일록 방석 갓다노라. 안 그러면 방법한다. 방법하면 손발리 오그라진다” 급의 전설이 되어 가는 중. 그나저나 크리스천은 모름지기 “육신을 죽입시다 육신은 나의 원수”를 외쳐야 할 것 같다.

5. 어둠의 다크에서 죽음의 데스를 느끼며

무슨 영단어 암송시도 아니고...
왕년에 이 외수 씨를 경악하게 만든 전설의 시라고 한다.

가만히 읽어 보면, 성경 출애굽기에서 이집트의 아홉째 재앙인 어둠 재앙 같은 느낌이 들지 않는지? -_-;;
그때 이집트 사람들은 진짜 어둠의 다크에서 죽음의 데스를 느끼며 이 재앙이 길이길이 가슴속의 하트에 기억될 리멤버가 되었지 싶다. 뭐, 서풍은 메뚜기 재앙을 끝낼 때 불었던 바람이긴 하지만.

지금도 “어둠의 다크”, “개미를 죽입시다”, “병시나 산소” 등은 구글이나 네이버에서 자동 완성까지 되는 유명한 문구이며, 각종 웹툰에서 패러디까지 되고 있다.

6. 김 성모 만화를 너무 많이 본 사람이 작성한 약관

사람들이 어디 가입할 때 약관을 도통 안 읽는 것만큼이나
대부분의 크리스천들도 성경에 관심이 없으며 안 읽는다. (어쩌면 자기네 교회 헌법에도)

그래서 수백여 군데의 사이트에 저런 '빅장을 구사하고 뼈와 살이 분리되는' 약관이 한때 복붙으로 나돌았으며,
그런 것처럼 열세 군데가 삭제되고 6만여 군데가 변개된 성경이 오히려 진짜 행세를 하면서 버젓이 나도는가 보다.

Posted by 사무엘

1.

<날개셋> 한글 입력기는 잘 알다시피 글쇠배열 수준을 넘어서 한글 조합 로직을 완전히 외부에 expose하고 사용자가 이를 입력 옵션의 일부로서 마음대로 고칠 수 있는 유일한 한글 입력 프로그램이다.

한글 조합 로직은 전산학에서 오토마타라고 불리는 '정규 문법'(regular grammar)으로 흔히 모델링되며, 보통은 그 알고리즘이 해당 한글 입력 프로그램의 소스 코드 내부에 복잡한 switch문의 형태로 하드코딩되어 있다. 그러나 <날개셋> 한글 입력기는 그렇지 않으며, 아예 C언어 수식의 문법 형태로 오토마타를 사용자가 일일이 지정이 가능하다.

정규 문법은 옛날에 1996년도 한국 정보 올림피아드 경시부(본인이 그 시절에 정올 공부를 한 세대여서.. ^^)에서 출제되었던 잠수함 코드 식별 문제와 같은 차원의 난이도이다. 주어진 규칙대로 상태를 쭉쭉 switch해 나가다가 코드가 yes로 끝나면 잠수함이고, 그렇지 않으면 noise이다. 한글 입력 오토마타도 그런 수준이라는 뜻이다.

첨언하자면, 이것보다 한 단계 더 복잡한 차원의 문법은 그 이름도 유명한 문맥 자유 문법(CFG)이다. 이제는 다단계의 여닫는 식별 부호를 재귀적으로 처리할 정도가 되어야 하고, 제대로 파싱하기 위해서는 스택이 필요하다. 여기서 스택은 한글 입력 순서를 기억하는 그런 스택이 아니라, 각 재귀 단계별 상태를 기억하기 위한 스택이다. 정규 문법이 Windows의 INI 파일 정도의 복잡도라면, 문맥 자유 문법은 XML 정도 된다고 보면 된다.

전산학 전공자라면 데이터 구조 시간에 복잡한 괄호와 연산자가 들어간 수식을 처리하는 프로그램을 만든 적이 있을 텐데, 그게 바로 간단한 문맥 자유 문법을 인식하는 프로그램을 구현해 본 것이다. 그러나 한글은 초-중-종성으로만 구성되지 '초성-여는 중성-종성-닫는 중성'이라든가, '여는 초성-중성-여는 종성-닫는 종성-닫는 초성' 처럼 글자 자체가 재귀적으로 이상하게 전개되는 형태는 아니므로, CFG가 아닌 정규 문법만으로 표현이 충분히 가능하다.

사람이 다루는 자연어든, 컴파일러가 다루는 프로그래밍 언어 소스가 아니어도, 컴퓨터라는 계산 기계가 인식과 생성과 처리 가능한 모든 파일 포맷은 결국 이런 문법으로 formal하게 생성 규칙을 나타낼 수 있으며 그럴 수밖에 없다. 텍스트 파일이든, 그래픽 포맷이든, 심지어 기계어 코드의 포맷이든 말이다. 그래서 오토마타 이론은 전산학에서 매우 중요하게 다루어진다.

2.

다시 본론으로 돌아와 한글 입력기 얘기를 계속하겠다.
한글 입력기도 구현체가 제각각이기 때문에 프로그램마다 동작 방식이 대동소이한 차이가 있었다. 예를 들어 “중성+종성 형태의 미완성 한글의 입력이 가능한가? 그리고 세벌식의 경우 초성+종성 미완성 한글도 입력 가능한가?” 하는 것 말이다. 오토마타는 바로 이런 세밀한 로직을 바꿀 수 있다.

아래아한글은 도스용 3.x까지만 해도 그런 게 가능하지 않다가 윈도우용으로 넘어오면서 어느 샌가 미완성 한글의 표현이 가능해졌으며, 특히 97 때는 전무후무하게 초-종-중 순의 입력도 가능해서 아주 초보적인 형태의 모아치기까지 지원했었다. 그게 워디안 이후부터는 다시 없어졌지만 말이다.

<날개셋> 한글 입력기는 그런 것들을 구분하기 위해서 일반적인 이어치기 오토마타뿐만이 아니라 미완성 한글의 입력을 불허하는 오토마타도 따로 갖추고 있다.
PC 환경이 도스에서 윈도우로 넘어가면서 한글 코드의 주류도 조합형에서 완성형으로 넘어갔다. 완성형은 구조적으로 낱자의 초성과 종성을 구분하는 게 불가능하고 미완성 한글도 표현할 수 없기 때문에, 한글 입력 오토마타도 그에 맞춰서 설계되는 게 불가피했다.

그런데 맥 OS가 제공하는 한글 입력기는 동작 방식이 흥미롭다. 두벌식은 별 차이가 없는데 MS의 한글 입력기와 큰 차이를 보이는 부분은 세벌식이다.
오토마타가 '미완성 한글을 허용 안 하는 이어치기'의 변종이다. 초성과 중성의 단독 입력은 허용하지만, 종성 단독이나 여타 미완성 한글의 입력은 아예 무시하여 허용하지 않는다. 또한 받침 ㄲ, ㅆ은 ㄱ, ㅅ의 연타로 입력을 못 하고 반드시 한 타로만 쳐야 한다.

입력 무시는 <날개셋> 한글 입력기의 오토마타에서 -1이라는 음수 상태로 정의되어 있으므로 이런 입력 로직도 <날개셋> 한글 입력기로 어렵지 않게 구현할 수 있다.

0 → A ? 1 : B ? 3 : C ? -1 : 0
1 → A ? 1 : B ? 2 : C ? -1 : 0
2 → B ? 2 : C ? 4 : 0
3 → B ? 3 : C ? -1 : 0
4 → C ? 4 : A|B ? 0 : -1

초기 상태에서는 종성 C만 -1로 빠지게 하여 무시하면 된다. 그리고 초성이 입력된 상태인 1번 상태에서도 C만 무시하면 된다.
초성과 중성이 모두 입력된 2번 상태에서만 종성의 입력이 허용되며, 이 경우 오토마타는 4번 상태로 가게 된다.
중성만 단독으로 입력된 상태인 3번에서도 중성만 동일 상태로 받아들이면 되고 종성은 여전히 무시한다. (C ? -1: 0)

끝으로 문제가 되는 건 초-중-종성이 모두 입력된 4번 상태이다. 받침 ㄴ+ㅎ=ㄶ 같은 결합은 계속 허용해야 하지만 더 결합할 수 없는 받침은 입력을 무시해야 한다. 그리고 초성과 중성은 다음 글자로 입력을 받아들인다. 이 상태를 어떻게 표현하면 좋을까?

<날개셋> 한글 입력기는 오토마타로부터 양수 상태값을 얻어서 결합 가능 승인은 받았지만 실제로는 낱자 결합 규칙이 존재하지 않아서 추가 결합이 불가능해진 낱자가 발견될 경우, 성분 변수 A~C에다가 모두 0을 집어넣어서 해당 상태에 대한 오토마타 함수값을 다시 구한다. 그렇기 때문에 C에 값이 있을 때는 일단 4번 상태를 계속 유지하게 하되, 초성이나 중성에 값이 있으면(A|B) 다음 글자로 넘어가서 조합을 진행하게 하고(0), 진짜로 세 변수가 모두 0일 때만 -1로 조합을 무시하게 하면 된다.

요컨대 초성과 중성만 단독 입력이 가능하고 정확하게 초-중-종 순서를 따르지 않은 unexpected 종성은 입력을 무시하게 한 오토마타인데, 이것도 좀 오래 써 보니 오타 방지 차원에서는 나쁘지 않은 것 같다.

3.

이제 오토마타 얘기 말고 다른 기술적인 얘기로 넘어가겠다.
맥 사용자라면 이미 충분히 아시겠지만, 매킨토시 컴퓨터는 별도의 한/영이나 한자 키가 없기 때문에 한/영 전환이 cmd+space이고, 한자 변환은 opt(alt)+enter이다.

다만 약간 불편한 점은, 두벌식이든 세벌식이든 겹받침을 입력하는 방법이 없다는 것이다. 두벌식에서 ㄱ+ㅅ을 누르면 둘은 따로 떨어지며, 세벌식은 아예 겹받침 단독 입력이 불가능하기 때문이다.

초성+한자로 특수문자를 입력하는 기능도 맥에는 없다. 일반 PC에서는 그야말로 도스 시절에서부터 존재한 오랜 전통임에도 불구하고, 맥은 그런 것의 영향을 지금까지 전혀 받지 않은 채 지내 왔다니 놀라울 따름이다. 전/반각 모드 같은 것도 맥에서는 찾을 수 없다.

윈도우에서는 두벌식/세벌식이 한 한글 IME 내부에서의 설정치로 존재해 왔지만 맥은 각각의 벌식이 마치 영문 쿼티/드보락처럼 별개의 입력 방식으로 다뤄진다. 어찌 보면 이게 더 직관적인 디자인인 건지도 모르겠다. 그래서 입력 환경 설정 대화상자에는 글자판을 선택하는 옵션은 없으며 backspace 키의 동작 방식 같은 것만 있다.

Windows는 95 이래로 조합 중인 한글을 깜빡이는 네모 커서로 나타내는 관행을 도스 시절 프로그램으로부터 확실하게 도입하여 정착시켰다. 이 당연한 관행이 3.1때까지만 해도 없었기 때문에, 한글을 조합 중일 때 커서는 그냥 해당 한글의 앞에 똑같은 길쭉한 형태로만 보였다. 당시 윈도우 3.x용 MS 워드 6.0이 예외적으로 IME를 자체 처리하여 네모 커서를 자체 구현하던 수준이었다.

그에 반해 맥은 조합 중인 한글을 그냥 일본어나 중국어의 조합을 표시하듯이 밑줄로 처리한다. 즉, 맥에서는 깜빡이는 네모 커서를 볼 일이 없다는 뜻. 사실, 깜빡이는 네모 커서는 도스 시절 이래로 오랫동안 봐 왔기 때문에 심리적으로 편하기는 하지만, 한글 조합을 두 글자 이상의 길이로 표현하는 가능성을 차단했다는 큰 제약도 존재한다.

그래서 MS 운영체제에서는 전통적으로 한글 조합을 단어 단위로 잡는 기능이 존재한 적이 없다. 한자 입력할 때를 빼면 사실 전/반각만큼이나 별로 필요하지도 않은 것도 사실이긴 하지만 말이다. 그 반면 맥에는 그 옵션이 있다.

이런 점들을 감안하면, 한글 입력 하나를 두고도 맥과 윈도우는 문화가 상당히 다름을 알 수 있다. 차이는 이것으로 그치지 않는다. 오류가 없는 100% 정확한 세벌식 최종 글자판이 윈도우에서는 무려 비스타와 오피스 2007 타임라인에 와서야 겨우 제공된 반면, 맥에서는 공 박사님의 영향력 덕분인지 그야말로 OS X도 아니고 20세기 클래식 시절부터 당연히 기본 제공되어 왔음도 감안할 필요가 있다.

Posted by 사무엘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘