Team Topologies(팀 토폴로지)

최근 직장 동료로 부터 이 책을 추천 받았다. 책의 내용은 IT 조직 구조에 따른 협업관계 그리고 업무 플로우와 시스템의 커플링의 이야기이다.

 

책을 읽으며 많은 것을 느끼게 되었다. 경력이 이제 막 10년차에 들어서 현재 직장에서 많은 고객사를 만나지만 지금까지의 거쳐왔던 회사들도 그렇고 같은 고민을 항상 했었다.

 

'책에서 말하는 BP는 모두가 알고 있을텐데 왜 따라가지 않을까?'

내가 지니고 있던 Bias를 완전 해결해주는 답을 얻었다. 그 당시 그럴수 밖에 없었고 그것이 최선이었기 때문에 선택을 한 것이다. 특히 예시를 든 대기업의 사례가 특히 와닿았다. 많은 대기업이 큰 관계형 데이터베이스에 강력한 결합과 의존성을 지니고 있다. 현재에 와서 많은 기업이 이 의존성에서 벗어나기 위한 IT 현대화에 많은 노력과 투자를 하고 있다. 그래서 조직 구조보다는 기술적인 노하우와 액티비티가 중요하다고 생각했었다.

 

하지만 이 책은 반대로 Working Backwards 전략을 취한다. Project 보다는 Product를 생각하게 하고 모든 구성원이 이 궁극적인 Outcome을 이루기 위한 방향성을 어떤 구조로 가져갈 수 있는지 설명한다.

팀은 기술적 노하우나 액티비티가 아니라 비즈니스 도메인 영역에 맞춰 구성 해야한다.
- 유타 에크스타인

 

모든 Architecture에는 오답이 없고 비싼 정답만 있다. 그래서 IT 시스템의 Architecture는 그 당시 최선의 선택을 한 것이라고 생각해 왔다. 하지만 조직은 달랐다. 7번째 회사에 온 지금에서도 돌이켜보면 그 당시 조직 구조는 왜 이럴까? 왜 매번 조직개편을 하면서 피곤하게 context를 스위칭 시킬까? 라면서 불평 불만이 많았다.

 

이 물음에 답을 주는 책이었다. 첫 장을 펼친 이후로 하루만에 다 읽으며 되새길 부분에 인덱스를 걸어 놓았다. 이 책은 IT 종사자라면 특히 관리 직에 있을 시니어 급이라면 모두가 아는 법칙을 가지고 다양하고 자세하게 설명해준다.

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

이것을 자세하기 알지 못하고 잘못된 의미로 해석할 수도 있다. 그렇다면 조직 구조를 어떻게 해야할까? 모놀로식 레이어드 아키텍쳐를 가진게 과연 잘못된 걸까? MSA를 하기위해 조직을 나누는게 올바른 것일까? 역 콘웨이 전략을 따라야 할까?

 

다양한 물음이 앞서는 와중 요즘 읽고 있는 DDD관련된 책과 굉장히 밀접한 부분이 있다는 것을 알게 되었다. Bounded Context에 대한 내용이다. DDD에서 Bounded Context는 해당 도메인의 Boundary를 설계하고 ACL또는 OHS를 통해 제공자와 사용자간 커플링을 적절하게 관리한다.

 

조직 구조도 마찬가지이다. A팀과 B팀 C팀이 있을때 A팀과 B팀이 긴밀하게 협업 하고 자주 소통한다면 이것은 A팀의 도메인과 B팀의 도메인이 밀접한 커플링이 있다는 반증이 된다. 반대로 B팀과 C팀은 서로 협업을 하지만 모든 것은 API 명세등으로 소통하며 시스템이 연계 되어있다. 이것은 현재 Amazon에서 취하는 방식으로 Two-pizza Team과 관련이 있다. 

 

그렇다면 B팀과 C팀의 협업이 많지 않으면 표준없이 개발되지 않을까? 하는 물음이 생길수 있다. 이 책에서는 팀의 규모가 적을 수록 인지 저하가 줄어들고 상위 조직의 공동 책임 모델을 가지고 별도의 API명세와 같은 도구 또는 문서로 협업을 하라는 식의 가이드를 제공한다.

 

Communication between teams is also important as you move toward the shared responsibility model and start moving out of the siloed development approach. This brings the concept of ownership to the team, and shifts their perspective to look at the process as an end-to-end venture. Your team should not think about your production environments as black boxes where they have no visibility.
Two-Pizza Team

 

이처럼 조직간의 도메인 그리고 핵심 도메인이나 난해한 도메인의 수를 제한하며 다른 조직의 도메인과 초소한의 커플링을 가지고 가는것을 이 책에서는 지속적으로 이야기 한다.

 

콘웨이의 법칙은 지금까지 내 경험으로는 정론이자 진리와 같았다. 하지만 나는 많은 부분을 잘못 해석하고 있었다. 많은 부분에서 인사이트를 주는 책이었다. 한번쯤 꼭 읽어보길 추천한다.