AI 회의록이 일을 줄이기는커녕 늘리는 순간

회의록은 빨리 생겼지만 할 일이 더 늘었다

예를 들어 다음과 같은 상황이 생길 수 있다. 회의가 끝나면 요약이 도착한다. 업무 도구에는 담당자와 마감일이 붙은 새 작업이 생긴다. 처음에는 후속 업무가 빠지지 않는 것처럼 보인다. 그런데 팀원이 “이건 해보기로 한 적이 없다”고 말한다. 누군가는 아이디어를 냈을 뿐이고, 누군가는 다른 팀에 가능 여부를 물어보겠다고 했을 뿐이다. AI가 모호한 대화를 실행 약속으로 바꾸면 회의록 자동화는 일을 줄이기 전에 일을 만든다.

Reddit의 한 자동화 구축자는 회의가 끝난 뒤 실제 결정·열린 질문·누가 무엇을 하기로 했는지를 추출해 기존 프로젝트 도구에 넣는 흐름을 만들었다고 밝혔다. 통화 후 약 1~2분에 실행되지만 구축에는 약 하루 반이 걸렸고, 그중 많은 시간을 합의하지 않은 작업이 생기지 않도록 조정하는 데 썼다고 설명했다. 처음에는 지나치게 적극적으로 작업을 만들어 불필요한 항목이 늘었다고 했다.

다른 병목도 있다. Threads의 leeannobm은 AI가 회의록을 써주는 것은 도움이 되지만 그 안에서 실행 항목을 찾는 데 다시 20분이 든다고 밝혔다. 문서 작성은 빨라졌는데 담당자가 어디부터 행동해야 하는지 읽어내는 일이 남은 사례다.

두 사례가 가리키는 문제는 다르다. 하나는 없는 작업의 생성이고 다른 하나는 있는 작업을 찾는 후처리다. 실무에서는 짧은 요약, 결정 사항, 확인이 필요한 질문, 실제 실행 약속을 나누어 출력해야 한다. 회의 내용을 보기 좋게 줄이는 기능만으로는 후속 업무가 끝나지 않는다.

‘좋은 생각’과 ‘이번 주에 한다’를 다른 목록에 둔다

회의에서는 가능한 방법을 떠올리고, 선택지를 비교하고, 누가 할지 정한다. 이 과정의 문장이 모두 같은 무게를 갖지는 않는다. “다음에 고객에게 물어보면 좋겠다”는 제안이고 “내가 수요일까지 고객에게 확인해 공유하겠다”는 실행 약속이다. “A안으로 진행한다”는 결정이지만 실행 담당자가 정해지지 않았다면 바로 개인의 할 일로 바뀌지는 않는다.

업무에 적용할 때는 결과를 종류별로 나누는 방식이 유용하다. 결정 사항에는 합의한 방향을, 아이디어에는 아직 채택하지 않은 제안을, 실행 항목에는 수행할 행동과 책임을 남긴다. 미해결 질문은 답이 필요한 대상으로 따로 표시한다. 이 구분을 하지 않고 모든 동사를 ‘할 일’로 추출하면 논의 과정까지 작업 목록에 들어간다.

위 문장들은 특정 회의의 인용이 아니라 구분 기준을 보여주는 예시다. 실제 팀의 기준은 더 세밀할 수 있다. 다만 “업무로 등록할 수 있는가”를 문장의 자연스러움으로 결정해서는 안 된다. 회의에서 합의한 행동인지, 아직 검토 중인 선택지인지가 기준이다.

회의 후 자동화에 관한 Reddit 토론에서도 질문자는 브레인스토밍한 미래 아이디어와 당장 해야 할 일을 다른 데이터베이스에 보관하고 싶다고 했다. 댓글들은 분류 단계를 거쳐 출력 위치를 나누는 방식을 제안했다. 아이디어를 보관하는 것과 누군가의 일정에 넣는 것은 다른 처리다.

담당자와 기한의 빈칸을 AI가 채우게 하지 않는다

할 일 목록은 빈칸이 없어야 깔끔해 보인다. 이 때문에 AI에 “담당자와 마감일까지 붙여 달라”고 요청하기 쉽다. 그러나 회의에서 말하지 않은 담당자를 채우면 책임이 새로 배정되고, 말하지 않은 날짜를 채우면 약속이 새로 생긴다. 정보 추출을 요청했는데 업무 배정까지 넘어가는 순간이다.

실무에서는 행동 자체가 합의됐는지와 담당자·기한이 정해졌는지를 따로 기록해야 한다. “가격표를 갱신한다”는 합의가 있어도 누구에게 맡길지 정하지 않았으면 담당 미정이다. 담당자가 정해져도 날짜를 말하지 않았다면 기한 미정이다. 날짜 없는 실행 항목을 모두 지우면 실제 합의를 놓치고, 날짜를 만들어 넣으면 없는 약속을 추가한다.

앞선 Reddit 토론의 댓글 작성자는 날짜가 나오지 않았을 때 추측하지 말고 표시하라고 제안했다. 이 제안은 기한 없는 항목을 확인 대상으로 남기는 기준으로 활용할 수 있다. 팀의 실제 운영에서는 기한이 없는 작업도 존재하므로 모든 빈칸을 같은 오류로 처리하기보다 확정된 정보와 추가 결정이 필요한 정보를 구분해야 한다.

상대 날짜도 확인이 필요하다. 화요일 회의에서 말한 “다음 금요일”을 어떤 날짜로 해석할지, 녹음 파일이 늦게 들어왔을 때 회의일과 처리일 가운데 어느 쪽을 기준으로 삼을지 정한다. AI가 처리한 오늘을 기준으로 날짜를 채우면 이미 지났거나 다른 주의 마감일이 생길 수 있다.

업무 등록 양식에는 행동, 담당자, 기한 외에 확인 상태를 두는 편이 좋다. 확인 대기인 후보는 담당자에게 통지할 수 있지만 확정 작업과 같은 알림을 보내지 않는다. 담당자가 “내가 맡은 일이 맞다”고 확인하면 확정으로 바꾼다. 자동화가 빠르게 만들수록 이 상태 차이를 표시하는 일이 중요해진다.

작업마다 어떤 발언에서 나왔는지 돌아갈 길이 있어야 한다

잘 쓴 한 줄 요약만 있으면 누가 어떤 맥락에서 말했는지 사라질 수 있다. “견적 검토”라는 작업에는 견적서를 새로 만들라는 뜻과 기존 견적에서 가격을 확인하라는 뜻이 섞일 수 있다. 모호한 항목을 확인할 때 회의록 전체를 처음부터 읽게 하면 자동화가 덜어준 시간이 다시 들어간다.

업무에 적용할 때는 회의 날짜, 회의록 링크, 해당 발언이나 위치를 실행 항목에 함께 붙인다. 원 발언에는 조건도 포함해야 한다. “고객이 승인하면 다음 주에 진행한다”에서 고객 승인 조건을 빼면 아직 시작하면 안 되는 일이 즉시 작업이 된다. 짧게 쓰는 과정에서 조건을 지우지 않는 것이 중요하다.

Notion의 AI Meeting Notes는 회의 내용에서 핵심과 실행 항목을 식별하는 기능을 설명한다. 이 기능을 실제 팀 업무에 연결할 때도 식별된 실행 항목이 현재 회의에서 나온 것인지 확인해야 한다. 회의록을 여러 개 함께 검색하는 흐름이라면 이번 회의의 범위를 명시해야 과거에 이미 끝난 작업이 새 작업으로 들어오는 일을 줄일 수 있다.

Google Meet의 회의 요약 안내는 연결 문제 등으로 요약이 불완전하거나 부정확할 수 있다고 설명한다. 요약에 특정 항목이 없다는 이유만으로 회의에서 논의하지 않았다고 판단하면 안 된다. 중요한 결정과 실행 약속은 원 발언을 찾아 확인하는 절차가 필요하다.

출력에 원본 연결을 남기는 이유는 AI의 표현을 길게 검사하려는 것이 아니다. 팀원이 자신의 할 일을 이해하고, 다르게 기억하는 내용이 나왔을 때 같은 근거를 보고 합의하기 위해서다. 결과 문장만 전송하는 방식보다 업무를 수정하고 되짚는 시간이 짧아진다.

Notion에 넣었다는 사실과 업무가 확정됐다는 사실을 분리한다

회의록에서 실행 항목을 추출한 뒤 바로 업무 도구에 생성하면 등록은 빠르다. 하지만 같은 회의 파일을 다시 처리하거나 요약을 수정할 때 작업이 또 생길 수 있다. 한 항목이 문장만 조금 달라진 채 두 번 등록되면 두 사람이 같은 일을 하거나 완료한 일을 다시 하게 된다.

실무에서는 회의와 실행 항목을 식별할 값을 보관하고, 재처리 때 기존 항목을 먼저 조회해야 한다. 문장이 같다는 이유만으로 무조건 합치거나 다르다는 이유만으로 새로 만들지 않는다. 같은 행동을 두 회의에서 언급한 것인지, 실제로 범위가 바뀐 것인지 확인한다. 날짜나 담당자가 변경됐으면 새로운 작업보다 기존 작업의 변경으로 다룰 수 있다.

이 표는 팀에 적용하기 위한 처리 순서다. API 호출이 성공했다는 표시만 받는 대신 저장된 항목을 다시 확인하는 데까지 이어야 한다. Notion API는 블록을 식별자로 조회하는 기능을 제공한다. 실제 연동에서는 대상 도구에 맞춰 생성된 항목의 내용과 위치를 다시 확인하는 흐름을 둘 수 있다.

등록에 실패했을 때도 회의록 생성과 업무 등록을 같은 성공으로 표시하면 안 된다. 문서는 만들어졌지만 작업 세 개 중 하나가 실패했다면 그 하나를 다시 처리해야 한다. n8n의 오류 처리 기능처럼 실행 실패를 따로 받는 흐름을 사용하면 실패 항목을 담당자가 확인할 수 있다.

회의가 끝난 직후에는 문장보다 약속을 확인한다

검토 요청이 다음 날 도착하면 참석자는 회의에서 어디까지 합의했는지 다시 떠올려야 한다. 앞선 Reddit 토론의 한 사용자는 회의 종료 후 5분 안에 행동 목록을 받아 아직 내용을 기억할 때 확인하는 방식이 유용했다고 밝혔다. 이 시간은 모든 팀의 의무 기준이 아니라 해당 사용자의 운영 경험이다.

팀에서 검토할 때는 오탈자보다 세 가지를 먼저 본다. 합의하지 않은 일이 들어왔는지, 합의한 일이 빠졌는지, 조건·담당자·기한이 달라졌는지다. 자연스럽게 다듬어진 문장일수록 빈 정보를 새로 채웠는지 주의해서 읽어야 한다. 참석자들이 같은 작업을 다른 표현으로 적었을 때도 무엇을 끝내야 하는지 동일한지 확인한다.

초안까지만 자동화한 운영 사례도 있다. Threads의 kimddol3는 3개월 운영한 파이프라인에서 회의 종료 후 5분 안에 초안이 나온다고 밝혔다. 작성자가 설명한 범위는 초안 생성이다. 이 구조를 팀에 적용하면 AI가 모든 약속을 확정하는 대신 확인할 후보를 빨리 제시하도록 사용할 수 있다.

검토 부담을 줄이려면 후보 전체를 장문의 회의록 속에 숨기지 않는다. 확정 가능 항목과 미정 항목을 나란히 보여주고 원본으로 이동할 링크를 붙인다. 담당자가 빈칸을 정하거나 항목을 제거한 결과는 다음 등록에 반영해야 한다. 승인 전 내용과 승인 후 내용이 섞이지 않도록 기록을 남긴다.

성과는 생성한 작업 수가 아니라 후속 업무가 이어졌는지다

실행 항목이 많아졌다는 사실은 좋은 회의록의 증거가 아니다. 새 작업을 많이 만드는 자동화는 처음에는 빈틈없이 보이지만 합의하지 않은 일을 처리하는 수정 비용을 만들 수 있다. 실무에서는 생성 건수와 함께 승인된 항목, 삭제한 후보, 누락해 추가한 항목, 중복으로 합친 항목을 본다.

처음 도입할 때는 한 종류의 정기회의에서 후보 추출과 확인만 연결하는 편이 좋다. 팀이 분류 기준에 익숙해지고 기존 작업과의 연결이 안정되면 등록 단계를 붙인다. 모든 회의의 모든 발언을 처리하기보다 입력과 출력이 일정한 회의부터 시작해야 수정할 기준도 분명해진다.

회의록 자동화가 끝났다는 기준은 회의록이 생겼다는 데 있지 않다. 실제로 합의한 행동이 올바른 담당자의 기존 업무 공간에 들어가고, 기한이 미정이면 미정으로 남으며, 원 발언으로 돌아갈 수 있어야 한다. 아이디어는 남겨두되 아직 약속하지 않은 일을 업무로 만들지 않아야 한다.

자주 묻는 질문