요즘도 계속 SE를 하고 있다. 나 혼자 하는 거면 모를까, 그래도 팀원들과 같이 하는 것이다보니 다수의 의견을 따라 웹을 버리기로 했다. 사용자 편의를 위해서 뭔가 자세하게 하려고 하면 할수록 sequence diagram, class diagram이 오히려 복잡해져서, '문서와 코드의 consistency'를 중요시하는 분위기 상 오히려 감점 요인만 늘어난다는 생각 때문이었다.

지금 우리가 이 수업에서 하고 있는 프로젝트는 CADIT(Conceptualization - Analysis - Design - Implementation - Test)의 과정 중 T를 제외한 나머지를 다룬다. 상당히 전통적인 개발 방법론이라고 볼 수 있는데, 문제는 이 방식이 처음에 모든 것을 완벽하게 설계해놓고 거기에 맞춰 코드를 만들어 결과물을 짠~ 내놓는 것이라는 점이다.

이는 몇 년 전부터 뜨기 시작한 XP(Extreme Programming)에 정면으로 대치된다. XP에서는 아주 작은 스케일(초, 분)부터 아주 큰 스케일(달, 년)까지의 시간 단위마다 지속적으로 가치 점검과 방향 수정을 하며, 모든 것을 다 설계한 다음 한 번에 구현하는 것이 아니라 중요한 기능들부터 먼저 구현하면서 주변 기능들을 덧붙여 나가는 방식을 사용한다. 어떻게 보면 자전거 타기에 비유할 수 있을 것이다. 자전거를 타면 우리는 원하는 경로를 따라가기 위해 무의식 중에 연속적으로 미세하게 경로 변경을 하는데, CADIT은 모든 준비를 마친 다음 목표 지점에 도달하기 위해 포탄 발사하듯 내던지는 격이다. 그 둘의 차이점(장단점)은 굳이 말하지 않아도 알 수 있으리라 생각한다.

사실, 수업 프로젝트로 하는 것이기 때문에 우리가 처음 원했던 수준만큼 프로젝트를 진행하는 것은 여러모로 무리가 있을 수도 있다. 다른 수업과의 로드 분산도 고려해야 하고, 조교와의 의견 조율도 필요하기 때문이다. 또 학부 수업에서는 아무래도 '고전'에 해당하는 것을 다루다보니 더 그런 것이라는 얘기도 들린다. 결국 우리는 설계 문서 작성법을 익히는 데 의의를 두고 코드는 C#을 이용해서 간단하게 짜기로 했다. (물론 완전히 확정됐다고 보기는 조금 그렇다) 실제 서비스하는 것을 목적으로 하지 않고 prototyping을 목적으로 한달까(라고 자기합리화하는 듯한 느낌이 들지만).

하아, 세상을 너무 복잡하게 살 필요는 없는 것 같다. 가끔은 맘에 안 드는 것을 다른 방식으로 받아들이는 것도 괜찮겠지.

덧. 실제 현업 프로젝트에서는 HTML이나 Javascript 혹은 CSS 같은 건 설계 문서에 어떻게 표현하는지 알고 싶습니다. 아시는 분은 답글 부탁드립니다. (파일 단위로 단순히 entity화하는 건지, 템플릿 하나를 클래스 하나로 보는지 등등...)