화자 분리(Speaker Diarization) 2026 — pyannote 구축과 Whisper 결합

# 화자 분리(Speaker Diarization) 2026 — pyannote 구축과 Whisper 결합

화자 분리란 무엇인가 — 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 수치는 찾기 어렵다. 자체 데이터로 측정해 보고 판단하는 것이 안전하다. 위 벤치마크는 영어권 데이터셋 기준이라는 점을 감안해야 한다.

자체 구축 vs 상용 API

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

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

실무에서 자주 막히는 지점

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

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

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

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

FAQ

Whisper 없이 화자 분리만 쓸 수 있나요?

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

실시간으로 되나요?

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

GPU 없이 돌릴 수 있나요?

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

전사와 화자 분리 중 무엇을 먼저 해야 하나요?

어느 쪽이든 된다. 다만 단어 단위 타임스탬프를 지원하는 전사 도구를 쓰면 정렬 정확도가 올라간다. 문장 단위 타임스탬프만 있으면 화자가 바뀌는 지점이 문장 중간일 때 어긋난다.

정리

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

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