어제 소감을 밝힌 스콧 구슬리의 개인적 이야기 및 .NET에 대한 이야기도 재미있었지만 세미나의 두번째 섹션인 사례 소개 또한 못지않게 유익한 것으로 생각됩니다. 기존 DevDay에서 발표한 사례들이 그저 예제 수준의 조금은 실망 스러운 것들이었기 때문에 기대를 않고 보았었는데, 프로젝트를 진행하는데 있어 제가 항상 고민하던 부분들과 비슷한 사항들을 역시 고민하였고, 저와는 달리 이를 명쾌하게 해결하여, 성공적으로 프로젝트를 이끈것으로 보여 무척 인상적이었습니다.
제가 감명받은 부분은 프로젝트에서 .NET이 사용되었다는 것을 떠나 프로젝트를 성공적(개발자와 고객 상호만족)으로 이끌기위한 적절한 개발 방법론의 도입과 시행착오를 통한 보다 실질적인 개발 프로세스의 적용, 그리고 기술적인 면에서의 아키텍처 구조였습니다.
먼저 개발자로서의 개발 경험의 고하를 떠나 누구나 겪게되는 개발에 전혀 도움이 되지 않아 보이는 산출물에 대한 생생한 증언과 이를 현명하게 극복한 사례였습니다.(물론 1차 시행착오를 경험하였지만...) 요구사항 명세서를 예로 고객과 개발자의 언어 장벽이 얼마나 크며, 실적과시를 위한 요구사항 명세서가 개발 과정에서 얼마나 무용지물인지를 비교적 간단하지만 효과적으로 전달했다는 느낌을 받았습니다.
또한 요구 기능에 대해 가장 잘 알고 있는 사람은 고객이며, 따라서 테스트는 고객에의해 이루어져야 한다고 역설하고 마침내 이를 개발 프로세스에 포함하여 실제 그렇게 이루어지도록 한 부분은 기 알고있는 사실임에도 불구하고 항상 실천이 쉽지 않았기 때문에 비교적 성공적으로 이루어졌다는 면에서 신선하게 다가왔습니다. 특히 이런경우 개발 프로세스 도구가 도움이 될거란 확신을 얻을 수 있었습니다. 주객이 전도되는 불상사만 피한다면, Test와 Build, 배포, 피드백을 자동화 해주는 도구를 통해 고객이 자연스럽게 테스트에 동참하도록 할 수 있겠구나 하는 생각이 들었습니다. 저는 그동안 갖추어지지 않은 프로세스 내에서 고객이 테스트에 동참해야 한다는 원칙만을 고수하며, 정작 그런 환경을 제공하지는 못했기 때문에 실패하지 않았나 하는 생각을 해볼 수 있었습니다.
기타 1차 개발과정에서 나타난 개발 프로세스의 문제점들을 분석하여, 이를 해결하기 위한 과정과 적합한 방법론의 선택 그리고 적용까지의 과정을 위 내용을 포함하여 설명하는 부분은 저의 경우는 극히 일부에서만 성공하고 실패했던 경험이 많은터라 정말 공감이 가면서도 교훈이 되는 유익한 내용이었습니다.
부가적으로 일정과 관련하여, 고객의 기능 요구에 대한 개발자의 피드백 의무는 해당 요구사항 구현에 소요되는 구체적인 기간을 알려주는 것임과 PM이 할일이 개발자들로 부터 이들 시간 범위를 취합하여, 일정을 추정하고 고객과 조율하는 것임을 언급하는 내용에서 또 한가지 교훈을 얻을 수 있었습니다. 저는 그동안 고객(기획자)에게 일정을 알려주는 것이 당연한 의무임을 알고는 있었지만, 너무 정확한 시간 산정에 얽매인 나머지 항상 무리한 산정으로 귀결되어 버린 것은 아닌지 하고 되짚어 볼 수 있었습니다. 특히 왜 정확한 기간을 추정하려 애쓰는가? 란 지적에 귀가 번쩍 틔였는데, 예로 '기능 요구에 대해 구현을 하는데 빠르면 1일 길면 1년' 이라 답하는 것이 무엇이 문제인가? 구현 기간에 대한 답이 개발자가 해야할 꼭 필요한 의무이기는 하지만, 왜 굳이 정확한 기간을 말하려 애쓰는가? 경험에 의한 대략적인 범위를 말하고 고객과 개발자가 합리적인 기간 범위를 합의하여 공유해 나가는 과정이 중요하지 않겠는가? 하는 요지의 지적은 그 동안 제가 놓치고 있었던 부분을 일깨워 주었습니다.
그리고 이러한 신뢰할만한 일정 추정의 또 하나의 적인 요구사항의 잦은 변경이 실질적으로 불가피함과 이를 개발 프로세스와 도구로 충분히 극복할 수 있음을 보여준것 또한 유익했습니다.
앞의 내용이 프로젝트 매니저로서의 개발 프로세스 적용에 대한 사례연구였다면, 다음의 내용은 개발자로서의 주어진 기술적인 문제해결을 위한 아키텍처에 대한 것이었습니다.
시스템 아키텍처를 결정하는데 있어서의 요소들과 이의 우선순위 결정, 유연하고 독립적이며 확장성 좋은 UI 모듈을 위한 고민, 기존 시스템 분석을 통한 중요 요소 추출 과 각 요소들을 만족 시킬만한 기술 검토의 과정을 표를 통해 명료하게 정리하고 필요한 기술을 선택해 나가는 과정, 데이타 모델링을 위한 XML 선택의 과정등 기술적 측면을 설명하는 내용 또한 너무나 유익한 내용이었습니다.
특히 그동안 XML 사용시 항상 어려움을 겪던 저에게, XML Schema를 자동으로 Class 코드로 만들어주는 툴들이 있다는 것을 알게된것은 충격이었습니다. XML을 통해 그동안 코드를 많이 작성해 봤지만 왜 다들 XML Schema를 외쳐댔는지 이제서야 조금은 깨달은것 같았습니다.
여러가지 면에서 첫번째 섹션인 스콧 구슬리의 인터뷰 보다 훨씬 유익했다는 말로 시청 소감을 마무리 할까 합니다.
