지난 주말 (2012년 5월 20일) 코엑스에서 스마트 개발자 협회가 주관하는 글로벌 커뮤니티 써밋에 EVA 커뮤니티 연사로 발표를 했습니다.
먼저 이번 발표에 많은 도움을 준 소프트웨어 마에스트로 멘티인 오유환, 강미경, 김나래, 손윤정 4 멘티에게 감사드립니다. 이 4명이 아니였다면 이러한 좋은 자료는 나오지 못했을 겁니다.
프리젠테이션이 다루는 내용은 다음과 같습니다.
Android 이해
- 구글이 꿈꾸는 Android의 미래 (Modu 사 특허 인수와 Android@Home)
- Binder ( Broker 패턴 )과 Intent
오픈소스 그리고 사례
- Simple Framework
- Logcat보다 Microlog4Android
- 불편하지 않은 화면 갱신 (Publisher-Subscriber)
분석 방법
- Localytics로 사용자 행동 패턴 분석
- STAN을 이용한 Android App 분석방법
이번 발표는 소프트웨어 마에스트로 멘토로 활동하면서, 멘티들과 같이 만들어 낸 작품입니다. 비록 여러가지 상황(취업, 학업등)으로 모든 멘티가 다 2단계에 진출은 하지 못했지만, 지금도 열정을 내뿜으며 같이 성과를 만들어내고 좋은 팀웍을 유지하고 있습니다.
지표란 직접 경험을 하지 않아도 현재의 상황을 알수 있는 도구를 말합니다. 옛날 제주도에서는 식수가 귀해 빗물을 식수로 사용을 했습니다. 빗물의 오염도를 파악하기 위한 지표로, 개구리 (숫놈끼리만 넣거나, 암놈끼리만 넣거나)들을 넣었다고 합니다.
개구리 들이 벌레들을 잡아먹어 물이 항상 청결한 상태를 유지할 수 있었으며, 또한 개구리의 생존 여부로 물 오염도를 파악을 할수 있기 때문입니다.
일전에 소프트웨어 품질을 판단하는 지표로, 1000 피트의 뷰 라는 글을 소개해 드렸습니다. 너무 상세하지도 않고, 너무 추상화되어 있지도 않은 그 사이의 뷰를 1000 피트의 뷰라고 불렀습니다.
이러한 지표중 하나로, 예전 저의 포스트에서 Dependency Structure Matrix (DSM) 을 소개해 드렸습니다.
이번 포스트는 이러한 연장선상으로 Clean Code로 유명하신 Robert C. Martin (줄여서 Uncle. Bob)님이 만드신 Instability/Abstractness Graph 하나를 설명해 드리고자 합니다. (이 그래프에 대해 국내에 명확하게 소개된 자료가 없어서, 꼭 여러분에게 공유를 해드릴려고 합니다. )
이 포스트를 읽기 이전에 Bob 삼촌이 발표하신 패키지 구조의 원칙들(Principles of Package Architecture) 을 읽어보시거나, 또는 저의 이전 포스트인 Dependency를 관리하는 방안 을 읽어보시길 바랍니다.
Uncle Bob의 지표는 Instability와 Abstractness 두 개에 대해 이해를 하셔야 합니다. 물론 여기에 추가적인 지표를 더한 변종(Variant) 들도 있지만, 이 두 가지 개념을 확실히 이해하실 필요가 있습니다.
저는 원하는 것을 말하지 않아도 될만큼 만족하고 있는 고객을 만나본 적이 없습니다. 대부분 그들은 엄청나게 세세한 부분까지 이야기 합니다. 문제는 고객들이 항상 모든 진실을 이야기하지 않는다는 것입니다. 그들은 보통 거짓말을 하지 않습니다만, 고객의 관점에서 말할 뿐 개발자의 관점으로는 이야기 하지 않습니다. 그들은 그들만의 용어를 사용합니다. 그들은 중요한 세부사항들은 생략합니다. 그들은 마치 여러분도 그들처럼 그 회사에서 20년동안 근무했다고 생각하는 것 같습니다.
거기에다가 많은 고객들이 처음에는 정말로 원하는 것이 무엇인지 모른다는 사실까지 더해집니다! 고객들중 일부는 ” 큰 그림”을 파악하고 있을 수도 있겠지만, 그들이 보고 있는 “큰 그림”에 대한 세부사항을 효과적으로 전달할 수 있는 경우는 흔치 않습니다. 다른 사람들은 전체그림에 대해서는 얕은 지식을 가졌을 수도 있지만, 그들이 원하지 않는 것이 무엇인지를 알고 있습니다.
그러므로, 무엇을 원하는지에 대한 전체의 진실을 여러분에게 말해주지 않는 누군가에게 어떻게 소프트웨어 프로젝트를 제공할 수 있겠습니까? 그것은 매우 간단합니다. 그들과 더 많이 접촉해야 합니다.
얼마전 이대엽님이 도메인 주도 설계 (Domain Driven Design) 라는 명서를 번역해 주셨습니다. 저 역시 구매를 했었고, DDD가 가져오는 철학이나 사상은 정말 훌룡합니다.
왜 이런 명서가 이제 번역될수 밖에 없는지 현실을 알고 있지만, 정말 슬픕니다.
POSA나 DDD와 같은 명서들은 번역을 한다는 것의 거의 희생에 가깝습니다.
사실 역자 입장 에서는 적절한 어휘 선정과, 국내 개발자의 시선에 맞게 레벨을 조정하기 위해 각주를 다는등 여러가지 노력이 필요합니다.
또한 책이 많이 팔릴지도 의문이고, 이미 읽을만한 분은 다 읽었다고 생각이 들고, 나의 안티를 양성하지 않을까 고민이 됩니다.
실례로, 몇몇 출판사를 통해 “명서를 왜 이렇게 번역했느냐?”라며 여러가지 공격을 당한 사례들을 종종 들었기에 쉽게 움직이지 못하는 것도 사실입니다.
이러한 상황에서도 DDD가 이 세상에 나오게 해주신 이 대엽님과 여러 고생해 주신 분들에게 감사를 드립니다.
다시 본론으로 돌아와 DDD는 고객과 개발자/아키텍트 간에 대화를 나눌수 있는 좋은 도구입니다.
패턴 계의 철학을 생각해 보면, 모든 상황에 만능인 솔루션은 없다. 단지 상황에 맞는 해결책이 있다는 것을 생각해 볼 필요가 있습니다. 그러기에 해당 Context들이 대부분 도메인과 밀접한 연관이 있고, DDD의 초안이 PLoP 에서 첫 데뷔를 했기 때문에 역시 그 본류는 패턴의 철학과 맞 닿아 있는 방법입니다.
그럼 DDD를 프로젝트에 적용하기 이전에, 고려해야 할 것들 이야기 해보고자 합니다. 어떠헌 프로세스, 툴들에게도 동일하게 적용된느 철학입니다. 맹목적인 추종보다 결국 상황에 맞는 솔루션이라는 것을 기억해 주셔야 됩니다.
이번 저자 워크샵은 정말 힘든 강행군의 연속이었습니다.
PLoP 2011의 의장인 Lise Hvatum 과 2일에 거쳐 패턴을 같이 다듬었습니다. 사실 이번 PLoP에는 저희가 바쁜 일정에 논문을 잘 쓰지 못해서 논문을 같이 다듬는 Writing Group으로 배정을 받았는데, 오히려 많은 것을 배운거 같습니다.
같이 논문을 써준 김 지원님이 같이 간 덕분에 외롭지 않고, 이래 저래 정리한 내용도 2배로 늘어났습니다. 
결과적으로 좀더 Clear하게 그리고 Simple 하게 전체적으로 패턴을 바꾸었습니다. 첫째날 차 유리가 깨지고 지원이가 노트북을 읽어 버리는 바람에 사고 수습하느라 하루가 날라가 버리고, 남은 2일동안 강행군을 펼쳤고, 마지막날 새벽 4시에 겨우 마쳐서 최종본을 보냈슴니다.
지원가 맘고생도 많았지만, 이 잃어버린 노트북만 아니였어도.. 이렇게 고생을 하지않았을 텐데… 마지막날에 발표한 자료가 pdf 로 변환하면서 몇몇이 깨져버려 이래 저래 고생을 가장 많이한 PLoP 입니다.
Lise에게 보여주니, 새벽 4시에 온 메일을 보고 놀랐다고,정말 용감했다고 하더라구요! 좀더 명확하고 간결해졌다고 피드백을 받았습니다.
저자 워크샵
저자 워크샵이 무엇인지 모르시는 분은 제가 일전에 포스팅 한 저자 워크샵 데모 포스트를 보시고읽어보시면 좋을듯 합니다.
(중앙에 있는 분이 PLoP 11 Chair이자 , 저희 논문 Shepherd였던 Lise Hvatum , 그리고 오른쪽에 있는 분이 AsianPLoP의 리더이자, 와세대 대학의 조교수이신 Hironori Washizaki 입니다.)
실제 저희 워크샵에서 받은 내용을, 지원이가 잘 정리해 주었습니다. 추후 mp3를 듣고 더 업데이트 할 생각입니다.
Fearless Change란 조직의 변화를 이끌어내고, 사람과 함께 소통하게 만드는 패턴입니다. 물론 이 패턴들도 상당히 장,단점이 있어서, 적절히 활용하시는게 바람직합니다. Fearless Change 패턴을 만들어 낸, Linda Rising 님의 성품과 사람을 이끌어 내는 힘은 정말 존경받을 만한 일입니다. 현종님의 경험이 담긴 Fearless Change를 공개하겠습니다!! 이 자료의 모든 저작권은 김현종 님에게 있습니다. 또한 EVA 이름으로 일전에 마이크로 소프트웨어에 기고한 글들을 […]
패턴계에서는 절대적으로 내려오는 한가지 격언이 있습니다.
Pattern isn’t an island. 패턴은 섬이 아니다.
패턴이라는 것은 크게는 Architecture을 결정하기도 하며, 그 밑에 Design을 결정하는 중요한 역할을 합니다. 즉 패턴간에 서로 깊은 연관성을 가진다는 것 입니다.
일전에 제가 다녀왔단 PLoP Bootcamp 포스트에서 Fault Tolerance 패턴의 저자인 Bob Hanmer가 Problem/Solution에서 언급한 패턴 언어를 참고하시기 바랍니다.
위 그림을 예로 들면 통신시 신뢰성을 확보하기 위해 IO GateKeeper라는 Monitor를 통해 데이터를 거쳐가게 만들었지만, Source/Destination/메세지의 순서등을 구분하기 위해 Token (Time + Mac Address + Handler 정보) 인 IO Triage 이용하게 되고, IO Triage를 구축하기 위해 내부적으로 Timestamp를 사용하는 모습이 보입니다.
즉 거대한 아키텍쳐적인 결정이든, 그 밑에 세분화된 설계에 대한 결정들이 개별적으로 결정되는 것이 아니라, 서로 간에 영향을 미치며 결정된다는 것입니다.
작년에 Kent Beck님은 세미나에서 이러한 말을 했습니다.
“Design is an island‘ (설계는 섬이다.)
패턴을 몰랐다면 이러한 말이 별로 도발적으로 들리지 않았겠지만, 패턴계에서 늘 원칙처럼 언급하던 패턴이 가져오는 Side Effect를 중화시키기 위해 다른 해결책으로 또 다른 패턴들이 도입되는 그림을 늘 봐온 저로서는 도발적인 정의였습니다.
두번째 고객 소통 패턴을 여러분과 공유합니다.다시 한번 손정민, 변현규, 문준석, 송은진 4 친구에게 정말 감사함을 표합니다!
소통은 사회적 관계를 형성하기 위한 핵심 매개체 중 하나다. 바쁜 현대사회에서 페이스북이나 트위터 등 소셜 네트워크 서비스(SNS)를 이용해 소통의 끈을 이어가는 사람들을 보면 소통이 인간의 기본욕구라는 것을 명확히 알 수 있다.
그렇다면 소통은 단지 사람과 사람사이에서만 성립되는 것일까? 필자는 기업과 고객의 관계에서도 소통이라는 명제가 성립할 수 있다고 생각한다. 이번 기고에서는 애자일과 패턴의 대가인 Linda Rising이 발표한 ‘고객과 소통하는 패턴’을 국내 실정에 맞게 의역했다.
이전 기고에서는 “고객 = 돈줄”이 아닌 “고객 = 사람”, 즉 “판매가 아니라 관계다(It’s a relationship., Not a Sale)”를 시작으로 고객을 파악하고(Know the Customer) 신뢰를 쌓으며(Build Trust) 고객의 말에 집중하는(Listen Listen Listen) 방법에 대해 알아 보았다.
이전 패턴이 고객과 관계를 형성하기 위한 패턴이였다면, 이번에 소개할 패턴은 형성된 관계를 발전시키는데 초점을 두고 있다.
반응하라(Be Responsive).
Aliases : 고객을 벽걸이처럼 내버려두지 말고 지속적인 관계를 유지한다.
Problem : 고객요구에 대한 적당한 반응시간은 언제일까?
Context : ‘판매가 아닌 관계다’와 ‘고객을 파악해라(Know the Customer)’를 이해한다. 신뢰 쌓기에 매진하라. 듣고 듣고 또 듣는 자세를 가져라.
Forces : 당신은 고객에게 주의를 기울이기 원하지만 항상 즉각적인 반응을 할 수는 없다. 사무실에 없거나 고객응대 시스템이 다운될 수도 있다.
6월 19일 제 11회 JCO 발표는 저에게 많은 것을 깨닫게 해주었습니다.
청중 여러분들과 정말 기쁘고 재미난 세미나를 했던것 같습니다. 저 역시 정말 신나고 재미있게 발표한 자리여서 여러분들에게 매우 감사를 드립니다.
여러분에게 자료를 공개해 드립니다. (아래 링크로 들어가시면 pptx를 다운 받으실수 있습니다.) JCO 발표용으로 업데이트한 자료들을 최종 반영했습니다.
Framework engineering JCO 2011
이번 행사를 통해 몇몇 느낀 점을 공유할까 합니다. 들은 분의 후기는 많지만, 발표자의 후기는 좀 독특하잖아아요.
지난 Rebecca Wirfs-Brock의 Nature of Order I를 이어 그 다음 이야기를 진행하고자 합니다. 혹시 이전 내용을 못 읽으신 분은 링크를 따라 한번 읽어보시길 권해드립니다.
워낙 방대한 내용이라, 섣불리 글이 써지지 않더군요. 철학과 생명체, 사물 (Thing)의 구성 원칙들을 기술하는 것이다 보니, 농업 / 생명 / 건축등 다양한 것을 예로 들어 설명하고 있습니다. 게다가 너무 철학적이어서, 개발자가 읽기에는 지루할수도 있죠. 아직 책을 다 읽지 못했지만, PLoP에서 정리한 노트내용과 NOO를 SW 설계에 빚대어 설명한 논문들 그리고 저의 부족한 경험을 합쳐서 용기를 내어 써 봅니다.
항상 경청하는 자세로 여러분의 피드백을 받겠습니다. 부족한 부분은 말씀해주시고, 더 좋은 의견을 주시면 관련 자료를 더 찾고 공부해서 NOO 데이터를 계속 업데이트할 욕심은 있습니다.
Architecture 101 