우리 사무실에는 Drop 커피 기계가 있습니다.

* 비슷하게 생긴놈
사용자 삽입 이미지


우리는 매일 매일 이 커피머신으로 부터 커피를 받아 먹는다.
그런데 문제가 있다. 어떤 날은 싱겁고, 어떤 날은 매우 진하며, 어떤 날은 달고, 어떤 날은 쓰다.


이 문제를 해결하려면 아마도 우리에게는 계량용 컵과 만들때 얼마만큼의 물에 얼마만큼의 커피와 설탕을 넣었는지에 대한 기록이 필요할 것이다. 아울러 어떤 레시피가 우리의 입맛을 만족시켰 줬는지 우리 스스로 평가하고 기록하는 기록장이 필요할 것이다.

최근에 소스 그자체가 설계서라는 이야기를 들었다.
이 이야기는 설계를 하고나서 얼만큼의 커피를 몇 g넣고, 몇 ml의 물을 넣을 거이며, 몇 개의 각설탕을 컵에 담아 둘지를 미리 기록하지 않고 일단, 넣고보자라는 이야기와 상통한다.

이 경우 테스트할 사람과 개발자할 사람만 있다면 아무런 문제가 없다.
문제는 그 코드를 전달 받거나, 그 코드를 나중에 찾아볼때가 문제가 된다.


그 코드를 왜 만들었는지, 그 코드를 무슨 생각으로 어떤 색을 입혔는지 모른다면 그 코드는 인수받은 사람에게 가치가 없는 코드에 불과하다.

예를 들어, 우리가 아름다운 그림을 감상할 때 그 그림에 담긴 이야기를 듣지 않는다면 아무리 아름다운 그림일지라도 우리가 주변 사람을 찍는 사진 한장만큼의 가치도 가질 수 없다.

설계과정은 우리가 커피를 얼마나 넣을지, 물을 얼마나 넣을지, 설탕을 얼마나 넣을지에 대해 협상하고 설정하는 과정이라면, 설계서는 이 과정을 기록하는 기록물이다.

즉, 커피를 만든 배경을 아는 순간 커피를 마시는 우리는 그 기록물과 과정을 보고 들으며 아무리 맛이 없는 커피라도 의미를 부여할 수 있게된다.

이걸 우리는 스토리 텔링이라 한다.

누구에게 동의받거나 합의된 생각은 아니지만, 설계가 중요하다면 설계서 역시 중요하다.
다시말해, 이 제품을 만들때 우리가 무슨 생각을 했고 우리가 어떤 목적으로 이걸 만들었다는 이야기를 담아내는 설계서는 매우 중요하다.
반대로 사람 이야기가 빠져있는 설계서라면 집어 던져라. 그냥 코드에 주석이나 잘 달면 될 일이다.
더 나아가 설계서가 딸랑 버전 1개면 된다고 생각해도 설계나 설계서 따위는 집어 던져라.
소스가 변할때 마다 그 소스의 배경 이야기와 최소한 그 소스의 지도를 만든다고 생각해야 한다.

물론, Doxygen이라는 좋은 도구도 있다.
Doxygen은 설계서가 아닐까?
내 입장에서는 Doxygen은 매우 훌륭한 설계서이다. 실시간 코드 지도를 만들어 줄 뿐아니라, 주석에 내 감정의 정보만 넣어도 그 자체로 이야기상자가 된다.

그렇지만, Doxygen은 요구사항을 추적할 수 있는 도구는 아니다.
설계의 궁극적인 목표는 요구사항과 코드의 Mapping에 있다.
다시 말해 설계서에는 요구사항도 담아 낼 수 있어야 한다는 이야기이고, 설계서 자체로 개발목적 뿐만 아니라, 테스트에도 사용될 수 있어야 한다. 그런 의미에서 Doxygen은 조금 의문이다.  
(물론 Doxygen을 폄하하는게 아니다. 코드와 문서의 Mapping을 실시간으로 할 수 있는 도구로는 이 제품이 최고이기 때문이다.)

개발자로써 이 논쟁에 대한 나의 입장은 "과도한 설계란 없다. 하지만 과도한 설계서에는 반대한다."이다.
그리고, 그 설계서를 갱신하고 사람들의 이야기를 담아낸다면 당신이 만드는 제품도 인간의 냄새를 풍길 것이다.

2011/12/27 10:03 2011/12/27 10:03

트랙백 주소 :: 이 글에는 트랙백을 보낼 수 없습니다