조엘 온 소프트웨어 _ 비트와 바이트 : 프로그래밍 실전 (2)

 

5장 ~ 8장 손쉬운 기능명세 작성법

 

기능 명세의 중요성

 

프로젝트를 시작하기 전 기능명세 작성에 대한 중요성은 5장에 나오는 아래 3문장으로 요약할 수 있습니다.

" 모든 사람이 명세서 작업을 해야 한다고 생각은 하지만, 아무도 명세서 작업을 하지 않습니다. "

" 명세서 작업을 하지 않는 관례는 소프트웨어 프로젝트에서 가장 크고 불필요한 위험 요인을 짊어지는 행동입니다. "

" 명세서 작업을 생략하고 바로 코드 작성으로 뛰어드는 프로그래머나 소프트웨어 개발자일수록 놀라 자빠질 정도로 생산성이 낮습니다. 즉 형편엇는 코드를 작성하거나 조잡한 소프트웨어를 양산하며, 결국 전혀 쓸데없는 거대한 위험을 자초해 프로젝트를 위협합니다. "

 

그런데 저는 위 내용을 보면서 

' 팀단위로 거대한 프로젝트를 진행하기 위해서는 기능 명세가 꼭 필요할지도 몰라.
그런데 나처럼 개인이 대규모 프로젝트를 하지 않으면 꼭 필요한 행동은 아니지 않을까? '라고 생각하는 찰나 

바로 다음장에 이런 내용이 언급되었습니다.

" 심지어 코드를 모두 혼자 작성할지라도 순전히 여러분 본인을 위해 명세서 작업을 해야 합니다. 프로그램이 세부적으로 어떻게 동작하는지를 기술하다보면, 자연스럽게 프로그램을 설계하게 됩니다."

 

 

사실 저는 제대로된 프로젝트를 제로베이스부터 만들어본 시기가 6개월밖에 되지 않았습니다.

부끄럽게도 이 때 기능명세에 대한 개념자체도 몰랐고, 머리로 인지하지는 못했지만 

일단 코드부터 작성하면서 시작은 했짐나 마음속 한구석에 뭔가 정리하면서 진행해야하지 않을까?.. 라는 불편한 감정이  남아있었습니다.

 

그래서 일단 무작정 코드 작성하는 행동은 멈추고 아래와 같이 당근에서 급하게 구매한 화이트보드와
평소에 사용하는 WorkFlowy 라는 생각정리툴을 활용해서

 - 지금 어떤 프로그램을 만들어야하는지,
 - 그 프로그램을 만들기 위해서는 어떤 기능들이 필요한지,
 - 그 기능들을 어디에 배치하면 좋을지 ... 

에 대해서 깊게 생각하고 한번 정리해봤었죠.

 

대략적인 구조 설계 경험

 

이렇게 대략적인 "목표" 와 "Software구성" 그리고 "필요기능" 들에 대해서 정리하고 보니

무작정 아무생각없이 코드작성부터 구현하려고 했었던 제 자신이 참 무식하고 용감해보였습니다. ^^;

 

 

하지만 책에서 정리된 내용은 위와같은 단순 내용정리에 국한되지 않았고, 더 체계적이고 범용성이 있는 기능명세가 필요하다고 
언급합니다.

 

기능 명세의 필요성

 

기능 명세가 꼭 필요한 이유는 크게 두가지로 나눠집니다.

• 프로그램 설계에 대한 시간적 구조적 효율성
• 의사소통 시간의 절약

 

프로그램 설계에 대한 시간적, 구조적 효율성에 대해서는 사실 굳이 설명하지 않더라도 모든 개발자 분들이 이해할거라고
생각합니다.

 

위 이미지처럼 아무런 계획표, 기능명세가 없이 시작한 프로젝트는 필요한것 모듈들이 생각나면 그때 그때 쌓아올리다가 
결국 예상치도 못한 결과로 이어지기 마련인거죠.

 

그래서 미리 "이러이러한 내용과 구성으로 집(프로젝트구성)을 지을것이다!" 라는 추상적인 내용을 문서화함으로써
갈대같은 마음의 고객님들 요구사항과 예상치 못하는 상황들을 유연하게 처리해낼 수 있고,
기초를 탄탄하게 잡을 수 있습니다 

 

저는 사실 시간적, 구조적 효율성에 대해서는 당연히 인지하고 있었지만 

"의사소통 시간의 절약"에 대해서는 크게 인지하지 못했었습니다.

 

사실 이건 시간적 레버리지와 관련된 책에 나온 "메뉴얼화"에 대해서와도 동일한 시각이었기 때문에
이렇게 프로그램의 명세서를 사용해서도 시간적 레버리지를 활용할 수 있구나 라는 시각을 갖게 해주었습니다.

 

오늘도 이 전 직장에서의 경험을 간략하게 이미지로 그려보자면 아래와 같은 상황이 수도없이 반복되었습니다. 

영업부, 기획부, 셋업부서등 관련부서의 시도때도 없는 질문

 

설비에 대한 프로그램을 개발하고 있을 때 

관련부서에서는 정말 시도때도 없이 내려와서 설비에 관한 질문들을 늘어놓습니다.

그럴때마다 답변하고, 잊어버린 부분이 있으면 다시 찾아봐서 답변해줘야하고...

 

저는 프로그램을 개발할 때 이런 간섭들과 시간을 존중받지 못한다는 상황이 너무 싫어서 이런 방법을 썼습니다.

설비에 붙어있는 포스트잇

설비에 자주물어보는 FAQ(?)를 포스트잇 작성해서 붙여놓고 관련 부서분들이 와서 여쭤보면

위에 붙어있는 포스트잇을 보시면 된다고 말씀드렸죠 ^^;;..

 

어떻게 보면 예의가 없어 보일수도 있겠지만 

사실상 모두에게 이득이 되는 일이라고 생각하고 한 행동이었습니다.

 

물론  좀 더 디테일하게 들어가서
 - 관련 부서사람들에게 어떠한 방식으로 프로그램을 구성할 것인지 
 - 메뉴얼을 만들 때 기술집필가에게 어떤 부분을 전달할 수 있는지
 - 이 프로젝트를 마무리하는데 얼마나 걸릴 수 있을지

에 대한 부분을 기술명세에 구체적으로 작성함으로써의 의사소통의 효율성을 높일 수 있다고 나와있지만

위 포스트잇 사용과 결이 비슷하다고 생각합니다.

 

결국은 관련된 "모두가 알아볼 수 있는" 그리고 "알아보기 쉬운"  깔끔하고 센스있는 기술 명세를 만듦으로써
일일이 설명해줘야 하는 시간을 아주 효율적으로 절약할 수 있는 것입니다.

 

기능 명세 작성법

 

규칙1. 재미있게 씁시다
규칙2. 명세를 쓰는 작업은 머리가 돌아가도록 코드를 쓰는 작업과 유사하다.
규칙3. 최대한 단순하게 작성하라
규칙4. 여러차례에 걸쳐 검토하고 다시 읽어라
규칙5. 표준양식은 해롭다고 간주한다.

 

// 기술 명세에 관한 디테일한 작성방법은 따로 글을 작성할 예정입니다.
// URL

관련 디테일한 글은 따로 작성하겠지만 위 규칙 5가지를 관통하는 한마디의 문장이 마지막에 나옵니다.

"명세는 사람이 읽어야 하는 문서입니다. "

 

 

 

다음 글은11장 고리타분한 버그수정에 관한 글을 작성할 예정입니다.

 

위 챕터를 잠깐 읽어봤을 때 단순히 버그를 수정하는 간단한 내용이 아닌 사업적인 내용과 버그와의 연관성을 통찰력있게 풀어낸 내용이라 인상깊은 글을 남길 수 있을 것 같습니다.