스포티파이가 개발 조직을 키우면서 쓴 방식을 헨리크 크니베리(Henrik Kniberg)와 안데르스 이바르손(Anders Ivarsson)이 2012년 글 "Scaling Agile @ Spotify"로 소개하면서 널리 알려졌다. 글 첫머리부터 "현재 일하는 방식의 스냅숏일 뿐, 끝난 여정이 아니라 진행 중인 여정"이라고 못 박았다.
네 가지 단위
- 스쿼드(Squad): 기본 개발 단위. 스크럼 팀과 비슷하고 작은 스타트업처럼 느껴지도록 설계했다. 한 공간에 앉아 설계부터 출시까지 필요한 기술을 모두 갖추고, 스크럼이든 칸반이든 일하는 방식을 스스로 정한다. 공식 리더 대신 우선순위를 정하는 프로덕트 오너(Product Owner)가 있고, 일하는 방식은 팀이 정한다. 애자일 코치의 도움을 받는다
- 트라이브(Tribe): 음악 플레이어, 백엔드 인프라처럼 관련된 영역의 스쿼드 묶음. 스쿼드라는 작은 스타트업의 인큐베이터 역할이다. 한 사람이 사회적 관계를 유지할 수 있는 인원에 한계가 있다는 던바의 수(Dunbar's Number)를 근거로 100명 남짓을 넘지 않게 잡았다
- 챕터(Chapter): 같은 트라이브 안에서 비슷한 기술을 가진 사람들(테스트, 웹, 백엔드 등)의 모임. 챕터 리드가 채용·성장·연봉 같은 라인 매니저 역할을 하면서 자신도 스쿼드에서 실무를 한다
- 길드(Guild): 트라이브를 넘어 조직 전체에 걸친 관심사 커뮤니티. 관심 있는 사람은 아무나 들어갈 수 있다. 웹 기술 길드, 애자일 코치 길드 같은 것이다
자율성과 규모의 이점
스쿼드가 완전히 자율적이고 서로 소통하지 않으면 회사를 서른 개로 쪼개도 마찬가지다. 그래서 챕터와 길드를 조직을 붙잡는 접착제로 두어, 자율성을 크게 희생하지 않으면서 지식·도구 공유 같은 규모의 이점을 얻으려 했다. 일하는 방식으로 보면 사람을 기능 부서가 아니라 스쿼드에 먼저 배치하고, 기능별 연결을 두 번째 축으로 두는 매트릭스 조직이다. 이후 크니베리가 소개한 스포티파이 엔지니어링 문화 영상은 이것을 "정렬(Alignment)이 높을수록 자율이 가능하다"는 축으로 다시 설명한다.
팀 경계를 미션과 제품 영역에 맞춰 나누는 점은 시스템이 조직의 소통 구조를 닮는다는 콘웨이의 법칙를 의식한 설계로 읽을 수 있다.
한계: 그대로 베끼지 말 것
- 2017년 스포티파이에서 일한 제러마이아 리(Jeremiah Lee)는 2020년 글에서, 당시 애자일 코치였던 요아킴 순덴(Joakim Sundén)의 말을 빌려 "글을 쓸 때도 우리는 그렇게 하고 있지 않았다. 일부는 포부, 일부는 근사치였다"고 전한다. 공저자 이바르손도 이것을 복사할 프레임워크로 보지 말라고 했다
- 리가 꼽은 문제: 챕터 리드는 사람을 관리하지만 팀의 결과에는 책임이 약해 갈등이 생기면 여러 리드에게 올려야 했다. 공통의 협업 방식 없이 자율만 강조해 의존성이 늘수록 비효율이 커졌다. 새 용어가 평범한 매트릭스 구조와 그 실패를 가렸다
이름(스쿼드, 트라이브)을 들여오는 것으로는 아무것도 바뀌지 않는다. 우리 조직의 소통 구조와 의존성부터 보고, 자율과 정렬을 어떻게 맞출지 정한다. 다른 조직의 성공 사례를 맥락 없이 따라 하는 위험은 굿하트의 법칙처럼 형식이 목적을 대신할 때와 닮았다.
출처: Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds Henrik Kniberg & Anders Ivarsson(2012) · Spotify engineering culture (part 1) Henrik Kniberg(2014, 영상) · Spotify's Failed #SquadGoals Jeremiah Lee(2020)