패턴계에서는 절대적으로 내려오는 한가지 격언이 있습니다.
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를 중화시키기 위해 다른 해결책으로 또 다른 패턴들이 도입되는 그림을 늘 봐온 저로서는 도발적인 정의였습니다.
6월 19일 제 11회 JCO 발표는 저에게 많은 것을 깨닫게 해주었습니다.
청중 여러분들과 정말 기쁘고 재미난 세미나를 했던것 같습니다. 저 역시 정말 신나고 재미있게 발표한 자리여서 여러분들에게 매우 감사를 드립니다.
여러분에게 자료를 공개해 드립니다. (아래 링크로 들어가시면 pptx를 다운 받으실수 있습니다.) JCO 발표용으로 업데이트한 자료들을 최종 반영했습니다.
Framework engineering JCO 2011
이번 행사를 통해 몇몇 느낀 점을 공유할까 합니다. 들은 분의 후기는 많지만, 발표자의 후기는 좀 독특하잖아아요.
지난 Rebecca Wirfs-Brock의 Nature of Order I를 이어 그 다음 이야기를 진행하고자 합니다. 혹시 이전 내용을 못 읽으신 분은 링크를 따라 한번 읽어보시길 권해드립니다.
워낙 방대한 내용이라, 섣불리 글이 써지지 않더군요. 철학과 생명체, 사물 (Thing)의 구성 원칙들을 기술하는 것이다 보니, 농업 / 생명 / 건축등 다양한 것을 예로 들어 설명하고 있습니다. 게다가 너무 철학적이어서, 개발자가 읽기에는 지루할수도 있죠. 아직 책을 다 읽지 못했지만, PLoP에서 정리한 노트내용과 NOO를 SW 설계에 빚대어 설명한 논문들 그리고 저의 부족한 경험을 합쳐서 용기를 내어 써 봅니다.
항상 경청하는 자세로 여러분의 피드백을 받겠습니다. 부족한 부분은 말씀해주시고, 더 좋은 의견을 주시면 관련 자료를 더 찾고 공부해서 NOO 데이터를 계속 업데이트할 욕심은 있습니다.
안녕하세요. 많은 분이 기다리고 기다리셨던 “아키텍트가 알아야할 97가지” 가 드디어 나왔습니다. 아직 정식 출간은 아니지만, 예판으로 판매중입니다.
노란북( 책 비교 사이트)에 올라온 “아키텍트가 알아야할 97가지”
이번 “97 아키텍트”는 혼자 어떠한 성과물을 만드는 것보다, EVA 라는 팀의 이름으로 만든 성과물이라는데 깊은 의미를 두고 싶습니다. 누군가 한 말이 생각나네요 ” 빨리가면 대의가 아니다. 대의이기 때문에 느리고, 오래걸린다…” 굳이 대의까지는 아니지만, 느리지만, 더 정교하고, 다양한 시선을 합하느라 더 오래 시간이 걸렸습니다. 베타리더 분들의 도움과 많은 분의 지원과 격려로 만들어진 작품입니다. 많이 홍보해주시고, 널리 퍼뜨려 주시길 부탁드립니다.
SE업계의 장로이신 CMU의 Mary Shaw교수님의 Talk가 한국에서 진행되네요. Mary Shaw 교수님은 David Garlan 교수님과 같이 SE 쪽에서 오랫동안 헌신하신 분입니다.
유명한 서적인 Software Architecture: Perspectives on an Emerging Discipline 저자이시기도 하구요.
이번 세미나는 아쉽게도 그의 연구인 Value-Based Software Engineering 쪽은 아니지만, SE 쪽에서 워낙 입지가 탄탄한 분이라 한번 만나 보시면 좋을거 같습니다.
좋은 SE 논문을 쓰는 방법입니다. SE 관련 학생들/부서에 있으신 분들에게 좋을거 같네요. 개발자 분들중에 어떻게 학습을 하고 글을 쓰는지, 자신의 지식을 표현하느지 관심있는 분도 좋을거 같습니다.
아키텍트로서 성장하기 위한 길은 막막하게 느껴지곤 한다. 누구에게 아키텍트로서 가야 하는 길을 물어야 할 것인가? 산전수전 다 겪은 나이가 지긋한 아키텍트로 활동 중인 사람을 만나기란 하늘의 별따기다. 따라서 필자는 업계 최고의 아키텍트들의 조언을 모아 가상의 인터뷰를 진행해 봤다. 이 인터뷰의 내용은 필자가 PLoP라는 패턴학회에서 만난 해외 거장들과의 토론과 조만간 출간될 번역서인 『아키텍트가 알아야 할 97가지』의 내용을 모아 만들었다.
손영수 안녕하십니까? 여러 선배님들. 아직 ‘Architecture’의 ‘A’자도 깨우치지 못했지만, 여러 선배님들에게 아키텍트로 성장하기 위한 방법과 또 아키텍트로서 올바른 아키텍처를 바라보는 방법들을 여쭤 보고자 합니다. 많은 이들이 궁금해 하는 질문일텐데, 여러 선배님들처럼 훌륭한 아키텍트가 되기 위해선 어떠한 것들을 준비해야 할까요? 실제 현업에서 아키텍팅할 때 어떠한 부분을 고려해야 할지 여러분들의 얘기를 듣고 싶습니다.
Rebecca Wirfs-Brock 국내에는 비교적 많이 알려져 있지 않지만, 정말 현실을 직시하는 몇 안되는 Architect입니다. 일전에 소개 드린것 처럼, 절대 어느 한가지 맞다고, 자기의 설계 기법이나, 방법을 따라야 한다는 몇몇 아키텍트와 달리. 여러가지 해결책을 펼쳐놓고, 주어진 상황에서 적합한 전략/솔루션을 선택하는 아키텍트 입니다.
아마도 패턴에 영향을 많이 받아서 그런거겠죠. 패턴 자체가 그러거니깐요.
패턴을 공부하다 보면 무엇이 맞다는 것 보다나는, 주어진 Context/Resulting Context를 심각히 고려하고 그중에 적합한 것을 선택하는 자세가 몸에 베이게 됩니다. 그게 아니면 제대로 패턴을 익힌거라고 할수 없으니깐요. 물론 저는 이제 아주 아주 조금 눈을 떠 가는 중이구요. (전 애벌레입니다. 🙂 – 몇몇 대단하게 보시는 분이 있어서. 오해를 하시지 마시기를…)
저도 많은 정보를 전달해 드리고 싶지만, 영어가 짧고, Nature of Order에 대한 선 지식이 없어서, 잘못된 내용이 있을수도 있습니다. (폭탄 발언?) 여튼 제가 이해하는 것이 잘못되었다고 생각하신 분은 댓글을 달아 주시면 바로 수정하겠습니다. 일단 잘못된 정보를 전달하면 안되기 때문에 글을 쓰지 말라는 분도 있지만, 누군가 정확한 의견을 전달해주면 그걸 수정하는 것이 맞지, 실패나 비난을 두려워해 아무것도 공유하지 않는 것은 정말 비겁한 자세라고 개인적으로 생각합니다. 전 정반합이 힘을 믿습니다.
Christopher Alexandar의 Nature of Order라는 서적은 크게 4가지 Volume으로 구성되어 있지만, Rebecca는 두권만 언급했습니다.
- 1st Volume은 the fifteen property of things (어떤 존재, 사물에 대한 15가지 속성)
- 2nd Volume은 Unfolding process for create“lively” things (살아있는 생명쳬를 만들기 위한 절차들)
오늘 Rebecca가 발표한 내용은 1st Edition에 나오는 15가지 속성을 기반으로 S/W에 빚대어 설명하는게 골자입니다. 1시간에 이런 무거운 내용을 전달하다 보니, 하고 싶은 얘기를 다 못껴내신거 같더라구요. 그리고 저 역시도 영어가 짧아서.. 이해를 다 하지는 못한거 같습니다.
Rebecca 아주머니는, Habitable Software라는 이야기를 꺼내며 화두를 시작했습니다. 사용하기 편하고, 경험하기 쉬운 소프트웨어를 말하는 데요. 이러한 시스템을 구성하기 위해 Alexandar가 말하는 15가지 속성으로 잘 구성되어야 된다고 얘기를 꺼냅니다.
Alexandar가 말하는생명체가 가지는 15개의 속성
- Levels of scale
- Strong centers
- Boundaries
- Alternating repetition
- Positive space
- Local symmetries
- Good shape
- Deep interlock and ambiguious
- Contrast
- Gradients
- Roughness
- Echoes
- The void
- Simplicity and inner calm
- No-separateness
Joshua Kerievsky 의 A Timelss way to communicate 세션 (부제 : : The Alexandrian Pattern Format )을 듣고 왔습니다. 패턴 저자들에게 Christopher Alexander 패턴의 가치를 깨닫게 해주고, 패턴 저자로써 가야할 방향을 제시한 좋은 발표였습니다.
크게 요약하면, 패턴을 작성하는 스타일이 있는데, Portland Form – Jim Copeling Form – GoF Form – Alexandarian Form 형태로 성숙하고 더 좋은 포멧이라는 것을 설명하는 세션이었습니다. A Timeless way of Building를 작성한 Christopher Alexandar가 만든 패턴 포멧에 대한 가치와 심오한 배경등을 설명해 주고, 왜 우리 패턴 저자들이 Alexandar가 만든 스타일을 따라야 하는지 설명을 해주었습니다.
재미난 건 PLoP에 GoF인 Ralph Johnson도 있고, Linda Rising 도 있고, Jim Copelin은 안 나왔지만 이미 친분이 두터운 관계인데, 그들의 스타일을 일일이 설명하면서, 어떻게 개선해야 되는지 설명한 세션이다 보니, 국내에선 이렇게 하다가 분위기가 험악해 질수도 있을거 같았는데. 놀라웠던건 그들이 그걸 수긍하고, 이미 Alexandarian 패턴 포멧을 따라가겠다는 의지를 밝혀 주었다는 겁니다. 역시 PLoP에 참가한 대가들은 변화와 개선점도 아주 빠르게 흡수한다는 것이 놀라웠습니다.
일단 특별히 어떤 형태로 쭉 잘정리하고 싶었지만 영어를 실시간으로 들으면서 정리하는데는 시간이 무지 많이 걸리거 같아. Timeline 순서대로 쭉 메모한 것을 그대로 적겠습니다.
뛰어난 아키텍트는 복잡도를 최소한으로 줄일 수 있어야 하며, 단단한 기본 구조를 취하면서도 급변하는 상황에 적절히 대처할 수 있는 실용적인 해결책들을 설계할 수 있어야 합니다.
위대한 아키텍트는 고립된 소프트웨어 모듈에서뿐만 아니라 사람과 사람사이, 시스템과 시스템 사이에서 일어나는 변화의 충격을 이해해야 합니다.
변화는 다양한 형태로 나타날 수 있습니다.
- 기능 위주의 요구 사항 변경
- 확장성 요구의 진화
- 수정된 시스템 인터페이스들
- 팀원의 변동
- 그리고 리스트(해야 할일)의 계속적인 발생
소프트웨어 프로젝트 변화의 광범위함과 복잡함을 미리 추측하는 것은 불가능하며, 변화가 발생하기 전에 모든 잠재적 어려움을 수용하는 시도는 헛된 일입니다. 그러나 아키텍트는 이러한 어려움들이 프로젝트를 망칠지 또는 완수할지를 결정하는 중요한 역할을 해야합니다.
아키텍트의 역할이 반드시 변화를 관리하기 위한 것은 아니지만, 오히려 변화가 관리될 수 있음을 보장해야 합니다.
Architecture 101 