화자 분리 Whisper에 붙이기 2026 — pyannote 구축과 DER 17% 읽는 법

화자 분리란 무엇인가 — 3줄 요약

"누가 언제 말했는지"를 구간으로 나누는 작업이다. 음성을 텍스트로 바꾸는 전사(STT)와는 다른 문제이고, 그래서 다른 모델이 필요하다.

Whisper를 돌리면 이런 결과가 나온다.

그러면 그 일정은 다음 주로 미루겠습니다 확인했습니다 예산은 어떻게 하죠

회의록으로 쓰려면 이렇게 되어야 한다.

[화자 A] 그러면 그 일정은 다음 주로 미루겠습니다.
[화자 B] 확인했습니다. 예산은 어떻게 하죠?

이 차이를 만드는 것이 화자 분리다.

왜 Whisper만으로는 안 되는가

Whisper는 음성 인식 모델이다. 소리를 글자로 옮기는 데 최적화돼 있고, 목소리의 주인을 구분하도록 학습되지 않았다. 화자 정보를 출력하지 않는 것은 결함이 아니라 설계 범위 밖이다.

그래서 회의록 파이프라인은 두 단계가 된다.

1. 화자 분리 — 오디오를 "0:00–0:12 화자 A, 0:12–0:20 화자 B" 같은 구간으로 자른다
2. 전사 — 각 구간을 텍스트로 옮긴다
3. 정렬 — 두 결과를 시각 기준으로 합친다

순서를 바꿔도 된다. 전사를 먼저 하고 단어별 타임스탬프에 화자 구간을 겹쳐도 결과는 같다. 중요한 것은 두 모델의 출력이 같은 시간축 위에 있어야 한다는 점이다.

pyannote.audio — 사실상의 표준

pyannote.audio는 PyTorch 기반 오픈소스 화자 분리 툴킷이다. MIT 라이선스이며 GitHub 스타 10.4k를 기록하고 있다.

파이프라인은 두 가지가 제공된다.

공개된 벤치마크는 다음과 같다. DER(Diarization Error Rate)은 낮을수록 좋다.

DER 17%는 "10분 중 1분 40초는 화자가 틀린다"는 뜻이다. 회의록 초안으로는 충분하지만 그대로 배포할 수준은 아니다. 사람이 훑어보는 단계를 전제로 설계해야 한다.

실행에는 ffmpeg가 필요하고, community-1은 HuggingFace에서 모델 라이선스에 동의한 뒤 토큰을 발급받아야 한다. GPU는 필수는 아니지만 CPU만으로는 실용적인 속도가 나오지 않는다.

DER 을 읽는 법 — 17% 가 무슨 뜻인가

화자 분리 성능은 DER(Diarization Error Rate) 로 보고된다. 벤치마크에서 「DER 17%」를 보고 「83% 맞다」로 읽으면 안 된다. DER 은 세 종류의 오류를 합친 값이고, 어느 쪽이 큰지에 따라 처방이 완전히 다르다.

DER = (Miss + False Alarm + Confusion) / 전체 발화 시간

세 번째가 업무에서 가장 아프다. Miss·False Alarm 은 구간이 어긋나는 것이라 텍스트를 읽으면 사람이 보정할 수 있지만, Confusion 은 A 가 한 말이 B 의 말로 기록된다. 콜센터 통화에서 상담원 발언이 고객 발언으로 붙으면 그 데이터는 쓸 수 없다.

그래서 보고서에 DER 총합만 적혀 있으면 반쪽이다. 세 성분을 나눠 받아야 어디를 고칠지 알 수 있다.

같은 음원인데 DER 이 달라지는 이유

측정 설정이 숫자를 바꾼다. 조건을 안 밝힌 DER 은 비교할 수 없다.

논문·벤치마크 수치는 대개 collar 0.25초 + 오버랩 제외다. 우리 음원에 그대로 적용하면 숫자가 올라간다. 그래서 견적 비교나 검수 기준을 세울 때는 collar 와 오버랩 포함 여부를 과업에 명시하고, 같은 설정으로 측정하게 해야 한다.

업무 관점의 합격선

DER 을 몇 %로 잡을지는 용도가 정한다.

화자 수가 적을수록 쉽다. 2인 통화는 10~15%가 현실적이고, 5인 이상 회의는 25%도 잘 나온 값이다. 「DER 10% 이하」를 다자 회의에 걸면 성립하지 않는 과업이 된다.

한국어에서는 어떤가

화자 분리는 전사보다 언어 의존이 낮다. 목소리의 음향적 특징(성문, 피치, 발화 스타일)으로 구분하기 때문에, 무슨 언어로 말하는지는 상대적으로 덜 중요하다. 영어 데이터로 학습한 모델이 한국어 회의에서도 비슷하게 동작하는 이유다.

다만 한국어 회의 환경 특유의 조건이 정확도를 떨어뜨린다.

• 맞장구가 잦다 — "네", "그렇죠", "아 예" 같은 짧은 발화가 겹치면 구간 경계가 흐려진다
• 겹쳐 말하기 — 두 사람이 동시에 말하는 구간은 어떤 모델에서도 오류율이 급등한다
• 호칭·직함으로 부른다 — "부장님", "김 대리"처럼 이름 대신 직함을 쓰면, 화자 라벨을 실명에 매핑하는 후처리가 어려워진다
• 회의실 녹음 품질 — 노트북 마이크 하나로 원탁을 담으면 거리가 먼 화자의 음성이 뭉개진다

한국어 데이터셋 기준의 공개 DER 수치는 찾기 어렵다. 자체 데이터로 측정해 보고 판단하는 것이 안전하다. 위 벤치마크는 영어권 데이터셋 기준이라는 점을 감안해야 한다.

Whisper 와 붙이는 실제 경로 — 세 가지

Whisper 는 「무슨 말을 했는지」만 주고 화자 정보가 없다. pyannote 는 「언제 누가 말했는지」만 주고 내용이 없다. 둘을 합치는 방식이 세 가지이고 결과가 다르다.

경계 문제가 체감 품질을 가장 많이 좌우한다. 사후 정렬에서 가장 흔한 사고는 한 문장의 앞부분이 이전 화자에게 붙는 것이다. 「네, 그러면 제가 확인해 보겠습니다」에서 「네,」만 고객에게 붙고 나머지가 상담원에게 붙으면, 문장 단위로 집계할 때 두 건으로 세어진다.

그래서 단어 단위 타임스탬프로 정렬하는 쪽이 거의 항상 낫다. 단어마다 어느 구간에 들어가는지를 보고 다수결로 문장의 화자를 정하면 경계 오류가 크게 줄어든다.

처리 순서에서 자주 틀리는 것

마지막 줄이 맞는 이유는 둘 다 원본 전체를 봐야 제 성능이 나오기 때문이다. Whisper 는 문맥을 보고 받아쓰고, pyannote 는 전체 음원에서 화자 임베딩을 모아 비교한다. 잘라서 주면 둘 다 성능이 떨어진다.

화자 수를 모를 때 — 임베딩과 클러스터링

pyannote 가 화자를 가르는 원리는 음성 조각마다 화자 임베딩(목소리 특징 벡터)을 만들고, 비슷한 것끼리 묶는(클러스터링) 것이다. 그래서 「화자가 몇 명인가」를 아는지가 결과를 바꾼다.

2인 통화에서 화자 수를 지정하지 않는 것이 가장 흔한 낭비다. 콜센터 녹취는 거의 항상 2인인데 자동 추정으로 돌리면 잡음·보류 음악 구간이 제3의 화자로 잡힌다. 한 줄 설정으로 DER 이 눈에 띄게 내려간다.

반대로 같은 사람이 둘로 쪼개지는 경우도 있다. 전화 음질이 중간에 바뀌거나(스피커폰 전환), 목소리 톤이 크게 달라지면 임베딩이 멀어진다. 이때는 최소 화자 수를 고정하는 쪽이 낫다.

오버랩 — 동시에 말하면 무너진다

두 사람이 겹쳐 말하는 구간은 어느 모델에서도 가장 약하다. 그런데 한국어 회의·상담에서 겹침이 드물지 않다 — 맞장구·끼어들기가 많다.

세 번째가 압도적으로 싸다. 콜센터라면 상담원·고객을 스테레오 좌우 채널로 분리 녹음하면 화자 분리 자체가 필요 없어진다. 모델을 올리는 것보다 녹음 장비 설정을 확인하는 것이 먼저다.

네 번째는 하지 말 것 — 숫자를 좋게 만들지만 겹침 구간의 오류는 그대로 남는다. 검수 기준을 정할 때 겹침 포함 여부를 명시해야 하는 이유다.

자체 구축 vs 상용 API

분기 기준은 데이터 민감도다. 회의 내용이 외부로 나가면 안 되는 조직(금융·의료·법무·공공)이라면 자체 구축 외에 선택지가 없다. 반대로 데이터 반출에 제약이 없고 물량이 적다면 상용 API가 총비용에서 유리하다.

애매한 구간은 월 처리 시간이 수십 시간 이상인 경우다. 이때는 API 과금이 인프라 비용을 넘어서기 시작하므로 실제 물량으로 계산해 봐야 한다.

파이프라인 한 건을 끝까지 — 2인 통화 1,000건

전제 — 콜센터 통화 1,000건(평균 4분), 모노 녹음, 상담원 발언만 따로 집계하고 싶다.

1단계 — 녹음 설정을 먼저 본다

2단계 — 설정을 고정한다

3단계 — 어느 쪽이 상담원인지 정한다

화자 분리는 「A 와 B」를 가르지만 「누가 상담원인지」는 모른다. 이 매핑을 빠뜨리면 집계가 뒤집힌다. 쓸 수 있는 단서:

첫 발화자 + 고정 문구 둘을 같이 쓰는 것이 실무에서 가장 안정적이다. 하나만 쓰면 예외 통화에서 뒤집힌다.

4단계 — 검수 기준

발주처가 지정한 통화 50건(보류음악 포함·스피커폰 전환 포함 각 10% 이상) 샘플 기준으로

DER 15% 이하(collar 0.25초, 겹침 포함), Confusion 성분 5% 이하,

상담원·고객 매핑 정확도 98% 이상을 만족한다.

DER 세 성분(Miss·False Alarm·Confusion)을 분리해 보고하고, 겹침 검출 구간 목록을 제출한다.

Confusion 을 따로 거는 것이 핵심이다. DER 총합이 15%여도 Confusion 이 12%면 상담원 발언 집계가 틀어진다. 그리고 매핑 정확도를 별도 항목으로 둬야 한다 — 이건 DER 에 안 들어가는데 업무에서는 더 중요하다.

전사 쪽 검수 기준(CER·용어 사전)은 STT 도입 가이드에, 정확도를 판정 문장으로 만드는 일반 요령은 부하테스트 가이드에 정리했다.

5단계 — 이 건에서 틀리기 쉬운 것

실무에서 자주 막히는 지점

화자 수를 미리 알려주면 정확도가 오른다. 대부분의 파이프라인이 화자 수 힌트를 받는다. 4명 회의라는 걸 알면 모델이 4개로 나누려 하므로, 알 수 있다면 반드시 넘긴다.

라벨은 매번 바뀐다. "화자 A"가 같은 사람이라는 보장은 파일 하나 안에서만 유효하다. 여러 회의를 이어 붙이면 A가 다른 사람이 된다. 실명 매핑은 별도 작업이다.

짧은 발화는 잃는다. 1초 미만의 "네", "음" 같은 발화는 구간으로 잡히지 않거나 옆 화자에 흡수된다. 발언 횟수를 세는 용도라면 이 손실을 감안해야 한다.

후처리가 결과를 좌우한다. 모델 출력을 그대로 쓰기보다, 같은 화자의 인접 구간을 병합하고 너무 짧은 구간을 제거하는 정리를 거치면 읽을 만한 회의록이 된다.

FAQ

Whisper 없이 화자 분리만 쓸 수 있나요? 가능하다. 화자 분리 결과만으로도 "누가 얼마나 말했는지"는 알 수 있다. 발언 시간 비중 분석이 목적이라면 전사가 필요 없다.

실시간으로 되나요? pyannote의 기본 파이프라인은 파일 전체를 보고 처리하는 방식이라 실시간에 맞지 않는다. 실시간이 필요하면 스트리밍을 지원하는 별도 구성이 필요하고, 정확도는 떨어진다.

GPU 없이 돌릴 수 있나요? 동작은 하지만 실용적이지 않다. 1시간 오디오가 CPU에서는 매우 느리게 처리된다. 물량이 적다면 상용 API가 현실적이다.

전사와 화자 분리 중 무엇을 먼저 해야 하나요? 어느 쪽이든 된다. 다만 단어 단위 타임스탬프를 지원하는 전사 도구를 쓰면 정렬 정확도가 올라간다. 문장 단위 타임스탬프만 있으면 화자가 바뀌는 지점이 문장 중간일 때 어긋난다.

정리

회의록 자동화는 전사 하나로 끝나지 않는다. Whisper는 무슨 말인지를, pyannote는 누가 말했는지를 답한다. 둘을 같은 시간축에서 합쳐야 읽을 수 있는 회의록이 된다.

전사 쪽 구현체 선택과 로컬 파이프라인 구성은 한국어 STT 오픈소스 가이드에서, 상용 솔루션 비교는 STT 솔루션 유형 비교에서 다뤘다.

회의록 자동화는 전사·화자 분리·후처리가 하나의 파이프라인으로 엮여야 실무에 쓸 수 있습니다. 각 단계를 따로 붙이면 시간축이 어긋나 결과가 무너집니다.

트리숲은 AI-Native 개발 방식으로 음성·문서 처리 파이프라인을 구축해 왔습니다. 사내망 안에서만 도는 구성도 가능합니다.