My Words, Your Memory

#1 설계서 1 : (돈주시는 분들이 내놓으라고 윽박지를 때 제출하는) 이면지 묶음 및 이면지 생성용 파일. 통상 개발이 끝나가는 시점이나 끝난 이후에 작성한다. 아무리 생각해도 그 누구도 읽지 않을 것 같지만, 이렇게 만들어진 이면지 뒤에 눈물로 시를 쓰는 사람들은 분명 어디엔가 존재한다.

#2 설계와 구현 : 달걀과 닭. 그러나 사람들은 이를 "닭의 해부도와 생닭" 의 차이로 이해한다. 닭의 질병을 치료하거나, 슈퍼 닭을 만들기 위한 유전 공학적 기법을 보통 리팩토링이라고 부른다.

#3 요구 사항 : 모든 '아트'의 시작. 업계의 거장이신 낭만 김국현 선생께서는 "네가 너를 모르는데, 난들 너를 알겠느냐? 한치 앞도 모두 몰라 다 안다면 재미 없지." 라는 명언을 남기셨다. 전설에 의하면, 좋은 설계는 고객을 만족시키고, 좋은 요구 사항 분석은 고객에게 감동을 준다, 곤 하는데 그냥 전설에 지나지 않는 것 같다. 너무나 자주 변경 된다는 점에서 업계의 선수들을 분노하게 만들지만, 미래로부터 과거로의 시간 여행이 불가능하다는 것에 대한 작은 증거로서는 감사히 여길만 하다.

#4 기능 명세 : 요구 사항 명세가 구천을 떠돌고, 설계서가 난산과 유산을 거듭하는 동안 홀로 외로이 지구를 지키느라 고생하는 우리들의 좋은 친구. 기능 명세 만들랬더니 엑셀 표 들고오면 면상에 '조엘 온 소프트웨어'를 던져버리고 싶어질 것이다.

#5 설계서 2 : 설계를 하기 위해 쓰는 문서. 당신의 설계를 남에게 설명하기 위한 문서를 뭐라고 부르는지는 모르겠다. 무엇을 해야 하는지, 어떻게 해야 하는지 감 잡았으면 누구나 쓸 수 있어야 정상이지만, 결코 구현의 모든 것을 담을 수는 없다. UML 따위 몰라도 별로 상관은 없는데, 일단 그림을 그리려면 최소한 상속 관계와 함수 호출은 구분해서 그려주는 센스가 필요하다. 일반적으로, '명확한 설계'는 '읽거나 이해하기 쉬운 설계' 와 동의어가 아니며, '도면이 많은 설계' 와는 더욱 거리가 멀다.

#6 설계 회의 : 아직 설계가 끝나지 않았지만, 언젠가는 끝내야 한다는 사실을 참여 인원들에게 인식시키기 위한 목적으로 행해지는 사회적 관습. 의사 결정권자(들)에게 일순간 지나치게 많은 정보를 주입하여 '혼란' 상태 이상을 유발하는 백마법과 함께 시전되는 경우, 실제 설계자의 취향을 관철해내는 방법으로서 상당히 유용하다. 단, 의도와 달리 설계 자체가 완전히 엎어져버리는 불상사도 일어날 수 있다.



@ 물론 '타타타'는 PCTOOLS 김국현님이 아닌 가수 김국환이 불렀지만, 우리는 자주 두 사람의 이름을 혼동하곤 한다.