제품 중심 조직

회사를 가르는 기본 방식은 오랫동안 직군이었습니다. 개발은 개발끼리, 디자인은 디자인끼리 묶는 직능 조직입니다. 같은 일을 하는 사람이 한자리에 있으니 기준을 맞추기 쉽고 새로 온 사람을 가르치기도 쉽습니다.

문제는 내보내는 단위가 직군과 어긋난다는 데 있습니다. 사용자가 받는 것은 개발 작업물이 아니라 기능 하나이고, 거기에는 기획과 디자인과 개발이 다 들어갑니다. 팀이 직군으로 잘려 있으면 그 하나를 내려고 세 팀의 일정을 각각 얻어 와야 합니다.

그래서 이런 장면이 생깁니다. 기획자가 디자인팀에 요청을 넣으면 그 팀의 대기 목록 뒤에 붙고 3주 뒤에 화면이 나옵니다. 그때 개발팀은 이미 다른 일정에 들어가 있어 두 주를 더 기다립니다. 아무도 늦지 않았는데 2주짜리 기능이 8주가 됩니다. 페이지덱이 스무 명이던 시절 기능 하나를 내는 데 부서 간 회의가 평균 네 번 필요했습니다.

제품 중심 조직은 이 어긋남을 팀 경계로 해결합니다. 일의 종류가 아니라 내보내려는 결과를 기준으로 선을 다시 긋습니다. 요청이 한 팀 안의 대화로 바뀌면 일정을 얻어 오는 단계 자체가 사라집니다.

팀 하나에 목표 하나를 주고, 그 목표를 끝까지 내는 데 필요한 직군을 그 팀 안에 다 넣습니다. 구성은 보통 기획자 한 명, 디자이너 한 명, 개발자 서넛입니다. 45명 회사라면 이런 팀 다섯에서 여섯이 생깁니다.

자르는 순서는 넷입니다.

1. 목표 단위를 정합니다. 문서 편집, 공유와 권한, 결제와 요금제처럼 사용자가 겪는 덩어리로 자릅니다. 개발팀·디자인팀 같은 직군 이름이 남아 있으면 자르기 전과 달라진 것이 없습니다.
2. 단위마다 직군을 채웁니다. 한 직군이 비면 그 팀은 여전히 밖에 요청을 넣어야 하므로, 채울 사람이 모자라면 팀 수를 줄입니다.
3. 팀마다 볼 숫자를 하나씩 붙입니다. 공유 팀이면 초대 수락률처럼 그 팀의 일로 움직이는 값입니다. 목표가 회사 전체 매출처럼 크면 무엇을 해도 움직이지 않아 팀이 자기 일을 판단할 수 없습니다.
4. 무엇을 팀이 정하고 무엇을 위에서 정하는지 적습니다. 화면 문구와 출시 시점은 팀이 정하고 요금제 구조는 회사가 정한다는 식입니다. 이 줄이 빠지면 팀은 매번 확인을 받으러 나가고, 회의 수는 자르기 전으로 돌아갑니다.

보고 라인은 팀장 쪽으로 한 줄만 둡니다. 누가 평가를 쓰고 연봉을 정하는지가 이 선으로 정해집니다. 대신 직군 기준을 볼 사람이 사라지므로 장치를 따로 답니다. 디자이너들이 격주로 모여 서로의 화면을 보는 자리나 재사용할 부품을 한곳에 모아 둔 디자인 시스템이 그것입니다.

제품이 한 사람 머리에 다 들어가지 않을 만큼 커졌을 때부터 씁니다. 기준은 제품 수가 아니라 영역 수입니다. 제품이 하나라도 편집과 공유와 결제가 각각 다른 판단을 요구하면 자를 자리가 생깁니다.

인원으로는 서른 명 안쪽에서는 이르고 마흔 명 전후에서 자연스러워집니다. 스무 명을 다섯 팀으로 자르면 팀마다 네 명이 되어 직군이 다 안 차고, 못 하는 일을 다시 밖에 요청하게 됩니다. 자르기 전과 같은 상태에 팀 이름만 늘어난 셈입니다.

SaaS 회사에서는 사실상 기본값입니다. 일하는 방식 쪽에서는 같은 모양을 스쿼드라고 부르는데, 조직도에 그려지는 정식 조직이 아니라 한 목표를 맡은 소규모 자율 팀을 가리키는 말이라는 차이가 있습니다.

안 맞는 곳도 있습니다. 고객사 프로젝트를 받아서 하는 회사는 일의 단위가 제품이 아니라 계약이라 직군별로 사람을 빼 쓰는 편이 낫습니다.

대가도 있습니다. 팀마다 판단이 갈리니 여섯 달쯤 지나면 A 팀 버튼과 B 팀 버튼의 생김새가 다릅니다. 부작용이 아니라 속도와 바꾼 값입니다. 그래서 조직 개편으로 이 형태를 도입하는 회사는 공통 기준을 지킬 장치를 같이 만듭니다.

"이건 편집 팀 안에서 끝낼 수 있어요. 디자인 요청 따로 안 넣어도 됩니다."

필요한 직군이 팀 안에 있어 밖의 일정을 기다릴 필요가 없다는 뜻입니다.

"팀을 제품별로 자르긴 했는데 결정은 아직 위에서 받아 오네요."

형태만 바뀌고 권한이 따라오지 않았다는 지적입니다.

"공유 팀 지표가 초대 수락률이라 이번 분기에 볼 게 명확해졌어요."

팀 단위마다 자기 일로 움직이는 숫자가 붙었다는 말입니다.

페이지덱은 구성원이 38명이 되던 분기에 직군 팀 셋을 제품 팀 넷으로 다시 잘랐습니다. 규원이 기준으로 삼은 것은 조직도 모양이 아니라 직전 두 분기의 출시 기록이었습니다. 출시까지 걸린 시간 중 실제 작업이 아닌 대기가 절반을 넘었고, 그 대기는 대부분 다른 팀 일정을 기다린 시간이었습니다.

넉 달 뒤 대기 시간은 3분의 1로 줄었고, 대신 민서가 화면 네 개에서 같은 기능의 버튼이 다르게 생긴 것을 찾아왔습니다. 지현과 민서는 네 팀 디자이너가 격주로 모이는 자리를 만들고 공통 부품 목록을 하나로 합쳤습니다. 태오는 그 목록을 코드 쪽에서도 쓰도록 정리했습니다.

팀을 제품별로 자르면 속도가 저절로 오른다고 보는 경우가 많습니다. 자르기 전의 병목이 부서 사이의 요청이었으니 그 선을 없애면 끝난 것처럼 보입니다. 하지만 요청이 없어졌어도 결정을 여전히 밖에서 받아 오면 기다리는 시간은 그대로 남습니다. 그대로 두면 팀 이름만 바뀐 상태로 회의 수가 자르기 전과 같아지고, 개편을 왜 했는지 아무도 답하지 못하게 됩니다.

직군 관리자가 필요 없어진다고 읽는 것도 흔합니다. 팀장이 팀 안의 모든 직군을 데리고 있으니 그렇게 보입니다. 실제로는 기준을 보는 사람이 그만큼 더 필요합니다. 개발자 셋을 데리고 있는 팀장이 개발자가 아니면 코드 품질을 판단할 근거가 없습니다. 그대로 두면 각 팀이 자기 기준으로 굳어, 여섯 달 뒤에는 팀을 옮긴 사람이 새 팀의 방식을 처음부터 배워야 합니다.