소프트웨어 아키텍처
마이크로서비스 등의 분산 아키텍처 설계 및 구현에 참여한 소프트웨어 아키텍트 경력자인 마크 리처즈(Mark Richards)와 쏘우트웍스(ThoughtWokrds)이사이자 소프트웨어 아키텍트인 닐 포드(Neal Ford)는 소프트웨어 아키텍처를 다음과 같이 한 문장으로 정의했습니다.
소프트웨어 아키텍처는 시스템의 청사진(blueprint)이다.
소프트웨어 아키텍처는 쉬이 정의하기 어렵고 아키텍트마다, 사이트마다 정의하는 것이 다르므로 여러 관점에서 복합적으로 바라봐야 하는 개념이라고 생각합니다. 시스템 구조(structure), 설계 원칙, 아키텍처 결정, 아키텍처 특성의 4가지 관점에서 소프트웨어 아키텍처를 정의하겠습니다.
시스템의 구조
각 회사마다, 팀마다, 개인마다 한 프로그램 또는 프로젝트를 설계할 때 미리 고려하면 좋은 것은 아키텍처 스타일입니다. 구현하려고 하는 시스템에 어느 아키텍처 스타일을 사용할지 고려해야 합니다. 아키텍처 스타일의 종류는 예를 들어 레이어드 아키텍처, 파이프라인 아키텍처, 마이크로커널 아키텍처 뿐만 아니라 서비스 기반인지 이벤트 기반인지 공간 기반인지 또는 오케스트레이션 기반인지에 따라도 나눌 수 있을 만큼 매우 다양합니다.
아키텍처를 설명할 때 "이 시스템은 파이프라인 아키텍처입니다."라고 한다면 이는 시스템의 구조를 말할 뿐 시스템의 아키텍처를 설명한 것은 아니므로 다른 특성도 살펴보아야 합니다.
아키텍처 특성
아키텍처 특성(Architecture characteristic)은 시스템의 기능수행과 관련있는 모든 것들을 말합니다. 프로그램 실행 중에 인터넷 접속이 끊기거나 하드웨어 오류로 인한 에러나 경계 조건을 감당하는 능력부터, 새로운 기능을 삽입하는 것이 용이한지를 보는 능력, 그리고 심지어 시스템 운영상 법적 제약조건이 있는지도 따져봐야 하는 것 등이 모두 아키텍처 특성에 관한 것입니다.
아키텍처 결정
아키텍처 결정(Architecture decision)은 아키텍트가 어떤 기술을 사용하기로 결정하고 그 기술을 어느 아키텍처 특성(예를 들어 보안성 강화)을 위해 선택한 것임을 나타냅니다. 시스템 설계 시, 어느 기술을 사용할 것인지를 정하는 것 뿐만 아니라 그 기술은 어느 아키텍처 특성을 지원하기 위해 사용한 것인지 까지 결정해야 합니다. 이를 위하여 소프트웨어 아키텍트는 트레이드오프(trade-off) 스킬이 매우 뛰어나야 한다고 생각합니다. 예를 들어 서비스 간 통신은 동기로 할지 비동기로 할지에 대한 결정에 관한 것입니다.
동기 통신 방법과 비동기 통신 방법의 각각의 명확한 장단점 중에서 어느 방법이 시스템에 가장 잘 맞는지를 결정해야 합니다.
설계 원칙
마지막인 설계 원칙(design principle)은 시스템 구축에 필요한 가이드라인입니다. 설계 원칙은 개발자가 아키텍처 구현 작업을 할 때 제약조건을 마련하는 데에도 도움이 됩니다. 개발자가 무엇을 할 수 있고 무엇을 할 수 없는지를 예시하고 특정 목적에 맞는 라이브러리를 지정하거나 레이어드 스택을 결정해야 하는 것 등이 설계 원칙의 대표적인 예시입니다.
바로 위의 아키텍처 결정이 예를 들어 반드시 지켜야 하는 헌법이라면, 설계 원칙은 일을 함에 있어 나아갈 방향과 계획 같은 방침입니다.
마무리 - Trade
off
위의 네 가지 특성으로 소프트웨어 아키텍처를 정의를 해보았는데, 결국 소프트웨어 아키텍처는 어느 것을 얻으려면 반드시 다른 것을 희생하여아 하는 관계의 연속인 트레이드오프라고 생각합니다. 설계하려는 각 시스템마다 사용해야할 시스템의 구조도 모두 상이하고 고려해야 할 아키텍처 특성, 결정까지도 모두 정해진 것이 없고 다양하기 때문에 이 여러 요소 중에서 시스템과 가장 잘 맞는 것이 무엇인지를 선택하는 과정에서 트레이드오프는 필수입니다.
