팀 토폴로지(Team Topologies)
1. 개요
정의: 팀 토폴로지는 매튜 스켈턴(Matthew Skelton)과 마누엘 파이스(Manuel Pais)가 2019년 제시한 조직 설계 모델로, 빠른 소프트웨어 전달 흐름(flow)을 조직의 제1목표로 삼아 네 가지 기본 팀 유형과 세 가지 상호작용 방식으로 팀 구조를 의도적으로 설계하고, 팀의 인지 부하(cognitive load)를 관리 가능한 수준으로 유지함으로써 조직이 만들어 내는 소프트웨어 아키텍처를 원하는 방향으로 유도하는 접근 방식이다.
팀 토폴로지가 등장한 배경은 소프트웨어 전달의 병목이 더 이상 '기술'이 아니라 '조직 구조'에 있다는 현장의 자각이다. 클라우드 네이티브·마이크로서비스·DevOps가 보편화되면서 개별 기술 역량은 상향 평준화되었으나, 팀 간 과도한 의존과 인수인계, 승인 대기, 중앙 집중식 통제가 전달 속도를 갉아먹는 핵심 요인으로 남았다. 전통적인 기능별 조직(개발팀·QA팀·운영팀·DBA팀을 분리)은 하나의 기능을 출시하는 데 여러 팀을 거치게 만들어 리드타임을 늘리고 책임 소재를 흐린다.
두 번째 배경은 콘웨이의 법칙(Conway's Law)에 대한 재해석이다. 콘웨이는 "시스템을 설계하는 조직은 그 조직의 의사소통 구조를 그대로 복제한 설계를 만들어 낸다"고 했는데, 이는 곧 조직도가 아키텍처를 결정한다는 뜻이다. 팀 토폴로지는 이 법칙을 수동적으로 받아들이지 않고, 원하는 아키텍처를 먼저 정의한 뒤 그 모양에 맞게 팀을 배치하는 역콘웨이 기동(Inverse Conway Maneuver)을 전략적으로 활용한다.
세 번째 배경은 인간의 인지 용량에 대한 현실 인식이다. 한 팀이 책임지는 영역(도메인·기술 스택·운영 범위)이 넓어질수록 팀원의 머릿속에 담아야 할 지식의 총량이 늘어나는데, 이 인지 부하가 임계치를 넘으면 품질 저하·전달 지연·번아웃으로 직결된다. 팀 토폴로지는 "팀을 소프트웨어 전달의 기본 단위로 삼고, 팀이 감당할 수 있는 만큼으로 책임 범위를 제한하라"는 원칙을 전면에 내세운다는 점에서, 개인이 아니라 팀 우선(team-first) 사고로의 전환을 요구한다.
2. 네 가지 기본 팀 유형과 세 가지 상호작용
팀 토폴로지의 핵심은 조직에 존재할 수 있는 팀을 단 네 가지 유형으로 수렴시키고, 팀 사이의 관계를 세 가지 상호작용 방식으로 제한하는 것이다. 유형과 상호작용을 소수로 제한하는 이유는, 선택지가 적을수록 조직 구조가 단순·명료해지고 팀 간 책임 경계와 의사소통 경로가 분명해지기 때문이다. 아래 개념도는 네 유형과 그들 사이의 전형적 관계를 한눈에 보여 준다.
flowchart TB
SA1["스트림 정렬 팀 A(Stream-aligned)"]
SA2["스트림 정렬 팀 B(Stream-aligned)"]
PLAT["플랫폼 팀(Platform)"]
ENAB["조력 팀(Enabling)"]
CSUB["복잡 하위시스템 팀(Complicated-subsystem)"]
PLAT -. "X-as-a-Service" .-> SA1
PLAT -. "X-as-a-Service" .-> SA2
ENAB == "Facilitating(촉진)" ==> SA1
CSUB -. "X-as-a-Service" .-> SA2
SA1 -- "Collaboration(협업)" --- SA2
스트림 정렬 팀(Stream-aligned team)은 조직의 중심이자 가치 전달의 주역으로, 특정 비즈니스 도메인이나 사용자 여정 같은 하나의 '흐름'에 끝에서 끝까지(end-to-end) 책임진다. 예컨대 '결제', '검색', '모바일 온보딩'처럼 하나의 가치 흐름을 전담하며, 설계·개발·테스트·배포·운영을 스스로 수행해 외부 의존 없이 빠르게 전달하는 것을 목표로 한다. 팀 토폴로지는 전체 조직에서 이 유형이 대다수(권장적으로 다른 세 유형의 합보다 많게)를 차지해야 하며, 나머지 세 유형은 모두 스트림 정렬 팀의 인지 부하를 덜어 주기 위해 존재한다고 본다.
플랫폼 팀(Platform team)은 스트림 정렬 팀이 반복적으로 필요로 하는 하부 역량(배포 파이프라인, 관측성, 인증, 데이터베이스 프로비저닝 등)을 셀프서비스형 내부 제품으로 묶어 제공한다. 핵심은 플랫폼을 '티켓을 받아 처리하는 창구'가 아니라, 사용하기 쉽고 문서화가 잘 된 제품으로 다루는 것이다. 이는 플랫폼 엔지니어링([[platform-engineering]])과 직접 맞닿는다. 플랫폼이 잘 설계되면 스트림 정렬 팀은 인프라의 세부를 몰라도 되어 인지 부하가 크게 줄어든다.
복잡 하위시스템 팀(Complicated-subsystem team)은 전문적·수학적 깊이가 요구되어 아무나 다루기 어려운 특정 하위시스템(예: 비디오 코덱, 실시간 결제 정산 엔진, 머신러닝 추천 모델, 금융 리스크 계산기)을 전담한다. 이런 영역을 스트림 정렬 팀에 맡기면 특정 소수에게 지식이 쏠려 인지 부하가 폭증하므로, 전문성을 한곳에 모아 별도 팀으로 분리하는 것이 합리적이다.
조력 팀(Enabling team)은 스트림 정렬 팀이 새로운 기술·방법론(예: 테스트 자동화, 보안 역량, 클라우드 전환)을 습득하도록 한시적으로 코칭·멘토링하는 역할을 한다. 조력 팀은 일을 대신 해 주는 것이 아니라 역량을 이식한 뒤 빠지는 것을 목표로 하며, 상주하지 않고 수주~수개월 단위로 개입한다는 점이 특징이다.
세 가지 상호작용은 다음과 같다. 협업(Collaboration)은 두 팀이 한시적으로 긴밀히 함께 일하며 새로운 것을 발견하는 방식으로, 혁신 속도는 빠르지만 경계가 흐려지고 인지 부하가 커진다. 서비스로서 제공(X-as-a-Service)은 한 팀이 다른 팀에 명확한 인터페이스(팀 API)를 통해 기능을 제공하는 방식으로, 명료하고 확장성이 좋아 플랫폼 팀의 기본 모드다. 촉진(Facilitating)은 조력 팀이 다른 팀의 장애물을 제거하고 역량을 키우도록 돕는 방식이다.
| 팀 유형 | 주요 책임 | 지속성 | 기본 상호작용 |
|---|---|---|---|
| 스트림 정렬 | 하나의 가치 흐름 end-to-end 전달 | 상시(장수명) | 협업·X-as-a-Service 수신 |
| 플랫폼 | 셀프서비스 내부 플랫폼 제공 | 상시(장수명) | X-as-a-Service 제공 |
| 복잡 하위시스템 | 전문 지식 집약 모듈 담당 | 상시(필요 시) | X-as-a-Service 제공 |
| 조력 | 역량 코칭·장애물 제거 | 한시적 | Facilitating 제공 |
팀의 규모와 수명도 설계 요소다. 팀 토폴로지는 '아마존의 피자 두 판 팀' 원칙과 던바의 수(Dunbar's number)를 근거로, 한 팀을 대략 5~9명 수준의 신뢰 관계가 유지되는 소규모로 두고, 과제가 끝나면 해체하는 프로젝트식 팀이 아니라 오래 유지되는 장수명(long-lived) 팀에 과제를 흘려보내는 방식을 권장한다. 팀이 자주 재편되면 그때마다 신뢰 형성과 도메인 학습 비용이 다시 발생해 흐름이 끊기기 때문이다. 이 관점에서 스트림 정렬·플랫폼·복잡 하위시스템 팀은 상시 유지하고, 조력 팀만 한시적으로 운영하는 것이 자연스럽다.
3. 인지 부하와 역콘웨이 기동, 그리고 팀 API
팀 토폴로지를 실제로 작동시키는 운영 원리는 인지 부하의 측정과 제한이다. 인지 부하는 (1) 본유적 부하(언어·프레임워크 같은 기본 기술 학습), (2) 외재적 부하(배포 환경·절차처럼 본질과 무관한 복잡성), (3) 본질적 부하(해결하려는 도메인 문제 자체)로 나뉜다. 팀 토폴로지는 플랫폼과 자동화로 외재적 부하를 최대한 제거하고, 팀의 책임 도메인을 쪼개 본질적 부하를 감당 가능한 범위로 제한하라고 처방한다. 예를 들어 한 스트림 정렬 팀이 서로 무관한 도메인 7~8개를 동시에 맡고 있다면, 이는 인지 부하 초과 신호이므로 도메인을 분할하거나 팀을 늘려야 한다.
아키텍처 경계를 어디에서 그을지는 단층선(fracture plane) 개념으로 판단한다. 단층선이란 소프트웨어를 쪼개기 자연스러운 경계로, 비즈니스 도메인(DDD의 바운디드 컨텍스트), 규제 준수 영역, 변경 빈도, 성능 격리 요구 등이 대표적 기준이다. 아래 흐름도는 역콘웨이 기동을 통해 '원하는 아키텍처 → 팀 설계 → 결과 아키텍처'로 이어지는 과정을 나타낸다.
flowchart LR
A["목표 아키텍처 정의(느슨 결합 모듈)"] --> B["단층선 식별(도메인·규제·변경빈도)"]
B --> C["모듈별 스트림 정렬 팀 배치"]
C --> D["인지 부하 평가(과부하 점검)"]
D -->|"과부하"| E["도메인 분할/플랫폼 흡수"]
D -->|"적정"| F["팀 API 정의(인터페이스 명시)"]
E --> C
F --> G["콘웨이 법칙에 의해 목표 아키텍처 창발"]
G -.피드백.-> A
팀 사이의 경계를 명확히 하기 위해 팀 토폴로지는 팀 API(Team API)라는 개념을 쓴다. 팀 API란 한 팀이 외부에 공개하는 '사용 설명서'로서, 제공하는 코드·서비스·문서, 버전 정책, 연락 방법, 업무 시간, 로드맵, 작업 요청 방식을 명시한다. 팀 API가 잘 정의되면 다른 팀은 사람에게 일일이 묻지 않고도 그 팀의 산출물을 소비할 수 있어, 조직 전체의 의사소통 비용이 급감한다. 이것이 바로 X-as-a-Service 상호작용을 지탱하는 실질적 장치다.
예를 들어 어떤 기업이 배포 1건에 '개발팀→QA팀→보안팀→운영팀'의 4단계 핸드오프로 평균 12영업일이 걸렸다고 하자. 이를 결제 도메인 전담 스트림 정렬 팀으로 재편하고 보안·배포를 플랫폼 팀의 X-as-a-Service(정책 코드 내장 파이프라인)로 흡수하면, 핸드오프가 사라지면서 리드타임이 수 일 이내로 단축되는 효과를 기대할 수 있다. 실제 수치는 조직·도메인마다 크게 다르므로 단정하기는 어렵지만, 핸드오프 횟수 감소가 리드타임 단축의 핵심 지렛대라는 점은 여러 사례에서 공통적으로 관찰된다.
4. 전통적 조직·유사 모델과의 비교
팀 토폴로지의 차별성은 기존 조직 모델과 견줄 때 분명해진다. 전통적 기능 조직은 직무 전문성을 모으는 데 유리하지만, 하나의 기능 출시에 여러 팀의 핸드오프가 필요해 흐름이 끊기고 리드타임이 길어진다. 반면 팀 토폴로지의 스트림 정렬 팀은 핸드오프를 없애 흐름을 최적화한다.
널리 알려진 스포티파이 모델(스쿼드·트라이브·챕터·길드)과도 비교된다. 스포티파이 모델이 '자율적 스쿼드'라는 문화적 지향을 강조하는 데 비해, 팀 토폴로지는 팀 유형과 상호작용을 명시적 규칙으로 정형화하고 인지 부하라는 측정 가능한 기준을 제시한다는 점에서 더 처방적(prescriptive)이다. 실제로 스포티파이조차 자사 모델이 '복제용 청사진'이 아니라 특정 시점의 스냅샷이었다고 밝힌 바 있어, 재현성 측면에서 팀 토폴로지가 보완적 역할을 한다.
구체적 사례로, 글로벌 핀테크 기업들은 '결제', '대출', '사기탐지'를 각각 스트림 정렬 팀으로 두고, 사기탐지의 핵심 ML 엔진은 복잡 하위시스템 팀으로 분리하며, 공통 배포·관측성은 플랫폼 팀이 X-as-a-Service로 제공하는 구조를 흔히 채택한다. DevOps 성과 지표를 다루는 DORA 연구([[dora-metrics]])에서도, 느슨하게 결합되고 자율적인 팀 구조가 배포 빈도·변경 리드타임·변경 실패율·복구 시간 네 지표 모두에서 상위 성과와 상관됨이 반복 확인되는데, 이는 팀 토폴로지가 지향하는 구조와 방향이 일치한다.
| 구분 | 기능 조직 | 스포티파이 모델 | 팀 토폴로지 |
|---|---|---|---|
| 최적화 대상 | 직무 전문성 | 팀 자율성·문화 | 전달 흐름·인지 부하 |
| 팀 경계 기준 | 기술 직무 | 제품 영역(느슨) | 단층선(도메인·변경빈도) |
| 상호작용 규정 | 암묵적 | 느슨(챕터·길드) | 명시적 3종 |
| 아키텍처 전략 | 사후 결과 | 암묵적 | 역콘웨이(의도적) |
5. 심화: 플랫폼 엔지니어링·DevOps와의 연계 및 최신 동향
팀 토폴로지는 2022년 이후 부상한 플랫폼 엔지니어링 흐름과 사실상 쌍을 이루며 재조명되고 있다. 플랫폼 엔지니어링이 "내부 개발자 플랫폼(IDP)을 제품처럼 제공하자"는 기술·운영 전략이라면, 팀 토폴로지는 그 플랫폼을 누가(플랫폼 팀) 어떤 관계(X-as-a-Service)로 제공하고 소비해야 하는지를 조직 설계 언어로 규정한다. 가트너는 2026년까지 대규모 소프트웨어 조직의 상당수가 셀프서비스 내부 플랫폼 팀을 두게 될 것이라 전망해 왔고, 이는 팀 토폴로지의 플랫폼 팀 개념이 실무 표준으로 자리잡고 있음을 시사한다(정확한 수치·시점은 보고서 판마다 다르므로 일반화해 이해해야 한다).
최근에는 플랫폼을 그 자체로 하나의 스트림 정렬 조직처럼 운영하자는 '플랫폼 as a product' 심화 논의, 그리고 생성형 AI 도입이 팀 인지 부하에 미치는 영향에 대한 논의가 활발하다. AI 코딩 도우미가 외재적 부하를 낮추는 한편, 생성 코드의 검증·보안 책임이 새로운 본질적 부하로 추가되므로, 팀 경계와 책임 범위를 재설계해야 한다는 관점이 제시된다. 또한 조력 팀을 통해 AI 활용 역량을 조직 전체로 확산시키는 모델, 복잡 하위시스템 팀이 사내 LLM·RAG 파이프라인([[retrieval-augmented-generation]])을 전담하는 모델도 사례로 등장하고 있다.
출제 관점에서 팀 토폴로지는 "조직 구조가 소프트웨어 품질·속도에 미치는 영향을 논하라", "마이크로서비스 전환 시 조직 설계 방안", "플랫폼 엔지니어링 조직 운영 전략" 같은 문항과 강하게 연계된다. 답안 구성 시에는 ① 콘웨이 법칙·인지 부하로 문제를 정의하고, ② 네 팀 유형·세 상호작용으로 해법을 제시하며, ③ 역콘웨이 기동·단층선·팀 API로 구체적 실행 전략을 덧붙이고, ④ DORA·플랫폼 엔지니어링과 연계해 효과를 입증하는 흐름이 효과적이다.
6. 고려사항 및 시사점
기술사 관점에서 팀 토폴로지의 도입은 단순한 조직도 재편이 아니라 전달 아키텍처 전반의 재설계로 접근해야 하며, 다음 사항을 종합적으로 고려한다.
- 적용 전략(점진적 전환): 전사 일괄 개편은 저항과 혼란을 부르므로, 리드타임 병목이 심한 한두 가치 흐름부터 스트림 정렬 팀으로 전환하고 플랫폼 팀을 병행 육성하는 점진적 역콘웨이 기동이 현실적이다. 조직 변화에는 체계적 변화관리와 경영진 후원이 필수다.
- 트레이드오프(자율 vs 표준, 전문성 분산): 스트림 정렬 팀에 권한을 넘길수록 전달은 빨라지나 기술 파편화·중복 투자가 늘 수 있어, 플랫폼 팀의 골든 패스로 표준을 흡수해 균형을 잡아야 한다. 복잡 하위시스템 팀 분리는 전문성을 지키지만 지식 고립(사일로)과 병목을 낳을 수 있으므로, 조력 팀·문서화로 완화한다.
- 인지 부하 측정의 난제: 인지 부하는 정량화가 어려워 팀 설문·도메인 수·온콜 부담·사고 빈도 등 대리 지표를 병행해 주기적으로 점검해야 하며, 과부하 신호가 보이면 도메인 분할이나 팀 증설을 주저하지 말아야 한다.
- 거버넌스·보안과의 정합성: 자율적 스트림 정렬 팀이 늘수록 보안·규정 준수를 팀마다 재구현하는 위험이 커지므로, 정책을 코드로(Policy as Code) 플랫폼에 내장해 DevSecOps([[devsecops]])와 결합하는 것이 안전하다.
- 전망·연계 기술: 팀 토폴로지는 마이크로서비스·DDD·플랫폼 엔지니어링·SRE와 결합할 때 시너지가 극대화되며, 향후 AI 보조 개발 확산에 따라 '팀 단위 인지 부하'를 재정의하는 방향으로 진화할 것으로 전망된다. 조직은 구조를 고정물이 아니라 지속적으로 감지·진화시키는 대상으로 다루어야 한다.
참고자료
- Matthew Skelton, Manuel Pais, "Team Topologies", IT Revolution, 2019. https://teamtopologies.com/book
- Team Topologies 공식 사이트(개념·키컨셉 정리). https://teamtopologies.com/key-concepts
- Melvin Conway, "How Do Committees Invent?", 1968. https://www.melconway.com/Home/Committees_Paper.html
- Gartner, "What Is Platform Engineering?". https://www.gartner.com/en/articles/what-is-platform-engineering
한 줄 요약: 팀 토폴로지는 전달 흐름과 인지 부하를 기준으로 조직을 네 팀 유형(스트림 정렬·플랫폼·복잡 하위시스템·조력)과 세 상호작용(협업·X-as-a-Service·촉진)으로 의도적으로 설계하고, 역콘웨이 기동으로 원하는 아키텍처를 창발시키는 현대적 조직 설계 모델이다.