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

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

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

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

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

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

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

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

괴짜경제학 : Freakonomics

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

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

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

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

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

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

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

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

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

우리는 예외가 프로그램의 정상 흐름의 일부로 사용되는 일이 거의 없어야 한다고 믿는다. 예외는 의외의 상황을 위해 남겨두어야 한다. 잡히지 않은 예외는 프로그램을 종료시킬 것이라고 가정하고, '모든 예외 처리기(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 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 # 펜을 종이에서 든다.

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