개발의 첫단계 :: 스펙잡기

모든 개발프로젝트를 시작함에 있어 명세서(specification)의 작성은 아주 중요하다. 완벽한(과연?) 명세서를 만든다면 개발프로젝트는 50%이상완료되었다고보아도 좋다.
명세서가 뭐길래 그토록 중요한 것일까?
명세서를 쓴다는 것(혹은, 스펙을 잡는다는것)은 프로젝트의 최종 목표를 정하는 일이고, 목표물이 되기까지 거쳐야 하는 필수 단계들을 나열하는 것이고, 마주칠지도 모르는(아마 거의 마주치게 될) 어려움을 미리 예측하여 어려움의 발생을 최소화하는 유일한 방법이다. 적어도 내가 아는 한은 그렇다.
또, 비교적 지킬수 있는 스케줄링을 하는데 무척이나 기여한다.

우리나라의 대부분의 IT기업들은 보통 스펙을 잡는 과정을 개발과정으로 간주하지 않는다. 이는 기획자의 몫이며 개발자는 기획자가 만든 기획안(이걸 스펙과 혼동한다)대로 구현해 주면 되는 것이라고 생각한다.
그나마도 이렇게 생각해주면 다행이다.

기획자도 없이, 누군가(사장, 혹은 부서장?)에 의해 무언가를 만들겠다고 내던져진 말이 곳 스펙이 되어 버린다. 개발자는 의례 Visual Studio라던지 Eclipse라던지, 터미널에 VI를 열어놓고 높으신 분께서 말한 제품을 어떻게 만들수 있을지 생각한다.

뭔가 이상하지 않은가?
"이러한 소프트웨어가 필요하다"
라고, 단지 필요한 소프트웨어의 대충의 명칭을 말하면 개발자는 알아서 그것은 이런 기능을 가질 것이다 라고 판단하고 자기 머릿속에만 있는, 곳 자기도 기억하지 못할 스펙을 상상해 낸다. 신기하게도 제품은 완성되고, 처음에 프로젝트를 시작시켰던 분께서는...
"훌륭해.. 그런데, 이걸 왜 만든거지?"
라고 말한다. OTL
만들라면서요..
"내가 만들라고 했던건 이런게 아니라.. 어쩌구 저쩌구...주절주절..."
아니 그걸 이제와서 말씀하시면 어떡해요..

누가 잘못한걸까..
개발자도 기획자도 모두 잘못했다.

모든 소프트웨어 프로젝트는 항상 고객에게 기능을 제공하기 위한것이라는 공통된 목적이 있다.
고객은, 개발자가 자기 혼자 쓰려고 만들때는 자기 자신이 될 것이고, 사내 지원조직이나 시스템조직에게는 운영조직이나 다른 시스템조직 또는 서비스를 받는 유저가 고객이 될 것이고(전문용어로 내부고객이라고도 한다), 제조업체의 개발조직에게는 제품을 구입해 주는 소비자(이건 당연히 외부고객이다)가 고객일 것이다. 어떤 경우건 고객은 언제나 위대하시고 언제나 옳은 말씀만 하신다는걸 기억해야 한다.
고객이 "난 이렇걸 원해요"라고 말하는데, "그게 아니죠.. 당신은 이런걸 원하는 것입니다"라고 말할수 있는가? 과연 그게 맞다고 생각하는가? 무슨 근거로?

그래서 스펙화과정, 명세서 작성과정이 꼭 필요하다는 것이다.

XP(eXtreme Programming)이라는 방법론에서 말하길 고객을 개발과정에 참여시키라고 한다.
명세서를 작성하는 과정이 고객이 개발과정에 참여할 아주 좋은 단계이다.
우선,
"이 소프트웨어가 (또는 하드웨어라도 마찬가지..) 이러한 기능을 하며, 이 기능들을 위해서 사용자에게 이러한 인터페이스를 제공하고, 사용자에게 보이지 않는 곳에서 데이터들을 이렇게 조직하기 때문에 이러이러하게 응용한 기능들을 얼마든지 만들수 있다."
이런 "내용"이 명세서에 모두 들어가야 한다.
"물론 이 모든것을 구현하는데는 몇달의 시간이 소요되고, 그에 따른 비용이 얼마이므로, 이 제품의 가격은 얼마가 된다"
이런내용도 가급적 포함시키는게 좋다.

개발자들은 이런 과정을 싫어하는 경향이 있다.
늘 해왔듯이 에디터를 띄우고 코드를 적어 내려가고, 컴파일하고 실행시켜 보아서 고객이 말한 행동을 하는 소프트웨어가 되었는지 확인하는걸 개발의 왕도라고 생각한다. 하지만, 개발자는 실리콘으로 만들어진 것이 아니라 단백질로 만들어졌기 때문에 , 인간 사고 패턴의 한계를 벗어날 수는 없고, 망각이라는 한계로부터 자유로울 수 없다.
만일 당신의 두뇌는 실리콘으로 만들어져 있고 1.5V또는 3.3V의 전원을 공급해서 두뇌를 운용한다면 이따위 헛소리는 집어치라고 말해도 할말이 없다.(5V의 전원을 쓴다면 그따위 구닥다리 두뇌는 집어치우고 차라리 단백질을 택하라고 자신있게 말할 수 있다)
많은 개발자들이 고객은 기술에 대해 아는것이 아무것도 없는데 말도 통하지 않는 그런 사람들하고 어떻게 같이 스펙 작업을 하는가 라고 말할지도 모르겠다. 하지만 고객에게
"이 정보는 Windows 2003 server에 설치된 MS SQL에 저장되어 있으며, 3개의 테이블이 Foreign key로 엮여 있어 Data Integrity가 높게 유지될 수 있습니다. 그러나 Integrity에 대한 exception을 발생할 때의 handling을 위해서 wrapper를 만들 것입니다. 이렇게 하면 모든 컴포넌트의 Data I/O를 통제 할수 있습니다. Data의 I/O가 일어나면 blahblah Algorithm에서 증명된 방법으로 데이터를 가공합니다.
연산의 최소화를 위해 reference를 3개 사용하여 최적화를 수행할 수 있을 것입니다.
이렇게 가공된 데이터는 Bitmap object에 매핑되어 스크린 또는 프린터로 전송됩니다. 프린터로 전송될 때는 Postscript로 변환하기 위한 엔진이 사용됩니다. 어쩌구.."
이런 기술적인 얘기를 하라는게 아니다. 나도 이해 못하겠는 소리를 고객에게 하면 뭣하는가.
이런 현학적인(이 단어도 현학적이다;;) 명세서를 고개에게 들이밀면, 고객은 현란한 기술용어에 감탄하던지 겁을 먹고 개발자에게 "네.. 그렇게 만들어 주면 너무 훌륭하겠네요"라고 말해버린다.
솔직해져라. 이걸 노려왔지 않은가..

스펙명세서에는 크게 두가지 버전이 만들어지는게 정석인데, 하나는 Fuctional Specification(기능명세), 또 하나는 Technical Specification(기술명세)가 된다. 고객에게는 절대 기술명세를 보여줘서는 안되며 (기밀사항이 아니더라도 보여줘선 안된다.) 더욱이 함께 작성해 보자고 달려들어서도 안된다.명세는 쉽게 작성되어야 하는데, 기술명세는 개발자에게 아무리 쉽고 하찮은 내용일지라도 고객에게는 마법주문서와 같아보이게 마련이다.

절대로 명세서는 쉽게 작성해야 한다.
쉽게, 그리고 눈에 확 들어오도록, 가급적 재미있게(구어체를 섞어주는것도 좋다) 작성해야 한다. 명세서를 쉽고 재미있게 작성하지 않으면, 작성한 자신도 다시는 들여다 보지 않을 것이고, 본인이 지금 명세와 얼마나 다른 물건을 만들고 있는지 눈치채지 못하게 된다.
조엘 스폴스키는 "당신이 쉽고 재미있는 명세서를 작성하여 보여줬다고 당신을 얕잡아 보는 회사에서 일한다면, 다른 회사를 찾아보는게 좋을 것이다"라고 충고했다.

조엘, 당신은 대한민국을 모르는군요.. 대한민국은 스펙을 작성하는 사람을 시간을 축내는 사람, 머리가 나빠서 저렇게 정리하느라 시간을 다 써버리는 사람으로 취급한답니다. 젠장할 쉽고 재밌는 명세서를 보여줄 기회가 없기 때문에 우리 회사가 그런 명세서를 얕잡아 보는지 알수가 없다구요..

쉽고 재밌는 명세서(기능명세일 경우엔 특히나 더욱)를 작성할때는 적절히 예를 들어가면서 소프트웨어의 행동을 모두 보여주는 것이 좋다.
어떤 입력에 대해 어떻게 행동할 것인지를 고객과 함께 협의해 나가야 한다.
다이얼로그 박스에 붙어있는 버튼을 클릭하면 어떤 일이 일어날지를 협의해야 한다. 스펙이 구체화 되어 갈수록 다이얼로그박스에 로고를 넣을 것인지, 버튼을 가로로 배치할 것인지 세로로 배치할 것인지, 버튼의 크기는 얼마나 되어야 할지도 여러가지 안을 고객에게 보여주며 고르던지 더 좋은 제안을 하도록 유도해야 한다.

DVD대여 프로그램을 발주하는 DVD대여점 사장님은, 자기 점포의 고객 명단(주의! 우리 고객이 아니다, 우리 고객의 고객이다)을 가장 소중하게생각할 것이다. 사장님이 생각하는 가장 중요한 고객의 정보를 눈에 띄게 배치해서 맘에 드는지 물어봐야 한다. DVD대여점 고객의 취향을 대여 패턴으로 분석이 가능하도록 모든 DVD타이틀의 정보를 어떻게 입력하고 관리할지도 알려 주어야 한다. 사용법이 어렵다고 하면 쉽게 고쳐줘야 한다. 그런 정보를 관리하려 하는게 아니라고 하면 로직을 수정해 줘야 한다.

우리회사에 참 상대하기 힘든 DVD가게 사장님-_-이 있다.
"대여프로그램 만들어줄꺼죠?"
이 한마디 던져놓고 몇달동안 자기 일 하느라 관심도 없이 지내더니 요즘 부쩍 이래가지고 DVD대여를 어떻게 하냐고 땡깡이다. 그러면서 언제까지 되겠냐고 다짜고짜 들이댄다. 마치 내가 프로그램을 잘못 만들고 있으면서 태평하게 놀았기 때문에 자기가 지금 장사를 할수 없다는 식이다. 어쩌라구..
내배를 째던지..
우리 사장님한테 말해서 날 짜르던지..

에효.. 길어졌다.
내일 또 써야지..

---

덧. 써놓고 보니 내 사상은 확실히 "실용주의 프로그래머"와 "XP", "조엘의 블로그"의 영향을 심하게 받은거 같다;;;;

덧. 혹시 있을지도 모르는, 이 다음 과정이 궁금한 방문객을 위한 링크^^;;;

출처: http://luminance.kr/107