요즈음 널리 유행하는 방법론들처럼 체계화 되어있는 것은 아니지만, 이 책은 소프트웨어 개발의 여러 부분들에 걸친 조언을 담고 있는 책이다. 그 범위는 소프트웨어 개발에서 어떤 것이 바람직한 리더쉽인가, 어떻게 팀을 만들 것인가, 고객이나 비즈니스 부문 등의 팀 외부와 어떻게 소통할 것인가, 경쟁 시장에서 어떻게 포지셔닝할 것인가,빌드와 출시, 개발 일정과 주기는 어떻게 할 것인가, 사람은 어떻게 뽑을 것인가와 같이 소프트웨어 개발 팀에 관련된 거의 모든 부문을 다루고 있다고 해도 과언이 아니다.
저자는 소프트웨어 개발팀을 생태계와 같은 것으로 보고 있다. 팀원들은 팀장의 지시에만 따르고, 미리 정해진 역할을 수행하는 것이 아니라, 팀장은 팀원에게 권한을 위임해야하며 (지식노동에 있어서 이것은 이미 황금률이다.) 팀원들은 자신의 능력이 다른 팀원들과 조화를 이루도록 역할을 진화시켜 나간다. 이러한 관점은 소프트웨어가 지식 노동의 산출물이기 때문에 무엇보다도 팀원들부터 아이디어가 자유롭게 나오고 그 중에서 최상의 아이디어가 선택되어야한다는 이유에 비롯한다.
애자일 소프트웨어 개발 프랙티스 (이를테면 XP와 같은)에서와 비슷한 주장들을 1995년에 쓰여진 이 책에서 하고 있는 것도 재미있는 점이다. (참고로, C3 프로젝트는 1996년에 시작되었고, Kent Beck이 유명한 Extreme Programming Explained를 내놓은 것은 1997년의 일이다.) 신속하게 개발주기를 반복한다든가, 알려진 상태를 유지하는 것, 고객과의 관계의 강조 등에서 그러한 것들을 엿볼 수 있다. Scrum과 같은 방법론은 1993년에 적용되기 시작했고, Iterative and Incremental Development: A Brief History와 같은 문서를 보면, 1980년대에 이미 점진적인 개발 방법이 소프트웨어 개발계에 떠들썩하게 떠오르고 있음을 할 수 있다.
설령 책이 제시하는 세부적인 방법들에 동의를 하지 않는다고 하더라도 한번이라도 팀에서 소프트웨어 개발을 해본 경험이 있다면, 지난 날의 경험을 회상하며 이 책의 조언에 대해 깊히 생각해보는 것은 매우 유익한 일일 것이다. 다만, 저자는 인문학적인 배경이 있는지 몰라도 문학이나 철학에 기원한 개념들을 자주 빌려쓰고 있을 뿐만 아니라 전체적인 문체도 간명한 편은 아니어서, 읽기가 쉽지 않은 면이 있다. 단지 번역의 탓만은 아닌 듯 보인다. 반대로 이러한 점 때문에, 한문장 한문장을 곱씹어볼 경우 여러가지 경우에 여러 의미로 다가올 수도 있을 것이고, 비단 저자의 조언을 곧이곧대로 받아들이기보다는 풍부한 고민의 원천이 될 수 있는 면도 있을 것이다.
전통적인 철학의 근본적 목적은 바로 신념들을 받아들이거나 거부할 수 있는 합리적인 근거를 제공하려는 시도이다. 과학은 설명을 추구하고 인과적 설명의 형태를 띄나, 철학은 정당화를 추구하고 신념에 필요한 합리적 근거를 탐구한다.
따라서, 철학의 역할은,
충돌하는 두 신념 사이의 어디에 양립불가성이 존재하는지 보여주기 위해서, 두 신념의 체계에 깔려있는 의미를 명료하게 밝히려고 노력하고,
양립불가성을 해결할 방도를 제시하는 것이다.
양립불가성을 해결하는 방법에는, 전통적인 신념을 제거하거나 반대로 새로운 신념을 거부하는 방법이 있고, 2개의 신념 체계 중 하나를, 이들이 양립할 수 있도록 수정하는 있다. 이러한 작업에는 관련된 모든 사실에 알맞는 관념의 새로운 틀을 제시하는 작업이 뒤따를 수 있다. 또한, 하나의 문제가 새로운 개념적 틀이나 철학 체계를 통해 해결되면 철학자들의 관심을 그 체계 자체에로 전환하기 쉽다.
지식 철학과 실천 철학
지식 철학(인식론, 형이상학)이 무엇이 참인가에 대한 신념에 관심이 있다면, 실천 철학(도덕 철학, 사회 철학, 정치 철학)은 인간과 사회를 위해 무엇이 옳으며 선한지에 관한 신념과 원리에 관심이 있다.
비판적인 평가
신념이 합리적으로 정당화되기 위한 2가지 기준은 (내적인) 일관성과 사실과의 일치다.
사실의 문제(matter of fact)에 관한 신념의 경우, 즉 사실 철학의 문제에서, 일관성을 가진다고 하더라도, 실제 사실의 세계에 적용되거나 또는 일치하는지를 알아야 한다. 이 때, 철학자는 일관성을 검증할 수 있으나 무엇이 관련된 사실인가를 알아내는 것은 바로 과학의 임무다. 따라서, 지식 철학은 한 신념이 사실과 일치하는 지를 결정할 수 없다. 실천 철학은 사실과의 일치라는 기준을 대신하는 것이 무엇인지 분명하지 않다. 상충하는 가치체계 중 어느 것이 사실적, 객관적인 것으로 간주될 수 있는지 결정하기 위한 인정된 절차는 없다. 대안은 비판적인 평가에 있다. 비판적인 평가란, 한 신념을 직접적으로 정당화하는 것이 아니라, 그 신념에 대한 다른 대안을 제거함으로써 간접적으로 그것을 지지하는 형식을 말한다.
정치철학에 국한해서 실천철학에 대한 비판에 대한 반론은 다음과 같다.
일관성이라는 기준이 부정적 검증으로서 어느 정도 결정적일 수 있음을 과소평가 (과학에서도 마찬가지.)
전통적인 정치 철학에 대한 비판은 사실이 가치 판단을 뒷받침하는 역할을 수행한다는 점을 간과 (가치 판단은 종종 일치성의 시험을 받는 사실에 관한 신념을 전제한다.)
비판적인 평가의 문제점
정치철학에 있어서 비판적인 평가의 대상이 되는 모든 문제가 이 같은 방식으로 해결될 수는 없다. 갈등이 일어나는 대립적 주장을 살펴봄으로써, 불일치성이나 잘못된 실제적 전체들을 밝혀내는 철학적 방법은, 비교상의 가치(comparative value)에 대한 견해의 차이(e.g. 자유와 평등이라는 가치에 대한 서로 다른 상대적인 평가)라는 핵심적인 문제를 미해결된 상태대로 내버려두는 문제점을 가지고 있다.
Robert Glass의 이 책은 내가 읽은 소프트웨어 엔지니어링에 관한 문헌들에서 자주 인용되기에 꼭 한번 읽어봐야지 하고 생각하고 있던 책이다.
제목 그대로 이 책은 소프트웨어 엔지니어링에 관한 사실들과 오해들을 열거하고, 각각에 관한 논쟁과 저자의 의견들을 정리해놓은 책이다. 각각의 항목들은 다른 유명한 저작들에서 언급된 내용이 많아서 ‘집대성’의 느낌이 든다. 이 책의 가장 큰 목적은 저자가 서론에 언급한대로 ‘기본적이면서도 중요’한 사실들인데도 ‘자주 잊혀지’는 사실들을 사람들이 ‘반복해서 배우게’하는 것일 것이다. 한편으로는 사실들의 원저작에 해당하는 개개의 저작들을 읽을 때와는 다르게, 여러 사실들과 논쟁을 한곳에 정리해놓음으로써, 소프트웨어 엔지니어링에 대한 생각을 정리하고 관점을 만들어낼 수 있도록 도와준다.
대부분의 사실들은 말그대로 ‘사실’로 통용되는 것들이지만, 몇몇은 아직 논쟁거리인 경우도 있고, 개인적으로 동의하고 싶지 않거나 또는 그동안 믿지 않았던 것들도 있었다. 사실 이러한 점들을 읽는 도중에 메모를 해서 정리했어야 하는데, 그러지 못한 것이 후회된다. 하지만, 이 책은 한번 더 읽어볼 기회가 있을 듯하고, 그 때는 반드시 그에 관한 글을 따로 써야겠다.
저자가 채택한 사실에서 몇가지 경향을 찾아본다면, 다음과 같다.
사람이 중요하고 도구와 기술은 그보다 중요하지 않다.
어떤 문제에서든 은탄환은 없다.
소프트웨어 개발 프로세스의 초기 단계들(요구사항, 설계)은 중요하다.
소프트웨어 개발 프로세스의 몇몇 단계들은(테스팅, 검토, 유지보수)은 대단히 중요하지만 과소평가되고 있다.
대규모 또는 범용적인 재사용은 어렵다.
저자는 소프트웨어 엔지니어링 학계에서 널리 받아들여지고 있는 사실들은 단정적으로 받아들이고 있으며, 소프트웨어 엔지니어링에 있어서의 최근의 변화에 대해서는 어느 정도 긍정적인 점들은 인정하기는 하나 약간 망설이는 느낌이 든다. 한마디로 말해 보수적이다. 어떻게 보면, 학계가 바라보는 현재의 소프트웨어 엔지니어링에 대한 시점이 이 책에 그대로 반영되어있다는 느낌이 든다. (이를테면, 학계에서도 인정이 되고 있는 패턴에 대해서는 항목을 하나 할애해서 재사용에 대한 해법 중 하나로 인정하고 있다. 반면 오픈소스나 XP에 대해서는 약간 방어적이다.)
하지만, 그러한 태도가 이 책의 단점이라기보다는 장점이라고 생각한다. 소프트웨어 엔지니어로서 우리는 새로운 기술, 도구, 프랙티스가 우월하므로 도입해야만 한다는 강박관념에 항상 시달려왔다. 우린 오히려 좀 더 신중해야할 필요가 있다.
이 책을 읽으면서 자꾸만 내가 겪었던 현실들이 떠오르면서 나 또는 다른 사람들이 기본적이면서도 중요한 사실들을 얼마나 자주 잊고 있는가를 되돌아보게 되었다. 저자에게 동의하지 않을 수 없는 것은 이러한 사실들은 정말로 반복해서 배우는 수밖에 없을 것이라는 점이다.
리팩토링이 없다면, 소프트웨어의 생명 주기가 진행될 수록 소프트웨어의 질은 점점 떨어질 수 밖에 없다. 현대적인 관점에서 소프트웨어 개발은 더이상 Rocket Science처럼 고정된 결과물을 산출하는 활동이 아니다. 뛰어난 소프트웨어 아키텍트라 하더라도 소프트웨어 개발 프로젝트의 초기에 그 소프트웨어를 바라보는 방식 (또는 디자인)이 후반에까지 변함없이 지속될 확률은 매우 낮다. 하물며 여러 사람이 함께 일하는 팀 소프트웨어 개발에서야 더이상 말할 것도 없다. 특히, 사용자의 요구사항이 다 떨어져서 더이상 변경할 것이 없어지지 않는 한, 소프트웨어 질의 하락은 점점 빨라질 뿐이다.
이 책은 리팩토링에 관한 바이블이다. Martin Fowler는 더이상 언급할 필요도 없는 유명한 저자다. 이 책은 리팩토링과정 예시를 통한 리팩토링에 관한 소개, 리팩토링의 정의와 중요성, 리팩토링을 언제, 어떻게 적용할 것인가에 관한 가이드, 리팩토링 패턴 카탈로그로 이루어져 있고, 리팩토링의 간략한 역사와 리팩토링의 도입 방법, 리팩토링도구에 관한 의미있는 에세이들으로 끝맺고 있다.
Martin Fowler는 리팩토링을 다음과 같이 정의하고 있다.
Refactoring: a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.
리팩토링의 목적은 소프트웨어를 좀 더 이해하게 쉽게 만들거나 그 과정에서 소프트웨어를 좀 더 이해함으로써 소프트웨어를 수정하는 비용을 줄이는 것이다. 반대로 말하면, 소프트웨어를 수정할 필요가 없다면, 리팩토링을 할 필요는 없다는 얘기가 된다. 또한 여기에는 한가지 가정이 있는데, 소프트웨어를 좀 더 이해하기 쉽다면, 수정하기도 쉽다는 것이다. 당연한 얘기같지만, 많은 개발자들은 어떤 이유에서건 이를 중요하게 생각하지 않는다.
리팩토링의 정의는 리팩토링의 가장 중요한 측면 또한 언급하고 있는데, 바로 겉으로 드러나는 소프트웨어의 동작 방식을 변경하지 않는다는 것이다. 리팩토링 패턴 카탈로그는 바로, 소프트웨어의 동작 방식을 변경하지 않는다는 제약을 위해서 어떤 방식으로 Refactoring을 수행해야하는가에 관한 패턴들을 모아둔 것이라고 볼 수 있다. 그리고, 이러한 제약을 보장하기 위해서 Unit Testing을 제안하고 있는 것이다.
패턴 카탈로그를 읽는 것은 (항상 그렇듯이) 매우 지루한 일이었다. 패턴 카탈로그는 패턴이 갖는 이점들을 제공하지만, 카탈로그를 처음부터 끝까지 읽어볼 정도로 가치가 있지는 않다. 특히, Mechanics 부분은 읽지 않아도 무방하다. 어느 정도 숙련된 개발자라면 리팩토링의 개념만 잘 알고 있다면, Mechanics를 직접 읽어볼 필요 없이 같은 것을 수행할 수 있을 것이다. 특히, 많은 수의 리팩토링 패턴들이 도구를 통해 자동화가 되어있는 현재 시점에서는 더더욱 그러하다. 내가 추천하는 방법은, 패턴의 이름(Name), 맥락(Context) 부분과 동기(Motivation) 부분만 읽고, 이해가 가지 않는 경우에만 예시(Example) 부분을 읽어보는 것이다. 내게는 패턴들을 통해 어휘를 확장시킬 수 있었던 것이 가장 큰 도움이 되었다. 예를 들어, 실제로 리팩토링을 수행할 때, 커밋 로그(Commit Log)에 리팩토링 패턴을 적어넣을 수 있어서 편리했다. 사실, 만약 이 책을 가장 효과적으로 읽고 싶다면, 패턴 카탈로그만 빼고 다 읽고 나서, 패턴 카탈로그들은 이름만 익숙해질 정도로만 훑어보라고 조언해주고 싶다.
패턴 카탈로그 읽는 것을 마치고 수십 페이지 남겨놓은 상태에서는, 마치 이미 이 책을 다 읽었다는 듯 생각을 하고 있었는데, 이 책의 마지막 장들에 들어있는 에세이들은 상당히 중요한 문제 제기와 인식을 제공해주었다.
사실상 리팩토링이라는 단어를 처음으로 만들고 초기부터 연구를 수행한 William Opdyke의 에세이는, 왜 실제 세계에서 프로그래머들은 리팩토링을 하지 않으려하는가를 따져보고, 어떻게 하면 그런 문제를 넘어 리팩토링을 적용할 수 있을 것인가에 관해서 얘기하고 있다. 자세히 설명하기 보다는 다음 문단을 인용하도록 하자.
Within Lucent/Bell Labs I found that encouraging application of reuse and platforms required reaching a variety of stakeholders. It required formulating strategy with executives, organizing leadership team meetings among middle managers, consulting with development projects, and publicizing the benefits of these technologies to broad research and development audiences through seminars and publications. Throughout it was important to train staff in the principles, address near-term benefits, provide ways to reduce overhead, and address how these techniques could be introduced safely. I had gained these insights from my refactoring research.
이 내용은 비단 리팩토링에만 해당되는 것은 아니다. 주로 단기적인 성과를 중요시하는 기업 환경에서, 장기적인 투자를 필요로 하는 무언가를 추구하기 위해서는 위에서 언급한 모든 일들을 할 수 있을 정도로 부단히 노력해야한다는 생각이 든다.
두번째 에세이는 리팩토링 도구에 관한 얘기를 하고 있는데, 이 책이 쓰여진 1999년에는 어느 정도 널리 퍼진 리팩토링 도구가 없었겠지만, 2007년 현재에는 주요 언어인 Java의 주요 IDE들이 리팩토링을 직접 지원하고 있기 때문에, 기술의 변화를 지면을 통해 느낄 수 있게 해준다.
이 책의 마무리에 해당하는 Kent Beck의 에세이는 리팩토링을 할 때 가져야할 마음가짐에 관해서 얘기하고 있는데, 중요한 항목들은 여기에 인용할 가치가 있을 것이다.
Get used to picking a goal
Stop when you are unsure
Backtrack
Duets
이 책을 읽기 시작하면서 바로 떠오른 생각은 패턴들로 리팩토링하는 리팩토링 패턴이 이 책에는 별로 없다는 것이다. 저자는 이 책에서 리팩토링 패턴의 가장 작은 단위들을 우선적으로 다루고 싶어했고, 그 목적은 의미가 있었던 것 같다. 그리고 이 책에서도 같은 아이디어를 여러번 언급하고 있다. 실제로 이 아이디어는 2004년에 출판된 Refactoring to Patterns라는 책으로 실현되었다. 시간이 되는대로 Refactoring to Patterns를 읽어볼 예정이다.
Effective Java Programming Language Guide (이하 Effective Java)는 Java 프로그래밍 언어를 잘 쓰기 위한 책에 속한다. 이 책은 Effective C++ 시리즈나 Exceptional C++ 시리즈처럼 하나의 조언과 그것에 대한 설명을 담은 57개의 항목들로 구성되어있다. 형식 뿐 만 아니라 내용을 보더라도 Java의 Effective C++과 같다고 봐도 무방할 것 같다.
Effective Java의 각 항목들은 반드시 Java 언어에만 국한되는 것이 아닌 일반적인 프로그래밍 원칙들 또는 객체 지향 프로그래밍에서 일반적으로 통용되는 프로그래밍 원칙들도 포함하고 있다. 그래서, Effective/Exceptional C++ 시리즈와 중복되는 항목들도 있다. (예를 들어, ‘Item 14: Favor composition over inheritance’ 와 같은 경우)
이런 종류의 책들은 한번만 읽는다고 해서 그 책들의 조언들을 완전하게 응용하기는 어렵다. 그래서, 단지 각 항목들의 리스트만이라도 주기적으로 보면서 조언들을 상기시켜주는 것이 좋다. (Effective Java의 항목 리스트) 특히, 거의 기계적으로 적용할 수 있는 항목들은 항상 기계의 도움을 받을 수 있도록 자동화해두는 것도 좋은 방법일 것이다. (지난 글에서 언급했던 FindBugs와 같은 이클립스 플러그인들이 도움을 줄 수 있을 것이다.) 한편, 각 항목들로부터 도출되는 보다 일반적인 프로그래밍 원칙들은 마음에 잘 새겨두는 수 밖에는 없을 것이다.
이 책이 출판된지 (2001년) 꽤 오래되었기 때문에, 현재 Java (특히 Java 5.0)의 상황을 반영하지 못하는 항목들이나 언급들이 약간씩 보인다. (예를 들어, type-safe enum 항목이나 doug lea의 concurrency 라이브러리에 대한 언급) 하지만, 반영하지 못하는 점들은 대체로 Java가 개선되었기 때문에 발생하는 것이어서 여전히 그 충고들 자체는 유효하다고도 볼 수 있다.
C++ 프로그래밍 언어에 관한 유명한 책들의 저자들이 해당 언어의 커뮤너티에서 상당히 유명하고 중요한 역할을 수행하고 있는 것을 보면, 분명히 이 책의 저자에 대해서도 알아두는 것이 도움이 될 것이다. Effective Java의 저자인 Joshua Bloch는 Sun Microsystems의 Distinguished Engineer 였고, Java 5.0 명세의 개발과정에도 중요한 역할을 했으며, 현재는 Google의 Chief Java Architect이다. 그는 이 책 이외에 Java Puzzlers도 썼는데, 국내에는 번역되지 않았기 때문에, 아마존에서 주문해서 읽어볼 예정이다.
Effective Java의 내용은 상당히 기본적인 내용에 해당하기 때문에, 실제로 Java 프로그래밍 언어를 사용하면서 깨닫게 되는 문제들을 고려하면 부족한 것이 사실이다. 최근에, 이 책과 같은 스타일의 또다른 책을 찾아보고 있는데, 아직은 없는 것 같다. Effective C++ 시리즈의 Scott Meyers나 Exceptional C++ 시리즈의 Herb Sutter와 같은 훌륭한 저자들이 Java 쪽에는 없는 것일까. Java 쪽의 유명인들이 부족한 것도 아닌데 말이다.
젊은이들이 연기를 하는 것은 그들의 잘못이 아니다. 삶은, 아직 미완인 그들을, 그들이 다 만들어진 사람으로 행동하길 요구하는 완성된 세상 속에 턱 세워놓는다. 그러니 그들은 허겁지겁 이런저런 형식과 모델들, 당시 유행하는 것, 자신들에게 맞는 것, 마음에 드는 것, 등을 자기 것으로 삼는다. ― 그리고 연기를 한다.
읽은 지가 오래되었으니, 작품 개개에 대한 얘기는 다음번으로 미루자. 대신, 책을 읽을 당시에 끄적거린 노트를 들여다보자.
무진은 어디에 있는 도시인가? 안개가 많은 도시라는 것을 볼 때, 바닷가 근처거나 호수가 있는 내륙지방(강원도)의 느낌이 난다. 읽다보면, 호남지방인가 하는 생각도 잠시 든다. 어디에 있는 도시인가는 별로 중요하지 않고, 오히려 별로 알려지지 않은 점이 중요한 것인가? 도시로부터의 도피처? 실락원?
영화 "생활의 발견"와의 관련성. 지방 도시에서 만난 여선생과의 정사라는 스토리라인. "우리 서로 솔직해지기로 해요"라는 대사.
서울과 무진의 공간적 대비. 서울은 이성이 지배하는 공간. 무진은 욕망이 지배하는 공간. 자의식과 무의식. 욕망(비이성)에의 옹호? 주인공의 이중성 자체도 비이성?
부조리극. Camus. 타인의 속물적 행동에 대한 비판과 주인공 자신의 속물적 행동.
사실 이 노트의 마지막 줄에 있는 ‘부조리극’이라는 단어가, 이 소설집 전체에 대한 내 느낌을 대면해준다고 볼 수 있을 것 같다. 작품마다 부조리의 현실, 주인공과 부조리와의 관계는 제각기 다르고, 주인공이 그러한 부조리에 대처하는 방법도 다르지만, 공통된 것은 바로 부조리를 다루고 있다는 것이다. 그리고, 그러한 점은 상당히 마음에 들었다. 나는 까뮈를 좋아한다.
그래도 전집이니까 붙어있는 작가 연표를 보고서 알아낸 것은 이 소설집에 있는 작품들은 김승옥 씨가 스무살 남짓하던 시절에 쓴 것들이란 것이다. 일상으로부터 부조리를 발견해내는 것은 이십대의 정신인 것 같다는 생각이 들었다. 십대가 아직 세상을 잘 몰라서 또는 정신적인 능력이 부족해서 그렇다고 치자면, 왜, 삼십대, 사십대는 아닌가. 이십대만이 가질 수 있는 그러한 정신이란 무엇일까.
어쩌면, 김승옥 씨의 삶 자체가 이러한 물음의 대답이 될 수 있을지도 모르겠다. 이렇게 치열한 작품들을 썼던 작가는 서른이 끝나갈 무렵 ‘광주사태’로 의욕을 잃고 절필을 하게 된다. 그리고, 이제 그는 "하나님에 의해서 내 영안이 열"렸다며 이제 "하나님의 진실을 드러내기 위"한 소설을 쓰겠다고 한다. 그의 치열한 정신을 읽은 나로서는 잘 상상이 가지 않는다. 어쩌면 이런 것이 삶일런지도 모른다.
김대중을 다루고 있고, 또 그를 상당히 옹호하고 있기 때문에, 대선 때면 흔히 나오는 대통령 후보자 선전 책자처럼 여길 사람이 있을지도 모르겠다. 하지만, 이 책은 옹호를 위한 책이라기 보다는 비판을 위한 책이다. 그 대상은 바로 언론과 지식인이다.
전반부에서는 김대중에 대한 내용을 다루고 있다. 책이 쓰여질 당시(1995년)의 김대중에 대한 이미지란 어떤 것인가를 보여주는 것만으로도 상당히 흥미로운데, 그것이 왜 잘못되었고 또 어떻게 조작되었는가를 조목조목 밝혀주고 있다.
김대중에 대한 얘기가 나오면 당연히 지역감정 문제가 나온다. 그 문제의 핵심을 강준만 씨는 언론과 정치평론을 하는 지식인, 그리고 국민의 문제로 보고 있다.
후반부에서는 그러한 문제를 집중해서 다루고 있다. 추리소설을 쓰는 기자, 연예기사를 방불케하는 정치보도, 언론의 이미지 조작 등 우리가 현재 언론에 대해 내리는 평가 – 언론의 문제점들을 잘 정리하고 있다. ‘좆선’이라는 단어가 없던 시절이었던 것을 감안하면 상당히 도전적인 책이 아니었을까 상상해본다. 지식인들의 양비론적이고 정치혐오주의적인 정치평론들도 쓰레기라고 얘기한다.
그의 ‘김대중 옹호’ 중 몇가지는 어떤 사람들의 (자신도 그 근거를 모르는) 김대중 이미지에 대한 신뢰에 금이 가게하지는 못할테고, 아마도 그들은 불편함을 느낄 것이다. 그런 것들을 비판하는 것은 좋지만 부차적인 일이다. 강준만 씨가 주장하고 있는 언론과 지식인의 문제가 우리 모두가 해결해야할 중요한 문제임은 대부분이 동감하리라고 믿는다.
전체적으로 언론이나 정치인, 지식인을 비판하기 위한 상당히 많은 양의 자료를 인용하고 있어서, 약간 놀랐다. 분명히 그런 자료들을 인용하지 않아도 논지 전개에는 문제가 되지 않았을지는 모르겠지만, 그러한 자료들이 이 책의 객관성에 상당한 도움을 주고 있는 것은 사실이다.
대학교를 다닐 때까지도 정치에 대한 혐오를 가지고 있었고, 어린 마음에 무정부주의자를 자처했었다. 그것이 깨어진 것은 강준만 씨의 ‘노무현과 국민사기극’과 김규항 씨의 ‘B급 좌파’를 읽고난 후 였는데, 강준만 씨의 이 책을 좀 더 일찍 읽었더라면, 좀 더 빨리 정치에 대한 올바른 시각을 가질 수 있지 않았을까 싶다.
민요섭이라는 인물의 살인사건을 추적하는 형사의 얘기안에 민요섭과 그가 창조한 인물, 아하스페르츠의 얘기가 담겨있는 액자형태의 소설이다. 액자 내 소설이 풍부한 신학적 내용을 담고 있어서 지적으로는 즐겁지만 자칫하면 흐트러지기 쉬운 집중력을 액자의 틀이라고 할 수 있는 추리소설의 형식이 지탱해주고 있다고 할 수 있다.
‘사람의 아들’, 아하스페르츠는 민요섭이 쓴 소설의 주인공이지만, 민요섭 자신의 생각과 행동을 그대로 반영한다. 민요섭과 아하스페르츠는 동일한 자아다. 현실에서의 민요섭의 행동은 아하스페르츠의 생각에 그대로 반영된다. 혹은 vice versa. 육욕에 눈을 뜨고 기존의 신에 반기를 드는 민요섭과 아하스페르츠는 말그대로 동격이다.
아하스페르츠는 자신의 신에 대해 더이상 믿지 못하나, 신이 존재함을 믿으며, 다른 종교들의 신들을 알기 위한 여행을 떠난다. 소설의 많은 부분은 여러 종교들에 대한 탐색으로 채워져있으며, 지적인 즐거움을 제공한다.
아하스페르츠가 예수와 대면하는 부분은 소설의 절정이다. 바이블에 등장하는 광야에서의 시험을 재구성한 것은 상당히 재미있는 아이디어고, 서양의 고전, 특히 바이블에 미치는 비평가들이 좋아할 만한 내용이다.
아하스페르츠는 무신론 혹은 불가지론의 결정판을 보여준다. 하지만, 형사가 얘기하는대로 민요섭과 아하스페르츠는 새로운 신을 만들지는 못한다. 이것은 민요섭과 아하스페르츠의 한계인 동시에, 이문열의 한계, 그리고 이 소설의 한계일 것이다. 다시 원래의 신으로 회귀해버리는 민요섭이 그의 극단적인 제자에게 살해당한다는 결말은 그 한계가 이 작가와 소설에 한정된 결함이 아니라 인간 전체의 한계가 아니냐는 질문을 던지게 만드는데, 그것은 착각이 아닐까.
이건 반쯤 농담스레 하는 말이지만, FSM과 같은 ‘신’을 보면 인간은 새로운 신을 만들 수 있는 천부적인 능력을 타고났다고 생각할 수 밖에 없다.
Dynamics of Software Development by Jim McCarthy
