• Pattern Architecture = Architectural Style
• Pattern은 다음 3가지로 분류될 수 있음
• Architectural Pattern / Framework Pattern : Highest Level of abstraction in software pattern. 전체 시스템 차원의 구조와 관계에 대한 정의
• Design Pattern : collection of class or subsystem을 통해 문제를 해결하는 방법에 대한 서술
• Idiom (표현 양식, 언어) : the lowest level of pattern. 특정 프로그래밍 언어로 어떻게 개발되는지에 대한 코드 레벨
• 다만, MVC와 같이 위 3가지 카테고리로 분류하기 어려운 패턴도 등장. 한계가 있음.
• Pattern-Oriented Software Architecture
• Software 개발에 대한 또다른 접근 방법
• POSA에서는 아키텍처를 다음 4가지 그룹으로 분류함
• From Mud to Structure Category
• 시스템의 전체 task를 상호 동작하는 컴포넌트, subsystem, 레이어로 분해
• Layers Pattern
• Task를 서로 다른 Layer로 분리. 각각의 Layer는 특정 수준으로 추상화.
• 크고 복잡한 시스템을 구현하기 쉽게 분리 가능
• 유지보수성과 확장성 측면에서 강점
• 비싼 시스템 리소스는 단점
• Blackboard Pattern
• 여러 개의 특정 subsystem을 결합하여 각각의 솔루션에 대한 지식을 활용.
• 결정적인 솔루션을 가지고 있지 않은 경우에 적합
• 서로 연관이 없는 컴포넌트나 subsystem의 집합
• 복잡한 에러 핸들링에 효율적임
• Pipes & Filters Pattern
• Stream data 처리 시스템에 대한 구조
• 데이터 처리에 여러 단계의 step/pipe 순차적인 처리.
• 각 pipe 프로세스는 filter를 포함하고 있음.
• 데이터는 pipe와 filter를 통과. 데이터 처리는 빠르지만, 데이터 처리에 대한 오버헤드와 static 정보 공유에 비용이 비싸고 flexible하지 않다. (유연하지 않음)
• XML Streaming 데이터 처리와 같은 경우에 적합
• Distributed System Category
• 분산 어플리케이션에 대한 완전한 구조 제공
• Broker가 유일한 패턴임
• Pipes and Filters 패턴이나 Microkernel 패턴도 카테고리에 속하지만, 다른 카테고리에 더 적합함
• Broker Pattern
• 분산 시스템에서 주로 사용하는 패턴
• 원격 서비스를 호출하는 decoupled component에 대한 시스템 구조
• Client / Server 간 더 좋은 decoupling을 제공할 수 있음
• 변경성, 확장성, 위치 투명성 등 많은 장점이 있지만 디버그와 테스트가 어려움
• CORBA : Common Object Request Broker Architecture에 사용
• Interactive Systems Category
• 인간과 컴퓨터간의 상호작용과 같은 software 시스템 구조.
• 인간의 상호작용을 handling하는 데 초점
• Model-View-Controller Pattern과 Presentation-Abstraction-Control Pattern이 이 카테고리에 속함
• MVC Pattern
• 시스템을 Model, View, Controller 3가지 파트로 분리
• Model : 전체 시스템이 어떻게 동작하는지 설명
• View : 모델이 어떻게 보여지는지 설명
• Controller : 시스템과 User 사이 상호작용 제공
• 유지보수성과 확장성을 증대시키지만, 디자인 복잡성도 증가함
• 잘 알려진 예제는 smalltalk 아키텍처
• PAC Pattern
• 협업 에이전트(cooperating agent)의 계층 형태(hierarchy form)로 software system간 상호작용 구조를 정의
• 각 agent는 특정 application function에 대해 책임을 지는 3개의 컴포넌트(presentation, abstraction, control)로 이루어져 있음
• 인간과 컴퓨터가 상호작용할 때, functional core와 다른 agent와의 communication을 분리함
• Adaptable System Category
• 시스템은 시간이 지나감에 따라 발전하여 디자인이나 기능이 변경됨
• Adaptable System(적응형 시스템)은 Application의 확장과 개발된 기술의 조정, 기능 요구사항의 변경으로 이러한 문제를 극복함
• Microkernel Pattern
• Microkernel Pattern은 확장된 기능성과 고객별(customer-specific) 파트(part)로부터 최소 기능 코어를 분리.
• 확장 기능을 연결하고 협업을 조정하는 소켓을 제공.
• 다른 프로세스에서 실행되는 컴포넌트간 서로 통신 가능.
• 카네기 멜론 대학에서 개발된 mach(마하) 운영 체제가 이 패턴을 사용.
• Chorus 상용 시스템도 이 패턴을 사용.
• Reflection Pattern
• Reflection Pattern은 소프트웨어 시스템이 구조와 동작을 동적으로 변경하는 메커니즘 제공
• Type structure (유형 구조), date element (날짜 요소), function call(함수 호출) 메커니즘 수정 지원
• 이 패턴에서 application은 Meta level, Base level 2 분야로 분리됨
• Meta level : 소프트웨어 자체를 인식하고, 선택된 시스템 속성에 대한 정보를 제공
• Base level : Application Logic을 담당. Implementation은 meta level에서 유지.
• 결론
• 시스템 아키텍처는 사용 가능한 아키텍처 패턴과 그 사용법을 이해해야 함
• 시스템 아키텍처를 설계할 때, 인간과 환경적 요소들도 중요
• 프로젝트 수행 시, 예산과 아키텍처의 아름다움 아래 프로젝트에 사용할 수 있는 회사 정책, 리소스는 사용된 아키텍처 패턴이 아니라 아키텍트에 의해서 결정됨.

무엇인가를 구축할 때, 아키텍쳐부터 시작해서 전반을 설계한다는 것은 큰 모험이자 즐거움이 아닐 수 없다. 치열하게 머리를 싸매고 이리저리 재다보면 어느 순간 훌쩍 성장해 있는 지식과 무형의 자산인 자신감을 얻게 되는 거 같다.

그렇다고 그것이 자만이 되지 않도록 경계를 해야 하지만.

설계를 시작할 때는 전체에 대한 밑그림을 그리고,
그 다음 부분 부분을 세분화하고,
그 다음 세분화된 부분에 대해서 기술적으로 정리하고,
상세 스펙과 Entity, Attributes, Protocol을 비롯한 제반 사항들을 적어서 마무리 하고,
다시 반복해서 빠진 부분을 채우고, 변경할 부분을 변경하고.....

이런 일련의 반복 과정을 통해서 하나의 전체 큰 그림이 완성이 되어 간다.
우리는 이제... 시작점에 서 있는 거 같다.
KT SDP라는 큰 그림을 그리는 시작점.
어떤 그림이 나올지는 시간이 지나봐야 알겠지만,
내가 그린 그림이 KT 전체 SDP 모양새가 될 수도 있다는 사실이...
두렵다기보다는 설레고 흥분된다.

하나님께서 풍성한 지혜와 건강, 능력을 허락하셔서
오직 하나님의 말씀이 드러나고 성취되어 하나님만이 영광받으시는
나의 하루하루 삶이 되도록 인도하시기를 간절히 기도한다.

하나님의 승리가 곧 나의 승리가 될 것임을 믿어 의심치 않으니까.