AI 회의록에 사람의 검토 순서를 넣은 이유

처음 만든 회의록 상세 화면에는 회의 정보, 참석자 명단, 화자 대응, 보충 자료, 생성 결과, 녹취 원문을 한꺼번에 넣었습니다. 필요한 내용을 한곳에서 확인하게 한 구성이었습니다. 그런데 미리보기를 직접 본 뒤, 한 화면에서 한 가지씩 하도록 바꾸기로 했습니다.

녹취록을 가져온 사람에게 지금 필요한 것은 모든 입력칸이 아니었습니다. 먼저 파일이 제대로 읽혔는지 보고, 누가 한 말인지 확인하고, 잘못 적힌 내용을 고쳐야 했습니다. 저는 AI 회의록의 앞뒤에 이 검토 순서를 넣었습니다. 사람이 고친 내용이 다음 문서를 만들 때도 이어지게 하는 것이 중요했습니다.

이 글은 2026년 9월 22~23일 배포한 회의록 화면의 검토 흐름을 다룹니다.

한 번에 묻던 것을 나누기

새 흐름은 파일 선택, 분석 결과 확인, 화자와 원문 수정, 회의록 검토, 목적별 문서 만들기의 순서로 나눴습니다. 각 화면에서는 다음으로 할 일을 하나씩 보여주도록 했습니다.

중간에 닫아도 됩니다. 어디까지 했는지 저장하고 다시 열면 그 단계에서 이어가게 했습니다. 내부 공유용 문서만 필요한 사람에게는 공식 참석자 명단과 장소 같은 정보를 처음부터 모두 채우게 하지 않았습니다. 전자결재용 문서를 고르면 그때 필요한 정보를 묻는 방식입니다.

한 번에 받는 정보를 줄였다고 회의록을 확인할 책임까지 줄어드는 것은 아닙니다. 같은 확인을 하더라도, 무엇을 만들지 정해진 시점에 필요한 내용을 묻도록 순서를 바꾼 것입니다.

화자 번호를 이름으로 바꾸기 전에

아래는 흐름을 설명하려고 만든 가상의 독서 모임 회의입니다. 실제 회의의 발언을 옮긴 자료도, 프로그램을 실행해 얻은 출력도 아닙니다. 가상 인물 민서와 도윤이 다음 모임을 준비하는 상황으로 두겠습니다.

녹취에서 읽은 내용	사람이 확인할 내용
참석자 1이 자료 준비를 맡겠다고 말함	참석자 1이 민서인지 직접 확인
참석자 2가 토요일 오후를 제안함	도윤의 제안인지 확인하고 날짜가 확정된 것은 아닌지 구분
장소는 다음에 정하자는 발언이 있음	장소 미정 상태를 유지

녹취록의 ‘참석자 1’은 파일 안에서 발언을 묶는 표시입니다. 그 번호만으로 실제 이름을 알 수는 없습니다. 이전 회의에도 같은 번호가 있었다는 이유로 같은 사람이라고 채우면 다른 사람에게 발언이나 할 일을 붙일 수 있습니다.

그래서 화면에서는 화자 라벨과 발언 일부를 보고 사람이 이름을 입력하도록 했습니다. 이전 명단은 이름 후보를 찾는 데 쓰되, 번호와 이름을 자동으로 확정하지 않습니다. 이름을 모르면 라벨을 남겨둡니다. 빈 곳을 추측으로 채우는 것보다 확인되지 않았다는 상태가 보이는 편이 낫다고 판단했습니다.

명단에 들어가는 사람과 실제로 발언한 사람도 같지 않을 수 있습니다. 공식 문서의 참석자 정보는 전자결재용을 고른 뒤 따로 확인하게 했습니다. 음성에서 찾은 화자 목록을 참석자 명단 전체로 사용하지 않기 위해서입니다.

고친 녹취와 원본을 함께 남기기

녹취에는 잘못 적힌 이름이나 용어가 있을 수 있습니다. 이를 고칠 수 있게 하면서도 가져온 원본은 그대로 보존하기로 했습니다. 화면에서 바꾼 내용은 별도의 편집본으로 저장하고, 편집본이 있으면 회의록 생성에는 그 내용을 사용합니다.

예를 들어 설명용 녹취에 ‘발재 자료’라고 적혀 있고, 사람이 실제 뜻을 확인해 ‘발제 자료’로 고쳤다고 해보겠습니다. 다음 생성에는 고친 표현을 쓰되, 처음 받은 파일에서 무엇이 달라졌는지 확인할 길은 남아 있어야 합니다. 회의에서 하지 않은 말을 수정 과정에서 새로 넣지 않는 것도 사람의 확인 몫입니다.

편집본 역시 프로그램이 읽을 수 있는 녹취 형식을 유지해야 합니다. 시각이나 화자 줄을 잘못 바꿔 읽을 수 없게 되면 저장 오류를 보여주도록 했습니다. 문장만 매끄럽게 보인다고 처리에 필요한 구조까지 맞는 것은 아니기 때문입니다.

이렇게 원본과 편집본을 나누면 ‘왜 이런 회의록이 나왔는가’를 볼 때도 기준이 생깁니다. 처음 받은 녹취를 사용했는지, 사람이 고친 녹취를 사용했는지부터 확인할 수 있습니다.

사람이 고친 회의록을 다음 문서의 출발점으로

화자와 녹취를 확인한 뒤에는 AI가 만든 회의록 초안을 읽습니다. 이 단계의 문서를 기준 회의록으로 두었습니다. 사람이 여기서 고친 본문이 목적별 문서를 만드는 입력이 됩니다.

가상 독서 모임에서 도윤이 말한 토요일 오후는 제안입니다. 초안에 ‘다음 모임은 토요일 오후로 확정했다’고 적혔다면, 사람은 제안이었다는 점과 날짜가 아직 정해지지 않았다는 점을 고쳐야 합니다. 이 수정이 공유 문서에도 이어져야 같은 오류를 다시 확인하는 일을 줄일 수 있습니다.

처음의 설계에서는 기준 회의록의 손편집을 파생 문서에 반영하지 않는 방향도 있었습니다. 하지만 사람이 읽고 고친 내용을 다음 문서가 참고하지 않으면 검토가 중간에서 끊깁니다. 그래서 목적별 문서를 만들 때 저장된 기준 회의록의 현재 본문을 읽도록 바꿨습니다.

여기에는 선택에 따른 수고가 하나 더 있습니다. 내부 공유용 문서도 기준 회의록을 그대로 복사하는 대신 AI가 다시 정리하게 했습니다. 목적에 맞게 읽기 좋은 문서를 얻으려는 선택이지만, 사람이 고친 문장도 다시 바뀔 수 있습니다. 프로그램은 입력에 없던 수치와 문서 구조 등을 검사하지만, 이름과 문장의 의미는 사람이 한 번 더 읽어야 합니다.

검사가 통과했다고 ‘제안’이 ‘확정’으로 바뀌지 않았다고 보장할 수는 없습니다. 녹취의 시각을 찾았다는 사실도 그 발언이 해당 결론을 뒷받침한다는 뜻은 아닙니다. 검사 결과는 사람이 살펴볼 곳을 좁히는 데 사용합니다.

문서 목적은 검토 뒤에 고릅니다

같은 회의라도 읽는 사람이 달라지면 필요한 문서가 달라집니다. 함께 일한 사람에게 자세히 공유할 문서와, 공식적으로 결재를 올릴 문서를 나눴습니다. 전자결재용은 공식 회의록과 기안문을 각각 만드는 구성입니다.

문서	담으려는 내용	사람이 추가로 확인할 것
내부 공유용	논의 내용, 결정, 남은 일의 상세한 맥락	제안·확정·미정을 구분했는지
공식 회의록	공식 회의 정보와 참석 현황, 정리된 안건과 결과	명단·장소·회의명 등 공식 정보가 맞는지
기안문	회의 결과를 어떤 목적으로 보고하거나 결재받는지	보고 목적과 붙임 관계가 맞는지

가상 모임의 예에서는 자료 담당과 날짜 미정 상태가 공유 문서에도 유지되어야 합니다. 실제 결재용 문서를 만들 때는 여기에 필요한 공식 정보를 더하고, 사용하는 양식에 맞는지 별도로 확인합니다.

공유할 본문과 개인적으로 남길 메모도 분리했습니다. 본문 아래에 ‘비공개’라는 제목만 달아두고 나중에 잘라내는 방식은 사람이 제목을 고쳤을 때 흔들릴 수 있었습니다. 그래서 파일을 나누고, 공유용·결재용 문서를 만드는 단계에서는 비공개 메모 파일을 읽지 않도록 했습니다. 공개 본문에 민감한 내용을 잘못 넣지 않았는지는 여전히 검토해야 합니다.

문서를 한 번 만든 뒤에도 확인할 것이 있습니다. 녹취나 기준 회의록을 수정하면 전에 만든 공유용·결재용 문서는 옛 내용을 담고 있을 수 있습니다. 프로그램은 생성에 사용한 내용과 현재 내용이 달라졌는지 표시하도록 했습니다. 그러면 사람은 무엇을 다시 만들고 확인해야 하는지 알 수 있습니다.

검토가 다음 단계에 남도록

이 흐름은 9월 22~23일 서버에 배포한 회의록 화면에 반영했습니다. 단계별 화면과 편집·문서 생성 기능을 올린 상태이며, 실제 회의에서 수정 시간이 얼마나 줄었는지는 아직 측정하지 않았습니다. 문서 생성 이후의 상신과 최종 결재도 사람이 진행할 일로 남아 있습니다.

이번에 바꾼 것은 사람이 확인할 차례와 그 확인이 다음 문서에 전달되는 방식입니다. 화자와 녹취를 고치고, 기준 회의록을 읽고, 목적에 맞게 만든 결과를 다시 확인합니다. 사람이 고친 기준 회의록을 다음 문서를 만드는 입력으로 연결했습니다.

AI가 초안을 만들어주는 기능에 더해, 제가 고친 내용을 이어서 쓸 수 있는 흐름이 필요했습니다. 이 흐름에서 만든 문서를 업무 DB나 다른 기기의 위키에 연결하는 일은 별도 과제로 남아 있습니다. 이후 시스템 구조가 바뀌더라도, 무엇을 사람이 확인했고 다음 생성이 어느 본문을 읽었는지는 계속 구분해야 합니다.