마소 (마이크로 소프트웨어 ) 2월호에 “조직을 변화시키는 패턴 이야기“라는 주제로 글을 기고했습니다.
지금까지 블로그를 통해 공개한 Fearless Change 포스트를 거의 그대로 올린겁니다. 이미 저의 블로그를 구독하시는 분에게는 싱거운 자료지만, 자료 공유 차원에서 올립니다. 많은 분들에게 도움이 되었으면 하네요 🙂
물론 기고한 글은 모두 저의 지식이 아니며, Linda Rising의 지식과 다양한 분야의 경험을 가진 저희 EVA팀의 지식으로 만들어진 자료입니다. EVA 팀이 없었다면 이렇게 좋은 자료가 나온다는 것은 불가능했을 겁니다. EVA팀 감사합니다.
설마 하고 PLoP 사이트를 방문했는데. 오늘 즐거운 소식을 발견했습니다. 혹시나 해서 연도만 바꿔서 쳤는데.. PLoP 2010 Conference 페이지에 접근이 되네요.
OOPSLA가 SPLASH 라는 이름으로 바뀌게 되고, 2010년도에 연이어 Reno(리노)에서 열린다고 합니다.
“아키텍트가 알아야 할 97가지 것들” 에서 저에게 가장 와 닿는 에피소드입니다. 기술도 중요하지만, 더 중요한 것은 기회를 잡을 수 있냐다 라는 말이 너무나 가슴깊이 와 닿았습니다. 결국 사람들과 어떠한 관계를 가지느냐에 따라, 그 모듈의 관계 역시 정해 지는 거죠. 기술 매우 중요하지만, 그것 보다는 어떻게 팀원들과 하나되어 서로의 단점을 상쇄시키고, 장점을 강화 시킬수 있을까요? 이게 요즘 저의 가장 큰 숙제인거 같습니다.
지금 이순간에도 실패한 급여 시스템 프로젝트를 진행하고 있는 사람이 아마 한 명 이상 있을 것입니다.
왜 그런걸까요? 자바 대신 루비를 선택하거나, Smalltalk 대신 파이썬을 선택했기 때문일까요? 혹은 오라클 대신에 포스트그레스를 사용하기로 결정했기 때문일까요? 혹은 리눅스를 선택했어야 했는데 윈도우를 선택했기 때문일까요?
실패한 프로젝트에서 사용한 기술이 전락하는 것을 우리 모두는 보아왔습니다. 하지만 문제가 정말 해결하기 너무 어려워서 자바가 해당 업무에 적합하지 않았다라는 것은 무엇을 의미하는 것일까요?
대부분의 프로젝트들은 사람에 의해 만들어지며, 사람들은 성공과 실패에 대한 기반이 됩니다. 따라서, 사람들을 성공할 수 있게 만드는데 도움이 되는 것에 대해 생각해 볼 필요가 있습니다.
한편으로는, “단지 일을 올바로 하지 않고” 프로젝트를 어렵게 하는 누군가가 있다는 가망성에 대해 충분히 생각해 볼 수 있습니다.
한동한 블로깅이 뜸했던 이유들이 많이 있었습니다. 그중 하나가 바로 책 번역 다듬기 작업이었습니다. 거의 3주간 아무것도 못하고, 새벽과 틈틈이 시간을 쪼개며, “모든 소프트웨어 아키텍트가 알아야할 97가지”(가제)의 1차 역자 교정을 마쳤습니다. 정말 홀가분 하네요 🙂
저의 체력이 예전만큼은 안되구나.. 라는 것도 깨닫고, 번역투보다는 부드럽게 전달하기 위해 의역도 많이 넣었습니다. EVA 식구 분들이 자발적으로 너무 많은 도움을 주셔서 가능한 일이였습니다. 너무나 감사합니다. EVA 분들 감사합니다!!
이 책을 다듬고, 다시 씹고 씹어 읽으니 너무나 와 닿는 글 들이 많았습니다.
Half-Push/Half-Polling의 최종본을 공유합니다. 올해 정말 저에게 값진 선물은 PLoP에 참가해 여러가지 문화를 배울수 있었다는 점입니다. 또한 많은 유명 Architect를 만남으로써, 앞으로의 가야할 길과 협력의 중요성을 크게 깨닫게 되었습니다.
제가 패턴 저자가 되었다는 기쁨은 이루 말할수 없습니다. 다른 학회와 달리 논문만 발표하면 끝이 아닌 학회라, 저자 워크샾때 받았던 피드백으로 논문의 내용을 개선해야 했고, 겨우 겨우 최종본이 나왔습니다. TPLoP이라는 PLoP 저널에 실릴지는 모르겠지만, 최종본을 제출했습니다.
Home Networking이 아파트에 들어가는 것을 이해하지 못하는 서구권 문화 때문에 Office Automtation 으로 예를 바꾸고, 패턴의 Context를 좀더 이해하기 쉽게 하기 위해서 배경지식(Backgroud)과 Context를 좀더 명시적으로 적었습니다.
이 논문이 나오기 까지 많은 분의 노력에 감사드립니다. 결코 저 혼자만의 노력으로 나올 수 없는 논문이었습니다.
오늘 Linda Rising 아주머니에게 Fearless Change를 번역하고 있다고 말씀드렸습니다. 또한 저희 스터디 팀을 위해서 Comment를 남겨 달라고 했는데요. 남겨주셨네요 :). 제가 저희 스터디의 사진과 posting된 글을 공유해 드렸습니다.
다음과 같은 답변이 왔습니다.
Thank you for the information on your study group.
The pictures are great!
It looks like you are having fun and using the pattern “Do Food” :-)!
It’s exciting to hear that you are translating the book to Korean.
That will make the patterns available to others who don’t read English as well as you do!
I’m attaching two papers that Mary Lynn and I have written with some new patterns for change.
I hope you enjoy them.
All the best to you and the members of your study group!!!!
변화를 시작할 수 있다는 열정, 마음가짐을 가졌다면, 이제 조직에 변화를 가져올 수 있는 작업을 해야 합니다. 바로 사람을 얻는 것이지요.
나의 사람을 만들고, 같이 생각을 나누어 점진적으로 혁신의 생각을 전파해 나가는 것입니다. 큰 전략은 다음과 같습니다. 인맥이 넓은 Connector를 통해 Guru를 만나 나의 아이디어와 생각을 다듬어 신뢰성을 확보하고, 나의 상사인 Local Sponsor, 높게는 고위층인 Coporate Angel에 지지를 얻습니다. 그리고 Connector를 통해서 Innovator 성격의 사람을 찾아 내어 변화를 만들어 내자는 것이 목적입니다.
Linda Rising 아주머니께서 AsianPLoP 2010이 열린다는 멜을 보내주셨습니다.
아시아권에 유일한 PLoP 행사인 Mensore PLoP이 한동안 진행되지 않았는데. 드디어 새롭게 AsianPLoP 이라는 이름으로 처음 진행됩니다.
어디서 부터 변화를 시작해야 할까요?
그건 바로 마음가짐일 것입니다. 내 자신이 변화를 전파하는 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 