Book

The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition by Frederick P. Brooks

소프트웨어 엔지니어링 과목을 수강한 적이 있다면, 소프트웨어 엔지니어링에 어느 정도 관심이 있다면, 한번쯤은 이 책 제목 정도는 들어보았을 것이다. M-MM은 소프트웨어 엔지니어링의 고전이다.

Brooks는 IBM에서 OS/360 개발 프로젝트의 관리자였다. 나중에 Brooks는 이 경험을 분석하고, 그것에 관하여 여러 동료들과 논의했다. 그래서 그 결과로 나온 책이 바로 M-MM이다. 이 책은 각각 하나의 주제를 가지고 있는 에세이 모음의 형식으로 되어있다.

그 중에서도 가장 유명한 내용은 아무래도 Brooks’ Law가 나오는 책과 동명의 에세이인 ‘The Mythical Man-Month’일 것이다. Brooks’ Law는 간단히 말하면,

늦어진 소프트웨어 프로젝트에, 인력을 더 투입하면, 그 프로젝트는 더욱 늦어진다.

는 것이다. Brooks의 논지를 따라가다보면 당연한 얘기다. 하지만, M-MM이 쓰여진 지, 30여년이 지난 지금도, 소프트웨어의 생산을 부품 생산 공장에 빗대어 생각하려는 경향 – 미신은 여전히 존재하는 것을 보면, Brooks’ Law는 아직도 강력한 의미를 지니고 있는 것 같다.

이 책이 워낙 오래 전에 쓰여진 책이라, 현재의 기술에는 약간 맞지 않는 얘기도 나오지만, 대부분은 여전히 유효한 얘기들이다. 뿐만 아니라, 요즘에 나오는 소프트웨어 개발에 관한 수많은 철학의 근간은 M-MM에 빚지고 있는 것으로 보인다.

내가 산 책은 1995년에 나온 Anniversary Edition으로, 그 시점에서 원래의 M-MM에 대한 스스로의 평가를 내리고 있다. 특히, 인상적이었던 것은 , 원래 Parnas가 주창한 Information Hiding을 격하게 비판하던 Brooks가, “Parnas Was Right, and I Was Wrong about Information Hiding”이라고 적으면서, 자신이 틀렸음을 솔직하게 인정하고 있다는 것이었다.

Anniversary Edition에는 역시 엄청나게 유명한 에세이인 “No Silver Bullet”을 함께 싣고 있는데, 이 에세이는 소프트웨어 개발자라면 반드시 읽어봐야할 에세이라고 생각한다. (인터넷에서도 쉽게 구할 수 있고, 번역도 되어있는 걸로 알고 있다.) 이 에세이는 소프트웨어 개발에 있어서의 어려움은 본질적인(essential) 어려움과 비본질적인(accidental) 어려움으로 나눌 수 있다고 얘기한다. 비본질적인 어려움은 기술의 발전과 함께 개선되고 점차 사라져왔지만, 본질적인 어려움에 있어서의 기술 발전은 10년 내의 범위에서 크게 이루어지지 않을 것이다라는 그의 예측은, 이 책이 쓰여진 1975년에도, Anniversary Edition이 쓰여진 1995년에도 맞았고, 지금도 맞지않을까 하는 생각이다. 그가 생각하는 본질적인 어려움의 궁극적인 해결책은 소프트웨어 컴포넌트의 시장화를 통한 재사용이다. 현대에는 어느 정도 컴포넌트의 시장화가 진행되었지만, 본질적인 어려움을 해결할만큼의 재사용에 있어서는 벽에 부딪히고 있는 것이 실정이다. 하지만, “Software Factory”같은 개념을 발전시켜 나가고 있고 그와 같은 개념은 바로 Brooks의 이상을 정확하게 표현한 것이 아닐까 싶다.

흔히, 고전을 “오래된 것”, 그래서 낙후된 것으로 생각하는 사람들이 많다. 하지만, 고전의 참뜻은 “전범”이다. 그리스/로마 신화를 이해하지 못하고서, 서양의 미술을 이해하기 힘든 것처럼, 소프트웨어에 관해 이해하기 위해서 반드시 읽어야할 책들 중의 하나가 바로 M-MM이다.

Writing Solid Code by Steve Maguire

번역판을 읽었다. 원제는 ‘Writing Solid Code: Microsoft’s Techniques for Developing Bug-Free C Programs’. 대체로 C/C++ Programmer를 대상으로 한 버그를 줄이기 위한 프로그래밍 기술에 관한 유명한 책이다. 하지만, programming language에 한정되지않는 조언들도 있다. Steve Maguire의 Microsoft에서의 실제 경험을 바탕으로 지어진 책이고, 실제로 그의 경험들이 예시로 등장한다.

이 책에는 다음과 같은 조언들이 등장한다.

– Enable compiler warnings and pay attention to them.
– Use assertions to validate your assumptions.
– Don’t quietly ignore error conditions or invalid input.
– For a complicated, critical algorithm, consider using a second algorithm to validate the first. (e.g. validate binary search with a linear search).
– Don’t write multi-purpose functions such as realloc (it can grow memory, shrink memory, free memory, or allocate new memory — it does it all).
– Check boundary conditions carefully.
– Avoid risky language idioms.
– Write code for the “average” programmer. Don’t make the “average” programmer reach for a reference manual to understand your code.
– Fix bugs now, not later.
– There are no free features; don’t allow needless flexibility (like realloc).
– Ultimately the developer is responsible for finding bugs; he shouldn’t write sloppy code and hope that QA will find all his bugs.

[from Paul J. Mantyla’s comments in Amazon]

대체로 programming을 1-2년 정도 한 경험이 있는 사람이라면, 이러한 충고들은 대체로 스스로 익힐 수 있다. 시행 착오를 피하기 위한 책 정도가 될까. 오래된 책이라서 (1993년에 출판), 설명을 위한 예들 역시 오래된 감이 있지만, 충고들 자체는 여전히 유효하다. C/C++ programming job을 얻기 전의 학생들은 한번씩 읽어보면 좋을 듯한 책이다. 어느 정도 숙련된 programmer라면 부담없이 읽어볼만한 책이라서, 화장실에 두고 심심풀이로 읽는 것도 나쁘지는 않을 듯하다.

번역은 몇가지 용어의 번역이 모호해서, 원서를 찾아보기도 했지만, 무난한 편이었다. 번역서다 보니, 1-2일 정도만에 다 읽을 수 있었다.  조판 자체가 깔끔하지 못해서, 딱히 소장하고 싶은 마음이 들지 않는다. 번역서는 누군가에게 줘버리고, 원서만 가지고 있을 생각이다.

Test Driven Development: By Example by Kent Beck

TDD는 XP와 함께 매우 유명한 프로그래밍 기술 중의 하나다. 어느 정도 TDD나 Agile software development methodology에 관심이 있는 사람이라면, “Test First”가 TDD의 가장 중요한 idiom을 알고 있을 것이다. ‘automated test를 먼서 작성하고, test를 동작하게 만들기 위한 가장 간단한 code를 작성하고, refactoring은 가능한 한 뒤로 미루라’는 것이 TDD의 기본이다.

이 책은 세 개의 파트로 나뉘어있다. Part I은 어떤 story (일종의 requirement)를 구현하는 과정을 TDD를 사용해서 보여주고 있다. Part II는 xUnit이라는 tool을 사용해서 TDD를 좀 더 편리하게 수행하는 것을 보여주고 있다. Part III는 TDD와 연관된 여러가지 pattern들을 정리해두었다.

TDD는 여러가지 이익을 가지고 있지만, 가장 마음에 드는 것은 test 설계부터 하기 때문에, 구현자의 입장보다 사용자의 입장에서 먼저 생각해보게 되고, 결국 interface의 품질이 더 좋아진다는 것이다. interface는 중요하지만, implementation은 그다지 중요하지 않다. implementation은 변경할 수 있고, interface는 그렇지 않을 가능성이 크기 때문이다. 이미 사용자들이 interface를 사용하고 있다는 이유로 대충 설계해놓은 interface를 개선할 수 없게되는 경우를 흔히 볼 수 있다.

번역도 되어있고 하니, 한번쯤은 읽어볼만한 책이다. 아마 집중해서 읽으면 2-3일이면 다 읽을 수 있을 듯 하다.

Object Thinking

‘Introduction to Software Engineering’ 과목에서는 Object-Oriented Design을 가르친다. 간단한 정의와 함께, UML design 과정에서 use case로부터 object를 골라내서 class diagram을 그리는 법은 가르친다. 하지만, 아무도 object-oriented programming paradigm 뒤에 들어있는 생각을 가르쳐주지는 않는다. (물론, 다룰 주제가 많은 software engineering 과목에서 OOP를 깊게 설명하기는 어렵다.)

OOP language를 쓰는 것은 일종의 유행이다. 모두들 그 이유를 잘 알지도 못하면서 OOP를 선호한다. 심지어는 그것이 무엇인지도 모르면서 말이다. 사실, 나도 그런 사람들 중의 하나였고, C를 사용한 procedural programming paradigm에 익숙해지고 난 후, 주로 OOP language (C++, Java, Python, Ruby, …)를 사용하기 시작하면서, 계속 던지게 되는 질문은 OOP란 무엇인가, 대체 procedural programming paradigm보다 object-oriented programming paradigm이 무엇이 우월한가라는 것이었다.

‘Object Thinking’은 이러한 질문에 답변해주는 책이다. 즉, SE 과목에서 한두페이지의 페이지에 설명해놓은 것을 이 책에서는 300페이지에 걸쳐서 설명해놓은 책이다. OOP는 technique이 아니라 paradigm이다. 생각하는 방식은 누군가의 간단한 한마디 말로는 바뀌기 힘들다. (물론 그런 경우도 있다.) ‘Object Thinking’은 ‘object philosophy’, ‘object culture’란 말을 도입한다. 당연하게도, 사상(thinking)에는 철학(philosophy)이 전제되고, 문화(culture)가 따르고, 역사(history)를 가지기 마련이다. object thinking의 중심 원리(principle)들과 역사를 설명하고,  다른 philosophy와 culture와 대조를 함으로써 object thinking이 무엇인지가 조금씩 드러난다.

이 책에서는 단지 OOP가 무엇인지에 대해서만 다루고 있는 것은 아니다. OOP 외에도 software development의 여러가지 생각(thought)들을 object culture의 범주안으로 통합시킨다. 특히, XP와 같은 Agile software development가 여기에 해당된다. 따라서, 이 책에서 얘기하는 ‘object thinking’은 단지 OOP가 아닌 것이다.

또, 이 책에서 설명하는 OOP는 Booch를 중심으로 표준화된 전통적인 SE 진영의 OOP와는 조금씩 다르게 보인다. 여러번 책에서 언급되는 Smalltalk community 쪽(이를 공식적으로는 어떻게 지칭하는지 모르겠다.)에서 발전된 생각으로 보인다. 한가지 예로, OOP에 관한 여러 책들에서 object란 data와 algorithm의 결합이라고 지칭하지만, 이 책에서는 그러한 생각을 과감하게 거부한다. object란 behavior로 정의된다고 주장한다. 이러한 생각 한가지만으로도 object design에는 엄청난 영향을 미치게된다고 생각된다. (이 주제에 대해서는 나중에 따로 다뤄보겠다.)

아직 번역서가 없지만, 여력이 된다면, 또는 언젠가 번역이 된다면, 반드시 읽어보라고 추천해주고 싶은 책이다. 시간이 난다면, 이 책에서 인상 깊었던 생각들을 조금씩 블로그에 정리해볼까도 한다.

The C++ Programming Language

“More Effective C++”와 “Effective STL”을 번역하신 곽용재님이 번역작업 중이시고, 초고를 탈고하셨다고 한다. The C++ Programming Language는 C++의 창안자인 Bjarne Stroustroup이 쓴 책인 만큼 권위있고, 자세하며, 잘 쓰여진 책이다. (Books for Software Development 참조) C++ 을 배우는 사람들이 C++ 책을 추천해달라고 할 때, The C++ Programming Language를 추천해줄 수 없었던 가장 큰 이유가 번역이 되지 않았다는 사실이었는데, 앞으로는 대답이 달라질 수 있을 듯하다.

Joel On Software

“Rapid Development”를 번역하신 박재호님이 번역작업중이시다. 이 책은 원래 개발자들 사이에 매우 유명한 “Joel On Software”라는 Joel Spolsky의 홈페이지 내용을 책으로 엮은 것이다. 나는 송민철 팀장님이 알려주신 “The Joel Test”를 통해서 Joel On Software를 알게되었는데, 이 후로 계속 RSS를 구독중이다. 아쉽게도, 원서를 아마존을 통해서 이미 사버려서, 번역판을 살 일은 없을 것 같지만, 이런 좋은 책이 번역된다는 것은 매우 기쁜 일이다.

More Exceptional C++

Herb sutter의 “Exceptioanl C++”의 후속작이다. Exceptioanl C++ 처럼 Guru of the Week item을 책으로 엮어서 펴낸 책이다. 때문에 책에 있는 내용들은 거의 전부 웹에서 볼 수 있고 내용도 거의 비슷하다.

C++ In-Depth 시리즈의 번역 quality는 그동안 믿을만 했기 때문에, 별 걱정 없이 번역판을 읽었다. 이로써, 그 시리즈의 번역된 중급서들은 다 읽은 셈이다.

내용은 Scott Meyers의 Effective C++과 비슷한 부류의 것을 기대하면 된다. 즉, C++ 언어를 잘 쓰는 것에 대한 책이다. 여러가지 주제를 다루고 있어서 딱히 한정해서 얘기하기는 힘들 것 같다. 목차를 살펴보라.

형식은 C++ programming 시에 발생하는 문제들을 내놓고 이에 대한 답을 제시하는 식이다. (혹자는 문제집 풀고 있냐고…) 개인적으로 문답법을 상당히 좋아하긴 하지만, 이 책을 읽을 때는 그냥 무시하고 죽죽 읽어나가버렸다.

지금 읽는 소프트웨어 개발 관련 책만도 2권이나 있고 다른 읽을 책도 많지만, C++ 언어 계열로 더 읽는다면, 최근에 C++ In-Depth 시리즈에 추가된 Herb Sutter와 Andrei Alexandrecu의 저작, C++ Coding Standards를 꼽고 싶다. 제목으로부터 오해할 가능성이 높겠지만, tab size를 어떻게 쓰고, bracket 위치를 어디에 두는가에 관한 책이 아니다. 실제로 읽기 전엔 모르겠지만, EC++ 계열의 practice들을 정리해서 “표준적인 coding style”로 집약한 책으로 보인다. 하나를 더 고르라면, C++의 아버지 Bjarne Stroustroup이 C++ 언어의 진화 과정을 설명하고 왜 현재의 문법이 생겼는지를 설명해주는 Design & Evolution of C++을 꼽겠다. 언어의 역사를 이해하는 것은 언어의 철학을 이해하는 데에 도움을 주고, 언어의 철학을 이해한다면 그 언어를 쓰기도 쉬워진다.

덧붙여, 프로그래밍 언어에 대해 왜 그렇게 열심히 공부하냐는 사람도 있는데, 이는 작문법을 왜 그렇게 열심히 공부하냐는 질문과 비슷하다. 작문을 잘하기 위해서는 물론 작문을 많이 해보아야겠지만, 다른 사람들이 이미 고민해둔 좋은 작문방법이 있다면, 시행착오를 통해서 배우는 것보다는 이를 공부하는 것이 훨씬 시간이 절약되기 때문이다. 게다가, 작문법에는 언어간의 벽을 뛰어넘는 무언가가 있어서, 다른 언어에 대해서도 적용되는 경우가 있다. 반대로, 언어간의 벽을 뛰어넘지 못하는 철학적인 요소도 작문을 하는데에 필요하다.

물론, (프로그래밍을 처음 배우는 모든 사람들에게 항상 얘기하듯이) 작문법만 공부해서는 절대로 문장가가 될 수 없다는 점을 유념해야할 것이다. 역사 공부도 중요하고 철학 공부도 중요하지만, 실제로 다작을 해보는 것처럼 중요한 것은 없다. 마찬가지로 어느 정도 프로그래밍에 대한 지식을 익히고 나서는, 실제로 프로그래밍을 해보지 않는 한, 절대로 더 높은 단계로 올라설 수가 없다.