나는 명세서 작성을 무척이나 싫어한다. 특히 규모가 큰 프로젝트에서는 자잘한 사항에 대해서도 명세서를 요구하기 때문에 굉장히 성질이 난다. 가뜩이나 시간은 없는데 없는 글재주로 비워진 칸들을 채워야하고, 온갖 요구하는 다이어그램들을 그려줘야하니 정신이 없다. 명세서는 갑이 을에게 "너네 이거 하기로 해놓고 왜 안해?" 라던가 "우린 명세대로 했을 뿐입니다" 하는 계약상의 문서로밖에는 생각이 들지 않는다. 명세서는 프로젝트 시작과 끝을 알리는 계약서 같은 것으로만 인식되며 작은 프로젝트나 개인적인 프로젝트에서는 시간만 축낼 뿐 의미 없는 작업이라고 여겨진다.

무엇이 문제일까?

개발자는 명세서 작성이 코딩보다 오래 걸린다고 생각한다. 이것은 그렇지 않으면서도 그렇다. 일단 공대생 개발자는 글에 약하다. [문서]를 작성한다는 것은 굉장히 피곤한 일로 여겨지고 실제로도 피곤하다. 천마디 단어를 조합하는 것보다 몇 줄의 코드로 설명하는 것이 더 쉽다고 생각하기에 개발자는 문서를 작성하기보다 코드를 작성하는 데에 앞서게 된다. 코드가 명세보다 앞선 경우, 다음과 같은 문제가 발생한다.

* 개발자가 아닌 사람은 그 코드를 이해하기 어렵다.
* 개발자는 자신이 작성한 코드에 집착을 한다.

개발자가 아닌 사람이 코드를 이해하기 위해서는 대단한 노력이 필요하다. 그 언어를 알아야함은 물론이고 코드가 어떻게 동작하는지 일일이 추적해봐야 한다. 대부분 이러한 추적을 실패하고, 개발자는 이 사람을 이해시키기위해 미간에 주름이 잔뜩 잡힌 채 솰라솰라 전문용어를 난무한다.

이때 만약 듣는 이가 "그 코드 듣고 보니 이상하군요, 이렇게 동작해야 할 것 같은데요?" 라고 말하면 두번째 문제가 발생한다. 개발자는 자신의 코드에 굉장한 집착 증세를 보인다. 일단 개발자는 그 사람을 설득하려 든다. "그건 이러이러해서.. 저건 이러이러해서..." 결국 하고자 하는 이야기는 "니가 뭘 안다고 지껄이는거냐. 그냥 넘어가라" 일 것이다.

명세가 먼저 앞섰다면 어땠을까? 개발자는 코드를 이해 못하는 중생들을 가르치기 위해 목이 터져라 외칠 필요가 없다. 코드가 아닌 인간 언어로 작성된 명세는 누구나 읽고 이해할 수 있다. 만약 누군가 "이 기능이 잘못되었어요" 라고 말해도 개발자가 크게 당황할 일은 없다. "그래요? 그럼 이렇게 바꿀까요?" 어차피 글에 약한 개발자는 그 글에 대해 자신이 작성한 코드 만큼 집착을 보이지는 않는다. 이 작업은 코드를 수정하는 것 보다 훨씬 간편하고 빨리 끝나며 기분도 덜 상한다.

이제 개발자는 명세를 통해 도달된 합의에 대해 코드를 작성하면 된다. 개발 과정에서 고민해야 할 상당 부분이 이미 명세를 통해 결정되었으므로 개발자는 결정된 사안을 구현하는데에만 집중하면 된다. 이미 명세를 통해 이해가 된 부분이므로 개발자가 구현한 코드를 다시 힘들게 이해시킬 필요도 없다.

이렇듯 명세는 프로젝트 참여자가 서로 대화할 수 있는 수단을 제공하며 개발자에게 합의된 설계 도면을 제공한다.

여기서 한가지 짚고 넘어가야할 문제가 있다. 명세가 [대화할 수 있는 수단]을 제공해야 한다는 것이다. 대부분 명세라하면 전문 용어로 조합된 이해하기 힘들고 고리타분한 문서로 인식되기 일쑤다. 사실 그렇다. 그렇게 작성해 오고 있으니까! 아직도 많은 사람들은 어려운 단어를 조합하여 최대한 읽기 힘들게 함으로써 자신이 하고 있는 일이 얼마나 위대한가를 보여주기위한 과시용 문서를 작성하고 있다. 이러한 문서는 너무나 이해하기 어려워서 아무도 읽으려 들지 않는다. 읽히지 않는 명세가 대화의 수단을 제공할 리 없다. 이것은 명백히 잘못된 명세이다. 명세는 이해하기 쉽게 작성하여 읽히게끔 해야한다.

혼자서 하는 일인 경우 왠만한 것은 다 머릿속에 들어있으므로 명세를 작성하지 않는 것이 보통이지만 개인 프로젝트도 명세는 반드시 필요하다. 개발자가 자신의 코드에 집착한다는 이야기를 앞서 했듯이, 개발 과정에서 어떤 문제에 봉착하면 개발자는 그 문제를 해결하기위해 발버둥치면서도 정작 이미 작성된 코드는 어떻게든 살리려고 한다. 그러나 이것은 그 문제를 근본적으로 해결하기 못하고 주먹구구식으로 땜질이나 하는 행위와도 같다. 결국 그 프로젝트는 점점 더 알 수 없는 코드들로 엉켜서 최악의 경우 처음부터 새로 작성하는 바보같은 짓을 하게 될 것이다. 코딩보다 앞선 명세는 개발자의 이러한 집착 증세를 피할 수 있게 하고 넓은 시각을 제공하여 프로젝트를 성공으로 이끌어 줄 것이다.

그렇다면 어떻게 해야하나?

명세를 작성하라! 개발 프로세스가 어떤 모델을 따르느냐에 따라 한번에 작성하는 명세의 범위는 달라지겠지만 명세를 작성해야함은 변치 않으며 항상 코딩보다 앞선다.

읽기 쉽게 작성하라! 당신이 쉽게 쓴 명세 때문에 당신이 하고 있는 일의 가치가 떨어진다고 생각하지 마라. 아무도 알아듣지도 못하는 전문용어로 도배된 명세는 일의 가치를 높이는 것이 아니라 아예 관심 밖으로 멀어지게 할 뿐이다.
이 글의 트랙백 주소는 http://semix2.tistory.com/trackback/240 입니다
  1. finally 2006/10/22 21:01 댓글주소 수정/삭제 댓글쓰기

    Joel On Software에서 명세서의 중요성에 대한 글을 읽고 나서 semix2님에 대한 글을 읽으니 새삼 더 중요성을 알게 되었습니다. 명세서 작성은 다른 사람 뿐 아니라 개발자 자신에게 조차도 엄청 큰 도움을 주는 것 같습니다.
    하지만 아직까지도 대부분의 초보 개발자(저를 포함한;;)들은 명세서를 작성하는 것을 보지 못합니다. 저 또한 죠엘책을 읽기전까진 명세서가 무엇인지조차 몰랐으니 ;;

    올블에서 보고 잠깐 한개 읽고 댓글을 달아봅니다;

    1. semix2 2006/10/23 16:59 댓글주소 수정/삭제

      실은 조엘 온 소프트웨어를 보고 느낀 점을 쓴 거랍니다. 회색 박스에 적어 놓았듯이 여태 명세는 왜하나 싶었었는데 그 글을 읽고 나니까 정말 뭔가 잘못하고 있구나 싶더라구요.

      명세 없이 작업을 하다보니 순간 순간 접하는 문제를 적극적으로 수정하기보다는 이미 짜 놓은 코드를 살리는데에 급급한 나머지 우회하려고만 들다보니 결국 프로젝트를 엎어버리는 결과를 늘 초래합니다. 여태 왜 그런지도 몰랐었지요;;

      개발자를 만나게 되서 정말 반갑습니다. 이따 저녁에 블로그 놀러갈게요. ^^

  2. finally 2006/10/24 12:00 댓글주소 수정/삭제 댓글쓰기

    이런이런 ㅋ
    저도자주 놀러올게요^^;

    트랙백이라도한개 날려야겠네요 ㅋㅋㅋㅋ
    제가 지금 신분이 군인이라 ㅋ 자유롭게 인터넷을 하진 못해요~

    하지만 블로그에 재미들인 이상 자주자주업데이트하고 놀러올겁니다^^;

    1. semix2 2006/10/25 10:39 댓글주소 수정/삭제

      ^^ 네, 자주 와주시면 고맙죠!! 워낙 썰렁한 블로그라;;
      군인이시군요. 전 군대 있을 때 프로그래밍 언어를 공부한게 계기가 되었답니다. 갑자기 군대 이야기하니까 막 새록새록.
      건강히 군생활 하시고 좋은 경험 많이 쌓으시길 바래요~