Ch27 소프트웨어 아키텍처 법칙들

한 줄 정의

소프트웨어 아키텍처는 세 가지 보편 법칙 위에 서 있습니다. 모든 결정은 트레이드오프이며, 어떻게보다 왜가 더 중요하고, 대부분의 선택은 양자택일이 아닌 스펙트럼 위의 한 점입니다.

쉽게 말하면

이 책 전체를 한 페이지로 압축하면 세 문장으로 줄어듭니다.

첫째, 공짜 점심은 없습니다. 어떤 결정이든 좋은 점만 골라 가질 수 없고, 반드시 잃는 게 있습니다. 만약 잃는 게 없어 보인다면 아직 못 찾은 겁니다.

둘째, 결정 자체보다 결정의 이유가 더 오래갑니다. 코드와 다이어그램을 보면 “어떻게” 했는지는 알 수 있지만, “왜 그렇게 했는지”는 기록해 두지 않으면 사라집니다. 6개월 뒤의 나조차 그 결정을 의심하게 됩니다.

셋째, 모든 결정은 회색지대입니다. 마이크로서비스냐 모놀리스냐, 동기냐 비동기냐 같은 이분법은 환상입니다. 실제 결정은 두 극단 사이 어딘가의 한 지점이며, 그 위치는 맥락이 결정합니다.

왜 중요한가?

• 해결하는 문제: 아키텍처에는 모범답안집이 없으며, “어떤 스타일이 정답인가”라는 질문 자체가 잘못된 프레임이라는 점을 일깨웁니다.
• 이게 없다면: 아키텍트는 특정 솔루션을 “전도(evangelize)“하는 사람이 됩니다. 어제의 모범관행이 오늘의 안티패턴이 되는 환경에서, 전도는 장기적으로 평판과 신뢰를 갉아먹습니다.

이 챕터가 책의 마지막에 배치된 이유는 단순합니다. 앞에서 다룬 모든 아키텍처 스타일과 패턴, 도구는 결국 이 세 법칙의 사례 모음이기 때문입니다. 1판 집필 시 10~15개의 법칙을 찾을 수 있으리라 기대했지만 두 개만 추출됐고, 2판에서 하나가 추가됐습니다. 그만큼 보편적이고 그만큼 적게 남는 게 진짜 법칙입니다.

핵심 내용

제1법칙: 모든 것은 트레이드오프다

소프트웨어 아키텍트의 진짜 역할은 특정 접근법을 전도하는 사람이 아니라 트레이드오프를 객관적으로 중재하는 사람입니다. 이 평판이 중요한 이유는 두 가지입니다.

첫째, 어제의 모범관행이 내일의 안티패턴이 되기 쉽기 때문입니다. 특정 솔루션에 사회자본(social capital, 동료들과의 관계에서 쌓아온 전문성에 대한 신뢰)을 투자해 두면, 환경이 바뀌어 결정을 뒤집어야 할 때 평판이 함께 무너집니다.

둘째, 의사결정권자들은 열정적인 옹호보다 냉정한 객관성을 원합니다. 결정이 중요할수록 “이 사람의 분석은 신뢰할 수 있다”는 평판이 자산이 됩니다.

사례 1: 공유 라이브러리 대 공유 서비스

분산 아키텍처에서 공통 기능을 어떻게 처리할지의 딜레마입니다. 실행 시점에 호출하는 공유 서비스(서비스 A,B,C가 공유 서비스 호출)와, 빌드 시점에 각 서비스에 컴파일되는 공유 라이브러리(서비스 A~E가 각자 커스텀 라이브러리 포함) 중 선택해야 합니다.

flowchart LR
    subgraph Lib["공유 라이브러리 방식"]
        SA1[서비스 A] -.- L1((C1~C7))
        SB1[서비스 B] -.- L2((C1~C7))
        SC1[서비스 C] -.- L3((C1~C7))
    end
    subgraph Svc["공유 서비스 방식"]
        SA2[서비스 A] --> SS[공유 서비스<br/>C1,C2,C3]
        SB2[서비스 B] --> SS
        SC2[서비스 C] --> SS
    end

트레이드오프 기준을 7가지로 정리하면 다음과 같습니다.

요인	공유 라이브러리	공유 서비스
이기종 코드 (다중 플랫폼)	−	+
높은 코드 변동성	−	+
변경 사항 버전 관리 능력	+	−
전반적인 변경 위험	+	−
성능	+	−
내결함성	+	−
확장성	+	−

수치로만 보면 라이브러리가 5:2로 우세해 보입니다. 하지만 이것이 “정답”이라는 뜻은 아닙니다. 요인마다 가중치가 다르기 때문입니다. 만약 팀이 다중 플랫폼(Java, Python, Go)으로 작성하는 환경이라면 “이기종 코드” 한 항목의 가중치가 나머지 모두를 뒤집을 수도 있습니다.

백엔드 관점에서

실무에서 이 결정을 내릴 때 가장 자주 마주치는 함정은 “라이브러리로 시작했는데 변동성이 높아서 매번 모든 서비스 재배포해야 하는” 케이스입니다. 인증/인가 같은 횡단 관심사를 라이브러리로 만들면 보안 패치 한 번에 수십 개 서비스를 다시 빌드·배포해야 합니다. 반면 결제 같은 도메인 로직은 변동성이 낮고 추상화 가능한 경우 공유 서비스보다 라이브러리가 안정적입니다. 변동성을 먼저 측정하지 않고 “공유”라는 단어 하나로 결정하면 거의 항상 후회합니다.

사례 2: 동기적 vs 비동기적 메시징 (대기열 vs 토픽)

Trading 서비스가 거래 정보를 Notification, Analytics 서비스에 알리는 구조를 생각해 봅니다.

flowchart LR
    subgraph Q["대기열(점대점)"]
        T1[Trading] --> Q1[(대기열)]
        T1 --> Q2[(대기열)]
        Q1 --> N1[Notification]
        Q2 --> A1[Analytics]
    end
    subgraph TP["토픽(브로드캐스트)"]
        T2[Trading] --> TOP[(토픽)]
        TOP --> N2[Notification]
        TOP --> A2[Analytics]
    end

대기열 방식

장점	단점
소비자마다 다른 메시지를 보낼 수 있다	결합도가 높아진다 (생산자가 소비자를 알아야 함)
대기열마다 처리 현황을 개별 모니터링할 수 있다	Trading 서비스가 다수의 대기열에 연결해야 한다
더 안전하다 (다른 서비스가 엿듣기 어려움)	추가적인 인프라가 필요하다
	확장 능력이 낮다 (새 소비자 추가 시 대기열도 추가)

토픽 방식

장점	단점
결합도가 낮다 (생산자가 소비자를 모름)	모든 소비자가 동일한 메시지를 받아야 한다
Trading이 메시지를 한 번만 생성한다	각 소비자를 개별 모니터링하거나 확장할 수 없다
확장 능력과 진화성이 뛰어나다	덜 안전하다
	확장성 관련 선택지가 더 제한적이다

토픽의 장점은 확장 능력입니다. Compliance 서비스 같은 새 소비자가 추가되어도 기존 코드는 건드리지 않고 구독만 추가하면 됩니다. 단점은 **스탬프 결합(stamp coupling)**과 보안입니다. 모든 소비자가 동일한 페이로드를 봐야 하므로 “정말 모두가 모든 메시지를 읽을 권한이 있는가?”라는 질문을 던져야 합니다.

결론

조직 목표에 따라 갈립니다. 보안이 우선이면 대기열, 빠른 성장과 신규 서비스 추가가 잦으면 토픽입니다.

귀결 1: 누락된 트레이드오프

트레이드오프가 아닌 무언가를 발견했다고 생각한다면, 아마도 트레이드오프를 아직 찾아내지 못했을 가능성이 높다.

코드 재사용이 대표 사례입니다. “직접 작성할 코드가 줄어들고 중복이 감소한다”만 보면 단점이 없어 보입니다. 하지만 효과적인 재사용에는 두 조건이 필요합니다.

추상화(abstraction)

여러 지점에서 활용 가능한 형태여야 합니다.

낮은 변동성(low volatility)

자주 바뀌면 안 됩니다. 공통 코드가 변경될 때마다 모든 호출자를 그 변경에 맞춰 조율해야 하기 때문입니다.

이 두 조건이 만나는 영역은 배관(plumbing) 코드입니다. 기술 프레임워크, 라이브러리, 플랫폼이 그 예입니다. 반대로 도메인 코드는 가장 빠르게 바뀌는 부분이므로 최악의 재사용 대상입니다. DDD의 경계 컨텍스트(bounded context)가 다른 컨텍스트의 구현 세부사항을 재사용하지 않는다는 원칙도 같은 맥락입니다.

이것이 오케스트레이션 주도 SOA의 핵심 교훈이기도 합니다. SOA의 철학적 기반이 “코드 재사용 극대화”였는데, 실제로는 모래 늪에서 헤엄치는 경험을 줬습니다. 어떤 변경이든 예측 불가능한 부작용을 시스템 전체로 확산시켰기 때문입니다.

좋은 것만 가질 수는 없는 이유

“결합도가 낮은 마이크로서비스로 민첩성·빠른 배포를 누리면서 동시에 코드 재사용도 많이 하고 싶다”는 요청은 양립 불가능합니다. 코드 재사용은 결합이 있어야 가능합니다. 둘을 모두 원하는 것은 핵심 트레이드오프를 잘못 파악한 사례입니다.

귀결 2: 트레이드오프 분석을 단 한 번만 하고 끝낼 수는 없다

이유는 두 가지입니다.

첫째, 의사결정에 영향을 주는 변수가 수십, 수백 가지입니다. 복잡성, 팀 경험, 예산, 일정 압박 같은 변수가 조금만 바뀌어도 분석 결과가 완전히 달라집니다.

둘째, 이 사실 자체가 아키텍트의 직업 안정성입니다. 아키텍트의 임무는 영구적이고 완벽한 결정을 내리는 게 아니라 트레이드오프 분석 자체를 반복하는 것입니다.

제2법칙: 어떻게(방법)보다 왜(이유)가 더 중요하다

기존 시스템을 보면 “어떻게” 작동하는지는 파악할 수 있습니다. 하지만 원래 아키텍트가 결정 기준을 기록해 두지 않은 한, 왜 그 결정을 내렸는지는 알아내기 어렵습니다.

이것이 아키텍처 다이어그램과 ADR을 함께 사용해야 하는 이유입니다. 다이어그램은 “어떻게”를, ADR은 “왜”를 기록합니다.

‘맥락 벗어남’ 안티패턴

트레이드오프는 이해하지만 현재 맥락에 기초해서 각 항목에 가중치를 부여하는 방법을 모를 때 발생합니다.

앞의 공유 라이브러리 vs 공유 서비스 사례를 다시 봅니다. 객관적 점수만 보면 라이브러리가 5:2로 우세합니다. 하지만 어떤 팀이 다중 플랫폼으로 작성하고 공통 행동방식을 깔끔히 관리하고 싶다면, “이기종 코드”와 “높은 코드 변동성” 두 기준의 우선순위가 훨씬 높아집니다. 이 경우 점수와 무관하게 공유 서비스가 정답입니다.

일반적인(generic) 트레이드오프 분석은 그다지 유용하지 않다. 트레이드오프 분석은 구체적인 맥락에서 수행할 때 비로소 가치가 생긴다.

이게 면접 질문 “마이크로서비스가 좋은가요?”에 “상황에 따라 다릅니다”라고 답해야 하는 진짜 이유입니다.

제3법칙: 대부분의 결정은 양극단 사이의 스펙트럼이다

대부분의 아키텍처적 결정은 양자택일이 아니라 양극단 사이의 스펙트럼에 있는 한 지점이다.

이 법칙은 2판에서 추가됐습니다. 1판에서는 두 법칙만 제시했지만, 점차 결정 기준이 이분법적이지 않다는 사실을 깨달았습니다.

아키텍처 vs 설계, 오케스트레이션 vs 코레오그래피, 토픽 vs 대기열, 공유 라이브러리 vs 공유 서비스 — 모두 깔끔하게 둘 중 하나로 떨어지지 않습니다. 그 기준들은 상당히 복잡한 스펙트럼 위에 놓여 있습니다.

불확실성의 늪

아키텍트는 종종 불완전한 정보에 기초해 중요한 결정을 내려야 합니다. 그리고 모든 정보를 다 가지고 있더라도 결정이 명확하지 않은 경우가 많습니다. 결정이 양극단 사이 어딘가에 존재하기 때문입니다.

백엔드 관점에서

“마이크로서비스로 갈까, 모놀리스로 갈까?”라는 질문 자체가 잘못된 프레임입니다. 실제 결정은 모듈형 모놀리스 → 서비스 기반 → 마이크로서비스로 이어지는 스펙트럼 위에서 “지금 우리 팀과 도메인은 어디쯤이 적당한가”를 묻는 것입니다. 동기 vs 비동기도 마찬가지입니다. 같은 시스템 안에서 결제는 동기, 알림은 비동기, 분석은 비동기 + 배치로 섞이는 게 자연스럽습니다.

마지막 조언

아키텍처에는 정답이나 오답이 없다. 오직 트레이드오프 가 있을 뿐이다. — 닐 포드(Neal Ford)

평생 아키텍처를 설계할 기회가 대여섯 번도 채 되지 않는다면, 훌륭한 아키텍트가 어떻게 탄생하겠는가? — 테드 뉴어드(Ted Neward)

실력 향상의 비결은 연습 입니다. 책 예시 기반의 아키텍처 카타(kata)를 활용하면서, ADR을 함께 남기는 습관이 핵심입니다. 다이어그램만 그리면 “어떻게”만 남고 이야기는 반쪽이 됩니다.

비교 / 트레이드오프

법칙	핵심 메시지	실무에서 깨지는 순간	대응
1. 모든 것은 트레이드오프	잃는 것 없는 결정은 없다	”이 기술은 단점이 없어요”라는 발표를 들을 때	더 찾아본다 (귀결 1)
2. 왜가 더 중요하다	결정 기준이 사라지면 결정도 무용지물	6개월 뒤 “이거 왜 이렇게 했지?”가 시작될 때	ADR + 다이어그램 병행
3. 양극단 사이의 스펙트럼	이분법은 환상이다	”A vs B”로 회의가 흘러갈 때	스펙트럼의 어느 지점인지 묻는다

내 생각

• 세 법칙 중 실무에서 가장 자주 위배되는 건 제2법칙입니다. 한국 회사에서 ADR을 꾸준히 남기는 팀을 거의 본 적이 없습니다. PR 설명에 “왜”를 쓰는 정도로 끝나고, 그마저도 PR이 머지된 뒤에는 검색 가능성이 급격히 떨어집니다. 6개월 뒤 누군가 코드를 보고 “이게 왜 이렇게 됐지?”라고 묻기 시작하면 그때부터 비용이 발생합니다.

• 제3법칙은 면접관 입장에서 “마이크로서비스로 가야 할까요?” 같은 질문을 받았을 때 가장 유용한 프레임입니다. 결정의 축을 “예/아니오”에서 “어느 지점/왜 거기”로 옮기면 대화의 질이 완전히 달라집니다.

• 제1법칙의 “트레이드오프가 안 보이면 더 찾아봐라”는 조언은 시니어로 갈수록 점점 무겁게 다가옵니다. 신기술 도입 제안서에서 “단점이 없다”는 표현을 보면, 거의 항상 도입한 뒤 6개월 안에 그 단점이 드러납니다. 단점을 미리 찾는 능력이 곧 시니어의 가치입니다.

더 알아볼 것

• 실제 회사 코드베이스에서 공유 라이브러리/서비스 비율과 변동성 측정
• 최근 6개월 내 PR/이슈에서 “왜”가 누락된 결정 찾아 ADR로 재작성
• 마이크로서비스 vs 모놀리스 결정을 스펙트럼 위에 그려보기
• 아키텍처 카타 사이트(oreil.ly/EPop7)에서 카타 한 개 풀어보기

관련 개념

• Ch01 서론
• Ch02 아키텍처적 사고
• Ch21 아키텍처적 결정
• Ch15 이벤트 주도 아키텍처
• Ch17 오케스트레이션 주도 서비스 지향 아키텍처
• Ch18 마이크로서비스 아키텍처

출처

• 마크 리처즈, 닐 포드, 『소프트웨어 아키텍처 The Basics』 27장