회의록을 다 썼다면, 다음은 누구에게 넘겨야 할까?
어시스턴트가 회의 후 작업을 정리할 때 제안, 결정, 약속의 차이를 유지하고, 산출물, 담당자, 기한을 명확히 한 뒤, 확인된 사항을 팀이 실제로 사용하는 시스템으로 전달하도록 합니다.

AI가 생성한 개념 삽화이며, 내용은 가상의 예시입니다.
고객 회의가 끝난 후, 어시스턴트가 세 가지 실행 항목을 정리했다고 가정해 봅시다. 금요일까지 새 버전 제안서 전달, 샤오린이 견적 담당, 다음 주 데모 일정 잡기. 회의록만 보면 명확해 보이고, 각 항목에 담당자와 날짜가 있는 것처럼 보입니다.
하지만 회의 기록으로 돌아가 보면, 고객은 “금요일에 먼저 한 버전 볼 수 있을까요?”라고 물었고, 샤오린은 “영업팀에 가서 가격을 확인해 볼게요”라고 말했으며, 데모는 고객이 테스트 데이터를 준비한 후에야 가능합니다.
이 세 가지를 그대로 작업 시스템에 입력하면, 팀에는 아직 수락되지 않은 약속이 몇 개 생깁니다. 금요일이 되면 고객은 제안서를 기다리고, 샤오린은 견적 독촉을 받고, 데모 초대장도 이미 발송됩니다. 회의에 남아 있던 불확실성이 정리 과정에서 사라진 것입니다.
회의 후 인계는 이러한 차이를 유지해야 합니다. 어시스턴트는 할 일을 추출하고, 맥락을 보충하고, 작성을 준비할 수 있지만, 각 작업은 무엇이 확정되었고, 무엇을 누가 결정해야 하는지 설명해야 합니다.
제안, 결정, 약속을 구분하기
“다른 견적 방식을 시도해 볼 수 있다”는 제안입니다. “이번에는 월별 견적을 사용한다”는 결정입니다. “목요일에 견적서를 보내드리겠습니다”는 구체적인 약속을 포함합니다. 세 문장 모두 견적과 관련이 있지만 후속 처리는 다릅니다. 제안은 누군가의 채택을 기다리고, 결정은 이미 효력이 발생했으며, 약속은 상대방에게 예측 가능한 의무를 부여합니다.
회의 후 정리에서 세 가지를 모두 “실행 항목”으로 쓰면 이 구분이 사라집니다. Lindy의 회의록 작성 가이드와 Viktor의 당일 회의 후속 조치 완료는 각각 회의록 작성법과 앱 간 후속 조치 측면에서 회의 후 작업을 다루지만, 한 문장이 어떤 합의를 형성했는지는 여전히 별도로 판단해야 합니다.
판단 근거는 자료에 이미 있는 증거입니다. 누군가 채택했는지, 승인을 거쳤는지, 약속한 사람이 직접 말했는지, 시간이 지정되었는지. 이러한 근거를 찾을 수 없으면 제안 또는 확인 대기로 처리합니다.
앞서 가정한 회의의 경우 다음과 같이 정리할 수 있습니다.
| 회의에서의 표현 | 현재 확정할 수 있는 내용 | 여전히 확인해야 할 내용 |
|---|---|---|
| 고객이 “금요일에 먼저 한 버전 볼 수 있을까요?”라고 물음 | 고객은 금요일에 초안을 보고 싶어 함 | 팀이 수락하는지, 초안에 무엇이 포함되는지 |
| 샤오린이 “영업팀에 가서 가격을 확인해 볼게요”라고 말함 | 샤오린이 가격 문의 작업을 맡음 | 언제 피드백할지, 누가 최종 견적을 결정하는지 |
| ”테스트 데이터가 준비되면 데모를 하자” | 데모에는 선행 조건이 있음 | 누가 데이터 준비를 확인하고, 이후 어떻게 일정을 잡을지 |
정리할 때 관련 원문과 출처 위치를 유지합니다. 전사 단락을 찾을 수 있으면 단락을 첨부하고, 원본 자료에 타임스탬프가 있으면 타임스탬프를 유지합니다. 화자를 명확히 식별할 수 없으면 확인 필요로 표시하고, 발언 내용을 바탕으로 이름을 추측하지 않습니다.
담당자가 없는 할 일은 일단 확인 대기 영역에 남겨둘 수 있습니다. 표의 모든 필드를 채우는 것이 인계를 더 완전하게 만드는 것은 아닙니다.
담당자는 실제로 맡은 작업과 일치해야 함
샤오린이 가격 문의를 약속했으므로 “영업팀에 가격 확인”을 샤오린에게 맡길 수 있습니다. 여기서 그가 견적 작성, 할인 승인, 고객 발송을 담당한다고 추론하면 원래 약속이 확대됩니다.
한 사람이 문제를 소개했다고 해서 그가 문제 해결 작업을 맡은 것은 아닙니다. 직책, 발언 횟수, 과거 역할 분담은 누구에게 물어봐야 할지 찾는 데 도움이 될 수 있지만, 이번 배정의 근거로 직접 사용해서는 안 됩니다. 팀에 이미 명확한 배정 규칙이 있다면 어시스턴트가 규칙에 따라 배정을 제안하고 근거를 설명할 수 있습니다.
산출물은 담당자가 판단할 수 있을 정도로 구체적으로 써야 합니다. “견적 후속 조치”는 해석의 여지가 너무 많습니다. “영업팀에 두 가지 방안의 가격을 확인하고, 결과를 견적 초안에 반영”이라고 해야 무엇을 해야 하는지 설명됩니다. 고객에게 발송하는 것이 포함되는지는 별도로 명확히 해야 합니다.
날짜도 마찬가지입니다. 고객이 제시한 희망 시간, 팀이 수락한 마감 시간, 다음 진행 상황 점검 시간은 각각 다른 의미를 가집니다. 회의에서 “가능한 한 빨리”라고만 했다면 미정으로 유지하고, 어시스턴트는 확인용 날짜를 제안할 수 있지만 제안을 회의에서 통과된 일정으로 작성해서는 안 됩니다.
확인을 요청할 때는 아직 결정되지 않은 부분만 질문하기
전체 회의록을 담당자에게 보내고 “확인 부탁드립니다”라고 덧붙이면, 상대방은 여전히 모든 의문점을 스스로 찾아야 합니다. 더 유용한 인계는 질문을 구체적인 사항에 맞춥니다.
예를 들어, 어시스턴트는 다음과 같은 확인 요청을 준비할 수 있습니다. 아래 내용은 여전히 가상의 예시입니다.
고객은 금요일에 제안서 초안을 받기를 원하지만, 회의에서 팀이 해당 날짜를 수락했다는 기록은 찾지 못했습니다. 프로젝트 책임자는 이 날짜를 수락할지, 그리고 이 버전에 무엇이 포함되어야 하는지 확인해 주세요.
샤오린은 영업팀에 가격을 문의하기로 했지만 피드백 시간은 정해지지 않았습니다. 샤오린은 예상 피드백 시간을 보충해 주세요.
데모는 고객이 테스트 데이터를 제공할 때까지 기다려야 하므로, 캘린더 초대는 아직 생성하지 않습니다. 누가 데이터 준비 여부를 확인할지 확인해 주세요.
세 가지 질문은 각각 답할 수 있는 사람에게 전달됩니다. 이미 확인된 사항은 함께 기다릴 필요가 없고, 아직 조건이 부족한 사항은 원래 상태로 유지합니다. 이렇게 하면 한 번의 답변으로 명확한 공백 하나를 해결할 수 있습니다.
확인은 그 당시의 해당 버전 내용에만 유효합니다. 책임자가 “금요일에 초안 제공”에 동의한 후, 산출물이 나중에 “전체 제안서와 견적”으로 확대되면 이 답변은 추가된 범위를 포괄할 수 없습니다. 변경된 부분은 다시 확인해야 하고, 나머지는 여전히 유효합니다.
작업을 담당자가 실제로 사용하는 곳에 작성하기
회의 문서는 논의 근거를 보관하고, 작업 시스템은 역할 분담을 담당하며, 외부 이메일은 이미 확인된 일정을 설명합니다. 세 가지는 서로 연결되고 각자 필요한 정보를 보관합니다.
인계에 적합한 작업은 일반적으로 산출물, 담당자, 확인된 기한 또는 선행 조건, 관련 회의 기록을 포함합니다. 담당자는 링크를 따라 합의의 근거를 찾을 수 있어야 하며, 전체 회의를 다시 읽지 않고도 시작할 수 있어야 합니다.
작성하기 전에 이 사항에 이미 작업이 있는지 확인합니다. 이번 주 회의는 지난주 사항에 날짜만 추가한 것일 수 있습니다. 같은 이름의 할 일을 또 만들면 진행 상황이 두 곳에 분산됩니다. 어시스턴트는 기존 작업과 소속 프로젝트를 확인하고 업데이트 제안을 해야 합니다. 같은 사항인지 판단할 수 없으면 후보 기록을 책임자에게 확인 요청합니다.
외부 이메일은 별도로 정리해야 합니다. 내부에서 논의 중인 할인, 아직 승인되지 않은 납품 날짜는 같은 회의록에 있다는 이유로 고객 회신에 포함되어서는 안 됩니다. 이메일 초안은 이미 외부 전달이 허용된 내용만 표현하고, 내부 할 일은 해당 작업 공간에 남깁니다.
작업이 생성된 후에는 위치와 배정 상황을 보고할 수 있습니다. 담당자 필드는 배정만 의미하며, 상대방이 이미 알고 있거나 시작했음을 의미하지 않습니다. 상대방이 맡았는지는 팀에서 합의한 확인 방식에 따릅니다.
OOMOL로 회의 자료와 작업 시스템 연결하기
이번 인계에서 어시스턴트는 두 가지 일을 해야 합니다. 회의 기록과 기존 작업에서 읽고, 작업 시스템과 이메일에 씁니다. 읽는 부분은 제안과 약속을 구분할 수 있는지 결정하고, 쓰는 부분은 오판이 다른 사람에게 직접 영향을 미칠지 결정합니다.
OOMOL의 Connector SDK는 연결된 앱 계정을 호출하는 경로를 제공합니다. 먼저 Connections에서 회의 기록을 보관하는 앱과 팀의 작업 도구를 연결하세요. 연결하기 전에 각 앱이 필요한 읽기, 조회, 생성, 업데이트 작업을 제공하는지 확인합니다. 회의 전사는 기존 회의 도구가 계속 제공하며, 앱 연결이 OOMOL이 회의를 녹음하거나 화자를 식별한다는 의미는 아닙니다.
양쪽을 분리하여 출시하는 것이 좋습니다. 먼저 읽기만 연결하여 어시스턴트가 인계 초안을 정리하도록 합니다. 제안과 약속을 구분하는 것이 예상대로 작동하는지 확인한 후, 권한 제어 가이드에 따라 작업 생성, 메시지 전송 등의 쓰기 작업을 활성화하고 대상 계정, 프로젝트, 수신자, 최종 내용을 확인합니다.
앱 연결은 읽기/쓰기 기능을 제공하지만, 제안과 약속의 구분, 담당자 매칭, 확인 기록, 작업 연결은 여전히 어시스턴트 지시 또는 비즈니스 프로세스로 구현해야 하며, 구체적인 규칙은 팀의 실제 방식에 따라 구성합니다.
한 회의의 인계 초안부터 시작하기
이미 끝났고 원본 기록을 확인할 수 있는 회의를 선택하고, 범위를 이번 논의와 해당 프로젝트로 제한합니다. 필요한 앱이 이미 연결된 어시스턴트에게 다음 요청을 처리하게 합니다.
이 회의 기록을 바탕으로 확정된 결정, 명확히 맡은 작업, 확인 대기 사항을 정리해 주세요. 각 작업에는 산출물, 담당자, 기한 또는 선행 조건을 명확히 쓰고 출처를 첨부하세요. 근거가 없는 필드는 미정으로 유지합니다. 지정된 프로젝트에서 이미 있는 관련 작업을 찾아 각각 추가 또는 업데이트 제안을 해 주세요. 먼저 인계 초안을 저에게 주고, 작업을 생성하거나 메시지를 보내지 마세요. 확인이 필요한 곳에는 구체적인 질문과 답변하기 적합한 사람을 적어 주세요.
검토할 때 세 가지를 중점적으로 확인합니다. 고객의 바람이 팀의 약속으로 작성되지 않았는지, 질문한 사람이 담당자로 배정되지 않았는지, 조건이 아직 충족되지 않은 사항이 미리 일정에 잡히지 않았는지.
확인 후 어시스턴트가 해당 사항을 대상 시스템에 작성하고 실제 작업 링크와 아직 결정되지 않은 내용을 반환하게 합니다. 다음 담당자가 작업을 열면 자신이 무엇을 약속했고, 무엇을 납품해야 하며, 아직 이행되지 않은 조건이 무엇인지 알 수 있습니다.