"누가 말했는지 헷갈리는 AI 회의록은 끝" Whisper 화자 분리 오류를 LLM으로 교정하는 실무 파이프라인

회의가 끝난 후 음성 녹음 파일을 OpenAI의 Whisper로 텍스트 변환(STT)해 본 적이 있다면, 그 놀라운 인식률에 감탄했을 것입니다. 하지만 감탄도 잠시, “누가 이 말을 했지?“를 구분하는 화자 분리(Speaker Diarization) 단계에 이르면 한계에 부딪힙니다.

오픈소스로 널리 쓰이는 PyAnnote 등 오디오 기반 화자 분리 라이브러리는 목소리의 주파수와 톤을 기준으로 사람을 구별합니다. 그러다 보니 마이크 상태가 나쁘거나, 목소리 톤이 비슷한 참가자가 있거나, 중간에 말을 끊고 끼어드는 상황이 발생하면 여지없이 화자가 뒤엉킵니다. “A팀장이 질문하고, 본인이 직접 대답한 것”처럼 기록된 엉터리 회의록을 일일이 손으로 수정하다 보면 “이럴 거면 차라리 받아쓰기를 직접 하고 말지”라는 탄식이 절로 나옵니다.

이 글에서는 오디오 기반 Whisper 화자 분리 기술의 물리적 한계를 인정하고, 이를 대규모 언어 모델(LLM)의 문맥 이해 능력을 통해 사후 교정(Post-processing)하는 하이브리드 자동화 파이프라인을 소개합니다.

1. 목소리만으로는 한계가 있다: 화자 분리가 실패하는 진짜 이유

흔히 Whisper만 돌리면 완벽한 회의록이 나올 것이라 기대하지만, 실제 비즈니스 미팅 환경은 그리 만만치 않습니다. 오디오 데이터 분석에만 의존하는 기존 화자 분리 기술(PyAnnote, MMS 등)이 실패하는 근본적인 원인은 크게 세 가지입니다.

결과적으로 Whisper가 텍스트는 99% 정확하게 뽑아내더라도, 화자 ID(Speaker 0, Speaker 1…)가 꼬여 흐름이 완전히 왜곡된 회의록이 탄생합니다.

2. 해결책: ’문맥’을 읽는 LLM 교정 파이프라인

이 문제를 해결하기 위해, 우리는 음성 주파수가 아닌 ’텍스트의 흐름(Context)’을 파악해 화자 오류를 바로잡는 LLM 파이프라인을 추가해야 합니다. 사람은 목소리가 안 들려도 대화의 맥락, 경어체 사용 여부, 이전 질문과의 연관성, 호칭 등을 보고 “아, 이 말은 김 대리가 한 거네”라고 직관적으로 파악할 수 있습니다. LLM에게 바로 이 역할을 맡기는 것입니다.

전체 자동화 아키텍처는 다음과 같이 설계됩니다.

[회의 오디오 파일]
       │
       ▼
[Step 1: Whisper (텍스트 추출)] ───► 각 발화의 정확한 타임스탬프와 대사 확보
       │
[Step 2: PyAnnote (화자 분리)] ───► 시간대별 임시 화자 ID (예: Speaker_01, Speaker_02) 매핑
       │
       ▼
[Step 3: 데이터 정렬 (Alignment)] ──► 시간대를 기준으로 [시간 - 임시 화자 - 대사] 형태의 Raw 데이터 생성
       │
       ▼
[Step 4: LLM 교정 (Contextual Correction)] ──► 대화 흐름 분석, 화자 일치성 수정, 실제 이름 매핑
       │
       ▼
[최종 정제된 회의록 생성]

3. 실무에 바로 쓰는 LLM 프롬프트 디자인

LLM을 통해 화자 분리 오류를 교정할 때 가장 중요한 것은 원래 대사의 왜곡 없이 화자 ID만 자연스럽게 교정하도록 유도하는 프롬프트입니다. LLM이 마음대로 대사를 요약하거나 생략하지 못하도록 제약 조건을 꼼꼼히 걸어주어야 합니다.

실제 효과를 보았던 프롬프트 템플릿의 핵심 골자를 공유합니다.

# 시스템 프롬프트 (System Prompt)
너는 전문 속기사이자 대화 맥락 분석 전문가야. 
입력 데이터는 음성 인식(STT) 및 오디오 화자 분리 기술을 거쳐 작성된 회의록의 초안이야. 
하지만 화자 분리 엔진의 한계로 인해 화자 ID(예: Speaker_0, Speaker_1)가 뒤엉켜 있거나 잘못 매핑된 상태야. 
아래 가이드라인에 따라 회의록의 '화자 ID'를 문맥에 맞게 교정해 줘.

## 교정 규칙
1. **대사 절대 수정 금지**: 발화 내용(텍스트)은 단 한 글자도 수정, 생략, 요약해서는 안 돼. 오직 '화자 이름/ID' 부분만 올바르게 수정해야 해.
2. **호칭 및 맥락 분석**: 
   - 예: "지수 님, 일정 확인하셨나요?"라고 물은 뒤 바로 이어지는 "네, 확인했습니다"의 화자가 앞사람과 동일하게 찍혀 있다면, 이는 화자 분리 오류야. 답변자의 화자 ID를 적절하게 분리해.
   - 대화 중 언급되는 이름(예: "길동 님", "대표님")과 직책을 단서로 삼아 무명 ID(Speaker_0)를 실제 이름(홍길동)으로 매핑해 줘.
3. **존칭 및 어조 확인**: 상급자와 하급자 간의 대화에서 존칭과 반말의 흐름이 깨진 곳이 있다면 화자 오류일 가능성이 높아. 맥락을 통해 이를 바로잡아 줘.
4. **결과 포맷**: 마크다운 테이블 형식으로 [시간 | 원래 화자 -> 교정된 화자 | 대사] 형태로 출력해 줘.

[실제 적용 예시]

4. 기존 방식 vs LLM 파이프라인 비교 평가

오디오 데이터만 만지작거리며 화자 분리 임계값(Threshold) 설정을 고치는 전통적인 개발 방식과, Whisper에 LLM을 결합한 하이브리드 방식은 실무 효율 측면에서 극적인 차이를 보입니다.

비교 항목 기존 오디오 중심 화자 분리 (PyAnnote 단독) Whisper + LLM 하이브리드 파이프라인
인식 원리 음성의 물리적 주파수 정보 분석 오디오 정보 + 언어학적 문맥(Context) 종합 분석
추임새/중첩 대처 오류 발생 확률 매우 높음 (화자 엉킴 현상) 전후 맥락을 보고 유연하게 기존 화자에 병합
실제 이름 매핑 불가능 (단순 인덱스 Speaker_0로만 출력) 본문 내 호칭 정보를 파악해 홍길동 팀장 등으로 자동 치환
구축 및 튜닝 난이도 고성능 GPU 기반 오디오 모델 미세 조정 필요 (매우 어려움) 표준 API 연동 및 프롬프트 엔지니어링 수준 (쉬움)
수작업 보정 소요량 화자 ID 오류가 곳곳에 흩어져 있어 회의록 전체를 처음부터 재검수해야 함 문맥상 어색한 구간만 부분 검수하면 되어 검토 범위가 크게 줄어듦

5. 실무 구현 시 반드시 알아야 할 주의사항 (Pro-Tips)

자동화 파이프라인을 사내 시스템에 올리거나 상용 서비스로 배포하기 전에, 아래 세 가지 현실적인 걸림돌을 선제적으로 제어해야 합니다.

① 토큰 수 제한과 롱폼(Long-form) 데이터 처리

1시간이 넘는 긴 회의는 텍스트 분량만 수만 자에 달합니다. LLM의 컨텍스트 윈도우(Context Window)가 아무리 커졌더라도, 너무 방대한 텍스트를 한 번에 밀어 넣으면 뒷부분 교정 퀄리티가 급격히 떨어지는 ‘Lost in the Middle’ 현상이 발생합니다.

② 개인정보 및 사내 보안 (Data Privacy)

회의록에는 사내 기밀 정보, 매출 지표, 개인 이름 및 이메일 주소 등이 고스란히 담겨 있습니다. 외부 LLM API(예: OpenAI API)를 호출할 때 데이터가 모델 학습에 재사용되지 않도록 설정하는 것은 필수입니다.

③ LLM의 환각(Hallucination) 방지 조치

아무리 온전한 대사 유지를 강조해도, LLM이 문장을 마음대로 자연스럽게 고치거나 비속어를 정제하는 과정에서 발화 내용 자체가 변조될 위험이 있습니다.

6. 음성 비서의 마침표를 찍다

Whisper의 등장이 회의록 작성에서 ’타이핑 노동’의 시대를 끝냈다면, LLM과의 결합은 ’누가 말했는지 고치는 편집 노동’의 시대를 끝내고 있습니다. 물리적인 음성 스펙트럼 분석만으로는 넘지 못했던 오디오 화자 분리의 한계를 인지적인 텍스트 맥락 추론으로 극복해 낸 이 접근법은, 실제 업무 자동화 영역에서 가장 유용하게 작동하는 AI 협업 모형 중 하나입니다.

조금 더 매끄러운 업무 환경을 구축하고 싶다면, 먼저 오픈소스 Whisper와 PyAnnote의 API 결과물을 적당한 청크로 분할해 가벼운 프롬프트와 함께 GPT-4o나 Claude 3.5 Sonnet에 던져보세요. 수작업으로 마우스를 끌어가며 회의록 이름을 고치던 지루한 시간이 단 몇 초의 API 호출로 단축되는 신세계를 경험하게 될 것입니다.

연관 글