한빛출판네트워크

그동안 한빛미디어㈜는 개발자들을 위한 IT 전문서만을 중점적으로 출간해왔습니다. 그런데 지난달 그동안의 고정관념을 깰만한 책 한권이 출간되어 독자님들의 관심과 사랑을 듬뿍 받고 있습니다. 현재 강컴 컴퓨터관련 교양서 1위를 달리고 있는 『행복한 프로그래밍: 컴퓨터 프로그래밍 미학 오디세이』가 바로 그 책이죠. 단숨에 이 책을 읽어버렸다는 박재호님께서 과연 단숨에 읽어버렸을지 의심이 갈 정도로 이 책의 이곳 저곳에 대해 날카로운 지적을 해주셨습니다. 물론 이에 대해 저자 임백준님의 친절한 답변도 있었구요. 이에 한빛미디어 이비즈팀에서는 이 내용을 인터뷰 형식으로 재편집하여 독자님들께 공개합니다.

박재호: 책 아주 재미있게 잘 봤습니다. 한빛미디어를 방문했다가 돌아오는 도중, 이 책을 읽으면서 독서 삼매경에 빠져, 내려야 할 역을 몇 개 지나쳐버렸으니까요. 소설을 읽을 때나 생길법한 해프닝이었죠.

임백준: 저도 박재호님의 서평 매우 인상적으로 읽었습니다. 책을 읽고 분석하시는 능력이 대단히 뛰어난 분이라는 생각이 들었습니다. 책의 전반적인 흐름에 대한 호의적인 평가에 대해서 진심으로 감사를 드리고 기술적인 부분에 대한 냉정한 평가도 아프지만 고맙게 받아들여서 약으로 삼겠습니다. 박재호님이 지적해주신 부분에 대해 제가 변명할 것은 변명을 하고 반론할 것은 반론하려고 합니다. 전 준비가 다 되었는데… 질문하시죠?

박재호: 그럼 다른 이야기는 안하고 곧바로 질문으로 들어가겠습니다. 비트의 법칙에서 Kbytes, Mbytes, Gbytes 정의에 오류가 있는 듯 싶습니다. 실제 프로그래머가 3억 쯤은 우습게 알고 생략한다고 하셨는데, 시스템 프로그래머나 임베디드 시스템 개발자는 1비트에도 목숨을 걸며 정확하게 2진수로 계산을 합니다. 장사꾼(marketroid)들이 사용하는 용어와 개념을 소개하고 있는건 아닌지요? (http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?prefix 참고)

임백준: 108p의 "소프트웨어 공포 얘기"를 보면 맨 밑의 괄호 안에 이러한 표현이 있습니다. "특수한 목적을 가지고 있는 임베디드 소프트웨어를 작성하는 프로그래머들을 제외하면…" 저도 임베디드 시스템 개발자에게 1비트가 매우 중요하다는 사실을 잘 알고 있으며 따라서 임베디드 시스템 프로그래머의 경우를 예외로 취급하였습니다. 위의 표현은 "오류"가 아니라 박재호님이 제 뜻을 약간 잘못 이해하신 것 같습니다. 1KB, 1MB 등의 표현은 "장사꾼"만이 아니라 "프로그래머"들도 수시로 사용하는 표현입니다. 예를 들어서 "1K"라는 표현 속에는 이미 24비트가 생략되어 있습니다. 제가 책에서 그러한 이야기를 한 이유는 3억을 우습게 아는 프로그래머의 경솔함을 지적하려는 것이 아니라 "비트의 법칙"을 일반 독자들에게 자연스럽게 소개하려는 의도였습니다.

박재호: 알겠습니다. 책을 더 읽다보니 생활 속에 숨어있는 알고리즘에서 줄서기 비유를 드셨더군요. 줄서기를 멀티쓰레드 개념으로 설명했는데, 솔직하게 말해서 양자는 별로 연관성이 없다는 생각이 듭니다. 사람이 멀티쓰레드로 독립적으로 움직인다는 이야기인가요? 정말 어색하지 않나요? 이건 확률과 큐잉 이론(queueing theory)로 설명해야 할 것 같은데요. (http://whatis.techtarget.com/definition/0,,sid9_gci212853,00.html 참고)

임백준: 이 지적도 제가 온전히 동의하기 어렵습니다. 제가 의도했던 것은 여러 개의 줄이 저마다 자기 나름의 속도로 줄어드는 현상을 각 쓰레드의 명령어가 서로 독립적인 순차에 의해서 실행되는 현상에 비교한 것뿐입니다. (굳이 말하자면 줄에 서 있는 "사람"이 쓰레드 내부의 "명령어"에 대비된다고 볼 수 있습니다.) 또한 큐잉 이론 자체가 이미 멀티쓰레드 개념을 전제하고 있으므로 여기에서 "큐잉 이론"과 "멀티쓰레드"는 서로 배척하는 대상이 아니라 상보적인 관계를 맺고 있다고 봅니다. 따라서 "줄서기"가 "큐잉 이론"으로만 설명이 되고 "멀티쓰레드"와는 아무런 상관이 없다는 주장에는 동의하기 어렵습니다.

박재호: 언어의 모호성에서의 예제에 대해서 좀더 자세한 설명을 듣고 싶습니다. 제 생각에는 예제를 잘못 드신 것 같습니다. 개념까지 혼동하고 계신듯한데, 컴파일러 이론에서 설명하는 모호성은 논리 오류와는 다른 개념입니다.

if (a>b)
...
else if (a>b)
...

예제와 관련하여 현재 대부분 프로그래밍 언어가 따르는 LALR(1) 파서와 관련하여 문법적인 측면에서는 하나도 모호하지 않습니다. dangle else 예가 차라리 낫지요. 그리고 while 무한 루프 예제 역시 부적절하다고 봅니다. 반례를 들어볼까요? X 윈도우 시스템에서 고의적으로 이벤트 구동 무한 루프로 빠질 경우 이를 모호하다고 해서 오류로 처리해야 하나요? (LARL(1) 파서와 모호성에 대해서는 본문에서도 언급한 "Compilers: Principles, Techniques, and Tools -- Dragon Book" 참고)

int main()
{
// ...
        while (TRUE) {
                XEvent xevent;
                XtNextEvent(&xevent);
                XtDispatchEvent(&xevent);
        }

        return 0;       // 이 문에 절대 도달하지 않는다.
// 컴파일시 하지만 gcc가 불평하지 않도록 명시적으로 달아놓는다.
}

임백준: 언어의 모호성을 설명하는 부분에서 사용한 예가 기술적으로 정확하지 않았다는 지적은 100% 인정합니다. 날카로운 지적에 감사 드립니다. 변명을 하자면 제가 본문에서 사용한 "모호성"이라는 개념은 컴파일러의 파싱이론에서 나오는 모호성(ambiguity)을 설명하려고 했던 것이 아니라 자연 언어와 컴퓨터 프로그래밍 언어 사이에 존재하는 일반적인 차이를 독자들에게 평이하게 설명하려고 했던 것입니다. 책을 쓰는 도중에도 예가 그렇게 마음에 들지는 않았었는데, 박재호님의 지적을 받고 다시 한 번 더 그 부분을 살펴보니… 과연 개념적으로 문제의 소지가 있다는 사실을 인정하지 않을 수 없었습니다. 그야말로 "모호성"에 대한 설명이 "모호해진" 예라고 하겠습니다. ^^

---

참고 도서 행복한 프로그래밍: 컴퓨터 프로그래밍 미학 오디세이 임백준 상세설명보기 목차보기 박재호님 서평보기 샘플챕터보기

---

박재호: 이름과 같은 고유명사에도 몇몇 오류가 보이던데요. 알고리즘의 이해에서 카누스 교수의 이름이 그렇구요. 본문 중에 "누스"라고 이름을 적고 있는데 자기 이름은 카누스(Ka-NOOTH)라고 본인이 직접 밝혔습니다. 이를 존중하는 편이 좋겠죠?^^ (http://www-cs-faculty.stanford.edu/~knuth/faq.html 참고)

임백준: "카누스" 교수의 웹사이트에서 "Ka-Nooth"가 맞는다는 사실을 확인하였습니다. 몰랐던 사실을 지적해 주셔서 고맙습니다. 사실 미국 친구에게 "Knuth"를 읽어보라고 해서 확인을 한 다음 쓴 것이었는데, 결국 그 친구도 잘못 알고 있었나 봅니다.

박재호: 또 있습니다. 소프트웨어 공포 이야기에서 그레이스 호퍼의 성 말입니다. 많은 사람들이 착각하고 있는 것 중에 하나이기도 한데 그레이스 호퍼는 남성이 아니라 여성입니다. 이름도 그렇지만 특히 성을 바꾸는 행위는 대단한 실례라고 생각되는데요. (http://www.wic.org/bio/ghopper.htm 참고)

임백준: 그레이스 호퍼가 여자라는 사실은 저도 알고 있습니다. 아마 호퍼에 대한 대명사가 "그녀"가 아니라 "그"였다는 사실을 지적하고 계신 것 같은데, 그 부분은 (국어 실력이 부족해서 범한) 실수입니다. 그레이스 호퍼의 사진까지 넣으려고 했었으니 호퍼가 여자라는 사실을 모를 리는 없었겠죠.

박재호: 또 한가지 이상한 점이 있습니다. 우주왕복선 버그 찾기에 보면 말이죠. var이 나오는데, 사실 var라는 데이터형은 존재하지 않습니다. JavaScript에서 var는 핵심어(keyword)입니다. 『JavaScript: The Definitive Guide, 2nd Ed.』, (O"Reilly, 1997) 34p, 38p만 참고해도 알 수 있는 내용입니다.

임백준: 맞습니다. 제가 쓴 "자바 스크립트에서는 데이터형에 대한 구별이 없기 때문에 모든 변수가 var라는 데이터형으로 선언되고 있다"라는 표현에서 뒤의 "데이터형"은 "키워드"라고 부르는 것이 정확하겠습니다.

박재호: 알고리즘과 해킹을 다루는 내용 중에 에니그마 이야기가 나오더군요. 『암호의 세계』 (이지북, 1997)을 보면 에니그마에 대해 다음과 같이 말하고 있습니다.

"암호 발견의 시초는 이탈리아군이 보내는 암호문에 대문자 L이 없다는 사실을 통해 이탈리아 쪽 에니그마에 L로만 구성된 평문을 입력한 사실을 밝혀냄으로써 물꼬를 열었다. 그리고 독일군이 에니그마를 사용해서 암호문을 만들 때 개별열쇠를 AAA, BBB와 같은 쉬운 키를 선택하는 바람에 이를 통해 내부 구조를 추측하는 작업이 가능해졌다. 본문 내용(총통, 총사령부)을 통한 암호 추측은 우선 에니그마와 관련한 내부구조를 파악한 다음에 사용할 수 있었던 수법이다." ─ 『암호의 세계』 (이지북, 1997) 에니그마의 암호 원통, 10. 에니그마 베일을 벗다

임백준: 보충 설명으로는 훌륭합니다만, 제 글에 대한 "오류"라고는 볼 수 없을 것 같습니다.

박재호: 아직 질문이 다 끝난 것은 아닙니다. 에니그만 이야기의 의문이 아직 풀리지 않았으니까요. 『행복한 프로그래밍: 컴퓨터 프로그래밍 미학 오디세이』의 178p 원문을 보면 다음과 같습니다.

"고지식한 독일군 부대가 자신들이 사용하는 암호화 알고리즘의 정체가 드러날 위험이 있는 사실을 상상조차 하지 못하고 매일같이 전송했던 정보의 내용은 어이없게도 "보고할 것 없음"이었다."

그런데 제가 수집한 자료에 따라면, 영화에서나 볼 수 있는 이런 극적인 상황은 벌어지지 않았습니다. 영국군은 독일군의 무선 통신문에 특정 단어가 나오도록 무지 노력했었습니다. 중요한 수로를 표시해놓은 등부표를 폭파해버린 다음, 독일 선박에게 무전을 전달할 때 이를 가로채서 해상 부표라는 단어가 들어있을 것이라는 추측을 하기도 하고, 특정 지역을 폭격한 다음 독일군이 이쪽으로 병력을 급파할 것이라는 추측을 하기도 하면서 필사적으로 본문에 들어있는 단어를 찾아내려고 노력했습니다. 하지만 에니그마 관련 미해군 1급 비밀문서(지금은 비밀이 풀렸습니다만)를 살펴봐도 상기 내용은 나오지 않습니다. 대신 제가 앞서 설명한 키값을 쉽게(예: 자판 배열을 쫓아 인접한 3글자를 뽑아냄) 만들었다는 이야기는 나옵니다.

만일 "보고할 것 없음"이라는 똑같은 보고가 계속되었다면 영국군이 이런 고생을 했을 이유가 없습니다. 에니그마 히스토리를추적해보시면 아시겠지만, 독일군이 아무리 관료주의에 젖어있었다고는 해도 그런 멍청한 실수는 하지 않았을 것이라 생각됩니다. 실제로 영국군이 암호를 해독했다는 감이 오면 독일쪽에서는 즉시 에니그마 구조를 더 복잡하게 개선하고 키 값을 더 복잡하게 바꿨으니 말입니다. 본문에 나온 내용을 담고 있는 참고문헌을 알려주실 수 있습니까?

임백준: 저도 그 부분은 자료를 다시 수집해보아야 겠습니다. 본문에 적은 내용의 출처는 Bruce Schneier가 쓴 『Secrets & Lies: Digital Security in a Networked World』(Wiley, 2000)의 p90~91에 나온 내용입니다. 제 책에는 195p에 명시되어 있고요. "카누스" 교수는 자신의 책에서 오류를 발견하고 지적해주는 독자들에게 $2.56을 지불한다고 하는데 저는 $2.56대신, 박재호님이 하시는 일이 모두 잘 되기를 진심으로 기원하는 것으로 고마움을 대신하겠습니다. 늘 행복하시기 바랍니다.

박재호: 네, 감사합니다. 임백준님도 늘 행복하시고, 이 책이 독자님들로부터도 계속해서 많은 사랑을 받기를 기원합니다.