Framework 설계시 가장 중요시 여겨야 하는 것이 사용성이다.
사용자들이 쉽게 사용하고, 생산성에 만족하느냐가 Framework의 생존 여부와 연결되어 있기 때문이다. 쉽게 사용할 수 있는 사용 편의성을 일전에 얘기한 적이 있지만,이 못지 않게 중요한 것이 Framework 사용자가 실수를 하기 어렵게 만드는 것이다. 즉 실수하지 않게 성공의 웅덩이를 만들어서 성공할 수 밖에 없게 만들라는 얘기다.
PLoP10으로 인해 Framework 관련 논문을 작성하면서, .NET과 Java Framework를 설계한 대가들의 공통적인 충고를 들을 수 있었다.
Pattern을 어떻게 하면 잘 만들수 있을까요? Joe 의 패턴 라이팅을 공개합니다.
이번 AsianPLoP에서는 작년에 참여한 PLoP BootCamp와는 조금 다른 형태로 Joe(Joseph William Yoder) 아저씨의 패턴 라이팅(Pattern Writing)을 경험해 보는 좋은 시간을 가졌습니다.
패턴 라이팅을 말하기 전에 Joe 아저씨에 대해서 간략히 소개를 해 드리면, 그는 Refactory Inc. 를 운영하고 있으며, 런타임시에 객체의 생명주기를 관리하는 유명한 패턴인 AOM (Adaptive Object Model) 을 만든 사람입니다. GoF 중 한 명인 Ralph Johnson의 제자 이기도 합니다.
그의 발표자료를 공유합니다. 브라질에서 열리는 PLoP인 SugarLoad PLoP에서 2년전에 이미 발표한 자료네요. 이 자료를 읽기 전에 저의 블로그에 공유한 Linda 아주머니의 Pattern 만드는 법, 또 PLoP에서 소개한 Pattern Template을 먼저 읽어보시길 바랍니다.
Writing Patterns “The Straight Scoop” 다운 받는곳 (출처 SugraLoad PLoP)
패턴 템플릿 설명
이 책의 저자인 Linda Rising은 조그만 Recorder Consort 팀을 이끕니다. 5명이라고 하지만 다 제각기의 다양한 장단점과 개성이 있기 마련입니다.
과연 Fearless의 저자인 Linda는 어떻게 이 팀을 이끌까요? 바로 개별적으로 만나는 것(Personal Touch)입니다.
- Karen은 어렸을때부터, 레코더를 불었기 때문에, 가장 뛰어난 실력자입니다. 그래서, 가장 어려운 부분과 솔루 부분을 맡깁니다.
- Rick은 레코더도 잘 부르지만, 기타와 노래도 잘 부릅니다. 하지만 Rick 은 어러운 부분을 부르는 것을 싫어하며, 튀기 좋아합니다.
그래서 어려운 부분은 Karen에게 다양한 악기 파트는 Rick에게 맡깁니다.
- Anne 와 Karl 은 온화한 성격이며, 적당한 도전을 기쁘게 받아들입니다. 그리고 Anne는 피아노도 잘 칩니다.
Anne와 Karl의 온화한 성품때문에, 합주나 Karen을 뒷받침하는 연주를 부탁합니다.
결국 Linda는 Personal Touch와 Tailor Made 패턴을 이용해, 구성원의 다양한 성격과 장단점을 파악하고, 적합하게 팀을 조율했습니다.
Fearless Change 그 전장 들을 통해 이미 사람도 나의 편으로 만들어 놓고, 자주 소통할 수 있는 상황을 만들었습니다.
이제 다 준비 되었으니 촬영을 시작해야죠! (Take Action)!
A라는 변화나 행위를 하고 싶을때, 부정적인 생각과 피드백을 받을수 도 있지만, 해보지 않고는 모르는 일입니다. 완벽을 너무 추구한 나머지 아무것도 하지 않는 것보다는, 어떠한 행동을 취하면서 실제 느껴 보는 것이 중요합니다.
춤을 배우고 싶을때, 먼저 춤을 쳐보고, Mentor에게 도움을 받는 것이 좋지, 아무것도 안하고 멘토링 받을 수 있을까요?
행동을 취하기 위해서는 다음과 같은 패턴들이 필요합니다.
- Study Group : 서로의 의견을 받아 들이고 발전시켜라!
- Mentor : Study Group에서 먼저 시작한 사람, 경험있는 사람이 Mentor가 되어서 이끈다.
- Just Do It : 무언가 하면서 해라!!
매니저들은 내가 새로운 아이디어를 언급할 때마다, “안 돼! 또 다른 은 총알은 없어!” 라고 보는 것 같았다. 그러나 매니저들 중 한 명은 나의 아이디어에서 꼭 지켜야 할 것은 무엇이고? 나의 아이디어에서 중요하지 않는 (지저귀는 새소리) 것이 무엇인지 물어봤다.이러한 질문 방법에 나는 감탄했다.
관리자 들은 조언을 구하기 위해 하나의 아이디어를 두 개의 개별적인 것(장점과 단점을 비교)으로 본다는 것이다.
그래서 나는 모든 매니저에게, 아이디어를 검증하는 팀을 만들 수 있게 도와달라고 요청했다. 각각의 매니저들은 자기 팀에서 한 명의 검증 자를 임명했다. 어느 날 오후에 그 팀을 만났을 때, 나는 짧은 프레젠테이션을 한 다음,질문에 답변을 했다. 나는 필기하고 보고서를 작성했다. 그리고 보고서를 경영진에 전달하기 전에, 임명된 검증 자들의 동의를 얻었다.
이러한 활동은 혁신이 가지는, 장점들을 경영진에 설득하게 만들었을 뿐만 아니라, 내가 생각지도 못한 몇몇 이슈들을 발견하게 되었다. 생각해보면, 경영진이 심지어 회의적인 사람일지라도, 검증 팀은 모든 관련된 혜택으로 경영진들을 자기 주장에 끌어들였다.
Guru on Your Side (구루를 자신의 편으로 가지고 있는) 사람과 매니저와 다른 개발자들을 위한 새로운 아이디어를 평가하는데 흥미를 가진 동료들을 모아라.
나의 의견에 동조하는 사람들이 모였다면, 이제 풍성한 모임을 만들어 변화를 가져오는 전략을 다듬고 수립하는 것(Meeting and More)입니다.
회의를 통해 사람들과 협업하여 성과를 만들어 내고, 바쁘거나 특별히 만냐야 하는 중요한 사람들은 개별적으로 만나 신뢰성과 비젼을 끊임없이 공유함으로써, 사람과의 관계를 돈독히 하기 위한 패턴을 설명하고 있습니다. 즉 이메일 보다는 직접 식사와 함께 만나면서 서로의 비전을 공유해 나간다는 겁니다.
변화를 시작할 수 있다는 열정, 마음가짐을 가졌다면, 이제 조직에 변화를 가져올 수 있는 작업을 해야 합니다. 바로 사람을 얻는 것이지요.
나의 사람을 만들고, 같이 생각을 나누어 점진적으로 혁신의 생각을 전파해 나가는 것입니다. 큰 전략은 다음과 같습니다. 인맥이 넓은 Connector를 통해 Guru를 만나 나의 아이디어와 생각을 다듬어 신뢰성을 확보하고, 나의 상사인 Local Sponsor, 높게는 고위층인 Coporate Angel에 지지를 얻습니다. 그리고 Connector를 통해서 Innovator 성격의 사람을 찾아 내어 변화를 만들어 내자는 것이 목적입니다.
어느 날 저는 은행 점장에게 자신이 운영하는 지점을 성공할 수 있게 하기 위해, 그가 무엇을 했는지 물어보았습니다.
“글쎄” 점장이 대답하길. “나는 나의 주업무가 직원들을 지원하는 것이라고 믿습니다. 직원들이 일을 할 때 직원들을 방해하는 모든 장애물을 제거하고 대처 수단을 발견하는 것이지요.”
가장 가까운 일선 경영층에 도움을 요청하십시오. 만약 여러분의 상사가 새로운 아이디어를 도입 할려는 당신의 작업을 지원한다면, 당신은 훨씬 효율적으로 조직에 아이디어를 도입할 수 있을 겁니다.
여러분이 조직에 새로운 아이디어를 도입하려고 노력하는 Evangelist(144)라고 합시다.
여러분은 새로운 아이디어를 위해 관심과 노력이 필요합니다.
경영층은 일터에서 합법적인 것들을 지원합니다. 몇몇 사람들은 새로운 아이디어를 수용하는 작업 뒤에 경영층이 숨어있다고 생각되지 않는 한, 새로운 아이디어에 열중하지 않습니다. 스폰서 쉽(지원을 하는 여러 행위)은 중요합니다.
어디서 부터 변화를 시작해야 할까요?
그건 바로 마음가짐일 것입니다. 내 자신이 변화를 전파하는 Evangelist가 되어야 하며,열정을 지속적으로 유지 할수 있는 Dedicated Campion되는 것입니다.
성공적인 Dedicated Champion이 되기 위해서는 변화를 주도하는 역할 역시 업무의 부분으로 인정받아야 되는데, 대부분의 기업들이 업무라면, 단순히 개발하거나, 어떠한 성과가 나오는 부분에 초점을 맞추고 있다는 것이 문제입니다.
기업이나 조직에서 변화를 주도하기 위해서는 변화를 이끄는 일, 역시 업무로 인정하는 분위기가 필요합니다. 안되면 Google 처럼 2/8 이라도 해주셨으면..
그리고 변화를 계속해서 잘 주도내 나가고 있다는 것을 보이기 위해서, 무언가 지속적으로 일이 진행된다는 것을 알려야 하며, 또한 잘 평가받기 위해서, 근거와 자료를 뒷 받침하는 자료를 꾸준히 만드는 작업이 필요합니다.
그렇다고 프로세스 대한 도입으로 차츰 차츰 반복되는 실수나, 문제점을 줄어나간다는 것 을 도표로 뽑아내어 예전보다 나아졌다고 평가를 하는 것 보다는, 조직원들이 변화를 인식하고, 이것이 긍정적으로 바뀌고 있다고 팀원들이 다 같이 느끼게 하는 것이 더 중요하곘죠. 하지만 변화를 지지 하는 Coporate Angel(높은 상관)에게 지속적인 지원을 받기 위해서는 이러한 평가자료도 매우 중요합니다.
자 그럼 Fearless Change 에서 언급하는 전략적으로 변화를 시작하는 방법에 대해서 공유해보죠.
내가 설계한 시스템을 과연 개발자가 잘 만들고 있을까? 제대로 된 방향으로 가고 있을까? 우리 시스템이 어디가 꾜여있진 않을까? 진척율을 짝짝 올라가 양은잘 맞추는거 같은데..?
만약 이런 질문을 하고 있는 Architect나 Senior Software Engineer라면, 중간 상황을 어떻게 파악하시나요? 완벽한 대답은 아니지만 최소한 제대로 Architecting의 흐름이 흘러가는지 파악하는 좋은 툴중 하나인 DSM (Dependency Structure Matrix) 을 소개드리고자 합니다.
일전에 Dependency의 종류를 설명한 Dependency 대한 고찰 과 Dependency를 해결하는 방법을 소개한 Dependency 를 관리하는 방법 사이에 있는 포스트로, 바로 Dependency가 어디에 있는지 분석하자는얘기입니다. 문제 제기와 해결책은 제시했는데, 사실 Dependency를 파악하는 방법에 대한 이야기를 전해드리지 못했습니다. 이제서야 이야기를 꺼내게 되네요.
이 포스트는 2005년 OOPSLA에서 발표된 Paper인 “Using Dependency Models to Manage Complex Software Architecture”의 내용을 약식 정리한 것입니다.
Architecture 101 