Daybreakin Things

Posted
Filed under 컴퓨터

드디어 어제 부로 이번 학기 최대의 다크호스였던 소프트웨어공학개론 프로젝트가 끝났다. 제일 널럴한 과목으로 생각하고 수강변경기간에 덜컥 신청하고, 친구 한 놈과 동아리 후배 녀석 한 명까지 꼬셔서 같이 들었다가 이거 완전 대어를 낚은 셈이 되어버렸다. (조모임을 한 번 하면 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

안불렀슈

저는 임베디드쪽 프로그래밍 관련 일을 하고 있는데요, 5-6년전에 개발된 코드에 문제가 발견되는 경우에는 '문서'들이 정말 필요하더라구요.

개발자수가 많아지고, 프로그램 수명이 몇년 ~ 몇십년 가는 경우에는, 코드 1줄보다 문서 1줄이 더 중요하다는 것을 많이 느끼게 됩니다.

^^;;

daybreaker

저도 문서화는 매우 중요하게 생각하는 편입니다. 혼자 짜는 프로그램조차 1년 정도 지나면 반쯤 까먹기 마련인데 여럿이서 짜는 프로그램은 그 정도가 더 심하겠죠. 다만 좀더 개발자들이 접근하기 쉬운 문서화 방법은 없을까 하는 생각은 듭니다. (사실 닥치고 개발자가 똑똑(?)하면 문서가 별 필요 없긴 합니다만 모든 사람의 능력이 동일하지는 않기 때문에 문제지요..)

윗층

http://onesound.tistory.com/1083

나쁜 태터 개발자들. ㅋㅋㅋ

daybreaker

역시 문서화의 문제가... orz;;

최재훈

보통 서비스 회사에선 생각보다 문서를 많이 만들진 않는 편이고(어차피 계속 유지보수하면서 누군가 담당하기 때문에...), SI 업체 같은 경우에 산출물을 갑한테 줘야 해서 많이 하는 편이죠.

데이터베이스 분야에서 유명한 컨설턴트가 자기는 모델링 도구를 사용 안 하고 종이에 그리고, 필요한 경우엔 부하 직원 시켜서 모델링 도구로 옮긴다고 말한 걸 들은 적이 있다는....

daybreaker

손으로 그리는 게 가장 좋은 것 같아요.
전 하다못해 타블렛이라도 지를까(.....) 생각 중입니다;;

최재훈

2004년도 쯤에 같은 교수님 강의를 들은 것 같은데, 그땐 마지막 프로젝트 빼곤 오히려 널럴한 과목이었어요. 아무래도 TAU G2가 삼성 전자 등에서 쓰이기 시작하면서, 학생들이 실무에 적용할 수 있는 도구를 익히게 해보자는 취지였던 것 같은데 덕분에 복잡해진 듯.

문서량이 140장 정도면 사실 준수한 것이라 말할 수 있을지도......
퇴사할 때 생각해보면 하루에 문서를 40장씩 쏟아냈기 때문에......
그렇긴 해도 프로젝트 완료된 후에 문서 만드는 건 쉬우니 1:1로 비교하긴 무리일테지만요.

XP가 개발자 중심이라는 지적은 어느 정도 맞는데, 그래도 나선형 모델도 있고 충분히 다른 대안도 있었을텐데 말이죠. 마일스톤을 좀더 나눠서 나선형으로 해도 괜찮았을 듯. NASA 쪽에서 공개한 가이드라인 보면 상당히 재밌는데 말이죠.

마지막으로 TRAC 등의 로그를 활용하는 건 나름 괜찮은 아이디어이지만 외부에서 평가용으로 사용하기엔 부적절하고, 내부에서 부담없이 자신들의 퍼포먼스를 평가할 땐 상당히 좋은 아이디어 같네요.

daybreaker

문서를 주어진 예제의 틀에 맞추다보니, 뭔가 불필요한 말들이 계속 반복되는 것 같고 해서 귀찮아지고 그래서 힘든 면이 있었죠. 문서의 형식을 딱히 제한하지 않고 썼다면 양도 더 줄이고 보다 명확해졌을 것 같습니다. (근데 이게 참 어려운 것이, 이런 삽질을 해봤으니 이런 얘기를 할 수 있다는 점입니다. 교수님이 지적하시는 게 그 부분이기도 하구요.)

TAU의 경우는 너무 버그가 많았습니다. 작업하다가 날려먹는 게 다반사니(정말 subversion이라도 썼으니 망정이지) 욕이 안 나올 수가 없었습니다. 당연히 작업 시간도 길어졌구요. 차라리 손으로 그리는 게 낫겠다는 생각입니다. 마지막 프로젝트할 때는 결국 Visual Paradigm이라는 다른 툴을 찾어서 했죠.

그러니까, 문서화 자체가 싫다기보다는, 문서화 과정에서 마주치는 툴의 버그/불편함, 형식적인 것들 때문에 질렸다고 보는 게 맞겠습니다. (정말 TAU같은 개쓰레기-_-툴을 왜 쓰는지... 정말 쓰다보면 욕이 안 나올 수가 없더군요) 다 작성해놓고보니 사실 어떻게 쓰는지만 알았으면 수십배는 빨리 썼을 것 같아요.

또 한 가지, 저희가 구현한 KAuction의 기능이나 규모로 봤을 때 문서량이 얼마나 나와야 적절(?)한 건지 모르겠네요. 회사에서 하는 프로젝트들이야 대체로 규모가 어느 정도 있으니 문서량이 많을 것이다라는 생각은 들지만, SE 프로젝트의 경우 문서를 만들기가 귀찮아서 or 힘들어서 기능을 뺀 경우가 거의 다입니다. 상당히 간단한 기능들만 구현했음에도 문서양이 이만큼 된다는 건 그냥 원래 그런 것인지 궁금합니다.

lifthrasiir

여기 날뷁한테 낚인 친구 한 명이요~! ....결국 최종 발표에는 참석 못 했음.

daybreaker

묵념 (...)

[로그인][오픈아이디란?]