오늘 밤 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. 이러한 문서화가 오히려 순간순간 나타날 수 있는 개발자들의 창의성을 엮어내는 데 방해가 되는 것은 아닐까. 물론 지나치게 창의적이어서 배가 산으로 가면 안 되지만 말이다.