Joel on Software

Joel on Software   조엘 온 소프트웨어

 

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

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

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

 

손쉬운 기능 스펙 작성법 –  제 2부 : 스펙이란 무엇인가?


글 : Joel Spolsky
번역 : AhnLab
2000년 10월 3일 화요일

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

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

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

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

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

읽어보셨는지?

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

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

                     [Image]

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

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

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

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

()목표항목. 단위로 제품을 개발하는 경우, 팀원마다 각자가 애호하는 결코 포기할 없는 기능이 하나씩은 있게 마련이다. 이런 기능들은 모두 포함시키다 보면, 개발 기간은 무한정으로 길어지고 돈도 너무 많이 들게 된다. 따라서, 필요한 기능들만 추려내는 과정이 요구되며, 이를 위해 가장 효과적인 방법은 스펙에 ()목표 항목을 포함시키는 것이다. , 하지않아야 항목들을 명시하는 것이다. 비목표 항목은 제품에서 배제할 구체적인 기능이 수도 있고 (가령, “텔레파시를 통한 사용자 인터페이스는 제외한다!”), 아니면 보다 일반적인 사항이 수도 있다 (이를테면, “이번 버전에서는 처리 속도에 대해서는 신경 쓰지 않기로 한다. 제대로 작동만 된다면 느려도 상관없다. 처리 속도는 2.0 버전을 개발할 , 시간이 되면, 최적화할 것이다.”) 이와 같은 비목표 항목을 선정하는 과정에서 논쟁이 있을 수도 있지만, 가능한 조기에 공개적으로 배제 항목을 확정하는 것이 중요하다. 같은 항목은, 아버지 부시 대통령의 표현처럼 절대로 하지 않아야 한다

개요. 스펙에 대한 목차와 같은 부분이다. 개요는 간단한 순서도의 형태로 작성할 수도 있고, 혹은 프로그램의 구조에 관한 넓은 논의가 수도 있다. 개요를 읽고 나면 전체적인 그림을 그릴 있고, 세부 항목을 보다 쉽게 이해할 있다.

세부항목. 마침내 세부 항목을 기술할 차례다. 대부분의 사람들은 자신이 알아야 특정 사항만 빼고는 세부 항목은 대충 읽고 넘어간다. 가령, 서비스를 설계하는 경우, 세부 항목 부분을 기술하는 가장 좋은 방법은 모든 화면마다 정식으로 이름을 부여하고 각각의 화면을 기가 질릴 만큼 아주 자세하게 기술하는 것이다.

세부항목 기능 스펙에서 가장 중요한 부분이다. 아마 앞서 제시한 스펙 샘플에서 필자가 로그인 오류에 대한 모든 가능한 경우의 수를 고려하여 얼마나 무자비하게 자세한 내용을 기술했는지 보았을 것이다. 이메일 주소가 유효하지 않은 경우에는 어떻게 것인가? 패스워드가 맞지 않는 경우에는 어떻게 것인가? 등등. 모든 경우에 상응하는 코드를 실제로 작성하게 되는데, 더욱 중요한 것은 각각의 모든 경우에 대해 누군가는 의사결정을 내려야 한다는 사실이다. , 사용자가 패스워드를 잊어버린 경우에는 어떻게 것인가를 누군가는 결정해야만 하는 것이다. 의사결정이 이루어지지 않으면 코딩 작업도 불가능하다. 스펙은 같은 의사결정을 문서화해야만 한다.

미해결과제. 스펙의 초안을 작성하는 동안에는 미해결 문제를 그대로 놔두는 것도 무방하다. 필자의 경우, 초안을 작성할 때는 항상 여러 건의 미해결 문제가 포함되곤 한다. , 필자는 각각의 미해결 과제를 금방 식별할 있도록 특수한 방식으로 표시를 해두고, 필요한 경우, 대안을 제시하기도 한다. 이런 문제들은 프로그래머들이 코딩 작업을 시작하기 전까지는 모두 해결되어야만 한다. (프로그래머들에게 쉬운 부분부터 먼저 작업에 착수하도록 지시하고 미해결 문제는 나중에 해결해도 무방하다고 생각할 지도 모른다. 결코 좋은 생각이 아니다. 처음부터 미해결 과제를 안고 시작하지 않더라도, 프로그래머들이 코딩을 진행하다 보면 새로운 문제들이 계속 발생하게 마련이고 이런 문제들을 소화하는 것만으로도 벅차기 때문에 미리 알고 있던 문제는 완전히 해결한 후에 코딩을 시작해야 한다. 게다가, 각각의 문제를 해결하는 방식이 코딩 과정에 중대한 영향을 미칠 수도 있다.)

주석활용. 스펙을 작성할 염두에 두어야 하나의 사실은 프로그래머와 테스트 담당자, 마케팅 담당자, 기술문서 담당자 등을 비롯한 다양한 독자들이 스펙을 읽게 된다는 사실이다. 스펙 작성 과정에서 이런 독자들 특정 대상에게만 도움이 될만한 정보를 생각하게 수도 있다. 가령, 필자는 통상적으로 프로그래머들이 읽어야 기술적 구현 과정에 관한 세부사항은 기술 정보라는 주석을 달아 따로 표시한다. 그러면 마케팅 담당자는 내용은 읽지 않고 넘어가고 프로그래머들은 열심히 읽게 된다. 필자가 작성하는 스펙에는 테스트 정보 마케팅 정보 혹은 문서화 정보 같은 주석들이 많이 포함된다.

지속적인업데이트. 한번에 끝장을 보는 작업 방식을 좋아하는 개발팀도 있다. 프로그램 전체에 대한 설계를 한번에 끝내고 스펙을 작성한 , 이를 출력해서 프로그래머들한테 던져주고는 집에 가면 된다는 식이다. 필자가 말은 이것뿐이다. “ !” 

바로 이런 작업 방식 때문에 사람들이 스펙에 대해 부정적인 생각을 갖게 되는 것이다. 많은 사람들이 스펙을 만들어봐야 아무 소용이 없다. 제품의 기능은 끊임없이 변경되고, 유효기간이 지난 정보만 가득한 스펙은 결코 제품을 반영하지 못한다 말한다.  




이게 도대체 무슨 소린지. 혹시 그들의 스펙은 이상 유효하지 않은 정보만 가득하고 실제 제품을 제대로 반영하지 못하는 지도 모르겠다. 하지만, 필자의 스펙은 다르다. 제품 개발이 진행되는 동안 새로운 의사결정이 이루어질 때마다 지속적인 스펙 업데이트가 이루어진다. 스펙은 항상 제품이 어떻게 작동될 것인가에 대한 전체의 집단적 이해를 반영한다. 스펙은 제품 코딩이 모두 완료된 후에야 (, 모든 기능이 완성되었지만, 테스트 디버깅 작업은 여전히 진행중인 상태) 비로소 최종적으로 확정된다.

필자의 경우, 프로그래머들을 괴롭히지 않기 위해 스펙을 매일 새로 발표하는 일은 삼간다. 대개는 팀원들이 기준으로 삼을 있도록 정해진 서버에 항상 최신 버전을 올려놓는다. 그리고는 이따금씩 주요 작업 단계마다 스펙을 출력하여 팀원들에게 나눠주되, 스펙 전체를 다시 읽어야 하는 수고를 있도록 수정된 부분을 표시한다. 팀원들은 표시된 부분만 찾아서 무엇이 변경되었는지를 확인할 있다.



이 기사는 영어로 Painless Software Specifications Part 2 라는 이름의 기사가 원본입니다. 

Joel Spolsky는 뉴욕에 위치한 작은 소프트웨어 회사인 Fog Creek Software의 창업자입니다. 예일 대학교를 졸업하고 Microsoft, Viacom, Juno등에서 프로그래머와 매니저로 일했습니다.


이 페이지의 내용은 한사람의 의견을 대변합니다.
All contents Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky