자기 조직화 팀

Self-organizing Team

개념

목표는 밖에서 받지만 그 목표에 어떻게 도달할지는 팀이 스스로 정해서 진행하는 구조입니다.

등장 배경

계획하는 사람과 일하는 사람이 나뉘어 있는 구조가 오래 기본이었습니다. 관리자가 할 일을 쪼개 목록으로 만들고, 누가 무엇을 언제까지 할지 정해 내려보냅니다. 받은 사람은 적힌 대로 합니다.

이 구조에는 한 가지 어긋남이 있습니다. 일을 가장 잘 아는 사람이 결정하지 않습니다. 그 화면 코드를 실제로 만져 본 사람만 이 작업이 3일이 아니라 2주라는 것을 알고, 두 작업의 순서를 바꿔야 한다는 것도 그 사람이 압니다. 그런데 결정은 만져 본 적 없는 쪽에서 내려옵니다.

페이지덱 초기에 이 장면이 있었습니다. 작업 목록이 내려왔고 태오가 "초대 기능을 먼저 만들면 권한 구조를 두 번 고쳐야 한다" 고 말했습니다. 맞는 말이었지만 그 순서로 짠 일정이 이미 고객에게 전달돼 있었습니다. 결국 두 번 고쳤습니다.

그래서 결정을 아는 쪽으로 옮기기로 합니다. 무엇을 왜 만드는지는 여전히 밖에서 정하되, 어떻게 만들지는 만드는 사람들이 정하게 하는 것입니다. 자기 조직화 팀은 그 경계를 정해 둔 구조를 가리킵니다.

작동 방식

핵심은 자율의 범위를 분명히 나누는 것입니다. 팀이 정하는 것과 정하지 않는 것이 섞이면 이 구조는 곧 무너집니다.

팀이 정하는 것은 넷입니다.

  1. 누가 무엇을 맡을지 — 배분을 받지 않고 서로 정합니다.
  2. 어떤 순서로 할지 — 기술적 의존 관계를 아는 쪽이 순서를 짭니다.
  3. 어떤 방법으로 할지 — 기술 선택, 설계, 어디까지 자동화할지가 여기 들어갑니다.
  4. 이번 주기에 얼마나 담을지 — 밖에서 양을 정해 주지 않습니다.

팀이 정하지 않는 것도 넷입니다.

  1. 무엇을 왜 만드는지 — 제품 목표는 밖에서 옵니다. 프로덕트 오너가 우선순위를 정하는 역할이고, 팀은 그 판단을 대신하지 않습니다.
  2. 언제까지 필요한지 — 시장이나 계약이 정하는 시점은 제약으로 받습니다.
  3. 품질 기준 — 어디까지 됐을 때 끝인지는 조직 차원의 합의입니다.
  4. 팀의 구성 — 누구를 넣고 뺄지는 팀 밖의 결정입니다.

이 경계가 서려면 넷이 갖춰져야 합니다. 목표가 작업 목록이 아니라 결과로 주어져야 하고, 출시까지 필요한 직군이 팀 안에 있어야 합니다. 그 구성을 교차 기능 팀이라고 부르는데, 디자인이나 배포를 다른 팀에 요청해야 하면 순서를 스스로 정하는 일이 성립하지 않습니다. 결정 권한이 실제로 있어야 하고, 결과에 대한 책임도 집니다.

굴러가는 모습은 세 자리에서 드러납니다. 스프린트 플래닝에서 담을 양을 스스로 정하고, 하루 단위로 진행을 맞추며 막힌 것을 옮기고, 회고에서 절차를 고칩니다. 회고는 일하는 방식을 돌아보고 고칠 점을 정하는 자리입니다. 절차를 고칠 권한이 없으면 앞의 둘은 형식만 남습니다.

쓰이는 곳

맞는 조건은 셋입니다. 문제가 복잡해서 미리 다 쪼갤 수 없을 때, 기술 판단이 결과를 크게 좌우할 때, 구성원이 그 판단을 할 만큼 경험이 있을 때입니다. 소프트웨어 개발이 이 셋을 대체로 만족하기 때문에 애자일 계열이 이 구조를 기본으로 둡니다.

안 맞는 자리도 있습니다.

  1. 절차가 외부에서 정해진 일 — 규제나 인증 절차처럼 순서를 바꿀 수 없는 작업에서는 자율의 여지가 거의 없습니다.
  2. 경험이 얕은 구성 — 전원이 신입인 팀은 대개 가장 쉬운 것부터 하게 되고 위험한 것이 뒤로 밀립니다.
  3. 긴급 상황 — 장애가 터진 자리에서는 지휘를 한 사람이 잡아야 합니다. 합의로 결정하는 동안 시간이 갑니다.

관리자의 역할은 사라지지 않고 바뀝니다. 작업을 배분하는 일에서, 목표를 설명하고 팀 밖의 장애물을 걷어 내는 일로 옮겨 갑니다. 스크럼에서 스크럼 마스터를 따로 두는 것도 그 역할을 명시하려는 것입니다.

자주 나오는 실패는 둘입니다. 아무도 결정하지 않는 경우와, 목표는 안 주고 자율만 준 경우입니다. 뒤쪽이 더 흔합니다. 무엇을 위한 일인지 모르는 팀은 각자 자기 기준으로 정하고, 몇 주 뒤에 방향이 갈라져 있습니다.

실무 용례

"작업 배분은 저희가 정할게요. 목표랑 기한만 주시면 됩니다."

결정 경계를 분명히 하자는 요청입니다.

"이건 팀이 정할 게 아니라 우선순위 문제예요. 오너가 정해 주셔야 합니다."

무엇을 만들지는 팀의 자율 범위 밖이라는 지적입니다.

"자율이라더니 결정할 때마다 승인받고 있어요."

권한이 말로만 있고 실제로는 없다는 뜻입니다.

페이지덱은 이 구조를 한 번 잘못 시작했습니다. 규원이 "팀이 알아서 하세요" 라고 말한 뒤 작업 목록을 내려보내지 않았는데, 목표도 함께 사라졌습니다. 3주가 지나 각자 고친 것을 모아 보니 같은 화면을 두 사람이 다르게 고쳐 놓은 상태였습니다.

그래서 순서를 바꿨습니다. 지현이 이번 주기에 달성할 것을 결과 문장 두 개로 적어 오고, 어떻게 나눠 할지는 회의에서 팀이 정합니다. 담을 양도 팀이 정하되 최근 실적과 크게 다르면 지현이 이유를 묻습니다. 자율이 늘어난 것이 아니라 경계가 그려진 것입니다.

흔한 오해

관리자가 필요 없어진다고 읽는 경우가 가장 많습니다. 팀이 스스로 정한다니 위에서 정하는 사람이 없어도 된다는 말처럼 들립니다. 하지만 사라지는 것은 작업을 쪼개 배분하는 일뿐이고, 목표를 정하고 맥락을 전달하고 팀 밖의 장애물을 치우는 일은 그대로 남습니다. 오히려 후자가 늘어납니다. 팀이 스스로 정하려면 무엇을 위한 일인지 훨씬 자세히 알아야 하고, 설명하는 것은 밖의 몫입니다. 배분을 그만둔 관리자가 설명도 그만두면 팀은 방향 없이 돕니다.

무엇을 만들지도 팀이 정한다고 보는 것도 흔합니다. 자율이라는 말에 범위가 안 붙어 있으니 그렇게 읽힙니다. 하지만 이 구조에서 팀이 정하는 것은 방법이고 목표는 밖에서 옵니다. 우선순위를 팀이 정하기 시작하면 고객 요청과 내부 판단이 부딪힐 때 누가 결정하는지가 사라지고, 결국 목소리가 큰 쪽으로 기울게 됩니다. 만들 것을 정하는 역할과 만드는 방법을 정하는 역할을 나눠 두는 것이 이 구조의 전제입니다.

같이 보면 좋은 페이지

  • 애자일

    이 구조가 어느 접근의 원리인지 먼저 봅니다

  • 반복적 개발

    같은 접근의 다른 원리를 함께 확인합니다

마지막 업데이트 2026-09-16