Ch07 아키텍처 특성의 범위

한 줄 정의

아키텍처 퀀텀(architecture quantum) 은 아키텍처 특성이 적용되는 범위를 정의하는 단위로, “시스템 전체에 하나의 특성 집합”이라는 기존 가정을 깨고 서비스/컴포넌트 수준의 특성 차이를 반영합니다.

쉽게 말하면

“확장성이 필요해”라고 할 때, 시스템 전체가 아니라 어느 부분에 확장성이 필요한지가 중요합니다.

결제 서비스와 상품 카탈로그 서비스는 서로 다른 아키텍처 특성이 필요합니다. 아키텍처 퀀텀은 이렇게 “같은 특성 집합이 적용되는 독립적인 단위”를 의미합니다.

왜 중요한가?

기존 프레임워크들은 시스템 전체에 하나의 아키텍처 특성 집합이 적용된다고 가정했습니다. 하지만 마이크로서비스 같은 현대적 아키텍처에서는 서비스 수준의 특성들과 시스템 수준의 특성들이 다릅니다.

코드 수준의 지표만으로는 운영 아키텍처 특성(특히 외부 의존 컴포넌트인 데이터베이스 등)의 영향을 평가할 수 없습니다. 아키텍트가 코드베이스를 아무리 잘 설계해도, 시스템의 데이터베이스가 그런 특성과 일치하지 않으면 그 노력은 성과를 내지 못합니다.

아키텍처 퀀텀 개념은 범위를 생각하는 새로운 방법을 제공합니다. 현대적인 시스템에서 아키텍트들은 시스템 수준이 아니라 퀀텀 수준에서 아키텍처 특성을 정의하며, 이러한 접근은 새로운 문제 도메인을 분석할 때 중요한 정보를 제공합니다.

핵심 내용

아키텍처 퀀텀의 정의

아키텍처 퀀텀 은 높은 기능적 응집(functional cohesion) 과 동기적 커네이선스(synchronous connascence) 를 가진, 독립적으로 배포 가능한 아티팩트입니다.

물리학의 퀀텀(양자) 개념에서 빌려온 용어로, “더 이상 쪼갤 수 없는 최소 단위”를 의미합니다. 마이크로서비스가 자신만의 데이터와 의존요소들과 함께 아키텍처 안에서 독립적으로 실행될 수 있다는 점에서, 마이크로서비스는 아키텍처 퀀텀의 정의에 잘 맞습니다.

아키텍처 퀀텀은 아키텍처 특성 집합의 범위를 확립하며, 다음 네 가지 특징을 지닙니다.

아키텍처 특성 집합의 범위 확립

아키텍트는 아키텍처 퀀텀을 아키텍처 특성 집합들을 구분하는 경계선으로 활용합니다.

특히 운영 특성들을 구분하는 데 유용합니다. 독립적으로 배포할 수 있고 기능적 응집도가 높다는 점에서 아키텍처 퀀텀은 아키텍처 모듈성의 유용한 척도를 제공합니다.

독립적 배포 가능

아키텍처 퀀텀은 아키텍처의 다른 부분과 독립적으로 기능하는 데 필요한 모든 구성요소를 포함합니다.

예를 들어 애플리케이션이 데이터베이스를 사용한다면 그 데이터베이스는 퀀텀 일부입니다. 데이터베이스 없이는 시스템이 기능하지 못하기 때문입니다. 그런데 이 요구사항과 퀀텀의 정의를 조합하면, 데이터베이스 하나(단일 데이터베이스)만 사용하도록 배포되는 거의 모든 레거시 시스템은 시스템 전체가 하나의 퀀텀이 됩니다. 반면에 마이크로서비스 아키텍처 스타일에서는 서비스마다 개별적인 데이터베이스를 사용합니다. 이 경우 각 서비스가 개별적인 아키텍처 특성 범위를 가지므로, 아키텍처에 여러 개의 퀀텀이 형성됩니다.

높은 기능적 응집도

컴포넌트 설계에서 응집은 컴포넌트에 포함된 코드가 얼마나 목적에 맞게 통합되어 있는지를 나타냅니다.

예를 들어 고객 엔티티와 관련된 속성과 메서드만 가진 Customer 컴포넌트는 응집도가 높지만, 각종 메서드가 마구잡이로 모여 있는 utility 컴포넌트는 그렇지 않습니다. 기능적 응집도가 높다는 것은 아키텍처 퀀텀이 목적에 맞는 일을 한다는 뜻입니다.

시스템 전체가 하나의 데이터베이스를 사용하는 전통적인 모놀리스 애플리케이션에서는 이러한 구분이 거의 중요하지 않습니다. 본질적으로 시스템 전체가 하나로 응집되어 있기 때문입니다. 하지만 이벤트 주도(event-driven)나 마이크로서비스 같은 분산 아키텍처에서는 아키텍트가 각 서비스를 단일 작업흐름(도메인 주도 설계의 경계 컨텍스트 에 해당)과 일치하도록 설계할 가능성이 큽니다. 그런 서비스들은 기능적 응집도가 높아 나옵니다.

외부 구현의 정적 결합도 낮음

아키텍처 퀀텀들 사이의 구현 결합 수준이 낮아야 합니다. 이 특징 역시 경계 컨텍스트 사이의 낮은 결합이라는 DDD 철학에서 파생됩니다. 퀀텀은 컴포넌트보다 한 단계 높은 추상화 수준에서 아키텍처의 운영 구성요소를 형성합니다. 퀀텀들은 서비스 경계들과 겹치는 경우가 많습니다.

목표는 아키텍처의 서로 다른 부분들이 느슨하게 결합되는 것을 아키텍트들이 선호한다는 점과 맞습니다. 범위가 줄어서 결합도가 더 높아도 됩니다. 하지만 범위가 넓을수록 결합은 더 느슨해야 합니다.

결합 유형의 이해

외부 구현의 정적 결합도가 낮다는 특징을 명확히 이해하려면 결합을 좀 더 세부적인 유형들로 나누어 정의할 필요가 있습니다.

의미적 결합 (Semantic Coupling)

아키텍트가 풀려는 문제 자체에 내재된 자연스러운 결합입니다.

예를 들어, 주문 처리 애플리케이션에서 재고, 카탈로그, 장바구니, 고객, 판매 같은 요소들이 서로 결합하는 것은 자연스러운 일입니다. 도메인을 변경하면 그 영향이 시스템 전체로 파급되며, 아키텍트가 이를 방지하는 수단이나 적절한 아키텍처 패턴은 없습니다.

구현 결합 (Implementation Coupling)

아키텍트와 팀이 어떤 의존성을 구현할 것인지 결정하는 것과 관련이 있습니다.

주문 처리 애플리케이션에서 데이터 경계를 설정할 때 다양한 제약조건을 고려해야 합니다. 모든 데이터가 단일 데이터베이스에 있어야 하는가, 아니면 확장성이나 가용성을 고려해서 데이터베이스를 분리해야 하는가?

이런 질문들의 답은 시스템의 의미적 결합에는 거의 영향을 주지 않지만 아키텍처적 결정에는 큰 영향을 미칩니다.

정적 결합 (Static Coupling)

아키텍처의 ‘배선(wiring)’ 방식을 의미합니다. 즉, 서비스들의 상호 의존관계에 관한 것입니다. 서비스가 동일한 결합 지점에 의존한다면 같은 아키텍처 퀀텀의 일부가 됩니다.

예를 들어, Catalog와 Shipping이라는 두 마이크로서비스가 주소 정보를 공유하는 컴포넌트에 의존한다면, 둘은 하나의 공유 컴포넌트에 의해 결합되며, 따라서 같은 아키텍처 퀀텀의 일부가 됩니다.

소프트웨어 아키텍처에서 결합을 파악하는 쉬운 방법은 무언가를 변경했을 때 다른 뭔가가 고장 난다면 그 둘은 결합된 것입니다. 정적 결합은 아키텍처에 존재하는 범위 의존성(scope dependency) 을 정의합니다.

동적 결합 (Dynamic Coupling)

아키텍처 퀀텀들이 반드시 서로 통신해야 할 때 작용하는 힘들을 설명합니다. 예를 들어, 시스템 안에서 함께 실행되는 두 서비스가 하나의 작업흐름을 형성해서 통신하면서 공통의 작업을 실행하게 됩니다. 분산 아키텍처의 경우 아키텍트는 서비스 간 통신과 관련된 트레이드오프를 고려해야 합니다.

이러한 결합 유형들을 바탕으로 아키텍처 퀀텀의 셋째 특징을 좀 더 정확하게 설명할 수 있습니다. 아키텍처 퀀텀들 사이의 구현 결합 수준이 낮아야 한다는 것은, DDD 철학에서 파생된 것으로, 퀀텀들은 서비스 경계들과 겹치는 경우가 많습니다.

일반적으로 긴밀한 결합은 한 서비스나 하위시스템(subsystem) 안의 코드 요소들처럼 높은 응집도가 필요한 경우에 바람직합니다. 단일한 구현이 변경되었을 때 예기치 못한 파급 효과로 (겉보기에는 별 관련이 없는) 다른 많은 것이 고장 나는 아키텍처를 가리켜 “취약하다(brittle)“라고 말합니다. 시스템의 결합 범위가 넓을수록 결합이 느슨해지며, 느슨한 결합은 아키텍처를 덜 취약하게 만드는 데 도움이 됩니다.

예를 들어 아키텍트가, 하나의 호출자에게만 영향을 미칠 것이라고 생각하면서 어떤 서비스 호출의 한 필드 이름을 State에서 StateCode로 바꾸었지만 실제로는 다른 여러 의존요소가 예기치 않게 깨지는 상황을 상상해 보기 바랍니다.

도메인 주도 설계의 경계 컨텍스트 개념

에릭 에반스(Eric Evans)의 Domain-Driven Design 은 현대적인 아키텍처 사고에 깊은 영향을 미쳤습니다. 도메인 주도 설계(Domain-driven design, DDD) 는 아키텍트가 복잡한 문제 도메인을 체계적으로 분해할 수 있게 해주는 모델링 기법입니다.

DDD에는 경계 컨텍스트(bounded context) 라는 개념이 있습니다. 하나의 경계 컨텍스트는 도메인의 특정 부분에 대응됩니다. 주어진 경계 컨텍스트 안에서는 그 부분에 연관된 모든 것을 볼 수 있지만, 다른 경계 컨텍스트에서는 볼 수 없습니다.

DDD 이전에 아키텍트들이 조직 안의 공통 엔티티들에 걸쳐서 코드를 전체적으로 재사용하려고 했습니다.

이런 공통의 공유 코드 요소를 만들어 내면 결합도가 높아지고 조정(coordination)이 어려워지며 복잡성이 증가하는 등 수많은 문제가 발생한다는 점을 깨닫게 되었습니다. 경계 컨텍스트 개념은 각 엔티티가 분리된 컨텍스트 안에서 가장 잘 작동한다는 점에 착안합니다.

즉, 전체 조직에 걸쳐 통합된 Customer 클래스를 만드는 대신 문제 도메인마다 개별적인 Customer 클래스를 만들고 다른 Customer 클래스와의 차이점은 해당 도메인과의 통신 지점에서 조정하는 것이 낫습니다.

동기적 통신

통신(communication) 은 동적 결합을 의미합니다. 지금 맥락에서는 아키텍처 퀀텀들이 서로를 호출하는 것이 통신입니다. 이런 관계는 분산 아키텍처에서 흔합니다.

운영 범주의 아키텍처 특성들은 분산 아키텍처에서 중요한 타이밍과 차단(blocking)을 결정하는 경우가 많기 때문입니다.

예를 들어, Payment 서비스와 Auction 서비스가 있는 마이크로서비스 아키텍처를 생각해 봅시다. 경매가 끝나면 Auction 서비스가 결제 정보를 Payment 서비스에 동기적으로 전송합니다. 그런데 Payment 서비스가 500ms마다 결제를 하나씩만 처리할 수 있다고 하면, 다수의 경매가 동시에 끝나면 어떻게 될까요? 두 서비스는 운영 아키텍처 특성들이 다릅니다. 따라서, Payment에 대한 Auction의 첫 호출은 성공하지만 이후의 호출들에서는 Payment 서비스가 다수의 요청을 감당하지 못해서 호출들이 실패하기 시작할 가능성이 있습니다. 간단히 말해 Payment 서비스는 Auction 서비스보다 확장성이 떨어집니다.

비동기 통신(asynchronous communication)은 잠재적 영향이 적으므로, 여기서는 동기적 통신만 다룹니다. 예를 들어, Auction 서비스가 메시지 대기열(message queue)을 이용해서 Payment 서비스를 비동기적으로 호출한다면 대기열이 버퍼 역할을 하므로 어느 정도까지는 두 시스템이 함께 잘 작동할 수 있습니다. 물론 Payment가 처리할 수 있는 것보다 더 많은 메시지를 Auction 서비스가 계속 보낸다면 결국 메시지 대기열이 넘칠 것입니다. 하지만 다수의 메시지가 간헐적으로만 들어온다면, 대기열은 수신자가 준비될 때까지 그 메시지들을 보관할 수 있습니다. 반면에 분산 아키텍처에서 동기적 통신은 그런 여유가 전혀 없습니다. 아키텍처 구성요소들의 아키텍처 특성들이 서로 다르다면 더욱 그렇습니다.

범위 지정의 영향

아키텍처 특성들의 범위는 아키텍트가 서비스 경계(service boundary) 를 적절히 결정하는 데 도움이 됩니다.

범위 지정과 아키텍처 스타일

문제 도메인의 퀀텀 경계를 결정하면 아키텍처 스타일을 선택하기가 좀 더 쉬워집니다.

아키텍트는 아키텍처 특성들과 도메인을 분석해 가장 적절한 아키텍처 스타일을 결정해야 합니다. 이 분석 작업의 일부는 주어진 솔루션에 아키텍처 특성 그룹이 하나만 있으면 되는지, 아니면 여러 개가 필요한지 판단하는 것입니다.

flowchart LR
    A["아키텍처 특성 및<br/>도메인 분석"] --> B{"특성 집합이<br/>하나인가?"}
    B -->|하나| MONO["모놀리스 아키텍처"]
    B -->|둘 이상| DIST["분산 아키텍처"]
    MONO --> M_STYLE["모놀리스 스타일 중<br/>적절한 것을 선택"]
    DIST --> S1["① 아키텍처 특성 선택"]
    S1 --> S2["② 퀀텀 경계 결정"]
    S2 --> S3["③ 영속성 메커니즘 결정"]
    S3 --> S4["④ 통신 스타일 결정<br/>동기 vs 비동기"]

• 단일 퀀텀(모놀리스 경로): 하나의 아키텍처 특성 집합으로 충분하다고 결정한 경우, 모놀리스 아키텍처를 선택하면 이후에 결정할 사항들이 줄어듭니다. 일반적으로 단일 모놀리스 데이터베이스가 적합합니다.
• 복수 퀀텀(분산 경로): 분산 아키텍처를 선택하면 네 단계의 후속 결정이 필요합니다.

분산 아키텍처 쪽으로 이 단계에 도달했다면 영속성 선택지는 두 가지입니다. 하나는 데이터베이스를 하나만 사용하는 것이고(이벤트 주도 아키텍처에서 흔함) 다른 하나는 서비스 세분도에 따라 데이터를 더 분할하는 것입니다(마이크로서비스 아키텍처적 방식으로).

영속성을 결정한 후에도 한 단계가 더 남아 있습니다. 바로, 퀀텀들 사이의 통신을 동기적으로 진행할 것인가 비동기적으로 진행할 것인가입니다. 동기적 통신을 선택하면 앞에서 정적 결합을 통해 확립된 퀀텀 경계들을 다시 변경해야 할 수도 있습니다. 두 결합 유형은 자주 상호작용합니다.

카타: 고잉 그린 예제

고잉 그린(Going Green, GG) 은 중고 전자제품을 재활용하고 재판매하는 사업체인 체인 고잉 그린의 아키텍처를 설계하는 예제 카타입니다.

GG는 공용 키오스크와 웹사이트 모두에서 중고 전자제품을 사고팝니다. 키오스크와 웹사이트는 동일한 시스템을 실행합니다. 사용자가 기기(device) 모델 번호와 상태를 시스템에 업로드하면 GG가 적절한 구매가(견적)를 제시합니다.

flowchart LR
    UI["공용 사용자<br/>인터페이스"]
    UI --> Q["견적 제시"]
    Q -->|좋은 가격이면| SHIP["기기 발송"]
    SHIP --> ASSESS["기기 평가"]
    ASSESS --> PAY["대금"]
    PAY --> RESELL["재판매"]
    PAY --> REUSE["재활용"]
    REUSE --> ACCT["재활용/회계"]

아키텍처 특성들을 분석해 보니 특성들이 세 그룹으로 뚜렷하게 나뉩니다.

퀀텀	포함 기능	필요한 아키텍처 특성
고객 대면(견적, 상태)	견적, 물품 상태 서비스	확장성, 가용성, 민첩성
전자제품 평가	평가 서비스	유지보수성, 배포성, 테스트성, 민첩성
재활용/보고/회계	입고, 재활용, 회계, 보고 서비스	보안, 데이터 무결성, 감사성(auditability)

flowchart LR
    subgraph Q1["고객 대면(견적, 상태)"]
        확장성
        가용성
        민첩성_1["민첩성"]
    end
    subgraph Q2["전자제품 평가"]
        유지보수성
        테스트성
        민첩성_2["민첩성"]
    end
    subgraph Q3["재활용, 보고, 회계"]
        보안
        데이터_무결성["데이터 무결성"]
        감사성
    end

    style Q1 fill:#e1f5fe,stroke:#0288d1
    style Q2 fill:#f3e5f5,stroke:#7b1fa2
    style Q3 fill:#fff3e0,stroke:#ef6c00

이 세 그룹이 서로 다른 퀀텀을 형성하는 이유를 살펴보면:

• 고객 대면 부분은 사용자가 직접 상호작용하므로 확장성과 가용성이 핵심입니다.
• 전자제품 평가 부분은 새로운 모델이 지속적으로 출시되므로 빠르게 갱신할 수 있어야 합니다. 빠르게 갱신할수록 더 가치 있는(따라서 더 많이 재판매할 수 있는) 기기를 재판매할 수 있습니다.
• 재활용/보고/회계 부분은 재무 데이터를 다루므로 보안과 감사성이 중요합니다.

이런 아키텍처 특성들은 상충할 때가 많습니다. 예를 들어 감사성 같은 업무지원 관심사를 중요시하면서 빠른 배포성을 달성하기란 어렵습니다. 그리고 UI는 시스템의 다른 부분과는 완전히 다른 수준의 확장성을 요구합니다.

모든 특성을 충족하려 드는 것보다는, 아키텍처 특성 그룹들을 지침으로 삼아서 퀀텀들을 분리하는 것이 바람직합니다. 특성 범위를 서비스 세분도 결정을 위한 지침으로 사용하면 가장 유의한 트레이드오프 집합을 결정하는 데 도움이 됩니다.

flowchart TB
    subgraph Q1["퀀텀 1: 고객 대면"]
        QUOTE["견적 서비스"] --- QDB1[("DB")]
        STATUS["물품 상태 서비스"] --- QDB2[("DB")]
    end

    subgraph Q2["퀀텀 2: 전자제품 평가"]
        ASSESS2["평가 서비스"] --- ADB[("DB")]
    end

    subgraph Q3["퀀텀 3: 재활용/보고/회계"]
        RCV["입고 서비스"] --- RDB1[("DB")]
        RCY["재활용 서비스"] --- RDB1
        ACCT2["회계 서비스"] --- RDB2[("DB")]
        RPT["보고 서비스"] --- RDB2
    end

    style Q1 fill:#e1f5fe,stroke:#0288d1
    style Q2 fill:#f3e5f5,stroke:#7b1fa2
    style Q3 fill:#fff3e0,stroke:#ef6c00

범위와 클라우드

클라우드 기반 자원들은 시스템의 운영 아키텍처 특성들 대부분을 캡슐화하기 때문에 상황을 복잡하게 만듭니다. 아키텍트는 배포 모델에 따라 적어도 다음 두 시나리오를 고려해야 합니다.

클라우드를 컨테이너 호스팅에 사용

많은 개발 팀이 클라우드를 일종의 대안 운영 센터(alternate operations center)로 삼아서, 서버용 컨테이너들을 클라우드에서 실행하고 오케스트레이션합니다. 이런 상황에서 아키텍트는 컨테이너의 아키텍처 특성과 오케스트레이션 도구(쿠버네티스 등)에 의한 제약조건들을 고려해야 합니다.

예를 들어, Spring Boot 애플리케이션을 Docker 컨테이너로 패키징해서 EKS(AWS)나 GKE(GCP) 위에 배포하는 경우입니다. 이때 아키텍트가 설계한 확장성 특성은 쿠버네티스의 Pod 리소스 제한, HPA(Horizontal Pod Autoscaler) 설정, 노드 스케일링 정책 같은 오케스트레이션 계층의 제약을 받습니다. 아키텍처 자체는 기존과 동일하되, 운영 환경이 클라우드로 바뀐 형태입니다.

클라우드 제공업체의 자원을 시스템 구성요소로 활용

클라우드 기반 시스템의 또 다른 방식은 트리거 함수나 데이터베이스 등 클라우드 제공업체가 제공하는 구성요소들을 조합해서 애플리케이션을 만드는 것입니다. 이 경우 아키텍트는 클라우드 제공업체가 광고하는 역량들을 잘 살펴보면서 해당 맥락 안에서 적절한 역량들을 구축하는 방법에 관한 통찰을 얻어야 합니다.

예를 들어, API Gateway + Lambda + DynamoDB + SQS를 조합해서 서버리스 애플리케이션을 만드는 경우입니다. 탄력성이나 가용성 같은 운영 특성을 직접 구현하는 대신 AWS가 제공하는 관리형 서비스에 위임합니다. 하지만 이때 아키텍트는 Lambda의 콜드 스타트 지연, DynamoDB의 처리량 제한, 특정 제공업체에 대한 종속(vendor lock-in) 같은 트레이드오프를 함께 고려해야 합니다.

요즘 클라우드 제공업체가 흔히 기본으로 제공하는 여러 역량(탄력성 등) 중 상당수는 물리적 시스템에서 작업하던 이전 세대 아키텍트들이 어렵게 얻어낸 것입니다. 이들이 애쓰던 주요 관심사들은 이제 좀 더 쉽게 해결할 수 있게 되었지만, 현재의 아키텍트들에게도 공급업체의 가용성과 높아진 보안 우려 등 나름의 트레이드오프들이 있습니다. 소프트웨어 아키텍처의 세부 사항은 많이 변하지만, 트레이드오프를 분석하는 작업은 변하지 않습니다.

정리

관점	시스템 수준 특성	퀀텀 수준 특성
적용 범위	시스템 전체에 동일 적용	서비스/컴포넌트 그룹별 차별 적용
적합한 아키텍처	모놀리스	분산 (마이크로서비스, 이벤트 주도 등)
데이터베이스	단일 공유 DB	서비스별 개별 DB 가능
복잡도	낮음 (하나의 특성 집합 관리)	높음 (퀀텀별 특성 관리 + 통신 고려)
독립 배포	어려움	가능

결합 유형	성격	변경 가능성	예시
의미적 결합	도메인 고유, 불가피	변경 불가	주문-재고-결제의 관계
구현 결합	아키텍트 결정 사항	설계로 변경 가능	DB 분리 여부
정적 결합	배선(의존관계)	리팩터링으로 변경	공유 라이브러리 의존
동적 결합	런타임 통신	동기/비동기 선택	서비스 간 API 호출

내 생각

• 퀀텀 개념의 실질적인 가치는 “이 서비스들이 정말 같은 특성 집합을 필요로 하는가?”라는 질문을 강제하는 데 있습니다. 모놀리스에서 마이크로서비스로 전환할 때 서비스 경계를 어디에 그을지 결정하는 기준으로 활용할 수 있습니다.
• 고잉 그린 예제처럼 아키텍처 특성이 상충하는 영역을 분리하는 것은 실무에서도 자주 마주치는 패턴입니다. 특히 고객 대면 vs 백오피스 시스템은 거의 항상 다른 특성 집합을 요구합니다.
• 클라우드 환경에서 퀀텀 경계는 곧 비용 경계이기도 합니다. 확장성이 필요한 서비스만 오토스케일링 대상으로 두고, 그렇지 않은 서비스는 고정 인스턴스로 운영하는 것이 비용 효율적입니다.

관련 개념

• Ch04 아키텍처 특성의 정의
• Ch05 아키텍처 특성의 식별
• Ch06 아키텍처 특성의 측정과 거버넌스
• Ch03 모듈성
• Ch18 마이크로서비스 아키텍처
• Ch15 이벤트 주도 아키텍처

출처

• Fundamentals of Software Architecture (Mark Richards, Neal Ford) — Chapter 7