Ch26 아키텍처 교차점

한 줄 정의

아키텍처가 제대로 작동하려면 구현, 인프라, 데이터 토폴로지, 엔지니어링 관행, 팀 토폴로지, 시스템 통합, 엔터프라이즈 표준, 비즈니스 환경, 생성형 AI라는 9개 측면과 정렬되어야 하며 이 정렬 지점들을 아키텍처 교차점 (architectural intersection)이라고 부릅니다.

쉽게 말하면

아키텍처를 잘 그렸다고 해서 시스템이 잘 굴러가는 것은 아닙니다.

별점 5개짜리 마이크로서비스 설계를 골라도 인프라가 못 받쳐주면 확장성은 종이 위에서만 존재하고, DB가 모놀리스면 서비스별 자율성도 사라지며, 팀이 기술 분할로 묶여 있으면 도메인 경계가 깨집니다.

아키텍처는 자기 혼자만 잘해서는 안 되고 9개 다른 영역과 손발이 맞아야 한다는 것이 핵심입니다.

왜 중요한가?

• 해결하는 문제: 아키텍처 스타일을 옳게 골랐는데도 시스템이 실패하는 근본 원인을 설명합니다. 정렬이 어긋난 지점, 즉 오정렬(misalignment)을 찾아내고 고치기 위한 체크리스트를 제공합니다.
• 이게 없다면: 아키텍트는 “아키텍처가 잘못됐다”고 결론 내리고 스타일을 갈아엎는 헛수고를 반복합니다. 실제 문제는 인프라나 팀 구성, DB 토폴로지에 있는데 엉뚱한 곳을 손보는 셈이 됩니다.

핵심 내용

9개 교차점 한눈에 보기

교차점	핵심 질문
구현	소스 코드가 운영 특성, 내부 구조, 제약조건과 정렬되는가?
인프라	배포 방식이 확장성·반응성·내결함성·가용성과 정렬되는가?
데이터 토폴로지	DB 종류와 배치(모놀리스/도메인/서비스별)가 스타일과 맞는가?
엔지니어링 관행	빌드·테스트·배포 파이프라인이 스타일과 부합하는가?
팀 토폴로지	팀 구조가 아키텍처 분할 방식과 맞물리는가?
시스템 통합	외부 시스템과의 통신이 운영 특성을 깨뜨리지 않는가?
엔터프라이즈	조직 표준·관행·지도 원칙과 정렬되는가?
비즈니스 환경	사업의 방향성과 변동성에 맞게 진화 가능한가?
생성형 AI	LLM 도입이 아키텍처에 미치는 영향을 다루었는가?

아키텍처와 구현

소프트웨어 아키텍처의 제1법칙은 “상황에 따라 다릅니다 “. 그리고 두 번째로 흔한 답변은 “그건 구현 세부 사항 (implementation detail)이다”. 아키텍처가 실패할 때 두 번째 답변이 원인이 되는 경우가 많습니다.

구현은 세 가지를 동시에 만족시켜야 합니다.

운영상 관심사 (operational concern)

확장성, 반응성, 내결함성, 가용성 같은 아키텍처 특성을 구현이 실제로 살려내야 합니다.

책의 사례가 인상적입니다. 수십만 동시 접속을 받기 위해 마이크로서비스 를 골랐고, 별점 등급표에 따라 결정도 옳았습니다. 그런데 경계 컨텍스트를 너무 잘게 쪼개는 바람에 Order Placement가 Inventory Management를 동기 호출해야 했고, 이를 풀려고 인메모리 복제 캐시 를 도입했습니다. 결과: 동시 접속 8만 명 시점에 모든 VM에서 OOM이 발생해 시스템이 다운됐습니다.

flowchart LR
    subgraph "확장 시 OOM"
        OP[Order Placement<br/>읽기 전용 복제 캐시]
        IM[Inventory Management<br/>갱신 가능한 인메모리 캐시]
        DB1[(주문 DB)]
        DB2[(재고 DB)]
        IM -.복제.-> OP
        OP --> DB1
        IM --> DB2
    end

아키텍처는 확장성·탄력성을 노렸는데 구현은 반응성·서비스 분리에 집중했습니다. 둘 다 자기 관점에서는 옳은 결정이었지만 서로 다른 목표를 추구한 것이 문제의 본질입니다.

구조적 무결성 (structural integrity)

논리적 컴포넌트는 보통 소스 저장소의 디렉터리 구조 또는 이름공간으로 표현됩니다. 따라서 소스 코드 구조가 논리적 아키텍처와 어긋나면 유지보수성·테스트성·배포성이 무너집니다.

해결책은 자동화된 거버넌스 도구 입니다. 자바의 ArchUnit, .NET의 ArchUnitNet/NetArchTest, 파이썬의 PyTestArch, 타입스크립트/자바스크립트의 TSArch 같은 도구로 디렉터리 의존 규칙을 코드로 강제합니다.

오정렬 vs 정렬 비교

핵심은 영역 간 의존이 얼마나 얽혀 있는가 입니다. 같은 기능을 구현해도 모듈 경계가 모호하고 화살표가 사방으로 튀면 한 곳을 고칠 때 영향 범위가 폭발합니다. 반대로 영역이 깔끔히 분리되고 의존이 단방향이면 변경 영향이 국지적으로 묶입니다.

flowchart TB
    subgraph misalign["오정렬: 경계가 무너진 의존"]
        subgraph subA[구독자]
            a1[정보]
            a2[새 티켓]
        end
        subgraph subB[티켓]
            b1[전문가]
            b2[티켓 상태]
        end
        subgraph subC[완료]
            c1[이메일 알림]
        end
        a1 <--> b1
        a2 --> b2
        b2 --> a1
        b1 <--> c1
        c1 --> a2
    end

flowchart TB
    subgraph align["정렬: 경계가 명확한 단방향 의존"]
        subgraph subD[고객]
            d1[고객 등록]
            d2[고객 프로필]
        end
        subgraph subE[티켓 처리]
            e1[티켓 생성]
            e2[티켓 할당]
        end
        subgraph subF[고객 설문]
            f1[설문 전송]
            f2[설문 템플릿]
        end
        d1 --> e1
        e1 --> e2
        e2 --> f1
        f1 --> f2
    end

오정렬 그림은 영역 사이를 양방향 화살표가 가로지릅니다. 이메일 알림이 새 티켓을 다시 만들고, 티켓 상태가 구독자 정보를 수정하는 식입니다. 결과적으로 “티켓 상태 컬럼 하나 바꾸기”가 구독자·완료 영역까지 퍼집니다.

정렬 그림은 화살표가 한 방향으로만 흐르고 영역 경계를 깔끔히 넘습니다. 티켓 처리는 고객 정보를 읽기만 하고, 설문은 티켓 처리의 결과만 받습니다. 한 영역 내부 변경이 다른 영역으로 새지 않습니다.

아키텍처 제약조건 (architectural constraint)

제약조건은 “통신은 REST로만”, “특정 DB만 사용” 같은 지배적 규칙입니다. 계층형 아키텍처라면 다음과 같은 제약을 명시해야 합니다.

• 모든 데이터베이스 로직은 반드시 영속성 계층 에 있어야 합니다.
• 표현 계층 은 영속성 계층에 직접 접근할 수 없습니다.

UI 개발자가 빠르다고 DB를 직접 호출하기 시작하고, 백엔드 개발자도 비즈니스 계층에서 DB 로직을 섞으면 단순한 컬럼명 변경 하나가 모든 계층에 파급됩니다. 자동화 거버넌스 도구가 여기서도 유용합니다.

아키텍처와 인프라

2000년대 중반까지 아키텍처와 운영의 관계는 SLA에 기반한 형식적 관계였고, 운영은 자주 서드파티에 아웃소싱됐습니다. 마이크로서비스 같은 현대적 스타일은 예전에는 운영의 영역이었던 탄력적 확장 (elastic scaling)을 아키텍트와 데브옵스의 협업으로 처리합니다.

Pets.com의 교훈

탄력적 확장이 그냥 똑똑한 한 명이 발명한 것이 아니라 비싼 교훈에서 나온 개념임을 보여주는 사례입니다. 1998년 Pets.com은 매력적인 양말 인형 마스코트로 마케팅에 모든 돈을 쏟았지만 인프라 준비를 못 했고, 주문 폭주 → 사이트 지연 → 트랜잭션 유실 → 배송 지연 → 크리스마스 직후 폐업이라는 시나리오로 무너졌습니다.

지나친 성공이 오히려 비즈니스를 죽인다 는 현상의 희생양이 된 것입니다.

클라우드 환경에서도 정렬은 깨질 수 있습니다

• 여러 리전·가용 영역에 분산하면 인메모리 복제 캐시 의 성능 이점이 감쇄·상쇄됩니다.
• 반대로 서비스·컨테이너·쿠버네티스 파드를 동일 VM에 몰면 성능은 좋아지지만 확장성·내결함성·가용성·탄력성이 나빠집니다.

데브옵스가 이 교차점에 등장한 이유 자체가 아키텍트와 인프라 책임자 사이의 소통·협업 부족으로 인한 오정렬을 메우기 위함이었습니다.

아키텍처와 데이터 토폴로지

자주 간과되지만 매우 자주 시스템을 무너뜨리는 교차점입니다.

데이터베이스 토폴로지

flowchart TB
    subgraph 모놀리스["모놀리스 DB"]
        UI1[UI] --> C1[컴포넌트들] --> D1[(단일 DB)]
    end
    subgraph 도메인["분산 도메인 DB"]
        UI2[UI] --> C2[컴포넌트들] --> D2A[(도메인 A DB)]
        C2 --> D2B[(도메인 B DB)]
    end
    subgraph 서비스별["분산 서비스별 DB"]
        UI3[UI] --> S1[svc] --> D3A[(svc1 DB)]
        UI3 --> S2[svc] --> D3B[(svc2 DB)]
        UI3 --> S3[svc] --> D3C[(svc3 DB)]
    end

마이크로서비스가 모놀리스 DB를 공유하면 경계 컨텍스트 가 무너지고 변경 제어가 극도로 어려워집니다. 내결함성·확장성·탄력성·유지보수성·테스트성·배포성이 모두 나빠집니다.

서비스 기반 아키텍처는 DB 토폴로지 측면에서 좀 더 유연합니다.

아키텍처 특성과 DB 유형의 정렬

DB 유형	강점(★4~5)	잘 맞는 스타일
관계형	일관성, 트랜잭션	모놀리스, 계층형
키-값	확장성, 탄력성	마이크로서비스, 공간 기반
문서	확장성	마이크로서비스, EDA
컬럼형	확장성, 탄력성, 대량 쓰기	마이크로서비스
그래프	관계 탐색	도메인 특화
NewSQL	확장성 + ACID	마이크로서비스, 공간 기반

데이터의 구조

데이터 구조에 맞는 DB를 골라야 합니다. 하나의 아키텍처 안에 여러 구조가 공존할 수 있으므로 폴리글랏(polyglot) 데이터베이스, 즉 데이터 구조에 따라 다른 DB 제품을 섞어 쓰는 접근이 합리적입니다.

• 관계형 데이터 → PostgreSQL
• 키-값 → Redis
• 그래프 → Neo4J
• 다중 모델 DB(multi-model)로 한 제품에서 여러 형식을 다루는 것도 가능합니다.

읽기/쓰기 우선순위

• 대량 쓰기 우선 → 컬럼형 DB
• 대량 읽기 우선 → 키-값/문서/그래프 DB
• 읽기·쓰기 비슷 → 관계형/NewSQL DB

아키텍처와 엔지니어링 관행

프로세스 vs 엔지니어링 관행

둘을 분리해서 보는 것이 도움이 됩니다.

• 프로세스: 팀 구성, 회의 진행, 작업흐름 같은 사람·조직 메커니즘 (스크럼, XP, 칸반)
• 엔지니어링 관행 (engineering practice): CI, CD, TDD처럼 프로세스와 무관한, 검증된 기술·도구

폭포수 같은 비반복적 프로세스로 마이크로서비스를 만들면 마찰이 폭발합니다. 반복적 프로세스가 아키텍처와 잘 맞는 이유는 교살자 무화과 패턴 (Strangler Fig Pattern), 기능 토글 같은 기법을 장려해 변화에 잘 대응하기 때문입니다.

진화적 아키텍처(evolutionary architecture)와 적합성 함수

특정 기준을 충족하도록 시스템을 설계해도 변화의 행진 속에서 그 설계가 살아남는다는 보장이 없습니다. 아키텍처 적합성 함수 (architectural fitness function)는 특정 아키텍처 특성의 무결성을 객관적으로 평가하는 수단입니다. 지표 측정, 단위 테스트, 모니터, 카오스 엔지니어링 등이 포함됩니다.

시장 출시 기간(time to market) = 민첩성 (agility) = 유지보수성·테스트성·배포성의 복합 특성입니다. 이 세 가지가 모두 엔지니어링 관행의 영향을 받으므로 적합성 함수로 측정·추적할 수 있습니다.

마이크로서비스 아키텍처에는 머신 프로비저닝, 테스트, 배포 같은 작업을 자동화할 것이라는 가정이 깔려 있습니다. 구식 운영 그룹과 수동 프로세스로 마이크로서비스를 구축하려 하면 실패할 가능성이 높습니다.

아키텍처와 팀 토폴로지

가장 기본적인 정렬 방법: 아키텍처의 분할 유형에 따라 팀 토폴로지를 선택 하는 것입니다.

도메인 분할 → 교차 기능 팀

UI부터 DB까지 고객 관련 기능성의 종단 간(end-to-end) 처리를 책임지는 스트림 정렬 팀 (기능 전담 팀) 형태가 자연스럽습니다. 마이크로서비스나 모듈형 모놀리스와 잘 어울립니다.

기술적 분할 → 기능별 팀

UI 팀, 백엔드 팀, 공유 서비스 팀, DB 팀으로 나누는 방식. 계층형 아키텍처와 잘 맞습니다.

비즈니스 기능 팀 + 데이터 동기화 팀

공간 기반 아키텍처와 잘 어울리는 패턴입니다.

조직의 팀 토폴로지가 아키텍처와 정렬되지 않으면 팀들이 아키텍처를 구현·유지하는 데 어려움을 겪고 결국 비즈니스 목표를 달성하지 못할 가능성이 높습니다.

아키텍처와 시스템 통합

호출되는 시스템의 가용성·확장성·성능이 호출하는 시스템과 동등하지 않으면 아키텍처의 운영 특성이 그쪽에서 깎입니다.

통합 시 고려해야 할 것

• 통신 프로토콜 선택
• 시스템 간 계약(contract)의 형태
• 아키텍처 특성의 호환성
• 통합이 각 시스템의 아키텍처 퀀텀 을 보존하는가?

이 교차점에 충분히 집중하지 않으면 시스템 간 정적·동적 결합도가 높아지고 확장성·반응성·민첩성이 동시에 나빠집니다.

아키텍처와 엔터프라이즈

엔터프라이즈는 회사(또는 한 부서·사업부)에 속한 모든 시스템과 제품의 집합입니다. 보안 표준, 플랫폼·기술 표준, 문서화·다이어그램 표준 등을 시스템 유형과 관계없이 강제하는 회사가 많습니다.

엔터프라이즈 수준의 관행·표준·절차를 무시한 아키텍처는 기술적으로 아무리 효과적이어도 ‘일회성’ 솔루션 으로 간주되어 폐기되기 십상입니다.

아키텍처와 비즈니스 환경

도메인-아키텍처 동형성 (domain-to-architecture isomorphism)

비즈니스의 위치와 방향을 이해하고 핵심 시스템 아키텍처를 비즈니스 환경에 맞게 정렬하는 원칙입니다.

• 극심한 비용 절감 중인 회사 → 마이크로서비스/공간 기반은 부적합 (구축·유지 비용이 큽니다)
• 인수합병으로 공격적으로 확장하는 회사 → 모놀리스는 부적합 (진화·적응 능력 부족)

알려지지 않은 변화 (unknown change)

도널드 럼즈펠드의 유명한 분류:

• 기지의 기지 (known knowns)
• 기지의 미지 (known unknowns)
• 미지의 미지 (unknown unknowns) ← 소프트웨어의 천적

‘빅 디자인 업 프런트’(Big Design Up Front)가 고통스러운 이유가 바로 미지의 미지 때문입니다.

잔여성 이론 (residuality theory)

배리 오라일리(Barry O’Reilly)가 제시한 사고방식. 비즈니스 변화를 스트레스 요인 (stressor)으로, 그에 상응하는 아키텍처 변경을 잔여물 (residue)로 다루는 기법입니다. 잔여물이 누적되면 아키텍처가 복잡성 이론의 임계 상태(critical state)에 도달한다는 이론입니다.

아키텍처와 생성형 AI

생성형 AI를 아키텍처에 도입

도입할 때 추천하는 접근법: 추상화 (abstraction)와 모듈성 (modularity).

• 한 LLM을 다른 LLM으로 신속하게 교체할 수 있는 능력이 핵심입니다.
• 다양한 LLM에 가드레일 (guardrail)을 설정하고 결과를 평가(eval)할 수 있어야 합니다.
• Langfuse 같은 도구로 LLM 관측성(observability)을 구축합니다.

이력서 익명화 사례: 표본(sample)과 지표를 수집하고 여러 LLM 엔진을 비교할 수 있는 능력이 중요합니다. 너무 많이 지우면 정보가 사라지고, 너무 적게 지우면 편향이 남습니다.

아키텍트를 보조하는 생성형 AI

LLM은 결정론적 코드 생성(“중복 없는 4자리 PIN 생성기 작성”)에는 탁월합니다. 하지만 아키텍처 질문에는 약합니다.

• 위험 평가: “이 아키텍처에 위험 영역이 있는가?”
• 위험 완화: “이 위험을 어떻게 해결해야 할까?”
• 안티패턴: “이 아키텍처에 흔한 안티패턴이 있는가?”
• 결정: “이 작업흐름에 오케스트레이션과 코레오그래피 중 무엇을 사용해야 할까?”

소프트웨어 아키텍처의 모든 것은 트레이드오프 이기 때문입니다. LLM은 지식 (knowledge)을 이해하지만 지혜 (wisdom)는 부족합니다.

유망한 도구로 소트웍스 헤이븐 (Haiven)이 있습니다. 아키텍처 다이어그램을 사람이 XML로 변환할 필요 없이 그대로 입력해 병목·문제점을 질문할 수 있습니다. PlantUML을 ArchUnit 코드로 변환해 구조를 통제하려는 시도도 있습니다.

비교 / 트레이드오프

9개 교차점의 영향 범위

교차점	주된 영향 영역	정렬 깨졌을 때 증상
구현	코드 품질, 운영 특성	메모리 부족, 응답 지연
인프라	운영 특성 실현	확장 한계, 가용성 저하
데이터 토폴로지	변경 제어, 확장성	모놀리스 DB 결합
엔지니어링 관행	민첩성	배포 마찰, 회귀
팀 토폴로지	구현 속도	팀 간 충돌, 인지 부하
시스템 통합	결합도	외부 시스템에 발목 잡힘
엔터프라이즈	채택 가능성	폐기되는 일회성 솔루션
비즈니스 환경	적합성, 진화성	사업과 따로 노는 시스템
생성형 AI	미래 적응성	LLM 종속, 평가 부재

데이터 토폴로지 정렬 차이

flowchart LR
    subgraph 정렬됨[정렬됨]
        MS1[마이크로서비스] --> SDB1[(서비스별 DB)]
    end
    subgraph 어긋남[오정렬]
        MS2[마이크로서비스] --> MDB[(공유 모놀리스 DB)]
        MDB -.컬럼명 변경.-> 모든서비스
    end

오정렬 케이스에서 컬럼명 하나 바꾸려면 모든 서비스를 동시 배포해야 합니다. 마이크로서비스의 핵심 가치인 독립 배포 가 무너집니다.

내 생각

”아키텍처가 잘못됐다”는 진단의 함정

이 챕터에서 가장 크게 와닿은 것은, 시스템이 안 돌아갈 때 우리가 가장 먼저 의심하는 “아키텍처 스타일이 틀렸나?”라는 질문이 대부분 오진이라는 점입니다. Order Placement/Inventory Management 사례에서 마이크로서비스 선택 자체는 옳았습니다. 무너진 건 구현과 인프라가 아키텍처가 노린 운영 특성과 정렬되지 않았다는 사실이었습니다. 시스템이 실패할 때 스타일을 갈아엎기 전에 9개 교차점부터 한 번 훑어보는 습관이 필요합니다.

”구현 세부 사항”은 핑계가 아니다

“그건 구현 세부 사항이다”는 자주 책임 회피의 도구로 쓰이지만, 이 책은 그 구현 세부 사항이 아키텍처의 성패를 결정한다고 못박습니다. 다이어그램은 그대로인데 동기 호출 한 줄이 시스템을 무너뜨릴 수 있다면 아키텍트는 코드를 봐야 합니다. 이 관점은 Ch24 유능한 팀 만들기에서 말한 “아키텍트가 손을 더럽혀야 한다”와 정확히 같은 결론에 도달합니다.

도메인-아키텍처 동형성이 가장 인상적

도메인-아키텍처 동형성(domain-to-architecture isomorphism) 개념이 가장 신선했습니다. “회사가 비용 절감 중이면 마이크로서비스를 쓰지 마라”라는 실무 조언은 기술 트렌드만 좇는 의사결정에 대한 강한 반례입니다. 아키텍처 결정이 단순히 기술적 트레이드오프가 아니라 회사가 처한 비즈니스 국면과 정렬되어야 한다는 시각은 시니어로 갈수록 더 중요해질 사고방식입니다.

”지식과 지혜는 다르다”

LLM은 지식(knowledge)에는 강하지만 지혜(wisdom)에는 약하다는 표현이 정곡을 찌릅니다. PIN 생성기 같은 결정론적 문제는 LLM이 잘 풀지만 “마이크로서비스 vs 공간 기반 중 무엇이 적합한가” 같은 트레이드오프 질문은 LLM이 답하지 못합니다. 이는 아키텍트의 일이 LLM으로 자동화될 영역이 아님을 의미합니다. 동시에 잔여성 이론(residuality theory)이 시사하듯, 아키텍트의 일은 점점 더 “예측”이 아니라 “변화 흡수 능력 설계”로 이동하고 있습니다.

더 알아볼 것

• ArchUnit으로 자동화된 거버넌스 규칙 작성해보기
• Building Evolutionary Architectures (정병열 옮김, 한빛미디어, 2023) 읽고 적합성 함수 직접 구현
• 잔여성 이론 - Residues: Time, Change, and Uncertainty in Software Architecture (Leanpub, 2024)
• Langfuse로 LLM 관측성 구축
• Haiven 도구로 아키텍처 다이어그램 분석 시도
• 폴리글랏 DB 적용 사례 (PostgreSQL + Redis + Neo4J 조합)

관련 개념

• Ch08 컴포넌트 기반 사고
• Ch10 계층형 아키텍처
• Ch14 서비스 기반 아키텍처
• Ch15 이벤트 주도 아키텍처
• Ch16 공간 기반 아키텍처
• Ch18 마이크로서비스 아키텍처
• Ch21 아키텍처적 결정
• Ch22 아키텍처 위험 분석
• Ch24 유능한 팀 만들기
• Ch25 협상과 리더십 스킬

출처

• 마크 리처즈, 닐 포드, 『소프트웨어 아키텍처 The Basics』 26장 “아키텍처 교차점”
• Neal Ford et al., 『Building Evolutionary Architectures』 (O’Reilly, 2022)
• Barry O’Reilly, 『Residues: Time, Change, and Uncertainty in Software Architecture』 (Leanpub, 2024)