2005년 11월 8일 화요일

시작

이번달 21일에 입대하여 군대를 가게 됩니다. 다른 사람들보다 약간 늦게 가는 편이지만 남들이 이야기 하는 불안감 같은 것은 없고 오히려 편안하고 기대되기까지 하는 것이 첫 시작은 나쁘지 않은 것 같습니다.

제대 이후의 제 인생은 입대 전과 같은 편안한 시간들이 될 것 같지 않아서 당분간 마지막 기회다 생각하여 짧게 여행을 다녀오려 했습니다. 가까운 곳으로 여행가는 것을 생각했었지만, 이런 저런 욕심들이 생겨서 사촌 누나가 살고 있는 필리핀도 생각해보고 선배가 같이 가자고 했던 일본도 생각해 봤었습니다. 그러다가 군대 가기전 가장 만나고 싶은 사람이 독일에 있다는 것에 생각이 미쳐서 결국 독일을 이번 여행의 목적지로 삼게 되었습니다. 총 8박 9일의 일정으로 특별히 다른곳은 가지 않고 그 친구가 살고 있는 에슬링겐만 들리거나 여유가 있으면 한군데를 더 들리기로 하고 7일에 출발하기로 했었습니다. 지금 이 글을 쓰는 시간을 기준으로는 어제인데요. 아침 9시 30분 비행기였는데 7시에 공항 버스를 타고 갔었던지로 완전히 늦어 버렸습니다. 결국 출발하지 못했지만 8일 출발표(결국 오늘이죠)를 구해서 가기로 했습니다.

오늘 공항에서 삽질을 하면서 느낀점들을 간단히 정리해보면 아래와 같습니다.

발권시간에 늦었을 경우 대처방법



  •  
      발권을 위한 창구에 사람이 없을 경우 2층(인천공항)에 있는 해당 항공사 사무실로 찾아간다.

      탑승가능 여부를 물어본다(일반적으로 탑승불가)

      탑승 불가시 티켓을 구입한 여행사에 전화하여 티켓환불을 신청한다(JAL의 경우 환불수수료 1000엔, 여행사는 나름데로의 환불수수료를 받는 경우가 있다. 인터파크 여행사의 경우 2만원).

      목적지로 가는 당일의 다른 티켓을 알아보거나 다음날 티켓을 알아봄(일반적으로 당일티켓은 구하기 힘들다. 성수기에는 다음날 티켓도 구하기 힘들기는 마찬가지 비수기에는 가능).




정리해보니 별일 아니었지만 공항에서는 상당히 당황했었습니다. 몇 번 출국해 봤던터라 별다른 긴장없이 공항에 왔는데 발권하려는 창구에 사람이 없을 때 당황스러운 기분이란.. 잘 못 찾은게 아닐까 몇번을 확인해 봐도 이상이 없었을 때는 정말 당황스럽더군요. 40분전에 갔었던 것 같은데 넉넉잡아 2시간 전에 가라는 말이 정말 가슴에 와 닿았습니다. 이전에는 2시간 전에 왔더니 기다리느라 지겨웠는데, 차라리 기다림에 지루함을 느끼는게 더 안전하다고 생각됩니다.

일단 액댐한거라 생각하고 빨리 가야겠다고 다짐하는 계기가 되었습니다.

더불어 추가 정보.

서울대에서 출발하여 인천공항으로 가는 공항리무진버스를 타고 갔었는데 이 버스가 늦게 된 결정적 원인이었습니다.

공항리무진 버스들을 인천공항전에 10번에서 15번 정도 정차를 하는데 그렇게 정차하면서 시내를 통과하는데 너무 많은 시간이 걸립니다. 특히 아침 9시 30분 비행기처럼 출근시간이 겹쳐있는 경우는 기존에 공지된 공항리무진의 소요시간을 훨씬 웃도는 시간이 걸립니다.

제가 낙성대에서 7시에 승차해서 갔었는데 9시 거의 다 되어 도착하였으니 공지되어 있는 시간보다 30분정도 오차가 있었습니다. 결국 집에서 가까운 공항리무진 버스를 이용하는 것이 좋긴 하지만 중간정차역이 많은 경우 출근시간이나 퇴근시간과 같은 외부적인 요소로 인해 시간이 더 지연될 가능성이 있다는걸 염두에 두고 이용하는게 좋을 것 같습니다.

당연한 내용이지만 의외로 먼 인천공항까지의 거리와 러쉬아워의 혼잡이 더해지면 치명적인 위험이 될 수도 있다는걸 알아야 하겠습니다. 네이버 등에서 검색해보면 공항리무진은 아니라고 하던데 609번 버스의 경우 공항리무진과 같은 플랫폼에서 승차가능합니다만 직행이라 1시간만에 도착할 수 있습니다.

공항에서 오는 길에 강남역을 가기 위해서 609번 버스를 이용하였는데 올림픽대로를 이용하여 빠른 속도로 도착할 수 있었습니다. 가격이 8000원이라 일반 공항리무진보다 500정도 비싸지만(혹은 같은 가격) 훨씬 빠르게 갈 수 있으므로 올림픽대로까지 막히는 상황이 아니라면 이용해볼만 하다고 생각합니다.

고속버스터미널에서 길건너 반포종합상가 앞에서 승차할 수 있습니다. 게다가 공항리무진의 경우 5시 40분경에 첫차가 출발하지만 609번 버스는 일반 서울버스와 마찬가지로 4시 20분경에 첫차가 있으므로 아침 일찍 공항에 가야하는 경우에도 유용하다고 생각합니다.

2005년 10월 17일 월요일

대안언어축제 - Ajax

8월 20일부터 21일까지 이틀동안 비발디파크에서 1회 대안언어축제가 있었습니다.
처음 축제를 같이 제안하여 기획에도 참여했었기 때문에 제게는 더욱 기억에 남는 행사입니다. 덕분에 좋은 분들도 많이 알게 되었고 즐거운 시간도 가질 수 있었습니다.

그런데 시간이 지난 뒤 생각해보니 제가 세션을 하나 맡아서 발표를 했었는데 지금까지 그 자료를 올리지 않았었단 사실이 기억났습니다. 물론 제 자료가 그다지 볼게 없기 때문에 찾으시는 분도 없으시겠지만 혹시나 도움될지 몰라서 자료를 이곳에 올립니다.

기존의 Ajax관련 발표자료들과 이리저리 비슷한 면이 많기 때문에 특별한걸 원하시는 분들은 굳이 보지 않으셔도 상관없구요. 이 발표의 핵심은 중간에 있었던 간단한 Ajax프로그램 제작이었지만 이 자료에는 언급되어 있지는 않습니다. 특별히 발표를 녹화하지도 않았기 때문에 발표 전부를 이 자료를 통해서 느끼기는 어려울 것 같습니다.

대언언어축제 Ajax세션 자료(PDF)

2005년 9월 6일 화요일

네트워크를 훔쳐라 : Stealing the Network

네트워크를 훔쳐라
Ryan Russell 외 지음, 강유 옮김/에이콘출판


제가 워낙 다양한 부분에 관심을 가지고 있어서 예전에 크래킹이나 보안부분을 공부하기도 했었습니다. 학교에서는 보안팀에 속해 있었기도 해서(실제로 보안작업은 거의 안했지만) 관심을 가지고 봤던 기억이 있습니다.

덕분에 왠만한 수준의 시스템 보안이나 심심풀이 크래킹 정도는 가능하게 되었는데요(스크립트 크래킹 말이죠). 이 분야도 깊게 들어가면 장난이 아닌지라 발만 잠깐 담그고 요즘은 거의 보지 않고 있었습니다.

그런데, 보고 싶어지는 보안 분야 책이 있어서 그 책을 사면서 몇권 같이 주문했던 책 중에 '네트워크를 훔쳐라'가 있었습니다. 일단 다른 사람들 서평을 보고 마음이 끌렸습니다. 해킹이나 크래킹이나 보안 서적들 중에서는 말 그대로 쓰래기에 가까운 책들이 꽤나 있어서 함부로 사는걸 꺼리게 만드는데, 일단 역자가 꽤나 유명하신 분이라 맘에 들었고 서평을 보니 심심하진 않을 것 같아서 같이 구입했었습니다.

읽기 시작했던 건 한달전인데 중간에 다른 책들도 읽고 이런 저런 사정으로 며칠전에 완독했습니다. 그렇다고 책이 어렵다거나 진도가 안나가는건 아니구요. 평이한 수준(물론, 이 분야 서적중에서 -_-;)에 쉽게 쉽게 읽힙니다. 그렇다고 내용이 황당무계하다거나 하지도 않고 정석 전문 보안 이야기들을 담고 있습니다. 최근 케빈 미트닉의 해킹, 침입의 드라마와 비슷하기는 한데, 그보다 더 기술적인 서술이 포함되어 있습니다. 해킹툴 같은 것도 원래 이름을 그대로 밝히고 있어서 현실감을 주는데 일조했던 것 같습니다.

각 에피소드 별로 사용하는 기술적이나 사회공학적 기법들이 다르게 구성되어 있고, 등장 인물의 역할이나 캐릭터가 달라서 실제 사례에 관한 기본적이 교제로도 이용할 수 있을 것 같다는 생각이 들었습니다. 다만, 시간적인 격차 때문에 최근의 흐름과 일치하지 않는 부분도 있지만 일반적인 흐름은 거의 변하지 않았기 때문에 요즘에도 충분하게 이용할 수 있고 경계해야 할 부분들을 잘 집어줍니다.

이야기를 읽다보면 결국 보안은 인간의 문제로 끝나는데요. 이는 본질적인 보안의 문제라고 생각합니다. 아무리 완벽한 보안을 구축하더라도 그 연결고리에 포함되어 있는 인간이라는 불확정 요소로 인해서 단단한 보안이 무너질 수 있다는 거죠. 그걸 잘 알고 있는 침입자들은 그 문제를 이용하는 것이구요.

괴짜경제학 : Freakonomics

괴짜경제학
스티븐 레빗 외 지음, 안진환 옮김/웅진지식하우스(웅진닷컴)

전 경제학을 전공하지도 않고, 경제학에서 사용하는 수학이랑은 친하지도 않은데다, 주변에 아는 경제학자도 없지만 경제학에 상당히 관심을 가지고 혼자서 책도 보고 생각도 하면서 공부를 하고 있습니다.

흔히 프로그래밍은 공학 쪽에 속하는 지라 프로그래머는 인문,사회과학 분야와 관련이 없다고 생각합니다. 하지만 실제 프로그래밍 분야나 다른 많은 공학에 속하는 학문에서는 다양한 인문, 사회과학 분야의 지식을 이용하며 경제학도 그 중에 하나입니다. 고리타분한 말 같지만 모든 학문은 결국 통하는 것이겠죠.

그래도, 제 얇은 수준의 경제학 지식으로는 전문가 수준의 경제학 공부를 하기 힘들겠죠. 그래서 저는 주로 경제학 입문서나 실용 경제학 같은걸 공부합니다. 거시경제학같은 것 보다는 미시경제학쪽을 주로 공부하고 있습니다. 경제학을 좋아하고 공부를 하고 있기는 하지만 아무래도 경제학의 한계 같은 것을 생각하지 않을 수 없습니다. 실제 경제학이라는 학문이 깊게 들어가면 들어갈 수록 현실과의 괴리를 자아내는 학문이라 그 함정에 빠지지 않고 제게 도움이 되는 정도에서 그 부근을 주로 볼려고 노력하고 있죠.

잡설이 길었습니다. 위의 잡설의 요는 '결국 어떤 것을 하든 다양한 학문이 필요한 경우가 생기니 미리 미리 공부하면 좋다.' 입니다. 결국 공부해서 남주냐 라는 식이겠죠. ^^

여하튼, 괴짜경제학을 보면서 제가 평소에 가지고 있던 생각을 한번 더 확인 할 수 있었습니다. 사회의 현상이란 그렇게 자로 길이 재듯이 어떤 한 이론을 이용해서 이래서 이렇다 라고 말하기 힘들다는 거죠. 이론이란 것은 결국 어떤 현상을 일반화 한 것인데요. 일반화란 과정은 필연적으로 현상에 영향을 주는 요소(factor)를 제거하는 과정이 포함되기 마련입니다. 그래서 결국 법칙이 될 수 없는거죠. 특히, 과학이나 수학같은 그나마 근사 혹은 정확한 예측이 가능한 이론이 아니라 사회과학 등의 결국 인간이 관계된(돈도 인간이랑 관계있죠) 학문의 이론들은 십중팔구는 근사 혹은 유형을 알려주지 정답을 알려주지는 않습니다. 결국 우리는 현상을 보고 그 원인을 예측하지만 그 예측의 기반이 되는 이론이 정확하지 않을 수도 있기 때문에 예측 자체가 틀릴 경우가 있다는거죠.

괴짜 경제학은 그런 일반적인 예측이 틀렸을 수도 있다면서 색다른 예측을 제시하고 있습니다. 결국 이책의 저자인 스티븐 레빗도 경제학자이기 때문에 먼저 기존 예측의 오류를 자세히 분석합니다. 그리고 자신의 대안이 옳다고 생각하는 이유를 이야기 하죠. 그 결과 '교사와 스모 선수의 공통점은?'같은 의도적이면서 도발적인 소제목들이 나오는거죠.

하지만 세상의 모든 일들이 생각지도 못했던 이유들로 발생된다면 기존의 경제학자들을 할일이 없겠죠. 대부분의 많은 사회의 일들은 경제학자나 사회학자들의 이론으로 설명되는 경우가 많습니다. 앞에서 말한 것처럼 이론이란 것은 결국 현상에서 발생하는 것이기 때문에 현상의 모습을 담고 있죠. 하지만 어떤 현상이 다른 현상들과 비슷해 보이지만 실제 원인이 달랐을 경우도 있습니다. 그런 경우도 생각하면서 비판적인 시작을 가져보자는게 저자의 생각이 아니었을까 생각이 듭니다. 물론, 책에는 그런말은 써져있지 않지만요.

2005년 9월 2일 금요일

실용주의 프로그래머 : 예외 처리


우리는 예외가 프로그램의 정상 흐름의 일부로 사용되는 일이 거의 없어야 한다고 믿는다. 예외는 의외의 상황을 위해 남겨두어야 한다. 잡히지 않은 예외는 프로그램을 종료시킬 것이라고 가정하고, '모든 예외 처리기(exception handler)를 제거해도 이 코드가 여전히 실행될까.'라고 자문해 보자. 만약 그 답이 '아니오.'라면 아마도 예외가 비예외적인 상황에서 사용되고 있는 것이다.

"실용주의 프로그래머" page 208


처음 C 언어를 배워서 프로그래밍을 할 때는 사용자가 관리자의 의도와 상관없는 행동으로 프로그램이 에러가 날 수 있는 부분을 if나 다른 명령을 통해서 처리하였습니다. 그 뿐만 아니라 시스템이나 다른 외부의 영향에 의해서 프로그램이 오동작 할 부분도 처리를 했었죠.

이런 기법들이 자바나 파이썬 등과 같은 예외 처리(Exception handler)를 지원하는 언어들을 만나면서 예외를 이용한 에러처리 방법으로 바뀌게 되었습니다. 이 방법이 기존의 if를 이용하는 방법에 비해서 여러면에서 쉬웠기 때문에 실제 코드에서 이용하게 되는 일이 많아졌는데요, 어느 때 부턴가 예외가 그렇게 좋은 것은 아니다 라는 말을 듣게 되었습니다. 그래서 왜 좋지 않은지 찾아봤으나 잘 이해가 되지 않았었는데, 오늘 위의 인용된 글을 읽으면서 머리를 관통하는 생각이 있었습니다.

결국 예외라는 것은 프로그램의 정상적인 흐름을 방해하는 부정적인 요소들이며 그 부정적인 요소들을 처리하기 위한 방법으로 예외 처리를 쓰는 것이라는 걸 알았습니다. 결국 무심하게 사용했던 당연하게 예외가 발생할 부분을 만들고 그걸 처리하는 부분에 프로그램의 루틴을 넣었던 것이 문제였다는 것을 알게 되었습니다. 예외를 처리하기 위해 예외 처리를 사용하는 행위 자체에서 새로운 문제가 발생할 수도 있다는 것을 알고 사용하는 것은 무심하게 사용하는 것과 차이가 있을 거라 생각합니다.

"실용주의 프로그래머"의 저자는 우리가 경계해야 하는 이유에 대해서 명확하게 설명하고 있습니다.


왜 우리는 이런 식으로 예외에 접근할 것을 제안하는가? 예외가 있다는 것은 즉 컨트롤의 이동이 즉각적이고 로컬하지 않다는 것을 말한다. 일종의 연쇄 goto 같은 것이다. 예외를 정상적인 처리 과정의 일부로 사용하는 프로그램은 고전적인 스파케티 코드의 가독성 문제와 관리성 문제를 전부 떠안게 된다. 이런 프로그램은 캡슐화 역시 깨트린다. 예외 처리를 통해 루틴과 그 호출자들 사이의 결합도가 높아져 버린다.

"실용주의 프로그래머", page 210

특정 도메인 언어 Domain Specific Language

이번달 초에 샀던 책이지만 요즘에서야 실용주의 프로그래머를 보고 있습니다. 예전에 원서로 조금 봤었는데, 역시 원서는 노력이 없으면 진도가 그렇게 잘 나가지 않는터라 이번에 나온 번역서를 얼마나 기다렸는지 모릅니다. 역자이신 김창준씨와 약간의 인연이 있어서 번역서가 나온다는 소식을 먼저 듣긴 했는데 그 덕분에 다른 사람들보다 더 오래 기다렸던 것 같습니다. -_-;

지난 대안언어축제에서 김창준씨의 언어속언어세션을 들으면서 처음으로 DSL(Domain Specific Language)에 대해서 알게되었습니다. 물론 알고보니 그동안 제가 사용했던 적도 있고 생각했었던 개념이긴 했지만 언어에 기반한 문제 해결이 아니라 문제 해결에 기반한 언어를 생각하는 방식은 참신하고 즐거운 생각이었습니다. 실제로 세션에서 진행되었던 프로그래밍 부분에서는 간단한 프로그램을 설계했었지만 기존의 방식과 다른 EDSL(Embeded Domain Specific Language)를 이용한 설계에서 많은 것을 배울 수 있었습니다.

그렇게 DSL과 첫만남을 했었는데, 요즘 실용주의 프로그래머를 읽다보니 12장에 "도메인 언어"라는 챕터명으로 DSL에 대하여 설명이 나와 있는 것을 보고 굉장히 반가운 마음이 들어서 읽어보았습니다.

DSL은 결국 프로그래밍 언어



DSL은 말 그대로 어떤 영역에 특화된 언어입니다. 우리가 가장 흔하게 접할 수 있는 것으로는 퀘이크 등의 FPS게임의 스크립트 언어를 들 수 있는데요, 대부분의 이런 게임에 내장되어 있는 스크립트 기능을 이용해서 새로운 MOD(Modification)를 만들 수 있습니다. 게임에 내장된 언어를 이용하여 새로운 게임을 창출하는 거죠. 스타크레프트나 워크레프트3의 경우도 Custom Map을 디자인 할 수 있는 툴을 제공합니다. 툴에는 맵 디자인 뿐 아니라 스크립트엔진도 포함되어 있어 게임을 제작할 수 있죠. 실제 워크레프트3에 있는 시나리오 캠페인은 워크레프트3의 맵 제작기로 제작한 것이라 합니다.

게임 분야 뿐 아니라 CAD나 Maya와 같은 그래픽 프로그램에도 특화된 언어를 제공하고 있습니다. 더 일반적인 예로는 Excel의 매크로가 있겠죠. 이러한 DSL들은 프로그램을 더 강력하게 하고 일반적인 한계를 넘어서는 것 뿐만 아니라 프로그램의 사용을 더 편리하게 하는 역할도 합니다.


Battlefield 1945 Desert Combat Mod
Battlefield 1942의 Mod중 가장 인기가 많았던 Desert Combat


DSL을 이용한 개발



좀 더 넓게 생각해보면 프로그램 개발에도 DSL을 이용할 수 있습니다. 대부분의 프로그램은 해결을 하기 위한 어떠한 문제가 존재합니다. 예를 들어 포토샵의 경우는 이미지를 편집해야 한다는 문제가 존재합니다. 우리가 이러한 프로그램을 만들면서 그 프로그램이 해결해야 할 문제를 알고 그 프로그램이 어떠한 영역에서 작동하는지 파악하면, 그 문제를 그 문제의 영역의 표현으로 기술할 수 있습니다. 그리고 그렇게 기술하는 언어가 DSL이 되는 것입니다.

"실용주의 프로그래머"에서의 예를 들면

일련의 X.25 선에서 ABC 규칙 12.3에 정의된 트랜잭션에 귀 기울이고 있다가, 트랜잭션이 오면 XYZ 회사의 43B 형식으로 바꾼 다음, 그것을 위성 통신을 이용해 다시 전송하고 추후 분석용으로 저장해 둡니다.


라는 문제를 해결하는 방법을 클라이언트가 정의하였다면 아래와 같은 소형 언어(mini language)로 표현할 수 있습니다.


From X25LINE1 (Format = ABC123) {
Put TELSTAR1 (Format = XYZ43B);
Store DB;
}


실제로 이렇게 쓰고 실행이 가능하다면 프로그램을 쉽게 작성할 수 있을 뿐 아니라, 추후 관리에서도 많은 도움이 될 것입니다. 실제 이와 같은 개발을 위해서는 사용할 소형 언어에 필요한 기능들을 구현하고 언어를 위한 간단한 인터프리터나 컴파일러를 구축합니다. 그렇게 만들어진 언어에는 우리가 만들고자 하는 프로그램에서 다루어야 할 문제에 대한 해결방법이 들어 있기 때문에 그 언어를 이용해 자연스럽게 목적 프로그램을 작성할 수 있습니다.

이러한 방식의 프로그래밍을 Buttom-Up Programming이라고 부릅니다. 기존의 프로그램 작성법인 Top-Down Programming에서는 프로그램을 몇개의 기능이나 다른 분류방법에 따라 분류한 후 그걸 또 분류하여 작성하는 방법을 택하였지만, Buttom-Up Programming에서는 그 기반이 되는 언어를 구성하고 그 언어를 기반으로 프로그래밍 하는 방법을 이용합니다.

연습문제


"실용주의 프로그래머" 챕터 12에 있는 연습문제 5번을 끝으로 이 글을 간단히 끝내려고 합니다. 제 생각에는 이 문제에 DSL의 장점과 개념이 들어 있는 것 같습니다. 이 문제는 문제를 푸는 것보다 문제를 보는 것이 중요할 것 같네요.

5. 우리는 간단한 그리기 프로그램을 제어하기 위해 소형 언어를 하나 구현하려 한다. 이 언어는 한 글자짜리 명령으로 구성되는데, 어떤 명령은 뒤에 한 자리 숫자가 따라 나올 수도 있다. 예를 들어, 다음을 입력하면 사각현이 하나 그려진다.

P 2 # 2번째 펜을 선택한다
D # 펜을 종이에 내려놓는다
W 2 # 서쪽으로 2cm 이동하며 그린다
N 1 # 그 다음 북쪽으로 1cm 이동하며 그린다
E 1 # 그 다음 동쪽으로 2cm 이동하며 그린다
S 1 # 그 다음 다시 남쪽으로 그린다
U # 펜을 종이에서 든다.


이 언어를 파싱하는 코드를 구현하라. 코드는 새로운 명령어를 추가하기 쉽게 설계되어야 한다.

2005년 8월 25일 목요일

프로젝트 소스 빌드툴 : Cruise Control

Cruise Control : 지속적인 빌드 관리 시스템


일일빌드와 통합소스관리를 통한 프로젝트의 혁신을 꾀한다면 SVN(Subversion)과 Ant같은 빌드관리툴의 사용이 필수적입니다. - MS에서 내놓은 소스 버전 컨트롤 툴들이 있기는 하지만 일단 오픈소스 관점에서 살펴보려고 합니다. 제가 아는게 이쪽 뿐이라 그런거니 다른 MS제품이 궁금하신 분께 양해를 구합니다. - 자바의 경우 Ant나 Maven을 주로 사용하겠고 C나 C++의 경우는 make를 이용하여 빌드를 할 것입니다. 이런 프로그램들은 목적 언어가 약간씩 다를지라도 프로그램을 빌드하기 위한 과정을 일괄처리 할 수 있도록 돕고 최대한 자동화된 처리과정을 제공하는 점에서 비슷한 기능을 한다고 볼 수 있습니다. 이들 프로그램은 프로젝트 빌드를 위한 충분한 기능을 제공하고 있지만 CVS(Concurrent Versions System)이나 SVN과 같은 버전 컨트롤 시스템을 사용하여 소스를 관리하고 UnitTest를 위한 TestCase를 포함하고 있는 프로젝트의 경우 항상 최신의 소스를 유지하면서 빌드하고 빌드 결과 뿐 아니라 테스팅 결과도 날마다 생성하게 하는 작업은 불가능합니다. 이와 같은 작업을 위해서 Shell Script로 비슷한 약할을 하는 프로그램을 작성하여 쓰기도 하는데 제가 오늘 소개해 드릴 Cruise Control은 이런 작업에서 최적화 되어있는 프로그램이며 간단한 설정으로 전체빌드 과정을 통제할 수 있습니다.

Cruise Control의 특징



  • 소스저장소와 빌드소스를 동기화 시켜줍니다

  • 빌드후 결과를 웹으로 보여주고 메일로 전송도 가능합니다

  • UnitTest결과를 보고서로 보여줍니다



Cruise Control이 필요한 사람


현재 Cruise Control이 최대의 성능을 발휘할 수 있는 환경은 다음과 같습니다.
Ant혹은 Maven을 이용하여 빌드를 관리하는 프로젝트이며 CVS나 SVN을 통해서 소스통합과 버전관리를 하는 프로젝트. 더불어 UnitTest Framework를 사용하여 TestCase를 가지고 있는 프로젝트



Cruise Control Setting


Cruise Control Getting Started에 Cruise Control을 세팅하는 기본적인 부분이 나와 있습니다. 설정의 세세한 부분은 Getting Started 문서를 참조하시길 바랍니다. 이 글에서는 문서에는 나와 있지 않은 svn과의 연동 부분에 대해서 설명하려고 합니다.

문서에는 기본적으로 ant를 이용한 cvs와의 연동을 가정하고 설명하고 있습니다. 하지만 기본적으로 svn은 cvs에서 파생된 프로그램이라 봐도 무방하기 때문에 설정도 많이 바뀌는건 없습니다. 그리고 Cruise Control에도 기본으로 svn플러그인이 포함되어 있기 때문에 설정파일만 수정하면 간단하게 사용할 수 있습니다.

일단 제가 사용하는 config.xml 파일을 보면서 설명을 하겠습니다.





















buildfile="/home/minfra/build-PCT.xml"
target="build"
uselogger="true"
usedebug="false"/>












기본적으로 Getting Started에 있는 config.xml 예제와 같습니다. 수정된 부분은






이 부분이 추가된 것과







이 부분이 변경된 정도입니다. 나머지는 ant파일의 위치같은 사소한 수정이 있습니다.

위의 수정되거나 추가된 코드 부분이 svn을 위한 세팅입니다. 다른 프로젝트에 이 설정을 사용하더라도 위의 svn부분은 수정할 필요가 없습니다. 위의 코드들은 svn에 대한 세팅 정도만 표시되어 있기 때문에 실제 svn의 작업이 이루어지게 하는 부분이 필요합니다. 그 작업은 config.xml에 ant 파일로 지정된 파일에서 이루어집니다.

결국 config.xml을 통해서 빌드 시스템의 세팅이 이루어지고 실제 빌드 작업은 ant 태그에 설정된 build-PCT.xml을 통해서 이루어집니다(혹시나 해서 하는 말이지만 파일이름은 아무래도 상관없습니다). build-PCT. xml에 실제 프로젝트 빌드를 위한 루틴을 넣어도 되겠지만 관리의 편리성을 위해서는 실제 빌드를 위한 파일은 build.xml를 만들어 소스 디렉토리에 추가 시키고 Cruise Control을 위한 파일들은 외부에 두어 빌드 루프가 실행되도록 하는 것이 좋습니다.

build-PCT.xml













위 xml문서의 아래 부분을 통해서 checkout 되어 있던 소스디렉토리가 update되면서 프로젝트를 빌드하게 됩니다. 다만, 이와 같은 설정을 사용할 경우 미리 프로젝트 디렉토리를 관리자가 checkout 해 두어야 합니다.






Cruise Control 실행


모든 설명이 끝나면 세팅 완료 후 빌드 시스템을 실행시켜야 합니다.
문서에 나와 있는 것과 같이 INSTALL_DIR/main/bin/cruisecontrol.sh 를 실행시키는 것으로 실제 프로그램은 동작합니다. 다만 사용자가 직접 실행시킬경우 현재 화면에 실행되기 때문에 cruisecontrol.sh & 처럼 백그라운드로 실행시키거나 cron에 등록시켜 실행되도로 하면 됩니다.

Cruise Control은 소스 저장소를 확인하면서 변경된 사항이 있을 경우 로컬의 소스 디렉토리를 업데이트하고 새로 빌드합니다. 이때 소스 저장소를 확인하는 주기는 5분정도 입니다. 이로 인해 개발자가 소스를 커밋한 다음 이 소스가 실제 시스템에서 빌드되는데 약 5분정도의 지연이 있게됩니다. 그리고 성공적으로 빌드 되어을 경우 보고서를 작성하는데 빌드에 실패했을 경우에도 보고서를 작성하게 되므로 빌드에 실패한 소스를 고치지 않고 계속 방치할 경우 5분에 한번식 실패보고서가 만들어지게 됩니다. SMTP를 이용해서 email로 보고서가 전송되도록 했을 경우 하루만 방치하더라도 수십통의 메일이 오겠죠. 이런 황을 방지 하기 위해서 빌드 실패에 대한 책임을 미리 정해서(마지막 커밋한 사람이 책임지고 성공하게 한다던지, 실패를 본 처음 사람이 한다던지) 관리하면 최대한 성공적으로 빌드되는 소스를 보유할 수 있습니다.

BEAT SPACE NINE : m-flo

M-Flo - Beat Space Nine
M-flo 노래/(주)에스.엠.픽쳐스


m-flo의 새앨범이 발표되었습니다. 제가 일본 사정에 능숙하지 못하고 엘범 구조를 잘 몰라서 이게 새로운 엘범인지 모움집인지 모르겠습니다만, 일단 들어본 적이 없는 노래들이니 새로운 앨범이라 생각합니다.

BEAT SPACE NINE이라니 뭔가 해석을 해라고 만든 제목은 아닌 것 같네요. 금방 安藤日記에서 확인하고 혹시나 하는 마음에 쥬크온을 실행시키고 검색했더니 업데이트 되어 있네요. -_-;

그 쪽 사람중에 m-flo를 좋아하는 사람이 있는건지, 누군가 미리부터 언급을 했던건지는 모르겠습니다. 제가 찾는 음원중 몇개는 없곤해서 실망을 주었던 쥬크온이 오랜만에 만족스럽네요. 3000원 정액요금은 계속 사용해도 될 것 같습니다. 이 글을 쓰기 위해서 쥬크온 홈페이지에 오랜만에 들어갔더니 Craig David의 새 엘범도 나왔네요. 오랜만에 즐거운 엘범의 연속입니다. 조만간 CD를 주문하던지 hot track에 한번 들러야 할 것 같습니다. 예전에 받은 도서상품권도 지갑에서 계속 썩어가고 있으니 써보는 것도 나쁘지 않겠죠.

이번 엘범에는 예전에 싱글로 나왔던 "let go" 가 포함되어 있고 원래 멤버였던 LISA와의 곡도 들어 있습니다. 5번 트랙에는 휘성과의 곡도 있군요. 지누션과 친한 m-flo이니 어떻게 그쪽으로 인연을 가져서 참여하게 된게 아닐까 생각합니다만. 이미 알고 있었던 사이였을 가능성이 높겠죠. 저야 그 사람들이랑 친하게 지내는 사이가 아니니 어떻게 알겠습니까. ^^

전체적으로 Astromantic 만큼 호화멤버로 만든 엘범은 아니지만 상관없이 좋습니다. 뭐, 제가 m-flo좋아하니 그런말을 하는 것이겠지만, 이 사람들의 특징은 아주 대충적인 랩이니(요즘이야 말이죠) 많은 사람들의 공감대를 자극할 수 있는게 아닐까 합니다. 랩으로 사랑타령 하는건 별로 좋아하지 않았는데 이상하게 m-flo에는 관대해지는군요.

조만간 Craig David 의 새 엘범도 들어보고 이야기를 늘어보도록 하겠습니다. m-flo는 역시 노래만 열심히 들었던 예라 말을 하고 싶어도 별로 할말이 없네요. 아.. 좋네요 들어보세요. 이정도가 제가 할 수 있는 말일 듯 합니다.

BEAT SPACE NINE
1.BEAT
2.Taste Your Stuff/loves BENNIE K
3.Loop In My Heart/loves EMYLI & YOSHIKA
4.SO EXCLUSIVE/loves Sowelu
5.I'M DA 1/loves WHEE SUNG
6.ONE DAY/loves 加藤ミリヤ
7.A.D.D.P./loves MONDAY満ちる
8.tO yOUR bEAT/loves YOSHIKA
9.SPACE
10.DOPEMAN?/loves EMYLI&Diggy-MO'
11.COZMO-NAUGHTY/loves Kahimi Karie
12.The Other Side of Love/loves EMYLI
13.Float'n Flow/loves Rie fu
14.HEY!/loves Akiko Wada
15.let go/loves YOSHIKA
16.TRIPOD BABY/loves LISA
17.NINE

2005년 7월 21일 목요일

메타 블로그에 대한 생각

국내에는 다양한 설치형 블로그나 서비스형 블로그가 있습니다. 개인별로 생각하는 건 다를 수 있겠지만 제 생각으론 사용하기에 불편함이 없을 수준의 프로그램들이 충분하게 있다고 봅니다.

그 런데 유독 메타 블로그 프로그램은 특별하게 사용할 만한 것들이 없는게 이상하게 생각 되었습니다. 물론 메타 블로그라는 시스템이 여러 사이트가 동시에 존재하기 보다는 포탈 형식의 한곳으로의 집중이 유리한 면이 있습니다. 하지만 개념을 바꿔서 생각해보면 조그만 그룹들들을 이어주는 연결 역할을 하는 메타 블로그 시스템들이 유기적으로 연결되어 커다란 시스템을 구성해보면 어떨까 생각이 들었습니다.

이미 웹에서는 이런 아이디어가 많이 퍼져 있습니다. WEB2.0이 그러하고 몇몇 P2P프로그램 역시 그러합니다. 위키 시스템도 한나의 위키가 일종의 정보저장소의 역할을 하기도 하지만 다른 위키들과 소통을 하기 위해서 시스터위키 같은 시스템을 이용하고 있습니다. 메타 블로그 시스템도 서로 다른 피드들을 공유하거나 자신들이 수집한 피드들의 정보를 통해서 새로운 2차적인 정보를 생산할 수 있다면 재밌는 일이 생길 수 있을 거라 생각했습니다.

결과적으로 이번에 시작한 한양메타블로그 프로젝트는 새로운 방식의 메타 블로그 시스템을 구축해 보자는 시도인 것입니다. 일단 제가 다니는 한양대학교의 블로거들을 위한 시스템을 구축해야 하겠죠. 그리고 완성 결과를 오픈소스로 공개하여 다른 시스템도 생겨날 수 있도록 하려고 합니다. 물론 프로젝트는 지속적으로 진행되면서 프로그램은 발전해 나가야 하겠죠.

일단 초기에 진행되는 과정에서는 프로젝트 공개를 하지 않고, 1차 완성이 되는 시점에서 SourceForgeKLDP.NET에 등록하고 그곳을 통해서 지속적인 배포를 하려고 합니다.

현 재 다양한 시도를 염두에 두고 있습니다. 메타 메타 블로그 시스템(위에서 설명한 연동하는 메타 블로그)을 비롯해서 팟캐스팅을 좀 더 편하고 현실적으로 지원할 수 있는 방안도 생각중이고(기존의 제공 방법은 서버의 트래픽 문제나 등록이 불편한 점 등의 문제가 있는 것 같습니다) API제공이나(당연하겠습니다만) 기존의 피딩 방식에서는 코멘트나 트랙백을 알기 힘든 점도 어떻게 향상시킬 수 있을지 생각하고 있습니다.

중간 중간에 저작권 문제나 피딩 수집의 공개정책 같은 사안들에 부딪칠 수 있겠지만 일단은 기술적인 부분에 중점을 두고 프로그램을 개발해 나갈려고 합니다. 운영시에 발생할 수 있는 다양한 문제들은 시험 운영을 통해서 체크해 나갈려고 합니다.

2005년 6월 9일 목요일

조엘의 생각을 들어보자





조엘 온 소프트웨어
조엘 스폴스키 지음, 박재호.이해영 옮김/에이콘출판

해외의 개발자 사이에서는 이미 많이 알려져 있는 컬럼(혹은 웹로그)인 Joel on Software는 외국의 개발자 메일링 리스트를 구독하다보면 가끔 인용당하는(?) 그의 글로 인해서 내게도 익숙했다.

우리나라에서는 안철수 연구소에서 몇몇 글들을 번역해주고 있기 때문에 이미 알고 있는 사람들은 조엘테스트니 일별 빌드니 하는 것이 어느정도 익숙할 것이다. 다만 안랩에서 모든 글을 번역한게 아니라서 영어가 부족한 나와 같은 사람에게는 아쉬운 점이 있었는데 그의 블로그와 같은 제목으로 미국에서 출간되었던 책이 번역되어 접하게 되니 반가운 마음을 금할 수가 없었다.

 예약 구매로 도착한 다음날에 다 읽어버렸다. 굉장히 직설적인 방법으로 이야기를 하는 그의 글은 시원한 느낌과 함께 즐거움을 안겨주었다. 특히 얼마전에 읽었던 The Art of Unix Programming과 여러모로 비교되면서 이런 저런 생각을 해볼 수 있어서 즐거움은 배가 되었다. 직설적인 화법의 소유자답게 그는 레이몬드(TAOUP의 저자)의 의견에 동감하는 부분은 인정하면서도 그의 생각과 일치하지 않는 부분에는 단호하게 아니다라고 말한다.

예를 들어 레이몬드는 TAOUP에서 GUI(Graphic User Interface)와 CUI(Console User Interface)를 이야기 하면서 GUI는 확장성이나 효율성등의 면에서 유닉스의 전통적인 CUI프로그램(pipe를 이용하고 한가지 용도에 최적화된)에 못미친다고 이야기 한다. 그는 CUI프로그램에 GUI로 인터페이스를 구축하는 방식이 더 유연한 방식이라고 보는데, 이에 대해 조엘은 CUI방식을 고입하는 것이야 말로 Usebility를 해치는 것이라 말하고 있다.

난 UNIX스타일의 개발을 더 좋아하기 때문에 조엘의 생각은 내 생각과 다른 부분도 있었다. 하지만, 근거 없이 GUI가 우월하다고 이야기하는 그런 방식의 전개가 아니고 조엘 나름데로의 경험과 생각을 기반으로 하고 있어서, 일견 그의 생각에서도 많은 것을 배우고 타당점을 찾을 수 있었다.

분명히 다른 프로그램과의 인터페이스 측면이나 자동화 측면, 그리고 프로그램에 어느정도 익숙해질 숙련 사용자를 위한 면에서 CUI인터페이스 제공과(레이몬드 역시 무조건 적으로 GUI를 비판하는 것이 아니라 CUI를 기반으로 하는게 어떨까 하는 의견이다) 텍스트 기반의 통신이 좋을 것이다. 하지만 프로그램을 가볍게 사용하는 라이트유저나 프로그램의 사용성(단순하게 사용하기 편리한) 향상을 위해서는 잘 설계된 GUI역시 많은 도움이 될 수 있을 것이다.

결국, 여기에서는 프로그램의 사용 환경에 따른 선택이 중요하게 작용할 것이며, 우리가 평소 이야기 하듯 상황에 따른 선택이 중요할 것 같다.

개인적으로는 GUI프로그램들이 CUI인터페이스를 제공하는 것도 좋을 것 같다고 생각한다. 직접 프로그램을 사용하면서 CUI인터페이스의 필요성을 느낀 경우가 많았는데, 특히 작업을 자동화해서 여러 프로그램에게 협업을 시키게 한다는 부분이든지 프로그램을 테스트 할 경우에서 편리한 점이 많았다.

개발자들 사이에서 이견을 발견하는 것은 쉬운 일이지만 어느 정도 정점에 선 사람들이 그렇게 다른 의견을 이야기 하는 것은 언제나 많은 교훈을 준다. 각자의 의견은 대부분 일리가 있고 나름데로 타당한 이유를 가지고 있기 때문에 내가 몰랐던 부분들에 대해서 생각해 볼 수 있는 기회를 주고 내 생각을 정립할 수 있는 기회가 된다. 조엘의 책에서는 그와 다른 개발자 사이의 이견들을 발견할 수 있고 각각의 주장들을 접할 수 있다(조엘은 대부분 상대 주장도 싣거나 출처를 제시하고 있다).

책을 읽으면서 그렇게 접한 다른 주장들도 시간을 내서 알아보거나 읽어본다면 많은 도움이 될 수 있을 것이다.

책에도 나오고 있지만, 조엘이 제시하여 상당히 유명해진 조엘 테스트 라는 것이 있다. 한 조직을 평가하는 기준으로 12가지의 테스트를 만들었는데, 전체 몇 개의 테스트를 통과했는지에 따라 조직을 평가한다. 각 테스트마다 1점으로 12점은 완벽한 조직, 11점은 괜찮지만 10점 이하는 문제가 있는 것으로 평가한다. 방법론이나 개발방법에 대한 테스트가 아니라 단순하게 조직의 질을 테스트하는데 목적을 두고 있는 것 같은데, 우리나라에서 12점 만점을 받는 조직은 몇개 안될 거란 생각이 든다(솔직히 하나라도 있을까?). 물론 우리나라의 문화적인 차이 때문에 조엘 테스트 중에 적합하지 않은 것도 있을 수 있지만, 조엘 테스트에서 좋은 점수를 받기 위해 노력하는 조직은 더 높은 수준의 질을 유지할 수 있을거라 생각한다. 조엘 테스트를 보면 새로운 기술에 민감하면서 조직의 질을 높이기 위해서 노력하는 조직들이 유리할 것 같다는 생각이 든다. 내 생각도 그렇게 기민한 조직이 앞으로 생존가능성이 높을 것 같다.

조엘이 블로그에 쓴 글들을 모아서 책으로 발간했기 때문인지 책 전체를 관통하는 하나의 생각이나 주제 같은 것은 없다. 다만 조엘이 느끼고 생각한 짧은 글들을 하나씩 읽어가면서 내가 생각했던 것들과 비교도 해보고 조엘의 생각에 감탄도 하면서 즐겁게 읽을 수 있는 것이 이책의 묘미가 아닐까 생각한다. 더불어 컴퓨터 화면을 통해서 봤던 글이기는 하지만 종이로 된 책을 읽을 때의 감성적 느낌을 통해서 같은 글을 읽었을 때 느끼지 못했던 새로운 것들을 느낄 수 있는 것도 또 다른 묘미일 것이다.

2005년 5월 9일 월요일

Security : Divide and Conquer






해킹, 침입의 드라마
케빈 미트닉.윌리엄 사이먼 지음, 이성희.송흥욱 옮김/사이텍미디어(희중당)

 최근 케빈 미트닉의 행방을 보면 전업한 해커(혹은 크래커)의 성공적인 사례를 보여주는 듯 하다.

그는 이번 책으로 벌써 두권의 보안관련 서적을 출판했으며, 현재는 보안 컨설턴트로 활동중이기도 하다. 음지에서 생활하던 그가 석방 후 보안분야에서 활동을 하고 보안에 관계된 서적을 출판하는 것을 보면 인생은 새옹지마라고 말할 사람도 있을 것이다.

이런 저런 이야기들을 제쳐두고 그의 책을 들여다보자. 도움이 되는 정보를 많이 얻을 수 있다. 특히 사회공학해킹은 우리나라를 비롯하여 전세계에서 특별한 대비책을 가지고 있지 않는데, 이는 사회공학 해킹이 인간의 본성을 이용한다는데 그 원인이 존재한다고 생각한다.

케빈은 그의 책을 통해서 그러한 사회공학해킹에 대한 유형을 이야기 하고 대비책을 말하고 있다. 물론 그 대비책이란 것들이 실행과 유지를 하는데 많은 시간이 들거나 많은 자금이 드는 경우도 있지만, 간단한 조치를 통해서 큰 효과를 얻을 수 있는 것도 이야기 하고 있다.

네크워크를 통한 침입을 막는 것만이 전부가 아니라는 사실을 알고 다양한 침입을 방지하는 것이 제대로 된 보안을 위한 길이라 볼 수 있을 것이다.

지난번의 책(해킹, 속임수의 예술)을 통해서 자신이 사용했던 혹은 알고 있는 사회공학해킹에 관해서 다루었는데, 이번에는 몇 가지 해킹 에피소드를 분석하면서 보안에 대한 경각심을 불러 일으키고 있다. 책에서 말하고 있는 이야기들은 케빈 자신의 이야기가 아니며(지난번과 달리) 케빈은 그들의 이야기를 검증하고 부연설명과 얻을 수 있는 교훈을 설명하고 있다.

다루는 에피소드의 범위가 상당히 넓어서 11개의 에피소드가 나오는데, 각 케이스가 대부분 중복되는 경우가 아니라 나름데로의 특징을 가지고 있는 경우이다. 아마도 케빈은 자신이 생각한 침입의 경우에 대해서 분류를 나누고 각 분류에 해당되는 에피소드들을 조사했거나 주변의 에피소드들을 수집하고 분류하는 과정에서 책에 나오는 에피소드들을 추렸지 않을까 생각된다.

각각의 에피소드들은 간단한 스크립트를 이용한 크래킹을 비롯해서 치밀하게 계획된 시스템 침입이나 고도의 기술을 이용한 시스템 해킹, 사회공학 해킹기법을 이용한 기술적 해킹, 프래킹, 사회공학 해킹, 모의침입 테스트 등의 광범위한 침입방법들을 다루고 있다.

개인적으로 첫번째 에피소드인 카지노 털기를 재밌게 봤는데 이들의 행위가 전형적인 해커의 모습과 많이 닯아 있어서 그런것 같다. 각 주인공들은 일부는 컴퓨터를 제대로 알고 있는 전형적인 해커가 나오기도 하고 내가 보기에는 다른 사람들의 스크립트나 취약점 문서들만 이용해서 크래킹을 하는 그다지 스크립트 키드(script kid) 수준의 크래커가 나오기도 한다(물론 내 관점이다). 그리고 컴퓨터에 관해서 그렇게 능통하지는 않지만 사회공학 해킹 능력이 뛰어난 사람도 나온다.

각 에피소드들은 상당히 재미있어서(이 부분은 공저자인 윌리엄 사이먼의 도움이 컸을 것이다) 소설처럼 읽기에도 전혀 무리가 없다. 책을 11개의 이야기가 모여있는 모음집 정도로 생각하고 재미있게 읽을 수 있을 정도지만 각 에피소드마다 있는 케빈의 에피소드 분석과 대응방안은 보안책인자나 보안을 담당하고 있는 사람들에게 많은 도움을 줄 수 있을 것이다. 대부분의 회사나 단체들은 보안사고가 발생하는 그 사고를 공개하고 대처방안을 논의하거나 자신들의 대처와 그 결과를 밝히지 않는다. 오히려 그런 사고가 발생했다는 사실을 감추기 위해서 노력하는 경우가 많다. 결국 해킹의 유형들이 공개되는 경우가 드물기 때문에 대처를 확실하게 수립하지 못하는 것이다. 이 책의 에피소드들은 대부분의 공격기법들을 망라하고 있기 때문에 굳이 케빈의 조언을 유념하지 않더라도 책을 읽은 보안담당자들은 각각의 케이스에 따른 대처방안을 스스로 생각해 볼 수 있을 것 같다.

결론


 먼저 출판되었던 케빈의 첫번째 책과 마찬가지로 이번책에도 그가 제시하는 대처방안을 모두 적용한다는 것은 현실적으로 거의 불가능하다. 이러한 문제점 때문에 그의 책은 완벽한 보안 가이드가 되기 힘들다. 하지만 우리는 아마도 그의 책에서 필요한 부분이 집중적으로 보안을 강화할 수 있는 방법 얻을 수 있을 것이다. 하나의 구멍만 있어도 1000의 구멍을 막기 위해 들였던 노력이 수포가 되어 버리는 보안분야에서는 넓은 범위를 방어하기 위한 전략보다는 중요성에 따라 다른 수준의 보안을 적용하는 것이 더 중요하다.

케빈은 단순하게 컴퓨터를 이용한 침입뿐 아니라 사회공학해킹이나 여러기법들을 혼용한 기법 등도 다루고 있는데 그가 제사힌 대처방안들을 이용하면 꽤나 높은 수준의 보안 시스템을 구축할 수 있다. 그러한 보안시스템을 높은 수준의 보안을 요하는 곳에 적절하게 적용하는 것이 이와 같은 책을 보고 얻을 수 있는 것이 아닐까 생각한다. 확실히 넓은 지역을 몇개의 구멍만을 유지한체 힘겹게 방어하는 것보다 필요한 지역만 각각 철통같이 방어하는 것이 유리하다.

2005년 5월 2일 월요일

눈을 뜨고 명확하게 보자.






촘스키, 누가 무엇으로 세상을 지배하는가
레미 말랭그레 그림, 드니 로베르 외 인터뷰 정리/시대의창

노암 촘스키란 이름은 프로그래밍을 공부하면서 AI분야에 사용되곤 하는 생성문법이론의 창시자로 몇번 들어본 적이 있었다. 그리고 가끔 다른 사람들의 글에서 그의 이름이 언급되곤 하는 걸 봤던 것이 내가 그에 관해 들어본 전부이다.가끔씩 듣는 그에 대한 이야기로 인해 막연하게 관심을 가지고 있었다. 우연하게 몇권의 책을 구입하면서 촘스키 3부작이란 이름으로 그를 인터뷰한 내용을 책으로 발간한 내용을 만날 수 있었다. 활발한 활동의 대부분을 저술로 보내는 만큼 그가 직접 저술한 책들이 여러권이지만, 왠지 인터뷰를 통해서 처음 접한다는 것이 좀 더 친근한 첫만남인 것 같은 생각이 들었다.

프랑스에서 출간된 이 책은 촘스키와 프랑스인인 인터뷰어와의 대화를 기초로 작성되었다. 기본적으로 별다른 가감없이 질문과 답변을 정리하고 있으며, 이해를 돕기 위한 주석을 통해서 보충 설명을 하고 있다. 질문에 대한 답변을 통해서 촘스키는 그가 평소 말하고 주장하는 바를 다양하게 표현하고 있다. 다양한 사례를 통해서 우리는 그의 주장을 파악할 수 있으며, 그의 생각을 알아볼 수 있다.

프랑스에서 발간된 책인 만큼(실질적인 저자-인터뷰어-도 프랑스인인 만큼) 미국과 유럽을 비교하면서 설명하고 있는 부분이 많다. 그래서 미국만큼 유럽에 익숙하지 않은 내가 읽기에는 쉽게 이해되지 않는 부분이 몇 군데 있었다. 미국에 대해서도 그다지 많은 부분을 알지 못하기 때문에 이해도가 더 떨어지긴 했으나 맥락을 짚어 가면서 이해하고자 노력하였다.

책의 서두에서는 프랑스에서 많은 화제가 되었던(맥락상으로) 포리송 사건에 대해서 이야기를 하고 있다. 이 부분은 국내에 그다지 소개된 부분이 아니고 관심있을 만한 사건은 아니라서 이부분에 대해서는 표현의 자유에 대한 그의 생각을 엿보는 기회로 생각하였다. 표현의 자유는 그가 이야기 하는 각종 권력을 감시하고 대항하는 활동을 위한 기본적인 전제조건이다. 결국 표현의 자유가 침해받는 어떠한 상황이라도 그는 용납할 수 없었을 것이다. 나 역시 얼마 전에 읽었던 "신문읽기의 혁명(손석춘)"에서 이야기되었던 보도관제 등의 표현의 자유에 대한 억압을 생각해보면 표현의 자유에 대한 억압은 결국 부당한 권력 행사를 돕는 작용을 하게 될 것이라 생각하고 있었다. 아마도 우리가 거대한 권력에 대항(혹은 최소한의 권리행사)을 한다면 표현의 자유만이 도구가 될 수 있을 거라 생각한다.

200페이지 정도의 분량의 이 책에서 그가 이야기 하고자 하는 바는 일관된 한가지 주장이다. 그는 수 많은 권력들로 부터 대중들에게 가해지는 피해들을 경고하고 그들 권력을 감시해야 한다고 말한다. 그의 주장은 언듯보면 황당한 음모이론처럼 느껴지기도 한다. 국가권력, 언론권력, 기업권력과 같은 강한 힘을 가진 자들이 세상을 지배하기 위해서 어떠한 행동을 하고 있다는 그의 주장은 음모이론들과 어느 정도 맥락을 같이 한다고 볼 수도 있다. 그렇다고 그의 주장이 황당하기만 한 이야기인 것은 아니다. 우리의 주변에는 잠시만 생각해봐도 알 수 있는 음모들이 존재한다. 신문은 그들의 생각 혹은 더 큰 권력의 지시에 의해서 기사를 조작(편집 및 모든 조작을 생각해서)하며 기업은 그들의 의도를 관철하기 위해서 폭력이나 권력을 동원하기도 한다.

얼마 전에 삼성에 노조를 만들기 위해서 준비하던 사람들의 휴대폰이 도청당하고 그들에게 유무형적으로 협박이 가해진 사건이 있었다. 실제로 현재까지도 노조없는 기업을 유지하고 있는 삼성이 노조건립을 막기 위해서 다양한 조작을 하고 있다는 사실은 널리 알려져 있다. 불법적인 방법까지 동원하면서 그런 활동을 벌이고 있지만, 언론과 국가의 보호로 이러한 일들은 언론에도 널리 보도되지 않고 재판에서도 유리한 판결을 받는다. 최근 판결에서도 삼성은 기소중지를 얻어냈다(도청및 위치추적 등에 대한 고소).

촘스키는 이러한 권력등에 대항해서 글을 쓰고 연설을 한다. 스스로를 안전한 담장안에서 활동하는 운동가라 말하고 있지만 그는 세상에 진실을 알리고 움직임을 일으키기 위해서 그의 수많은 글에서 주장하고 있다. 권력에 대한 경계심을 가지고 그들을 감시해야하는 의무는 대중에게 있다고 말하고 있는 것이다.

2005년 3월 11일 금요일

독기학설, 혜강 최한기로 가는 발판





독기학설
김용옥 지음/통나무

평소 혜강 최한기에 대해서 관심을 가지고 있었으나 그의 대표작인 기학이나 신기통, 추측록 등을 읽어볼 엄두를 내지 못하고 있었다. 언젠가는 읽어봐야겠다는 막연한 생각만을 가지고 있었을 뿐이었다.

그러던 차에 독기학설이라는 책에 대해서 말을 들었다. 기학이라는 책에 대한 독서감상문이라는 김용옥씨의 주장이었는데. 읽어보고 느낀 점은 혜강을 알기 위해서 입문하려는 나같은 사람에게 들려주고 싶은 혹은 혜강에 대해서 생각을 해본적이 없는 사람에게 알려주고 싶은 말을 쓴 것 같다는 생각이 들었다. 사실, 이 책은 원래 단행본으로 발간하려는 글이 아니었고 어떤 학술지에 실을 학술논문으로 작성하였다고 한다. 그 학술지에서 이 글의 파괴력(학자들의 입장에서 생각해보면 리차드 도킨스의 [과학혁명의구조]로 인해 느꼈을 파괴력같은 느낌이었을 것 같다) 때문에 게재를 거부 당했다고 한다.

결국, 단행본으로 발간을 결심했고 내가 읽은 책은 1999년에 출시된 책에 몇가지 수정을 한 2판이다.

학술논문으로 작성되었던 글인 만큼 생각없이 쉽게 읽을 수 있는 글은 아니다. 일단 의견을 뒷받침 하기위한 각주들이 꽤나 많은데, 각 각주들은 설명하는 주석도 있지만 대부분 참고문헌에 대한 언급이기 때문에 각 참고문헌들에 대해서 별다른 지식이 없는 나와 같은 사람들에게는 그 참고문헌의 내용을 유추해야 하는 어려움이 따른다. 그리고 평소 한자를 읽을 기회가 없어서 거의 잊고 있던 한자들도 꽤나 나오기 때문에(물론 한글로 독음한 것도 있으나 아닌 경우도 많다) 독음 자체를 하지 못해 이해하기 힘든 부분도 있으며 한글로 나오는 단어라도 뜻을 몰라 사전을 뒤져야 하는 경우도 있다(평소에 어휘력의 부족을 느끼지 못했는데 김용욕씨의 어휘의 범위가 나와는 다르다는 것을 느꼈다. 그만큼 풍부한 어휘를 사용하기도 하고 한편으로는 어렵게 말을 하기도 한다 ^^;).

글은 크게 두 부분으로 나누어져서 서술되는데 첫번째 부분에서는 조선조의 철학의 흐름에서 우리가 실학이라고 알고 있는 부분이 실제로 존재했었는지 조선근대사의 많은 생각들이 실학이라는 테두리 안에서 존재했었는지를 따져본다.

이 부분을 읽으면서 리차드 도킨스의 [과학혁명의구조]를 읽고 느꼈던 느낌을 받을 수 있었다.
리차드 도킨스는 그의 저서에서 우리가 흔히 교과서에서 보는 변증법적인 과학 발전과정은 실제의 과학사에서 찾아보기 힘들며 오히려 각 시대에 존재하였던 수많은 생각들 중 하나가 주류를 이루고 있던 생각들을 대체하는 과정(주로 나이 먹어 죽음으로서)에서 패러다임 쉬프트(패러다임의 교체)가 일어난다고 이야기 하였다.

그럼에도 불구하고 후세에서 그런 과정을 기술할 때, 변증법적으로 한 이론의 취약점이 발견되고 그 이론을 보충한 반이 다시 원래 이론인 정과 합쳐져서 그 합이 다시 주류를 이루는 이론인 정이 된다는 알려져 있는데. 이런 형식을 사용하는 것은 실제로 실제적인 과정을 잘못 해석하였거나 후세의 배움의 용이성을 위함이라는 것이다(이 의견에는 다른 사람들의 생각도 포함되어 있다).

그렇게 실학의 실체에 대해서 이야기하며 도올은 조선말에 살았던 혜강 최한기라는 사람에 대해서 주목할 필요가 있다고 한다. 혜강는 주자학이라는 하나의 패러다임 안에서 계통을 이루던 대부분의 조선조 학자들과는 괘를 달리 했다는 것이다. 과학사의 패러다임 쉬프트와 같은 사건을 일으키지는 못했지만, 충분히 가치가 있는 연구를 하였으며 그 연구는 그 시점에서의 위대함 때문에 현실에서 조명해야 할 것이 아니라 지금 시점에서도 필요한 것이기 때문에 살펴볼 필요가 있다고 말한다.

150페이지도 안되는 짧은 분량의 책이지만 그 안에는 진실을 보기위한 씨앗이 들어있다고 생각한다. 물론 도올의 의견이 무조건 옮다는 것은 아니지만, 나 역시 그러지 않을까 생각했던 그리고 궁금했던 부분에 대한 그의 의견에는 대부분 동감한다.

기학이 새롭게 나왔다고 한다(2004년에 개정판이 출시되었다). 내가 어떤 것들을 느끼고 배울 수 있을지 흥분이 된다. 새로운 것을 배우고 그 배움을 익히는 것처럼 즐거운 것이 또 있을까. 독기학설을 통해서 혜강 최한기의 생각에 접근 할 수 있는 발판을 쌓은 느낌이다. 멀게만 느껴져서 다가가기 힘들었던 벽에 조금은 가까워진 느낌이다.

[인상깊은구절]
다산은 일생을 페리페리(주변)에서 살았다. 그렇지만 그의 모든 관심은 센타(중심)에 있었고 실제적으로 그의 행동은 센타에 영향을 주었다. 혜강은 일생을 센타에서 살았다. 그러나 그의 관심은 항상 센타를 초월한 곳에 있었다.

2005년 3월 7일 월요일

프로그래밍에 관한 철학서








Art of UNIX Programming
Eric S. Raymond 지음, 김희석 옮김/정보문화사
유닉스나 리눅스게 많은 관심을 가지고 있지 않은 사람이라도 컴퓨터에 관심을 가지고 여러 분야를 공부하다 보면 에릭 레이몬드라는 사람을 한번쯤은 접하게 된다.이책의 필자인 에릭 레이몬드는 유닉스/리눅스 공동체에 여러가지 공헌을 한 프로그래머로서도 많이 알려져 있지만, 몇가지 사건으로 더욱 잘 알려져 있다.

그 첫번째가 시장과 성당 이라는 글을 통해서다. 이 논문은 fetchmail이란 프로그램을 통해서 소프트웨어 개발에서 어떤 스타일이 존재하는지 그리고 어떤 의의를 지니고 있는지 연구한 결과를 담고 있다. 두번째로 Open Source운동의 중심에서 활동한 면을 들 수 있다. 여러가지 의견이 있지만 그는 Open Source운동에서 중심적인 역할을 담당했던 인물이다.

그 이외에도 몇가지 일들로 인해서 그는 유닉스/리눅스 공공체에서는 널리 알려진 인물이 되었으며, 그 이외의 분야에서도 관심을 받 게 되었다.

평소에도 해커 사전이라고 불리는 Jargon File 등을 비롯한 다양한 문서들을 집필, 감독 하였고 활발한 집필활동을 펼치고 있다. 주로 그가 작성한 문서들은 온라인으로 배포가 되었고 변동된 사항이 있으면 추가하여 문서가 업그레이드 되었다. "Art of Computer Programming"역시 온라인으로 존재하며 5년간에 걸쳐서 꾸준하게 작성한 결과물이다.

책은 흐름상 두 부분으로 나뉘어진다. 첫번째는 유닉스의 철학을 설명하는 부분이고 두번째는 그 철학이 어떻게 적용되며, 어떤식으로 작동하지는를 말하는 부분이다. 우리들이 흔히 배우던 교과서에서 보자면 삼각함수의 원리와 그 유례를 설명하는 첫 부분과 예제와 연습문제를 통해서 각 원리들이 어떻게 적용되고 우리는 어떻게 적용시켜 다른 문제를 해결할 수 있는지 알게 되는 것과 같다.

특히, 두번째 부분에서는 성공적으로 유닉스 개발 철학이 적용되어 개발된 소프트웨어들을 살펴본다. 만일 독자가 자신의 프로젝트에 서 적용했을때 어떤 효과를 기대할 수 있을지, 어떻게 적용할 수 있을지 알도록 돕고 있다.

책에서 설명하는 유닉스의 철학은 비단 유닉스에서만 성립는 것이 아니라 소프트웨거 전반적에 걸쳐서 타당하게 적용될 수 있는 내용 들이다. 유닉스 공동체의 이런 철학들은 유닉스가 원래 좋은 소프트웨어고 공동체가 원래 훌륭했기 때문에 발생한 것이 아니다. 단지, 30년이 넘는 세월 동안 프로젝트가 진행되고 소프트웨어가 발전해 오면서 쌓이게 된 지식들이 집합되었기 때문에 그와 같은 철학을 탄생시킨 것이다. 분명 이 책에는 그런 지식들이 포함되어 있다. 어느 정도 도움을 받을 수 있을 건지는 개인에 따라 다르겠지만, 적 든 많든 도움을 얻을 수 있을 거라 생각한다.

책의 제본상태는 훌륭하지만, 몇 군데 오타가 있고, 조금 이해하기 힘든 번역(오역은 아니나 혼란스러웠다)도 준재한다. 하지만, 전체적으로 번역은 잘된 편이다.

이 책을 보면서 몇번이나 소리내어 웃었는지 모른다. 너무 재밌어서 지하철에서도 한손에 들고 시간가는 줄 모르고 읽었었다(책이 작 은 편이 아님에도 불구하고!). 내가 사용하던 프로그램, 내가 프로그래밍 할 때, 생각없이 했던 작업들에 그런 원리가 숨어 있다는데 놀랐고, 나의 프로그래밍 방법에 개선할 점을 알 수 있었다. 비록 유닉스 프로그래밍이란 타이틀을 달고 있지만, 위에서 말한바와 같 이 다양한 분야에 적용될 수 있으며 어느정도 프로그래밍을 해서 자신만의 방법이나 생각같은게 잡힌 사람들에게는 중간 길잡으로써 좋을 거라 생각한다.

인터넷에 전문이 공개되어 있다.

Man of Month를 마치며

벌써 2020년 1월 14일이다. 19년의 마지막 달에 Man of Month라는 팀의 제도를 시작한다고 했었는데, 12월이 지나고 그 다음 달도 거의 절반이 흐른 것이다. MoM을 시작하면서 하겠다고 계획했던 것들도 실제 한 것들과 비교해보니...