
회의록 자동 작성 AI, 화자 분리가 두세 명을 스무 명으로 나눴습니다
화면에 찍힌 화자 수는 20이었습니다. 녹음 속 회의에는 두세 명이 앉아 있었습니다.
보험대리점(GA) 지사의 정산 회의 녹음 15분 35초를 처음 기계에 넣었을 때 일입니다.
기계는 그 회의를 스무 명이 돌아가며 한마디씩 한 대화로 받아 적었습니다. 이대로라면 누가 무엇을 맡았는지는 뽑을 수가 없습니다.
결국 손댄 곳은 녹음을 올릴 때 참석자를 체크하는 칸 하나였습니다.
참석자 명단 한 장이 화자 분리와 이름 후보, 할 일 담당자까지 어떻게 묶는지 차례로 보겠습니다.
점수 84%로 1등 한 모델이 실제 분리에서는 무너진 일도 적었습니다. 담당자 칸이 0건에서 6건으로 채워진 과정까지 실측으로 남겼습니다.
스무 명이 된 두세 명
화자 분리는 녹음을 잘게 자른 뒤 목소리가 닮은 조각끼리 묶는 작업입니다. 몇 묶음으로 나눌지는 기계가 스스로 추정합니다.
문제는 짧은 조각이었습니다. 1초도 안 되는 맞장구 조각은 목소리 특징이 흐리게 잡힙니다.
흐린 조각은 기존 묶음 어디에도 들어가지 못하고 새 화자가 됩니다. 그렇게 생긴 유령 화자가 쌓여 스무 명이 됐습니다.
자료를 찾아보니 이 과분할의 뿌리는 묶는 단계, 곧 클러스터링 쪽이었습니다.
묶음 수를 기계에 맡기는 한 같은 일이 되풀이됩니다. 그래서 묶음 수를 사람이 미리 정해 주기로 했습니다.
참석자 체크 한 칸
녹음을 올리는 화면에 참석자 체크 칸을 두었습니다. 체크한 사람 수가 그대로 화자 수가 됩니다.
이 샘플은 실제로 말한 목소리가 둘이었습니다. 목소리 모델까지 바꾼 뒤 화자 수를 2로 고정하자 띠가 두 색으로 모였습니다.
이 체크 칸은 화자 수 말고도 일을 더 합니다. 같은 참석자 명단을 뒤 단계에서도 다시 씁니다.
| 명단이 쓰이는 곳 | 하는 일 |
|---|---|
| 화자 이름 후보 | '화자 1'을 실제 사람으로 바꿀 때 고를 보기 |
| 할 일 담당자 후보 | 할 일마다 붙일 수 있는 사람의 범위 |
| 전사 용어사전 | 사람 이름을 받아쓰기 모델에 미리 알려 줌 |
업로드하는 사람이 30초쯤 들이는 입력입니다. 이 명단 하나로 화자 수와 이름 후보, 담당자 범위가 함께 정해집니다.
비슷한 목소리 두 사람
화자 수를 고정하자 이번에는 반대 문제가 나왔습니다. 두 사람이 한 명으로 뭉친 겁니다.
처음 쓴 목소리 특징 모델은 두 사람을 705초와 46초로 나눴습니다. 사실상 한 사람이 거의 다 말한 회의로 본 셈입니다.
목소리 특징 모델을 바꾸자 두 사람이 따로 잡혔고 분리가 일관되게 유지됐습니다.
여기서 한 번 더 헛걸음을 했습니다. 모델 네 종으로 '등록된 목소리 다시 알아보기' 점수를 비교했더니 한 모델이 84%로 1등이었습니다.
그 모델로 실제 화자 분리를 돌리자 다시 705초와 46초로 무너졌습니다. 그 뒤로 화자 분리 판정은 전사문을 눈으로 읽어서 합니다.
누가 한 말로 찍혔는지 문장마다 대조하는 방식입니다.
단어 단위로 화자가 튀는 문제도 있었습니다. 한 문장 한가운데 단어 하나만 다른 사람 말로 붙는 식입니다.
앞뒤 세 단어씩 보고 다수 쪽 화자로 맞추는 중앙값 스무딩을 넣었습니다. 그다음 1.2초 넘게 쉬거나 화자가 바뀌는 지점에서 발언을 끊었습니다.
점수가 더 좋다던 한국어 모델
받아쓰기 모델도 하나 걸러 냈습니다. 한국어로 따로 학습시켰다는 공개 모델이었습니다.
벤치마크 점수만 보면 기본 모델보다 나아 보였습니다. 같은 회의 녹음으로 A/B를 돌려 봤습니다.
| 비교 항목 | 기본 모델 | 한국어 학습 모델 |
|---|---|---|
| 받아 적은 단어 | 1,336개 | 752개 |
| 핵심 업무 용어 | 받아 적음 | 통째로 빠짐 |
| 판정 | 유지 | 기각 |
단어가 44% 빠졌습니다. 회의에 없던 말까지 지어냈습니다.
그 모델은 또박또박 읽는 낭독 음성으로 학습됐습니다. 말이 겹치고 끊기는 실제 회의에서는 버티지 못했습니다.
그래서 기본 모델을 유지했습니다. 반복 억제 설정과 용어사전을 붙인 상태입니다.
녹음에서 할 일 6건까지
전체 흐름은 받아쓰기, 화자 분리, 합치기, 회의록, 할 일 추출 순서입니다. 측정 환경은 GPU 없는 8코어 Ryzen 데스크톱 CPU 한 대였습니다.
| 단계 | 15분 35초 녹음 기준 |
|---|---|
| 받아쓰기 | 녹음 길이의 0.29배 (275초) |
| 화자 분리 | 녹음 길이의 0.73배 (682초) |
| 회의록·할 일 | 전사문을 받은 언어 모델이 작성 |
음성 처리 쪽은 오디오를 전사문으로 바꾸는 데서 멈춥니다. 회의록과 할 일은 다른 일꾼이 전사문만 받아서 씁니다.
이렇게 나눠 두니 하나를 바꿔도 다른 쪽이 흔들리지 않았습니다. 받아쓰기 모델을 바꿀 때 회의록 쪽은 손대지 않았습니다.
할 일 추출은 두 번 돌렸습니다. 화자 정보 없이 돌린 첫 판에서는 할 일 6건 모두 담당자 칸이 비어 있었습니다.
화자가 붙은 전사문으로 다시 돌리자 6건 모두 담당자가 잡혔습니다. 한 사람에게 2건, 다른 사람에게 4건이었습니다.
할 일마다 근거가 된 발언을 그대로 인용해 붙였습니다. 기한이 언급된 3건에는 회의 날짜 기준으로 날짜를 계산해 넣었습니다.
할 일을 저장하는 칸은 이미 쓰던 그룹웨어의 업무 기능을 그대로 쓰도록 설계했습니다. 새로 만들 부분은 업로드 화면과 검토 화면 쪽입니다.
그룹웨어 데모 첫 화면의 마감 임박 업무 목록이 추출된 할 일이 쌓이는 자리입니다.
끝내 사람이 확인하는 자리
화자 수를 맞춰도 이름까지 자동으로 붙지는 않습니다. 등록한 목소리로 사람을 다시 알아보는 정확도를 재 봤습니다.
전체 68%였습니다. 긴 발언은 77%, 짧은 발언은 47%로 찍기와 비슷했습니다.
이 녹음의 두 목소리는 비슷한 음색에 통화 음질이었습니다. 무료로 쓸 수 있는 목소리 모델을 바꿔 가며 시험했지만 이 벽은 넘지 못했습니다.
그래서 이름 붙이기는 검토 화면에서 사람이 확정하도록 했습니다. 기계는 후보를 미리 채워 두는 데까지만 합니다.
| 기계에 맡김 | 사람이 확정 |
|---|---|
| 받아쓰기 초안 | 사람 이름·금액 같은 고유명사와 숫자 |
| 화자 나누기 | 짧은 발언이 누구 말인지 |
| 할 일 후보와 근거 인용 | 담당자와 기한 |
고유명사 오류도 남았습니다. 이름 한 글자가 비슷한 소리로 바뀌는 식이었습니다.
나중에 다른 모델과 비교하다 빠진 구간도 하나 찾았습니다. 짧은 맞장구가 이어진 22초가 전사문에서 통째로 비어 있었습니다.
무음을 걸러 내는 단계와 그 뒤 받아쓰기 과정에서 짧은 맞장구가 빠진 탓이었습니다. 그 단계를 끄고 다시 돌리자 발언 9개가 돌아왔습니다.
다만 이 처방은 녹음 한 건으로만 확인했습니다. 침묵이 긴 회의에서 없는 말을 지어내지 않는지는 녹음을 더 모아 봐야 합니다.
녹음이 밖으로 나가지 않게
이 회의에는 인사와 수수료 이야기가 오갔습니다. 녹음 파일을 외부 변환 서비스에 올릴 수 없는 자료였습니다.
그래서 처음부터 사내 장비에서만 도는 구조로 설계했습니다. 측정 전 과정에서 녹음은 PC 밖으로 나가지 않았습니다.
받아쓰기는 상용 서비스에 크게 밀리지 않는다고 판단했지만 같은 녹음으로 직접 대조하지는 않았습니다. 화자 분리 쪽이 약한 곳이라 참석자 체크와 검토 화면으로 메웁니다.
지금 이 파이프라인은 운영 시스템에 넣지 않았습니다. 검증을 마친 자산으로 보존해 두고 있습니다.
들어가기 전에 정할 것이 남아 있기 때문입니다. 화자 분리를 돌릴 서버를 어디에 둘지, 녹음을 며칠 보관하고 지울지가 아직 미정입니다.
도입 전에 볼 판단표
회의록 AI를 들이기 전에 아래 질문에 먼저 답해 보세요. '아니오'가 나온 줄이 도입 전에 손봐야 할 자리입니다.
| 질문 | '아니오'라면 |
|---|---|
| 녹음을 외부 서비스로 보내도 되는 회의인가 | 사내 장비에서 도는 구조부터 검토하세요 |
| 업로드할 때 참석자를 입력할 수 있는가 | 화자가 과하게 쪼개질 각오를 하세요 |
| 모델을 우리 회의 녹음으로 A/B 했는가 | 벤치마크 점수를 믿지 말고 우리 녹음 한 건으로 비교하세요 |
| 회사 용어와 사람 이름을 용어사전에 넣었는가 | 고유명사 오류가 그대로 회의록에 남습니다 |
| 할 일 담당자를 사람이 확정하는 단계가 있는가 | 짧은 발언이 엉뚱한 사람 몫으로 갑니다 |
| 녹음 보관 기간을 정했는가 | 민감한 녹음이 서버에 계속 쌓입니다 |
직원들이 직접 녹음을 돌려 보며 이 표를 채워 보고 싶다면 회의록AI 교육 과정이 그 실습을 반나절에 다룹니다.
이미 쓰는 그룹웨어나 업무 도구에 업로드 화면과 검토 화면을 붙이는 일이라면 AI 자동화 상담에 회의 규모와 녹음 보관 조건을 먼저 알려 주세요.
이어서 읽기

사내 AI 챗봇 응답이 느릴 때, 범인은 AI가 아니었습니다
보험대리점 지사 시스템에 붙인 AI 비서가 '생각하는 중'으로 1~4분을 버텼습니다. 언어모델을 의심했지만 범인은 질문 단어마다 돌던 고객 검색이었고, 그걸 찾은 과정과 프롬프트 무게·스트리밍 처리, 다음 챗봇에 쓸 점검 순서까지 담았습니다.

사내 문서 AI 검색, 지식베이스 2,582건 중 90건만 들어갔습니다
보험대리점 지사 시스템의 AI 비서에 실무지식 2,582건을 넣었는데 실제로 들어간 건 90건이었고 오류는 하나도 없었습니다. 조용히 빠진 문서를 찾은 과정과 검색 노이즈를 걷어낸 기준, 도입 전 점검표를 적었습니다.

개인정보 유출 없이 AI 쓰기, 고객 이름 대신 '이 고객'으로 보냈습니다
고객관리 시스템에 AI 비서를 붙였는데 마스킹 함수는 어느 경로에서도 불리지 않고 있었습니다. 감사 기록을 먼저 남기고 실패하면 고객 정보를 붙이지 않는 구조로 고친 과정과 점검 순서를 적었습니다.