SE 프로젝트 (3)
- Posted at 2007/04/11 14:27
- Filed under 컴퓨터
오늘 밤 12시 듀를 앞두고 어제 SE 프로젝트 조모임을 무려 12시간 가까이—그것도 새벽 5시까지—했다. 물론 그 시간 동안 순수하게 SE만 한 것은 아니지만(밥도 같이 먹고 음료수 마시면서 잠시 쉬기도 하고, 잠시 내게 배정된 일이 없는 사이 TNF 홈페이지 코딩도 하고..), 그래도 에너지 소모는 엄청났다. 계속 바닥에 앉거나 누워있다보니(GON 동방이었음) 온몸이 쑤시기도 하고 정신적인 에너지 소모도 장난 아니다. 결국 오늘 아침 수업 2개는 다 째고 말았다. -_-
우리가 듀 직전이라서 이렇게 달리는가 하면 그것은 또 아니다. 우리 조는 다른 조들에 비해서 상당히 빨리 시작한 편이어서, 이미 지난 주 월요일부터 보고서 작성에 들어갔던 것이기 때문이다. (다른 조에 아는 사람을 만났더니 거의 일주일이나 늦게 일요일에 처음 시작했다고도...-_-) Web으로 할 것이냐 말 것이냐 하는 문제도 어떻게든 결론을 지어야했기 때문에 더욱 빨리 착수했던 것이기도 한데, 결국 사용하지 않는 쪽으로 결론이 났다.
뭐, 조원들과 함께 많은(-_-) 시간을 보내다보니 서로 친해진다는 점은 좋지만, 그래도 이건 좀 너무한다 싶은 생각이 들었다. 조원들이 시간을 잡아먹는다거나 하는 것이 아니라—원래 여럿이서 모여서 하다보면 서로 동기화를 해야 하기 때문에 발생하는 오버헤드가 있기 마련이므로—프로그램 설계 자체가 이렇게 시간을 많이 잡아먹을 만한 가치가 있는 일인가 하는 것이다. 뭐 교수님이 수업시간에 말씀하신 바로는 프로젝트 개발 기간의 80%가 설계고 20%가 구현이라는 얘기도 있지만, 지금 우리가 하는 방식의 설계는 너무 사람을 지치게 만든다.
매번 거의 똑같은 이야기를 쓰고, 하나의 기능을 작성하는 데 있어서 수많은 diagram들과 씨름해야 하는 것이 과연 효용성이 있는 것일까? 물론 documentation이 얼마나 중요한 것인지는 나도 잘 알고 있다. (사용자 입장의 것이든 개발자 입장의 것이든 간에.) 하지만 지금은 documentation이 모든 궁극적인 목표가 된 것 같다는 느낌이다. 문서를 위한 문서를 만든달까. 어떤 제품을 만든다는 것은 사용자의 욕구를 충족시키고 그것을 통해 profit을 창출하는 것이 목표일 텐데, 만약 지금과 같이 개발한다면 문서 만들고 나면 지쳐서 정작 개발은 전혀 하지 못할 것 같다.
심지어는, 약간 주제넘은 생각일지도 모르겠지만, UML이 과연 복잡한 프로그램 구조를 설명하는 데 적합한 것인지조차 하는 의심마저 들 정도다. 2~3시간에 걸친 UML 강의도 들어보고 담당 조교님과의 면담도 해보고 예제 문서도 들여다보고 꽤 많은 시간 동안 공을 들였지만, 뭐랄까, 오히려 UML이 우리가 설명하고자 하는 온전한 의도를 왜곡시켜버리는 것 같다. (뭐, 이건 우리가 그만큼 UML을 잘 못 다루기 때문일 수도 있겠지만.) 개발 문서라는 것은 개발자 자신뿐만 아니라 다른 개발자들에게도 설계도처럼 쓰일 수 있어야 하는 것이라면, UML이 과연 그 역할을 다 할 수 있을까 하는 생각이 드는 것이다. 아직 덜 배워서 그런 거라면 모르겠지만 동적으로 scaling되는 thread pool이라든가 하는 것들은 어떤 식으로 표현할까? 또 Web이 왜 이런 설계 문서 작성에 적합하지 않아야 하는 것일까? 등등 수많은 의문들이 존재한다. 사실 Class design 자체가 scale을 어느 수준까지 자세하게 할 것인가에 따라서 많이 달라지기도 하기 때문에 더욱 애매하다.
한 마디로 말해서, 지금 우리가 배우는 기법과 도구들이 우리가 들이는 시간과 노력만큼 절대적인 가치를 지니는가 하는 것이다. 이번 수강생들을 위해 30개의 라이센스를 샀다는, 매우 비싼 모델링 툴인 것 같은(?) TAU도 특정 상황에서 마우스 오른쪽 클릭에 꺼져버린다든가, diagram 인쇄 미리보기를 하면 프로그램 오류난다든가 등등 아주 버그 투성이인 것을 보면 (몇몇) 조교님들이 이 프로그램에 정말 감동먹었다고 하는 것이 도저히 상상이 가지 않을 정도다. Code generation이 된다고는 하지만 과연 그 모호한 UML를 통해 generation된 프로그램이 얼마나 효용가치가 있을까 하는 회의도 든다. (몇가지 예제를 보면 오히려 쓸데없는 부수적인 코드만 더 많아지는 것 같기도 하다.)
Object-oriented가 분명 현재의 대세가 되고 있고, abstraction과 encapsulation을 통해 매우 깔끔한 코드를 제공한다는 것은 동의한다. 하지만 OOP가 모든 것을 해결해 줄 수 있는 만능 솔루션이라고 생각하지는 않는다. 또, 끊임없이 발전하고 프로그래밍 기술과 끊임없이 변하는 요구사항들을 생각했을 때 지금의 설계 방법이 잘 통할 것 같지도 않다. 실전에서는 다르다는 것을 알면서도 이만한 시간과 노력을 들이는 게 무가치하게 느껴진다는 것이다.
다른 조 이야기를 들어보면, 조교들끼리도 class design 방법에 대해 의견차가 있는 것 같고, 게다가 예제 문서 또한 다 맞는 것이 아니라고 하고... 너무나 혼란스럽고 모호한 것이 많다. 이런 상황에서 우리는 엄청난 로드로 설계를 위한 설계를 하고 있다. 힘들더라도 제대로 하는 것이 맞다는 확신이 있으면 견뎌낼 만 할텐데 그렇지 않으니 문제다. 실전에서 이런 식으로 기력을 빨아먹어버린다면 그건 문서화 기계일 뿐이지 사람이 아니다. (프로그래밍하고 문서 만들고 하는 것도 궁극적으로는 자신의 행복을 위해서가 아닌가. 뭔가를 희생 혹은 투자했다면 그만한 가치를 찾아 합리화가 가능해야 한다.) 지금 제대로 하는 게 맞는 건지 심히 의심스럽다.
몇가지 잡설.
1. 혹시 이것은 이러한 방법론 말고 다른 방법론을 택해야 한다는 것을 몸으로 느끼고 깨닫게 하기 위한 고도의 전략?
2. 이러한 문서화가 오히려 순간순간 나타날 수 있는 개발자들의 창의성을 엮어내는 데 방해가 되는 것은 아닐까. 물론 지나치게 창의적이어서 배가 산으로 가면 안 되지만 말이다.
- Tag
- SE, 모호함, 문서화, 삽질, 설계, 프로젝트
- Response
- No trackback yet , 13 Comments
- RSS :
- http://daybreaker.info/blog/rss/response/595
Trackback URL : http://daybreaker.info/blog/trackback/595
Comments List
-
lifthrasiir 2007/04/11 15:05 # M/D Reply Permalink
이따위 버그 투성이에 느려 터진 프로그램이 시장에서 살아 남아서 점유율 상위권을 차지하고 있다는 것에 감동했다. -_-
-
daybreaker 2007/04/11 15:43 # M/D Permalink
그러게 말이다. 저런 모델링 도구 만드는 회사가 별로 없나?
그런 겸 해서, 거의 사장되다시피한 것 같은 오픈소스 프로젝트인 pyut를 branching해서 새로 짜보는 건 어때? =3==3
-
-
코카스 2007/04/11 15:13 # M/D Reply Permalink
ㄲㄲ 그렇지 않아도 석사 SE시간에 누가 '우리도 empiracal 한 방법론으로 프로젝트 합시다' 라고 했었죠. 교수님의 대답은 '그럼 second iteration 은 방학때 한번 돌아 볼까요?' 였습니다. :)
코스웍에서 설계에 집중했을 때 왜 사서 삽질을 하고 있을까 하는 생각이 드는 가장 큰 이유는 maintanence 단계가 없어서 그런게 아닐까 싶습니다. 그럼 오픈 소스 프로젝트들은 다 뭐냐.. 하면.. 오픈소스 프로젝트 리더들은 디자인, 코드에 있어서 천재들이라.. (과연..?)-
daybreaker 2007/04/11 15:42 # M/D Permalink
지금 배우는 것이 어떤 식으로든 지금의 노력을 상쇄(?)시킬만큼의 가치가 있다면, 그 있다는 것을 느낄 수 있는 뭔가가 있었으면 좋겠습니다.
-
-
최재훈 2007/04/11 15:57 # M/D Reply Permalink
'이렇게 하면 된다'가 아니라 '이렇게 하면 안 된다'를 배우고 있는 걸지도....-_-;;
-
daybreaker 2007/04/11 19:04 # M/D Permalink
쩝, 어떻게든 긍정적으로 해석을 하면 할 수는 있지만 문제는 이것 때문에 다른 과목에 너무 많은 영향을 끼친다는 겁니다. ㅠㅠ;
-
-
haneul 2007/04/11 16:19 # M/D Reply Permalink
사실 한과목에서 하는 프로젝트에서는 설계의 중요성을 크게 느끼지 못할 것 같긴 하네요. 그래도 코카스군이 얘기했다시피 maintanence단계가 들어가고, 다른 사람들 일을 인수인계하는 시점에서는 설계문서 하나 더 있는게 정말 고맙게 느껴진답니다. :)
-
daybreaker 2007/04/11 18:51 # M/D Permalink
흠, 저도 maintenance나 인수인계에서 설계 문서의 중요성은 알고 있습니다..만, 설계 문서를 작성할 때 좀더 효과적으로, 그리고 무엇보다 재미있게 작성할 수 있다면 더 좋지 않을까요. 여기서 재미라는 건, prototyping 등을 통해 보다 빠르고 주기적인 피드백을 받음으로써 설계와 구현을 밀착시켜 너무 한 가지 일만 함으로써 오는 지루함을 던다는 의미입니다. (어찌보면 'flow'를 원하고 있다는 게 맞을지도 모르겠군요)
-
-
blmarket 2007/04/11 17:50 # M/D Reply Permalink
idea를 설계가 반영해야지 설계를 idea에 반영시키면 쓰나... '이건 이래야 한다!' 라고 생각해놓고, diagram이 잘 지원을 못해주면 손으로 그리면 되는거지...
우리 팀 같으면 그런 문제보단 역할 분담, 그리고 팀 전체의 Communication에 비용이 많이 들어간 것 때문이라는 생각이 든다.-
daybreaker 2007/04/11 18:55 # M/D Permalink
확실히 손으로 그리는 게 가장 좋은 것 같아요. (http://daybreaker.tistory.com/611 참고) 저희 팀의 경우도 TAU로 작성하기 전에 대충 손으로 그려보고, User Interface도 손으로 그려서 서로 논의한 다음 결정했습니다..만-_- UML과 class design에 대한 이해도가 날마다 바뀌면서 결국 뒤집어엎는 삽질을 많이 했죠.
어느 일정 수준 이상 설계 경험이 있는 사람들끼리 한다면 아마 이런 오버헤드를 많이 줄일 수 있을 것 같아요. 저희는 그런 수준에 도달해가는 과정이라고 봐야 할까나..
그래도 제가 보기에 현재 저희 팀은 의사소통이나 역할분담은 잘 되고 있는 편이라고 생각합니다. 이런 소규모 팀프로젝트를 몇 번 해본 경험에 의하면 말이죠.
-
-
진혁군★ 2007/04/11 23:20 # M/D Reply Permalink
모든게 다 발전의 과정이라고 생각하고.. 천천히 가면 되지 않을가 하네