이번주 금요일 저녁에 강남에서 패턴 세미나를 엽니다.
이광춘 님과 친한 태호형이 힘을 다해 운영하고 있는 미래의 소프트웨어 품질 연구회라는 커뮤니티로, 좋은 강사들을 섭외해서 매 달마다 세미나를 진행하고 있네요. 좋은 강사의 자격(?)은 의심되지만, 부족하나마 저의 지식을 공유할려고 합니다.
- 주최 : 미래의 소프트웨어품질 연구회(미소연), DigiEco
- 일시 : 2009년 10월 23일(금), 오후 7시30분- (세미나는 1시간 30분 예정)
- 장소 : 토즈 강남대로점 (교보사거리 위치)
- 주제 : 미워도 다시 보는 패턴 이야기 / PLOP 학회 참석 후기
이번 행사는 Pattern에 대한 올바른 시선과 학습법을 제공해 드리고, PLoP에 대한 공유도 약간 할 생각입니다. 그리고 Do Food 패턴의 일환으로 약간의 음식(도넛 or 김밥) 도 무료로 제공되니, 금요일 약속이 없으시다면 방문해 주세요 🙂
국내에는 다른 아키텍트에 비해 유명세가 덜하지만, 제가 만난 컨설턴트중에서 가장 현실적인 방법을 제시하는 이가 Rebecca가 아닐까 생각이 듭니다. (물론 개인적인 생각의 차이는 있을수 있지만요..)
저희 Eva팀이 드디어 두 번째 프로젝트인 “97 things every software architect should know (가제 – 모든 아키텍트라면 알아야 할 97가지 이야기)” 에 대한 1차 번역을 마쳤습니다.
2 달만에 번역하기 프로젝트를 시도했지만, 예상외로 아키텍트 특유의 고급적인 문체, 시와 같이 운율을 살리는 비유, 해당 도메인의 지식 부재등으로 약간의 난전을 겪었습니다.
그래서 3달 만에 1차 번역이 마치게 되었네요. 내부적으로 1차 리뷰를 마치고 출판사에 맡겼지만 아직 손봐야 할 것이 여러군 데 있는 건 사실입니다. 어느정도 책의 형태가 나오면 베타리더를 모아 더 다듬어야 겠죠.
범위는 프로젝트의 크기를 언급합니다.
얼마나 많은 시간, 노력, 자원들이 필요한가?. 어떤 수준의 품질에서 어떤 기능성을 가지는지? 얼마나 많은 위험이 있는지? 어떠한 제약이 존재하는지? 이에 대한 대답들이 프로젝트의 범위를 정의합니다.
소프트웨어 아키텍트들은 크고, 복잡한 프로젝트에 도전하는 것을 사랑합니다. 잠재적인 보상은 사람들이 인위적으로 프로젝트 외관상의 중요성을 증가시키기 위해 프로젝트의 범위를 인위적으로 확장하게 유혹할 수 있습니다.
범위를 확장하는 것은 성공의 적입니다, 왜냐하면 실패할 가능성이 예상했던 것보다 더 빨리 증가하기 때문입니다.
프로젝트의 범위를 2배로 증가시키는 것은 종종 실패의 가능성을 10배로 높입니다. 왜 이렇게 실패 가능성이 높아질까요? 몇 가지 예 들을 살펴봅시다.
직감은 일을 두 배로 일을 하기 위해 우리의 시간이나 자원을 두 배로 늘리라고 말합니다.
역사[1]는 ,직관이 제안했던 것처럼, 미치는 영향이 선형적으로 증가(두배로 일하기 위해 미치는 영향이 단시 시간과 자원을 두배로늘리는 것)하지 않는다고 말합니다. 예를 들어나 네 명의 팀은 두 명의 팀이 커뮤니케이션 하는 것보다 2배 이상의 커뮤니케이션 비용이 들것입니다.
이미 구축되어 있는 시스템의 Sequence Diagram을 자동 생성하는 몇가지 방법이 있는데요.
그중 대표적인 것이 Enterprise Architect 의 Sequence Diagram 생성 기능을 이용하는 것일 겁니다. 하지만 EA는 실제 Debug와 Breakpoint를 걸어가면서 Step by Step으로 일일이 실행해야 되기 때문에, 실제 상황을 만들어 테스트를 해야 합니다. 물론 다양한 언어를 지원하는 것이 큰 강점이지만, Window 플랫폼에 종속되어 있는 단점이 있습니다. (물론 꽁수로 Linux에 돌리는 법도 있긴 있습니다. ) 그래서 EA가 동작하기 힘든 WinCE 기반의 시스템에서는 Sequence Diagram을 추출하기 힘들죠.
Sequen Diagram을 자동 생성하자고 정식 버젼도 아닌 VSTS 2010 을 깔아서 설치하기에는, 개발 환경 문제와 많은 시간이 소요 되기 때문에 할수 없었습니다.
그러던 중 .NET 용으로 툴을 발견했습니다. 바로 SequenceViz라는 툴입니다. 또한 Reflector의 Plug-in도 제공합니다. SequenceViz를 사용하기 위한 환경 구축과 그리고 숨겨진 기능을 공유하고자 합니다. 저 같이 .NET 2.0 버젼을 유지해야 되는 애매한 상황에서는 그럭 저럭 쓸만한 (?) 툴인 것 같습니다.
저와 같이 PLoP을 참여한 고 상원 군이 저와 는 다르게 저자 워크샾을 지켜 보았다고 합니다.
더 나은 저자 워크샵 진행 방법을 만들기 위해 참가자와 조정자의 진행 방식등을 분석했다고 합니다. 파리(저자)의 또 다른 시선이니 저자 워크샵을 진행하시는 분은 참고하시면 도움이 될듯 합니다.
아래의 메세지는 고상원 군의 포스트인 “저자 워크샾에 대한 관찰”에서 가져왔습니다. 참고하시길 바랍니다.
고상원 군 says…
얼마 전, 또 한번의 저자 워크샵을 가졌습니다. 이번엔 논문 내용에 대한 것보다 저자 워크샵 자체에 포커스를 맞춰서 메모를 했습니다. 저자 워크샵을 도입하려면 어떻게 반응하고, 어떤 문제점을 가지는지 고민할 필요가 있다고 생각했기 때문입니다.
오늘 Rebecca의 강의를 들은 후, 아는 분과 설계와 구현간의 gap에 대한 이야기를 들었습니다.
아무리 좋은 설계라도, 개발자가 전혀 다르게 구현한다면. 어떻게 해야 할까요? 그리고 RTC와 같은 좋은 툴들이 보급된다고 해서 과연 이러한 문제가 해결될까요? 이러한 툴에 맞게 개발 문화가 정착된 회사가 한국에 몇이나 있을까요? 형식적인 것이 아닌, 진정한 개발 문화가..
솔직히 이런 문제는 한국에서개발자 대비 QE의 비율이 너무 빈약해서, 스펙에 맞게 잘 구축된 테스트 환경도 찾아보기 힘들고, 실제 현장과 동일한 환경 또한 만들기 쉽지가 않습니다. 이러한 것이 선행되어 강력히 제약을 가해야, 비로서 올바른 구조가 될듯 한데. 참으로 어려운 이야기인것 같습니다. 거기다 Requirement 변경이 빗발치는 SI에서는말이죠. Owner의 말한마디로.. 되는 경우도 종종 있지만요.
이러한 하소연은 하루 이틀 나온 애기도 아니고, 정말 이땅의 많은 Manager와 Architect가 싸워서 합리적인 문화와 구조를 만들어야 가능하지 않을까요? 이런 현실과 부딪혀 이기기가 쉽지 않다고 생각이 들기도 합니다. 그래도 다 같이 머리를 맞대고 도전해 봐야죠.
PLoP에서 수많은 거장들을 만났습니다. 거장들중 우리나라에 그리 많이 알려지지 않은 분들을 하나씩 소개할려고 합니다. 왜냐면 이들의 연구분야들을 하나씩 소개하는 것이 어떤 분들에게는 귀중한 정보다 될것이고, 많은 도움이 될거라고 생각이 듭니다.
Robert Hanmer씨는 이번에 저희 Half-Push/Half-Polling 패턴의 목자 (Shepherd) 이셨습니다. (PLoP에서는 패턴을 제출하면 완성도 있는 패턴을 한번 거른다음, 각 패턴다마 패턴을 잘 쓸수 있게 목자(멘토)를 지정해 줍니다. 그럼 목자와 함께 계속 애기를 나누면서, 패턴들을 수정해 나가는 거죠. 그 이후 저자 워크샾을 통해 한번 더 다듬게 되고, 최종 논문이 완성됩니다.)
PLoP의 BootCamp를 수년간 Linda Rising과 이끌고 있었고, 상당히 부드럽고 배려심이 많으신 분입니다. 이하 Bob 아저씨(Robert를 다 Bob이라고 부릅니다)는 현재 Alcatel-Lucent (Lecent Technolgies and AT&T)라는 Telecomunication 회사에서 Consulting Member로 근무중이며, 고 수준의 가용성(availiability)를 보장하는 시스템을 꾸준히 만들어 오셨습니다.
이러한 패턴들은 고수준의 품질을 요구하는 제조업과 아주 밀접한 연관이 있으므로, 국내 제조업에 종사하는 소프트웨어 개발자에게는 상당히 도움이 될만한 서적이라고 생각됩니다. 그리고 인사이트에서 판권을 확보하고 현재 번역중이라고 하니 조만간 번역서를 만나 보실 수 있으리라 생각이 듭니다.
저희 EVA 네 식구 (현종님, 지원군, 민정님, 희정양, 정민군)와 함께 Half-Push/Half-Polling 패턴에 대해서 또 한번의 저자 워크샾을 가졌습니다. POSA2에 대한 이해도가 PLoP에 있는 분들보다는 높기 때문에, 좀더 수월하게 Writer’s Workshop이 진행될 수 있었던 것 같습니다.
재미난 것은 PLoP에서 받은 피드백과 유사한 내용도 많았고, 다양한 의견도 많이 나와 도움이 많이 되었습니다.
이번 PLoP에서 인상 적인 화면 하나는 바로 이것입니다. 바로 실시간으로 행사에 대한 피드백을 주고 받았다는 것입니다.
대부분의 행사는 행사가 끝난후에, A4 종이 한장에 조그만 칸에 불만 사항을 적습니다. 그리고 조금 더 진보한 상황은 이렇게 포스트 잇을 붙여서 자유롭게 그 의견을 말하게 해주는 겁니다. 몇몇 행사가 이런 형태를 취하고 있더라고, 바로 바로 그 피드백을 받고 대응하지는 않습니다. 물론 하는 분이 있으시다면,정말 멋있는 방법을 사용하시고 잇는 겁니다.
PLoP에서는 불만 사항들을 될수록 수정하도록 노력했으며, 못하는 상황에서는 이유를 충분히 설명해 주었습니다. 조그만 3시간 짜리 세미나라면 적용하기 어렵겠지만, 1~2일을 통째로 쓰는 워크샵이라면 충분히 의견을 주고 받는데 도움이 될거 같습니다. 그때 그때 피드백을 바로 받을 수 있으니깐요. 🙂
나중에 PaperMeeting이나 KPLoP 같은 행사를 진행할 때 꼭 써봐야 겠습니다.
Architecture 101 