스포티파이 모델

팀이 늘어날 때 조직을 다루는 익숙한 방법은 위에 관리 층을 하나 더 올리는 것이었습니다. 팀장 위에 실장을 두고 실장 위에 본부장을 두면 보고선이 정리됩니다. 대신 결정이 위로 올라가 내려오는 데 시간이 걸리고, 팀은 자기 일을 스스로 정하지 못하게 됩니다.

반대로 각 팀에 자율만 주면 다른 문제가 생깁니다. 두 팀이 알림 기능을 각각 다른 방식으로 만들어 두고, 한쪽은 테스트를 꼼꼼히 쓰는데 다른 쪽은 아예 쓰지 않습니다. 팀 안에서는 합리적인 선택이었지만 회사 전체로 보면 같은 일을 두 번 하고 기술 수준이 갈립니다. 사람이 옮겨 다닐 때마다 처음부터 다시 익혀야 하는 상태가 됩니다.

스포티파이 모델은 그 둘을 두 축으로 나눠 함께 두려는 시도입니다. 무엇을 만들지는 목표를 맡은 팀이 정하고, 어떻게 만들지의 기준은 같은 직군끼리 모여 정합니다. 2012년에 한 회사가 자기들의 방식을 공개한 문서에서 시작해 이름이 붙었습니다.

목표 단위로 팀을 자르고, 그 위에 직군별 모임을 얹는 순서로 짭니다.

1. 목표 하나에 팀 하나를 붙입니다. 한 목표를 맡은 소규모 자율 팀을 스쿼드라고 하고, 6명에서 12명 사이로 잡습니다. 이 팀 안에 기획과 디자인과 개발이 함께 있어 다른 팀을 기다리지 않고 내보낼 수 있어야 합니다.
2. 관련된 스쿼드를 묶습니다. 결제와 구독처럼 가까운 목표를 맡은 팀들을 트라이브로 묶고, 한 트라이브를 100명 안쪽으로 유지합니다. 그 위로 커지면 서로 누가 무엇을 하는지 모르게 되므로 트라이브를 쪼갭니다.
3. 직군별 모임을 만듭니다. 같은 직군끼리 전문성을 나누는 모임이 챕터입니다. 스쿼드가 가로라면 챕터는 세로입니다. 개발자들이 어떤 방식으로 테스트를 쓸지, 디자이너들이 어떤 부품을 공유할지가 여기서 정해집니다. 사람 관리와 성장도 대개 챕터 리더가 맡습니다.
4. 관심사 모임은 자발적으로 둡니다. 직군과 무관하게 같은 주제에 관심 있는 사람이 모이는 길드는 참여를 의무로 두지 않습니다. 의무로 만들면 회의만 늘고 내용이 비어 갑니다.
5. 자율의 범위를 문서로 적습니다. 무엇을 이루기로 했는지는 위에서 맞추고 그것을 어떻게 만들지는 팀이 정한다는 경계를 적어 둡니다. 이 문장이 없으면 자율이 각자 알아서로 읽히고, 3번에서 만든 기준이 지켜지지 않습니다.

두 축을 함께 두면 한 사람에게 보고선이 둘 생깁니다. 직능과 과제 두 축으로 보고선을 둔 매트릭스 조직의 성격이 이 모델에 들어 있어서, 스쿼드의 목표와 챕터의 기준이 부딪힐 때 누가 정하는지를 미리 적어 둬야 합니다.

맞는 자리는 제품의 갈래가 여럿이고 각 갈래가 따로 내보낼 수 있을 때입니다. 결제와 검색과 알림이 서로 크게 얽혀 있지 않다면 팀마다 자기 주기로 배포할 수 있고, 그때 이 구성의 값이 큽니다. 인원으로는 마흔 명 넘어가는 규모에서 이야기가 나옵니다. 그 아래에서는 트라이브도 챕터도 만들 이유가 없습니다.

맞지 않는 자리도 분명합니다. 첫째, 팀이 셋 이하면 이 구성은 이름만 늘립니다. 팀 대표끼리 모이는 회의 하나로 충분합니다. 둘째, 한 제품 안에서 팀끼리 의존이 강하면 자율이 서지 않습니다. 셋째, 규제나 안전이 걸린 분야에서는 문서화된 절차와 승인선이 먼저라 자율의 범위가 애초에 좁습니다.

한계는 이 모델의 출처에서 나옵니다. 공개된 문서는 한 회사의 2012년 한 시점을 찍은 사진이고, 그 회사도 그 뒤로 구성을 여러 번 바꿨습니다. 그래서 이 모델을 규정집처럼 옮기면 그 회사의 당시 사정까지 함께 들여오게 됩니다. 남의 조직도를 복사하는 대신 두 축으로 나눈다는 생각만 가져오는 편이 안전합니다.

실무에서 가장 자주 나는 사고는 이름만 바꾸는 것입니다. 기존 팀을 스쿼드로 고쳐 부르고 부서를 트라이브로 고쳐 부르면 조직도는 새것처럼 보이는데, 결정 권한이 그대로 위에 있으면 달라지는 것이 없습니다. 바뀌어야 하는 것은 호칭이 아니라 무엇을 누가 정하느냐입니다.

"팀 이름만 스쿼드로 바꾸면 달라지는 게 없어요."

권한이 옮겨 가지 않았다는 지적입니다.

"그건 챕터에서 정할 문제입니다."

만드는 방식의 기준은 직군 모임이 맡는다는 뜻입니다.

"우리는 팀이 셋인데 트라이브를 만들 이유가 없어요."

규모에 맞지 않는 층이라는 판단입니다.

페이지덱은 이 모델을 그대로 쓰지 않습니다. 구성원이 45명이라 트라이브를 만들 규모가 아니고, 제품이 하나라 갈래를 자를 자리도 적습니다. 대신 두 가지만 가져왔습니다.

하나는 목표 단위로 팀을 자르는 것입니다. 문서 편집과 공유·권한과 검색 세 갈래에 각각 기획과 디자인과 개발을 붙였습니다. 다른 하나는 직군 모임입니다. 지현과 민서와 태오가 각자 자기 직군의 기준을 맞추는 자리를 격주로 두었습니다. 알림 구현이 팀마다 갈리는 문제가 그 자리에서 정리됐습니다. 이름은 스쿼드도 챕터도 쓰지 않았습니다.

자율을 각자 알아서로 읽는 경우가 가장 많습니다. 자율 팀이라는 말이 앞에 붙어 있으니 자연스러운 오해입니다. 하지만 이 모델이 말하는 자율은 무엇을 이룰지는 맞춰 놓고 그것을 어떻게 만들지만 팀이 정하는 것입니다. 이 경계를 적어 두지 않으면 목표부터 팀마다 갈리고, 반년 뒤에 세 팀이 서로 다른 방향으로 걸어가 있는 상태가 됩니다. 이 모델을 소개한 문서에서도 정렬과 자율을 함께 놓고 설명합니다.

지금도 그 회사가 이렇게 일한다고 보는 것도 흔합니다. 이름에 회사가 들어 있으니 현재형으로 읽힙니다. 그런데 공개된 것은 한 시점의 기록이고, 그 회사의 사람들도 이후에 이것이 규정집처럼 쓰이는 것을 경계했습니다. 어느 조직도 남의 구성을 그대로 옮겨 쓸 수 없다는 것이 이 모델에서 가져갈 마지막 교훈에 가깝습니다.