드디어 어제 부로 이번 학기 최대의 다크호스였던 소프트웨어공학개론 프로젝트가 끝났다. 제일 널럴한 과목으로 생각하고 수강변경기간에 덜컥 신청하고, 친구 한 놈과 동아리 후배 녀석 한 명까지 꼬셔서 같이 들었다가 이거 완전 대어를 낚은 셈이 되어버렸다. (조모임을 한 번 하면 12시간씩 하는 등 체감 로드로 보건대 이건 6학점을 줘도 모자랄 것이다.)

어제는 그간의 프로젝트 진행과정과 구현물에 대한 데모가 있었다. 우리팀은 KAuction(KAIST-Auction) 기획을 결국 C#으로 끝까지 구현했고, 이미지 삽입 기능을 제외한 대부분의 기능이 큰 버그 없이 돌아갔다. 영화 예매 시스템, KAIST 사람들끼리 약속을 잡아주고 인맥 관리를 도와주는 KAIST MATE, 학습 효과를 높이기 위해 각종 시험 성적을 통계적으로 관리하고 조교들은 숙제를 내줄 수 있는 시스템 등 다양한 아이디어가 나왔다.

그 중에 마지막으로 발표한 팀이 JSP를 이용해 웹으로 구현했는데, 역시 그걸 내가 그냥 지나칠 리 없다. -_-

초반에 조교들과의 논쟁을 거치면서 웹 기반으로 프로젝트를 하는 걸 포기했는데, 그 당시에는 아직 직접적인 설계 경험이 없었기 때문에 결국 적절한 문서화에 실패할 가능성을 떠안을 수 없었기에 그랬었다. (무엇보다도 팀원들의 학점이 걸려 있었으므로.) 그러나, 240장짜리 최종 Design 문서[footnote]사실 이렇게 길게 된 건, Statemachine Diagram들이 여백이 많았다는 것과, 코드 구현 후 문서 작업을 할 땐 doxygen으로 자동 생성하면서 표로 정리하는 형태를 버렸기 때문이다. 하지만 그것을 감안하더라도, 아무리 줄이고 줄인다고 해도 140장은 될 것이다.[/footnote]를 작성하고 나니, 웹으로 할껄하는 생각이 강하게 들었다.[footnote]사실 나는 태터툴즈/텍스트큐브의 개발에 참여하고 있었고, 웹 관련 프로젝트를 몇 번 해보면서 이것을 어떻게 하면 좀더 "잘" 할 수 있을까 하는 관점에서 웹 기반 프로젝트를 꼭 SE로 해보고 싶었던 것이기도 하다. (교수님은 'fancy한 프로그램'을 만드는 것보다는 문서와 코드의 연결을 해보는 것이 수업 목표라고 하시면서 웹을 제한한 거라고 하시는데, 사실 나는 fancy한 다양한 웹기술의 활용보다는 웹에 SE를 적용한다는 점에서 해보고 싶었던 것이다)[/footnote]

HTTP의 request-response 모델이나 Ajax 기술, 또 로그인을 유지하기 위한 session, Django와 같은 웹프레임웍에서 제공하는 object들, presentation layer와 logic layer의 분리와 함께 발생하는 template 및 javascript들을 처음엔 어떻게 모델링해야 할지 난감한 면이 있어서 조교의 말에 넘어가버렸지만, 지금 와서 생각해보면 머릿속으로 다 줄줄이 그려진다. 물론 그간의 삽질이 있었기 때문에 그런 것도 있긴 하지만.

중간에 이 엄청난 문서 작업에 대해 막 화풀이(?)도 하고 그랬는데, 교수님도 인정하셨듯 한 번의 release를 향해 달려가는 waterfall 모델이기에 어쩔 수 없는 부분이기도 했다. 수업 후반부에서 process model들을 다루면서 다양한 개발 방식에 대한 이야기들이 나왔는데, 그 중에서 XP(eXterem Programming)는 light-weight process로 분류가 되고, waterfall 등의 heavy-weight와 달리 관리자 중심이 아닌 개발자 중심의 관점에서 만들어진 것이라는 얘기가 있었다.

유지보수를 생각하면 분명히 상세한 문서화가 중요하지만, 실제 개발 과정에서는 UML 중에서도 class diagram, sequence diagram, 그리고 자체적으로 attribute/method들과 각종 개념·의도들을 정리한 위키 페이지 외에는 거의 볼 일이 없었다. 다른 사람에게 KAuction의 구조와 코드를 완전히 이해할 수 있도록 하기 위해 (줄여서) 140장 가량의 문서가 필요한 것일까? 문서화의 필요성 자체에는 공감하지만 더 효율적이고 명확한 문서화를 할 수 있는 방법을 강구해봐야 한다고 생각한다.

내 생각에는 문서의 비중을 줄이고, prototyping을 한 후 기능과 세부 구현을 add-on시켜나가는 방식으로 하는 것이 오히려 더 현실감 있고 좋았을 것 같다. 문서화의 진정한 의미는 유지보수에서 나오는 것이기 때문에, 한 학기에 유지보수를 다 다룰 수 없는 상황에서 그쪽보다는 좀더 개발 프로세스 자체를 실험해보는 데 의의를 두는 것이 맞는 것 같다.

한편, SE랩의 어느 분이 논문을 쓰기 위해 effort 측정을 하는 프로그램인 PEM이라는 것을 사용하도록 했었는데, 결국 마지막에 가서는 대부분 쓰지 않은 것 같다. 일종의 키로거 비슷한 것으로, 작업하는 동안 켜두면 분당 keystroke 수, 마우스 움직임, 사용하고 있는 프로그램 등을 모니터링하는 것인데, 한 컴퓨터에서 여러 명이 원격 접속해서 쓰는 경우(Windows Server 2003을 쓰는 경우)에 문제가 발생하기도 하고, 저사양 컴퓨터에서는 성능 저하 문제도 있었다. 이런저런 이유로 인해 사람들이 잘 쓰지 않았고, 결국 그 논문을 제대로 마무리하기는 힘들어보인다.

Effort 측정을 과연 keystroke 등으로 객관적으로 뽑아낼 수 있는 것일까? 어떤 사람은 매우 천천히 한자한자 코드를 치는 사람이 있는가 하면, 머릿속으로 한참 생각하다가 바바바박 하고 코드를 쳐내는 사람도 있다. 그러한 다양성이 얼마나 잘 반영될 것인지 의문스럽다. 어쩌면 bluehope 형의 글처럼 subversion이나 trac 등을 잘 이용할 때 그런 툴들이 제공하는 log가 더 의미가 있는 것은 아닐까 하는 생각도 해본다.

어쨌든 SE 프로젝트는 끝났다. 아쉬운 점도 많았고, 또 배운 점도 많았다. 같이 프로젝트를 했던 사람들과 친해지게 된 것도 소득이라면 소득이랄 수 있겠다. 마지막으로 한 마디.

제발 이 과목 어디가서 3학점짜리라고 하지 말아주세요. OTL