사내에서 같이 책을 읽고 논의하면서 읽게 된 책인데 원래는 출간한 지도 몰랐던 책이다. 하지만 이 책은 DevOps Topologies를 만든 사람들이 쓴 책이다. DevOps Topologies는 몇 년 전 인상 깊게 보고 종종 DevOps 조직이 어떻게 움직여야 하는지 고민할 때 참고하는 사이트여서 이 책에 대해서도 기대를 하게 되었다. 내가 조직 구조에 대해서 많이 고민해 본 편은 아니라 조직구조를 다루는 책을 많이 읽진 않은 거 같은데 소프트웨어에 기반을 둔 IT 업체에서 조직 구조를 어떻게 설계해야 하는지에 대해서 다루고 있는 점이 흥미로웠다.

1부 전달 수단으로서의 팀

조직은 자신의 커뮤니케이션 경로를 반영한 설계를 하도록 제약받는다.
- 콘웨이

콘웨이가 말한 법칙이란 조직 커뮤니케이션의 실제 경로(닐스 플래깅이 언급한 가치 창출 구조)와 조직이 개발한 소프트웨어 아키텍처 사이의 강한 연관성, 혹은 알란 켈리가 준동형의 힘(homomorphic force)이라 부른 것을 의미한다.

설계가 조직의 구조를 벗어나지 못한다는 거로 유명한 콘웨이의 법칙에 대해 여기서는 역 콘웨이 전략으로 접근하는 걸 얘기하고 있다. 조직 구조가 커뮤니케이션 구조를 벗어나지 못하므로 원하는 제품과 설계에 맞게 조직 구조를 만드는 것이다. 같은 말인 것 같으면서도 반대로 접근한다는 게 재미있었다.

소트웍스 기술 책임자인 제임스 루이즈와 몇몇 기술자들이 역 콘웨이 정략('inverse conway maneuver' 혹은 'reverse Conway maneuver')을 적용해 팀 구조를 설계하자고 제안했다. 역 콘웨이 전략은 팀이 준수해야 하는 고정된 아키텍처 디자인이 아니라, 시스템이 수행해야 하는 것에 초점을 맞춘 팀 구조 설계를 집중한다.
다시 말해, 소프트웨어 아키텍처를 분리해서 설계할 수 있고, 설계 후에는 어떤 그룹이든 이를 구현할 수 있다고 보는 개념이 근본적으로 잘못됐다는 것이 핵심이다.

우리의 연구는 역 콘웨이 전략의 효과성을 뒷받침한다. 역 콘웨이 전략이란 조직이 바라는 (소프트웨어) 아키텍처를 구성하려면 그 팀과 조직 구조를 바꿔야 한다는 것이다. 이 전략은 설계부터 배포에 이르는 동안 팀 사이에 폭넓은 커뮤니케이션 활동이 없더라도, 팀이 업무를 완수할 수 있도록 지원하는 것을 목표로 한다.

관련해서 조직도와 실제 업무를 하기 위해서 조직도와 상관없이 이뤄지는 커뮤니케이션에 관해서 얘기하고 있고 조직이 이런 커뮤니케이션이 더 원활하게 이뤄지고 고립되는 팀이 없게 해야 함을 얘기하고 있다고 이해했다. 전혀 없을 수는 없겠지만 실제 조직도와 업무를 수행하기 위해서 얘기해야 하는 사람이 다른 경우나 조직도의 체계 때문에 일을 할 때 방해받는 느낌을 받은 경험이 있어서 꽤 공감이 갔다.

인지 부하라는 용어는 1988년 심리학자인 존 스웰러가 '업무를 기억하는 데 들이는 정신적 노력의 총량'이라는 표현을 한 이후 사용되기 시작했다. 스웰러는 인지 부하를 다음 세 가지로 분류한다.
* 내적 인지 부하: 문제 영역의 기본 태스크 관련 인지 부하(예: '자바 클래스 구조란 무엇인가?', '새로운 방법은 어떻게 창출하는가?' 등)
* 외적 인지 부하: 수행 중인 업무의 환경 관련 인지 부하(예 '구성요소를 어떻게 재배치해야 하는가?', '서비스 설정은 어떻게 해야 하는가?' 등)
* 관련 인지 부하: 학습이나 높은 성과 달성 과정에서 주의해야 할 업무 관련 인지 부하(예 '이 서비스가 ABC 서비스와 어떻게 상호작용해야 하는가?' 등)

조직이 현대 소프트웨어 시스템을 효과적으로 전달하고 운영하는 방법은 내적 인지 부하(교육, 좋은 기술 선택, 채용, 페어 프로그래밍 등)를 최소화하고, 외적 인지 부하(지루하거나 불필요한 작업, 업무 기억에 가치를 더하지 못하는 작업, 자동화 가능한 작업 등)를 제거하려 노력하는 것이다.

첫 번째 휴리스틱은 한 도메인을 한 팀에 할당하는 것이다. 도메인의 크기가 한 팀이 다루기에 너무 크다면, 도메인의 책임을 여러 팀에 부여하지 말고, 해당 도메인을 하위 도메인으로 나눈 뒤, 각 하위 도메인을 한 팀에 할당한다.
두 번째 휴리스틱은 한 팀(팀의 최적 인원은 7~9명이다)에 2~3개의 단순 도메인을 할당하는 것이다. 이런 도메인은 상당히 절차적이며 기계적으로 대응하기 때문에, 도메인 간 컨텍스트 전환 비용이 발생하더라도 감당할 수 있다.
세 번째 휴리스틱은 복잡한 도메인을 담당하는 팀에 다른 도메인을 더 할당하지 말아야 한다는 것이다. 아주 간단한 도메인일지라도 더는 맡게 해서는 안 된다.
마지막 휴리스틱은 한 팀이 난해한 도메인을 2개 이상 책임지지 않도록 해야 한다는 것이다. 8~9명 규모의 팀이라면 2개 도메인을 잘 다룰 수 있을 것 같지만 실제로는 그렇지 않다.

인지 부하를 얘기한 점도 흥미로웠는데 사람이 받아들일 수 있는 인지 부하는 한계가 있으니 이를 계속 관찰하고 적절하게 조정할 수 있어야 업무가 원활하게 진행될 수 있다는 것이다. 내가 다른 사람보다 인지 부하가 높은지는 잘 모르겠지만 보통 업무나 관심사에 제한을 안 두고 같이 일하는 걸 선호하는 편이라서 의사결정이나 협업할 때도 그런 쪽에 더 무게 중심을 두는 경향이 있는 편이라 인지 부하를 제한해야 한다는 부분은 더 많은 생각을 하게 했다.

2부 효과적인 흐름을 만드는 팀 토폴로지

세심하게 고려한 결과에 따란 만든 팀 구조를 팀 토폴로지라고 부르며, 팀을 의도적으로 조직 안에 배치하는 동시에, 각 팀의 책임 경계를 참조해야 함을 의미한다.

조직은 팀을 설계할 때 다음 질문을 의도적으로 던져야 한다. 우리가 보유한 기술과 제약 사항, 문화 및 엔지니어링 성숙도, 원하는 소프트웨어 아키텍처 및 비즈니스 목표 등을 고려했을 때, 어떤 팀 토폴로지를 사용해야 결과를 더 빠르고 안전하게 전달할 수 있는가? 주요 변화 흐름에서 팀 간 업무 전달을 줄이거나 피하려면 어떻게 해야 하는가? 소프트웨어 시스템의 어느 부분에 경계를 설정해야 시스템 생존성을 보전하고, 빠른 흐름을 유도할 수 있는가? 우리 조직 내 팀들을 그런 흐름에 맞춰 정렬하려면 어떻게 해야 하는가?

이 책에서는 스포티파이의 Spotify Model에 관해서 긍정적으로 다루는 부분이 나오고 있어서 Spotify Model이 실패했다는 Failed #SquadGoals에 대한 생각이 궁금하기도 했다. 내가 지금 있는 조직도 비슷한 형태의 모델을 사용하고 있고 최근 많은 스타트업이 하고 있어서 개인적으로 이 모델의 호불호가 있는 것은 아니고 그냥 궁금하다고 해야 할까? 나는 SRE로 일하면서 SRE가 기능 조직으로 따로 움직이기 때문에 따로 목적조직에서 chapter나 guild를 구성해서 일해본 경험이 없어서 혼자서 장단점을 판단하기가 어려웠다.

데브옵스 토폴로지는 두 가지 핵심 아이디어를 제공한다. (1) 데브옵스 성공을 위한 팀 구성 방식에는 만병통치약 같은 접근법이 존재하지 않는다. 모든 토폴로지는 적용되는 조직의 컨텍스트에 따라 그 적합성과 효과가 다르다. (2)데브옵스의 성공을 가로막는 여러 해로운 토폴로지(즉, 안티패턴)가 존재한다. 이 토폴로지들은 데브옵스 원칙을 어기거나 간과한다. 다시 말해, 모든 조직에 통용 가능한 올바른 토폴로지는 없지만 모든 조직에 해로운 토폴로지는 여럿 존재한다.

이전에 성공(?)했던 데브옵스 토폴로지도 얘기하는데 팀 팀 토폴로지도 비슷한 관점이라고 생각한다. 은총알 같은 방법은 존재하지 않지만 안티패턴을 존재하고 팀 토폴로지를 조직에 적용할 때도 팀의 많은 상황을 고려해야겠지만 그부분에서 안티패턴은 조심할 수 있을 것 같다.

팀의 자율성을 유지하려면 팀의 외부 의존성에 의해 차단되지 않도록 하는 것, 즉 새로운 기능들이 팀의 통제력을 넘어서는 어떤 일이 일어나기를 기다리느라 한가롭게 멈춰 있지 않도록 하는 것이 핵심이다.

책에서 전반적으로 얘기하고 있는 부분은 "팀이 자신이 하는 일을 끝까지 해내기 위해 다른 팀에 의존해서 막히거나 지연되는 일이 없도록"하는 부분이라고 이해했다. 그래서 아래처럼 팀을 4가지 범위로 정의하고 있는데 사실 이름이 좀 어려워서 확실히 감이 오진 않는다.

팀 유형을 다음과 같은 4가지 기본 팀 토폴로지 범위로 좁힐 수 있다.
* 스트림 정렬팀
* 활성화팀
* 난해한 하위시스템 팀
* 플랫폼 팀

스트림 정렬팀

스트림이란 비즈니스 도메인이나 조직 역량에 맞춘 업무의 지속적 흐름을 의미한다. 지속적 흐름을 달성하려면 목적과 책임을 명확하게 정의해야 한다.

스트림 정렬팀은 가치 있는 단일 업무 스트림에 정렬된다. 가치 있는 단일 업무 스트림이란 한 제품 혹은 서비스 기능 세트, 사용자 스토리 혹은 사용자 퍼소나일 수 있다. 또한, 팀은 고객이나 사용자 가치를 가능한 한 빠르고 안전하고 독립적으로 구현하고 전달할 수 있는 권한을 부여받는다. 업무 중 일부를 수행하기 위해 다른 팀에 핸드오프를 할 필요가 없다.

가장 중요한 팀은 스트림 정렬팀이다. 소위 말하는 목적 조직 즉, 특정 서비스를 맡아서 개발하는 팀을 의미했고 비즈니스 도메인을 해결할 때 문제 한두 개만 풀면 되는 게 아니라 지속해서 추적하고 개선하면서 해결해 나가야 했기에 스트림 정렬이라는 표현을 쓴 것 같다. 꼭 비즈니스 도메인에만 국한된 것은 아니지만 회사라는 특성을 생각해 보면 비즈니스 도메인을 맡아서 진행하는 목적 조직으로 이해해도 큰 무리는 없다고 생각했다.

스트림 정렬팀은 조직에서 가장 주요한 팀 유형이며 다른 팀 토폴로지를 따르는 팀들은 스트림 정렬팀의 부하를 줄이기 위해 존재한다.

스트림 정렬팀은 구성원은 자율성, 전문성, 목적성을 달성하고 있다는 성취감을 느낀다. 다니엘 핑크는 이 세 가지를 몰입하는 지식 근로자의 핵심 요소라고 말했다.

이후 나오는 3개의 팀 분류는 모두 스트림 정렬팀을 위해서 존재한다. 스트림 정렬팀이 더 일을 잘하게 하도록 하는 게 그 목적인데 서로 다른 것 같기도 하면서 비슷한 것 같기도 하고 좀 헷갈리긴 했다.

활성화팀

활성화 팀은 주어진 기술(혹은 제품) 도메인의 전문가들로 구성되며, 이들은 각자의 전문 영역에 대한 역량 차이를 메우는 가교 구실을 한다. 활성화 팀은 스트림 정렬팀과 교차 협업하면서 필요한 연구를 수행하거나, 다른 선택 사항을 시도해 보거나, 애플리케이션 스택에 적합한 도구와 프랙티스, 프레임워크 및 에코시스템 선택에 대한 적절한 정보를 제공한다. 스트림 정렬팀은 이를 활용해 별도의 노력을 기울이지 않고도 역량을 획득하고 발전시킬 수 있다.

활성화 팀은 스트림 정렬팀의 자율성을 높이는 것을 목표로 한다.

활성화 팀이 그들의 역할을 잘 해낸다면, 스트림 정렬팀은 몇 주 또는 몇 달 후에는 더는 활성화 팀의 도움을 받을 필요가 없어지므로 활성화 팀에 대한 의존성 또한 사라진다.

나한테는 가장 이해가 안 되는 분류이긴 했다. 특정 기술의 전문가들이 있으면서 스트림 정렬팀이 역량을 가질 수 있도록 노력하는 팀은 어떤 회사는 어느 정도 존재하기는 하지만 스트림 정렬팀의 지식과 경험을 전달하는 게 쉽지 않음을 빼고 생각하더라도 자신과의 의존성이 없어지도록 할 수 있는 팀이란 건 결국 자신의 존재를 지워야 하는 것인데 어떤 형태가 되어야 할지 잘 감이 오지 않았다.

난해한 하위시스템 팀

난해한 하위시스템 팀은 전문 지식에 깊이 의존하는 시스템 일부를 구축하고 유지할 책임이 있다. 따라서 난해한 하위시스템 팀은 (난해한) 하위시스템을 이해하고 변경할 수 있을 만큼, 해당 영역에 관해 일정 수준 이상의 지식과 경험을 갖춘 전문가로 구성된다.

난해한 하위시스템 팀의 목표는 복잡한 하위시스템을 포함하거나 사용하는 시스템에서 작업하는 스트림 정렬팀의 인지 부하를 줄이는 것이다.

난해한 하위시스템 팀의 임무는 전문가 집단이 개발해야 하는 난해한 하위시스템에 스트림 정렬팀이 투입하는 노력을 덜어내는 것이다.

이 팀 분류는 이름부터가 난해한데 활성화 팀과는 다르게 스트림 정렬팀이 직접 만들기 어려운(시간 혹은 리소스가 부족하거나 너무 복잡하거나) 시스템을 만드는 팀이라고 이해가 되기는 하는데 활성화 팀과 플랫폼 팀과 겹치는 부분이 많아 보여서 딱 구분되게 느껴지지 않았다.

플랫폼 팀

플랫폼 팀의 목적은 스트림 정렬팀이 충분한 자율성을 띠고 업무 결과를 전달하도록 돕는 것이다.

모든 스트림 정렬팀이 프리미엄 레벨 서비스(무중단 서비스나 자동 확장 또는 자동 복구 기능 지원 등)을 요구한다면 플랫폼 팀은 그 요구를 처리하지 못할 가능성이 커진다.

팀의 요구와 동떨어진 플랫폼을 구현하는 흔한 함정에 빠지지 않으려면 플랫폼 팀이 사용자 경험과 개발자 경험에 특히 집중해야 한다.

아마 내가 속한 조직이 플랫폼 팀에 가까울 것이고 많은 조직에서 플랫폼 팀과 비슷한 이름의 팀은 존재하기 때문에 이해는 되었지만, 플랫폼 팀과 난해한 시스템팀은 차이는 사실 잘 모르겠다.

3부 혁신과 빠른 전달을 위한 팀 상호 작용 진화

3부에서는 이러한 팀이 서로 어떻게 상호작용해야 하는지를 얘기한다. 다시 강조하자면 이 책에서 계속 얘기하는 것은 역 콘웨이 전략으로 팀을 중심에 두고 팀 간에 커뮤니케이션이 어떻게 해야 서비스를 잘 만들 수 있는 팀 토폴로지를 구성할 수 있는지를 얘기하고 있다.

조직은 팀 패턴을 발전시킴으로써 비즈니스와 조직, 시장, 기술 및 개인의 요구를 만족시켜야 한다.

팀 간 관계를 고려할 때는 한 목적을 달성하기 위해 다른 팀과 협력할 것인지 혹은 다른 팀을 서비스로 간주할 것인지를 결정하는 것이 핵심이다.

팀 최우선 역동과 콘웨이의 법칙을 따라 팀이 상호작용하고, 이때 따라야만 하는 3가지 핵심 방법을 정의하고 이해해야 한다.
* 협력(Colloaboration): 다른 팀과 밀접하게 함께 일한다.
* 엑스 애즈 어 서비스(XaasS, X-as-a-Service): 최소한으로 협력하며 무언가를 소비하거나 제공한다.
* 촉진(Facilitating): 다른 팀을 돕거나 다른 팀의 도움을 받아 장애를 없앤다.

협력

협력 상호 작용 모드는 새로운 기술과 기법을 탐색하는 업무 등 높은 수준의 적응력이나 발견이 필요할 때 적합하다.

두 팀이 협력 모드로 상호 작용할 때는 협업에 드는 비용이 매우 높으므로, 그만큼 높은 가치를 얻어야 한다는 의미다. 보상은 손에 잡히는 것이어야 한다.

지속적 협력이 필요하다는 것은 도메인 경계나 팀 책임, 혹은 팀 내 기술 조합이 잘못된 상태라는 것을 의미할 수도 있다.

장점
* 빠른 혁신과 발견
* 적은 핸드오프
단점
* 각 팀은 넓은 범위에 걸쳐 공유 책임이 있음
* 팀 사이에 더 많은 세부 사항과 컨텍스트가 필요하며, 인지 부하를 높임
* 이전과 비교해 협력하는 동안 산출물이 감소할 수 있음
제약 사항: 한 팀은 최대 1개 팀과 협력 모드를 사용해야 한다. 2개 이상의 팀과 동시에 협력 모드를 사용해서는 안 된다.
일반적 사용: 난해한 하위 시스템 팀과 협력하는 스트림 정렬팀, 플랫폼 팀과 협력하는 스트림 정렬팀, 플랫폼 팀과 협력하는 난해한 하위시스템 팀

여기서 협력은 아주 밀접하게 붙어서 일하는 것으로 이해했다. 팀 토폴로지를 계속 커뮤니케이션 흐름으로 풀고 있고 팀 간의 의존성을 주의 깊게 보고 있기 때문에 일시적으로 협력 모드로 일하는 것 은 가능하지만 지속해서 협력으로 일해야 한다면 두 팀의 경계를 다시 살펴봐야 한다는 부분에 공감되었다.

엑스 애즈 어 서비스

하나 혹은 둘 이상의 팀이 특별한 노력 없이도 동작하는 코드 라이브러리, 컴포넌트, API 혹은 플랫폼을 사용해야 하는 상황에서는 엑스 애즈 어 서비스 상호 작용 모드가 적합하다. 별도의 팀이나 팀 그룹이 서비스로서 해당 시스템의 한 컴포넌트 혹은 한 부분을 효과적으로 제공한다.

액스 애즈 어 서비스 팀 상호 작용 모드에서는 상호 작용하는 2개 팀 사이에 서비스로서의 컴포넌트, API, 기능을 사용하거나 제공하기 위한 일상적 협력이 거의 필요 없다. 바로 이것이 엑스 애즈 어 서비스 모델의 가장 분명한 장점이다.

어떤 대상(컴포넌트, API, 테스팅 도구, 혹은 전달 플랫폼 전체 등)을 서비스로 제공하고자 할 때, 서비스를 제공하는 팀은 서비스를 소비하는 팀과 자신들이 제공하는 서비스의 생존 가능성을 책임져야 한다. 또한 뛰어난 개발자 경험(DevEx)을 제공해야 한다.

장점
* 명확한 오너쉽과 분명한 책임 경계
* 팀 간 세부 사항과 컨텍스트 감소로 인한 인지 부하 제한
단점
* 경계 혹은 API의 비교적 느린 혁신
* 효과적이지 않은 경계 혹은 API에 의한 흐름 저하 가능성
제약 사항: 한 팀은 단일 서비스를 소비하거나 제공하는 것이 아니라, 여러 팀과 동시다발적으로 엑스 애즈 어 서비스 상호 작용하게 됨
일반적 사용: 스트림 정렬팀과 난해한 하위시스템 팀은 플랫폼 팀이 제공하는 엑스 애즈 어 서비스를 소비함. 스트림 정렬팀과 난해한 하위시스템 팀은 난해한 하위시스템 팀이 제공하는 컴포넌트 혹은 라이브러리를 서비스로 소비함.

회사에서 작년부터 만들고 있던 서비스를 XaaS로 제공하기 위해서 큰 노력을 하고 있었기에(이런 정의를 해서 접근하고 있진 않았지만...) 공감이 많이 갔던 부분이다.

촉진

하나 혹은 그 이상의 팀이 수행하는 업무의 특정 측면을 다른 팀이 촉진(혹은 코칭)함으로써 이익을 얻을 수 있는 상황에서는 촉진 상호 작용 모드가 적합하다.

장점
* 스트림 정렬팀이 흐름을 증진할 수 있도록 도움
* 팀 간 세부 사항과 컨텍스트 감소로 인한 인지 부하 제한
단점
* 대상을 직접 구현하거나 운영하지 않기 위한 숙련된 인원 필요
* 촉진에 참여한 팀 중 하나 혹은 양쪽 모두에게 상호 작용이 어색하거나 이상할 가능성
제약 사항: 한 팀은 촉진 제공이나 소비와 관계없이 적은 수의 팀과 촉진 상호 작용 모드를 사용해야 함
일반적 사용: 활성화 팀은 스트림 정렬팀, 난해한 하위시스템 팀 혹은 플랫폼 팀을 도움

소프트웨어 개발 방법론에서 일반적으로 접근하듯이 조직에서도 잘못된 부분을 파악해서 지속해서 조직 구조를 발전시킬 것을 강조하고 있다.

대부분의 설계란... 최선인 경우는 거의 없었다. (그래서) 우리 중에 만연해 있는 시스템의 개념을 바꿔야 한다. 효과적인 설계를 하기 위해서는 조직의 유연성이 중요하다.
- 멀 콘웨이, “How Do Committees Invent?”

소프트웨어를 구현하고 운영하는 현대 조직 설계에 있어, 가장 중요한 것은 조직의 형태가 아닌 새로운 어려움이 나타났을 때 조직을 적응 및 변화시키기 위해 활용할 규칙과 휴리스틱을 결정하는 것이다. 다시 말해, 조직 자체가 아니라 조직 구성에 필요한 규칙을 설계해야 한다.

팀 토폴로지만으로 효과적으로 소프트웨어를 전달하고 운영하는 조직을 만들기는 충분하지 않다. 이 책에서 제시한 구조와 역동 이외에도, 다양한 성공 요인이 존재한다.
* 건강한 조직 문화
* 훌륭한 엔지니어링 프랙티스
* 건강한 자금 및 재무 프랙티스
* 명확한 비즈니스 비전

정리

같은 조직에서 일하는 사람들과 논의하면서 읽어서 더 재미있게 읽었던 것 같다.

회사의 전체 조직 구조를 고민하는 게 주 업무는 아니기 때문에 아무래도 내가 속한 조직을 중심으로 생각하게 된 것 같다. 현재 SRE팀에서 배포 시스템을 만들고 있기 때문에 플랫폼 팀이면서 난해한 하위시스템 팀 같기도 했고 배포도 물론이지만 SRE팀은 클러스터나 클라우드 인프라, 모니터링 관련 정보를 지속해서 목적 조직에 전달하고 있기 때문에 활성화 팀의 역할도 하는 것 같다고 생각했다.

상호 작용에 대해서는 XaaS로 배포시스템을 만들고 있는 것은 방향은 맞게 가고 있다는 생각이 들었다. 여기 들어온 지 오래되진 않았지만, 그 이전에는 배포나 모니터링 관련해서 협력 관계로 일했을 거로 생각하고 이런 경험을 토대로 XaaS로 설계를 하게 되고 그 중간단계나 아직 커버하지 못한 부분은 촉진하면서 XaaS를 더 발전시키는 것 같다고 느껴졌다. 다른 팀도 비슷할 것 같지만 상호 작용은 딱 한 가지 모드로만 일한다기보다는 시기에 따라서 협력, XaaS, 촉진이 오가면서 일하게 되는 것 같고 여기서 특정 모드에만 고정되는 것이 주의해야 할 부분이라고 생각이 들었다.