Joel on Software

Joel on Software   조엘 온 소프트웨어

 

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

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

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

 

손쉬운 기능 스펙 작성법 – 제 1부 : 왜 스펙이 필요한가?


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

조엘의 평가 목록 (The Joel Test) 처음 웹사이트에 공개했을 독자들이 가장 민감한 반응을 보였던 항목 중의 하나가 스펙 작성에 관한 것이었다. 스펙을 작성하는 것은 치실을 사용하는 것과 같아서, 필요성은 누구나 인정하지만 아무도 하지 않는다.

그렇다면, 사람들은 스펙 작성을 기피할까? 사람들은 스펙 작성 단계를 건너뜀으로써 시간을 절약할 있다고 주장한다. 그들은 마치 스펙을 만드는 일을 미국항공우주국에서 우주선을 만드는 엔지니어들이나 혹은 대형 보험회사에서 근무하는 직원들에게나 어울릴만한 사치쯤으로 여기는 같다. 말도 되는 소리다. 무엇보다, 스펙을 작성하지 않는다는 것은 소프트웨어 프로젝트와 관련된 가장커다란위험을스스로자초하는 일이다. 그것은 옷가지만 달랑 등에 모하비 사막을 횡단하겠다고 나서는 것만큼이나 어리석은 행동이다. 사막을 날아오르기라도 하겠다는 건가. 스펙도 없이 코딩 작업에 뛰어드는 프로그래머나 소프트웨어 엔지니어들은 자신을 나는 총잡이쯤으로 생각하는 경향이 있다. 허리춤에서 권총을 뽑자마자 바로 목표물을 명중시키는 총잡이. 하지만, 그들은 그런 명사수가 아니다. 아주 비생산적인 프로그래머일 뿐이다. 형편없는 코딩으로 조악한 소프트웨어를 만들어내고, 불필요한 위험을 자초하여 프로젝트를 위태롭게 만들 것이다.

필자는 코딩 작업에 1주일 이상이 소요되거나 2 이상의 프로그래머가 참여하는 프로젝트의 경우, 스펙을 만들지 않으면 항상 작업 기간은 길어지고 코드 품질은 떨어진다고 믿는다. 이유는 다음과 같다.

스펙의 가장 중요한 기능은 프로그램을전체적으로설계하는이다. 코딩 작업을 혼자 진행하고 오로지 자기자신만을 위해 스펙을 작성하는 경우라 해도, 스펙을 작성하다 보면 프로그램이 어떻게 작동되어야 하는가를 구체적으로 기술하게 되기 때문에 실질적으로 프로그램을 설계하게 된다.

서로 다른 회사에서 일하는 명의 프로그래머를 상상해보자. Hasty Bananas Software 스피디 양은 절대 스펙을 작성하는 법이 없다. “스펙? 스펙 같은 필요 없어!” 한편, Well-Tempered Software Company 로저스 씨는 스펙이 완전히 확정되기 전까지는 절대 코딩을 시작하지 않는 사람이다. 필자에게는 이들말고도 여러 명의 상상 친구들이 있다.

스피디와 로저스에게는 가지 공통점이 있다. 각자 자기 회사 제품의 2.0 버전이 기존 버전과 소급호환이 가능하도록 프로그래밍해야 한다는 점이다.

스피디는 간단하게 1.0 버전 파일을 2.0 버전 파일로 변환시켜주는 컨버터를 코딩하는 것이 소급호환을 제공하는 가장 좋은 방법이라고 결론 내린다. 그녀는 곧장 코딩을 시작한다. 쉴새 없이 자판을 두드리고 마우스를 클릭한다. 하드드라이브가 윙윙 돌아가고, 바쁘게 작업이 진행된다. 2주일 , 그녀는 그럴듯한 컨버터를 만들어냈다. 하지만, 고객은 만족스럽지 않은 모양이다. 스피디가 개발한 코드대로라면 회사 내의 전직원들이 일괄적으로 2.0 버전으로 업그레이드를 해야 하기 때문이다. 스피디의 가장 고객인 Nanner Splits Unlimited 새로운 소프트웨어를 없다고 말한다. Nanner Splits사는 버전을 변환하지 않고서도 2.0 버전이 1.0 버전 파일 상에서 작동될 있는지를 알고 싶어했다. 스피디는 소급 컨버터를 코딩한 , 이를 저장 기능에 연결하기로 결정한다. 그런데, 방법에는 다소 문제가 있다. 사용자가 1.0 파일 상에서 2.0 버전의 기능을 사용하는 경우, 파일을 1.0 포맷으로 저장하려고 하기 전까지는 2.0 기능이 제대로 작동되는 것처럼 보이기 때문이다. 사용자가 저장을 시도한 후에야 시스템은 사용자가 30 동안 작업했던 기능이 1.0 파일 포맷에서는 작동되지 않는다는 메시지를 보여준다. 그래서, 컨버터를 다시 코딩하는 추가로 2주가 걸렸고, 그럼에도 불구하고 결과는 별로 신통치 않았다. 4주일의 시간이 경과된 것이다.

한편, Well-Tempered Software Company (간단하게 "WellTemperSoft"라고 하자) 로저스는 스펙이 확정되기 전까지는 코딩 작업을 거부하는 원칙주의자형 프로그래머다. 그는 20 동안 스피디와 같은 방식으로 소급호환 기능을 설계한 , 다음과 같은 요지의 스펙을 들고 나타났다.

  • 구버전으로 작성된 파일을 , 해당 파일이 신버전으로 전환되도록 한다.

이와 같은 내용의 스펙을 고객에게 보이자, 고객은 잠깐만! 모든 직원이 한꺼번에 버전을 업그레이드하게 되는 것은 원치 않소!” 라고 했고, 로저스는 잠시 생각한 , 스펙을 다음과 같이 수정했다.

  • 구버전으로 작성된 파일을 , 해당 파일은 메모리 내에서 신버전으로 전환된다. 파일을 저장할 , 사용자는 원래의 버전으로 다시 변환할 것인지 여부를 선택할 있다.

다시 20 정도의 시간이 경과되었다.

로저스의 상사는 스펙을 들여다보더니 뭔가 탐탁치 않다고 생각한다. 그는 다른 아키텍처를 제안한다.

  • 코드를 분해하여 V1 V2 가지 인터페이스를 사용하도록 한다. V1에는 1.0 버전의 모든 기능이 포함되고, V2 여기에 신버전의 기능을 추가한다. V1 저장 기능은 소급호환 문제를 처리할 있고, V2 저장 기능은 새로운 내용을 저장할 있다. 사용자가 V1 파일을 열어 놓은 상태에서 V2 기능을 사용하려고 시도하는 경우, 프로그램은 즉시 경고 메시지를 제공할 있다. 이때, 사용자는 해당 파일을 신버전으로 변환하거나 아니면 신규 기능을 포기해야 한다.

, 20 경과.

지금 로저스는 잔뜩 부어 있다. 상사가 제시한 스펙대로 코드를 다시 분해하려면 3주일이 소요되기 때문이다. 그가 애초에 계획했던 스펙대로라면 2주일에 끝낼 있는데! 하지만, 스펙이 고객의 문제를 모두 원만하게 해결하기 때문에 그는 마음을 가라앉히고 작업을 시작한다.

로저스의 소요시간은 3주일하고도 시간. 스피디는 4주일이 소요됐지만, 코딩 결과는 만족스럽지 못하다.

이야기의 교훈은 사례만 꾸며내면 어떤 주장이든 입증할 있다는 것이다. 이런! 아니, 그게 아니라, 이야기의 교훈은 인간의 언어로 제품을 설계할 때는 여러 가지 가능성에 대해 생각하고 수정하고 설계를 개선하는 밖에 걸리지 않는다는 것이다. 워드프로세서에 입력된 글에서 단락쯤 삭제한다고 해서 기분 나빠할 프로그래머는 없다. 하지만, 제품을 프로그래밍 언어로 설계하는 경우에는 이야기가 달라진다. 프로그래밍 언어로는 반복적인 설계 작업을 되풀이할 때마다 주일이 소요된다. 나쁜 것은, 꼬박 2주일 동안 코딩 작업에 매달렸던 프로그래머로서는 자신이 저작한 코드에 집착할 밖에 없다는 점이다. 코드가 아무리 잘못 만들어졌더라도. 스피디의 상사나 고객이 뭐라고 떠들어도 그녀는 자신의 역작인 컨버터 코드를 포기할 없다. 설사 그것이 최선의 아키텍처는 아니라 할지라도. 결과, 최종 제품은 원래의 잘못된 설계와 이상적인 설계를 적당히 절충한 타협안이 되고 마는 경향이 있다. 그것은 우리가 이미 모든 코딩 작업을 끝낸 상태에서 코드를 폐기할 없었다는 점을 감안하면, 우리가 있는 최선의 설계 것이다. “그냥 우리가 있는 최선의 설계만큼 훌륭하지는 않지만 말이다.

이상이 바로 스펙을 작성해야만 하는 번째 이유다. 스펙을 작성해야 하는 번째 이유는 의사소통시간을절약할있다 것이다. 스펙을 작성하면, 프로그램이 어떻게 작동되어야 하는가에 대해 한번만 이야기하면 된다. 모든 관련자들이 스펙만 읽어보면 되기 때문이다. 이를테면, QA 담당자는 스펙을 읽어보면 프로그램이 어떻게 작동되어야 하는가를 있고 무엇을 테스트해야 것인지도 알게 된다. 마케팅 담당자들은 스펙의 내용을 바탕으로, 아직 만들어지지도 않은 제품에 대해 모호하고 환상적인 제품 백서를 작성하여 웹사이트에 올릴 것이다. , 사업개발팀에서는 스펙의 내용을 잘못 읽고는 제품이 대머리 치료에 좋다는 , 사마귀 치료에 특효라는 , 불가사의한 헛소문을 퍼뜨리고 다닐 것이다. 하지만, 이를 통해 투자자를 끌어 모을 있을 테니, , 나름대로 좋은 일이다. 개발자들은 스펙을 읽고 어떻게 코딩 작업을 진행해야 것인지를 있다. , 고객들은 자신들이 기꺼이 값을 치를만한 제품이 만들어지고 있는가를 확인할 있다. 그런가 하면, 기술문서 담당자들은 스펙을 읽고 훌륭한 매뉴얼을 집필할 있다 (물론, 사용자들은 매뉴얼을 잃어버리거나 어느 구석에 내팽개쳐버리기 일쑤지만, 엄연히 이것은 별개의 문제다). , 관리자들은 스펙을 읽고 나서, 중역회의에 가서 프로젝트에 대해 뭔가 아는 척을 있다. 기타 등등.

스펙을 작성하지 않는 경우, 물론, 경우에도 위와 같은 다양한 의사소통이 이루어지기는 한다. ? 필요하니까. 하지만, 의사소통은 그때그때무계획적으로 이루어진다. QA 담당자는 프로그램을 되는대로 테스트해보다가, 뭔가 이상하다 싶으면 프로그래머에게 달려와서 원래는 이것이 어떻게 되었어야 하는 건지에 대해 멍청한 질문들을 반복적으로 늘어놓는다. 이것이 프로그래머의 생산성 저하 이어진다는 사실 외에도, 프로그래머들이 올바른 일러주기보다는 자신의 코딩 결과에 맞는 답을 내놓기가 쉽다는 심각한 문제가 있다. 결국, QA 담당자는 설계를 기준으로 프로그램을 테스트하는 것이 아니라, 프로그램을 기준으로 프로그램을 테스트하는 꼴이 되고 만다. 물론, 설계를 기준으로 테스트하는 쪽이 아주조금 바람직하겠지만.

스펙이 없을 벌어질 있는 가장 기가 막힌 (비극적인) 상황은 기술문서 담당자에게서 일어날 있다. 대부분의 소프트웨어 회사에서, 기술문서 담당자들은 프로그래머의 작업을 방해할만한 정치적 영향력을 가지지 못한 경우가 많다. 그러다 보니, 어떤 기술문서 담당자가 자꾸 쫓아와서 이것저것 물어보며 프로그래머를 귀찮게 하면, 프로그래머는 관리자에게 달려가 [ 비속어 삭제 ] 같은 기술문서 담당자 때문에 도대체 일을 수가 없다며 제발 그들을 멀찌감치 쫓아달라고 징징거린다. 그러면, 관리자는 작업 생산성을 높이기 위해, 기술문서 담당자에게 이상 프로그래머의 소중한 작업 시간을 빼앗지 말라고 명한다. 어떤 회사가 이런 회사에 속하는지는 금방 구별할 있다. 이런 회사에서 만든 프로그램의 매뉴얼이나 도움말에는 사용자도 화면을 보면 있는 수준 이상의 정보는 하나도 들어있지 않기 때문이다. 가령, 화면에 다음과 같은 메시지가 나타났다.

  • LRF-1914 지원을 활성화하시겠습니까?

같은 메시지를 사용자가 도움말 클릭하자, 아래와 같은 희비극적인 도움말이 나타난다.

  • LRF-1914 지원 (기본설정) 또는 LRF-1914 지원 취소 중에서 하나를 선택하실 있습니다. LRF-1914 지원을 원하시면 선택하시거나 “Y” 키를 누르십시오. LRF-1914 지원을 원치 않으시면 아니오 선택하시거나 “N” 키를 누르십시오.

어찌나 크게 도움이 되는지 도움말을 기술문서 담당자가 자신이 LRF-1914 지원이도대체어떤기능인지를모른다는사실을 감추기 위해 노력했다는 것만은 분명하다. 그는 프로그래머에게 LRF-1914 지원에 대해 물어볼 수가 없었던 것이다. ? (1) 물어보기가 창피해서, (2) 프로그래머는 인도의 하이데라바드에 있고 자신은 영국 런던에 있었기 때문에, (3) 상사가 프로그래머의 작업을 방해하지 말라고 명했기 때문에. 그것도 아니면, 일일이 언급할 수도 없을 만큼 많은 조직적 병리현상 때문일 수도 있겠지만, 가장 근본적인 문제는 스펙이존재하지않았다 것이다.

스펙을 작성해야 하는 번째 이유는 상세한 스펙이 없을 경우, 스케줄 관리가 불가능하다는 것이다. 물론, 박사학위가 걸린 프로젝트라서 14 정도는 투자하겠다 마음먹고 있다거나, 혹은 듀크 뉴켐 같은 나가는 게임의 신규 버전을 개발하고 있는 중이라서 코딩이끝나면출시한다 식의 입장을 견지하고 있다면, 스케줄 같은 없어도 무방하다. 하지만, 거의 대부분의 경우, 실제 소프트웨어 업체에서는 어느 정도 기간이 소요될 것인지를 미리 알아야 한다. 제품을 개발하는 데에는 들기 때문이다. 가격을 모르고는 아마 청바지 장도 사려 들지 않을 것이다. 하물며, 어떻게 책임 있는 기업가가 개발 기간이 얼마나 될지 , 비용이 얼마나 들지도 모르는 상태에서 제품 개발 여부를 결정할 있단 말인가? 스케줄 관리에 관한 자세한 내용은 손쉬운 소프트웨어 스케줄 관리법 참조한다.

프로그래머들이 흔히 저지르는 실수 중의 하나가 바로 프로그램 설계에 관해 논쟁만 벌이다가 그에 대한 결론은내리지않는이다. 윈도우 2000 개발팀의 수석 개발자였던 Brian Valentine 의사결정은 10 이내로, 다음부턴 마음대로 라는 그의 모토 유명하다.

프로그램 설계와 관련하여 논쟁이 벌어지는 경우, 주로 정치적인 이유 때문에 어느 누구도 선뜻 결정을 내리려 들지 않는 경우가 너무도 많다. 따라서 프로그래머들은 논쟁의 여지가 없는 부분에 대해서만 작업을 진행하게 되고, 시간이 흐를수록 어려운 의사결정 문제는 모두 마지막으로 미뤄지게 된다. 이야말로 실패할가능성이가장높은프로젝트 있다. 만일 어떤 신기술을 바탕으로 창업을 했는데 구조적인 이유로 매번 의사결정이 제대로 이루어지지 못한다면, 일찌감치 회사 문을 닫고 투자자들한테 돈을 돌려주는 것이 상책이다. 그런 회사는 어떤 제품도 시장에 내놓지 못할 것이기 때문이다.

스펙을 작성하는 것은 설계와 관련된 크고 작은 의사결정 문제들을 모두 확실하게 매듭지을 있는 훌륭한 방법이다. 스펙을 만들면 아주 사소한 문제까지 확실히 정해둘 있다. 가령, 회원제로 운영되는 웹사이트를 구축하는 개발팀이 사용자가 패스워드를 잊어버리는 경우 이를 이메일로 알려주기로 합의했다고 하자. 좋은 생각이다. 그런데, 코딩에 착수하자면, 이것만으로는 부족하다. 코딩 작업을 위해서는 이메일에 구체적인 문장까지 알아야만 한다. 하지만, 대부분의 회사에서는 사용자가 직접 읽게 문장을 프로그래머가 작성하는 것에 대해서는 별로 미더워 하지 않는다 (프로그래머들의 솜씨로 , 대개의 경우 그런 평가는 타당하다). 그래서, 마케팅 담당자나 홍보 담당자, 혹은 기타 어문학 전공자를 모셔와서 아무개 님의 패스워드는 다음과 같습니다. 앞으로는 패스워드를 잊어버리지 않도록 조심 하십쇼.” 라는 내용의 메시지를 글로 표현하게끔 한다. 완벽한 스펙을 작성하려고 하다 보면 (효과적인 스펙 작성 요령에 대해서는 뒤에서 자세히 살펴보기로 하자), 이런 세세한 것들까지 놓치지 않게 되고 이런 것들을 모두 확정하고 넘어가거나 아니면, 적어도, 나중에 빠뜨리지 않도록 커다랗게 표시를 해두게 된다.

, 지금까지 필자가 했던 이야기의 주제는 모두 똑같다. 스펙은 프로그램의 어머니이자 기초라는 것이다. 아마 대부분의 사람들은 사실을 알고 있을 것이며, 필자가 지금 떠들어대고 있는 내용도 전혀 새로운 이야기가 아니다. 그렇다면, 사람들은 스펙을 작성하지 않는가? 시간 절약을 위해서라는 것은 이유가 되지 않는다. 스펙을 만들지 않는다고 작업 시간이 단축되는 것은 절대 아니니까. 아마 대부분의 프로그래머들은 같은 사실을 인정할 것이다. (대부분의 개발팀의 경우, “스펙이라는 것이 프로그래머가 코딩을 모두 완료한 후에, 새로운 기능에 대한 설명을 삼백 번쯤 지겹도록 되풀이하고 나서야, 메모장 프로그램에 대강 입력한 페이지짜리 문서가 고작이다.)

필자는 많은 사람들이 글쓰기를 싫어하는 것이 이유라고 생각한다. 아무 것도 없는 화면을 마주하고 앉아 무언가 내려가야 한다는 것은 정말로 기가 질리는 일이다. 개인적으로, 필자는 대학에서 작문 강의를 들으면서 매주 서너 페이지 분량의 글을 제출하는 연습을 통해 글쓰기에 대한 두려움을 극복했다. 글쓰기는 근육과 같아서, 자꾸 쓰면 쓸수록 있게 된다. 스펙을 작성해야 하는데 그게 된다면, 일기를 쓰거나 개인적으로 웹로그 만들어보거나 작문 강좌를 듣거나 그것도 아니면, 4 내내 속을 털어놓던 대학 시절의 룸메이트에게 편지라도 보라. 생각을 글로 옮기는 것과 관련된 모든 것이 스펙 작성 실력을 키우는 도움이 것이다. 만일, 소속 팀원들의 스펙 작성 기피로 골치를 썩고 있는 소프트웨어 팀장이 있다면, 팀원들을 2주짜리 문예창작교실에라도 보내 보시라.

기능 스펙을 먼저 작성한 후에 프로그램을 코딩하는 회사에서 일해본 경험이 없는 독자라면, 아마 스펙이라는 어떻게 생긴 것인지도 적이 없을 것이다이런 독자들을 위해, 2부에서는 간단한 스펙의 보기를 제시하고 좋은 스펙의 요건에 대해서도 살펴볼 것이다2부에서 계속!



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

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