핵심 요지
회의가 많다는 사실만으로 조직이 나쁜 것은 아니다. 문제는 회의가 결정을 만들지 못하고, 공통 이해를 만들지 못하며, 집중 시간을 갉아먹을 때 생긴다. Shape Up의 경영 철학은 이 문제를 회의 축소 캠페인이 아니라 결정의 품질과 실행의 연속성을 재설계하는 일로 본다.
캘린더가 빈틈없이 채워진 조직은 대개 바빠 보인다. 하지만 “바쁨”과 “전진”은 다르다. 매일 같은 상태를 공유하고, 아직 형태가 잡히지 않은 일을 회의로 넘기고, 결정권자가 없는 자리에서 합의를 기다리면 회의는 협업의 장치가 아니라 불확실성을 재분배하는 장치가 된다.
37signals/Basecamp의 Shape Up은 이 장면을 다른 각도에서 본다. 질문은 “회의를 몇 개 없앨까?”가 아니다. 무엇을 먼저 충분히 정의할 것인가, 누가 언제 투자 결정을 할 것인가, 그리고 결정된 일을 수행하는 사람에게 얼마나 긴 방해 없는 시간을 돌려줄 것인가다.
이 글은 Shape Up의 경영 철학을 중심에 두고 Scrum, Kanban, Lean, DDD/EventStorming이 회의를 어떤 목적으로 사용하는지 비교한다. 결론은 단순하다. 회의는 필요하다. 다만 모든 회의가 필요한 것은 아니다.
Shape Up은 37signals가 공개한 제품 개발 접근법이다. 6주 사이클을 기본 단위로 두고, 다음 사이클에 투자할 일을 Betting Table에서 선택한다. 이때 핵심은 일을 잘게 쪼개 배정하는 것이 아니다. 시작 전에 문제의 윤곽, 해결의 방향, 범위의 경계와 위험을 충분히 Shape한 뒤, 팀이 그 안에서 해법을 완성하게 하는 데 있다.
회의가 잦은 조직에서는 개발자가 매번 맥락을 다시 불러와야 한다. 오전의 설계 판단은 점심 전 상태 공유로 끊기고, 오후의 구현은 긴급 우선순위 논의로 흔들린다. 이런 환경에서 속도를 떨어뜨리는 것은 회의 시간 한 시간 자체가 아니다. 회의 전후로 소실되는 집중력, 판단의 연속성, 책임의 선명함이다.
Shape Up은 이를 두 개의 다른 시간대로 나눈다.
이 분리는 “관리자는 계획하고 팀은 실행한다”는 낡은 분업이 아니다. 오히려 실행팀이 매일 승인을 받지 않아도 되도록 결정 가능한 경계와 책임을 사전에 명확히 하는 운영 설계다. 자율성은 회의를 없앤다고 생기지 않는다. 자율적으로 판단할 수 있는 문제의 모양과 권한의 경계가 있을 때 생긴다.
<aside> 🖼️
삽화 1 — 반복되는 상태회의의 컨베이어 벨트에서 벗어나, 명확한 결승선과 설계도를 앞에 둔 팀
</aside>
Shape Up이 backlog 중심 운영을 경계하는 이유도 여기에 있다. backlog는 가능성을 기록하는 데 유용하지만, 모든 항목이 언젠가 실행될 것처럼 보이게 만들기 쉽다. 반면 bet은 제한된 시간과 인력을 어디에 투자할지 선택하는 행위다. 선택에는 포기가 포함된다.
따라서 Betting Table은 보고를 받는 회의가 아니라 다음을 결정하는 자리다.