Joel on Software   조엘 온 소프트웨어

한글로된 다른 "Joel on Software" 글들

영어로된 다른 "Joel on Software" 글들

필자 메일주소(영어만 사용)

(제 1부는 다 읽어보셨는지? 아직 읽지 않았다면, 여기를 클릭.)

이 글은 기술스펙이 아니라 기능스펙에 관한 것이다. 이 두 가지를 혼동하는 사람들이 많은데, 이에 관해 표준 용어가 정의되어 있는지는 알 수 없지만, 필자는 이들 용어를 다음과 같은 의미로 사용하고 있다.

1. 기능스펙은 제품이 어떻게 작동되는가를 전적으로 사용자의 관점에서 기술한다. 즉, 제품의 기능에 대해 이야기할 뿐, 그 기능을 어떤 방법으로 구현할 것인가에 대해서는 신경 쓰지 않는다. 기능 스펙은 화면, 메뉴, 대화상자 등을 구체적으로 기술한다.
2. 기술스펙은 프로그램의 내부적 구현 방법을 기술한다. 즉, 데이터 구조나 상관 데이터베이스 모델, 프로그래밍 언어나 툴의 선택, 알고리즘 등에 관해 이야기한다.

어떤 제품을 설계할 때 가장 중요한 것은 사용자의 경험을 명확히 규정하는 것이다. 어떤 화면이 나타나고, 각 기능은 어떻게 작동되며 또, 어떤 일을 수행할 것인가 등등. 이와 같은 것들을 어떻게 구현할 것인가에 대한 걱정은 그 다음 문제다. 그 제품이 어떤 기능을 제공할 것인가가 결정되기 전에는 어떤 프로그래밍 언어를 사용할 것인가를 놓고 백날 논쟁을 벌여봐도 아무 소용이 없다. 이 글에서는 기능스펙에 대해서만 이야기를 진행할 것이다.

필자는 잘 만들어진 스펙이란 어떤 것인가를 제시하기 위해 간단한 스펙을 보기로 작성하였다. 다음 단락으로 넘어가기 전에, 먼저 스펙 샘플을 읽어 보시라.

다 읽어보셨는지?

아직 읽지 않았다면, 지금 읽기를 클릭한다. 샘플을 먼저 읽어봐야만 좋은 스펙의 요건에 대해 이해할 수 있다. 스펙 샘플을 모두 읽을 때까지 필자는 여기서 독자 여러분을 기다릴 것이다.

(참을성 있게 기다리는 중...)

자, 다 읽어보셨다면, 이제 스펙에 꼭 포함되어야 할 요건들에 대해 살펴보기로 하자.

기권조항. 순전히 자기 방어를 위한 것이다. 스펙 작성시 “이 스펙은 최종안이 아닙니다” 라는 식의 문장을 포함시킬 경우, 적어도 불만에 찬 사람들이 떼거리로 몰려와서 스펙 작성자를 물어뜯는 사태는 면할 수 있을 것이다. 시간이 흐르면서 스펙의 최종안이 완성되어가면, 이 문장을 다음과 같이 바꿔 쓸 수도 있을 것이다. “이 스펙은 분명히 최종안이지만, 미진한 부분이 있다면 말씀해 주십시오.”   

단독저작자. 스펙 작성은 팀 차원에서 이루어져야 한다고 믿는 소프트웨어 업체들도 있다. 하지만, 경험이 있는 독자라면, 여러 명이 한편의 글을 공동으로 써야 한다는 것이 얼마나 괴로운 일인지 잘 알 것이다. 공동집필 같은 것은 막대한 컨설팅 수수료를 정당화하기 위해 바쁘게 일하는 척 해야 하는 경영컨설팅회사한테나 어울릴 일이다. 이런 회사엔 하버드를 갓 졸업한 신입 컨설턴트들이 잔뜩 있으니까. 스펙은 단한사람이 책임지고 작성해야 한다. 만일 제품의 규모가 너무 방대한 경우에는 제품을 몇 개의 영역으로 나눈 후 각각의 영역에 대해 한 사람씩 책임지고 스펙을 작성하도록 해야 한다. 스펙에 자기 이름만 올려서 한 사람이 “공로를 독차지”하는 것은 이기적인 발상이라거나 “팀워크”를 저해한다고 생각하는 회사도 있다. 한마디로말도안되는소리다. 공로를 차지하는 것이 아니라, 자신이 스펙을 만든 프로그램에 대해서 책임을 져야 하는 것이다. 스펙에 문제가 있을 경우, 이를 책임지고 수정할 사람이 있어야 하며, 스펙에 이름을 올린 담당자가 바로 그 책임자가 되는 것이다. 

예상시나리오. 개발자는 제품을 설계할 때 사람들이 그 제품을 어떻게 사용할 것인가에 대한 생생한 시나리오를 머리 속에 그려야만 한다. 그렇지 않으면, 실제 용도와는 동떨어진 제품을 설계하게 된다 (Cue?Cat은 그런 제품의 예라 할 수 있다). 제품의 고객층을 선택한 후, 각 고객층에서 이 제품을 가장 일반적인 방식으로 사용할 가공의 전형적인 사용자를 상정하라. 가공의 사용자 및 예상 시나리오에 관해서는 필자가 쓴 UI 설계론의 제 9장에서 자세히 다루고 있다 (이 글은 온라인 상에서 무료로 제공된다). 시나리오가 생생하고 현실적일수록, 가공의, 혹은 현실속의 사용자들을 위해 보다 나은 제품을 설계할 수 있다. 필자가 아주 자세하고 구체적인 묘사에 신경을 쓰는 이유도 그 때문이다. 

비(非)목표항목. 팀 단위로 제품을 개발하는 경우, 팀원마다 각자가 애호하는 결코 포기할 수 없는 기능이 하나씩은 있게 마련이다. 이런 기능들은 모두 포함시키다 보면, 개발 기간은 무한정으로 길어지고 돈도 너무 많이 들게 된다. 따라서, 필요한 기능들만 추려내는 과정이 요구되며, 이를 위해 가장 효과적인 방법은 스펙에