건축으로 이해하는 소프트웨어 아키텍처 | 설계와 아키텍처의 핵심 차이점

channel_editor_icon 라주 간디 , 마크 리처드 , 닐 포

4시간 전

소프트웨어 아키텍처를 이해하기 위해 집을 떠올려 보세요. 집의 구조가 바로 아키텍처입니다. 집의 모양, 방의 개수, 층 수, 크기 등이죠. 이런 구조적 요소들은 나중에 변경하기 어렵고, 집에서 가장 중요한 부분입니다.

아키텍처는 집을 짓는 데 필수입니다. 아키텍처 없이 집을 짓는 모습을 상상할 수 있나요? 아마도 못생기고 기능적이지 않은 모양의 집이 나오게 될 것입니다. 소프트웨어도 마찬가지입니다. 확장할 수 없고 유지보수가 어려운 시스템들은 대부분 아키텍처를 충분히 고려하지 않았기 때문입니다.

✅ 건축 계획과 소프트웨어 아키텍처

소프트웨어 시스템의 ‘건축 계획’은 어떤 것일까요? 건축 계획이 집의 구조(방, 벽, 계단)를 정의하는 것처럼, 소프트웨어 아키텍처 다이어그램은 소프트웨어의 구조(사용자 인터페이스, 서비스, 데이터베이스, 통신 프로토콜)를 정의합니다. 둘 다 최종 결과를 가시화하고 개발에 지침을 제공합니다.

중요한 점은 건축 평면도에 바닥재 종류나 벽 색상, 가구 배치 같은 세부사항은 포함되지 않는다는 것입니다. 이런 것들은 구조적 요소가 아니라 설계(디자인) 요소이기 때문입니다.

✅ 소프트웨어 아키텍처의 차원들

우리 주변의 많은 것은 다차원적입니다. 예를 들어, 집에 있는 특정 방을 묘사한다고 생각해봅시다. 아마도 길이는 5미터, 폭은 4미터, 천장 높이는 2.5미터일 것입니다. 방을 정확하게 묘사하기 위해서는 높이, 길이, 너비의 세 가지 차원을 모두 명시해야 함을 주목하세요.

소프트웨어 아키텍처도 마찬가지로 차원을 설명할 수 있습니다. 다만 소프트웨어 아키텍처는 네 개의 차원이 있다는 점이 다릅니다.

① 첫 번째 차원: 아키텍처 특성

아키텍처 특성은 소프트웨어 시스템 아키텍처의 기반을 형성합니다. 이 특성이 없다면 아키텍처 관련 결정을 내리거나 중요한 트레이드오프^{(trade-offs)*}를 분석할 수 없습니다.

두 개의 집 중 하나를 선택한다고 가정해봅시다. 한 집은 넓지만 시끄러운 고속도로 옆에 있고, 다른 집은 조용한 동네에 있지만 훨씬 작습니다. 어떤 특성이 더 중요한가요? 집의 크기가 중요한가요, 아니면 소음과 교통이 중요한가요? 이 기준이 없으면 올바른 선택을 할 수 없습니다.

소프트웨어도 마찬가지입니다. 새로운 데이터베이스를 선택할 때, 고성능 검색이 필요하다면 그래프 데이터베이스를, 데이터 관계 유지가 중요하다면 관계형 데이터베이스를 선택하게 됩니다.

*트레이드오프(trade-offs): 두 가지 이상의 선택지나 요소 간의 균형을 맞추기 위해 하나를 선택할 때 다른 하나를 포기해야 하는 상황을 의미합니다.

② 두 번째 차원: 아키텍처 결정

아키텍처 결정은 시스템의 구조적 측면에 관한 선택으로, 장기적으로 중요한 영향을 미칩니다. 이러한 결정들은 제약사항이 되어 개발 팀에게 지침을 제공합니다.

집을 짓는다고 가정했을 때 단층으로 짓고 싶은가요, 아니면 2층집을 원하시나요? 지붕은 평평한가요, 아니면 뾰족한가요? 만약 크고 방대한 랜치 하우스를 짓는다면 또 어떨까요? 이러한 결정들은 집의 구조적인 측면에 영향을 미치므로 좋은 아키텍처 결정의 예입니다.

집을 지을 때 단층인지 2층인지, 지붕이 평평한지 뾰족한지 결정하는 것처럼, 소프트웨어에서는 "사용자 인터페이스가 데이터베이스와 직접 통신하지 않고, 서비스를 통해 데이터에 접근한다"는 식의 결정을 내립니다. 이런 결정이 전체 시스템 구조를 결정짓게 됩니다.

③ 세 번째 차원: 논리적 컴포넌트

논리적 컴포넌트는 시스템의 구성 요소로, 집의 방과 같습니다. 주문 결제 처리, 재고 관리, 주문 추적 등의 기능을 수행합니다.

시스템 내에서는 보통 디렉터리나 네임스페이스로 표현됩니다. 예를 들어, app/order/payment는 '결제 처리'라는 논리적 컴포넌트를 나타냅니다. 각 컴포넌트는 명확한 역할과 책임을 가져야 합니다.

④ 네 번째 차원: 아키텍처 스타일

집이 빅토리안, 랜치, 튜더 등의 특정 스타일을 가지는 것처럼, 소프트웨어 시스템도 전반적인 구조와 형태를 정의하는 아키텍처 스타일이 있습니다.

아키텍처 스타일은 각기 다른 고유한 특성들로 소프트웨어 시스템의 전반적인 모습과 구조를 정의합니다. 예를 들어, 마이크로서비스^{(microservices)} 아키텍처 스타일은 확장성이 좋고, 빠르게 변화하는 환경에 대응할 수 있는 높은 수준의 민첩성^(agility)을 제공합니다. 반면에 레이어드^(layered) 아키텍처 스타일은 덜 복잡하고 비용이 적게 듭니다. 이벤트 기반^{(event-driven)}아키텍처 스타일은 높은 확장성을 제공하며, 매우 빠르고 응답성이 좋습니다.

아키텍처 스타일은 시스템의 전반적인 특성을 정의하므로 처음부터 올바른 선택을 하는 것이 중요합니다. 랜치 하우스를 짓다가 빅토리안 주택으로 바꾸기 어려운 것처럼, 모놀리식에서 마이크로서비스로 전환하는 것도 상당한 작업이 됩니다.

✅ 아키텍처와 설계는 어떻게 다를까요?

아키텍처는 구조에 중점을 두고, 설계는 외관에 중점을 둡니다. 집으로 예를 들면, 벽면 색상, 가구 배치, 마루 종류는 설계 측면입니다. 반면 방의 크기, 문과 창문의 위치는 아키텍처, 즉 구조적 부분입니다.

비즈니스 애플리케이션에서도 마찬가지입니다. 아키텍처는 웹 페이지가 백엔드 서비스 및 데이터베이스와 통신하는 방식에 관한 것이고, 설계는 각 페이지의 색상, 필드 배치, 설계 패턴 등 외관에 관한 것입니다.

다시 요약하면 ‘구조’냐 ‘외관’이냐의 차이입니다. 때때로 아키텍처와 설계를 구분하는 것이 혼란스러울 수 있기 때문입니다. 이제 이들의 차이점을 알아보겠습니다.

새로운 주문 처리 시스템을 만든다고 가정해 보겠습니다. 고객은 주문 후 내역을 조회하거나 취소할 수 있고, 결제는 신용카드나 선불카드로 가능합니다.

• 설계 관점

설계 관점에서 결제 기능을 구현하기 위해 다음과 같은 통합 모델링 언어^{(Unified Modeling Language; UML)}클래스 다이어그램을 통해 클래스들 간의 상호작용을 정의합니다.

소스 코드를 작성하여 이러한 클래스들을 구현하는 동안 설계 관점에서는 클래스 파일들이 어떻게 조직되고 배포되는지, 즉 소스 코드의 물리적인 구조에 대해서는 언급하지 않았습니다.

• 아키텍처 관점

시스템 전체 구조를 다룹니다. 각 결제 유형별로 별도 서비스를 만들고, 이들을 관리할 오케스트레이터 서비스를 배치하는 등 시스템이 어떻게 조직되는지에 집중합니다.

새로운 주문 처리 시스템에 대해 다시 생각해봅시다. 시스템은 어떤 모습일까요? 아키텍처 관점에서 주문 결제 절차에 맞는 각 결제 유형을 위한 별도의 서비스를 생성하고, 결제 처리 부분을 관리할 오케스트레이터(orchestrator) 서비스를 만들 수 있습니다. 아래의 다이어그램처럼 말이죠.