업무 위임 방법: 제대로 자리 잡는 인수인계 — 브리프, 담당자, 마감일, 그리고 양쪽 모두 읽을 수 있는 기록 (2026)

업무를 위임하려면 단계별 목록이 아닌 결과물을 넘겨주세요. 결과, 마감일, 한계를 담은 한 단락짜리 브리프, 소리 내어 "맡겠습니다"라고 말하는 단 한 명의 담당자, 작업을 시작하기 전에 합의한 중간 점검, 그리고 나중에 양쪽 모두 읽을 수 있는 곳에 보관된 인수인계 기록이 필요합니다. 단계별 방법, 그대로 복사해 쓸 수 있는 브리프 템플릿, 여러 사람이 관여하는 업무를 위한 RACI 차트, 위임할 일과 직접 맡을 일, Teams, Zoom, Google Workspace, Slack에서 인수인계 기록이 위치하는 곳, 그리고 모든 멤버가 각자의 언어로 읽는 다음 요약에서 해당 업무가 완료 또는 미완료로 돌아오는 방식까지 안내합니다.

The Mind.com Team

알파 미리보기Team status pages
  • 단계가 아니라 결과를 위임하세요. 결과·마감일·한계를 담은 브리프 하나, "하겠다"고 답하는 담당자 한 명, 시작 전에 합의한 중간 점검 하나면 됩니다.
  • 인수인계는 나중에도 읽을 수 있어야 합니다. Teams, Zoom, Google Workspace, Slack에서 업무는 그 회의실에서 쓰인 언어로 문서에 적힌 한 줄일 뿐입니다.
  • InterMIND는 채널 전체를 각 멤버의 언어로 유지합니다. 브리프, 채팅, 업무를 보고하는 회의 요약까지 모두 해당합니다. 이 도구들을 대체하는 것이 아니라 옆에서 함께 쓰입니다. 게스트는 링크로 무료 참여하며 계정이 필요 없고, 비용은 활성 멤버에 대해서만 냅니다.
업무 위임 방법: 제대로 자리 잡는 인수인계 — 브리프, 담당자, 마감일, 그리고 양쪽 모두 읽을 수 있는 기록 (2026)

업무 위임하는 방법: 끝까지 가는 인수인계 — 브리프, 담당자, 마감일, 그리고 양쪽이 읽을 수 있는 기록 (2026)

업무를 위임한다는 것은 상대에게 결과와 그 결과에 도달할 여지를 넘겨주는 일입니다. 무엇이 끝난 상태인지, 언제까지인지, 어떤 한계 안에서인지, 진행 상황을 어떻게 들을 것인지를 함께 정하는 것입니다. "Mateusz — Aster 제안서, 승인 가능한 초안을 목요일까지 나에게, 표준 조건 이내로, 가격이 불확실하면 화요일에 알려 주세요"는 위임된 업무입니다. "Aster 제안서 좀 한번 봐 줄래요?"는 바람일 뿐이고, 이 말을 들은 사람은 엉뚱한 일을 제시간에 하거나 맞는 일을 늦게 하게 됩니다.

10명에서 200명 사이 팀의 리더 대부분은 의도한 것보다 적게 위임합니다. 이유는 산수 하나입니다. 업무를 처음 넘기는 비용이 그 업무를 직접 하는 비용보다 크기 때문입니다. 브리프를 쓰는 데 20분, 질문에 답하는 데 또 20분이 들고, 결과물은 내가 했을 때와 다르게 돌아옵니다. 같은 종류의 업무가 두 번째로 나올 때 이 산수는 뒤집힙니다. 첫 번째 인수인계를 글로 남겼다면 두 번째는 대화가 아니라 링크 하나로 끝나기 때문입니다. 이 가이드가 인수인계 자체만큼 인수인계의 기록에 많은 분량을 쓰는 이유입니다.

먼저 기술(craft)을 다룹니다. 위임이란 무엇이고 무엇이 아닌지, 무엇을 위임하고 무엇을 직접 쥘지, 끝까지 가는 인수인계의 여섯 단계, 그리고 복사해서 쓸 수 있는 브리프 템플릿과 RACI 차트입니다. 그다음은 구조입니다. 인수인계가 팀이 이미 쓰는 도구 안 어디에 있는지, 그리고 업무가 완료되었든 아니든 아무도 쫓아다니지 않고 어떻게 돌아오는지를 살펴봅니다.

위임이란 무엇이고, 무엇이 아닌가

위임이라고 불리는 것은 세 가지이고, 그중 가운데 하나만 진짜 위임입니다.

넘겨주는 것담당자가 결정하는 것돌아오는 것
지시단계: "공급업체에 전화해서 새 가격표를 요청하세요"없음 — 방법이 이미 주어짐완료 여부와 상관없이 그 단계
위임결과: "20일까지 서명할 수 있는 공급가를 확보해 주세요"명시된 한계 안에서의 방법결과, 그리고 그 과정에서 배운 것
방기한계도, 날짜도, 중간 점검도 없는 결과무엇이 끝난 상태인지를 포함한 모든 것어느 쪽으로든 뜻밖의 결과

지시가 잘못된 것은 아닙니다. 신입 사원의 첫 주는 대부분 지시로 채워집니다. 다만 모든 단계가 여전히 나를 거치므로 확장되지 않습니다. 방기는 신뢰처럼 느껴지지만 대개는 리더가 너무 바빠서 브리프를 쓰지 못한 것이고, 담당자는 한계를 넘어 보고서야 그 한계를 알게 됩니다. 위임은 그 중간입니다. 결과는 고정되어 있고, 경로는 담당자의 몫이며, 양쪽 모두 언제 어떻게 그 일을 이야기할지 알고 있습니다.

위임된 업무는 액션 아이템과도 다릅니다. 액션 아이템은 회의에서 태어난 한 줄, 즉 동사 하나, 담당자 한 명, 날짜 하나이고, 그것을 만든 회의가 직접 점검합니다. 위임된 업무는 보통 더 큽니다. 브리프가 있고, 며칠 또는 몇 주가 걸리며, 그 과정에서 여러 개의 액션 아이템을 만들어 냅니다. 둘은 회의 요약에서 만납니다. 위임된 업무는 담당자가 보고하는 대상이고, 액션 아이템은 그 보고를 이루는 줄들입니다.

무엇을 위임하고 무엇을 쥘 것인가

질문은 "내 접시에서 무엇을 덜어낼 수 있을까"가 아니라 "무엇이 다른 사람의 손에서 지금 혹은 두 번째부터 더 낫게, 최소한 비슷하게 돌아올까"입니다. 네 가지 기준이 있습니다.

  1. 다른 사람이 오늘 당장 80% 수준으로 할 수 있다. 부족한 20%를 메우기 위해 브리프와 중간 점검이 있습니다. 팀에 80%에 도달한 사람이 없다면 그 업무는 육성 과제입니다. 더 가까운 중간 점검과 함께 위임하고, 첫 라운드는 훈련으로 셈하세요.
  2. 반복된다. 매달 나오는 업무는 20분짜리 브리프를 쓸 가치가 있습니다. 브리프는 한 번 쓰고 열두 번 재사용하기 때문입니다. 한 번만 나오고 한 시간이면 끝나는 업무는 넘기는 것보다 직접 하는 편이 싸지는 경우가 많습니다. 누군가 그 일을 배워야 하는 경우는 예외입니다.
  3. 한 문단으로 쓸 수 있는 완료 정의가 있다. 끝난 상태를 말로 설명할 수 없다면 아직 위임할 수 없습니다. 대신 첫 단계는 위임할 수 있습니다. "끝난 상태가 어떤 모습일지 알아보고 금요일까지 알려 주세요"는 날짜가 있는 진짜 업무입니다.
  4. 그 결정을 내릴 수 있는 사람이 나 하나만은 아니다. 어떤 결정은 직책상 내 몫입니다. 채용, 급여, 성과 면담, 내 상사가 나를 지목해서 물을 일, 부여받은 한도를 넘어 조직을 구속하는 모든 일입니다. 이런 것은 직접 쥡니다. 반면 그 준비 작업은 언제든 위임됩니다.

원칙적으로 내게 남는 것은 위의 결정들, 나만 할 수 있는 대화, 그리고 내가 그 역할을 맡은 이유인 단 하나의 업무입니다. 나머지는 모두 위임 후보이고, 후보 목록은 보통 리더의 예상보다 깁니다.

업무 위임하는 방법: 여섯 단계

1. 말하기 전에 브리프를 쓰세요. 한 문단이면 됩니다. 결과, 그것이 중요한 이유, 마감일, 한계, 그리고 관련된 다른 사람을 담습니다. 브리프를 쓰는 일은 앞 절의 테스트이기도 합니다. 문단이 써지지 않는다면 그 업무는 아직 내 손을 떠날 준비가 안 된 것입니다. 또 브리프를 쓰면 인수인계가 담당자가 다시 읽을 수 있는 형태로 존재하게 됩니다. 이것이 위임된 업무와 그냥 언급된 업무의 결정적인 차이입니다.

2. 담당자는 한 명으로 정하고, 소리 내어 "예"를 받으세요. 팀도, 두 명도 아닌 이름 하나입니다. 담당자는 다음 주에 그 업무에 대해 질문받을 사람이므로, 이번 주에 그 업무에 동의한 사람이어야 합니다. 업무를 제안하고, 상대가 예라고 하든 아니오라고 하든 "마감을 금요일로 옮기면 예"라고 하든 말하게 하세요. 누군가 들은 업무는 위임된 것이 아닙니다. 누군가 "예"라고 답한 업무가 위임된 것입니다.

3. 끝난 상태가 어떤 모습인지 말하고, 상대가 되받아 말하게 하세요. 담당자가 결과를 자기 말로 반복합니다. "Aster 제안서 승인 가능한 초안, 표준 조건, 목요일까지 당신에게." 이 30초짜리 되읽기가 나중에 생길 문제의 대부분을 걸러 냅니다. 두 사람이 "초안", "승인 가능", "목요일"을 조금씩 다르게 이해하고 있는 경우가 흔하기 때문입니다.

4. 권한을 명시하세요. 나에게 묻지 않고 결정할 수 있는 것이 무엇인지. 네 단계면 거의 모든 업무를 설명할 수 있습니다. 행동하기 전에 알려 주세요. 결정하고 알려 주세요. 결정하세요. 한계를 벗어날 때만 알려 주세요. 결정하세요. 나는 들을 필요 없습니다. 어느 단계에 해당하는지 말하고, 한계(가격, 날짜, 협의해야 할 사람의 목록)를 명시하세요. 자신의 단계를 모르는 담당자는 모든 일로 나를 찾아오거나 아무 일로도 찾아오지 않습니다. 둘 다 위임이 실패한 것처럼 보이지만, 사실은 한 줄이 빠진 브리프입니다.

5. 중간 점검은 일이 시작되기 전에 합의하세요. 불안해졌을 때가 아닙니다. 날짜, 형식, 분량을 정합니다. "화요일에 채널에 세 줄 메시지 — 순조로움, 순조롭지 않음과 그 이유, 나에게 필요한 결정." 중간 점검을 나중에 정하면 마이크로매니지먼트이고, 브리프에서 미리 정한 같은 점검은 지원입니다. 또 담당자가 실패처럼 보이지 않으면서 도움을 청할 자연스러운 순간이 되기도 합니다.

6. 양쪽이 나중에 읽을 곳에 인수인계를 두세요. 브리프, "예"라는 답, 권한 단계, 중간 점검 날짜는 팀이 이미 업무를 보관하는 곳, 즉 채널, 트래커, 프로젝트 스레드에 둡니다. 두 사람만 볼 수 있고 한 사람만 찾아낼 다이렉트 메시지에 두면 안 됩니다. 업무가 돌아오면 결과를 브리프 옆에 둡니다. 그러면 같은 종류의 업무를 맡는 다음 사람은 대화가 아니라 기록에서 시작합니다. WhatsApp 그룹에서 이루어진 인수인계는 그 그룹이 존재하는 동안만 기록입니다. 채팅 내보내기가 만들어 주는 것과 만들어 주지 않는 것은 대화 하나가 담긴 텍스트 파일이며, 그 옵션은 모든 곳에서 제공되지도 않습니다.

그리고 업무가 착지한 뒤에 한 가지가 더 있습니다. 무엇이 돌아왔는지를 같은 곳에서 같은 사람들에게 말하세요. "Mateusz의 초안이 수요일에 들어왔고, 두 줄을 고쳐서 목요일에 Aster로 나갔습니다." 담당자는 자기 작업이 확인되었음을 듣고, 팀은 마무리된 인수인계가 어떤 모습인지 알게 되며, 기록은 마지막 줄을 갖게 됩니다.

위임 브리프 템플릿

업무: [한 줄 — 명사로 쓴 결과: "승인된 제안서", "공급업체 3곳의 후보 목록"]
담당자: [이름] · 위임자: [이름] · 합의일: [날짜]
중요한 이유: [한 문장 — 무엇이 풀리는지, 누가 기다리는지]
완료의 기준: [담당자가 확인할 수 있는 두세 줄 — 무엇이, 누구의 손에, 어떤 형태로 존재하는지]
마감일: [날짜] · 중간 점검: [날짜, 형식 — "채널에 세 줄"]
결정할 수 있는 것: [권한 단계와 한계 — 가격, 날짜, 범위]
먼저 물어볼 것: [위임하는 쪽의 말이 먼저 필요한 한두 가지]
함께할 사람: [이름 — 용건]
출발점: [링크 — 지난번에 이 일을 했을 때의 자료, 템플릿, 고객 파일]

결과 (업무가 돌아올 때 작성): [무엇이 어디에 언제 도착했는지 — 그리고 다음에는 다르게 할 한 가지]

이 블록은 일반 텍스트이므로 서식을 다시 맞추지 않고도 채팅 메시지, 캔버스, 트래커 티켓, 이메일에 그대로 붙여 넣을 수 있습니다. 마지막 줄은 대부분의 템플릿이 빠뜨리는 줄이며, 두 번째 인수인계를 첫 번째보다 싸게 만드는 줄입니다.

RACI 차트 템플릿 — 업무에 여러 사람이 관여할 때

브리프에는 담당자가 한 명입니다. 업무가 여러 사람에 걸칠 때, 예를 들어 제안서에 법무의 수정 의견, 재무의 가격, 어카운트 리드의 승인이 필요할 때도 담당자 한 명의 원칙은 유지됩니다. RACI 차트는 누구도 다른 사람이 하고 있다고 가정하지 않도록 이를 글로 적는 방법입니다. 행마다 네 글자가 있습니다.

  • R — Responsible(실행): 작업을 수행합니다. 한 명 이상.
  • A — Accountable(책임): 결과를 소유하고 승인합니다. 행당 정확히 한 명이며, 브리프의 담당자가 바로 이 사람입니다.
  • C — Consulted(자문): 작업이 끝나기 전에 의견을 줍니다. 양방향.
  • I — Informed(통보): 결과를 전달받습니다. 일방향.
업무Mateusz (어카운트 리드)Lena (법무)Priya (재무)Tomás (영업 총괄)
Aster 제안서 초안 작성A / RCCI
계약 조건 수정 검토CA / RII
가격 및 결제 조건 설정CIA / RC
승인 후 고객에게 발송RIIA

세 가지 규칙이 차트를 정직하게 유지합니다. 행마다 A는 하나입니다. 책임자가 둘이면 아무도 없는 것과 같습니다. 모든 행에 R이 최소 하나 있어야 합니다. A만 있고 R이 없는 업무는 바람일 뿐입니다. 그리고 C와 I로만 채워진 열이 없어야 합니다. 모든 일에 자문하면서 아무 일도 실행하지 않는 사람은 작업이 아니라 직함 때문에 차트에 들어 있는 것이고, 모든 행의 속도를 늦출 것입니다. 사람들에 걸친 업무의 첫 회의에서 차트를 만들고, 한 번 소리 내어 읽고, 브리프 옆에 두세요.

세 가지 인수인계, 전과 후

처음 한 말위임된 업무로 바꾸면
"Aster 제안서 좀 한번 봐 줄래요?"Mateusz — Aster 제안서의 승인 가능한 초안, 표준 조건, 10월 30일 목요일까지 나에게. 범위는 줄 단위로 직접 결정하세요. 정가 미만의 가격은 먼저 물어보세요. 화요일에 채널에 세 줄.
"후보자를 내가 보기 전에 누가 좀 추려 줬으면 좋겠어요."Priya — 지원서 11건 중 3명의 후보 목록, 각각 그 이유를 한 문단씩, 11월 3일 월요일까지. 후보 목록은 직접 결정하세요. 면접 일정은 내가 정합니다. 기준을 넘는 사람이 세 명 미만이면 목요일에 알려 주세요.
"이번에는 월간 보고서가 더 일찍 필요해요."Kenji — 10월 운영 보고서를 평소 템플릿으로, 5일까지 리더십 채널에. 지금부터 매달 당신이 맡습니다. 숫자는 Dana에게서 받고, 3일까지 자문을 구하세요. 어떤 숫자의 출처를 확보할 수 없을 때만 알려 주세요.

오른쪽 열에 무엇이 있는지 보세요. 이름, 명사로 쓴 결과, 날짜, 권한 단계, 중간 점검이 있습니다. 왼쪽 열에는 동사 하나와 희망뿐입니다. 둘의 차이는 한 번 쓰는 네 문장 정도입니다.

이미 쓰고 있는 도구에서 인수인계는 어디에 있는가

인수인계에는 브리프, "예"라는 답, 결과를 양쪽이 나중에, 그리고 다음 분기에 같은 업무를 맡을 사람이 읽을 수 있는 장소가 필요합니다. 주요 플랫폼은 각각 회의에서 태어난 업무를 적는 장소를 갖고 있고, 각각 다른 지점에서 멈춥니다. 아래는 공급업체 자체 페이지에 문서화된 동작만 다룹니다. 각 셀에는 해당 사실을 확인한 월이 적혀 있고, 페이지는 출처 푸터에 있습니다.

플랫폼회의에서 나온 업무가 적히는 곳그 후 어떻게 되는가
Microsoft Teams통화 중 회의 컨트롤의 Notes. 참석자나 주최자 누구나 편집할 수 있는 Loop 컴포넌트이며, 사람을 태그해 업무를 할당합니다. 회의 요약(recap)에는 후속 업무가 나열됩니다(Notes 페이지 2026년 10월 확인, recap 페이지 2026년 8월 확인)노트는 자동으로 저장되며 Teams 캘린더와 회의 요약에서 접근할 수 있습니다. 외부 참석자는 접근하거나 편집할 수 없습니다(2026년 10월 확인)
Zoom Workplace유료 Zoom Workplace 요금제에서 AI Companion 회의 요약에 "Next steps" 섹션이 포함됩니다(2026년 8월 확인)요약은 이메일로 전송되고, 웹 포털의 Summaries 페이지에 나열되며, 회의의 그룹 채팅에 게시할 수 있습니다. 호스트가 공유하도록 선택한 경우에만 참가자가 받고, 편집은 호스트만 할 수 있으며, 인증되지 않은 사용자는 이메일을 받지 못합니다(2026년 8월 확인)
Google Workspace"Take notes for me"가 회의 후 노트 문서에 "suggested next steps" 섹션을 추가합니다. 읽는 사람은 다음 단계를 검토하고 편집할 수 있으며 "and even assign the task to someone"이 가능합니다(2026년 9월 확인)노트는 Google Doc으로 도착하며 설정된 방식대로 공유됩니다. 업무 할당은 문서 안에서 사람이 클릭해서 하며, 이 기능은 한 번에 한 언어만 지원합니다. 같은 회의에서 여러 언어가 사용되는 경우는 지원되지 않습니다(2026년 10월 확인)
Slack회의 안건 템플릿으로 만든 캔버스를 채널에 공유하며, 다음 단계와 마감일이 있는 액션 아이템 섹션이 있습니다(2026년 10월 확인)캔버스는 문서로서 채널에 남습니다. 통화에서 말한 내용은 누군가 직접 입력하지 않는 한 그 안에 없습니다(2026년 10월 확인)

어디서나 같은 점이 두 가지 있습니다. 인수인계는 회의 옆의 문서이고, 그 회의실에서 쓰인 하나의 언어로 쓰입니다. 그리고 업무가 돌아왔는지는 문서가 답해 주지 않으며, 사람이 문서를 열어 물어야 합니다. 위임하는 리더와 담당자가 업무 언어를 공유하지 않는 경우, 인수인계 통화 자체는 문서화된 답이 있는 별개의 문제입니다. Microsoft Teams가 두 언어로 진행되는 라이브 회의를 어떻게 처리하는지, 그리고 어디서 멈추는지, 그리고 Google Meet의 경우를 참고하세요.

회의 요약에서 업무가 돌아오는 방식

InterMIND는 팀의 회의가 채널 안에 존재하는 커뮤니케이션 공간이므로, 인수인계의 집은 하나입니다. 채널의 채팅에 브리프가 게시되고, 담당자의 "예"는 그 아래 답글이 되며, 화요일의 중간 점검은 같은 스레드의 세 줄입니다. 이 모든 것이 각 멤버의 언어로 유지됩니다. 밀라노의 리더가 이탈리아어로 브리프를 쓰면, 부쿠레슈티의 담당자는 루마니아어로 읽고 루마니아어로 답하며, 양쪽 모두 토글 한 번으로 원문을 볼 수 있습니다. 다른 곳에서 작성한 브리프나 이메일로 도착한 고객의 요청은 이메일로 채널에 들어옵니다. 채널 호스트가 채널 전용 주소를 만들어 주면, 그 주소로 보낸 메시지는 발신자 이름으로 일반 메시지처럼 나타나고, 첨부파일은 유지되며, 다른 메시지와 마찬가지로 읽는 사람마다 번역됩니다.

인수인계가 채널의 회의에서 이루어진다면, Share to conference로 브리프를 모두의 화면에 영상 타일 옆에 띄웁니다. 공유한 사람이 모두가 보는 앞에서 실시간으로 편집하고(마감일을 옮기고, 권한 줄을 추가하고), 참가자 모두가 자기 언어로 읽습니다. 통화가 끝나면 회의 요약이 회의 자체에서 작성됩니다. 요약과 맡기로 한 업무가 각각 담당자와 함께, 각 줄의 타임스탬프를 유지한 채 담겨 있습니다. 요약은 로그인한 각 멤버에게 이메일로, 채널의 메시지로, 캘린더 일정의 링크로 도착하며, 모든 멤버가 그 회의실에서 우연히 쓰인 언어가 아니라 자기 언어로 읽습니다. 어느 멤버든 편집할 수 있고, 모든 편집에는 작성자와 수정 이력이 남습니다. 채널은 지난 모든 세션의 요약을 보관하므로, 3주 전의 브리프와 돌아온 결과는 검색 한 번이면 찾을 수 있습니다. 링크로 연 즉석 회의는 가장 최근의 요약만 보관하고, 통화가 끝나면 채팅이 삭제됩니다. 팀의 인수인계는 채널에 속합니다.

팀 상태 페이지(team status pages)를 켠 조직에서는 업무 후속 점검도 이루어집니다. 회의 요약에 기록된 모든 업무는 조직의 업무 체인에 합류하고, 채널 회의의 다음 요약이 작성될 때 미결 업무는 회의에서 나온 말에 비추어 판정됩니다. 완료되었다고 보고된 업무는 완료로 표시되고, 논의되었지만 끝나지 않은 업무는 회의에서 나온 말로 된 사유와 함께 미완료로 표시되며, 아무도 언급하지 않은 업무는 미결로 남습니다. 판정은 각각의 인용문과 그 근거가 된 회의 요약과 함께 조직의 상태 페이지에 남고, 멤버 본인의 판정이 모델의 판정보다 우선합니다. 다음 세션이 시작될 때 Mia가 미결 업무와 그 담당자를 짚어 주므로, 아무도 물어볼 생각을 하지 않았더라도 중간 점검이 이루어집니다. 팀 상태 페이지는 프리뷰 기능입니다. 조직의 관리자가 알파 약관에 동의한 뒤 Settings → Advanced에서 켭니다(Preview features 페이지에서 각 기능을 설명합니다).

업무가 기록 시스템에 반영되어야 하는 경우, 예를 들어 CRM의 거래나 트래커의 티켓이라면, 호스트가 어떤 주소로든 회의 요약 사본을 추가합니다. 그러면 해당 회의나 채널의 모든 회의 요약이 주소를 한 번 확인한 뒤 그곳으로도 전송됩니다. 이는 모든 요금제에서 가능하며 저장된 주소는 최대 10개입니다. 자세한 방식은 모든 회의 요약의 사본을 이메일로 CRM에서 받는 방법에 있습니다.

채널은 멤버 전용입니다. 팀의 기록에서 업무를 맡는 협력업체, 에이전시, 고객은 이메일 초대로 무료 계정에 추가되며, 그때부터 자기 언어로 채널을 읽습니다. 팀 밖의 채널 참가자에게는 요금이 청구되지 않습니다. 회의 한 번만 필요한 사람, 예를 들어 브리프 하나를 받으러 온 공급업체나 후보자는 링크로 즉석 회의에 참여합니다. 휴대폰으로, 계정 없이, 무료로 참여하고, 회의를 자기 언어로 실시간으로 들으며, 그 이후에는 아무것도 받지 않습니다. 계정은 무료이고, 기록에 접근할 수 있게 만드는 것이 바로 계정입니다. 호스트가 공간을 제공하며, 유료 요금제에서는 직전 28일 동안 활성 상태였던 멤버, 즉 회의에 참여했거나 채팅에 글을 썼거나 Mia에게 질문한 멤버에 대해서만 비용을 냅니다. 조용해진 멤버는 비용 없이 접근 권한을 유지합니다.

기술로서의 위임은 어떤 도구에서도 살아남습니다. 누군가는 여전히 브리프를 쓰고, 이름 하나를 고르고, 그 사람이 소리 내어 "예"라고 말하게 해야 합니다. 살아남지 않아도 되는 것은 두 번째 일입니다. 통화 후에 인수인계를 한 가지 언어로 다시 타이핑하는 일, 그리고 지난 회의에서 합의한 일을 누가 했는지 묻는 것으로 다음 회의를 여는 일입니다.

FAQ

업무를 효과적으로 위임하려면 어떻게 해야 하나요?

단계 목록이 아니라 결과를 넘기세요. 끝난 상태가 어떤 모습인지, 마감일, 한계, 관련된 다른 사람을 담은 한 문단짜리 브리프를 쓰세요. 담당자를 한 명 정하고 소리 내어 "예"를 받으세요. 담당자가 결과를 자기 말로 되받아 말하게 하세요. 나에게 묻지 않고 결정할 수 있는 것이 무엇인지 말하세요. 일이 시작되기 전에 중간 점검(날짜, 형식, 분량)을 합의하세요. 그리고 인수인계를 양쪽이 나중에 읽을 수 있는 곳에 보관하세요. 업무가 돌아오면 같은 곳에서 그 사실을 말하세요.

위임의 단계는 무엇인가요?

순서대로 여섯 가지입니다. 브리프, 담당자, 되읽기, 권한 단계, 중간 점검, 기록. 처음 세 가지는 양쪽이 같은 것을 의미하도록 보장합니다. 네 번째는 담당자가 모든 결정을 위해 돌아오거나 부여받지 않은 결정을 내리는 것을 막습니다. 다섯 번째는 날짜를 미리 정해 두어 지원과 마이크로매니지먼트를 구분합니다. 여섯 번째는 같은 업무의 두 번째 인수인계를 첫 번째보다 싸게 만듭니다.

어떤 업무는 위임하지 말아야 하나요?

직책상 내 몫인 결정, 즉 채용, 급여, 성과 면담, 내 상사가 나를 지목해서 물을 일, 부여받은 한도를 넘어 조직을 구속하는 모든 일, 그리고 나만 할 수 있는 대화입니다. 이런 결정을 준비하는 모든 일은 위임할 수 있습니다. 한 문단으로 완료 상태를 설명할 수 없는 업무도 아직 위임할 준비가 되지 않은 것입니다. 다만 끝난 상태가 어떤 모습일지 알아보는 첫 단계는 위임할 수 있습니다.

위임(delegating)과 업무 배정(assigning)은 어떻게 다른가요?

배정은 단계를 넘기고 방법은 내가 쥡니다. "공급업체에 전화해서 새 가격표를 요청하세요"가 그 예입니다. 위임은 결과를 넘기고 방법은 명시된 한계 안에서 담당자에게 맡깁니다. "20일까지 서명할 수 있는 공급가를 확보해 주세요"가 그 예입니다. 배정은 신입 사원의 첫 몇 주와 긴급 상황에 맞지만, 모든 단계가 여전히 배정하는 사람을 거치므로 확장되지 않습니다. 위임은 확장되며, 그 대가는 브리프 한 장입니다.

RACI 차트란 무엇인가요?

업무를 행으로, 사람을 열로 놓은 표이며, 각 셀에 네 글자 중 하나가 들어갑니다. R은 작업을 수행하는 사람, A는 결과를 소유하고 승인하는 단 한 사람, C는 작업이 끝나기 전에 자문하는 사람, I는 결과를 통보받는 사람입니다. 이 표를 쓸모 있게 만드는 규칙은 행당 A 하나입니다. 책임자가 둘인 업무에는 책임자가 없는 것입니다. RACI 차트는 여러 사람이 관여하는 업무를 위한 것이며, 담당자가 한 명인 단일 업무에는 브리프만 있으면 됩니다.

마이크로매니지먼트 없이 위임한 업무를 어떻게 점검하나요?

일이 시작되기 전에 브리프에서 중간 점검을 합의하세요. 정해진 날, 정해진 형식, 정해진 분량(예를 들어 화요일에 팀 채널에 세 줄)으로 정하고, 중간 점검 사이에는 묻지 마세요. 합의한 날에 같은 질문을 하면 지원이고, 임의의 날에 하면 마이크로매니지먼트입니다. 중간 점검에서 "순조롭지 않음"이 돌아오면, 대화는 사람이 아니라 장애물에 관한 것이어야 합니다. 반복되는 회의의 요약이 다음 세션에서 미결 업무를 되읽어 주는 공간에서는, 후속 점검이 내 주기가 아니라 자체 주기로 이루어집니다.

위임은 왜 실패하나요?

거의 언제나 업무가 아니라 인수인계에서 실패합니다. 결과가 글로 적혀 있지 않아서 담당자가 다른 것을 만들었거나, 아무도 "예"라고 하지 않아서 아무도 책임지지 않았거나, 권한 단계가 명시되지 않아서 담당자가 모든 결정에서 멈추거나 부여받지 않은 결정을 내렸거나, 중간 점검을 리더가 불안해졌을 때 정해서 불신으로 받아들여졌거나, 결과가 한 번도 인정받지 못해서 다음 업무를 덜 신경 써서 맡게 된 경우입니다. 이 가운데 어느 것이든 브리프의 한 줄로 해결됩니다.


출처: Microsoft — Microsoft Teams에서 회의 노트 작성; Microsoft — Microsoft Teams의 회의 요약(Recap); Zoom — AI Companion으로 회의 요약 사용하기; Google Workspace Updates — "Take notes for me"가 이제 "next steps"를 포착합니다; Google Meet — Google Meet의 "Take notes for me"; Slack — 회의 안건 템플릿(캔버스). Microsoft의 노트 페이지, Google의 Meet 도움말 페이지, Slack의 템플릿은 2026년 10월에 확인했고, Microsoft의 recap 페이지와 Zoom의 회의 요약 페이지는 2026년 8월에, Google의 next-steps 발표는 2026년 9월에 확인했습니다. 공급업체는 시간이 지나면서 요금제, 기능, 지원 언어 목록을 변경합니다. 최신 상태는 각 공급업체의 페이지에서 확인하세요.

회의 및 요약 더 보기

회의 및 요약의 모든 게시물
How to write an SOP: steps, template, example, review cycle — and where the SOP lives after it is written (2026)
회의 및 요약

How to write an SOP: steps, template, example, review cycle — and where the SOP lives after it is written (2026)

To write an SOP, pick one recurring job, watch the person who does it, draft the numbered steps first — each starting with a role and a verb and ending in a result someone else can check — add the exceptions and the records, give it an ID, an owner and a review date, test it on someone new to the job, then publish it where the team already reads. The seven steps in order, a one-page template you can copy, a worked example, the review cycle that keeps the procedure true, where the SOP lives in Teams, Zoom, Google Workspace and Slack after it is written — and how the procedure and every review of it stay readable for each member in their own language.

The Mind.com Team

재택근무 정책: 템플릿, 구성 항목, 예시 — 그리고 정책이 자리하는 단 하나의 채널 (2026)
회의 및 요약

재택근무 정책: 템플릿, 구성 항목, 예시 — 그리고 정책이 자리하는 단 하나의 채널 (2026)

재택근무 정책은 사무실 밖에서 일하는 방식에 대한 서면 규칙 모음입니다. 누가, 어디에서 근무할 수 있는지, 언제 연락이 가능해야 하는지, 팀은 어떻게 소통하는지, 장비와 통신 비용은 누가 부담하는지, 회사 데이터는 어떻게 안전하게 보호하는지, 그리고 정책 자체는 어떻게 검토하는지를 담습니다. 실무에 쓸 수 있는 정책에 들어가는 열 가지 항목, 그대로 복사해 쓸 수 있는 템플릿, 3개국에 걸쳐 있는 40명 규모 회사를 위한 작성 예시, 정책과 그 검토가 Teams, Zoom, Google Workspace, Slack 어디에 자리하는지, 그리고 하나의 채널이 정책과 그에 대한 모든 질문, 모든 변경 사항을 각 구성원이 자신의 언어로 읽을 수 있게 하는 방법까지 다룹니다.

The Mind.com Team

팀 생산성을 높이는 방법: 더 적은 회의, 서면 상태 보고, 모든 오피스가 읽을 수 있는 기록 (2026)
회의 및 요약

팀 생산성을 높이는 방법: 더 적은 회의, 서면 상태 보고, 모든 오피스가 읽을 수 있는 기록 (2026)

팀 생산성을 높이려면 무언가를 결정하는 회의만 남기고, 상태 공유는 정해진 시간까지 게시하는 서면 업데이트로 옮기며, 모든 구성원이 나중에 읽을 수 있도록 결정 사항과 작업의 기록을 한 곳에 유지하세요. 각 방법의 근거가 되는 계산과 함께 세 가지 핵심 요소, 복사해서 쓸 수 있는 주간 상태 보고 템플릿, 30일 계획, Teams, Zoom, Google Workspace, Slack에서 서면 상태 보고와 회의 기록이 위치하는 곳, 그리고 채널을 통해 상태, 작업, 모든 요약을 각 구성원이 자신의 언어로 읽을 수 있게 하는 방법까지 다룹니다.

The Mind.com Team

이메일로 새 게시물 및 제품 업데이트 받기

새 글 및 제품 업데이트가 포함된 이메일을 매월 한 번 발송합니다. 언제든지 구독을 취소할 수 있습니다.