비오는 날엔 해골과 같이 산책을.
비오는 날엔 여러분은 무엇이 생각나시나요?
커피, 소주, 해물 파전? 무엇을 선택하든지 아마 이런 맘일 겁니다. 우울한 날엔 분위기에 빠져 보기도 싶고, 또는 친한 친구들과 함께 얘기를 나누며 적적함을 달래고 싶을 수도 있습니다. 저는 동완이 아빠가 되고 나서는 거의 꿈도 못꾸고 있습니다. 🙂
자!, 만약 여러분의 프로젝트가 비오는 날 (Rainy Day)라면 어떻게 할까요? 이 Rainy Day의 의미는 우리가 구축해야 될 시스템이 무엇인지 고객도 모르고, 나도 모른다는 얘기입니다.
구체적인 목표나 비교 대상이 없는 프로젝트를 말하는 거죠. 이런 비오는 날에 여러분의 대처 방법이 어떨지 궁금합니다.
사실 우리는 이해당사자들이나 고객의 요구사항을 받아들이고, 멋진 프로그램을 만들길 원합니다. 하지만 고객은 정작 자기가 뭘 원하는지 구체적인 것을 제시할 수 없다면, 참 막막할겁니다. 전 이럴때 걸어다니는 해골 (Walking Skeleton)을 추천해 드립니다.
이 아이디어는 Agile 에서 유명한 Allestair Cockburn이 아주 오랜전에 낸 아이디어 입니다.
이럴 경우에는, 고객이 원하는 시스템이 무엇인지 정말 경청해서 듣고, 거기서 무엇이 정말 중요한 요소인지 식별해 내는 것이 가장 먼저겠죠. 그래서 간단한 Prototype을 만들고 고객에게 피드백을 받을 수도 있을 겁니다.
이럴 경우 해야 되는 것이 바로 걸어다니는 해골입니다. 걸어다니는 해골이란 핵심 시나리오나 Feature가 실행되기 위한 종단(End-to-End : UI 단 부터 DB 까지 또는 다른 시스템 호출까지..)간에 모든 연결 고리를 다 지나는 Skeleton을 말하며, 이걸 몇개 만들어 보길 권해드립니다.
최종 보이는 결과가 고객의 입장에서는 UI 이겠지만, 실제 시스템이 필요로 하는 내부적인 요구사항과 실제 구축시 발생하는 여러 문제들을 정확히 파악 해 내지 못할수도 있습니다. 예를 들어 여러 QoS (보안, 응답 속도, 처리량 등..) , 선정한 Framework의 사용성 및 적합성, 비지니스 도메인에 대한 정보에 대해 전혀 예측을 못할 수도 있습니다.
물론 걸어다니는 해골이 모든 문제를 완벽하게 파악해내는 만병 통치약은 아니지만, 그나마 어느정도 시행 착오를 줄여 줄수 있는 좋은 방법입니다.
Skeleton을 구축할 때, 주의 해야 할것은 바로 시나리오로 Skeleton을 구축하길 권해드립니다. 물론 시나리오보다는 Feature 기반의 시스템이라면, Feature별로 가야 겠죠. (최악의 경우는 시나리오 기반의 시스템인데 Feature로 구착하는 경우죠.. 또는 반대.. ) 그래서 변화가 발생하더라도, 변화의 전파를 잘 가둘수 있게 시스템을 만드는 것이 중요합니다. Feature Crew나 기능 팀이 좋은 예 이겠죠.
아마 그리고 남아있는 예측하지 못하는 변화/요구사항의 해결책은 대화이며, 서로의 문제를 능동적으로 대처할수 있는 정신이 아닐까 생각이 듭니다. Kent Beck이 말한 말이 아직도 생각나네요. “발생한 이슈(버그, 문제)는 한 사람의 책임이 아니라, 우리 모두의 책임이다.” 라는 말요.
우리모두 성공하는 팀이 되기 위해선, 서로 이타적인 조직을 만들기 위해서 노력해야 될듯 합니다. 저처럼 한번 말아먹으면, 정말 정신 차리게 됩니다. 다시는 이러한 일이 없길 바라며..
Architecture 101 
데브피아 mblog 보고 따라 왔는데.. 이런게 있었네요.. 최근하는 프로젝트가 딱 이경우입니다. 처음에 요청부서랑 엄청 싸웠습니다. 저희는 원하는걸 말해라.. 그쪽부서는 먼저 보여줘라.. 역시 누군가 같은 고민을 했을텐데 “걸어다니는 해골” 좀더 자료를 찾아보고 공부를 해봐야겠네요..
예 쉽지 않는 얘기죠.
Walking Skeleton은 UI Prototyping보다 좀더 자세히 고객의 반응을 받을수 있고,
저희 개발자도 Framework를 선정하고, Architecture를 선정하는데 도움을 주는 한 방법입니다.
사실 이 작업으로 저희 개발자/아키텍트 역시 많은 시행착오를 겪으면서 견고한 아키텍쳐를 뽑아 낼수 있죠. 특히 저희 같이 경험이 없는 사람들에게는 좋은 방법입니다.
이걸로 이제 뼈대가 갖추어 지면, Sparx Systems EA의 Code Template 기능으로 코드를 막 찍어내서, 생산성을 무지 무지 향상 시킬수 있습니다.
얼마나 정형화 시킬지가 관건이지만요 🙂 !!
여튼 도움이 되셨다니 즐겁네요!!
이 포스트를 같이 프로젝트 하고 있는 사무실 동료에게 보여주니까 무척 공감을 하네요. 여세를 몰아서 디자인 패턴에 대해서 소개도하고 갖고 있던 책중에 HeadFirst Design Pattern 책을 보여주니 집에서 봐야겠다며 빌려갔습니다. 다음에는 곤란한 상황이 되면 먼저 영수님께 적당한 패턴이 있는지 물어보고 시작해야 겠습니다.. ^^
사실 패턴은 무지 많이 도움이 됩니다.
제가 실례되는 말씀을 하는것 같지만.. 사실 GoF 패턴으로 할수 있는 것은 매우 빈약합니다.
단지 패턴들을 엮어 주는 접작체 같은 역할을 하지요.
거대한 아키텍쳐 패턴과, 디자인 패턴, 구현 패턴들이 적제 적소하게 쓰여야 하며, 모든걸 패턴화 시키기 보다는 적절히 🙂 분배하는게 중요합니다.
전 GoF의 디자인 패턴 보다는 Refactoring to Patterns (패턴을 활용한 리펙토링) 이라는 서적이 아마 더 도움이 될거라고 생각이 듭니다. 패턴에 좀더 친숙해 지기 위해서는요 🙂
여튼 궁금한 문제나 QoS 선정등에 대한 이야기들이 정해지면 말씀해 주세요. 시간이 허락하면. 🙂 아는 범위에서 성심 성의껏 지원하겠습니다. !!
옛말에 “잘될놈은 떡잎부터 알아본다” 라고 하죠.
그 떡잎이 무지하게 중요하다는 거죠!!
하지만 급격한 IT의 발전으로 그 떡잎을, 중요성의 잣대로 보는 이는 아무도 없다는 것이 현재의 문제입니다.
그리고 그 잣대를 놓고.. 이득없는 싸움을 우리는 항상 하고 있죠..
오늘도 한번 더 되새겨 봅니다.
기초의 중요성을 ㅋㅋ ~~ 감사합니닷!!
그렇지 튼튼한 떡잎. 튼튼한 구조를 만드는데는 관심이 없지.
대부분, 사람들, 고객, 의사 결정자들은.
정보를 잘 전달하는 UX적인 관점으로 많은 것을 생각하시지..
그 밑단은 생각을 잘 안하시지. 마치 성형수술 몇번하면 더 미인이 되는줄 알지만,
그것도 심해지면 곪아 터지고, 부작용이 크다는 것을 아직 인식하지 못하는거 같애..
아마 그런 문제들을 해결하는 하나의 방법인거 같애.. 🙂
여튼 기회가 오면 날자고. 아직은 너나 나나 때가 아닌거 같애 🙂
[…] 검증하고 진화시키는 유용한 전략 중 하나로 Alistair Cockburn이 이야기한 ‘걸어 다니는 해골(walking skeleton)’이 있습니다. 걸어 다니는 해골은 종단(예를 들어 UI부터 DB까지) 간을 […]