[Top 1% Book Review] 왜 PM과 개발자는 늘 문서 가지고 다툴까?

Introduction

오늘은 최근에 읽은 책 하나를 소개하려고 합니다. 개발 프로세스의 역사를 다룬 책인 <고약한 문제, 합당한 해결>인데요. 저를 포함해 거의 모든 개발자들이 개발 스킬에 대해서는 매일같이 공부하는 반면 개발 프로세스에 대해서는 상대적으로 등한시하죠.

하지만 일을 하는데 있어서 "무엇"(==결과)만큼이나 중요한 게 "어떻게"(==과정)이라고 생각합니다. PM에게 모든 프로세스를 떠넘기고 단지 결과물만을 만드는데 집중하는 태도는 스스로를 "PM을 위한 도구"로 취급하는 건 아닐까요. 이 책의 내용이 여러분들에게 보다 숲을 볼 수 있는 관점을 제공할 수 있을리라 생각합니다.

이 글은 "소프트웨어 개발 프로세스에서 왜 폭포수 모델이 문제가 되는 건지", "그래서 그간 소프트웨어 진영에서는 어떤 시도를 해왔는지"에 대해 얘기합니다. 물론 우리는 애자일로 귀결될 것이라는 결말을 이미 알고 있죠. 하지만 대체 어떤 맥락에서 애자일이 나왔는지에 대해 역사적 과정에 대해서는 미처 모르는 분들도 많을 거예요. 그런 관점에서 이 책의 내용이 우리가 제품을 만드는 과정을 톺아보게 하는 좋은 인사이트를 줄 것이라고 생각합니다 :) 

다 읽고 싶지 않은 분들은 보고 싶은 내용만 살펴보세요

1. 전문 지식이 없는 열정은 공허일 뿐이고 양심이 사라진 전문가는 해악일 뿐이다

엔지니어는 자신이 배운 과학적 원리가 내포된 공학적 지식에 기초해서 물건을 만들어야 합니다. 이런 것들을 이 책에서 전문가 정신(프로 의식)이라고 불렀습니다. 분야에 관계없이 공학을 한다는 것은, 단순한 아마추어가 아닌 전문가의 자질을 갖추어야 하는데, 무한동력 기계를 발견하겠다고 인생을 투자하는 아마추어 발명가는 전문가로서 기본적인 공학적 지식이 부족한 것이고, 이에 반해 무한동력 기계를 발견하겠다고 사기를 치는 엔지니어는 전문가 정신이 부족한 것입니다. 전문 지식이 없는 열정은 공허일 뿐이고, 양심이 사라진 전문가는 해악일 뿐입니다.

<고약한 문제, 합당한 해결>, P. 15

"전문 지식이 없는 열정은 공허일 뿐이고, 양심이 사라진 전문가는 해악일 뿐"이라는 문장이 특히나 와닿았습니다. 개발자이기 이전에 한 명의 공학자로서 어떤 마인드셋으로 일을 대해야 하는지, 나는 정말 프로의 마인드로 늘 임했는지 반성하게 만드는 구절이었습니다.

2. 아마추어와 프로 엔지니어의 아홉 가지 차이

1. 아마추어는 사용자가 프로그래머와 똑같이 알고 있다고 가정하는 반면, 프로는 결코 사용자가 알고 있다고 가정하지 않는다.2. 아마추어는 예외를 살면서 일어날 수 있는 것으로 여기지만, 프로는 설계할 때 이미 그 예외적인 경우를 포함시킨다.3. 아마추어는 리뷰를 귀찮게 여기지만, 프로는 리뷰를 환영한다.4. 아마추어는 버그를 닥치는 대로 만들어내지만, 프로는 에러가 없는 프로그램을 출시한다.5. 아마추어는 문서를 마지막에 작성하지만 프로는 처음부터 작성한다.6. 아마추어는 불완전한 명세서 스펙으로 작업하지만, 프로는 명세서를 매우 자세하게 만든다.7. 아마추어는 생명주기를 잘 따르지 않지만, 프로에게는 잘 정의된 단계와 기준이 있다.8. 아마추어들은 당면한 일을 그럭저럭 해나갈 뿐이지만, 프로는 미래와 더 큰 시스템에 대한 관심을 보이며 일한다.9. 아마추어는 컴퓨터를 위해 프로그래밍하지만, 프로는 사람을 위해 프로그래밍한다.

<고약한 문제, 합당한 해결>, P. 54

3. 사용자(대개 경영진)가 개발자의 도움 없이 요구사항을 분석할 때 생기는 문제들

착수 단계는 상위 경엉진 수준에서 수립하는 전략 계획이나 사업을 진행하면서 나온 결과를 토대로 시작한 때가 흔하다. 해결해야 할 문제는 개팔적인 형태로 설명하는데, 즉 목표로서만 언급될 때가 많다. 경영진은 초기 우선순위와 제약조건을 다음과 같이 설정할 때도 있다. "이 프로젝트는 전략적으로 중요하지만, 5백만 달러 이내로 끝내야 해."(...)폭포수 모델을 설명하는 어떤 자료에서는 착수 단계에서 컴퓨팅 전문가의 도움이 필요 없다고 결론짓는다. 사용자는 자신이 해결하길 원하는 문제에 대부분 익숙하기 때문에, 사용자가 대개 분석 작업을 한다. 그러나 나중에 살펴보겠지만, 이것 때문에 문제가 발생한다.

<고약한 문제, 합당한 해결>, P. 65

4. 폭포수 모델이 절대 개발 방법론이 될 수 없는 이유

1. 분석 단계 - 팀이 초기 준비를 마치면 조심스럽게 기존 시스템을 분석한다. 사용자를 인터뷰하고 미리 조사해둔 양식과 보고서, 절차 등을 수집한다.(...) 이때 기존 시스템을 사용하면서 조직이 경험했던 특별한 문제나 요청사항에 주목한다. 또한 여기에서 착수 단계에서의 제약조건을 적용하는데, 불필요한 요구사항을 제거하고 기초 설계 단계를 포함한 아래 단계들의 범위를 조절하기 위해서다.2. 추가 수집 및 재분석 단계 - 마지막으로, 개발자는 현재 시스템을 개선하거나 바로잡을 새로운 비즈니스 요구사항을 수집하고, 사용자에게 어떤 영역에서 어떠한 영향을 끼칠 지 파악하고 조직에는 어떤 변화가 생길지 식별한다.3. 개발 단계 - 개발팀은 지금까지 수집한 자료를 모두 분석해서 새로운 시스템을 개발한다. 이 과정이 (유일하게) 폭포수 모델 프로세스에서 창조적인 부분이다. 시스템 개발에 대해 이야기하고 보고하는 데는 시간을 많이 쓰지만, 정작 실제 시스템 개발을 하는 데는 시간을 정말 적게 들이는 것에 주목하라. 내가 조사했던 폭포수 모델에서는 이런 현상을 전부 목격할 수 있었다.

<고약한 문제, 합당한 해결>, P. 72

앞서 살펴봤듯이 폭포수 모델은 가장 유명한 모델이고, 거기에는 선호할 만한 강력한 근거가 있다. 앞으로 살펴볼 테지만, 애플리케이션 도메인과 조건 변화를 고려해서 폭포수 모델에는 변종이 많이 생겼다. 더구나 애플리케이션의 요구를 충족하려고 맞춤형까지 나왔다. 그럼에도 폭포수 모델에는 크고 작은 문제가 있다. 모델 자체의 문제도 있지만 모델 외적인 문제도 있다. 먼저 모델 외적인 문제에 대해 이야기해 보자.폭포수 모델은 결코 개발 방법론이 될 수 없으며 오히려 프로젝트 관리 기법이라고 주장하는 사람들이 있다. 그들은 폭포수 모델에는 소프트웨어를 만드는 실제 기법이 결여되었다는 것을 근거로 제시한다. 나는 대여섯 종류의 폭포수 모델을 분석해 보았는데 그 내용 중 90퍼센트는 작업에 대 한 언급과 보고로 이뤄졌으며, 나머지 10퍼센트가 무엇을 어떻게 하는지에 대해 설명하고 있었다.

<고약한 문제, 합당한 해결>, P. 99

폭포수 모델에는 심각한 내부 문제가 있으며 일부는 정말 심각한 것이다. 이런 문제 가운데 몇 가지를 아래에 열거했다.• 요구사항(여러분이 원한다면 명세라고 해도 좋다>이 불완전하다.• 폭포수 모델을 적용하는 비용이 비싸다.• 정말 오래 걸린다.(ㅋㅋㅋㅋㅋ)• 변종 폭포수 모델 사이에서 서로 관련이 없는 변종 모델이 많다.• 최종 사용자와 개발자 사이에서 의사소통이 매우 어렵다.•'무엇'을 '어떻게'에서 분리할 수 있다고 가정한다.• 적절한 에러 관리, 새롭게 등장하는 적합한 신기술을 사용하기에 적당하지 않다.• 그리고 마지막으로, 어떤 많은 부류의 문제들엔 그다지 잘 들어맞지 않는다.

<고약한 문제, 합당한 해결>, P. 106

이 중 3번(정말 오래 걸린다)와 5번(최종 사용자와 개발자 사이에서 의사소통이 매우 어렵다), 7번(신기술을 사용하기 적당하지 않다)는 정말 공감가는 부분이었는데요. 개발하면서 특히나 큰 프로젝트에 참여해보신 분들이라면 고개를 끄덕이지 않을 수 없는 내용이 아닐까요.

5. 개발자에게 문서화가 중요한 이유 & 폭포수 모델에서는 왜 문서화가 어려울까?

유지보수 프로그래머는 대개 시스템을 처음 접하기 때문에, 기존 코드를 분석하고 코드가 어떤 일을 하는지 알아내야만 한다. 문서도 항상 충분하지 않은데, 이것은 중간에 문서가 없어지기도 하지만 폭포수 모델을 진행하면서 일정에 쫓겨 문서 작성을 아에 못할 수도 있기 때문이다. 그래서 유지보수 프로그래머는 시스템 정보를 소스 코드에서만 얻는다.

<고약한 문제, 합당한 해결>, P. 87

6. 왜 하드웨어가 아니고 소프트웨어일까? - 불확실성의 근원

소프트웨어를 개발하기 위해 우리가 세워야 할 이정표는 되돌아가는 일 없이 앞으로만 나아갈 것을 요구한다. 그래서 우리가 돌아가거나 다른 데로 가게 되면 길을 잃을 수 있다. 우여곡절 끝에 우리가 저편 어느 지점에 도달했다 하더라도, 많은 실수와 초과 비용, 불완전한 작업과 몸부림친 흔적이 뒤에 남을 것이다. 이런 상황에서 요구사항 변경은 우리를 되돌아가게 하는 이유 가운데 하나가 된다. 그러므로, 우리는 바뀌지 않는 요구사항이 필요하다. 이처럼 확실성이 필요한 것은 우리가 여전히 가야 할 길을 확실하게 표시할 수 없는 우리 분야의 뿌리 깊은 불확실성에 원인이 있다.

<고약한 문제, 합당한 해결>, P. 109

문서는 하드웨어 개발보다 소프트웨어 개발에서 더 중요하다. 우리가 만드는 것은 보이지 않기 때문이다.(...) 프로젝트 관리자는 일이 제대로 진행되는지 판단할 자료가 필요하다. 상/하위 단계에 있는 개발자도 다음에 무엇을 수행할지 이해하려면 적당한 정보가 필요하다. 또한 수평적 통합을 위해 프로세스 선상에 있는 다음 사람에게 정확하고 완전한 기록을 남길 필요가 있다. 말로 해서는 할 수 없는 일이다. 영구적으로 기록되는 문서로 해야한다.

<고약한 문제, 합당한 해결>, P. 89

7. 왜 PM과 개발자는 늘 문서를 갖고 다툴까? - 답은 프로세스(폭포수)야!

아마 한 번쯤은 문서를 놓고 PM과 갈등을 빚어본 경험이 있으실 텐데요. "어떨 때 주로 이런 상황이 발생했지?" 라고 회고해보면 제 경우는1) 큰 프로젝트에서2) 수십 장에 달하는 기획 문서를 이해하려는 과정에서주로 일어났더라구요. 제 능력이 부족해서 문서를 다 이해하지 못해 일어난 건 아닌지 자책한 적도 많았어요. 하지만 이 역시 프로세스(시스템) 관점에서 풀 수 있는 문제였음을 아래 글을 보고 깨달았습니다. 

소프트웨어를 사용하는 조직은 이런 문제점을 잘 알기 때문에 종종 자신들의 요구사항을 '올바르게' 정의하는 작업에 착수하곤 한다. 보통 이런 조직에서는 상위 프로세스에서 시간과 돈의 제약을 받지 않고 하위 단계에 이르기까지 담보성 중간 제품을 얻지 못하기 때문에, 자신들이 생각할 수 있는 모든 것(부엌 싱크대 같은 사소한 것도 포함한다)을 열거하는 엄청난 요구 사항 문서를 내놓는다. "빅토리아 시대 소설"이라고 불릴 만한 이런 장황한 문서는 개발자를 압도하며, 나중에 프로젝트가 산으로 올라가서 서로 손가락질 할 때 조직 간 다툼의 근거가 된다.

<고약한 문제, 합당한 해결>, P. 113

8. 마무리: 우리 개발자들은 어떻게 일을 더 잘할 수 있을까?

이제 컴퓨터의 시간은 극도로 저렴해 졌는데도, 컴퓨터가 우리의 실수를 찾아내게 하거나 아니면 우리를 따라 다니면서 실수를 잡아내게 하지 않고, 우리는 구시대에나 적용할 만한 방식들을 여전히 고집하고 있다는 생각이 든다.

<고약한 문제, 합당한 해결>, P. 110

소프트웨어 엔지니어링이 기술의 발전과 맞물려 성장하지 못하는 것은, 전문 지식이 부족한 아마추어 전문가나 전문가 정신(프로의식)이 없는 전문가에게 가장 큰 원인이 있는 듯합니다. 아무리 기술이 발전하더라도 우리가 모두 아마추어 엔지니어로 남는다면, 무모하게 소프트웨어 세상의 무한동력 기계를 발명하려고 들거나, 프로젝트 시 데모만 하면 시스템이 죽어난다는 데모 귀신 징크스를 불안해하면서 살아갈 겁니다.결국 우리는 기술적으로 예전에 비해서 많이 발전했지만, 우리에게 내리는 부당해 보이는 평가나 처우에 대해서, 혹은 우리는 얼마나 전문가 정신 을 겸비한 엔지니어로서 일을 했는지 자문해 보아야 합니다.

<고약한 문제, 합당한 해결>, P. 15

이 글의 핵심은 폭포수 노답, 애자일 짱!이 아닙니다. 늘 새로운 기술이 하루가 멀다하고 등장하는 반면 개발자들은 왜 그대로인 걸까요? 우리는 그간 어떤 자세로 일을 대하고 있었는지, 어떻게 하면 더 프로답게 일을 할 수 있는지 자문해볼 필요가 있습니다. 이 책은 그에 대한 물음을 던져주는 귀중한 책입니다 :)

Top 1% 개발자로 거듭나는 확실한 처방전, 데브필입니다.