1.2 팀 토폴로지와 조직 설계

개요와 동기

사람을 팀으로 나누는 방식이 만들 수 있는 소프트웨어와 그 속도를 결정합니다. 이것은 비유가 아닙니다. 콘웨이의 법칙으로 알려진, 거의 기계적인 귀결입니다. 조직은 자신의 의사소통 구조를 닮은 시스템을 설계합니다. 세 팀이 컴파일러를 만들면 3패스 컴파일러가 나옵니다. 결제 로직이 프런트엔드 팀, 백엔드 팀, 데이터베이스 팀에 나뉘어 있다면, 결제를 바꿀 때마다 세 팀의 조율이 필요합니다. 작은 조직에서는 감당할 만합니다. 큰 조직에서는 조직도의 모양이 엔지니어링, 아키텍처, 전달 속도, 품질을 지배하는 제약이 됩니다. 그러므로 팀 구조 설계는 인사 부서의 뒷일이 아니라 일급 엔지니어링 활동입니다.

팀 토폴로지는 이 설계를 위한 의도적인 어휘를 줍니다. 구조가 개편과 인원 배정을 통해 우연히 쌓이도록 두는 대신, 성숙한 조직은 팀 유형과 상호작용 방식을 의도를 가지고 선택하고, 시스템과 사업이 진화함에 따라 그 선택을 다시 살핍니다. 목표는 각 팀의 인지 부하, 즉 팀이 효과적이기 위해 머릿속에 담고 있어야 하는 총량을 낮게 유지하는 것입니다. 그래야 팀이 자기 영역을 처음부터 끝까지 소유하고, 끊임없이 다른 팀을 기다리지 않으면서 꾸준한 가치의 흐름을 전달할 수 있습니다.

기업과 정부에서 이 규율은 결정적입니다. 큰 조직은 자연스럽게 깊은 위계, 긴 대기열이 있는 공유 서비스, 이틀짜리 변경을 두 달짜리 프로젝트로 바꾸는 인수인계 사슬로 번져 갑니다. 정부는 여기에 조달 경계, 계약자 팀, 의무화된 직무 분리를 더해 소유권을 더욱 쪼갭니다. 명시적인 토폴로지 설계는 이런 조직이 흐름을 되찾는 방법입니다. 팀을 가치의 흐름에 맞춰 정렬하고, 인지 부하를 줄이는 플랫폼을 만들고, 의존성을 숨겨지고 끊임없는 것이 아니라 보이고 의도적인 것으로 만드는 상호작용 패턴을 선택합니다.

핵심 원칙

콘웨이의 법칙은 피할 수 없습니다. 원하는 소프트웨어 엔지니어링에 맞게 팀을 설계하십시오(“역 콘웨이 전략”).
개인의 최대 가동률이 아니라 팀의 인지 부하를 최적화하십시오.
가치의 한 조각을 처음부터 끝까지 소유하는 스트림 정렬 팀을 선호하십시오.
플랫폼은 스트림 정렬 팀의 인지 부하를 줄이려고 존재하는 것이지, 관문을 지키려고 있는 것이 아닙니다.
팀 간 상호작용은 명시적이고 적게 하십시오. 협업, 서비스로서의 X(X-as-a-service), 촉진(facilitating) 중 하나입니다.
의존성을 최소화하십시오. 팀 사이의 모든 인수인계는 대기열이자 위험입니다.
팀 구조는 시스템과 사업이 변함에 따라 진화해야 하는 살아 있는 설계입니다.

권장 사항

네 가지 기본 팀 유형을 사용한다

팀 토폴로지는 대부분의 필요를 포괄하는 네 가지 팀 유형을 정의합니다. 스트림 정렬 팀이 기본입니다. 각 팀은 특정 제품, 서비스, 사용자 여정의 지속적인 작업 흐름을 처음부터 끝까지 소유합니다. 플랫폼 팀은 컴퓨팅, 배포, 데이터 파이프라인, 신원 같은 내부 제품을 제공하고, 스트림 정렬 팀이 셀프서비스로 소비해 인지 부하를 낮춥니다. 이네이블링 팀은 스트림 정렬 팀이 역량을 갖추도록 코칭한 뒤 물러나는 전문가(테스트, 보안, 관측 가능성)입니다. 복잡한 서브시스템 팀은 깊은 전문 지식이 필요한 구성 요소(가격 엔진, 비디오 코덱, 암호 모듈)를 소유하며, 모든 팀이 그 지식을 갖는 것이 말이 되지 않는 경우입니다. 대부분의 팀은 스트림 정렬 팀이어야 하며, 나머지 세 유형은 이들을 지원하기 위해 존재합니다.

역 콘웨이 전략을 적용한다

소프트웨어가 조직의 구조를 닮으므로, 원하는 소프트웨어가 나오도록 팀을 빚으십시오. 경계가 분명하고 느슨하게 결합된 서비스를 원합니까? 소유권 경계가 분명하고 느슨하게 결합된 팀을 만드십시오. 자기 일정으로 출시되는 결제 역량을 원합니까? 그것을 앞에서 뒤까지 소유하는 결제 팀을 구성하십시오. 영웅적인 조율로 콘웨이의 법칙과 싸우지 마십시오. 원하는 아키텍처가 최소 저항의 길이 되도록 팀 경계를 다시 그으십시오.

인지 부하를 명시적으로 관리한다

팀이 숙달할 수 있는 양에는 한계가 있습니다. 인지 부하에는 도메인의 복잡성, 기술, 운영 부담, 이해관계자의 폭이 포함됩니다. 팀이 서로 무관한 서비스를 너무 많이 소유하면 품질과 속도가 함께 무너집니다. 그러므로 각 팀의 책임을 진정으로 숙달할 수 있는 도메인으로 한정하고, 플랫폼과 이네이블링 팀을 써서 차별성 없는 복잡성을 팀의 접시에서 덜어 주십시오. 팀은 대략 다섯 명에서 아홉 명으로 유지하십시오. 쉽게 소통하고, 말하자면 피자 두어 판으로 먹일 수 있을 만큼 작아야 합니다.

상호작용 방식을 의도적으로 선택한다

팀 간 상호작용을 세 가지 방식으로 제한하십시오. 협업은 두 팀이 일정 기간 긴밀하고 대역폭이 높게 함께 일하는 것입니다. 발견에는 강력하지만 비용이 크므로 일시적으로 유지하십시오. 서비스로서의 X는 잘 정의된 인터페이스를 가진 깔끔한 제공자/소비자 관계로, 대규모 플랫폼 소비에 이상적입니다. 촉진은 한 팀이 다른 팀이 배우도록 돕는 것으로, 이네이블링 팀이 하는 일입니다. 중요한 팀 간 관계마다 그 방식의 이름을 붙이고, 같은 두 팀 사이의 오래 이어지는 협업은 그 경계가 잘못된 곳에 있다는 신호로 읽으십시오.

횡단 기능을 위한 운영 모델을 고른다

보안, 데이터, 디자인 같은 분야는 세 가지 방식으로 조직할 수 있습니다. 중앙 집중형(한 팀이 모두를 위해 소유), 연합형(전문가가 파트타임으로 파견되고 길드를 통해 조율), 내장형(각 스트림 정렬 팀 안에 전담 전문가)입니다. 중앙 집중형은 일관성과 깊이를 주지만 병목이 됩니다. 내장형은 속도와 맥락을 주지만 비일관성과 중복의 위험이 있습니다. 연합형(흔히 허브 앤 스포크 또는 실천 공동체 모델)은 둘 사이에 있습니다. 기능별로, 규모별로 선택하십시오. 대부분의 큰 조직은 이런 분야에서 표준을 정하는 작은 중앙 핵심을 둔 연합형에 이릅니다.

이너소스에 투자한다

이너소스는 오픈 소스의 협업 패턴을 조직 내부로 가져옵니다. 공유 내부 저장소, 공개된 기여 지침, 팀 경계를 넘는 코드 리뷰, 분명한 메인테이너입니다. 팀이 다른 팀의 구성 요소에 변경이 필요할 때, 티켓을 올리고 대기열에서 기다리는 대신 변경을 직접 기여할 수 있습니다. 이는 소유권을 해체하지 않고 팀 간 의존성을 덜어 주며, 큰 엔지니어링 인구 전반에 지식과 표준을 자연스럽게 퍼뜨립니다.

장단점

횡단 기능의 모델	장점	단점
중앙 집중형 (모두를 위한 한 팀)	일관성, 깊은 전문성, 분명한 표준	병목, 대기열, 제품 맥락의 상실
연합형 (허브 앤 스포크, 길드)	일관성과 속도의 균형. 지식 공유	조율의 규율이 필요. 책임이 흐려질 수 있음
내장형 (팀마다 전문가)	빠르고, 맥락이 풍부하며, 소유 의식이 높음	중복, 비일관성, 대규모로 인력 충원이 어려움

팀 유형	가장 적합한 용도	남용했을 때의 위험
스트림 정렬	대부분의 제품과 서비스 전달	없음. 이것이 지배적이어야 함
플랫폼	공유 인지 부하 줄이기	상아탑의 관문지기가 됨
이네이블링	역량을 일시적으로 퍼뜨리기	영구적인 의존성으로 변함
복잡한 서브시스템	정말로 깊은 전문 영역	평범한 일을 쌓아 두는 핑계로 쓰임

반복되는 트레이드오프는 자율성 대 일관성입니다. 완전히 자율적인 팀은 빠르게 움직이지만 표준, 도구, 보안 태세에서 서로 멀어집니다. 완전히 중앙 집중된 통제는 일관성을 지키지만 흐름을 질식시킵니다. 좋은 토폴로지 설계는 이음매를 찾습니다. 스트림 정렬 전달에는 자율성을, 정말로 일관되어야 하는 것에는 얇은 중앙 표준과 포장된 길(규정을 지키는 선택을 쉬운 선택으로 만드는, 잘 지원되는 기본 도구)의 플랫폼을 둡니다.

팀과 논의할 질문

품질이 무너지기 전에, 팀의 인지 부하가 너무 높다는 것을 알려 주는 구체적인 신호는 무엇입니까? “각 팀을 숙달할 수 있는 도메인으로 한정하라”는 말하기는 쉽지만 증거 없이 실행하기는 어렵습니다. 인지 부하는 전달과 신뢰성이 나빠질 때까지 보이지 않기 때문입니다. 측정 가능한 증상을 지켜보십시오. 팀이 소유한 무관한 서비스나 저장소의 수, 온보딩에 걸리는 시간, 엔지니어 한 명이 일주일에 오가야 하는 도메인의 수, 팀 책임 범위의 구석에서 오르는 인시던트 비율입니다. 큰 조직에서 이것이 중요한 이유는, 과부하 팀이 어떤 개편 도표도 예측하지 못하는 병목으로 조용히 변하기 때문입니다. 이런 숫자와 함께 팀 스스로 머릿속에 담을 수 있는 것과 없는 것에 대한 감각도 논의에 가져오십시오. 신호가 과부하를 가리키면, 해법은 더 많은 영웅적 행동을 요구하는 것이 아니라 차별성 없는 일을 플랫폼이나 이네이블링 팀으로 덜어 내는 것입니다.
여기서 개편은 그 혼란을 감수할 만한 가치가 정말 있습니까, 아니면 개편 중독을 키우고 있습니까? 역 콘웨이 전략을 적용하려고 경계를 다시 그으면 강력하지만, 모든 개편은 팀이 뭉치는 데 필요한 안정성을 무너뜨리고 어렵게 얻은 도메인 지식을 초기화합니다. 상충하는 고려는 현재 구조가 끊임없이 부과하는 조율 세금 대 변경의 일회성 비용과 사기 저하입니다. 기업과 정부 환경에서는 조달 경계, 계약자 팀, 의무화된 직무 분리가 개편을 더 느리고 비싸게 만들므로 기준이 더 높아야 합니다. 의존성 때문에 생기는 지연의 증거를 가져오십시오. 얼마나 많은 이니셔티브가 다른 팀을 기다리며 막혀 있고, 얼마나 오래인지입니다. 그 기다림이 구조적이고 클 때 개편하고, 고통이 일시적이거나 이너소스 기여와 더 분명한 인터페이스로 더 싸게 풀 수 있다면 판을 다시 짜는 것을 삼가십시오.
보안, 데이터, 디자인에서 어떤 사건이 내장형, 연합형, 중앙 집중형 사이를 옮기도록 촉발합니까? 이 장의 권장은 기능별, 규모별로 선택하라는 것이고, 더 어려운 규율은 어떤 성장이나 위험이 그 선택을 다시 보게 만들지 미리 정해 두는 것입니다. 엔지니어 50명에게 맞는 모델이 500명에서는 병목이나 일관성의 재앙이 될 수 있으며, 특히 기업과 정부 기관은 작은 중앙 핵심이 항상 쥐고 있을 표준에 이름을 붙여야 합니다. 각 기능의 현재 대기 시간과 일관성 격차를 가져오십시오. 몇 주씩 걸리는 검토 대기열을 가진 중앙 보안 팀은 연합형으로 가라는 신호이고, 서로 호환되지 않는 데이터 모델을 만들어 내는 내장 전문가는 중앙 표준 핵심을 더하라는 신호입니다. 대기열 길이 임계값이나 감사 지적 같은 촉발 조건을 지금 정해 두어, 변화가 위기 반응이 아니라 계획된 진화가 되게 하십시오. 답은 포장된 길과 챔피언 대 중앙 허브 중 어디에 투자할지를 결정합니다.
플랫폼 팀이 정말로 인지 부하를 낮추고 있는지, 조용히 관문지기가 되고 있는지 어떻게 알 수 있습니까? 플랫폼은 셀프서비스를 통해 규정을 지키고 믿을 수 있는 선택을 쉬운 선택으로 만들려고 존재하는데, 같은 팀이 도구를 강제하고, 모든 요청을 손으로 검토하고, 없애려던 마찰을 더하는 쪽으로 표류할 수 있습니다. 큰 조직에서 이 구분은 플랫폼 투자가 본전을 뽑는지, 모든 스트림 정렬 팀이 뒤에서 줄 서는 중앙 병목이 되는지를 가릅니다. 상충하는 고려는 한편의 일관성과 통제 대 다른 편의 소비자 자율성과 흐름입니다. 소비자가 알아볼 증거를 가져오십시오. 스트림 정렬 팀이 티켓을 올리지 않고 새 환경이나 파이프라인을 셀프서비스로 얻는 데 걸리는 시간, 셀프서비스 행위 대 사람이 개입한 행위의 비율, 강제로 올라탄 팀이 아니라 스스로 선택한 팀으로 측정한 플랫폼 채택입니다. 기업과 정부 환경에서는 플랫폼이 감사와 컴플라이언스 증거를 수동 관문이 아니라 자동으로 생성하도록 요구하십시오. 직무 분리 규칙을 사람 검토자를 끼워 넣어 충족하는 플랫폼은, 해소하려고 자금을 받은 병목을 다시 만든 것이기 때문입니다.
어떤 팀 간 관계가 영구적인 협업으로 굳어졌으며, 각각을 깔끔한 서비스 인터페이스나 다시 그은 경계로 바꾸려면 무엇이 필요합니까? 협업 방식은 집중적이고 일시적이어야 하며, 끝나지 않는 페어링은 대개 소유권이 잘못된 곳에 있거나 두 팀 사이의 인터페이스가 명시된 적이 없다는 신호입니다. 규모에서 이것이 중요한 이유는, 이름 없이 상설로 이어지는 협업이 조율 비용이 숨는 곳이기 때문입니다. 어떤 조직도에도 나타나지 않지만 두 팀이 건드리는 모든 변경에 세금을 매깁니다. 상충하는 고려는 가까이 머무르는 발견의 가치 대 관계를 정의된 인터페이스를 가진 서비스로서의 X 계약으로 바꾸거나 책임을 한 팀으로 합쳐서 얻는 흐름입니다. 한 분기 넘게 계속 협업해 온 팀 쌍의 목록, 최근 몇 달간 두 팀이 모두 필요했던 변경, 둘 사이의 안정적인 인터페이스를 문서로 쓸 수 있는지 여부를 가져오십시오. 계약자 경계와 조달 로트가 인수인계를 수년간 고정시킬 수 있는 기업과 정부 맥락에서는, 어떤 관계는 인터페이스와 이너소스 기여로 바꿀 수 있고 어떤 관계는 계약상 고정되어 명시적 의존성으로 관리해야 하는지 구분해 이름을 붙이십시오.
이네이블링 팀이 다른 팀의 역량 구축을 도울 때, 영구적인 의존성이 되지 않고 성공해서 물러날 수 있음을 어떻게 알 수 있습니까? 이네이블링 팀은 스트림 정렬 팀이 테스트, 보안, 관측 가능성을 익히도록 코칭하고 떠나는 것이 목적이며, 명시적인 종료 조건이 없으면 코칭 관계가 스트림 정렬 팀이 끝내 흡수하지 못하는 상설 서비스로 굳어집니다. 큰 조직에서 이것은 역량을 수십 개 팀에 퍼뜨리는 것과 해마다 더 나쁘게 확장되는 새로운 공유 병목을 만드는 것의 차이입니다. 상충하는 고려는 전문가 팀이 주는 깊이와 일관성 대 스트림 정렬 팀에 심으려는 자율성과 종단 간 소유권입니다. 역량 이전의 증거를 가져오십시오. 받는 팀이 이네이블링 팀 없이 이제 그 일을 처리하는지, 고정된 이네이블링 그룹이 한 번에 몇 개 팀에 투입되어 있는지, 각 참여가 의도한 인계 시점을 넘어 얼마나 오래 이어졌는지입니다. 희소한 전문 기술이 단일 중앙 팀이나 단일 계약 뒤에 있을 수 있는 기업과 정부 환경에서는, 역량 이전과 챔피언에 어떻게 자금을 댈지 미리 정해, 전문성이 모든 감사와 릴리스가 기다려야 하는 대기열 뒤에 갇혀 있지 않고 전달 팀으로 확산되게 하십시오.

분야별 관점

스타트업. 엔지니어 몇 명과 짧은 런웨이라면, 알맞은 토폴로지는 제품 전체를 소유하는 단일 스트림 정렬 팀이며, 규율이란 필요해지기 전에 사일로를 만들기를 거부하는 것입니다. 관문이 되는 단독 “DevOps”나 “QA” 담당자를 채용하지 말고, 그런 기술을 한 팀 안의 내장 역량으로 녹이십시오. 조직을 평평하게 유지해 콘웨이의 법칙이 여러분 편에서 일하게 하고, 아키텍처가 팀만큼 단순하고 바꾸기 쉽게 하십시오.

소기업. 전담 플랫폼 팀이나 이네이블링 팀을 둘 수 없으므로 플랫폼을 사십시오. 관리형 클라우드 서비스, 호스팅 파이프라인, 기성 보안 도구를 써서 한두 팀의 차별성 없는 인지 부하를 덜어 주십시오. 보안과 데이터 같은 횡단 관심사를 직접 만드는 기능이 아니라 구성해서 소비하는 것으로 보십시오. 맞춤형 소유권은 정말로 차별화되는 복잡한 서브시스템 하나에만 두고 나머지는 벤더가 짊어지게 하십시오.

대기업. 규모에서의 문제는 많은 팀 사이의 조율 비용이므로, 토폴로지를 명시적이고 통제되는 설계로 만드십시오. 네 가지 팀 유형의 공통 분류 체계, 이름 붙은 상호작용 방식, 포장된 길 플랫폼, 팀 간 대기열을 덜어 주는 이너소스입니다. 의존성으로 인한 지연과 팀의 인지 부하를 포트폴리오 지표로 추적하고, 개편을 연례 반사 행동이 아니라 높은 기준을 가진 의도적인 진화로 운영하십시오. 얇은 중앙 핵심이 일관되어야 하는 표준을 쥐고, 스트림 정렬 팀은 전달에 대한 자율성을 유지합니다.

정부. 조달 규칙, 계약자 경계, 의무화된 직무 분리가 소유권을 쪼개므로, 사람의 인수인계가 아닌 도구와 분명한 인터페이스로 그 제약을 충족하도록 토폴로지를 설계하십시오. 작은 표준 핵심과 감사 및 컴플라이언스 증거를 자동으로 생성하는 플랫폼을 가진 연합형 모델을 선호해, 직무 분리가 검토 대기열이 아니라 파이프라인으로 시행되게 하십시오. 팀 경계, 상호작용 방식, 운영 모델을 공개적으로 문서화해, 구조가 감사자, 감독 기관, 그리고 자금을 대는 대중에게 투명하게 하십시오.

사례

스타트업. 10명짜리 스타트업에는 제품 전체를 처음부터 끝까지 소유하는 단일 스트림 정렬 팀이 있고, 이는 그 규모에서 꼭 맞습니다. 인수인계도, 조율 세금도 없고, 모두가 같은 맥락을 공유합니다. 전담 “DevOps 담당자”와 별도의 “QA 담당자”를 채용하면서 문제가 시작되는데, 우연히 기능별 사일로를 다시 만들어 이제 모든 릴리스가 두 사람을 기다리게 됩니다. 이들은 그 채용을 일이 통과해야 하는 관문이 아니라 한 팀 안의 내장된 플랫폼 및 테스트 역량으로 다루어 방향을 바로잡습니다. 이 규모에서 가장 싼 토폴로지는 모두를 하나의 흐름 안에 두는 것입니다.

대기업. 한 대형 소매업체의 결제는 프런트엔드, 백엔드, 풀필먼트 로직이 기능별로 조직된 세 팀에 나뉘어 있어 바뀌는 속도가 느렸고, 모든 변경이 세 개의 백로그를 거쳐야 했습니다. 역 콘웨이 전략을 적용해, 고객 여정(“둘러보기”, “장바구니와 결제”, “구매 후”)을 중심으로 스트림 정렬 팀으로 재편했고, 각 팀이 자기 조각을 앞에서 뒤까지 소유하며, 배포와 관측 가능성을 서비스로 제공하는 플랫폼 팀이 뒷받침합니다. 한 분기가 걸리던 결제 변경이 며칠 만에 출시되기 시작했습니다. 예전에는 여러 팀에 걸쳐 있던 조율이 이제 한 팀 안에서 일어나기 때문입니다.

정부. 한 정부 세무 기관은 모든 릴리스를 검토하는 중앙 보안 팀을 운영해 몇 주씩 이어지는 대기열이 생겼고 중요한 수정이 지연되었습니다. 연합형 모델로 옮겼습니다. 작은 중앙 보안 기능이 표준을 정하고 사전 승인되어 자동으로 스캔되는 파이프라인이라는 “포장된 길”을 제공하는 동안, 각 전달 팀에 파트타임으로 파견된 보안 챔피언이 일상의 결정을 처리했습니다. 플랫폼은 컴플라이언스 증거를 자동으로 생성했습니다. 의무화된 직무 분리 요건은 여전히 충족되었지만 사람 병목이 아니라 도구와 분명한 인터페이스를 통해서였고, 릴리스 리드 타임이 극적으로 줄고 감사 준비도도 나아졌습니다.

비즈니스 사례: 동기, ROI, TCO

나쁜 팀 설계의 대가는 조율 오버헤드로 치르게 되고, 이 오버헤드는 전형적인 변경에 동기화해야 하는 팀의 수에 따라 선형보다 빠르게 커집니다. 모든 인수인계는 대기 시간이 있는 대기열이고, 정보를 잃는 맥락 이전이며, 의사소통을 그르칠 새로운 기회입니다. 일상적인 변경에 세 팀이 로드맵을 맞춰야 한다면, 진짜 비용은 그들의 작업을 합한 것이 아니라 일정 잡기, 기다리기, 재작업이라는 훨씬 큰 비용입니다. 대부분의 변경이 한 팀의 소유권 안에 들어가도록 경계를 다시 그으면 그 오버헤드는 그냥 사라집니다.

도입 비용은 실제입니다. 개편은 혼란을 일으키고, 플랫폼과 이너소스 관행을 만드는 일은 성과가 나오기 전에 선행 투자가 필요합니다. 그러나 도입하지 않는 비용은 복리로 불어납니다. 구조가 우연히 쌓이도록 둔 조직은 인수인계 사슬, 분기 단위의 대기열을 가진 공유 병목 팀, 조직도에 의해 화석화된 아키텍처를 쌓아 올립니다. 리더십을 설득하려면 의존성으로 인한 지연을 측정하십시오. 활성 이니셔티브 중 몇 개가 다른 팀을 기다리며 막혀 있고, 얼마나 오래인지입니다. 플랫폼과 토폴로지 투자는 보통 그 기다림을 흐름으로 바꿈으로써 본전을 뽑으며, 이는 인원을 늘리지 않고도 더 짧은 리드 타임과 더 높은 처리량으로 나타납니다.

안티패턴과 함정

콘웨이의 법칙 무시: 조직 구조가 전달할 수 없는 아키텍처를 설계하는 것.
기능별 사일로: 어떤 변경에도 조율해야 하는 별도의 프런트엔드, 백엔드, QA, 운영 팀.
공유 서비스 병목: 모든 프로젝트가 뒤에서 줄 서야 하는 중앙 팀.
관문지기로서의 플랫폼: 섬기지 않고 강제하며, 마찰을 없애는 대신 더하는 플랫폼 팀.
인지 과부하: 숙달할 수 없는 광범위하고 무관한 시스템을 소유한 팀.
영구적인 “협업”: 끊임없이 얽혀 있는 두 팀. 경계가 잘못 놓였다는 신호.
개편 중독: 끊임없이 판을 다시 짜서 팀이 뭉치는 데 필요한 안정성을 무너뜨리는 것.

성숙도 모델

1단계, 시작. 팀이 우연, 인원수, 레거시 위계로 형성됩니다. 아무도 팀 유형이나 상호작용 방식에 이름을 붙이지 않으며, 기능별 사일로와 공유 서비스 병목이 곳곳에 있고 의존성은 릴리스를 막을 때까지 숨겨져 있습니다.
2단계, 발전. 일부 스트림 정렬 팀이 존재하고 첫 플랫폼이나 이너소스 노력이 나타나지만, 패턴이 고르지 않게 적용됩니다. 몇몇 팀은 자기 조각을 처음부터 끝까지 소유하는 반면 다른 팀은 여전히 중앙 기능 뒤에서 줄을 서고, 인지 부하는 관리되지 않고 일화로만 논의됩니다.
3단계, 표준화. 네 가지 팀 유형과 세 가지 상호작용 방식이 문서화되어 조직 전체에서 의도적으로 사용됩니다. 플랫폼과 이너소스가 팀 간 의존성을 덜어 주고, 보안, 데이터, 디자인의 운영 모델이 선택되어 문서로 남아 있으며, 새 팀은 즉흥이 아니라 이 표준에 맞춰 구성됩니다.
4단계, 관리. 토폴로지가 기준선에 대해 측정되고 통제됩니다. 팀은 인지 부하, 의존성으로 인한 지연(다른 팀을 기다리며 막힌 이니셔티브와 그 기간), 플랫폼 셀프서비스 비율과 채택, 상호작용 방식의 지속 기간, 리드 타임과 변경 빈도 같은 전달 흐름 지표를 추적합니다. 임계값이 행동을 촉발합니다. 예컨대 기능을 연합형으로 바꾸게 만드는 대기열 길이나 잘못 놓인 경계를 알리는 상설 협업이며, 결정은 의견이 아니라 증거에 근거합니다.
5단계, 오케스트레이션. 팀 설계가 지속적으로 개선되고 아키텍처, 제품, 위험 계획과 통합됩니다. 조직은 시스템과 사업이 진화함에 따라 경계를 재조정하고, 역량이 이전되면 이네이블링 참여를 종료하고, 인지 부하가 이동함에 따라 플랫폼 투자를 재균형하며, 빠른 흐름을 일회성 개편이 아니라 적응하는 상설 속성으로 유지합니다.

논의를 위한 아이디어

전형적인 변경 하나에 몇 개의 팀이 조율해야 하며, 그 이유는 무엇입니까?
우리 팀 중 어느 팀이 인지 부하를 너무 많이 지고 있으며, 플랫폼이 무엇을 덜어 줄 수 있습니까?
어디에서 경계를 다시 그리는 대신 콘웨이의 법칙과 싸우고 있습니까?
우리 플랫폼 팀은 스트림 정렬 팀을 섬기고 있습니까, 아니면 관문을 지키고 있습니까?
지금 우리에게 보안, 데이터, 디자인은 중앙 집중형, 연합형, 내장형 중 무엇이어야 합니까?
어떤 “일시적” 협업이 조용히 영구적인 의존성이 되었습니까?

핵심 요점

조직 구조가 아키텍처와 전달 속도를 결정합니다. 의도를 가지고 설계하십시오.
네 가지 팀 유형을 사용하되 스트림 정렬을 기본으로, 나머지를 지원으로 두십시오.
역 콘웨이 전략을 적용해 원하는 아키텍처가 쉬운 길이 되게 하십시오.
인지 부하를 관리하십시오. 각 팀을 숙달할 수 있는 도메인으로 한정하십시오.
팀 간 상호작용 방식을 제한하고 이름을 붙이십시오. 오래 남은 의존성은 경계의 결함으로 취급하십시오.
횡단 기능에는 규모에 따라 중앙 집중형, 연합형, 내장형 모델을 고르고, 이너소스로 대기열을 덜어 내십시오.

참고 문헌과 더 읽을거리

Matthew Skelton and Manuel Pais, “Team Topologies: Organising Business and Technology Teams for Fast Flow”
Melvin Conway, “How Do Committees Invent?” (the origin of Conway’s Law)
Nicole Forsgren, Jez Humble, Gene Kim, “Accelerate”
Will Larson, “An Elegant Puzzle: Systems of Engineering Management”
Sam Newman, “Building Microservices” (on aligning services to teams)
Danese Cooper and Klaas-Jan Stol, “Adopting InnerSource,” and the InnerSource Commons patterns
Frederick Brooks, “The Mythical Man-Month” (communication overhead)