팀 토폴로지

학습 목표

Conway's Law가 아키텍처·조직에 미치는 영향을 설명할 수 있다.

Team Topologies 4유형(stream-aligned·platform·enabling·complicated-subsystem)을 구분할 수 있다.

상호작용 모드(collaboration·X-as-a-Service·facilitating)를 팀 설계에 적용할 수 있다.

앞서 본 MSA·Bounded Context와 팀 경계를 정렬하는 방법을 설명할 수 있다.

문제 상황

• 마이크로서비스 12개인데 팀은 프론트 / 백엔드 / DBA — 서비스 소유 없음
• 플랫폼 팀이 배포 티켓 만 — stream 팀 대기 3일
• 주문 장애에 결제·재고·알림 팀 동시 소집 — 엔드투엔드 오너 없음
• 아키텍트 4명이 모든 PR gate — 병목
• CDC·검색 인덱스 전문 팀 없음 — 각 팀이 반쯤 구현
• ADR·평가 프로세스는 있는데 누가 배포 단위 소유하는지 불명

ADR 운영까지 갖췄다. 구조를 배포·변경하는 조직이 따라오지 않으면 MSA는 분산 모놀리스가 된다.

1. Conway's Law

Conway's Law — 시스템 구조는 조직 의사소통 구조를 반영한다.

정렬됨	어긋남
Order 팀 → Order API + DB + 이벤트	백엔드 팀 → 모든 API
결정·배포 한 팀	3팀 핸드오프 per 기능
장애 오너 명확	RCA 회의만 **길어짐

organizations which design systems are constrained to produce
designs which are copies of the communication structures
of these organizations  — Melvin Conway (1968)

• 아키텍처 먼저 바꾸고 조직 그대로 → 인위적 경계 무너짐
• 역설계 — 현재 코드 의존 그래프가 실제 팀 대화 맵
• 앞서 MSA 분해 기준에 팀 ownership이 있었던 이유

2. Team Topologies 4유형

Team Topologies(Skelton & Pais) — 스트림 가치 전달과 인지 부하 분산.

유형	역할	예
Stream-aligned	가치 흐름 엔드투엔드 전달	주문·결제 여정 한 팀
Platform	stream 팀 부담 감소 — 자기 서비스 API	K8s·Kafka·CI·golden path
Enabling	임시 코칭·능력 전이	ADR·ATAM 워크숍
Complicated-subsystem	높은 전문성 하위 시스템	CDC·ML·레거시 메인프레임

원칙
대부분 stream-aligned	고객·비즈니스 흐름 중심
Platform은 티켓 부서 아님	제품처럼 문서·SLA·셀프서비스
Enabling은 상주 아님	목표 달성 후 철수
Complicated-subsystem 최소	정말 어려운 것만

3. 상호작용 모드

모드	언제	예
Collaboration	높은 불확실·공동 탐색	신규 도메인 분해 초기
X-as-a-Service	안정 인터페이스·반복 소비	stream → platform Kafka provision API
Facilitating	역량 전이 필요	enabling → stream 테스트 자율화

• 영구 Collaboration — 경계 흐림 → 모놀리스 의사소통
• Platform 기본 = X-as-a-Service — 대기열 최소
• 앞서 API 계약·이벤트 카탈로그가 X-as-a-Service 표면

4. 쇼핑 플랫폼 팀 맵

앞서 C4 Container·서비스 맵을 팀에 매핑.

organization: shop-platform
topology_version: 2026-q3

teams:
  - id: order-stream
    type: stream-aligned
    mission: end-to-end checkout slice for order placement
    owns:
      - Order API
      - order PostgreSQL
      - order.events topic
      - PlaceOrder UX backend-for-frontend
    consumes:
      - platform.kafka
      - platform.k8s-deploy
      - catalog-api.read-contract

  - id: commerce-stream
    type: stream-aligned
    mission: catalog browse and payment settlement
    owns:
      - Catalog API
      - Payment API
      - catalog Redis
      - payment PostgreSQL
    consumes:
      - platform.kafka
      - platform.observability
      - payment-pg.external

  - id: fulfillment-stream
    type: stream-aligned
    mission: inventory reservation and notification after order events
    owns:
      - Inventory API
      - Notification service
    consumes:
      - order.events
      - platform.messaging

  - id: platform
    type: platform
    mission: reduce cognitive load for stream teams
    provides:
      - Kubernetes clusters and golden path templates
      - Kafka cluster and topic provisioning
      - CI pipelines and observability baselines
      - internal developer portal
    interaction_mode: x-as-a-service

  - id: data-platform
    type: complicated-subsystem
    mission: CDC pipelines and analytics projections
    owns:
      - Debezium connectors
      - search index sync jobs
    serves:
      - commerce-stream
      - fulfillment-stream

  - id: architecture-enabling
    type: enabling
    mission: temporary lift for architecture practices
    activities:
      - ADR review facilitation
      - lightweight ATAM workshops
      - team topology health checks
    interaction_mode: facilitating

alignment_rules:
  - one stream team per primary user journey slice
  - no shared database ownership across stream teams
  - platform exposes self-service APIs not ticket queues
  - complicated-subsystem teams publish contracts not org-wide gatekeeping

팀	유형	소유·제공
order-stream	stream-aligned	Order API·DB·이벤트
commerce-stream	stream-aligned	Catalog·Payment
fulfillment-stream	stream-aligned	Inventory·Notification
platform	platform	K8s·Kafka·CI·observability
data-platform	complicated-subsystem	CDC·검색 projection
architecture-enabling	enabling	ADR·평가 코칭

• order-stream — 앞서 outbox·PlaceOrder 흐름 한 배포 단위
• data-platform — 앞서 CDC 파이프라인 전문 집중
• architecture-enabling — 23편 ADR 실전 퍼실리테이션

5. 조직·아키텍처 정렬 절차

단계	행동
1	가치 스트림·사용자 여정 식별
2	Bounded Context·서비스 맵 그리기
3	stream-aligned 팀 1:1 후보 매칭
4	Platform 백로그 — stream 설문 pain
5	Complicated 영역만 별도 팀
6	ADR로 팀 경계 변경 기록

신호	조치
모든 변경에 4팀 회의	stream 재정의
Platform 대기 일수 증가	셀프서비스 API
같은 DB 스키마 공동 수정	서비스·팀 분리
Enabling 팀 1년 상주	철수 계획

• 조직 변경도 ADR·평가 대상 — 구조만 바꾸지 않음
• Strangler·분해는 다음 편 — 팀 맵이 선행

6. 안티패턴

안티패턴	증상	대안
Component 팀	FE/BE/QA 분리	stream-aligned
Platform 게이트키퍼	모든 배포 승인	golden path 셀프서비스
공유 ownership	아무도 책임 안 짐	단일 팀 소유
나노 팀	1인 1서비스 × 20	적절 크기 stream
아키텍트 중앙 결재	PR 정체	enabling + ADR 가이드

7. 실무 체크리스트

질문	좋은 답
팀 수 vs 서비스?	stream 기준 — 서비스 수 아님
Platform 성공?	stream lead time·대기 감소
Conway 점검?	의존 그래프 vs 팀 대화 맵
Enabling 종료?	명시 목표·기간
문서?	team-topology-map.yaml + C4 갱신

8. 정리

• Conway — 조직 없이 MSA 지속 불가
• 4유형 — stream 중심, platform 제품화, enabling 임시
• 상호작용 — 협업 최소화, 계약 소비 확대
• 쇼핑 예 — 여정·CDC·플랫폼 분리
• Part 7 — 다음은 레거시 마이그레이션

다음에 다룰 것

• 레거시 마이그레이션
• strangler fig, branch by abstraction, 단계적 분해

---

해당 내용은 Team Topologies (Matthew Skelton, Manuel Pais) 및 Fundamentals of Software Architecture (Mark Richards, Neal Ford) 의 내용을 기반으로 합니다.