2025년 8월 06일·7분
더스틴 모스코비츠와 아사나: 회의를 시스템으로 대체하기
더스틴 모스코비츠와 아사나가 명확한 시스템—끊임없는 회의나 영웅적 노력 대신—이 팀의 협업, 의사결정, 결과물 전달을 돕는다는 관점을 어떻게 대중화했는지.
더스틴 모스코비츠와 아사나가 명확한 시스템—끊임없는 회의나 영웅적 노력 대신—이 팀의 협업, 의사결정, 결과물 전달을 돕는다는 관점을 어떻게 대중화했는지.
캘린더를 열면 빽빽합니다: 주간 상태, 동기화, 체크인, 정렬 회의, 그리고 거의 빠르게 끝나지 않는 몇몇 ‘빠른 통화’. 모두 바쁜 것 같은데도 같은 질문이 반복됩니다: 누가 무엇을 하나? 지난주 이후에 무엇이 바뀌었나? 우리가 계획대로 가고 있나, 아니면 그냥 움직이기만 하나?
업무가 보이지 않으면 회의가 기본 수단이 됩니다. 업데이트가 사람 머릿속에만 있거나, 흩어진 DM, 문서와 스프레드시트 사이에 있으면 신뢰할 수 있는 공동 이해를 만들기 위해 모두를 같은 시간에 같은 장소(또는 영상 통화)에 모으는 것이 유일한 방법처럼 느껴집니다. 그 결과는 예측 가능합니다: 지난 회의에서 무엇을 결정했는지 명확히 하기 위한 새로운 회의를 예약하게 됩니다.
대부분의 팀은 회의를 좋아해서 추가로 잡지 않습니다. 불확실성이 비용이기 때문에 잡습니다. 30분 동기화는 위험을 줄이는 가장 저렴한 방법처럼 보일 수 있지만, 프로젝트별로, 주간으로 쌓이면 비용이 커집니다.
근본 문제는 대화 사이에 업무가 “보이지 않게” 된다는 점입니다:
워크 관리 도구와 더스틴 모스코비츠의 사고와 자주 연결되는 철학의 핵심은 단순합니다: 반복되는 구두 조정을 가시적인 기록 시스템으로 대체하라. 상태를 발견하기 위해 회의하는 대신, 팀은 모두가 볼 수 있는 곳에 상태를 업데이트합니다.
Asana는 이러한 접근을 잘 보여주는 사례입니다: 작업, 담당자, 기한, 업데이트를 추적하는 공유된 장소. 도구 자체가 마법은 아니지만 요점은 분명합니다—업무가 보기 쉬워지면 방향을 유지하기 위해서만 회의가 필요하지 않습니다.
더스틴 모스코비츠는 페이스북 공동 창업자이자 초기 엔지니어링 리더로 잘 알려져 있습니다. 작은 팀이 짧은 시간에 매우 큰 조직으로 변하는 과정을 지켜본 그는, 페이스북을 떠난 뒤 저스틴 로젠스타인과 함께 Asana를 공동 창업하며 팀이 성장할 때마다 나타나는 특정 문제에 주목했습니다: 조정이 실제 작업보다 더 어려워진다는 것.
팀이 작을 때는 사람들 머릿속으로 계획을 유지하고 복도에서 설명하며 빠른 회의로 빈틈을 메꿀 수 있습니다. 인원이 늘어나면 그런 방식은 통하지 않습니다. 정보가 인박스와 채팅 스레드에 갇히고, 결정은 절반만 참석한 통화에서 내려지며, ‘누가 무얼 소유하는가’가 불명확해집니다. 결과는 예측 가능합니다: 더 많은 회의, 더 많은 후속조치, 더 많은 재작업.
모스코비츠의 핵심 아이디어(Asana 철학과 자주 연결됨)는 업무를 시스템으로 취급하라는 것입니다: 누구나 살펴볼 수 있는 가시적 약속, 책임자, 일정, 결정 규칙의 집합. 누군가가 모든 것을 기억하고 밀어붙이며 팀 간 번역을 해주는 영웅적 행동에 의존하는 대신, 시스템이 문맥을 담아줍니다.
개인의 연대기를 추적하기보다는, 여기서는 Asana의 업무 관리 접근과 많은 사람이 공감하는 원칙과 패턴을 추출하는 것이 목표입니다:
Asana를 쓰든 다른 워크플로 도구나 가벼운 프로세스를 쓰든, 근본적인 질문은 동일합니다: 팀의 업무 운영체제가 조정을 신뢰 가능하게 만들어 회의를 줄일 수 있는가?
대부분의 팀은 지속적인 회의를 선택하지 않습니다. 업무가 예측 불가능해서 조정이 실시간 구조 수습의 연속이 되기 때문에 그렇게 됩니다.
영웅주의는 프로젝트를 살리는 막판 구조 수습입니다: 중요한 세부사항을 기억하는 사람, 깨진 전달을 메우는 사람, ‘그냥 끝내자’며 늦게까지 남는 사람. 지식은 사람 머릿속에 있고, 진행은 소방 작업에 의해 좌우되며 팀은 DM, 복도 대화, 빠른 통화 같은 비공식적 알림에 의존합니다.
영웅주의는 눈에 띄는 움직임을 만들어 생산적으로 느껴집니다. 화재가 진화됩니다. 마감이 지켜집니다. 영웅은 칭찬을 받습니다. 하지만 근본 시스템은 개선되지 않아서 같은 화재가—종종 더 크게—다시 나타납니다.
팀이 커지면 영웅주의는 세금처럼 작동합니다:
결국 회의가 이미 있어야 할 공유 컨텍스트를 재구성하는 기본 방법이 됩니다.
시스템은 구조 수습을 재현 가능성으로 바꿉니다. 기억과 긴급성에 의존하는 대신, 팀은 명확한 워크플로—정의된 단계, 명시적 소유권, 그리고 작업이 존재하는 곳에 캡처된 공유 맥락—을 사용합니다. 목표는 관료주의가 아니라 진행을 지속하기 쉽게 만드는 것입니다.
시스템 중심의 팀에서는 통화 없이도 기본 질문에 답할 수 있습니다: 현재 상태는? 무엇이 막혔나? 누가 책임자인가? 다음 단계는 무엇인가?
흔한 징후:
영웅주의에서 시스템으로 옮기면 더 적은 회의가 현실적이 됩니다: 정보와 책임이 워크플로에 내장되면 조정은 실시간 동기화에 덜 의존합니다.
모든 회의가 ‘나쁘다’는 건 아닙니다. 질문은 그 회의가 공동 이해를 생성하는가, 아니면 단지 보이지 않는 업무를 보상하는가입니다.
상태 업데이트는 보통 범인입니다: 누가 무엇을 하는지 신뢰할 수 있는 공유 뷰가 없기 때문에 모두가 진행을 보고합니다.
결정 회의는 맥락이 채팅, 문서, 사람 머릿속에 흩어져 있어 발생하는 경우가 많습니다.
계획 세션은 유용할 수 있지만, 계획을 유지할 시스템이 없으면 실시간 프로젝트 추적으로 흐릅니다.
정렬 회의는 목표와 우선순위가 팀이 매일 참조할 수 있는 방식으로 문서화되어 있지 않을 때 나타납니다.
워크 관리 도구(예: Asana)를 신뢰할 수 있는 진실의 출처로 사용하면 대체 가능한 것들:
목표는 대화 자체를 줄이는 것이 아니라 반복되는 대화를 줄이는 것입니다.
실시간으로 처리하는 편이 나은 주제들:
서면 맥락으로 업데이트를 이해할 수 있고 사람들이 24시간 내에 응답할 수 있으면 비동기를 선택하세요.
실시간 토론이 필요하거나 감정이 개입되거나 오늘 바로 단일 결정과 명확한 소유자가 필요하면 회의를 선택하세요.
회의가 적은 워크플로는 ‘회의 없음’이 아니라 대부분의 조정이 업무 자체 안에서 일어나도록 설정하는 것입니다—그래서 더 적은 사람들이 “이건 어디까지 왔지?” 또는 “누가 그거 하기로 했지?”라고 물어야 합니다.
Asana 같은 도구는 업무를 공유 시스템으로 취급함으로써 이 아이디어를 대중화했습니다: 모든 약속은 가시적이고, 할당되며, 기한이 있습니다.
작업 단위는 누군가 실제로 완수할 수 있는 것이어야 합니다. 작업이 ‘토론’처럼 느껴지면 결과물 중심으로 바꾸세요(예: “Q1 캠페인 논의” → “Q1 캠페인 브리프 초안 작성 및 검토용 공유”).
좋은 작업은 보통 다음을 포함합니다:
이 항목들이 있으면 상태 질문은 줄어듭니다.
작업은 누군가 했다고 말한다고 끝나는 것이 아닙니다. 명확한 정의를 충족했을 때 완료입니다. 경량의 수용 기준을 사용하세요:
이것은 ‘내가 그렇게 의미한 줄 알았다’는 재작업 루프를 막습니다.
템플릿은 조정 비용을 줄이지만 단순해야 합니다. 몇 가지 반복 패턴으로 시작하세요:
템플릿은 유연해야 합니다: 기본 필드, 권장 하위작업, ‘필요 없으면 삭제’ 마인드셋.
작업이 채팅, 캘린더, 누군가의 기억에 흩어져 있으면 회의는 이를 보상하기 위해 늘어납니다. 약속(작업, 담당자, 날짜, 결정)을 중앙화하면 많은 ‘빠른 동기’가 빠른 조회로 대체됩니다.
상용 도구가 워크플로에 맞지 않으면 팀에 맞춘 가벼운 내부 시스템을 만드는 것도 방법입니다. 예를 들어 팀들은 Koder.ai 같은 도구로 챗 기반으로 워크플로를 설명하면 커스텀 웹 대시보드, 접수 폼, 상태 포털을 빠르게 생성해 소유권과 업데이트를 가시화할 수 있습니다.
상태 회의는 보통 한 가지 이유 때문에 존재합니다: 아무도 현재의 업무 상태가 보인다고 신뢰하지 않기 때문입니다. 비동기 리듬은 업데이트를 예측 가능하고 빠르게 훑어볼 수 있게 만들고, 실제 작업 항목과 연결시켜 ‘회의’가 가벼운 점검 흐름이 되게 합니다.
주간 계획(월): 각 팀원은 이번 주 계획을 짧게 게시하고 작업/프로젝트에 링크합니다. 작게 유지하세요: 완료할 것, 시작할 것, 하지 않을 것.
중간 점검(수/목): 변화를 조기에 드러내는 빠른 펄스—무엇이 바뀌었는지, 무엇이 막혔는지, 우선순위 조정이 필요한지.
주간 회고(금): 활동이 아니라 성과 중심 요약: 무엇이 배포되었는가, 무엇이 이동했는가, 무엇이 남았는가, 다음 주로 이어갈 것.
동기화가 남아있다면 예외에만 사용하세요: 해결되지 않은 블로커, 팀 간 트레이드오프, 실시간 토론이 진짜 필요한 결정 등.
일관된 템플릿을 사용해 모두가 빠르게 훑을 수 있게 하세요:
불릿으로 쓰고 헤드라인을 앞에 두며, 기반 작업에 링크해 재설명을 피하세요.
결정의 집과 실행의 집을 하나씩 정하세요(예: 프로젝트의 ‘결정 로그’ 스레드와 작업/프로젝트 트래커). 업데이트는 둘을 가리켜야 합니다: “결정은 여기” 그리고 “작업은 여기”. 이렇게 하면 ‘우리가 어디서 그걸 합의했지?’라는 순간을 줄일 수 있습니다.
24시간 업데이트 창을 설정하세요(고정 회의 시간이 아님). 하루 종료 시 인수인계 노트를 장려하고, 다음 시간대를 태그해 명확한 요청을 남기게 하세요. 긴급 이슈는 정의된 에스컬레이션 경로를 사용하되, 그렇지 않으면 비동기가 일을 처리하게 두세요.
회의는 종종 결정이 ‘붙지’ 않아서 길어집니다. 사람들이 회의 후 무엇을 결정했는지 또는 왜 결정했는지 불확실하면 질문이 다시 떠오르고 신규 이해관계자가 주제를 다시 열며 회의를 또 잡게 됩니다.
결정은 다음이 포함된 명확한 기록이 필요합니다:
결정 로그는 프로젝트에 링크된 간단한 항목이면 됩니다—생성하기 쉽고 찾기 쉬운 것이 핵심입니다.
각 항목은 짧게 유지하세요:
그리고 결정을 소유자에게 연결된 실행 항목으로 바꾸세요. ‘X를 결정했다’는 문장이 ‘Alex가 금요일까지 Y를 한다’로 이어질 때만 유용합니다. 결정이 작업을 만들어내지 않는다면 아마 아직 결정이 아닙니다.
실시간 통화를 요청하기 전에 일관된 사전 읽기 패턴을 사용하세요:
제안(무엇을 하려는가)
옵션(현실적인 선택지 2–3개)
트레이드오프(비용, 위험, 고객 영향, 시간)
권고안(당신의 선택과 이유)
비동기 댓글을 초대하고 마감일을 설정하세요(예: ‘오후 3시까지 피드백’), 그리고 결정 규칙을 명확히 하세요(소유자가 결정, 컨센서스, 또는 승인자 필요).
스레드가 길어지지만 아무 것도 확정되지 않는다면 보통 결정권자가 불명확하거나 기준이 명시되지 않았거나 ‘다음 단계’가 모호하기 때문입니다. 소유자를 명확히 하고 모든 논의를 세 가지 결과 중 하나로 끝내세요: 결정, 구체적 입력 요청, 또는 일정이 정해진 연기.
회의가 늘어나는 단순한 이유는 아무도 묻지 않으면 무슨 일이 일어나고 있는지 확신하지 못하기 때문입니다. 단일 소스 오브 트루스는 팀이 어디서든 찾을 수 있는 한 신뢰할 수 있는 장소를 제공해 줍니다—무엇이 진행 중인지, 누가 언제까지 어떤 정의로 완료하기로 했는지.
작업이 찾아보기 쉬우면 단지 답을 찾기 위해서 회의가 필요하지 않습니다.
작업이 채팅에 논의되고 결정이 이메일에 묻히고 일정이 누군가의 개인 노트에 있으면 같은 질문이 반복됩니다:
그 단편화는 중복 대화와 맥락 누락을 만듭니다. 팀은 업무를 전진시키는 것이 아니라 그것을 재구성하기 위해 동기화를 예약합니다.
워크 관리 도구(Asana가 잘 알려진 예)는 약속을 공개적이고 구조화되며 검색 가능하게 만들어 이러한 문제를 해결합니다. 목표는 모든 생각을 문서화하는 것이 아니라 팀이 의존하는 것을 회의 없이 찾을 수 있게 하는 것입니다.
팀이 더 맞춤형이 필요하면—교차 기능 요청 접수 포털, 자동으로 후속 작업을 생성하는 결정 로그, 또는 정확한 단계에 맞춘 상태 대시보드 같은—Koder.ai 같은 도구로 챗에서 워크플로를 설명하면 React 웹앱과 Go/PostgreSQL 백엔드를 생성할 수 있습니다.
대부분 팀은 도구가 더 필요한 것이 아니라 경계가 더 명확해야 합니다:
전달에 영향이 있다면 그것은 작업 툴에 있어야 합니다—채팅에만 있으면 안 됩니다.
시스템을 신뢰할 수 있게 만들려면 몇 가지 규범을 정하세요:
사람들이 어디를 봐야 할지 알고, 거기서 무엇을 찾을지 신뢰하면 상태 회의는 기본 발견 메커니즘이 아니게 됩니다.
시스템은 ‘빠른 동기?’ 메시지를 대체해야지 새로운 유형의 번거로움을 만들면 안 됩니다. 가장 흔한 실패 모드는 도구가 아니라 워크플로를 서류 작업으로 바꾸고 책임은 흐릿하게 남기는 것입니다.
회의가 적은 워크플로는 다음과 같은 이유로 무너질 수 있습니다:
프로세스 쇼는 모든 것이 정리된 것처럼 보이지만 실제로는 더 빨리 진행되지 않을 때입니다. 많은 움직임(업데이트, 재분류, 재할당)은 보이지만 진전은 적습니다. 징후는 사람들이 워크플로를 관리하는 데 작업 완료보다 더 많은 시간을 쓰는 것입니다.
시스템을 실용적으로 유지하려면 결정과 인수인계를 위해 설계하세요. 각 단계는 실제 질문에 답해야 합니다: 누가 소유자인가? 다음은 무엇인가? 기한은 언제인가? ‘완료’는 무엇을 의미하는가?
몇 가지 습관으로 과다 성장을 막을 수 있습니다:
전사적으로 한 번에 ‘회의 고치기’를 시도하면 실패합니다. 한 팀, 한 워크플로, 한 지표로 시작하세요.
지금 상태 회의를 생성하는 워크플로 하나를 골라(예: 주간 업데이트), 지표를 정의하세요(예: 상태 통화 감소, 사이클 타임 단축, ‘이거 어디 있지?’ 핑 감소). 2주간 실행해 조정하고, 워크플로가 시간을 절약하는 것이 증명되면 확장하세요.
회의를 없앤다고 시스템이 개선되지 않으면 작업은 조용해질 수 있지만 빨라지지는 않습니다. 목표는 방해는 줄이면서도 눈에 보이는 진전을 확보하는 것입니다.
2–4주 내에 볼 수 있는 변화:
이것들을 방향 지시자로 삼으세요. 회의가 줄었는데 놀라움이 늘면 고통만 옮긴 것입니다.
3–5개 지표를 일관되게 유지하세요. 유용한 예:
일관된 상태, 기한, ‘완료’ 정의를 사용해 워크플로 소프트웨어 안에서 추적할 수 있습니다.
숫자는 사람들의 안전감과 명확성을 포착하지 못합니다.
월간으로 물어보세요:
임시 호출과 막판 핑의 꾸준한 감소는 시스템이 작동하고 있다는 강한 신호입니다.
‘회의 40% 감소’만을 축하하지 마세요—산출량이 그대로이거나 품질이 떨어진다면 의미가 없습니다. 최상의 스코어카드는 절약된 시간이 더 나은 결과로 연결되는지 보여줍니다: 신뢰성 있게 배포, 재작성 감소, 조정 마찰 감소—사람들이 탈진하지 않고.
회의가 적은 워크플로는 한 번에 한 습관씩 바꾸고 고정할 때 가장 잘 작동합니다. 다음은 정렬을 잃지 않고 통화를 줄이는 안전한 30일 계획입니다.
명확한 대안이 있는 주간 상태 회의 같은 단일 ‘상태’ 회의를 선택하세요.
대체 방식을 문서화하세요:
그 다음 다음 일정은 취소하거나 15분으로 줄이고 비동기로 처리할 수 없는 블로커 해결에만 사용하세요.
사람들은 무엇을 써야 할지 모르면 비동기 업데이트를 건너뜁니다. 작은 템플릿 세트를 추가하고 기본으로 만드세요.
자체 워크플로를 구축하는 경우 Koder.ai 같은 플랫폼은 초기 앱과 템플릿을 빠르게 생성해 실험을 쉽게 합니다. 스냅샷과 롤백 같은 기능은 기존에 작동하는 것을 깨뜨릴까 걱정하지 않고 프로세스 변경을 시도하게 도와줍니다.
각 약속의 소유자를 명확히 하고 다른 사람이 얼마나 빨리 응답해야 하는지 규정하세요.
예: “블로커에 코멘트는 24시간 내”와 “업무일 종료 시까지 응답이 없으면 소유자가 옵션 A로 진행” 같은 규칙을 정하세요. 이는 비동기가 침묵으로 변하는 것을 막습니다.
주기적 회의를 감사(audit)하고 라벨을 붙이세요:
30일 차에 회의 수, 제때 배달률, ‘놀라움’ 빈도를 비교하세요. 놀라움이 줄었다면 시스템이 작동하는 것입니다.
원하면 더 많은 실용적 플레이북을 보려면 /blog에서 팀 워크플로 가이드와 템플릿을 찾아보세요.
회의는 팀에 신뢰할 수 있는 공유된 업무 뷰가 부족할 때 급증합니다.
약속들이 사람 머릿속에만 있거나, DM, 흩어진 문서나 스프레드시트에 있다면 공동의 맥락을 재구성하려고 자꾸 모이게 됩니다.
“가시화된 업무”는 누구나 빠르게 답할 수 있음을 의미합니다:
투명성 자체가 목적이 아니라 조정 불확실성을 줄이는 것이 핵심입니다.
영웅적 행동은 기억력, 긴급성, 비공식적 촉구(DM, 복도 대화, 급한 전화)에 의해 이루어지는 막판 구조 수습입니다.
시스템은 재현성으로 그것을 대체합니다: 명확한 워크플로, 명시적 책임자, 그리고 맥락을 캡처해 두어 진행이 특정 개인의 기억이나 개입에 의존하지 않게 합니다.
대개 교체 가능한 것들:
목표는 대화 자체를 줄이는 것이 아니라 반복되는 대화를 줄이는 것입니다.
실시간 뉘앙스가 중요한 경우는 유지하거나 신중히 사용하세요:
비동기로 충분한가요? 서면 맥락으로 이해할 수 있고 사람들이 24시간 내에 응답할 수 있다면 비동기를 선택하세요.
실시간 토론이 필요하거나 감정·톤이 중요하거나 오늘 바로 단일 결정과 책임자가 필요하면 회의를 선택하세요.
강한 작업 항목은 실제 약속이어야지 모호한 메모가 아니어야 합니다. 포함할 것:
예: “X를 논의” 대신 “X 초안을 작성해 검토용으로 공유”처럼 결과 중심으로 적습니다.
‘완료’의 정의를 미리 정하세요. 경량의 수용 기준을 사용하면 재작업과 ‘내가 그렇게 이해했나?’ 루프를 막을 수 있습니다:
경량 결정 로그 항목을 사용하세요:
그리고 결정을 작업 항목으로 전환해 책임자를 지정하세요. ‘X로 결정했다’는 문장이 작업으로 연결될 때만 실용적입니다.
경계를 단순하게 유지하세요:
규칙: 전달에 영향을 주는 것은 채팅에만 있지 말고 워크 툴에도 있어야 합니다.