패턴계에서는 절대적으로 내려오는 한가지 격언이 있습니다.
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를 중화시키기 위해 다른 해결책으로 또 다른 패턴들이 도입되는 그림을 늘 봐온 저로서는 도발적인 정의였습니다.
지난 Rebecca Wirfs-Brock의 Nature of Order I를 이어 그 다음 이야기를 진행하고자 합니다. 혹시 이전 내용을 못 읽으신 분은 링크를 따라 한번 읽어보시길 권해드립니다.
워낙 방대한 내용이라, 섣불리 글이 써지지 않더군요. 철학과 생명체, 사물 (Thing)의 구성 원칙들을 기술하는 것이다 보니, 농업 / 생명 / 건축등 다양한 것을 예로 들어 설명하고 있습니다. 게다가 너무 철학적이어서, 개발자가 읽기에는 지루할수도 있죠. 아직 책을 다 읽지 못했지만, PLoP에서 정리한 노트내용과 NOO를 SW 설계에 빚대어 설명한 논문들 그리고 저의 부족한 경험을 합쳐서 용기를 내어 써 봅니다.
항상 경청하는 자세로 여러분의 피드백을 받겠습니다. 부족한 부분은 말씀해주시고, 더 좋은 의견을 주시면 관련 자료를 더 찾고 공부해서 NOO 데이터를 계속 업데이트할 욕심은 있습니다.
Architecture 101 