책 소개
요약
"시스템을 설계하는 조직들은... 해당 조직의 커뮤니케이션 구조를 복제한 형태의 설계 외에는 만들 수 없다." - 콘웨이, 1968
팀 토폴로지 접근 방식은 엔터프라이즈 소프트웨어 딜리버리를 위한 효과적인 팀 구조에 관한 새로운 사고 방식을 제공한다. 팀 토폴로지는 일관성 있고 적용 가능한 가이드를 제공한다. 이 가이드를 따라 진화하는 팀을 설계하고 지속적으로 기술, 사람 그리고 비즈니스 변화를 다룬다. 여기에는 현대 소프트웨어를 구현하고 운용하는 팀의 크기, 형태, 위치, 책임, 상호 교류 모두가 해당된다.
팀 토폴로지는 스트림 정렬(stream-aligned), 플랫폼(platform), 권한 부여(enabling), 난해한-하위시스템(complicated-subsystem)의 4가지 근본적인 팀의 형태와 협업(collaboration), X-애즈-어-서비스(X-as-a-Service), 촉진(facilitating)이라는 3가지 상호 교류 모드를 제공한다. 콘웨이의 법칙, 팀 인지 부하, 조직 감지 방법을 함께 조합함으로써 소프트웨어 시스템을 구축하고 운영하는 효과적이고 인간적인 접근 방법을 취한다.
팀 토폴로지는 궁극적으로 팀이 고객 요구에 부응하고, 구현과 운용 그리고 소유하기 쉬운 소프트웨어를 구현하도록 돕는 것을 목적으로 한다. 또한 팀 토폴로지는 콘웨이의 법칙에 굳게 기반한 역동적인 팀 설계와 함께 솔루션을 개발하는 전략적인 도구가 된다.
추천의 글
“팀 토폴로지는 시장과 기술 변화를 예상하고 그에 적응하는 데 필요한 신선한 통찰력을 제공한다. 기업은 생존을 위해 기존의 명령과 통제 구조를 잊어야 한다. 대신, 권한을 리더들에게 위임함으로써 최고의 정보를 기반으로 행동하고 반응하게 해야 한다. 경영진들과 비즈니스 리더들은 이 책의 전략을 활용해 높은 성과를 내는 팀에 집중하고, 오늘날의 다양한 요구와 미래의 지평을 효과적으로 다룰 수 있을 것이다.”
― 베리 오라일리(Berry O’Reilly),
엑스캠프(ExecCamp) 창업자, 비즈니스 조언가, 『Unlearn』(McGraw Hill Education, 2018), 『Lean Enterprise』(O’Reilly Media, 2014) 저자
“조직을 어떻게 구성하고 어떤 행동을 독려하는가는 경영의 기본이다. 그럼에도 불구하고, 디지털, 데브옵스 및 SRE 트랜스포메이션을 거치는 IT 조직 설계 패턴을 목록으로 만들고 분석한 이들은 거의 없었다. 스켈톤과 페이스는 이 과감한 도전을 했을 뿐 아니라, 대체할 수 없는 고유한 자원을 만들어 냈다.”
― 데이먼 에드워드(Damon Edwards),
런덱(Rundeck) 공동 창업자
“팀 토폴로지는 흐름의 증진을 위해 팀 구조를 평가하고 최적화하는 데 꼭 필요한 프레임워크를 제공한다. 적절한 규모와 경계, 커뮤니케이션 수준을 갖춘 팀은 기업에게는 가치를, 팀 구성원에게는 만족감을 전달한다. 팀 토폴로지는 체계적 접근 방식과 실제 사례 연구를 조함함으로써 기술팀의 모든 잠재력을 이끌어 낸다.”
― 그렉 버렐(Greg Burrell),
시니어 신뢰성 엔지니어(Senior Reliability Engineer), 넷플릭스(Netflix)
“매튜 스켈톤과 마누엘 페이스가 쓴 팀 토폴로지는 매우 독특하다. 팀 토폴로지는 기술 기업들에게 큰 영향을 끼칠 것이다. 지속적 전달이 가능한 팀을 형성하려면 구조적이고 체계적인 접근 방식을 적용해야 한다. 스포티파이의 몇 가지 규칙을 모방하는 것만으로는 부족하다. 이 책이 부족한 부분을 채워 줄 것이다.”
― 닉 튠(Nick Tune),
API 플랫폼 리드(API Platform Lead), 나비코(Navico)
“콘데 나스트 인터내셔널(Conde Nast International)에서 데브옵스 토폴로지는 현재 데브옵스 상태를 이해하고, 원대한 데브옵스 운영의 비전을 정의하기 위한 핵심이다. 우리는 모델에서 상세히 기술된 내용을 따라 운영상 발생할 수 있는 여러 함정과 안티 패턴을 효과적으로 회피할 수 있었다. 난 매튜와 마누엘이 데브옵스 토폴로지를 한층 성장시키고, 그들이 최신의 학습 결과를 반영해 조직 설계를 위한 팀 토폴로지를 출간해서 더할 나위 없이 기쁘다.”
― 크리스탈 허스콘(Crystal Hirschorn),
엔지니어링(VP of Engineering), 글로벌 전략 및 운영 부문 부사장(Global Strategy and Operations), 콘데 나스트(Condé Nast)
“높은 성과를 내는 팀은 현대 디지털 경제에서 가치를 생성하는 핵심 요소다. 그러나 그런 팀과 관련된 적응 에코시스템을 육성하고 확장하는 것은 굉장히 어려운 목표다. 팀 토폴로지에서 스켈톤과 파이스는 차세대 디지털 운영 모델을 구조화하는 혁신적 도구와 개념을 제공한다. 전 세계 CIO와 아키텍트, 디지털 제품 전략가라면 반드시 읽어야 할 책이다.”
― 찰스 베츠(Charles Betz),
수석 분석가(Principal Analyst), 포레스터 리서치(Forrester Research)
“매튜 스켈톤과 마누엘 페이스는 ‘팀 토폴로지는 기능적인 책이다’라고 말했다. 그들이 한 말은 사실이다. 팀 토폴로지의 구성은 뛰어나고 다루는 내용 또한 명확하다. 건전한 사고방식에 기반하며, 독자로 하여금 조직을 사회 기술적 시스템 혹은 에코시스템으로 간주하게 한다. 이런 가정으로부터 기술적・인간적 조직의 효과적인 설계를 위한 실질적 제안과 기술(단순한 처방이 아니라)을 제공한다. 기술 및 조직 설계에 관심이 있다면 반드시 읽어야 할 책이다.”
― 나오미 스탠포드(Dr. Naomi Stanford),
조직 설계 실천가(Organization Design Practitioner), 교수이자 저자
“패턴과 언어에 관해 매튜와 마누엘이 수행한 연구 결과는 시간 경과에 따른 팀 컨텍스트를 조직에 맞춰 전환하기 위한 전략을 수립하고, 비즈니스와 기술 리더십을 흐름과 지속적 전달 중심으로 연결하는 데 매우 큰 가치를 제공한다.”
― 리차드 제임스(Richard James),
디지털 테크놀로지 & 엔지니어링 수장(Head of Digital Technology & Engineering), 네이션와이드(Nationwide)
“팀은 조직의 기본 구성 요소이며, 팀의 업무 방식과 운영 시스템이 성과의 높고 낮음을 구분한다. 이 책은 여러분의 현재 상황에 맞춰 조직 시스템을 최적화하도록 하는 매우 잘 정의된 정보를 제공한다.”
― 제레미 브라운(Jeremy Brown),
디렉터(Director), 레드햇 오픈 이노베이션 랩스 EMEA(Red Hat Open Innovations Labs EMEA)
“데브옵스는 훌륭하다. 하지만 실제로 조직에서는 이를 어떻게 구현해야 하는가? 사일로가 없는 팀에 모든 구성원을 배치하고, 크나큰 개방형 사무 공간에 함께 앉아 일하고, 점심을 먹고, 축구를 하면 되는가? 팀 토폴로지는 다른 지침서에서는 다루지 않은 데브옵스의 핵심적인 질문들을 해결하는 템플릿을 제공한다.”
― 제프 수스나(Jeff Sussna),
수스나 어소시에이츠(Sussna Associates) 창업자 및 CEO, 『Designing Delivery』(O’Reilly Media, 2015) 저자
“전통적 업무 방식으로 인한 어려움을 분석할 방법, 이를 완화할 수 있는 실질적 전략(즉, 인지 부하 감소, 적절한 팀 API 구현과 같은 새로운 상호 작용 모두)을 찾고 있다면, 지금 즉시 이 책을 읽어라!”
― 다니엘 브라이언트(Daniel Bryant),
기술 컨설턴트 및 어드바이저(Technical Consultant & Advisor) 및 「인포큐(InfoQ)」 뉴스 관리자
“팀 토폴로지는 팀과 팀이 지원하는 IT 아키텍처 사이의 공생 관계를 탐험하는 흥미진진한 읽을거리를 제공한다. 팀 토폴로지는 고정된 조직도나 자기 조직의 혼돈을 넘어 사람과 IT 시스템을 함께 발전시키는 방법을 알려준다.”
― 미르코 헤링(Mirco Hering),
글로벌 데브옵스 리드 엑센추어(Global DevOps Lead Accenture), 『엔터프라이즈 데브옵스』(에이콘, 2020) 저자
추천의 글
시스템을 작고 단순하게 유지하는 것은 가치 있는 목표이며 가장 성공한 시스템의 특성이기도 하다. 리만의 법칙(Lehman’s laws)에서 말하는 소프트웨어 진화, 그중에서도 특히 지속하는 성장은 시스템이 사용되면서 새로운 요구 혹은 기회를 인식함에 따라 새로운 역량들을 추가해야 하는 발전적 압력을 담고 있다. 복잡성이 증가하는 상황에 대처하려면 이중 설계, 즉 시스템 설계와 그 시스템을 생성하고 발전시키는 조직의 설계 영역에 관한 중요성이 커져야 한다. 지금까지 시스템과 소프트웨어 설계, 아키텍처와 관련한 수많은 연구와 업무가 수행됐고, 그 결과 수많은 도메인 주도 설계 및 소프트웨어 아키텍처 관련 서적이 출간됐다. 팀 토폴로지는 콘웨이의 법칙에 기반해 소프트웨어 개발 조직의 설계 문제를 다룬다.
기본적 논지는…즉, 시스템을 설계하는 조직은…그 조직에서 사용하는 커뮤니케이션 경로를 복제한 설계를 할 수밖에 없다는 것이다. 우린 이 사실이 시스템 설계 관리에 커다란 영향을 미치는 것을 봐 왔다.
우리는 조직 설계 구조와 관련된 한 기준을 발견했다. 설계를 위한 노력은 커뮤니케이션의 필요에 따라 조직화돼야 한다. 멜 콘웨이가 논문에서 소프트웨어 개발을 위한 조직 설계에 대해 내린 결론의 인용구는 이 책의 시작과 잘 맞아떨어진다. 팀 토폴로지는 팀 구조와 상호 작용 모드에 관한 조직 패턴을 설명하며, 조직이 시스템에 가하는 힘을 설계에서의 우려 사항으로 간주한다.
흔히 시스템 복잡도가 증가하면, 그 시스템을 구현하고 발전시키는 조직의 인지 요구도 함께 증가한다. 팀 토폴로지 접근 방식은 팀을 설계할 때 명확한 책임과 경계를 가진 팀의 인지 부하를 관리하는 것에 집중한다. 적절한 범위, 책임 경계, 자연스러운(상대적으로 독립적인) 시스템 (하위) 구조는 팀에 정렬돼야 한다. 이를 달성하려면 콘웨이의 법칙이 중요하며, 이를 활용해 명확한 경계를 갖고 느슨하게 결합된 응집 구조를 유지할 수 있다(역 콘웨이 전략이라고도 불리며, 본문에서 설명한다).
그러므로 팀 토폴로지는 콘웨이의 논문을 유용하게 다듬어서 현재 상황에 맞게 설정할 것이다. 물론, 팀 토폴로지는 그 이상이다. 팀 토폴로지에서는 새로운 4가지 팀 패턴을 정의하고, 각 패턴의 산출물, 형태, 해결하거나 형성하는 힘을 설명한다. 스트림 정렬팀은 가장 기본이 되는 팀 유형이다. 이 팀은 흐름에 최적화된 팀이며, 가치를 지속적으로 전달하고, 관련된 피드백 사이클에 완전히 반응하기 위해 노력한다. 다시 말해, 시스템을 설계할 때는 스트림 정렬팀 사이에 필요한 흐름을 지원하고, 의존성과 조정을 낮춰야 함을 의미한다. 난해한 하위시스템 팀과 플랫폼 팀은 스트림 정렬팀의 부하를 줄인다. 스트림 정렬팀은 난해한 하위시스템 팀 혹은 플랫폼 팀이 제공하는 하위 시스템이나 플랫폼 역량(여러 스트림 정렬팀이 수행하는 개발, 전달 및 운영의 모든 단계를 지원한다)을 소비한다. 활성화 팀 또한 비슷하게 다른 팀을 지원하나, 서비스 제공자로 스트림 정렬팀이 새로운 기법을 학습하고 새로운 기술을 조사하도록 돕는다. 이로써 스트림 정렬팀이 효과를 높이는 일에 집중하도록 한다.
매튜 스켈톤과 마누엘 페이스는 그들의 깊은 경험을 책에 녹여냈다. 다양한 팀 유형에 따른 성공에 필요한 요소들을 여러가지 상황 변화에 맞춰 설명하고 설계의 함축성을 식별하면서, 피해야 할 안티 패턴도 설명했다. 또한 관대하게도 실제 업무에서 현실적인 통찰력을 끌어내고, 참고할 것들을 제공한다. 책에 수록된 다양한 사례 연구는 이 책이 지닌 가치를 더욱 높여 준다.
팀 토폴로지는 핵심 구조 패턴, 상호 작용 모드 및 역동, 발전을 위한 고려사항 등 조직 구조와 관련한 정보를 충분히 제공하면서 이를 더욱 깊이 이해할 수 있도록 한다. 팀 토폴로지는 팀을 형성해 도전을 달성하게 하거나 기존 팀이 더욱 효과적으로 가치를 전달할 수 있도록 돕는 실질적이고 명확하며 집중적인 지침을 제공한다.
― 루스 말란(Ruth Malan),
아키텍처 컨설턴트(Architecture Consultant), 브레드메이어 컨설팅(Bredemeyer Consulting)
이 책의 구성
1부에서는 콘웨이의 법칙, 우리가 구현하는 시스템 설계에 조직적 상호 관계가 제약을 가하는 방법과 이런 경향을 활용하는 방법을 살펴본다. 다음으로 팀의 의미를 정의하고 효과적인 팀워크에 영향을 미치는 몇 가지 제약을 다룬다.
2부에서는 업계에서 입증된 일련의 고정적 팀 패턴, 콘웨이의 법칙과 조직 컨텍스트를 염두에 두고 특정 패턴을 선택하는 것의 의미를 살펴본다. 여러분이 속한 조직적 관점에서 더욱 적합한 팀 토폴로지가 무엇인지 광범위하게 생각해 볼 기회가 될 것이다. 2부에서 다룬 내용은 콘웨이의 법칙과 기본 팀 토폴로지를 활용해 팀을 시스템의 특정 영역에 정렬하는 방법을 결정하는 데 도움이 될 것이다.
마지막으로 3부에서는 빠르게 변화하는 운영 환경에 대응해 혁신과 빠른 전달을 달성하는 강력한 역량을 제공할 수 있도록 조직 설계를 진화시키는 방법을 다룬다. 팀 토폴로지 접근 방식을 활용해 시장과 사용자 요구에 민감한 조직을 만드는 방법을 설명하고, 채용과 기술에 미치는 영향을 설명한다.
1, 2, 3부 첫 부분에는 각 장의 핵심 내용을 표시했다. 각 장에는 다양한 도식을 사용해 유용한 정보를 강조했다. 또한 이해하기 쉬운 시나리오, 사례 연구, 서로 다른 환경에 적용할 수 있는 명확한 권장 사항들도 수록했다.
상세 이미지
목차
목차
- 1부. 전달 수단으로서의 팀
- 1장. 조직도의 문제점
- 조직 커뮤니케이션 구조
- 조직도 중심 사고방식의 문제점
- 팀 토폴로지: 팀에 관한 새로운 사고방식
- 부활한 콘웨이의 법칙
- 인지 부하와 병목
- 요약: 팀 구조, 목적, 상호 작용에 대한 재검토
- 콘웨이의 법칙 이해 및 활용
- 2장. 콘웨이의 법칙과 그 중요성
- 역 콘웨이 전략
- 팀 내 흐름을 독려하는 소프트웨어 아키텍처
- 조직 설계와 기술적 전문성
- 불필요한 커뮤니케이션 제한
- 주의: 콘웨이의 법칙의 안일한 적용
- 정리: 콘웨이의 법칙은 효과적인 기술팀 설계에 매우 중요하다
- 3장. 팀 최우선 사고
- 규모가 작고 오랜 기간 유지되는 팀을 표준으로 삼아라
- 좋은 경계는 인지 부하를 최소화한다
- ‘팀 API’를 설계해서 팀 상호 작용을 촉진하라
- 주의: 엔지니어링 프랙티스는 기본이다
- 정리: 팀의 인지 부하를 제한하고 상호 작용을 촉진해서 빠르게 움직여라
- 2부. 효과적인 흐름을 만드는 팀 토폴로지
- 4장. 정적 팀 토폴로지
- 팀 안티 패턴
- 변화 흐름을 위한 설계
- 데브옵스와 데브옵스 토폴로지
- 성공적 팀 패턴
- 토폴로지 선택 시 고려 사항
- 데브옵스 토폴로지를 활용한 조직 개발
- 정리: 현재 컨텍스트에 적합한 팀 토폴로지를 도입하고 발전시켜라
- 5장. 4가지 기본 팀 토폴로지
- 스트림 정렬팀
- 활성화 팀
- 난해한 하위시스템 팀
- 플랫폼 팀
- 변화 흐름에서 팀 사일로를 피하라
- 일반적인 팀 형태를 기본 팀 토폴로지로 바꿔라
- 정리: 4가지 형태의 팀을 느슨하게 연결하고, 모듈화한 그룹으로 사용하라
- 6장. 팀 최우선 경계 선택
- 팀 최우선 접근 방식을 적용한 소프트웨어 책임과 경계
- 감춰진 모놀리스와 결합
- 소프트웨어 경계 혹은 파단면
- 실제 사례: 제조
- 정리: 팀의 인지 부하에 맞춰 소프트웨어 경계를 선택하라
- 3부. 혁신과 빠른 전달을 위한 팀 상호 작용 진화
- 7장. 팀 상호 작용 모드
- 잘 정의된 상호 작용은 효과적인 팀의 핵심이다
- 3가지 핵심 팀 상호 작용 모드
- 상호 작용 모드에 따른 팀 행동
- 적합한 상호 작용 모드 선택
- 기본 팀 조직 선택
- 불확실성을 줄이고 흐름을 개선하는 팀 상호 작용 모드를 선택하라
- 정리: 잘 정의된 3가지 팀 상호 작용 모드
- 8장. 조직적 감지로 팀 구조를 발전시켜라
- 각 팀 상호 작용에 있어 적절한 협력이 어느 정도인가?
- 새로운 프랙티스의 학습과 도입을 가속화하라
- 지속적인 팀 토폴로지 발전
- 팀 토폴로지 조합을 통한 보다 큰 성과
- 팀 토폴로지를 시켜야 할 트리거
- 자기 조정 주도 설계와 개발
- 정리: 진화하는 팀 토폴로지
- 결론 차세대 디지털 운영 모델
- 4가지 팀 유형 및 3가지 상호 작용 모드
- 팀 최우선 사고: 인지 부하, 팀 API, 팀 규모 아키텍처
- 전략적인 콘웨이의 법칙 적용
- 적응력과 감지를 위해 조직 설계를 발전시켜라
- 팀 토폴로지만으로 IT 효과를 달성하긴 충분하지 않다
- 다음 단계: 팀 토폴로지 적용 시작하기
도서 오류 신고
정오표
정오표
[ p.45: 박스 ]
팀 구조는 필요한 소프트웨어 아키텍처와 일치하거나, 의도하지 않은 설계가 산출될 가능성을 감수해야 한다.
->
팀 구조는 반드시 소프트웨어에 필요한 아키텍처와 일치해야 한다. 그렇지 않으면 의도하지 않은 설계가 이루어질 위험이 있다.
[ p.68: 마지막 행 ]
동형의 힘(isomophic force)을 활용할 수 있다.
->
동형의 힘(isomorphic force)<주석: 동형성(isomorphism)에 대해 이해하면 동형의 힘도 이해하기 쉽다. 사회학에서 동형성은 둘 혹은 그 이상의 조직이 프로세스/구조 면에서 갖는 유사성을 의미하며, 이는 모방 혹은 유사한 제약 아래서 독립적으로 개발된 결과일 수 있다(https://en.wikipedia.org/wiki/Isomorphism_(sociology)). 본문에서는 콘웨이의 법칙의 영향을 고려해 유사한 소프트웨어를 개발하는 팀의 구조를 유사한 방식으로 만드는 것을 의미한다. - 옮긴이>을 활용할 수 있다.