SE 프로젝트 (2)
- Posted at 2007/04/06 23:36
- Filed under 컴퓨터
요즘도 계속 SE를 하고 있다. 나 혼자 하는 거면 모를까, 그래도 팀원들과 같이 하는 것이다보니 다수의 의견을 따라 웹을 버리기로 했다. 사용자 편의를 위해서 뭔가 자세하게 하려고 하면 할수록 sequence diagram, class diagram이 오히려 복잡해져서, '문서와 코드의 consistency'를 중요시하는 분위기 상 오히려 감점 요인만 늘어난다는 생각 때문이었다.
지금 우리가 이 수업에서 하고 있는 프로젝트는 CADIT(Conceptualization - Analysis - Design - Implementation - Test)의 과정 중 T를 제외한 나머지를 다룬다. 상당히 전통적인 개발 방법론이라고 볼 수 있는데, 문제는 이 방식이 처음에 모든 것을 완벽하게 설계해놓고 거기에 맞춰 코드를 만들어 결과물을 짠~ 내놓는 것이라는 점이다.
이는 몇 년 전부터 뜨기 시작한 XP(Extreme Programming)에 정면으로 대치된다. XP에서는 아주 작은 스케일(초, 분)부터 아주 큰 스케일(달, 년)까지의 시간 단위마다 지속적으로 가치 점검과 방향 수정을 하며, 모든 것을 다 설계한 다음 한 번에 구현하는 것이 아니라 중요한 기능들부터 먼저 구현하면서 주변 기능들을 덧붙여 나가는 방식을 사용한다. 어떻게 보면 자전거 타기에 비유할 수 있을 것이다. 자전거를 타면 우리는 원하는 경로를 따라가기 위해 무의식 중에 연속적으로 미세하게 경로 변경을 하는데, CADIT은 모든 준비를 마친 다음 목표 지점에 도달하기 위해 포탄 발사하듯 내던지는 격이다. 그 둘의 차이점(장단점)은 굳이 말하지 않아도 알 수 있으리라 생각한다.
사실, 수업 프로젝트로 하는 것이기 때문에 우리가 처음 원했던 수준만큼 프로젝트를 진행하는 것은 여러모로 무리가 있을 수도 있다. 다른 수업과의 로드 분산도 고려해야 하고, 조교와의 의견 조율도 필요하기 때문이다. 또 학부 수업에서는 아무래도 '고전'에 해당하는 것을 다루다보니 더 그런 것이라는 얘기도 들린다. 결국 우리는 설계 문서 작성법을 익히는 데 의의를 두고 코드는 C#을 이용해서 간단하게 짜기로 했다. (물론 완전히 확정됐다고 보기는 조금 그렇다) 실제 서비스하는 것을 목적으로 하지 않고 prototyping을 목적으로 한달까(라고 자기합리화하는 듯한 느낌이 들지만).
하아, 세상을 너무 복잡하게 살 필요는 없는 것 같다. 가끔은 맘에 안 드는 것을 다른 방식으로 받아들이는 것도 괜찮겠지.
덧. 실제 현업 프로젝트에서는 HTML이나 Javascript 혹은 CSS 같은 건 설계 문서에 어떻게 표현하는지 알고 싶습니다. 아시는 분은 답글 부탁드립니다. (파일 단위로 단순히 entity화하는 건지, 템플릿 하나를 클래스 하나로 보는지 등등...)
- Tag
- KAIST, SE, 소프트웨어공학개론
- Response
- No trackback yet , 13 Comments
- RSS :
- http://daybreaker.info/blog/rss/response/592
Trackback URL : http://daybreaker.info/blog/trackback/592
Comments List
-
jasmin 2007/04/07 00:00 # M/D Reply Permalink
글을 읽을때마다 정말 열심히 생활하는 것 같아서 보기 좋아요
화이팅입니다-
daybreaker 2007/04/07 06:16 # M/D Permalink
네. ^^;
-
-
polarnara 2007/04/07 00:14 # M/D Reply Permalink
그쪽 방향으로 결정되었군요. 뭐 좋은게 좋은 거라고 느긋하게 생각해보는 것도 :)
-
daybreaker 2007/04/07 06:16 # M/D Permalink
넵. 그냥 기본적인 것을 배우는 수준에서 만족키로 했습니다.
-
-
최재훈 2007/04/07 01:05 # M/D Reply Permalink
XP는 그렇다치고 나선형 개념 정도만 되어줘도 좋은데 말이죠. 그나저나 오늘 잠깐 이야기했던 Waterfall 2006 Workshop http://www.waterfall2006.com/ 이나 한번 봐요. 진짜 웃겨요.
-
daybreaker 2007/04/07 06:14 # M/D Permalink
흐흐, 시간 날 때 한번 봐야겠군요.;
-
-
lifthrasiir 2007/04/07 01:19 # M/D Reply Permalink
XP는 겉으로 보기에는 설계를 안 하는 것 같아 보이지만, 실은 설계와 프로그래밍이 합쳐진 형태라고 본다. 단위 테스트는 설계의 requirement에 해당하겠고, 그 requirement를 만족하는 프로그램을 최대한 점진적으로 완성시켜 나가는 과정이 설계 그 자체이며, 그 과정에서 파괴적이지 않은 방법으로 리팩토링을 하면서 설계를 안전하게 refine하는 셈이지. 개발자가 "설계를 싫어한다"는 통념에 비추어 보면 XP는 편식하는 아이들한테 다양한 재료로 맛있는 음식을 만들어서 편식을 하지 않도록 하는 방법론에 가깝겠지. 이번에 SE 프로젝트 하면서 그런 걸 정말 몸으로 느끼고 있다.
(덤: 컴파일러 프로젝트 한 시간 딜레이. 앗싸 ㅠㅠ)-
daybreaker 2007/04/07 06:18 # M/D Permalink
나도 XP가 설계를 하지 않는 거라고 보지는 않는다. 다만 설계와 구현이 매우 밀접하게 접목되어 있어서 설계가 있다고 생각되지 않을 정도(?)인 거겠지. 어쨌거나 기본 분석과 설계는 어느 정도 이루어져야 시작을 할 수 있을 테고, 그것을 agile하게 새로운 요구사항에 대해 대처할 수 있도록 하는 게 목표니까.
내가 말하고 싶은 건, 모든 것을 한 번에 완벽하게 설계에서 그대로 구현한다는 패턴으로 가는 게, 과연 실제적으로 얼마나 효용이 있을까 하는 점에서--그리고 웹이 OOP에 맞지 않는다는 다소 일방적인 주장 때문에--SE 프로젝트가 맘에 들지 않는다는 것이다. 한편 기본적으로 분석과 설계를 어떤 식으로 작성한다는 것을 배운다는 면에서는 좋은 경험이 되겠지.
-
-
CN 2007/04/07 13:06 # M/D Reply Permalink
스펙문서만 만들더군요. 얘기하지 않은 상황이 있으면 다시 토론에서 문서에 이야기 해두고.. 그렇게 작업했습니다. N모사에서는요.
-
daybreaker 2007/04/11 15:46 # M/D Permalink
흐음, 좀더 자세히 알 수 있을까요?
-
-
SCV 2007/04/08 13:28 # M/D Reply Permalink
항공과에서 하는 LTA 프로젝트(비행선 만드는거) 역시 이것과 좀 비슷하달까.. 한 번 디자인 플랜을 잡고 그 디자인을 매우 디테일한 부분까지 모두 설계한 다음에, 그것과 99% 일치하는 실제 모델을 만들어가는 프로젝트. 이런 방식은 이론과 실제의 차이를 확연히 느끼는 데는 좋겠지(..)만 아무래도 실제로 잘 나는 비행선을 만들기 위해서는 자주 시행착오를 거치는 방법이 훨씬 낫다고 생각해.
-
daybreaker 2007/04/11 15:47 # M/D Permalink
뭐 결국은 다 비슷한 것 같아.
건축 설계도 도면만 완벽하다고 해서 좋은 건물이 되는 것이 아니듯이.
-
-
kingori 2007/04/11 21:51 # M/D Reply Permalink
흠.. 제 경험으로는 설계문서 자체가 없었습니다.
설계 없어요, 걍 하는 겁니다.
물론 framework은 뭘 쓰고 coding 표준은 이런것이다 하는 것은 있지만 ,로직이 어떻게 흘러가고 하는것에 대해 그냥 개발자 맘대로 했죠.