서평

전체적으로는

정반합이라는 단어가 떠오르는 책이었다. 저자는 소프트웨어 분야가 근본적으로 복잡성이 증가할 수 밖에 없는 구조를 가지고 있는 분야라며 충분한 근거를 들어 이야기하였다. 그리고 소프트웨어 분야 종사자들 모두가 머리를 싸매는 이 복잡성을 해결해 줄, 물리학으로 치면 통일장 이론과도 같은 하나의 명쾌한 답(silver bullet)은 존재하지 않는다고 이야기하였다.

그러나 다른 많은 엔지니어들은 그에 대해 반론을 제기했다. 조작할 수 없다는 사실에 반례를 들면서 저자가 언급한 소프트웨어의 본질적인 복합성에 대한 해답을 내놓기도 하였고, 본질이 아닌 부수적인 복합성에 대한 해답을 내놓기도 하였다. 그리고 그것들은 현 시대에서 프로그래밍을 하는 우리들의 삶에 자연스럽게 녹아져있다.

그리고 더 이전에도 엔지니어들은 그 복잡성을 줄이기 위한 어마어마한 노력들을 하였다. 그 결과물은 우리가 지금 숨쉬듯 자연스레 사용하고 있는 것들이다. 일괄 처리 시스템에서 round robin scheduling algorithm 으로 대표되는 시분할 처리 시스템의 등장, 고수준 언어의 개발, UNIX 와 stdio 같은 표준형 개발규격의 탄생 등이 바로 그것이다. xerox labs 등에서 창발한 프로그래밍 패러다임인 OOP 도 포함될 것이다.

복잡성을 줄이기 위한 노력들, 해결할 수 없는 본질적인 복잡성이 존재한다는 저자의 주장, 저자의 주장에 반박을 하기 위해 더 나은 대안을 제시하는 사람들, 그리고 그 사람들의 대안을 합리성을 근거로 검토하여 인정하고 반박하여 더 나은 방향을 제시하는 저자와 사람들의 모습이 잘 담겨져있는 책이었다.

---

책의 내용을 살펴보며

man-month myth

우선 공감이 가는 내용들이 상당히 많았다. 특히 이 책의 제목인 man-month myth 와 직접적으로 연관된 초반부 내용부터가 가장 인상깊었다. ‘진척이 되지 않는 프로젝트에 무작정 사람을 더 투입하는 행위는 해당 프로젝트를 오히려 더 망친다’ 는 주장과 근거들이 담긴 단락부터 정말 흥미진진하고 공감을 해가며 읽었었다.

거기에 저자 본인의 경험법칙과 이런저런 근거들을 복합적으로 적용한, ‘설계에 30%, 구현에 20%, 초안 테스트에 25%, 최종 테스트에 25%를 할당하는 것이 썩 괜찮았다’ 라는 이야기엔 정말 고개를 끄덕이게 되었다. 추가로, 소프트웨어는 시간이 흐르고 기능이 추가되며 유지보수를 거치는 과정 속에서 본질적으로 복잡성이 확대될 수 밖에 없다는 의견에도 상담히 동감했다.

ready to throw away

이 부분 또한 공감가는 부분이었다. 예전에 테슬라와 관련된 techcrunch 의 칼럼 중 봤던 ‘비행중인 비행기의 부품을 고친다’ 라는 말을 항상 기억하면서 소프트웨어라는 건 이름(soft + ware)에 걸맞게 변화란 어쩔 수 없구나 라고 생각하고 있었는데, 이 부분의 표현은 더욱 직설적이었다. ‘버릴 준비를 하라’ 라니.

그러나 이 단락을 읽어보면 읽어볼 수록, 너무 맞는 말이라는 생각이 들었다.

그러므로 우리가 해야 할 질문은 파일럿 시스템을 만든 뒤에 버릴 것이냐 말 것이냐가 아니다. 그 일은 어차피 일어날 것이다. 버릴 시스템을 만들기 위해 계획을 미리 세울 것인가, 아니면 그것을 고객에게 납품하겠다고 약속할 것인가 이다.

파일럿 시스템은 만들어진 후에 폐기되어야 하고, 변화된 발상으로 재설계하는 일이 불가피하단 것을 인지했다면, 변화라는 현상자체를 직면하는것이 도움이 된다.

널리 쓰이는 프로그램을 유지보수 하는 비용은 통상 개발비용의 40% 혹은 그 이상이다. 이 비용은 놀랍게도 사용자의 수에 영향을 크게 받는다. 사용자가 많을수록 더 많은 버그가 발견되는 것이다.

특히 이 부분이 정말 공감이 갔다. 어차피 일어날 것이고, 소프트웨어의 유지보수와 기능개선은 또 다른 유지보수와 기능개선을 낳을 수 밖에 없는 일이기에 변화를 인정할 수 밖에 없다는 이야기.

no silver bullet

무서운 옛날 이야기에 나오는 온갖 괴물 중에서도, 친숙한 모습을 하고 있다가 느닷없이 공포스러운 존재로 변하는 늑대인간만큼 두려운 것은 없다. 그래서 우리는 그들을 영원히 잠에 들게 할 마법의 은 탄환 (silver bullet)을 찾는다.

질병을 관리하기 위한 첫 걸음은 악령설과 체액설(역자 주. 질병은 네 가지 체액의 균형이 깨져서 생긴다는 이론으로 히포크라테스에서 비롯되어 중세 때까지 통용되었다)을 세균 이론으로 대체하는 것이었다. 이 첫 걸음은 희망의 시작이기도 했지만, 그 자체만으로 마술적 처방에 대한 모든 희망을 산산이 부쉈다. 세균 이론의 교훈은 진전이란 많은 노력을 들여서 차례차례 이뤄지는 것이며, 청결이라는 규율에 끊임없이 주의를 기율여야 한다는 것이다.

오늘날의 소프트웨어 공학도 마찬가지이다.

사실 이건 서평으로 남기는 것이 아니라, 아얘 이 단락 하나를 빼서 만들고 싶은 생각이 들었다. 글을 읽으면서 핵심 내용만 정리하자는 문서에도 해당 단락은 거의 모든 내용이 담겨져 있을 정도였다.

간단히 요약하자면, 불편하지만 더 나은 방향으로 가기 위해서는 공감할 수 밖에 없는 이야기를 하는 단락이었다. 소프트웨어는 본질적으로 복잡하다. 물론 이게 모든 시도가 의미없다는 비관적인 이야기는 결코 아니다. 부수적으로 복잡한 요소들을 간단하게 만들기 위한 많은 노력들이 있었다. round robin scheduling 으로 대표되는 시분할 시스템, 고수준 프로그래밍 언어, 그리고 지금 이 글을 적는 2022년 cloud based infrastructure 와 거기서 더 나아간 infrastructure as a code 라는 것까지. 이 모든 것들은 소프트웨어의 (부수적인) 복잡성을 정말 간단하게 만드는 데 많은 기여를 했다.

그러나, 소프트웨어의 본질 자체가 변화 그 자체이고, 표현방식을 아무리 달리 하더라도 개념적 구조물은 동일하며, 소프트웨어를 기술하는 추상화 과정에서 복잡성이 망실되는 것 자체가 오히려 소프트웨어의 본질적인 부분을 잊어버리는 것이라고 할 수 있을 정도라는 특성 때문에 소프트웨어는 본질적으로 복잡할 수 밖에 없고, 소프트웨어의 생산성 향상 중 소프트웨어의 부수적인 복잡성에 대한 개선이 아니라 소프트웨어의 본질적인 면을 물리학의 통일장 이론과도 같은 획기적인 법칙을 통해서 개선을 이뤄내는 개선은 적어도 앞으로 10년동안 나오지 않을 것이라고 하였고, 2022년에 이 글을 봐도 썩 틀린 것 같진 않다.

---

생각해보기

is communication cost really exponential?

초반부의 man month myth 단락에 나온 부분이다. 진척되지 않는 소프트웨어 개발 프로젝트를 위해 무작정 사람을 투입하는 것은 지수적으로 증가하는 의사소통 비용을 고려하지 않은 행위로, 오히려 그 프로젝트를 완전한 파국으로 몰고갈 수 있다는 이야기였다.

어째서 그 의사소통 비용이 지수적으로 증가하냐고 이야기 하였느냐면, $C = n(n-1)/2$ 라는 공식 때문이다. n 은 사람의 수이다. 사람이 2명일 땐 1번만 소통하면 된다. 사람이 3명일땐 3번, 사람이 4명일땐 6번, 사람이 n명일 땐 n(n-1)/2 번 소통을 해야한다. 흥미로운 주제라고 하여 이 주제를 다양한 분야에서 종사하는 친구들이 모여있는 방에 한 번 던져보았다.

이런 의견을 들어볼 수 있었다. 합리적인 설명을 해 주어서 더더욱 공감이 갔다. 결국 의사소통을 하는 사람의 범위는 한정이 되어있기에, 구성원의 의사소통비용의 증가는 완전히 지수적인 증가라고만 보기보단, 선형적인데 기울기가 좀 가파른 선형적인 증가형태가 아닐까? 라는 생각을 하게 되었다. 물론 가파른 수준의 의사소통 비용의 증가 또한 맞다.

또, ‘무작정적인 인력 추가투입’ 이 아니라 적재/적소/적합 인력의 추가투입이 아닌 경우 상황은 얼마든지 달라질 수 있단 점이다. 특히 적합한(프로젝트에 대한 지식이 아직 얼마 없는 사람들) 인력을 투가하기 어려운 경우, 프로젝트의 초창기에라도 투입하는 것이 의사소통 비용이 증가하더라도 결국 장기적인 시간 단축을 이끌어 낼 수 있다는 점 또한 저자는 뒤에서 이야기하였다.

그러나 이 단락은 결국 ‘시간 내에 일이 진척이 안 되니 일단은 사람을 더 넣으면 빨리 해결되겠군’ 이라는 지레짐작을 경계하라는 것이 본질적인 내용이기에, 결국 본질에 대해서는 적어도 소프트웨어 개발자로 살아가는 나로선 정말 깊게 공감할 수 밖에 없었다.

---

무엇을 얻었는가?

생각해 볼 수 있는 기회를 얻었다

‘소프트웨어와 그 복잡성이란 무엇인가’ 라는 것에 대해서 생각해 볼 수 있는 화두. 내가 이 책을 읽으면서 가장 크게 얻어간 점이다. 피상적으로 ‘이름에 애초에 soft 가 들어가는 것이니 많이 바뀔 수 밖에 없는 것’ 이라고 생각했던 내게, ‘그래서 이것이 왜 복잡한 것인가?’, ‘그 복잡함을 구분할 수 있는가?’ 같은 질문들을 던져주고 그 질문들에 대한 저자의 깊은 고민 끝에 내놓은 의견을 책으로나마 들어볼 수 있었다.

그리고 내가 지금은 이렇게 당연하게 사용하는 고수준언어와 고수준런타임, 그리고 클라우드환경의 편한 인프라와 객체지향패러다임의 프로그래밍이 소프트웨어 개발에서 어떤 복잡성 문제를 해결하기 위해 대두되었는지의 그 맥락 또한 알 수 있었다.

진짜 목표를 세우는 데 고민할 수 있는 기회를 얻었다

인생의 목표(A goal of the whole lifetime)라는 개념 자체에 대해 고민해 보기 전까지 나는 목표가 있었다. 되게 간단했다. 연봉 3,000만원 이상의 개발자가 되는 것. 시장에서 그만큼의 능력을 인정받는 개발자가 먼저 되고 싶었다. 학원비 상환을 위한 기준이 반영된 금액이기도 하지만, 일단 난 그러고 싶었다.

그러나 조금씩 더 생각을 해보고, 고민을 해보고, 다양한 사람들을 만나보면서, 이것이 과연 목표일까? 라는 생각이 들었다. 애초에 목표라는 것의 정의를 뭔가 이상하게 한 느낌이었다. 정확히 말하면, 내가 목표라고 생각했던 개념은 사실 인생의 지점 중 하나가 아닐까? 라는 생각을 하게 되었다.

면접 질문으로 ‘존경하는 개발자가 누구인가요’ 라는 질문을 받고, 집에 돌아가서 그 질문에 대해서 진지하게 생각해 본 결과, 반박과 혁신, 그리고 자기파괴를 통해 진보를 해 나가고 있는 개발자인 라이언 달(ryan dhal)이었다. 그리고 내가 개발하는 데 복잡한 문제를 해결해 준 라이브러리/프레임워크 들의 수많은 개발자들, stackoverflow 에 많은 사람들이 접할 법한 문제에 대해서 쉽고 명쾌한 설명을 적어주는 사람들이 내가 존경하는 사람이 아닐까 라는 결론을 내렸다. 그리고 나도 언젠가 그들처럼 누군가에게 기여하고 싶다는 좀 더 추상적인 ‘목표’를 만들게 되었다. 내 인생의 목표라 하면, 정말 내 인생이란 자원의 대부분이 그 목표에 의존한다는 것이기에 안정적이어야 하고, 안정적인 만큼 추상적이어야 한다는 생각을 했기 때문이다.

그리고 이 책을 본 이후로 막연할 정도의 추상적인 목표에서 좀 더 명확한 추상적인 목표를 세울 수 있었다. 그리고 그건 내가 내 이력서에 적은 것처럼 내가 이전부터 한 생각이기도 했다. ‘복잡성을 줄여주는 사람’, ‘세상의 문제를 해결하여 그 문제때문에 귀찮아 하는 사람들을 편하게 만들어주는 사람’. 거기에 한 줄 더 추가하자면, ‘그런 문제를 소프트웨어로 해결하기 위한 사람들이 겪는 문제들을 해결하여 편하게 만들어주는 사람’ 이라는 목표가 생겼다.

기술적인 부분은?

기술적인(technical)한 부분은 얻지 못했다. 정확히 말하면, 이 책은 그런 기술적인 방법론(arts)들에 대해 이야기하는 책이 아니다. 그렇기 떄문에 그런 기술적인 내용을 얻으려고 한 것이 아니었고, 그래서 기술적인 내용은 얻은 것이 없었다고 말 하는 게 정확한 표현이 아닐까 한다.

---

마치며

좋은 책을 추천해준 차봇모빌리티의 장상열 CTO님, 그리고 아테나랩스의 장원표 개발자님에게 감사드립니다. 그리고 이 책을 번역해준 역자 강중빈님, 그리고 이 책을 써주신 프레더릭 브룩스 2세님에게 감사드립니다.