지난해 다양한 소프트웨어 아키텍팅 강의를 진행해 왔습니다. 아키텍처 설계 및 평가 기법, 그리고 부하테스트/ 성능 최적화에 대한 강의가 주를 이루었습니다. 아키텍처 설계 프로세스는 말그대로 진행은 하면 되지만, 결국 많은 설계 기법을 알지 못하면 좋은 설계를 하지 못하는 상황이 빈번하게 발생했습니다. 2022년에 다음과 같은 강좌 들을 진행했습니다. 강의를 하다보면서, 아직 많은 교재들이 디자인패턴에 지식이 머물러있고, 몇몇 […]
일전에 약속을 드렸던 것처럼 Fault Tolerance 패턴 자료를 공유드립니다. 고 가용성이라는 것이 서버쪽에서는 동일한 요소를 두개 주는 이중화라는 기법으로 확보가 가능하지만, 자동차나 프론트엔드, 모바일쪽에서는 이중화 전략을 쓰기에는 한계가 많습니다. 소프트웨어 아키텍처 설계 과정을 준비하면서 만든 자료입니다. 저 역시 많은 선배님들의 지식을 가지고 성장했던 것처럼, 이 자료가 많은 동료와 후배분 들에게 미약하나마 도움이 되었으며 합니다. pdf로 […]
제가 패턴학회에 이사회 맴버로 있고, 저에게 가르침과 영향을 많이 주신 두분이 계십니다. 한 분은 유연하면서도, 지혜로운 삶을 사는 자세를 가르쳐 주신 Linda Rising 이시고, 또 한분은 AT&T에서 네트워크 스위치 개발을 시작으로, 오랫동안 Fault Tolerant 패턴을 정리해 주신 Robert S. Hanmer 님입니다. Bob Hanmer 님은 요즘 외부 활동을 잠시 쉬고 계시지만 이 분의 여러가지 노력들을 아래와 […]
이번 저자 워크샵은 정말 힘든 강행군의 연속이었습니다.
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를 듣고 더 업데이트 할 생각입니다.
저에게 연례 행사가 된 PLoP / SPLASH 참가는 정말 뜻 깊은 행사가 될듯 합니다.
이번 Bootcamp 행사는, Linda Rising이 개인적인 사정으로 참석을 못해 아쉬움이 컸습니다. 하지만 반사 이익으로 사상 최고의 맴버로 진행이 되었습니다 . Robert Hanmer, Joe Yoder, Rebecca Wirfs-Brock 님이 진행을 하셨습니다. 이전 2번의 워크샵과는 다르게 프리젠테이션이 많이 보강되었습니다.
작년에 있었던 Joshua Kerivsky 발표의 영향 때문인지, Christopher Alexander의 철학과 이야기들이 많이 보강되었고, Joe Yoder가 AsianPLoP에서 했던 패턴 라이팅까지 패턴을 가르키는데 종합 선물센트에 가까운 Bootcamp 였습니다.
거기다 일본 KEIO대학에서 대거 행사에 참여했는데, 다케시라는 분이 Learning Pattern Languages를 만들었다며 선물로 나누어 주었습니다. (같이 프로젝트를 한 토모라는 분이 “Learning Pattern”의 PDF 버전이 공유되어 있다고 하니, 추후 접수되는 대로 공유하겠습니다. 아마 지금 일본 분들은 고국으로 가느라 비행기에 있겠네요.)
패턴계에서는 절대적으로 내려오는 한가지 격언이 있습니다.
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를 중화시키기 위해 다른 해결책으로 또 다른 패턴들이 도입되는 그림을 늘 봐온 저로서는 도발적인 정의였습니다.
Architecture 101 