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

1. 아날로그 텔레비전의 국산화

1975년 12월에 현대 자동차에서 최초로 고유 모델 승용차인 포니를 만들어 낸 건 잘 알려진 사실인데,
우리나라에서 자동차 말고 가전 분야에서 이에 필적하는 발전을 선도하던 기업은 바로 지금 LG 전자의 전신인 금성사였다.
라디오를 생산해 낸 노하우를 바탕으로 1966년 8월에 최초로 흑백 브라운관 텔레비전을 개발· 생산하는 데 성공했기 때문이다. 상당수의 부품을 국산화하고서 말이다.

이 TV 한 대가 지금으로부터 50여 년 전의 물가로 6만 원이었다. 이건 자료를 찾아 보면 엥겔 지수 자체가 더 높던 그 시절에 쌀 무려 20여 가마니의 가치를 상회하는 엄청난 가격이었다고 한다.
그러니 그 당시의 서민 경제력으로는 TV를 집집마다 장만한다는 건 불가능했다. 마을 이장님 집에서나 마을 사람들이 옹기종기 모여서 TV를 시청했다는 걸.. 개개인이 전화기와 DMB를 들고 다니는 지금으로서는 도저히 믿기 어려울 것이다.

참고로 금성사는 그로부터 11년 뒤인 1977년에야 컬러 TV를 만들어 냈다. 그 당시에 국내 최고의 전자공학 공돌이들이 머리를 짜내서 만들었을 것이다. 하지만 컬러 TV가 대세가 된 뒤에도 휴대용 소형 텔레비전이나 아파트 현관 인터폰 같은 CCTV는 가격이나 기술 문제 때문인지 여전히 흑백이 많이 쓰이곤 했다.

한 점에서 평면 화면을 표현하는 것이 쉬울 리가 없으니 초창기의 텔레비전은 아주 그냥 동그란 구면이었다. 컬러화를 이루고 채널 다이얼을 버튼으로 바꾸고 리모콘도 추가하고.. 이 모든 것 이상으로 텔레비전 관련 기술자들이 당면한 최대 과제는 당연히 이 면을 평평하게 만드는 것이었다. 그 덕분에 1990년대 중후반엔 완전평면 슈퍼플랫 브라운관 어쩌구 하는 경지에 도달했다. 크기도 30~40인치까지 커졌다. 한편, 컴퓨터 모니터는 큰 게 20몇 인치대.

하지만 공간 복잡도가 무려 O(n^3)에 달하는 크고 무거운 브라운관으로는 그 이상 대형화는 도저히 무리였다. 아울러 재래식 아날로그 TV 규격의 해상도만으로는 화질도 대형 화면에 적합하지 않았을 테고.
오늘날의 스마트폰 같은 초소형 컴퓨터가 출현 가능해진 데엔 단순히 집적도가 높은 고성능 CPU뿐만이 아니라 얇은 디스플레이 소자도 큰 기여를 했음을 부인할 수 없다.

이거 발전을 예상을 못 했기 때문에 옛날에 21세기를 상상했던 공상 과학 매체를 보면, 사람들이 첨단 기술이랍시고 텔레비전 전화로 상대방 얼굴을 보면서 통화를 하는데, 화면은 둥~그런 브라운관 화면인... 지금으로서는 참 웃지 못할 장면이 남아 있는 것이다. ㅎㅎ

이제 전세계에서 브라운관 모니터의 생산 중단이 임박했다.
브라운관 모니터에 떠 있는 운영체제로 어울리는 물건은 Windows XP 정도가 마지막이지, 2000년대 중반인 Vista와 그 이후부터는 영 어울리지 않는다. 사실 플로피 디스크도 새로 만들어지는 PC에서는 이때쯤부터 완전히 자취를 감췄고 말이다.

이와 더불어 한때 한창 유행했던 컴퓨터 모니터의 '보안경', 그리고 전원을 켜면 화면이 서서히 fade in으로 화면이 나타나던 장면 따위도 과거의 아련한 추억이 돼 간다.
그리고 컴퓨터에서는 VGA D-sub 단자도 점점 쓸 일이 없어지는 중이다. 한때는 기술적인 한계 때문에 영상 신호를 디지털 대신 아날로그 방식으로 보냈지만 지금은 다시 DVI 같은 디지털 규격으로 회귀한 지 오래이다. LCD는 브라운관보다 근본적으로 더 디지털 친화적인 방식이기 때문이다.

2. 테스트 패턴

옛날엔 그래픽 모드로 진입하는 도스용 프로그램들은 실행 전에 비디오 모드를 묻거나 "이 글자가 잘 보이면 F5를 누르세요" 요청을 하는 게 있었다.
그리고 옛날에 아날로그 영상물에서 이것과 비슷한 역할을 하던 물건은 바로 테스트 패턴이다. 현재 텔레비전이 신호를 잘 잡았고 색상을 옳게 표시하는지 테스트하기 위해 나타내는 색깔띠들이다. 흑백 명암과 RGB 각 축의 극단에 해당하는 고채도 색상들 조합이 쭈욱 나열돼 있다. 이것들도 아무렇게나 만들어진 게 아니라 다 규격이 있다.

왼쪽과 같은 단순한 색깔띠는 텔레비전보다는 비디오 테이프를 틀었을 때 맨 앞부분에서 잠깐 보였을 것이다. SMPTE Color bar (Society of Motion Picture and Television Engineers)라고 불린다.

오른쪽의 좀 더 복잡한 형태의 색깔띠는 필립스 전자에서 만들었는지 PM5544라는 코드명이라고 불린다. 옛날에 텔레비전 방송국에서 정규 방송을 시작하기 15~20분쯤 전부터 '화면 조정'이라는 명목으로 송출하곤 했다. 배경 위로는 현재 시각과 금일 방송 순서 같은 것도 떴다.
화면 조정 중일 때는 BGM이 흘러나오는 편이지만, 정규 방송이 끝난 뒤에는 그냥 무음이나 단순 싸인파 소리만 들어있기도 했다.

디지털 통신에 온갖 복잡한 규격과 프로토콜이 존재하고, 아날로그 비디오 테이프에도 VHS나 베타맥스 같은 상반된 규격이 있었듯이..
아날로그 영상 신호 송신 방식도 하나만 있는 게 아니다. 크게 NTSC와 PAL이라는 방식이 있다. 우리나라는 NTSC를 쓰지만 북한은 우리와 다른 PAL을 사용하며, 이는 아마 의도적으로 일부러 다르게 정한 게 아닌가 싶다.

처음에 흑백 TV를 기준으로 신호 체계를 만들었다가 나중에 컬러 방식이 개발되었을 때는.. 기존의 흑백 TV는 여전히 자기가 인식하는 흑백 신호만 수신이 가능하게.. 즉 하위 호환성이 유지되게 흑백 TV가 사용하지 않는 주파수대에 컬러 신호가 교묘하게 추가되었다고 한다.
컬러 TV의 입장에서는 걍 RGB가 더 직관적이겠지만, 흑백 신호의 strict superset을 구성할 수 있는 HSL 방식으로 색을 표현하기도 하고 말이다. 어, 그러고 보니 JPG 압축 과정에도 색깔을 RGB에서 HSL로 바꾸는 게 있었지 싶은데?

뭐, 본인은 전자공학 쪽은 문외한에 가까우며 지금은 구닥다리 아날로그 TV 송신이 진작에 중단됐을 정도로 세월이 흐르기도 했지만, 이런 쪽 이야기가 은근히 흥미롭게 들린다. 디지털 고화질 TV의 등장과 함께 화면의 종횡비가 와이드로 바뀌었다. 아울러 컴퓨터 모니터도 이 추세를 따랐는지 16:9 와이드가 대세가 된 지 오래이다.

3. 옛날 방송과 지금 방송의 차이

지금은 TV 뉴스에서 볼 일이 없어진 코너가 최소한 둘 있는데, 하나는 아침 7시 뉴스를 하기 전에 나오던 편인 "세계 뉴스"이고 다른 하나는 저녁에 나오는 편이던 "주식 시세"이다. 이유는 당연히 정보의 바다 인터넷의 등장으로 인해 공중파 텔레비전 방송에서 굳이 그걸 선별해서 틀어 줄 필요가 없어졌기 때문이다. 날씨처럼 범국민적인 정보라면 모를까, 그런 건 그냥 필요한 사람이 알아서 찾는 게 더 빠르다.

온갖 기업들의 주식 시세와 함께 상하 ▲▼ 삼각형들이 뜨고 있을 때는 꽤 다양한 고퀄의 BGM들이 많이 흘러나왔던 걸로 기억한다.

그리고 밤 9시 뉴스를 하기 전에 흘러나오던 시보도 정말 드라마틱하게 변해 왔다.
1980년대까지만 해도 옛날에는 파란 배경의 추레한 아날로그 시계 CG에다가 PC 스피커 스타일의 기계음 일색이었다.
당장 "귓속에 도청장치가 있습니다" 방송사고 동영상을 찾아 보시기 바란다. 그 시절에 9시 시보가 어떠했는지를.

그러다가 시계 그림은 점점 휘황찬란한 보석 CG로 바뀌었고, 광고의 비중이 커졌으며 2000년대 이후부터는 그냥 아날로그 시계 그림과 긴 차임벨 음향 자체가 삭제되었다. 영상 컨텐츠의 90% 이상은 광고이고.. 딱 정각 3초 전에 시각이 잠깐 나타났다가 사라지는 형태가 됐다. 이것이 시보 영상의 변천사이다.

4. 대기업에서 옛날에 개발한 소프트웨어

이제 좀 더 보편적인 옛날 이야기를 해 보자면..
옛날에는 금성과 삼성(!!)뿐만 아니라 대우와 현대도 자동차뿐만 아니라 '전자 제품'을 생산했고 심지어 소프트웨어를 개발하기도 했다.
특히 금성사의 경우 '하나'라는 텍스트 모드 워드 프로세서를 만들어서 한때 관공서 표준으로 쓰이기도 했고 '하나 스프레드시트'를 만든 적도 있다. 나중에 Windows용으로는 '윈워드'라는 워드 프로세서를 만들었지만 그건 망한 듯하고.

전자 제품도 함께 만드는 대기업에서 운용하는 소프트웨어 팀에서는 요즘 뭘 만드는지 모르겠다. 쟤들은 일단은 그래도 하드웨어에 같이 들어가는 소프트웨어를 만들지, 독립적인 패키지 프로그램이나 온라인 게임 같은 걸 만들지는 않을 것이다. 그런 분야는 이미 시장이 다 포화했으며, 대기업이라고 해서 기성 IT 특화 업체들을 이길 수 있는 건 아니니까. 그나마 삼성 전자의 훈민정음만이 좀 오래 간 정도이다.

5. 옛날의 경제 구도

끝으로, 우리나라의 옛날 상황에 대해서 단순히 못 살고 못 먹던 시대라는 막연한 편견 이상으로 진지하게 고려할 점이 하나 있다. 옛날에는 우리나라의 경제 구조가 지금보다 훨씬 더 폐쇄적이었다. 돈 되는 건 뭐든지 닥치고 수출하고, 그렇게 어렵게 번 외화를 아끼려고 국가적으로 완전 목숨을 걸고 있었다.

자동차 산업을 육성은 해야 하지만 국내에 석유 소비(=외화 유출)가 너무 늘어서는 안 되기 때문에 역설적으로 자동차의 내수 보급을 어느 정도 통제를 해야 했다. 듣보잡 신생 자동차 브랜드이다 보니 외국으로 수출은 아주 싸게 하고 반대로 손해분을 비싼 내수 가격으로 때우는 전략은 우리 같은 서민에게야 불리하지만 그 시절에 국가적으로는 지극히 자연스럽고 불가피한 전략이었다. 국제적으로 석유 파동이 벌어지니 저걸로도 모자라서 국가에서 자동차 산업 합리화라는 극단적인 조치까지 취해야 했으니, 개인뿐만 아니라 기업을 대상으로도 인위적인 규제가 있는 셈이었다.

또한 전에도 말했지만 겨우 신혼여행이나 배낭여행 명목으로 외국 나가는 건 가능하지도 않았다. 그런 사유로는 자기 사비가 아무리 많다 해도 나라에서 여권을 만들어 주질 않았다. 양담배 추방하고 과소비 추방하고 국산품 애용하자는 캠페인을 잔뜩 벌였으며, 기업에서의 외제품 수입은 정말로 연구 개발에 도움이 되는 것만 제한적으로 허용했다. 기업들은 자동차나 전자 기기를 만들 때 국가에서 밀어붙인 "x년 안으로 국산화율 y% 이상 진입" 같은 할당량을 반드시 달성하며 연구 개발을 해야 했다. 하물며 다른 외제품도 아니고 외제차에다가는.. 당연히 세금 왕창 때렸다.

지금이야 우리가 그렇게 폐쇄적으로 나갈 필요가 없다. OECD와 WTO 회원까지 된 주제에 그래서는 안 된다. 기술· 경제 방면에서 외국과 대등한 경쟁력이 있다면야 다 개방하면 된다. 하지만 그렇지 못한 상황에서는 여전히 불가피한 시장 왜곡과 보호도 해야 했다.
지금 우리가 자유롭게 외국에 나가고 외래 문물을 마음껏 누리면서도 나라가 유지되는 것은 정말 우리나라가 그만큼 잘살고 세계적인 경제력을 갖춘 덕분이라는 것을 알아야 할 것이다.

Posted by 사무엘

* 본인은 니코틴의 맛이라는 게 뭔지 모르는 비흡연자이다. 담배를 접할 일은 앞으로도 평생 없을 것으로 보인다.

올해부터 잘 알다시피 담뱃값이 크게 올랐다. 그래서 오르기 전 가격으로 담배를 사재기 하려는 흡연자, 그리고 있는 담배도 일부러 꿍쳐 놓고 값이 오를 때까지 안 파는 가게, 사재기를 단속하려는 정부 당국..의 삼파전은 뭔가 병림픽 같다는 생각이 들었다.

지금이야 흡연이 건강에 나쁘다는 인식은 상식 중의 상식이 된 지 오래이며 대중교통을 포함해 지붕이 있는 공공장소에서 흡연이 허용되는 곳은 전혀 없다. 그나마 건물 내에 별도로 지정되어 있던 흡연실도 요즘은 없어지는 추세여서 흡연자들은 근무 중에 담배라도 한 대 피우려면 옥상이나 1층까지 갔다가 와야 하니 시간과 업무 생산성 손실이 많다.

하지만 옛날에는 그 위험한 수소 비행선인 힌덴부르크 호 내부에도 흡연실이 있었고 비행기 스튜어디스가 간접흡연 때문에 폐암에 걸려 죽을 정도였다. 지금으로서는 상상도 할 수 없는 일.
담배가 몸에 해롭다는 건 둘째치고라도, 비행기 객실 안에서 화기를 반입하고 불을 피울 수 있다는 것 자체가 오늘날의 보안 관념으로는 충공깽에 가까운 사실임은 틀림없다.

다만, 군대나 회사에서 “우리 나가서 담배나 좀 피우고 올까?” 이러면서 선임과 후임 사이에 훈훈한(?) 이야기가 오고가고 서로 친해지는 순기능이 있다는 건 본인 역시 인정한다. 어찌 보면 꽤 큰 순기능이다. 담배가 그렇게까지 건강에 나쁘지 않고 연기 냄새가 그렇게까지 역겹지만 않다면 말이다.

나도 어지간해서는 비흡연자의 권리만큼이나 흡연자의 권리도 보장해 주고 싶다. 그래서 지붕 뚫린 바깥에서까지 흡연을 금지시키고 싶지는 않다. 내 앞에서 담배를 뻑뻑 피우며 길빵을 하는 사람이 있으면 내가 그냥 달려서 그 사람을 조용히 추월해 가 줄 용의는 있다.

하지만 길빵은 담배 연기가 문제가 아니라 굉장히 위험하다. 담배를 든 팔을 잘못 휘둘러서 옆의 사람이 화상을 입는 사고가 실제로 여럿 발생했다. 또한 담뱃재와 담배꽁초를 아무렇게나 버리는 사람은 정말 싫다.
이와 대조적으로 공공장소 화장실이나 아파트 계단 통로에서 몰래 담배 피우는 사람들은 본격적으로 연기와 냄새로 민폐를 끼친다. 개인적으로 완전 혐오. 가끔은 건물의 엘리베이터 대신 계단으로 내려가고 싶은데 그렇게 할 수가 없게 만드는 주범들이다.

이렇듯, 담배는 기체를 퍼뜨려서 주변의 여러 사람들에게 큰 불편을 끼친다는 점에서 액체인 술과 다르다.
그러나 한편으로 담배는 무슨 음주운전 교통사고나 주폭 같은 피해를 끼치지는 않으니 해악의 양상이 술과는 사뭇 다른 것 같다.

한국 담배인삼 공사의 비공식 슬로건이 “담배 피워 망친 건강 인삼으로 회복하자”라고 한다. =_=;; 진짜라고 믿으면 당연히 골룸..
둘 다 우연히 국가가 전매 독점 관리하는 식물이라는 공통점이 있을 뿐이다. tomorrow와 global을 갖다붙인 영어 이니셜은 아무래도 어거지 성격이 짙다.

담뱃값 인상은 그냥 복지 집행으로 인한 부족한 세수 확보 명분일 뿐이다. 국민 건강 그딴 것 때문이 아니며, 우리나라가 주변 선진국들보다 담뱃값이 싸기 때문에 더 올리자는 주장도 말이 안 된다. 그럼 우리나라가 주변 선진국보다 매우 비싼 생필품들에 대해서는 가격을 내려 줄 용의가 있기라도 한가? -_-;;

다만, 그렇다고 해서 국가가 담배 판매를 통해 왕창 이득을 챙기고 있는가 하면 그런 것도 아니다.
거시적으로는 담배 때문에 고의로 건강 망쳐서 발생하는 생산성 저하, 사회 비용과 의료보험 재정 탕진이 더 크다.
마치 서울 지하철 보증금보다 1회용 교통 카드의 생산 단가가 더 높으며,
미국은 자국에서 생산되는 석유를 자국의 자동차들을 굴리는 데 쓰느라 더 바쁘지 나중에 더 비싸게 팔려고 꿍쳐놓고 있는 게 아닌 것과 비슷한 이치이다. 음모론은 그저 음모론일 뿐.

끝으로, 금연 장려를 위해 이런 아이디어가 제안되어 있는데 다들 참 기발하다.

• 각종 경고문이나 사진을 붙이기에 앞서 담배 이름부터 좀 화끈하게 짓자. 자살초, 폐암말기, 썩은허파, 매독 등.
• “경고: 이 담배의 판매 수익은 국회의원들의 월급 지급을 위해 쓰입니다” ...;; 내 건강 망가지는 것보다 정치인들 배부르는 게 더 싫구나. 그저 웃프다.

Posted by 사무엘

요런 개념을 표로 일목요연하게 한 번쯤 정리할 필요를 예전부터 느꼈던지라, 잠시 짬을 내어 만들었다. C++ 프로그래머라면 고개가 절로 끄덕여질 내용 되겠다. 

• 괄호는 영어에서 접속사도 되고 지시형용사/지시대명사, 관계대명사까지 다 되는 that만큼이나 정말 다재다능한 물건이다.
• 베이직은 이례적으로 =, ()가 쓰임이 중첩되어 있다. =가 대입과 동등 연산을 모두 담당하며, ()가 함수 호출과 배열 첨자를 모두 담당한다. 함수 호출은 문법적으로 매우 제한된 문맥에서만 허용되니, C/C++같은 함수 포인터가 존재하지 않는다면 () 중첩이 아주 불가능하지는 않은 듯하다.
• C/C++은 @ $ ` 기호를 전혀 사용하지 않는다. 예전에 베이직은 각종 기괴한 기호들을 이용하여 변수의 자료형을 표현하곤 했다. A$는 문자열, A%는 정수, A#은 실수 같은 식이다.
• 파스칼은 포인터형을 선언하는 토큰이 ^인데, C/C++와는 달리, 포인터형을 나타낼 때와 포인터를 역참조할 때 토큰이 등장하는 위치가 서로 다르다. ^Type 그리고 Value^ 이런 식.
• int *a와 int a[5]배열에 대해서는 똑같이 *a를 쓸 수 있지만, 잘 알다시피 배열의 역참조와 포인터의 역참조는 개념적으로 다르다. C/C++을 처음 공부하는 초보자가 굉장히 혼동할 수도 있을 듯하다.
• 포인터는 다중 포인터가 존재할 수 있고 역참조도 여러 단계를 연달아 할 수 있다. 그러니 *가 여러 개 연달아 올 수 있다. 그 반면, 참조자는 구조적으로 딱 한 번만 참조/역참조가 가능하게 만들어진 포인터의 축소판이다. 그렇기 때문에 &&에다가 별도로 R-value 참조자라는 물건을 집어넣을 수도 있다. 이걸 생각해 낸 고안자는 정말 천재다.
• 일반적으로 &는 address-of 연산자이며 R-value를 상대로는 적용이 되지 않는다.
  그러나 일부 값은 L-value가 아님에도 불구하고 & 연산자의 적용이 가능하며, 심지어 a와 &a가 동일하게 취급되는 것도 있는데, 바로 static 배열과 일반 함수이다.
  기본적으로 포인터의 성격을 갖추고 있는지라 &를 안 해도 기본적으로 자신의 주소가 되돌아오고, &를 붙여도 무방하다는 오묘한 특징이 있다.
• 한편, C/C++에서 배열은 고유한 자료형임에도 불구하고 함수의 인자로 전달되거나 리턴값이 될 때는 그냥 포인터든 배열의 포인터든 포인터의 형태로만 전달된다. 배열 그 자체가 전달되지는 못한다.
  배열을 생으로 함수를 통해 주고 받으려면 구조체에다가 배열을 집어넣어야 한다.

Posted by 사무엘

1.
프로그래밍을 하다 보면 단독 실행이 가능한 EXE 형태의 프로그램만 만드는 게 아니라, 다른 프로그램에 부속물로 붙거나 여러 프로그램들 사이에서 공유되는 라이브러리, 플러그 인 같은 걸 만들 때가 있다.
플러그 인 정도야 호스트 프로그램이라도 분명하게 존재하니 양반이지만, 임의의 프로토콜을 갖는 공용 라이브러리는 static LIB이든 DLL이든, 그 자체로 단독 실행이 가능하지 않다. 그렇다 보니 그 라이브러리를 사용하는 프로그램을 또 별도로 만들어야 해서 테스트와 디버깅이 여러 모로 불편하다.

그래서 Windows에서 DLL을 만드는 솔루션의 경우, 그 솔루션에다가 DLL을 테스트하는 간단한 EXE도 프로젝트로 따로 만드는 게 보통이다.
Visual C++은 지난 2005부터인가 프로젝트를 새로 생성할 때, 솔루션 디렉터리 아래에 동명의 프로젝트 디렉터리가 한 단계 더 생기고, 한 솔루션에 소속된 프로젝트들의 생성물은 다 동일한 output 디렉터리에 만들어지도록 기본 동작 방식이 바뀌었다. obj 같은 임시 파일들만이 프로젝트별로 자기 고유한 위치에 생성된다. 이것은 나름 바람직한 조치라 여겨진다.

그런데, 발상을 전환하면 DLL을 생성하는 소스를 기반으로 곧바로 EXE를 만들어 DLL의 함수들을 의외로 굉장히 간편하게 테스트를 할 수 있다.
링커의 SUBSYSTEM 옵션 하나만 바꿈으로써 WinMain을 사용하는 GUI 프로그램과 main을 사용하는 콘솔 프로그램을 곧바로 전환할 수 있듯, EXE와 DLL은 똑같이 PE 헤더가 있는 실행 파일이며 본질적인 차이가 거의 없다. 구조체 필드 값이 일부 차이가 나고 entry point에서 같이 전달되는 인자의 타입이 다를 뿐이다.

DLL 프로젝트에서 configuration을 하나 만든다. 테스트와 디버그가 목적이므로 Debug 빌드 것을 초기값으로 가져오면 되겠다. configuration 이름은 Debug EXE 정도로 하자.
그 뒤 프로젝트 속성의 General (일반)으로 가서 Target Extension (대상 확장명)은 .dll이던 것을 당연히 .exe로 바꾼다.
그리고 제일 중요한 Configuration Type (구성 형식)을 Dynamic Library (.dll)이던 것을 Application (.exe)으로 바꾼다.

'확인'을 누른 뒤, DLL 소스의 한구석엔 원래의 DLL엔 없던 WinMain 내지 main 함수를 추가하고, 그 안에다 호출하고 싶은 DLL 클래스/함수들을 마음껏 사용하며 테스트한다.
이것만 해 주면 끝이다. 프로젝트를 이 configuration대로 빌드해서 돌리면 된다.

별도의 EXE를 따로 만들어서 테스트를 하는 거라면 그 EXE에 또 테스트 대상 DLL을 로딩하는 코드가 추가되어야 하지만 DLL 자체의 소스로부터 EXE를 생성하면 그런 번거로운 절차가 필요하지 않으니 더욱 좋다. EXE 자체에 DLL의 코드가 그대로 포함되기 때문이다.

static LIB을 만드는 프로젝트도 이런 식으로 별도의 EXE 생성 configuration을 만들어서 테스트가 가능할 것이다.
다만 DLL/EXE와는 달리 static LIB는 링크 절차가 존재하지 않고 그냥 컴파일만 가능하면 라이브러리 파일이 만들어지기 때문에 이로부터 온전한 EXE를 만들려면 추가적인 링커 설정 같은 게 필요할 것으로 보인다.

2.
여담이다만 DLL뿐만 아니라 EXE도 DLL처럼 export 심벌을 가질 수 있으며 그걸 GetProcAddress를 통해 얻어 올 수 있다.
EXE만 자신이 로딩한 플러그 인 DLL로부터 함수를 얻어 오는 게 아니라, DLL 역시 자신을 로드한 EXE로부터
GetProcAddress( GetModuleHandle(NULL), "GetHostInfo") 이런 식으로 코드를 얻을 수 있다. 이것도 참 기발한 발상이 아닐 수 없다. 어디 활용할 데가 없을까?

내가 개인적으로 굉장히 놀란 것은, 저렇게 한 프로세스 공간의 주인 역할을 하는 EXE가 아니라..
완전히 다른 EXE를 로딩해서 거기에 있는 코드를 실행하는 것도 가능하다는 것이다. EXE는 보통 0x400000 같은 고정된 주소에 로드되며 재배치 정보가 존재하지 않기 때문에 자기 위치에 로드가 못 되면 로딩이 실패한다.

그런데 자신과 로드 주소가 겹치는 EXE도 LoadLibrary를 하면 일단 작업이 성공하며 리소스 추출뿐만이 아니라 GetProcAddress도 실행 가능한 듯하다. 이쯤 되면 EXE와 DLL의 경계가 어찌 되는지가 궁금해진다.

3.
아무 중간 계층 없이 C/C++ 언어만으로 뭔가 라이브러리를 남에게 제공하는 건 애로사항이 적지 않다.

• 디버그 or 릴리스?
• 32 or 64비트?
• 최종 형태는 DLL or LIB?
• VC++ 어느 버전? (보안 기능 링크 에러)
• 사용하는 CRT의 형태는 DLL or static?

이런 식으로 상호 일치해야 하는 변수가 급격히 늘어나기 때문이다. 조건부 컴파일이 괜히 필요했던 게 아니다.
C/C++ 런타임 라이브러리도 비주얼 C++의 버전이 바뀜에 따라 내부적으로 야금야금 더해지고 바뀌는 기능이 있기 때문에--특히 보안 관련-- static 링크하는 경우 빌드 툴의 버전이 안 맞으면 이상한 심벌명에서 링크 에러가 나고 각종 문제가 생기기 쉽다.

그나마 같은 비주얼 C++끼리이니까 망정이지 서로 다른 컴파일러끼리 C++ 클래스 라이브러리를 공유한다면 name decoration까지 문제가 됐을 것이다. 사실상 공유 불가능이다.
옛날에는 문자 집합의 크기(일명 유니코드/ANSI)조차도 변수가 따로 있었을 정도이지만 요즘은 그래도 유니코드, 정확히는 wide string만 고려하면 되니 그건 그나마 나아졌다.

이 문제가 워낙 복잡하니..
일차적으로는 COM 같은 바이너리 표준이 나왔을 것이다.
아니면 그냥 소스 코드를 통째로 넘겨줘서 필요한 사람이 알아서 빌드해서 쓰게 하든가. 그 라이브러리가 애초부터 오픈소스 진영의 작품이라면 다행이지만, 상업용 코드라면 인터페이스 부분을 제외한 나머지에다가는 난독화 처리가 필요할 것이다.

그것도 싫으면 저런 골치아픈 요소들을 싹 잊어버리고 자바/C# 같은 바이트코드 기반으로 가는 수밖에 없는데... 그건 물론 성능은 COM보다도 엄청나게 더 희생시킨 귀결일 것이다.
그래도 아무 클래스에나 public static void Main만 있으면 그게 곧 실행 가능한 물건이고 빌드 속도도 안드로메다 급으로 빠르며 골치 아픈 32/64비트 구분 같은 것도 없는 환경이.. C++ 프로그래머로서 참 부럽게 느껴질 때가 있다.

Posted by 사무엘

PL(프로그래밍 언어)계에서 함수형 프로그래밍 언어는
자동차 엔진으로 치면 로터리 엔진, 발전소 업계로 치면 핵융합 발전 같은 뭔가 이상은 높지만 현실은 아직 좀 시궁창인 그런 떡밥스러운 영역으로 간주되는 것 같다.

전산학을 전공해서 PL 수업을 들은 분이라면 이미 잘 아시겠지만, 프로그래밍 언어란 크게 절차형과 선언형으로 나눌 수 있다.
절차형은 튜링 기계라는 컴퓨터의 특성을 그대로 반영하여 메모리로부터 값을 읽은 뒤 연산을 수행해서 값을 변경하고, 메모리 위치도 바꾸는 절차를 순차적으로 일일이.. 즉 HOW 위주로 기술하는 언어이다. 정보 올림피아드 경시부가 다루는 것은 응당 절차형 프로그래밍 언어를 활용하여 프로그램을 작성해서 문제를 해결하는 능력이다.

(덧붙이자면 튜링 기계에다가 데이터뿐만 아니라 코드, 즉 상태 변환 로직까지 동일한 메모리에다 올려서 해석하는 계산 모델이 바로 오늘날 컴퓨터의 근간이 된 프로그램 내장형, 즉 폰 노이만 모델이다. 자동차 엔진로 치면 정말 외연 기관에서 흡입-압축-폭발-배기 4행정 내연 기관으로 변모한 수준의 발전이 아닌가 싶다.)

한편, 선언형은 우리가 원하는 솔루션의 정의 내지 조건이 이러하다.. 라고만 써 주는 형태의 WHAT 지향형 언어이다. 그러면 컴퓨터가 알아서 문제를 풀어 낸다.
따지고 보면 데이터베이스 질의어인 SQL은 DLL, EXE 같은 실행 파일을 만드는 용도의 언어가 아닐 뿐이지 아주 대표적인 선언형 언어이다. 복잡한 DB에서는 질의어를 만드는 것도 굉장히 복잡한 일이 되며, 두 DB간의 JOIN은 어떻게 시키고 어느 구문부터 풀이해서 최적의 성능으로 질의를 수행할지 결정하는 것도 아주 어려운 축에 든다. 이런 거 성능 소요 시간을 몇 % 단축시키는 알고리즘을 개발해 내면, DB를 연구하는 전산학과 대학원 연구실에서는 그게 곧바로 논문감이 된다.

흔히 인공지능 문제 풀이형 언어로 알려져 있는 프롤로그도 선언형 언어이다. 이건 진짜 여러 변수들을 선언한 뒤 변수들간의 인과관계를 쭈욱 나열해 주면 이를 바탕으로 언어 런타임이 문제의 답을 찾아 낸다.

까놓고 말해 절차형 프로그래밍 언어로 "아인슈타인의 퍼즐" 같은 걸 풀려면, 프로그래머가 재귀호출에 각종 백트래킹 알고리즘을 직접 구사해야 하니 앞에서 말했던 정보 올림피아드 경시부 급의 기술이 필요하다. 그러나 프롤로그에서는 "영국인.집 = 빨강, 스웨덴.애완동물 = 개" 이런 식으로 단서만 주어진 규칙대로 쓴 뒤 쿼리를 날리면 금붕어를 기르는 사람의 국적을 구할 수 있다.

아마 네모네모 로직이나 스도쿠 같은 것도 해답이 갖춰야 할 조건을 명시하는 것만으로 바로 풀 수 있지 싶다. 단서들을 바탕으로 뺑뺑이를 돌리는 추론 과정은 언어 런타임 내지 엔진이 해 준다.
대학 학부 시절, OR개론 수업 때 잠시 접했던 선형계획법 문제 풀이 프로그램인 k-opt도 역시 지정된 문법에 따라 변수와 부등식들을 써 놓고 최소화/최대화 조건을 명시하면 프로그램이 해를 찾아 주니.. 일종의 선언형 프로그래밍 언어 런타임에 속한다고 할 수 있겠다.

그러니, 절차형 언어의 컴파일러는 최적화를 하는 게 기계어 코드 생성이나 멀티코어 병렬화 같은 아주 미시적인 것과 관계가 있는 반면, 선언형 언어의 수행 방식을 최적화하는 것은.. 거시적인 알고리즘 전략까지 결정해야 하니 더욱 까다로울 것이다. 미시적인 건 해당 언어 엔진이 아주 정교하게 구현되어 있지 않은 이상 신경 쓰기 힘들다.

앞서 언급한 SQL이나 프롤로그는 선언형 프로그래밍 언어 중에서 일종의 '논리 지향'인 물건들이다. 그런데 선언형의 하위 범주로는 '함수 지향', 함수형 프로그래밍 언어라는 게 있다. 이게 절차형보다는 좀 더 수학자스러운 형태로 컴퓨터를 부려먹는 방법을 기술하는 방법론이라고 한다. (함수형이 여느 절차형 프로그래밍과 계산 능력이 동등하다는 것은 튜링 기계와 람다 대수가 동치라는 것이 증명됨으로써 알려져 있다.)

순수한 함수형 프로그래밍 언어에서는 지저분한 대입 연산이 없고 한번 생성된 값은 변경 없이 계속 그 값으로 남아 있다. 새로운 값이 계속 생성될 뿐이다. 사실 문자열을 이런 사고방식으로 처리하는 라이브러리나 언어, 프레임워크에서는 이미 있는 문자열을 변경하는 게 굉장히 어렵기도 하다. Windows RT의 String 클래스도 그랬던 걸로 기억..

함수형 언어에서는 대입이 없으니 응당 뺑뺑이 loop도 있을 수 없다. loop을 대신하는 것은 재귀호출이다! loop조차도 기존 값을 계속 바꾸는 게 아니라 새로운 값을 자꾸 만들어 내는 방식으로 구현된다는 뜻이다.
처음에 해답의 범위가 0부터 100 사이에 있었다면 그 다음 턴에는 0부터 50 (log n 시간 복잡도), 혹은 0부터 99로 자가호출이 이뤄지고, 이것이 문제가 완전히 해결될 때까지 반복된다. 왜냐하면 이 문제의 솔루션이 바로 그런 형태로 귀납적으로 정의돼 있기 때문이다. 팩토리얼이든, 두 수의 최대공약수이든, 정렬이든 다른 무엇이든.

이 패러다임에서는 함수가 다른 여느 데이터와 완전히 동일한 수준으로 다른 함수의 인자가 될 수 있고, 특히 이름 없이 함수의 몸체만을 여느 값처럼 달랑 전해 줄 수 있고, 다른 함수로부터 합성되고 유도된 새로운 함수가 함수의 리턴값이 될 수 있다. 새로운 함수가 동작하는 데 필요한 주변 문맥은 클로저라는 물건이 알아서 다 처리해 준다.
C/C++의 함수 포인터에 머리가 굳은 프로그래머라면 calling convension은 무엇인지, this 포인터가 포함된 멤버 함수인지, pointer-to-member라면 다중 상속으로 인한 부가 오버헤드는 없는지 같은 디테일 때문에 머리가 복잡해질 것이다.

함수형 언어에서 if문은 응당 자기 자신도 조건이 만족하는 쪽의 값을 되돌리는 함수 형태이다.
그러나 if는 조건이 만족하는 쪽만 '계산'이 행해질 터이니 if(a) b; else c; 를 나타내는 if(a, b, c)는 통상적인 함수 호출 func(a, b, c)와 의미상으로 완전히 동일할 수는 없다. 예약어로 따로 해석되고 취급을 받아야 할 듯하다.

물론 이런 함수형 프로그래밍 언어가 구현되기 위해서는 현실에서 컴파일러가 최적화해 줘야 하는 것, 그리고 언어 런타임이 해 줘야 하는 오버헤드가 적지 않다. 끝없이 새로운 값을 생성해 내더라도 이제 참조가 끝나서 더 쓰이지 않는 값은 GC가 알아서 제거해 줘야 하고, 재귀호출, 특히 tail recursion 정도는 알아서 메모리 복잡도를 O(n) 급으로 늘리지 않는 일반적인 loop처럼 돌아가게 컴파일러나 런타임이 최적화를 해 줘야 한다. 함수를 값처럼 부드럽게 다루는 것도 기술적으로는 단순 함수 포인터 이상의 추상화 계층이 필요하며, 말처럼 쉬운 일이 아니다.

예를 들어.. X라는 함수가 있는데.. 얘는 a라는 인자를 받고는,
b라는 인자를 받아서 a에다가 b를 더한 값을 되돌리는 Y라는 함수를 되돌린다고 치자.
결국 Y는 X라는 함수가 호출될 때 전달되었던 매개변수 내지 그때 생성된 X 내부의 지역 변수에 의존하여 동작하는데..
나중에 Y가 단독으로 호출될 때는 X라는 함수는 실행이 끝나고 그 문맥이 존재하지 않는다. 이를 어찌하리?
이런 딜레마를 피하기 위해 C/C++ 언어는 애초에 함수 안에 함수를 만드는 걸 지원하지 않는 쪽으로 설계되었으며, C++의 functor 같은 것도 전부 자기가 자체적으로 데이터 멤버를 갖고 있는 객체 형태로 만들어지게 된 것이다.

또한, 아무리 대입이 사이드 이펙트가 남는 지저분하고 기피되어야 하는 연산이고.. 다른 모든 연산을 loop 대신 재귀호출로 때운다 해도.. 당장 외부 파일/키보드로부터의 input은.. 대입 연산 없이는 감당이 도저히 불가능하다. 그리고
return t1.len() > t2.len() ? t1: t2
처럼 그 재귀호출의 결과값을 취사 선택하는 간단한 판단을 위해서라도 임시 변수에 대입하는 것 정도는 근본적으로 전혀 없을 수가 없다.
어디 그 뿐이랴. 대용량의 단일 데이터를 대상으로 여러 함수들이 포인터만 주고받으며 동작하다 보면, 한 함수가 자기 argument 안에 입출력 대상인 모든 데이터를 집어넣는 것은 무리가 있다.

허나 함수형 프로그래밍이 성능면에서 불리한 요소만 있는 건 아니다. 대입으로 인한 side effect 같은 게 없으니 소스 코드의 정적 분석은 더 용이할 것이고 병렬화 등 입맛에 맞는 최적화에도 더 유리할 것이다. 애초에 선언형 프로그래밍 언어는 구체적인 실행 방식은 그런 똑똑한 컴파일러나 언어 엔진에게 맡기고 있으니까.
이러니 PL 분야를 연구하는 전산학자나 수학 덕후들이 함수형 프로그래밍 언어에 더욱 열광하는 듯하다. 저런 패러다임이 응집도· 결합도 같은 소프트웨어 공학적인 측면에서 더 깔끔한 코드를 만드는 데 도움이 되는 것은 덤이다.

대학교 전산학과에서는 함수형 프로그래밍 언어로 보통 Scheme을 실습하는 편이다. 본인도 먼 옛날 학부 시절에 '프로그래밍의 이해(PP)'라는 과목을 통해 그 물건을 접했으며, 그걸로 무슨 다항식의 곱셈을 하는 프로그램도 숙제로 만들고 여러 덕질을 했었다. 함수형 언어의 진짜 본좌라고 일컬어지는 Haskell 같은 건 난 모름.;;

여담이지만 지금 생각해 보니, 온갖 복잡한 괄호가 배배 꼬여 있는 Scheme 코드는.. 언어학에서 문장 구문 분석을 괄호로 표현해 놓은 것과 사뭇 닮았다는 생각이 들었다. (S (NP .. ) (VP ...)) 이러는 식.
Schme에서는 S 대신에 define, lambda, if 따위가 있을 것이다.

물론 그때는 본인은 <날개셋> 한글 입력기 개발에 도움이 안 되는 건 진짜 생까고 무시하던 시절이어서 그 코스의 의미를 제대로 이해를 못 했다. 왜 괜히 계산 과정을 이 따위로 어색하게 표기를 하는지..??
그건 사칙연산 같은 기초적인 연산자조차도 통상적인 표기법이나 우선순위를 깡그리 무시하고 정말로 오로지 함수 위주로.. 프로그래밍이, 아니 계산(computing)이라는 작업 자체를 몽땅 주어진 규칙대로 피연산자들을 처리해서 reduce하는 과정이라고 극도로 추상화한 귀결일 것이다. 일종의 발상의 전환인 것이다. car, cdr 명령이 튜링 기계로 치면 메모리 셀을 이동하고 값을 읽는 동작에 해당할 것이다.

단, Scheme도 마냥 순수 함수형 언어이기만 한 것은 아니다. 필요한 경우 대입 연산이 있을 수 있고 일부 절차형 패러다임 구문을 집어넣을 수도 있다. 마치 C#에서 부분적으로 unsafe, unmanaged 코드를 집어넣듯이 말이다.
그리고 반대로 C++ 역시, 기본적으로 객체지향 패러다임을 주류로 내세운 절차형 언어이지만 최근에는 함수형 프로그래밍 패러다임도 받아들여서 람다 함수를 기존 함수 포인터나 functor의 대용으로 쓸 수 있게 되었듯이.. 요즘 언어들의 대세는 자기 정체성은 유지하면서 다른 패러다임에서도 유용한 건 적극 받아들이는 것인 듯하다.

과연 함수형 프로그래밍 언어가 그저 대학교 과목에서나 잠깐 접하고 마는 떡밥 내지 PL 분야의 연구자들만 쓰는 도구 수준을 넘어.. 현업에서 적극 즐겨 쓰이는 날이 올지 모르겠다. 지금 현업에서 전혀 안 쓰인다는 말은 아니지만 아직까지는 수학 덕후, 컴덕후들의 전유물이라는 인상이 강한 편이니 말이다. 그래도 한 가지 확실한 건, 함수형 프로그래밍 패러다임을 실현해도 될 정도로 요즘 컴터 환경이 좋아지자, 각종 언어들에도 이 패러다임이 적극 많이 도입되고 이게 유행을 타고 있다는 사실이다.

여담으로, 람다 대수를 고안한 앨론조 처치는 family name이 어째 '교회'다..;; 독실한 신자 가문이기라도 했나 싶은 잡생각이 든다.

그리고 궁금한 게 있는데.. 이름 없는 함수에서 재귀호출을 해야 할 때 함수 자기 자신을 가리키는 this, self 같은 키워드는 없는가 싶다.
이 의문은 C++에서 람다 함수가 추가되었을 때부터 여러 프로그래머들에 의해 제기되어 왔다. 하지만 뾰족한 해결책은 없으며, std::function에다가 자신을 저장한 뒤, 그 변수명을 캡처로 도로 넘겨 줘야만 재귀호출이 가능하다. Scheme 역시 일단 def로 자기 이름을 지은 뒤, 그 이름을 호출해 줘야 된다.

재귀호출을 그렇게도 좋아하는 함수형 언어가

[](int x) { return x<=1 ? 1: this_func_itself(x)*(x-1); }

개념적으로 this_func_itself에 해당하는 키워드 같은 건 정말 없는 건지 신기한 노릇이 아닐 수 없다.

Posted by 사무엘

본인이 다니는 교회에서는 교계에 통상적으로 알려져 있는 성탄절과 부활절이 이교도(pagan) 절기와 섞여서 교리적으로 많이 변질된 비성경적인 절기라고 간주한다. 그렇기 때문에 이를 교회에서 공식적으로 지키지 않는다.

물론 그렇다고 해서 예수님의 성육신 탄생 내지 부활 자체를 안 믿는 건 아니다. 단지 예수님의 생일이 12월 25일이라고 가르치지 않으며 크리스마스 트리와 산타 할아버지, 부활절 달걀과 토끼 같은 걸 만들거나 시행하지 않을 뿐이다. 또한, 성경에 예수님의 탄생보다 훨씬 더 분명하고 중요하게 기록되어 있는 예수님의 죽으심을 더 중요하게 기념할 뿐이다(일명 성찬식이라고 불리는 주의 만찬).

예수님의 탄생과 관련된 종교 음악/노래들을 살펴보자.

• I. 그나마 찬송가 축에 들고 성경 고증대로 예수님의 탄생만을 다루고 있는 <천사들의 노래가>, <기쁘다 구주 오셨네> 같은 건 종교 텍스트로 치면 진짜로 영감 받은 66권 성경 정도의 퀄리티일 것이고..
• II. 가사가 성경적인 배경이긴 하지만 크게 교리 측면의 영양가가 없고 찬양으로서의 가치도 별로 없는 노래는 외경 정도의 등급일 것 같다. 어떤 예가 있는지에 대해서는 논란의 여지가 있으니 이 자리에서 밝히지 않겠다.
• III. 그것보다 더 나아가서 아예 눈썰매, 크리스마스 트리나 산타 할아버지만 나오는 수준의 캐롤은.. 딱히 기독교와 교리적인 관계가 있다고는 볼 수 없고 위경에 가까운 레벨이라고 간주해야 할 것이다.

물론 외경, 위경급이라고 해서 그게 일고의 가치가 없는 쓰레기이고 배척하자는 건 아니다. 개인적으로 그런 노래 들으면서 연말연시 크리스마스 분위기를 즐기는 것 자체를 나쁘다고 할 수는 없다. 크리스마스가 아무리 세속화했다고 해도 아예 대놓고 드루이드 교의 마귀적인 의식에 기원을 둔 할로윈보다는 낫지 않은가.
다만, 즐기더라도 오늘날의 크리스마스가 성경이 말하는 기독교와 직접적인 연결 고리가 있지는 않다는 건 알고서 즐길 필요는 있다. 고증상 예수님의 실제 탄생일은 유대인 절기 중의 장막절에 속하는 가을, 우리로 치면 오히려 추석과 더 가깝다.

뭐, 그런 배경에도 불구하고 서양에는 12월 25일 크리스마스가 우리로 치면 꽤 중요한 공휴일이다. 한중일 중에서는 대한민국 우리나라만이 유일하게 정부 수립 극초반부터 이례적으로 공휴일로 지정됐다. 이건 빼도 박도 못하고 초대 대통령이 기독교인이었던 덕분이라 해도 과언이 아니다.
우리나라는 11월에 공휴일이 전혀 없는 관계로, 10월 9일 한글날 이후의 공휴일은 거의 70여 일 뒤인 성탄절이다. 12월 25일은 학교에서는 대개 겨울방학이기 때문에 성탄절은 근로자의 날과 더불어, 학교 졸업하고 직장인이 되고 나서야 존재감이 느껴지기 시작하는 양대 공휴일이다.

다시 본론으로 돌아와 오늘은 캐롤 얘기를 계속하겠다.
캐롤은 우리나라에 가사가 번역되어 소개된 <징글 벨>, <울면 안 돼>, <루돌프 사슴코> 같은 게 있는데 그냥 초등학교 음악 책에나 나오는 쉬운 동요 수준으로나 알려져 있다.
뭐, <탄일종>은 크리스마스 컨셉을 꽤 우회적으로 표현한 국산 동요이고, <성탄제> 같은 시도 있으니 국산 컨텐츠가 아주 없는 건 아니지만.

하지만 외국에서는 우리나라 정서와는 사뭇 다른 크리스마스 노래가 많이 있으며, 그리고 비교적 최근까지도 신곡이 나오고 있다. 짤막한 동요보다야 더 큰 스케일로 말이다.
<화이트 크리스마스>, <실버 벨> 같은 것들은 다 1940~1950년대에 발표된 곡이다. 세상에 알려진 지 100년이 채 지나지 않았다.
국내에 번역되지 않은 곡으로 내가 아는 것만 열거해 봐도 Do you hear what I hear라든가, 프랑스의 Chants De Noel, The Christmas Song이 있다. 특히 The Christmas Song의 경우 어렸을 때 경험했던 크리스마스 파티에 대한 추억을 굉장히 서정적으로 묘사했다. 첫 단락만 대충 의역 스타일로 옮겨 보면...

중간엔 “Everybody knows a turkey and some mistletoe”(칠면조 요리와 겨우살이풀. 다들 잘 알지요) 라는 대사가 있어서 본인은 mistletoe라는 단어를 여기서 처음으로 접했다.
크리스마스 장식용으로 이 식물이 이런 식으로 쓰이는가 보다. 우리나라 정서상으로는 everybody knows라고 할 수는 없을 듯. 참고로, 아래 그림에서 딸랑딸랑 소리 나는 종이 말 그대로 jingle bell이다.

그래도 나중에 Enya의 White is in the winter night이라는 캐롤 스타일의 노래를 들으니 저 캐롤이 같이 떠올랐다.

위의 그림을 같이 보시라. 풀잎은 green이고 holly(열매)는 빨갛다. 저 문화권에서는 겨우살이풀에 저런 심상이 담겨 있는가 보다. “아 아버지가 눈을 헤치고 따 오신 그 붉은 산수유 열매”(성탄제)가 문득 떠오르기도 하고.

뭐, 종교적인 면을 빼고 생각하자면, 연말을 앞두고 이렇게 촛불 켜고 칠면조구이를 먹고 사람들끼리 선물을 주고받는 명절이 있다는 것 자체는 본인 역시 좋고 훈훈하다고 생각한다. 교회에서 성경 운운하면서 교리적으로 하지만 않는다면 말이다.

이런 일체의 관행 자체를 계 11:10의 부정적인 장면과 연관 시키면서 굉장히 부정적으로 보는 분들도 있는데.. 그렇게까지 과민반응을 보일 필요는 없을 듯.
마치 성경에서 생일이 부정적으로 나온다고 해서 친구들끼리 일체의 생일 잔치까지 괜히 나쁘다고 매도할 필요는 없듯이 말이다. 그건 그저 사람마다 받아들이기 나름인 재량의 영역이 아닐까 한다.

(창세기 파라오의 생일, 복음서 헤롯의 생일. 다 적그리스도를 예표하는 왕이며, 그 생일 잔치에 하필이면 사람이 죽는다. 각각 빵 굽는 시종장과 침례자 요한. 보통 왕의 생일 정도면 국가적으로 아주 경사스러운 잔칫날이며, 사형 집행은커녕 죄수들을 사면하고 풀어 주는 날인데 저건 굉장히 이례적이고 이상한 사건이다)

어쨌든, 방문자 여러분께 메리 크리스마스 인사를 드리는 바이다.

Posted by 사무엘

2014년 한 해 동안은 국군 전방 부대에서 불미스럽고 안타까운 소식이 둘이나 있었다.
다른 계급도 아니고 전역을 겨우 3개월 남짓 앞두고 있던 어느 병장이.. 지금까지 쌓인 게 얼마나 많았으면 돌연 총기 난사 + 무장 탈영이라는 초대형 사고를 쳤다. 그리고 총격전까지 벌인 끝에 자기 인생은 물론 여러 동료 병사와 주변 간부들의 인생까지 덩달아 쫑치게 만들었다.

그 뒤 지난 여름엔 어느 폐쇄적인 부대에서 한 병사가.. 구타와 가혹행위를 견디다 못해 하다못해 저렇게 총기 난사를 벌이거나 혼자 자살한 것도 아니고.. 진짜 순수하게 맞아 죽는 초유의 참극이 벌어졌다. 거의 군대판 '일본 여고생 콘크리트 살인 사건, 인디애나 주 실비아 라이컨스 사건'이나 다름없다.

유 관순 열사가 사형이나 고문치사나 병사가 아니라 간수들에게 순수하게 맞아 죽었다고 최근에야 밝혀졌는데.. 나라 지키러 간 군인이 변태 가학적인 악마 아군에 의해 그렇게 죽은 것이다. 동물이나 심지어 적군 포로에게라도 해서는 안 될 몹쓸 짓을 당한 것이다. 이러니 오죽했으면 군대에서 “참으면 윤 일병처럼 되고, 못 참으면 임 병장처럼 된다”라는 웃을 수만은 없는 블랙코미디가 나돌 정도였다.

군대에서 차라리 제2 연평해전 전사자들처럼 적과 싸우다가 적군의 총탄에 산화한 거라면.. 그 무엇도 목숨과 바꿀 수는 없겠지만 그래도 제일 영예로운 죽음이긴 하다.
천안함의 경우는 적군들 얼굴도 못 보고 전투다운 전투를 못 벌이고 전사자가 발생했으니 위의 경우보다는 좀 더 원통하고 안타깝지만, 그래도 그것만으로도 충분히 영예로운 일이다.

다음으로 훈련이나 다른 근무· 작업 중에 사고로 죽은 거라면 위의 경우보다 더 허무한 축에 들 것이다. 그러나 이 역시 엄연히 나라 지키다가 순직한 것이다. 그런 죽음이 전혀 없을 수는 없다.
하지만 전투력과 아무 관계가 없는 저런 병폐로 인한 원통하고 억울한 죽음은 도대체 어떻게 해야 근절할 수 있을까?

이런 일을 예방하겠답시고 동기들만으로 구성된 소대를 만들겠다는 안이 나왔는데, 이 역시 멍청한 생각이 아닐 수 없다. 동기들만으로 구성된 학교 학급 안에도 양아치와 일진들이 포진해서 “나보고 형이라고 불러” 이러는 걸 정녕 모르나 보다. 문제의 근원이 계급에 있는 게 아니다. 저건 문제의 본질을 잘못 짚어도 한참 잘못 짚었다.

좀 더 훈련이 혹독하고 힘들어도 좋으니 군대가 일과 후 시간 동안에는 병사들의 사생활을 조금이라도 더 보장해 줄 수 없을까? 거의 모든 병영 스트레스는 내무 생활 때문에 발생하는 것이니 말이다. 본인이야 뭐 자대 생활을 하지도 않았고, 군대 행정 같은 건 비전문가이니 그저 이런 생각만 부질없이 늘어놓을 뿐이다.

이제는 우리나라도 모병제를 해서 진짜 군대에 갈 의향이 있는 사람들 위주로 전문화된 군대를 꾸며야 한다는 말이 있지만 이 역시 현실은 녹록치 않은 것 같다. 오히려 극심한 저출산 때문에 지금처럼 강제 징병을 하고도 군대에 갈 사람이 부족한 듯하다. 거기에다 복무 기간은 1년 9개월까지 단축되어서 사정은 더욱 심각한 듯. 징병 검사는 갈수록 엄격해지고 있고, 덕분에 소총을 쥐어 줘도 될 정도로 정상적인 신체와 멘탈을 갖추지 못한 사람까지 입영하는 바람에 사고가 발생하는 빈도도 느는 듯하다. 즉, 문제의 원인과 해결책을 모병제와는 정반대 방향으로 진단하는 견해도 있다는 뜻이다.

또한 정말로 순수하게 모병제인 일본 자위대는 한국보다 시설 복지가 더 우수함에도 불구하고 그 안에서도 구타· 가혹행위가 만연하며 단위 인원당 자살자 비율도 “더 높다”. 애초에 우리나라 국군도 해병대는 순수하게 지원자로만 구성되어 있지만--비록 일단 군대 자체는 무조건 가야만 하는 상황에서 병과· 직종만이 지원제인 것이긴 해도-- 2011년 한 해 동안 온갖 불미스러운 사고는 다 터지지 않았던가. 이 문제에 관한 한 징병이냐 모병이냐가 본질적인 문제는 아닌 것 같다.

1년에 우리나라 군대에서 자살하는 장병의 수가 옛날에는 세자리 수였다가 그래도 21세기에 들어선 뒤부터는 수십 명 수준으로 줄었다. 비록 우리나라 국군이 병사 월급이 매우 적고 복지와 보상이 안습한 수준이며 가끔 저런 대형 사고가 터지고는 있지만, 그렇다고 해서 국군 내부의 인권 실상이 겨우 북한 따위에게 디스를 당할 정도는 절대로 아니다.

그리고 만에 하나 인권 실상이 좋다고 해 봤자 북한은 고등학교를 졸업한 뒤에 남자가 10년, 여자가 7년간 군대에서 '썩어야' 하는 나라이다. =_=;;; 그것 자체가 나라의 미래인 청년들에 대한 넘사벽급의 인권 유린이지 않겠는가? 우리나라에서는 애초부터 국비로 양성된 육사 출신 장교나 복무할 만한 기간을 저쪽 동네에서는 병들이 복무하는 것이다.

아무튼, 군대에서 다시는 저런 비극이 발생하지 않기를 '앙망'한다. 내가 개인적으로 바란다고 해서 저런 일이 또 안 터지지는 않겠지만.
이런 일을 빌미로 평소에 동성애자에 대한 생각이 불건전하던 사람, 국가관이 이상하던 사람들이 옳다구나 물어뜯고 군대에 대해서 대안 없는 비난이나 늘어놓고 감 놔라 배 놔라 하는 광경도 보고 있자니 개인적으로 심기가 무척 불편했다.

예나 지금이나 군 복무는 국민의 의무이지만 한편으로 내 인생에서 적지 않은 분량을 국가의 이름으로 희생시키고 착취당하는 일이다. 군대에 갔다간 나도 위에서 열거한 저런 험한 꼴의 주인공이 될 것 같고..
그래서 기를 쓰고 군대에 안 가려는 병역기피 범죄가 많았다. 또한 마지못해 입대는 했지만 그 뒤 견디다 못해서 도망가 버리는 사람이 종종 발생하곤 했다. 이름하여 탈영이고 법적 용어로는 군무이탈이다.

군대는 안 그래도 사기와 기강이 중요한 엄격한 집단이며 군대에 가고 싶어서 선뜻 간 사람은 별로 없다. 이런 와중에 국가가 탈영병을 집요하게 추적해서 잡아 주지 않으면, 까놓고 말해 탈영 안 한 사람이 바보가 될 지경이 되면 군대가 제대로 유지되지 못한다. 그래서 탈영은 국민의 의무 수행에 대한 형평성을 보장하기 위해서라도 '탈세'만큼이나 굉장히 큰 범죄로 간주된다. (물론 애초에 군대를 불법으로 뺀 병역기피하고 형평성이 안 맞다는 비판은 좀 있지만)

하지만 무작정 탈영병을 흉악범마냥 취급하는 것도 어폐가 있다. 다른 모든 범죄들은 신체의 자유가 있는 상태에서 자기가 고의로 나쁜짓을 저지른 경우이지만, 군무이탈은 국가가 개인으로 하여금 신체의 자유를 군대 안으로 속박하려고 하는데 그걸 견디다 못해 법을 어긴 경우이기 때문이다. 범죄하고는 아무 상관 없이 살았던 청년이 한 순간의 잘못된 선택으로 인해서 흉악범과 동급으로 취급되고 무작정 법의 철퇴를 맞고 전과자 되고 인생 종치는 건 국가적으로도 손해이다.

이렇게 탈영병 내지 군무이탈자는 법적으로 예외 없이 단호하고 무겁게 다뤄야 하는 한편으로 정상을 참작하여 아량도 베풀어야 하는 이중적인 면모가 있는 것 같다. 그래서일까?
국군에서는 정기적으로(대략 3년 간격) 육해공 참모총장이 전국의 탈영병들을 상대로 복귀 명령을 내린다. 공고문이 철도역이나 버스 터미널 같은 데에 다 게시된다. 이 특별 기간(대략 2개월 남짓)에 탈영병이 자수를 하면 지금까지 탈영해 있었던 기간에 구애됨이 없이 정상을 참작하여 “최대한 관대하게” 처분해 주겠다는 당근(?)까지 제안한다.

이것은 여러가지 효과를 노린 것 같다.
탈영 기간에 비례해서 처벌의 수위가 마치 채무 이자마냥, 주차장이나 도서관의 연체료마냥 눈덩이처럼 불어난다면 장기 탈영병은 탈영 기간이 길어질수록 자수 의욕을 잃고 아예 자살 같은 더 극단적인 선택을 할 가능성이 높아진다. 이것은 개인에게나 국가에게나 좋은 결과가 아니다.

그렇다고 마냥 무조건적으로 봐 줄 수만은 없으니 저렇게 군대판 “어서 돌아오오”를 정기적으로 시전하여 특정 기간에만 미끼를 내던지는 게 군무이탈자들의 심리를 동요시키는 효과도 있고 적절해 보인다.
거기에다 탈영에 대한 실질적인 공소시효를 최대한 늘리는 건 덤이다. 40대 초중반의 나이까지 끝까지 탈영 안 하다가 붙잡히면 나중에는 군무이탈에 대한 공소시효는 끝나더라도 '명령 불복종죄'로 처벌할 수가 있게 된다.

그런데 여기서 한 가지 의문이 생긴다.
지금까지 내려진 군무이탈자 복귀 명령을 보면.. 적용 대상이 “1963년 12월 1일 이후로 육해공군 복무 중에 군무이탈 중인 자”라고 돼 있다.

현재까지 잡히지 않은 가장 오래 된 탈영병이 탈영한 때가 1988년이라고 알려져 있다. 이 정도면 사실상 죽었거나 외국으로 밀항한 수준이 아닌가 싶다.
그런데 왜 기준 날짜가 지금으로부터 무려 반세기 전, 비현실적으로 까마득하게 먼 과거인 1963년인 걸까? 작정하고 엄청난 옛날을 잡고 싶거들랑 아예 “1940년대 말의 건군 이래로”, 혹은 “1953년 휴전 이래로”라고 해도 될 텐데? 궁금하지 않으신지?

그 이유는 국가에서 1963년 11월 30일과 그 이전에 발생한 탈영은 모두 정식으로 사면을 해 줬기 때문이다. 옛날에는 나라가 워낙 혼란스러웠고, 개인 사정상 도저히 불가피한 생계형 탈영도 있었을 테니 말이다.
저 때는 박 정희가 군복을 벗고 제5대 대통령으로 당선된 지 얼마 안 된 시기였는데, 민생 안정을 위해 이것저것 여러 조치가 취해지곤 했다. 역사 기록을 찾아 보면, 공교롭게도 출입국 관리법 위반자도 1963년 11월 30일 이전 것들은 다 사면해 줬다고 한다.

1963년은 한국 철도사에서는 서울교외선이 전구간 개통한(8월) 해이다. 그 이전의 1962년엔 군사 정권이 들어섰고 경제 개발 5개년 계획이 수립됐다. 그리고 이때 현재까지 우리나라 역사상 최후의 화폐 개혁이 행해져서 '원'이라는 단위가 쓰이기 시작했다. 1962년은 박통 정부가 독립 운동가들을 국가 차원에서 대대적으로 찾아내어 훈장을 추서하고 예우한 해이기도 하다. 유 관순, 윤 봉길 등 네임드급 인물들이 다 이때 훈장을 받았으니 말이다.

1963년 12월 1일이라고 하면 바로 그 정도로 옛날이라고 생각하면 된다. 물론 대한민국이 이 정도로 시스템과 기강이 잡힌 이상, 앞으로 정부가 군무이탈자들을 사면하는 일은 지금 같은 상황에서는 두 번 다시 없을 것이다.

현재까지 행방이 묘연하여 수배 중인 누적 탈영병의 수는 역시나 전군을 통틀어 70여 명 수준이라고 하는데, 공교롭게도 연간 군대에서 발생하는 자살자 수와 얼추 비슷하다. 탈영하고도 안 잡히려면 이 사회에서는 주민등록도 말소되고 그야말로 완전 '없는 사람'으로 지내야 한다. 따로 국가나 군대에서 처벌을 안 해도 그렇게 매장당한 채 고생하는 것 자체가 탈영에 대한 처벌이나 마찬가지이다.

얼마 전에는 어떤 사람이 과거에 열차를 상습적으로 몰래 무임승차 한 것이 마음에 걸려서 무임승차 금액을 변제한다고 코레일에 100만원을 기탁하고 간 훈훈한(?) 사례가 있었다. 그 사건들은 이제 증거도 없고 공소시효도 옛날에 다 지났으니 100만원은 코레일의 입장에서는 그저 기부액이나 마찬가지가 됐다.

마치 그것처럼, 지난 2006년엔 한번은 무려 18년 가까이를 도피 생활을 하는 바람에 심지어 가족하고도 연락이 끊어져 버린 30대 후반의 안타까운 아저씨가 끝내는 자수한 경우가 있었다. 이런 사람은 군대의 입장에서도 병사로 막 부리기가 민망하니.. 그는 1개월 남짓만 형식적으로 병영 캠프를 하다가 복무 부적격 심사에 통과되어 어쨌든 드디어 정식으로 전역했다고 한다.

아무쪼록 우리나라 군대가 탈영병이 발생할 일이 없을 정도로 내부 부조리와 비극이 없는 군대가 되기를 간절히 염원해 본다. 월급을 많이 못 주더라도 병사들의 마음을 사는 방법은 다른 쪽으로도 얼마든지 있기 때문이다.

Posted by 사무엘

오뚜기 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 사무엘