운영 모델·5 분

콘웨이의 법칙을 실제로 인력 배치할 수 있는 형태로

네 가지 팀 유형과 세 가지 상호작용 방식. 이 책이 최적화하는 제약은 인지 부하인데, 그건 아무도 예산에 잡지 않는 항목입니다.

출처

Team Topologies: Organizing Business and Technology Teams for Fast Flow

Matthew Skelton & Manuel Pais · IT Revolution · 2019

이 자료의 저자는 AslanWay가 아닙니다. 아래 요약은 원문 내용을 정리한 것이고, 이어지는 해설은 저희 의견이며 저자의 동의를 받은 것이 아닙니다.

이 자료의 주장

스켈턴과 파이스는 콘웨이의 관찰을 실행 가능한 형태로 바꿉니다. 조직이 왜 그런 아키텍처를 만들어내는지 설명하는 데서 멈추지 않고, 조직을 의도적으로 설계하기 위한 최소한의 어휘를 제안합니다.

팀 유형은 넷입니다. 하나의 흐름을 끝까지 책임지는 스트림 정렬 팀, 내부 서비스를 제공하는 플랫폼 팀, 다른 팀의 역량을 끌어올린 뒤 빠지는 인에이블링 팀, 그리고 정말로 깊은 전문성이 필요한 영역을 맡는 복합 서브시스템 팀.

상호작용 방식은 셋입니다. 협업, 서비스로 제공하기, 촉진하기. 규율은 간단합니다. 두 팀은 한 번에 하나의 방식으로만 관계를 맺고, 협업은 비싸고 한시적인 상태이지 기본값이 아니라는 것.

책의 핵심 주장은 한 팀이 머릿속에 담을 수 있는 양에 한계가 있다는 것입니다. 팀을 너무 많은 도메인에 걸쳐놓으면 인원을 늘려도 딜리버리가 나빠집니다. 플랫폼 팀의 존재 이유가 바로 이 부하를 흡수해 스트림 정렬 팀을 빠르게 만드는 데 있습니다.

가장 흔한 오용은 기존 사일로에 네 가지 이름만 새로 붙이고 소유권은 그대로 두는 것입니다. 플랫폼 팀에 매번 티켓을 올려야 한다면 그건 플랫폼 팀이 아닙니다.
'플랫폼을 제품처럼'이 유용한 판별 기준입니다. 대안이 주어졌을 때 스트림 정렬 팀이 우리 플랫폼을 고르지 않는다면, 그 플랫폼은 세금이고 사람들은 우회로를 찾습니다.
DORA의 2025년 조사에서 조직의 90%가 내부 플랫폼을 하나 이상 도입했고, 성과와 상관관계를 보인 것은 도입 여부가 아니라 플랫폼의 품질이었습니다. 이 책이 다루는 게 대체로 그 품질입니다.