우리는 종종 소프트웨어 공학을 고층빌딩,댐 또는 도로를 만드는 것에 비유하는 것을 들을 수 있습니다. 몇몇 중요한 측면에서는 사실입니다.
도시 공학에서 가장 어려운 부분은 한번에 완성되는 빌딩을 설계하는 것이 아니라, 건축 과정을 이해하는 것입니다. 건축 과정은 황량한 땅에서 완공된 빌딩까지 진행됩니다. 그 사이에, 모든 작업자는 각자의 업무를 책임감을 가지고 수행할 수 있어야 하며, 모든 공사기간 동안 완공되지 않는 구조체는 지탱해야 합니다. 우리는 거대한 통합 시스템(완공된 빌딩)을 배포하는 시점에서 교훈을 얻을 수 있습니다. (여기서 “통합”이란 단어는 거의 모든 엔터프라이즈 및 웹 어플리케이션을 포함합니다.!)
전통적인 “빅 뱅(big bang)” 1방식의 배포는 대들보(집과 지붕을 받치는 큰 보)와 들보(하중을 지탱하는 구조물 ) 더미를 쌓아 올려, 높이 올린 다음(공중으로 집어 던진 다음), 건물 형태대로 잘 이어 붙기를 기대하는 것과 같습니다.
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 아주머니가 보낸준 멜로 인해 AsianPLoP이라는 것이 열린다는 정보를 받았고, 충동적으로 지원을 했습니다. 논문이 accept 되었지만, 정말 운인것 같습니다.
이번 PLoP은 Piggyback 패턴(큰 행사뒤에, 연이어 작은 행사를 여는 패턴 – 참가자들이 쉽게 모이기 하기위한 패턴)의 일환으로, 일본의 가장 큰 소프트웨어 공학 학회인 GRACE와 함께 열렸습니다. 우리나라로 하면 정보처리학회 정도 될듯 합니다.
장소는 소프트웨어 진흥원과 유사한 NII(Nataional Institute of Informatics) 라는 곳(진보쵸)에서 열렸습니다. 참가비및 행사비는 일체 무료였습니다.
제가 참가한 프로그램을 중심으로 AsianPLoP을 소개하고자 합니다. 이번 행사는 영어권, 그리고 일본권으로 나누어 진행이 되었습니다. 일본은 일본인 끼리 진행하는 행사가 되어 버렸고, 반대로 영어권은 말 그대로 영어권 사람들이 모였습니다. 미국, 호주, 인도, 그리고 일본 조금, 한국 조금 이렇게 두가지 그룹으로 나뉘어 저자 워크샾이 진행되었습니다.
역시 언어로 인해 소통의 제약을 받는 것은 일본도 마찬가지 인가 봅니다. 아시아 권의 씁쓸함을 같이 느낄 수 있는 행사였죠.
이 책의 저자인 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 (구루를 자신의 편으로 가지고 있는) 사람과 매니저와 다른 개발자들을 위한 새로운 아이디어를 평가하는데 흥미를 가진 동료들을 모아라.
일전에 AsianPLoP에 대해 소개해 드린적이 있는데요. 운좋게 논문이 Accepted 되어서 가볼려구 합니다.
제가 만든 패턴은 아니구요. 회사의 김성 책임님이 만든 아이디어를 저와 다른 분이 잘 다듬어서 논문으로 제출했고, 통과되었습니다. 개인적으로 영어적인 문제를 많이 해결해 주신, James Chang 님에게 감사드립니다.
“아키텍트가 알아야 할 97가지 것들” 에서 저에게 가장 와 닿는 에피소드입니다. 기술도 중요하지만, 더 중요한 것은 기회를 잡을 수 있냐다 라는 말이 너무나 가슴깊이 와 닿았습니다. 결국 사람들과 어떠한 관계를 가지느냐에 따라, 그 모듈의 관계 역시 정해 지는 거죠. 기술 매우 중요하지만, 그것 보다는 어떻게 팀원들과 하나되어 서로의 단점을 상쇄시키고, 장점을 강화 시킬수 있을까요? 이게 요즘 저의 가장 큰 숙제인거 같습니다.
지금 이순간에도 실패한 급여 시스템 프로젝트를 진행하고 있는 사람이 아마 한 명 이상 있을 것입니다.
왜 그런걸까요? 자바 대신 루비를 선택하거나, Smalltalk 대신 파이썬을 선택했기 때문일까요? 혹은 오라클 대신에 포스트그레스를 사용하기로 결정했기 때문일까요? 혹은 리눅스를 선택했어야 했는데 윈도우를 선택했기 때문일까요?
실패한 프로젝트에서 사용한 기술이 전락하는 것을 우리 모두는 보아왔습니다. 하지만 문제가 정말 해결하기 너무 어려워서 자바가 해당 업무에 적합하지 않았다라는 것은 무엇을 의미하는 것일까요?
대부분의 프로젝트들은 사람에 의해 만들어지며, 사람들은 성공과 실패에 대한 기반이 됩니다. 따라서, 사람들을 성공할 수 있게 만드는데 도움이 되는 것에 대해 생각해 볼 필요가 있습니다.
한편으로는, “단지 일을 올바로 하지 않고” 프로젝트를 어렵게 하는 누군가가 있다는 가망성에 대해 충분히 생각해 볼 수 있습니다.
한동한 블로깅이 뜸했던 이유들이 많이 있었습니다. 그중 하나가 바로 책 번역 다듬기 작업이었습니다. 거의 3주간 아무것도 못하고, 새벽과 틈틈이 시간을 쪼개며, “모든 소프트웨어 아키텍트가 알아야할 97가지”(가제)의 1차 역자 교정을 마쳤습니다. 정말 홀가분 하네요 🙂
저의 체력이 예전만큼은 안되구나.. 라는 것도 깨닫고, 번역투보다는 부드럽게 전달하기 위해 의역도 많이 넣었습니다. EVA 식구 분들이 자발적으로 너무 많은 도움을 주셔서 가능한 일이였습니다. 너무나 감사합니다. EVA 분들 감사합니다!!
이 책을 다듬고, 다시 씹고 씹어 읽으니 너무나 와 닿는 글 들이 많았습니다.
Half-Push/Half-Polling의 최종본을 공유합니다. 올해 정말 저에게 값진 선물은 PLoP에 참가해 여러가지 문화를 배울수 있었다는 점입니다. 또한 많은 유명 Architect를 만남으로써, 앞으로의 가야할 길과 협력의 중요성을 크게 깨닫게 되었습니다.
제가 패턴 저자가 되었다는 기쁨은 이루 말할수 없습니다. 다른 학회와 달리 논문만 발표하면 끝이 아닌 학회라, 저자 워크샾때 받았던 피드백으로 논문의 내용을 개선해야 했고, 겨우 겨우 최종본이 나왔습니다. TPLoP이라는 PLoP 저널에 실릴지는 모르겠지만, 최종본을 제출했습니다.
Home Networking이 아파트에 들어가는 것을 이해하지 못하는 서구권 문화 때문에 Office Automtation 으로 예를 바꾸고, 패턴의 Context를 좀더 이해하기 쉽게 하기 위해서 배경지식(Backgroud)과 Context를 좀더 명시적으로 적었습니다.
이 논문이 나오기 까지 많은 분의 노력에 감사드립니다. 결코 저 혼자만의 노력으로 나올 수 없는 논문이었습니다.
Architecture 101 