요즘 블로그 글이 너무 뜸해서 일단 TNF 블로그에 썼던 글 하나 링크. 지적 사춘기

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

처음 시작은 유크 누나의 블로그. 시험기간에 제대로 말렸다. 나중엔 이오공감에도 올라갔다.;;

마치 P와 NP의 중간적이 맛이 많이 나고요. 표현을 하자면 굉장히 처음 보았지만 조금만 생각하면 polynomial time에 satisfiability problem으로 transform할 수 있는, 그것은 마치 P=NP라는 환상적인 대덕 스피드스타즈의 레이서, 8051 칩만으로 듀얼코어를 이기는 알고리즘. 하지만 증명할 수 없어서 다시는 볼 수 없을 것만 같은 그런 느낌을 받았습니다.

참고 자료 : http://genesis.isloco.com/139

댓글로 달았던 것에서 여인을 알고리즘으로 바꿨다. 시초가 된 원문은 다음과 같다. (TV프로그램 '스펀지'에서 어느 소믈리에가 했다는 표현)

음... 마치 이맛은 신세계와 구세계의 중간적인 맛이 느껴지구요. 음... 표현을 하자면, 굉장히 처음 보았지만 처음 본 것 같지 않은 풍경, 마치 이베리아 반도의 탱고의 여인, 탱고를 추는여인. 하지만, 그여인이 친숙하게 느껴지는 그런 느낌을 받았습니다.

유크 누나 블로그에 가면 그 누나의 동아리 게시판에 올라온 미적분학 버전, 건설및환경공학과 버전, 산디과 버전, 세포생물학 버전 등을 볼 수 있고, 수많은 사람들이 댓글과 트랙백한 것을 볼 수 있다. (심리학과 버전, MBTI 버전, 국문과 버전, SW 개발자 버전, ....)

드디어 지난 금요일에 기말고사가 끝났습니다. 시험기간 동안 Supreme Commander에 말리기도 하고, 소믈리에 놀이에 말리기도 하고... 우여곡절 끝에 어쨌든 끝났군요.

일단 이번 포스팅에서는 과목별 총평을 해보겠습니다.

고전역학I

물리과 과목을 들어보고 싶어서 들어본 과목. 교수님이 상당히 쉽게 가르치시는 편이었고, 시험이 교과서 예제 및 숙제 암기 형태라 좀 맘에 들진 않았지만, 뉴턴역학이 전부가 아니라는 것을 알게 되었다. 고등학교 때 뉴턴역학으로 풀려면 굉장히 복잡한 계산을 해야 했던 문제들이 라그라지안으로 쉽게 해석될 수 있다는 것이 매력이었다.
다만 교수님이 정리를 잘 해주시는 건 좋은데 너무 반복적으로 설명(전 시간에 한 내용을 또 설명하고 그러는데 그게 가끔은 그 수업 시간 다 가도록 그러는 경우가 왕왕 있다)해서 물리과 전공하는 친구들은 상당히 지루해했다. (나는 복습을 할 필요가 없어서 좋던데..-_-)

전산기조직

그다지 관심이 있는 분야는 아니지만 전공필수이기에 들은 과목. 그러나 이 과목을 담당하시는 교수님이 학술정보처 처장이라 그런지 술을 굉장히 많이 드셔서 술기운에 수업을 하시는 경우가 많았다;; 수업을 시작하면 조금 재밌는 얘기를 하시는 듯하다가 결국 다들 자게 만드시는 위력의 소유자. 게다가 시험은 족보와 판박이라서 족보를 본 자(혹은 재수강하는 자)와 그렇지 않은 사람들의 차이가 너무나도 크다.
수업 때 출석도 안 부르고 시험도 족보에서 그대로 나오니 공부를 할 필요를 느끼지 못하는 과목이다. 그나마 중간고사는 숙제에서 많이 나와서 할 만 했는데, 중간고사 이후 숙제가 하나도 없어서-_- 내가 혼자 골라서 풀어본 연습문제를 다 비껴갔다. OTL;;; 시험을 보면 시험지를 걷어버리기 때문에 족보를 구하기도 힘든 편. 그래서 이번에 수강한 사람들과 시험 끝나고 문제를 복기해서 동아리 족보를 만들었다. -_-;;
사실 내용 자체는 잘 이해하면 low-level까지 컴퓨터의 작동을 이해하는데 큰 도움이 되지만, low-level이나 embedded에 관심이 없다면 별로 재미도 없는 내용이고(개인적으로는 재밌었지만), 재수강비 15만원 주고 수업 안 듣고 성적 받을 수 있는 과목이라 들을 가치가 없다. (근데 왜 전공필수냐고! ㅠㅠ)

알고리즘

전산과의 가장 중요한 전공필수 과목 중 하나라고 할 수 있겠다. 데이터구조나 이산구조에서도 기본적인 개념과 몇 가지 알고리즘들은 배우지만 여기서는 더 넓은 영역을 다룬다. 문제는, 이 과목을 현재 번갈아 강의하시는 두 분의 교수님 수업이 둘다 매우 들을 만 하지 못하다는 것. 이 문제는 작년 가을부터인가 완전 영어강의로 바뀌어서 더욱 심해졌다.
나이가 좀 있으신 신교수님의 수업은 교수님의 목소리 톤이 매우 일정하고 졸리기 때문에 안 그래도 듣기 힘든데, 영어로 하는데다 굉장히 많은 내용을 꾸역꾸역 머리에 집어넣어주시는 스타일이라 따라가기가 힘들다. (잘만 따라가면 배우는 건 많다.) 이 강의의 문제는, 뭔가 필기를 해야겠다고 펜을 드는 순간 그 다음 수업 내용을 놓쳐버린다는 것. 한글 강의의 경우 웬만하면 머리에 buffering이 되는데, 이 강의는 가르치는 게 많아서 그런지 설명을 한 번씩만 하고 죽 지나가버리는데다 영어라서 한두 단어를 놓치면 전체 맥락이 끊겨버린다. (게다가 수업자료 슬라이드가 매우 보기 힘들게 구성되어 있다. 정의하지 않은 문자가 막 튀어나오는가 하면 내용을 정리한 게 아니고 Why? How?라는 질문만 잔뜩.... 사실 스스로 생각해보라는 점에서는 좋지만 수업을 듣기가 힘들어서 슬라이드에 의존하게 되기 때문에 쥐쥐다.) 다만, 교수님 자체는 열정이 있으셔서 수업 외 시간에 따로 찾아가면 질문도 잘 받아주시고 보강도 꼼꼼히(...) 하셔서 좋았다.
다른 한 분은 비교적 젊으신 최교수님인데, 사실 작년 가을에 들으려다가 첫 시간 듣고 바로 드랍했다. 이거야 원, 외국에서 공부하고 오셨다는데 영어강의를 이렇게 못하시면.... (내용만 안다면) 내가 대신 강의하고 싶을 정도다. -_-;;;; 대신 난이도나 로드는 신교수님 수업에 비해 낮다고 한다.
어쨌든 알고리즘은 수업 내용보다는 주로 교과서 및 Introduction to Algorithms를 보면서 주변 사람들과 정보를 공유해가며 공부를 할 수밖에 없었다. (나중에 안 사실인데 초반에 나온 몇몇 숙제는 Intro. to Algorithms 책 본문의 식 유도과정을 문제로 내기도 했던...-_-)

응용미분방정식

그야말로 어려운 이론도 없고 노가다만 하면 되는 과목이지만, 어떻게 된 게 수업은 이번 학기 수강과목 중 가장 들을 만했다. 응수과나 다른 과 교수님들이 수업을 하시는 경우가 많은데, 수학과 교수님이라서 그런지 설명도 체계적이었고 항상 수업 시작후 10분 정도 전시간 내용을 정리해주셔서 수업을 따라가기가 아주 편했다. (거의 안 졸고 필기도 거의 안 빠지고 다 했다)
다만 시험이... 시험이...............OTL OTL ;;;; 나름 필기도 열심히 하고 SE 프로젝트 때문에 퀴즈 몇 번 망한 거 빼면 퀴즈도 열심히 보고(매 챕터 내용정리도 하고..) 했던 과목인데 시험에서 완전... 족보를 보니까 매우 쉽길래 계산 실수가 곧 학점이겠구나 했는데, 문제 난이도가 갑자기 급상승했다. 미적분과 응미 전 범위의 모든 내용을 속속들이 꿰차지 않으면 풀 수 없도록 해놓았던 것이다. (겉보기엔 문제가 간단해보여도 실제로 계산해보면 3~4가지의 계산 방법 중 일반적으로 쓰는 것으로는 풀리지 않고 꼭 가장 외우기 싫은(?) 방법을 써야만 풀리게끔 해놨다.. -_-) 백지가 속출했다는 소문도 있지만 실제 성적 분포가 어떨지 예측을 할 수 없다.

소프트웨어공학 개론

일단 한숨부터. 하아;
이번 학기 가장 널럴한 과목이라고 생각하고 수강변경기간에 추가 신청한 과목인데, 결과적으로 다른 모든 과목을 말아먹는 과목이 되고 말았다. -_- 수업 자체는 그냥 교양 분위기였는데, 5명이서 하는 팀프로젝트가, 직접 제안한 프로젝트(주로 서비스 형태)를 가지고 Waterfall process model을 따라가다보니 문서 양이 기하급수적으로 증가해서 결국 최종 설계 문서는 A4 160장을 돌파했다. -_-; SW 개발이라는 것 자체가 워낙 추상적인 거라서 사람마다 생각하는 방식이 다 다르기 때문에 이를 sync시키기 위해서 시간이 많이 걸렸고, 로그인과 같은 매우 사소한 부분도 설계 문서 작성과 토론에 엄청난 시간이 걸렸기 때문에 로드가 10학점에 달했다. (조모임 한 번 하면 12시간씩 하고 그러니 다른 과목을 공부할래야 할 수가 없었고, 이 때문에 결석한다거나 퀴즈를 쥐쥐치는 일도 있었다.) 아직도 프로젝트가 안 끝나서, 다음 주 화요일에 최종 데모 발표까지 해야 한다. -_-;

URP : 수중로봇 개발

이것도 참... -_-; 주제 자체는 상당히 흥미로운 것인데, 교수님과 랩 조교님들 모두 로봇 제작을 처음 해보시는 거라서 삽질을 너무 많이 했다. 특히 어떤 부품들을 사용할 것인지 결정된 것이 4월쯤이었으니, 1월 초부터 시작한 걸 생각하면 너무 오래 걸린 셈이다. 게다가 부품들을 주문해서 인도받기까지 1개월이 넘게 소요되어 결과적으로 제대로 부품들을 건드리고 삽질을 시작한 것은 5월 중순부터였다. 축제에 기말고사 지나고 나니 다음 주 금요일이 최종보고서 제출 마감일.;;; 다행히, 이 연구를 우리가 한 번 하고 끝나는 게 아니고, 그 랩에서 몇 년 동안 계속 이어서 하면서 URP로 계속 개설하고 있기 때문에 연구 자체가 망했다...라고 말할 수는 없지만 많이 아쉬운 부분이다. 그런 점에서, 혹시 이 글을 보는 사람 중에 URP를 하고자 하는 사람이 있다면, 반드시 그 랩 구성원들이 어느 정도 경험이 있는 분야의 주제를 택하라고 얘기해주고 싶다. ㅠ_ㅠ

간만에 그린 그림. 그린 지는 좀 된 것인데 마침 생각나서 올려본다.

주제 1

주제 2

주제 3