보스에게 이 책을 2권 선물하고 2배 빨리 읽어 오라 해라

"I bought my boss two copies of The Mythical Man Month so that he could read it twice as fast." - @rkoutnik

프로그래밍은 어디에나 있지만 어디에도 없다. 프로그래밍으로 만들어진 소프트웨어는 어디에나 있지만, 많은 사람들에게는 마법처럼 여겨질 뿐이다. 아서 클라크의 유명한 말이 있다. "충분히 발달한 과학 기술은 마법과 구별할 수 없다." 더 나아가 생각해보면, 우리는 소프트웨어라는 마법의 원리는 모르지만 그 결과는 자연스럽게 받아들이는 시대에 살고 있다.

프로그래머의 작업은 시인과 마찬가지로 순수한 사고의 산물에 가깝다. 그는 허공 위에다 허공으로 만든 성을 상상의 힘으로 짓는다. (...) 하지만 프로그램은 실재하는 결과물을 만들어낸다는 점에서 시인의 시구와 달리 현실에 닿아있다. 7 page

프로그래밍은 결국 현실을 개념화하여 다시 현실에 결과물을 만든다는 점에서 상당히 변태스럽다. 소프트웨어는 그것을 정의하는 언어와 그 규칙에 따라 움직이는 연산으로 이루어져 있다고 볼 수 있는데, 다리를 만들기 위해 철근을 박고 콘크리트를 넣는 것보다는 개념적이다. 따라서 소프트웨어 공학은 그 외 전통적인 엔지니어링과는 결이 다른 부분들이 있다. 그러나 이러한 다름이 미신, 오해 그리고 환상을 불러일으킨다.

우리는 개조한 차고에서 두 명이 만들어낸 프로그램이 대규모 팀의 성과를 뛰어넘었다는 신문 기사를 가끔 접하곤 한다. 그리고 프로그래머라면 다들 이런 이야기를 믿을 준비가 되어 있는 것이, 어떤 프로그램이라도 1년에 1000 문장을 작성한다는 업계의 팀들보다야 자신이 훨리 빨리 짤 수 있음을 알기 때문이다. 그렇다면 왜 업계의 모든 프로그래밍 팀이 2인조들로 대체되지 않았을까? 우리는 여기서 '무엇'이 만들어지는지에 주목할 필요가 있다. 4 page

'늦어진 작업에 맨먼스를 더 투입하는 것이 오히려 더 큰 지연을 만들 수 있다', '부족한 시간 탓에 망가진 프로젝트는 다른 이유로 그렇게 된 경우를 모두 합한 것보다 많다.' 등 소프트웨어공학에 관련한 여러 생각들을 읽을 수 있었다. 40년 된 고전을 읽으며 상투적으로 받아들이며 읽지 않았나 싶다. 현명한 말들은 때에 따라 상투적으로 받아드려질 수 있다고 생각한다. 프로그래머인 내가 현실과 결부지어 '나는 얼마나 움직임을 만들어내고 있는가?' 반문해보면 여러 의미로 씁쓸해진다.

갈무리

• 81 먼저, 관리적 재능과 기술적 재능이 모두 뛰어난 사람은 찾기가 어렵다. 생각하는 사람은 드물고, 행동하는 사람은 더 드물며, 생각하면서 행동하는 사람은 가장 희귀하다.
• 159 작은 팀을 맡은 일선 관리자가 일정 지연을 알게 되었을 때 바로 보스에게 달려가는 경우는 드물다. 아마 팀이 지연된 부분을 만회할 수 있을 것이고, 관리자가 문제를 해결할 방법을 찾거나 팀 편제를 바꿀 수도 있으리라. 그렇다면 왜 그런 일로 상사를 걱정시키겠는가? (...) 그러므로 모든 먼지는 양탄자 밑으로 쓸어 넣고 덮어 둔다.
• 209 소프트웨어를 만들 때 고객을 위해 해야 할 일 중 가장 중요한 것은, 제품 요구 사항을 반복적으로 추출하고 상세화하는 것이다. 진실을 말하자면, 고객들도 자기가 무엇을 원하는지 알지 못한다.
• 221 경험상, 시스템 작업 과정에서 마주치게 되는 복잡성은 대부분 조직의 기능이 제대로 작동하지 못할 때 나타나는 증상이다. 같은 수준의 복잡성을 가진 프로그램으로 그린 현실을 본뜨고자 한다면, 문제가 해결되는 대신 원래의 혼란스러움만 그대로 보존하게 된다.
• 245 프로그래밍 시스템 제품은 개인적인 용도로 작성된 프로그램에 비해 아홉 배의 노력이 든다. 내 추정으로는 제품화하는 데 세배, 구성 요소가 시스템에 일관성 있게 포함되도록 설계, 통합, 테스트화하는 데 세 배가 들며, 이 두 종류의 비용은 본질적으로 서로 무관하다.

• 245 프로그래밍이라는 기예는 "우리 마음 깊은 곳 창작에 대한 갈망을 충족시키고, 모든 인간이 공통적으로 지닌 감수성을 즐겁게 하며", 다섯 가지 즐거움을 선사한다.

  • 무언가를 만드는 기쁨
  • 다른 이에게 쓸모 있는 것을 만드는 기쁨
  • 서로 맞물려 돌아가는 부속품으로 이루어진 복잡한 퍼즐 같은 사물을 만드는 매혹적인 경험
  • 반복 없는 작업에서 비롯되는 지속적인 배움의 기쁨
  • 너무나도 유연하고 다루기 쉬운, 순수한 사고의 산물이라는 표현 수단으로 작업하는 기쁨: 이것은 언어로 이루어진 객체들과는 또 다른 방식으로 존재하고 움직이며 동작한다.
• 247 프로그래머들은 순수한 사고로부터 프로그램을 만들어 내므로, 구현에 별다른 문제점이 있을 거라고는 생각하지 않게 된다. 그러나 우리 '아이디어'자체가 흠이 있기에 버그가 생겨난다.
• 247 소프트웨어 프로젝트에 사람을 추가로 투입하는 것은 필요한 전체 공수를 세 가지 측면에서 증가시키게 된다. 업무 재분배 그 자체로 인한 작업과 혼란, 새 인원에 대한 훈련, 더 늘어난 의사소통이 그것이다.
• 249 "시스템이 개념적 일관성을 가져가야 한다면, 누군가 그 개념을 통제해야만 한다. 이것이 설령 귀족 정치라 해도 양해를 구할 일은 아니다."
• 251 "일정 붕괴, 기능적 부조화, 시스템 버그 같은 일들은 모두 오른손이 하는 일을 왼손이 알지 못해서 생긴다." 팀들은 이런저런 가정 속에서 제각기 표류한다.
• 278 성능이나 심지어 사용의 용이성까지 희생하면서 별로 중요하지도 않은 기능을 탑재하려는 유혹에 빠지기가 쉽다. 그런 기능들이 가진 매력은 초반부터 명백하지만, 성능에 미치는 영향은 시스템 테스트가 진행될 때야 비로소 드러난다. 기능이 조금씩 추가되면서 사용의 용이성은 모르는 새 조금씩 훼손되어 가고, 매뉴얼은 점점 비대 해져만 간다.
• 286 버리기 위해 만들지 말라.