Talk about Software with hani

팀장의 고백  목차

• 게으른 PL이 프로젝트 일정을 지연시킨다.
• 개발명세서? 그 귀찮은 짓을 왜 하지? (오늘의 Post)
• 개발계획은 팀장의 것? 팀원의 것?
• 팀장! 당신은 진정한 Nego를 할 수 있는가?
• 형상 관리, 그까이거 그냥 폴더에 보관하면 되지
• UnitTest! 미완의 시도
• 인수테스트, 북치고 장구치고
• Trac을 통한 품질 관리
• 진정한 프로젝트의 가치는 어디에서 오는 것일까?

오늘은 “팀장의 고백” 시리즈의 첫번째 Post로 개발 명세서에 대해서 이야기하겠다. 시리즈 순서대로면 “게으른 PL이 프로젝트 일정을 지연시킨다.” 를 post해야지만, 좀 고민해야될 이야기가 많아서 다음 기회로 미루고 오늘은 개발 명세서에 대해서 생각해 보자.

개발 명세서란 무엇인가? 사전적인 의미로 살펴 보면 개발 명세서는 “개발과 관련된 하나하나의 내용을 자세히 적은 문서”라 할 수 있다. 그렇다. 쉽게 말하면 어떤 것을 만들 때 내가 무엇을 만들지를 주저리 주저리 적어 놓은 문서를 개발 명세서라 할 수 있다. 따라서 개발 명세서는 Software의 전유물이 아니다. 개발과 관련된 모든 분야에서는 개발 명세서를 작성한다. 그러나 말은 이렇게 하지만 실제로 본 개발 명세서는 전자 제품 만들 때 작성한 개발 명세와 Software를 만들 때 작성한 개발 명세서 정도다.

전자 제품, 예를 들어 냉장고를 만들 때 개발 명세서의 내용은 다음과 같다. “냉동실의 온도는 -15도에서 -3도 사이에서 변한다.”, “사용자가 맞혀 놓은 온도는 오차 범위(+-1도)에서 유지되어야 한다.” 등등 일반적으로 생각하는 냉장고의 기능과 제품 안전을 위한 검사 항목까지 일반인들이 생각하지 못하는 내용들로 채워져 있다. 이런 냉장고의 개발 명세서를 보면, 냉장고를 어떻게 만들어야 할지는 모르지만, 개발 명세서를 토대로 냉장고가 완성되었을 때 어떤 기능과 방식으로 작동할지를 짐작해 볼 수 있다.  냉장고, TV, 홈시어터 제품군을 떠나서 전자 제품 회사에서 제품을 만들 때 중요하게 생각하는 것은 개발 명세서를 만드는 작업이다. 눈으로 보면 알 수 있는 유형의 제품을 만들면서도 개발 명세서를 무척 자세하게 적는다.

개발 명세서를 상세하게 작성하는 이유는 여러가지가 있겠지만, 가장 큰 이유를 생각해보면 개발 명세서에 적는 기능 하나 하나가 돈이기 때문이다. 여기서 말하는 돈은 기능을 개발할 때 들어가는 비용이다. 앞에서 예를 들은 냉장고의 상세 기능인 “사용자가 맞혀 놓은 온도는 오차 범위(+-1도)에서 유지되어야 한다.”를 구현하기 위해서 중요한 변수는 오차 범위다. 이 오차 범위를 +-1도에서 +-5로 변경하면, 기능을 개발하기 위한 개발 비용을 무척 줄일 수 있다. 그렇기 때문에 개발 명세서에 나열된 기능을 놓고 개발자들은 냉장고를 만들 때 어느 정도의 기간과 비용이 소요될지를 예상해 볼 수 있다.

Software 분야에서의 개발 명세서

일반적인 제품의 개발 명세서 이야기는 여기에서 마치고 오늘의 주제인 Software 개발 명세서에 대해서 생각해 보자. 유형의 제품을 만들면서도 많은 시간과 노력을 들여서 개발 명세서를 작성하는데, 무형의 제품인 Software를 만드는 팀에서는 개발 명세서 작성에 큰 노력을 들이지 않을까? 여러가지 이유가 있겠지만, 가장 큰 이유는 Software 산업 내에 직업 분화가 다양하게 이루어지지 않았기 때문이다. Software 개발이라는 작업은 다양한 업무로 구성되어 있다. 간단하게 보더라도 고객 요구 분석, 시스템 설계, 개발, 테스트 업무, 배포 업무로 나뉘지만, 일반적인 Software 개발 회사에서는 이 모든 업무를 단 하나의 단어 “개발 업무”로 표현한다. 즉, Software개발자가 고객요구 분석부터 배포의 업무까지를 모두 도맡아서 하는 것이 현실이다.

그러나 Software를 개발해 본 사람은 고객 요구 분석에서 배포의 업무 하나하나가 전문성을 요구하는 작업이라는 것을 알것이다. 그러나 개발 회사 내에서도 이런 업무를 각각의 담당자를 지정해서 하기 위해서는 많은 비용이 발생하기 때문에, 개발자들이 모두 처리하기를 바라고, 실제 업무에 있어서도 그렇게 한다. 그런데 개발자 입장에서 가장 핵심적인 업무는 개발이다. 그렇기 때문에 아무리 고객 요구 분석이 중요하고, 테스트가 중요하더라도 결과를 내놓아야 하는 입장에서 본다면 개발 업무를 제외한 모든 업무는 사소한것으로 생각된다. 따라서 개발명세서 작성과 같은 업무는 물 건너 배부른 나라에서 한가할 때 하는 유흥정도로 느낀다.

스티브 맥코넬의 소프트웨어 개발(Professional, 인사이트)에서는 소프트웨어 산업도 전문직에 속한다고 주장한다.(지난 30년여의 세월을 뒤돌아 볼 때보다 소프트웨어 산업도 의사, 변호사, 각종 기술직처럼 전문직으로 성숙되고 있다고 주장한다.) 물론 이 이야기는 바다 건너 미국에 해당한 이야기지만, 우리나라도 서서히 개발자 중심의 개발문화에서 프로세스 중심의 개발 문화로 바뀌어 가야 한다. 그러기 위해서는 소프트웨어 개발 전단계에서 업무 분화가 이루어지고, 그렇게 된다면 개발 명세서와 같은 작성 업무가 개발자에서 프로그램 관리자와 같은 별도의 직군에서 의해서 수행될 것이다.

이상으로 간단하게나마 업계에서 당연히 작성해야 하는 개발명세서를 당연히 작성 안하는 이유를 살펴 보았다. 지금부터는 마무리 단계인 이번 프로젝트에서 어떤 식으로 개발명세서를 작성했으며 얻은 이점과 개선 사항은 무엇인지에 대해서 이야기해 보겠다. 개발명세서를 한번도 작성해 보지 않은 사람에게 개발명세서를 작성하라고 한다면, 좀 난감해 할 것이다. 개발명세서를 작성해 보고 싶은 사람에게 도움이 될만한 자료 하나를 소개하겠다. 조엘 스폴스키의 조엘 온 소프트웨어(Joel On Software, 에이콘)에 제 5장 손쉬운 기능 명세 작성법 : 1강 명세서 작업이 귀찮습니까? 다.(동일한 자료를 조엘의 블로그의 Painless Functional Specifications - Part 1 : Why Border?에서도 볼 수 있다.) 간단하지만 실무에서 적용하기에 충분한 참고 자료다.

의사 소통을 위한 개발 명세서 작성

지금 마무리 중인 프로젝트의 아주 개략적인 Scope을 설명하면(프로젝트의 내용에 대해서 상세히 설명하고 싶으나, 기업 비밀에 해당하는 내용이기 때문에 이야기할 수 없어 아쉽다.) 총 3개의 모듈을 개발해야 했으며, 이 중 한개의 모듈은 개발을 Outsourcing 하였다. Outsourcing한 모듈은 건축 설계에 대표적으로 사용되는 툴인 AutoCAD와 같은 2D GUI툴을 제공하며, 공학적인 Simulation을 수행한 후 Excel을 이용해서 다양한 형태의 Report를 출력해야 했다. 고객의 요구 사항은 매우 복잡했고, 프로젝트 초반에 고객 요구 사항을 명확히 하지 못한다면 일정관리에 치명적인 영향을 줄 수 있었다.

기존까지 수행한 프로젝트는 대부분이 고객과 같이 작업할 수 있었기 때문에, 상세한 개발명세서 작성을 간단한 사용자 시나리오나 GUI 설계로 대체하였다(사실 고객과 원할한 의사소통이 이루어진다 하더라다도 개발명세서는 꼭 작성해야 한다. 개발명세서의 필요성은 뒷부분에서 자세히 이야기하겠다.) 그러나 이번 프로젝트에서는 고객과 개발팀 그리고 Outsourcing 업체가 지리적으로 떨어져 있었기 때문에, 의사소통에 큰 문제가 있었다. 프로젝트의 참여 당사자들이 모두 같은 자리에 모여서 의견을 교환할 수 없는 상황이었기 때문에, 고객의 요구가 개발을 담당하는 Outsourcing업체에 명확히 전달되기 어려웠다.

이런 이유로 프로젝트 일정을 전체 관리하는 입장에서 고객의 요구사항을 명확히 해서 Outsourcing업체에 전달하기 위해서는 필연적으로 매우 상세한 개발명세서를 작성해야 했다. 우선 간단한 사용자 시나리오를 작성해서 S/W의 전체적인 GUI 윤곽을 잡은 후 이를 토대로 개발명세서 작성에 돌입하였다. 사용자 시나리오에서 최종 개발명세서 작성에 약 한달의 기간이 소요되었으며, 이 기간동안 5번정도의 Revision이 발생하였다. 최종 개발명세서는 A4용지 기준으로 55Page 분량 정도였다.(백마디 말보다 직접 작성한 개발 명세서를 몇 페이지 공유하는게 도움이 되겠지만 그러지 못하는 현실이 아쉽다.)

한 달간의 짧지 않은 시간동안 작성한 개발명세서에는 어떤 것들이 담겨져 있을까? 아래는 내가 작성한 개발 명세서를 읽고 담겨 있는 내용을 정리한 것이다.

• 전체적인 GUI
• 사용자 대화상자
• 전체적인 사용자 시나리오
• 상세 기능별 사용 방법
• 각 기능별 Input/Output
• 에러 발생 시 처리 방법

위의 개발 명세서는 사용자가 Software를 사용하면서 마주칠 모든 상황에 대해서 기술해 놓은 것이라 할 수 있다. Software를 사용할 잠재 고객들이 개발 명세서를 읽어봄으로써 Software를 어떻게 사용할 수 있는지 그리고 어떤 방식으로 작동하는지를 짐작할 수 있도록 작성해야 한다. 따라서 개발명세서는 개발자의 입장에서 작성하는 것이 아니라, 사용자의 입장에서 작성해야 한다. 명세서는 Software를 만드는데 있어서 출발점이다. 그렇기 때문에 명세서가 명확하지 않으면 Software또한 제대로 만들 수 없다. 따라서 명세서에 기술되는 내용은 초등학생들이 읽어도 무슨 내용인지 알 수 있는 수준으로 작성해야 한다.

“… Function-12A를 사용하기 위해서는 Functioin-11B가 먼저 활성되어야 한다. 따라서 Function-11B를 활성화하기 위해서는 Function-11B에 해당하는 메뉴를 누른 후 대화상자에서 “Yes” 혹은 “No”를 선택해야 한다. …” 간혹 개발 명세서는 기술적인 냄새가 물신 풍겨야 한다고 생각해서, 컴퓨터도 못 알아 들을 내용으로 명세서를 꾸미기도 한다. 그러나 이런식의 명세서는 차라지 작성하지 않는 편이 낫다. 명세서 작성 시 가장 강조하고 싶은 것은 간략하면서도 누구나 쉽게 이해할 수 있도록 작성해야 한다.

톰 디마르코의 소설 데드라인(A The Deadline, 인사이트) 위와 같은 명세서가 종종 작성되는 이유는 작성자가 멍청해서가 아니라, 해당 프로젝트의 이해 관계가 충돌하기 때문이라고 한다. 개발 명세서라고 하는 것은 Software의 모든 행위를 기술한 것이다. 그렇기 때문에 이해 당사자들이 정치적으로 충돌하는 프로젝트의 요구 사항이 합의되지 않고, 따라서 해당 개발 명세서도 명확하게 작성할 수 없다. 이런 프로젝트의 개발 명세서는 모호한 표현들로 가득차지고, 이 개발명세서를 읽는 사람들은 해당 명세서를 이해할 수 없게된다. 따라서 자신이 속해 있는 프로젝트의 개발명세서를 읽고도 무엇을 개발해야할지 모르다면, 프로젝트가 잘못되고 있음을 직감해야 한다.

개발명세서를 작성함으로써 얻을 수 있는 이점

1. 고객의 요구를 명확하게 정할 수 있다 : 사람 사는 세상에 상대방의 말을 100% 신뢰할 수 있다면 천국이 따로 없을 것이다. 그러나 현실은 상대방의 말만 믿고 일을 진행할 수 없다. 따라서 말에 신뢰를 부여하기 위해서 할 수 없이 글에 의존할 수 밖에 없다. 말보다는 글로 써 놓는 것이 구속력이 강함을 부인할 사람은 없을 것이다. 솔직히 개발명세서를 작성하기는 하지만, 내가 작성한 개발 명세서를 모든 사람들이 다 읽어보리라는 기대를 하지 않는다. 그러나 이해 관계자가 많고, 의사 소통에 문제가 발생할 가능성이 많다면 개발 명세서는 프로젝트를 일정 방향으로 이끌어 갈 수 있는 방향타 역할을 한다.

물론 고객 만족을 위해서 고객의 요구를 100% 반영하는 것이 가장 이상적인 프로젝트일 수 있다. 그러나, 성공적인 프로젝트는 냉정한 현실과 이상 사이의 중간 지점에서 적절한 타협을 이루어내야 한다. 그렇기 때문에 변화하는 고객의 요구를 어느정도 통제할 필요가 있다.(고객의 요구를 100% 반영하는 것이 필요한지에 대해서는 “팀장! 당신은 진정한 Nego를 할 수 있는가?”에서 다루겠다.) 표현의 차이기는 하나 고객의 요구를 명확히 한다는 것은 고객의 요구를 통제한다는 다른 표현이다. 시간이 흐른 후 고객이 다른 이야기를 할 때 “개발 명세서 몇 페이지에 이런 식으로 개발하기로 하였습니다” 라고 간단히 언급해 주는 것으로 변화 무쌍한 고객을 진정시키는데 도움이 되기도 한다.(현실에서는 이런 합의도 간단히 무시해 버리는 고객도 많다.)

2. 기간 산정 시 기본 자료로 사용된다. : “잘 만들어 주세요!”라는 말처럼 무서운 말이 없다. 프로젝트 관리자로써 대충 이런 식으로 만들어 달라고 Outsourcing 업체에 던져 주고 “잘 만들어 주세요!”라는 말 한마디로 일을 끝내는 이들도 있지만… 결국 이런식의 Outsourcing 업체 관리는 제 발에 족쇄를 채우는 형국이다. 잘 만들고 싶지 않은 Outsourcing 업체가 어디에 있을까? 모든 Outsourcing 업체들이 좋은 결과를 내고, 차기 프로젝트로 연결되서 일을 하고 싶어한다. 그렇기 때문에 Outsourcing 업체들이 좋은 결과를 낼 수 있도록 조금만 도와준다면 프로젝트를 성공적으로 마무리할 수 있다. 도움의 시작은 정확한 개발 일정을 산정할 수 있게 하는 것이다. 그러기 위해서 개발 명세서를 명확히 작성해서 넘겨 준다면 Outsourcing업체가 개발 일정을 산출하는데 많은 도움을 줄 수 있다. 따라서 일정을 관리하는 PL입장에서도 초기에 개발 명세서를 완벽히 작성해서 넘겨주는 수고를 조그만 들인다면, 프로젝트 후반부에서는 그렇게 신경 쓸 일이 많지 않다.(물론 현실적으로 개발업체 내부에서 발생하는 문제가 일정 지연에 큰 영향을 미치기는 하나, 이 부분은 부처님도 도와줄 수 없다. 이런 문제는 Risk Management가 해결 방안일 수 있다.)

개발 명세서 작성 시 개선 사항

이번 프로젝트로 제대로 된 개발 명세서를 작성할 수 있어, 개인적으로 한단계 실력을 높이는데 많은 도움이 되었다. 그러나 개발명세서를 작성하면서 가장 하기 싫은 작업이 있었다. 바로 완성된 명세서를 개정 작업하는 것이다. 개발명세서를 완성한 후 핵심 고객에게 전달하면 반드시 변경사항이 발생하였다. 이는 무척이나 자연스러운 일이며 바람직한 현상이다. 그러나 개발명세서를 수정해야 하는 입장에서는 반복적으로 일어나는 개정작업이 그다지 달갑지 않은 것도 사실이다. 원칙적으로 요구 사항이 변경될 때마다 명세서가 변경되어야 하나, 현실적으로 개발에 들어가게 된 후부터 다른 업무 때문에 개발명세서 변경 작업은 중단되었다. 개발명세서 개정 작업이 중단된 이유는 초기 Software의 Spec 명확화와 기간 산정의 역할을 다했기 때문이다. 그러나 애써 작성한 개발 명세서가 단순히 Spec을 잡는데에만 사용되기에는 아깝다는 생각이 들었다.

개발명세서의 활용방안에 대해서 고민하다가 스티브 맥코넬의 소프트웨어 프로젝트 생존전략(Software Project Survival Guide, 인사이트)에서 얻은 팁을 소개한다. 개발명세서가 단순한 명세서 수준에서 멈추는 것이 아니라, 사용자 도움말의 형태로 작성하는 것이다. 즉, 소프트웨어 개발 초기부터 도움말(개발명세서)을 만들어 나간다면, 개발 명세서 역할도 하면서 이 문서가 최종적으로 도움말이 되기 때문에, 지속적인 개정 작업을 할 수 있다는 것이다. 이 방법은 개발명세서의 작성이 과도한 업무 때문에 망설여지는 회사에서 적극적으로 고려해볼 필요가 있다.

이것으로 Post를 끝내고, 다음 Post에서는 개발 일정 수립 방법에 대해서 이야기하겠다.

This entry was posted on Saturday, April 15th, 2006 at 11:07 pm and is filed under software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.