HenrikKniberg와 AndersIvarsson이 쓴, 스포티파이에서 Squad와 Chapter, Tribe, Guild 조직을 운영하는 내용에 대한 문서.

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

아래는 발췌 번역 내용.

AlistairCockburn이 Spotify에 방문해서, "훌륭하네요 - 1992년부터 이러한 매트릭스 형태를 누군가 구현해주기를 고대하고 있었어요 그걸 이렇게 보게 되다니 반갑네요."라고 말했다.

알림: 우리는 이 모델을 발명하지 않았다. Spotify는 (다른 훌륭한 기민한 회사처럼) 빠르게 진화하고 있다. 이 문서는 단지 현재 우리가 일하고 있는 - 아직 여정 중인, 완료되지 않은 - 방식의 스냅샷일 뿐이다. 아마 당신이 이걸 읽는 동안, 많은 것들이 이미 바뀌었을 것이다.

잠깐만요, 이거 그냥 매트릭스 조직 아닌가요?

그렇다. 음, 어느 정도는. 하지만 우리 대부분이 사용하곤 했던 것과는 뭔가 다른 종류의 매트릭스이다.

많은 매트릭스 조직에서 비슷한 스킬을 가진 사람들은 기능적인 부서들로 "자원화(pooled)"되어 묶이고, 프로젝트에 "할당(assigned)"되고, 기능 관리자에게 "보고"한다.

Spotify는 이 중 어느 것도 하지 않는다. 우리 매트릭스는 배달(delivery)에 무게를 두고 있다.

이것은, 사람들이 안정되고 함께 앉는(co-located) 스쿼드로 묶이고, 다른 스킬 셋을 가진 사람들이 협력하고 훌륭한 제품을 배달하기 위해 자기조직화한다. 이것은 매트릭스의 vertical한 차원이다. 그리고 그것이 기본적인(primary) 것으로서, 사람들이 물리적으로 묶이고(grouped), 그들이 대부분의 시간을 보내는 곳이다.

수평적인(horizontal) 차원은, 지식, 도구, 코드를 공유하기 위한 것이다. 쳅터 리드의 업무는 그것을 촉진하고 지원하는 것이다.

매트릭스 관점에서, 수직적(vertical) 차원을 "무엇(what)"으로, 수평적(horizontal) 차원을 "어떻게(how)"로 생각하라. 이 매트릭스 구조는 각 스쿼드 구성원이 "다음에 무엇을 만들지"와 "그것을 어떻게 잘 만들지"에 대한 가이드를 얻을 수 있다는 것을 보장한다.

이것은 MaryPoppendieck과 TomPoppendieck이 제안한 "교수와 창업가(professor and entrepreneur)" 모델과도 들어맞는다. PO는 "창업가"나 "프로덕트 챔피언"으로, 훌륭한 제품을 배달하는 것에 초점을 맞춘다. 반면에 쳅터 리드는 "교수"나 "역량 리더"로서, 기술적 탁월성에 초점을 맞춘다.

이 두 역할 사이에는 건강한 긴장이 있다. 창업가는 속도를 높이고 지름길로 가기를 원하는 반면, 교수는 속도를 늦추고 제대로 만들기를 원한다. 두 관점 모두 필요하다. 이것이 "건강한" 긴장인 이유이다.

아키텍처는?

Spotify 기술은 고도로 서비스-지향적이다. 우리는 100개가 넘는 시스템을 가지고 있고, 각각은 분리되어 유지되고 배포된다. 재생목록 관리나 검색, 지불 같은 백엔드 서비스들, 그리고 iPad 플레이어 같은 클라이언트들, 라디오 같은 특정한 컴포넌트들, 음악 재생기의 "새 소식" 섹션들을 포함한다.

이론적으로는, 누구나 어느 시스템도 수정할 수 있다. Squad가 효과적인 기능 팀(feature teams)이기 때문에, 그들은 새로운 기능을 프로덕션으로 배포하기 위해 여러 시스템들을 업데이트해야 한다.

이 모델의 위험은, 아무도 전체로서의 시스템 일관성(integrity)에 초점을 맞추지 않는다면 시스템의 아키텍처가 엉망이 될 수 있다는 것이다.

이 위험을 극복하기 위해, 우리는 "System Owner"라고 부르는 역할을 둔다. 모든 시스템들은 시스템 오너가 있다. 또는 여러 명의 시스템 오너들을 가진다 (우리는 pairing을 권장한다). 크리티컬한 시스템의 경우, 시스템 오너는 Dev-Ops 쌍이다 - 다시 마해서, 한 명은 개발자의 관점을, 한 명은 운영 관점을 가진다.

시스템 오너는 그 시스템에 관련된 어떠한 기술적인, 또는 아키텍처적인 이슈가 발생하면 찾아가서 물어볼 수 있는 사람이다. (사람들이 시스템 오너에게 물어보러 간다.) 그는 코디네이터이고 그 시스템에 코드를 작성하는 사람들이 다른 사람들과 엉키지 않도록 가이드한다. 그는 품질, 문서화, 기술 부채, 안정성, 확장가능성, 릴리즈 프로세스 등에 초점을 맞춘다.

시스템 오너는 병목도 아니고 상아탐 아키텍트도 아니다. 그는 모든 결정을 혼자 내릴 필요가 없고, 모든 코드를 작성할 필요가 없고, 모든 릴리즈를 할 필요가 없다. 그는 대개는 스쿼드 멤버이거나 쳅터 리드로서, 시스템 오너쉽 이외에도 다른 일상적인 책임들을 가지고 있다. 그러나, 때로 그는 "시스템 오너 데이"를 가지곤 하며, 시스템에 대한 하우스키핑 업무를 한다. 보통은 우리는 그 사람의 시간의 10% 미만을 시스템 오너십에 들이도록 하지만, 당연히 시스템마다 조금씩 다르다.

또한 우리는 chief architect 역할을 가지고 있다. 그 사람은 여러 시스템들에 걸친 고수준의 아키텍처 이슈에 대해 코디네이트한다. 그는 새로운 시스템 개발을 검토하여 일반적인 실수가 없는지, 우리의 아키텍처 비전에 잘 맞춰져 있는지 확인한다. 피드백은 항상 단지 제안이며, 인력 - 최종 시스템 설계에 대한 결정권은 그것을 만드는 스쿼드 안에 있다.

이 모든 것이 어떻게 동작하나?

Spotify는 매우 빠르게 성장해서 - 3년간 기술자가 30명에서 250명으로 증가했다 - 성장통이 있었다. 이 확장 모델 - 스쿼드, 부족, 쳅터, 길드 - 은 지난 몇 년간 점진적으로 도입된 것이고, 사람들이 여전히 사용하고 있다. 하지만, 설문들과 회고들에 의하면, 이 확장 모델은 꽤 잘 동작하는 것 같다.