직능 조직

여덟 명이 한 방에서 일할 때는 조직 형태를 정할 일이 없습니다. 누가 무엇을 맡고 있는지 모두가 알고, 결정이 필요하면 의자를 돌려 물으면 됩니다. 사람이 스무 명을 넘기면 그 방식이 먼저 무너집니다.

가장 빨리 드러나는 것은 기준이 흩어지는 일입니다. 디자이너 셋이 각자 다른 일에 붙어 있으면 같은 제품 안에서 버튼 모양이 세 가지가 되고, 새로 들어온 디자이너에게 이 회사가 어떻게 그려 왔는지 알려 줄 사람이 옆자리에 없습니다. 개발도 같습니다. 코드를 어떤 방식으로 짜기로 했는지 물어볼 데가 없으면 사람마다 다르게 짜고, 반년이 지나면 서로의 코드를 읽는 데 하루씩 걸립니다.

이 상황은 회의에서 이런 모양으로 나타납니다. 누군가 "우리 디자인 기준은 누가 정하나요" 라고 물으면 잠깐 말이 끊기고, "지금까지는 그때그때 각자 정했죠" 라는 답이 돌아옵니다. 정할 사람이 없어서가 아니라 정하는 자리가 없어서 생기는 침묵입니다.

직능 조직은 그 자리를 만드는 가장 단순한 답입니다. 같은 일을 하는 사람을 한 팀에 모아 두면 기준을 정할 사람과 그 기준대로 일할 사람이 같은 곳에 있게 됩니다. 회사를 자르는 방법 가운데 가장 먼저 쓰인 형태이고, 뒤에 나온 형태들은 이 방식이 커진 회사에서 만들어 낸 불편을 풀려고 나왔습니다.

회사를 하는 일의 종류로 자릅니다. 개발자는 개발 조직에, 디자이너는 디자인 조직에, 마케터는 마케팅 조직에 속하고, 각 조직의 장은 그 직군을 오래 한 사람이 맡습니다.

이렇게 자르면 네 가지가 따라 정해집니다.

1. 소속 — 사람은 자기 직군의 조직에 들어갑니다. 45명 회사라면 개발 18명, 디자인 6명, 기획 5명, 마케팅 6명, 세일즈 7명, 경영지원 3명처럼 나뉩니다.
2. 보고 라인 — 누가 누구에게 보고하는지의 관계입니다. 평가와 연봉과 휴가 승인이 이 선을 따라 움직입니다. 디자이너가 어떤 제품 일을 했든 그의 평가는 디자인 조직의 장이 쓰고, 이 선이 하나뿐이라 누가 무엇을 정하는지를 따로 적어 둘 일이 없습니다.
3. 일을 받는 방법 — 제품 하나를 내보내려면 조직 세 곳에서 차례로 사람을 얻어 옵니다. 기획이 안을 만들어 디자인 조직에 일정을 요청하고, 그 결과를 들고 개발 조직에 다시 일정을 요청하는 순서입니다.
4. 드러나는 모습 — 조직도를 그리면 대표 아래에 직군 이름을 단 상자가 나란히 서고 그 아래로 사람이 붙습니다. 위아래로는 말이 잘 통하고 옆으로는 잘 통하지 않는 모양입니다.

비용은 3번에서 나옵니다. 페이지덱이 스무 명이던 시절이 이 모양이었고, 기능 하나를 내보내는 데 회의가 평균 네 번 필요했습니다. 조직 셋의 일정이 모두 비는 날을 찾다 보면 시작이 2주씩 밀렸습니다.

사람이 많지 않고 만드는 제품이 하나일 때 가장 잘 맞습니다. 옆으로 오가는 비용은 회사가 작을수록 작아지고, 기준을 세우는 이득은 회사가 작을 때도 그대로 남기 때문입니다.

실제로는 세 자리에서 자주 보입니다.

1. 50명 아래의 회사 — 제품이 하나라 어느 조직도 여러 제품에 나뉘어 붙을 일이 없습니다. 이 규모에서는 조직 셋의 일정을 맞추는 일도 회의 한 번으로 끝납니다.
2. 품질 기준이 결과를 좌우하는 직군 — 재무, 법무, 인사처럼 규칙을 틀리면 회사 전체가 위험해지는 일은 회사가 몇백 명이 되어도 직능 조직으로 남습니다. 제품별로 쪼개서 경리를 셋 두는 회사는 없습니다.
3. 새 직군을 회사 안에 들일 때 — 데이터 분석가를 처음 두 명 뽑았다면 서로 다른 제품에 흩어 놓기보다 한 조직에 두고 도구와 기준을 먼저 맞추는 편이 빠릅니다.

조직마다 사람을 몇 명까지 둘지는 헤드카운트로 내려옵니다. 조직이 둘 수 있는 자리의 예산인데, 직능 조직에서는 이 숫자가 직군 단위로 배분되기 때문에 개발 세 자리와 디자인 한 자리처럼 직군끼리 나눠 갖는 다툼이 생깁니다.

"저희가 아직 직능 조직이라 그 일정은 개발팀장한테 따로 확인해야 해요."

한 사람에게 물어서는 답이 나오지 않고 조직마다 일정을 받아 와야 한다는 뜻입니다.

"디자인 품질만 보면 직능 조직일 때가 나았죠."

기준을 한곳에서 정하던 때의 결과물이 더 고르다는 말입니다.

"이번 개편에서 직능 조직을 유지할지 제품별로 자를지부터 정해야 합니다."

세부 논의로 넘어가기 전에 회사를 자르는 기준을 먼저 정하자는 제안입니다.

페이지덱에서 이 말이 가장 많이 오간 자리는 45명이 되던 무렵의 개편 회의였습니다. 지현이 지난 분기에 기능 세 개가 모두 2주씩 밀린 기록을 가져왔고, 밀린 이유가 전부 조직 사이에서 일정을 기다린 시간이었습니다. 태오는 반대편 근거를 댔습니다. 개발 조직을 쪼개면 코드 기준을 볼 사람이 사라지고 신입 개발자가 물어볼 자리가 없어진다는 이야기였습니다.

규원은 둘 중 하나를 고르는 대신 나누는 지점을 정했습니다. 제품에 붙는 직군은 제품별로 옮기고 재무와 법무는 그대로 두기로 한 겁니다. 회사 전체가 한 형태를 쓰는 경우는 드물고, 어디까지 직능으로 남길지를 정하는 일이 실제 결정입니다.

직능 조직을 낡은 형태로 읽는 경우가 가장 많습니다. 빠른 팀을 이야기할 때 늘 제품별로 자른 사례가 나오니 그렇게 보이기 쉽습니다. 하지만 이 형태가 지는 것은 속도 한 가지이고 이기는 것은 기준과 육성 두 가지입니다. 스무 명짜리 회사가 제품별로 팀을 셋 나누면 디자이너가 팀마다 한 명씩 앉게 되는데, 그 한 명은 물어볼 사람 없이 혼자 판단하고 혼자 틀립니다. 형태를 고르는 일은 좋고 나쁨이 아니라 지금 회사가 어느 쪽 비용을 감당할 수 있는지를 고르는 일입니다.

직능 조직이면 직군끼리 협업이 안 된다고 읽는 것도 흔한 오해입니다. 조직도가 직군으로 갈려 있으니 일도 갈려 있으리라 짐작하는 겁니다. 실제로는 일이 생길 때마다 각 조직에서 사람을 모아 교차 기능 팀을 꾸립니다. 출시까지 필요한 직군을 한 팀에 모은 구성인데, 소속은 그대로 둔 채 이 일에 시간을 얼마나 쓸지만 정합니다. 다만 이 팀은 일이 끝나면 흩어지고 그 사이에 쌓인 맥락도 같이 흩어집니다. 협업이 안 되는 것이 아니라 매번 처음부터 다시 시작하는 쪽에 가깝습니다.