스포티파이 조직 모델

 

인트로

스포티파이 조직 관리 모델이 있다. 왜 스포티파이 모델이냐? 이유는 스포티파이가 만들었기 때문 ㅎㅎ.

‘프로덕트 매니저는 무슨 일을 하고 있을까’ 라는 책을 읽으면서 알게 된 방법론인데, 몇몇 스타트업에서 도입하고 있는 Guild 라는 제도가 여기 스포티파이 모델에 나오는 Guild와 유사한 것인가 궁금해서 이 모델을 찾아 정리해 보았다. 이 글은 스포티파이 모델에 대한 대략적인 내용과 현재의 평을 다룰 예정.

 

Hope you enjoy it!

스포티파이 모델이란?

아틀란시안에서 말하는 스포티파이 모델은 문화와 네트워크의 중요성을 강조하면서 애자일을 확장하기 위한 사용자 중심의 자율적인 접근 방식이다. 스포티파이 모델은 제품 개발을 위한 조직에서 여러 팀을 조직하는 한 가지 예시라고 할 수 있으며 문화와 네트워크의 필요성을 강조합니다. 또한 이 모델은 애자일을 지원할 수 있도록 조직을 구성하는 방법에 중점을 둔다.

 

스포티파이 모델은 2012년 Henrik Kniberg와 Anders Ivarsson이 Spotify가 애자일에 접근하는 혁신적으로 간단한 방법을 소개한 백서 Scaling Agile @ Spotify를 발표하며 세상에 알려졌다. 그 이후로 스포티파이 모델은 많은 화제를 불러 일으켰고 애자일하게 변화하는 조직에서 널리 사용되고 있다. 이 모델이 인기있는 이유 중 하나는 특정 관행을 따르기보다는 작업을 중심으로 조직하는 데 중점을 둔다는 점이다. 기존 확장 프레임워크에서 특정 관행(예: 데일리 스탠드업)은 프레임워크를 실행하는 방식인 반면, 스포티파이 모델은 기업이 애자일을 활성화하기 위해 조직을 구성하는 방법에 중점을 둔다.

 

스포티파이 모델은 팀의 자율성을 중시하므로 각 팀(또는 스쿼드)이 각자 프레임워크(예: 스크럼, 칸반, Scrumban 등)를 선택한다. 또한 스쿼드는 트라이브와 길드로 조직되어 팀원들을 정렬하고 지식을 교차 분배하도록 돕는다.

 

스포티파이 모델의 구성 요소

스포티파이 모델의 핵심은 단순성이다. Spotify는 업무를 중심으로 조직하기 시작했을 때 팀원과 팀을 구성하는 방법에 대한 몇 가지 중요한 요소를 식별했다. 프로덕트 매니저는 무슨 일을 하고 있을까? 책에도 나온 사진과 동일한 것은 아틀라시안에서 가져왔다. (근데 책에서는 스쿼드, 트라이브, 챕터, 길드에 대해서만 언급했다.)

1. 스쿼드
   • 스크럼 팀과 마찬가지로 스쿼드는 하나의 기능 영역에 중점을 둔 자율적인 교차 기능 팀이다. (일반적으로 6~12명). 각 스쿼드에는 자신이 수행하는 작업을 안내하는 고유한 미션, 지원을 위한 애자일 코치 및 안내를 위한 제품 소유자가 있다. 스쿼드에서는 어떤 애자일 방법론/프레임워크를 사용할지 결정한다.
   • 내가 느끼기엔 토스 등 스타트업에서 사일로라고 부르는 조직 구성 방법과 유사하다.
2. 트라이브
   • 동일한 기능 영역 내에서 여러 스쿼드가 서로 조정하면 트라이브가 형성된다. 트라이브는 여러 스쿼드 간에 정렬을 구축하도록 돕고 일반적으로 정렬을 유지하기 위해 40~150명(던바의 수 활용)으로 구성된다. 각 트라이브에는 스쿼드 간 협업을 돕고 협업을 장려하는 일을 담당하는 트라이브 리더를 둔다.
3. 챕터
   • 스쿼드는 자율적이지만 전문가(예: Javascript 개발자, DBA)는 모범 사례에 정렬하는 것이 중요하다. 챕터는 **각 전문가가 소속한 패밀리(디자인 리더, 테크 리더, PO 등)**이며 한 분야에 걸쳐 엔지니어링 표준을 유지하는 데 도움이 된다. 일반적으로 챕터는 선임 기술 리더가 주도하며, 이들은 또한 해당 챕터의 팀원 관리자일 수도 있다.
4. 길드
   • 주제에 대한 열정이 있는 팀원은 기본적으로 관심사가 같은 커뮤니티인 길드를 구성할 수 있다. 즉, 공통 관심사를 가지고 모인 팀원들이라고 말할 수 있다. 길드에는 누구나 완전히 자발적으로 가입할 수 있어야 하며, 챕터는 트라이브에 속하지만 길드는 여러 트라이브 간에 걸쳐 있을 수 있다. 길드의 공식 리더는 없고 오히려 누군가가 자발적으로 길드 코디네이터가되어 참가자들을 하나로 모으는 데 도움을 줄 수 있다.
5. 트리오
   • 트리오(일명 TPD 트리오)는 트라이브 리더, 제품 리더 및 디자인 리더의 조합이다. 각 트라이브에는 기능 영역에서 작업할 때 이 세 가지 관점 간에 지속적으로 정렬할 수 있도록 트리오가 있다.
6. 얼라이언스
   • 조직이 확장됨에 따라 목표를 달성하기 위해 때때로 여러 트라이브가 긴밀하게 협력해야 한다. 얼라이언스는 어떤 한 개의 트라이브보다 큰 목표를 달성하도록 트라이브 협업을 지원하기 위해 협력하는 트라이브 트리오(일반적으로 세 개 이상)의 조합이다. 즉, 트라이브의 집합.

스포티파이 모델 참고 이미지

 

이점

1. 덜 공식적인 절차: 제품 개발하는 군들을 쪼개놓았기 때문에, 그들이 결정하고 일을 진행하게 되므로 의사결정의 절차가 짧아진다.
2. 자체 관리 및 자율성: 쪼개진 조직 별로 관리를 각자가 진행할 것이기 때문에 자체 관리가 될 것이며, 그 만큼 자율성을 보장해줄 수 있다.

 

스포티파이 모델은 실패였다?

해당 백서의 공동 저자와 Spotify의 Agile 코치들은, 예전부터 외부 사람들에게 이거 따라 하지 말라고 얘기한 적이 있다고 한다. 애초에 Spotify에서 이 백서를 작성했던 시점에도 그들은 이 모델을 적용하지 않고 있었다는 것.

1. 각 팀의 엔지니어를 담당하는 단일 관리자가 없음. mini-CEO 역할을 했던 프로덕트 매니저에게 mini-CTO 같은 역할을 해줄 사람이 없음. 즉, 기술팀의 지원에 대해 책임지거나, 우선순위를 협상할 사람이 없었음. 기술팀 내부에서 의견 불일치가 일어나면 프로덕트 매니저가 모든 엔지니어와 협상 해야 함. 거기서 안되면 적어도 3명 이상인 백엔드/웹/모바일 엔지니어링 매니저들하고 협상하거나, 부서의 엔지니어링 책임자에게 에스컬레이션(보통 상사에게 의사결정을 요청하는 일을 뜻함)하는 일이 일어남.
2. 회사가 작을 때는 각 팀이 다양한 범위의 일을 하고, 종종 주도권을 가진 팀이 바뀌기도 함. 회사가 커지면 각 팀의 중복된 기능들은 효율화를 위해서 새로운 팀으로 합쳐서 만들어짐. 팀이 많아지면 주도권이 변경될 일이 줄어들고, 자신들이 해결해야 할 문제에 대해 장기적으로 생각이 가능해짐. 하지만 각 팀이 자신들만의 방법으로 참여하니까 전체 조직의 생산성이 떨어짐.
3. 각 팀(스쿼드 등)에게 Agile을 가르쳐주고, 프로세스를 코치해줄 만한 여력이 떨어지게 됨. 조직이 성장할 수록 점점 팀들은 세분화되고 많아질 것이기 때문. 심화되면 2번의 문제가 발생.

 

그래서?

이러한 matrix 조직의 운영의 어려움에 대해서 알아둘 필요가 있다고 생각한다.

내가 HR과 관련된 직무거나, 피플팀(인사팀)에 속해서 일을 하고 있지는 않지만 협업하는 부서가 많은 만큼 자연스럽게 스쿼드 처럼 업무를 수행하는 그룹들이 형성되기 마련이다. PM의 경우에는 하나의 제품 그룹 외에도 다른 그룹과 섞여야 할 때가 많을 터이니 알아두면 좋은 개념이긴 할 것이다. 하나씩 잘 읽어보고 단 것은 먹고 쓴 것은 뱉자.

 

참고

https://www.atlassian.com/ko/agile/agile-at-scale/spotify

애자일 확장을 위한 Spotify 모델 | Atlassian

https://news.hada.io/topic?id=2191

Spotify의 Squad 팀 모델은 실패였다 | GeekNews

https://jh4hj.tistory.com/m/1015

프로덕트 매니저는 무슨 일을 하고 있을까

https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf