여러분에게 좋은 소식을 하나 알려 드리겠습니다. 패턴 학회인 PLoP 2009 에 참여할 예정입니다.
그 이유는 … 바로… !! 제출한 논문이 통과되었기 때문입니다.
저에게 현재 초벌 번역이 끝난 상태인 Framework Design Guideline 2nd Edtion을 같이 번역하고 있는 진호, 상원, 제민 이가 많은 도움을 주었습니다. 사실 이책을 번역하고 나온 금액으로 워크샾에 참여할 생각이었지만, 다들 취업때문에 바빠서 번역 일정이 약간 미루어 졌습니다. 어쩔수 없이 자비로…
오늘날의 시스템은 분산되어 있고, 느슨하게 결합되어 있습니다. 느슨하게 결합된 시스템을 구축하는 것은 조금 귀찮은 작업입니다., 우리는 왜 이런 귀찮은 작업을 해야 될까요? 우리는 조그만 변화로 시스템들이 산산이 부서지는 것을 원하지 않기 때문에, 우리의 시스템들이 (변화에) 유연하길 원합니다.
오늘날의 환경에서 유연함은 매우 중요한 자산입니다. 여기서 우리는 어플리케이션의 작은 부분만을 제어할 수 있습니다. 분산 서비스나 써드-파티 패키지들에서 작동하는 나머지 부분들은 다른 부분이나 외부 밴더 들에 의해 제어됩니다.
그래서, 변화에 유연하고 시간이 흐름에 따라 진화할 수 있게 시스템을 구축하는 것은 좋은 노력처럼 보입니다. 하지만, 이것은 우리의 시스템이 시간이 흘러감에 따라 변할 수 있음을 의미합니다. “오늘날의 시스템은 더 이상 어제의 시스템이 아니다.” 라는 것처럼..
불행하게도, 변화는 문서화하는 것도 어렵게 만듭니다. 항상 변경되는 시스템에서는, 문서가 프린터 되는 순간 그 문서는 구식으로 되어 버리고, 이러한 상황들이 심해질 수 있습니다. 게다가, 일반적으로 유연하게 시스템을 구축 하는 것은 아키텍쳐가 좀더 복잡해 지는 것을 의미하며, 잘 알려진 “Big Picture (큰 그림)”[1]을 얻기 어렵습니다.
예를 들어 만약 모든 시스템의 컴포넌트들이 꼭 설정 가능한 채널을 통해 다른 구성요소들과 통신을 한다면, 컴포넌트들은 어떤 행위를 (무엇을 해야) 할지에 대한 정보를 얻기 위하여 채널 설정부만 바라보면 됩니다.
제 2회 아키텍트 Summit에 발표 자료입니다. 아키텍트에 ‘아’짜도 따라가지 못하는 저가, 우여 곡절 속에 수많은 쟁쟁한 분과 함게 발표를 맡게 되었습니다.
다른 쟁쟁한 아키텍트 분들에게 누가 되지 않았길 바라며, 발표를 준비했습니다. 주제는 패턴과 EA의 활용에 대해서 간략히 언급해 드렸습니다.
로마인의 세계에서, 야누스는 시작과 끝, 문과 통로의 신입니다. 야누스는 다른 방향의 바라보는 두 개의 머리로 보통 묘사되며, 영화나 동전에서 볼 수 있는 상징입니다. 야누스는 전환과 변화를 나타냅니다. 우리의 삶에서 예를 든다면 과거에서 미래로, 젊음에서 늙음, 결혼, 탄생, 시대의 도래와 같은 것이 있습니다.
소프트웨어 또는 건축물이든 어떤 아키텍트도, 앞과 뒤로, 과거에서 미래로 볼 수 있는 야누스의 능력은 꼭 필요한 능력입니다. 아키텍트는 비전과 현실, 향후 방향과 과거의 성공, 개발 제약과 사업/관리 기대치를 융합하기 위해 노력합니다.
이러한 (간극을 메우는) 다리를 만드는 것은 아키텍트의 중요한 역할입니다. 종종 아키텍트는 프로젝트를 완성하기 까지, 프로젝트에 영향을 미치는 다른 영향력들(예를 들어 접근 용이성 vs 보안, 경영의 미래 비전을 설계하면서 현재 비지니스 프로세스를 만족시키는 것)이 발생시키는 간극을 극복하기 위해 노력할 때, 희로애락을 느끼기도 합니다.
다양한 프로젝트의 이해당사자를 만족시킬 수 있는 소프트웨어(product)를 만들기 위하여, 좋은 아키텍트는 두 가지의 다른 아이디어나 생각, 다른 목표와 비전을 처리할 수 잇는 두 개의 머리를 가져야만 합니다. 아키텍트인 당신은 단순히 두 개의 얼굴이 아닌, 야누스가 가진 두 개의 머리를 주의 깊게 보아야 합니다. 훌륭한 IT 아키텍트는 뛰어난 경청 자[1] 이자 평가자 이어야 합니다.
넬슨 제독이 1805년 트라팔가에서 프랑스와 스페인 함대를 격파한 이후, “분할 후 정복(Divide and Conquer)”은 복잡하고 어려운 문제를 다루는 슬로건(상징)이 되었습니다. 동일한 의미를 가지는 좀더 친숙한 용어로 “걱정 거리의 분리 (Separation of Concern)”가 있습니다.
걱정 거리의 분리로부터 우리는 캡슐화를 얻게 되고, 캡슐화로부터 우리는 경계와 인터페이스를 얻게 됩니다.
아키텍트의 관점에서, 가장 어려운 부분은 동작하는 시스템을 구축하기 위해 필요한 적당한 인터페이스를 정의하고, 경계를 정하는 자연스러운 위치를 찾는 것입니다.
이것은 거대한 엔터프라이즈 시스템에서는 특히 어려운 일입니다. 이런 상황에서, “결합도는 낮추고, 응집도는 높여라”와 “정보 교환이 자주 발생하는 영역들은 나누지 말아라”와 같은 오래된 명언이 몇 가지 지침을 제공합니다. 하지만 명언들은 어떻게 쉬운 방법으로 이해당사자들에게 가능성 있는 해결방안과 문제들을 대해 소통할 수 있는지 알려주지 않습니다.
Architecture 101 