회의록 자동 교정, 원본을 지우지 않고 따로 남긴 이유
짧은 음성 메모는 던지면 노트가 됐다. 근데 여럿이 한 시간 넘게 떠든 회의 녹음 받아쓰기는 완전히 다른 물건이더라.
내 볼트엔 이미 음성을 텍스트로 바꾸는 배선이 깔려 있다. 폰으로 혼잣말 녹음해서 던지면 알아서 받아써서 노트로 꽂히는 거. 그건 옵시디언 자동화 3편에 다 적어놨으니 여기선 안 다룬다. 문제는 그다음이었다. 회의 녹음을 같은 입구에 넣었더니, 짧은 메모에선 한 번도 안 났던 고장이 줄줄이 나왔다.
📑 목차
- 1. 짧은 메모랑 긴 녹음은 아예 다른 문제였다
- 2. 통째로 못 넘겨서 10분씩 잘랐다
- 3. 두 번 받아쓰게 하고 서로 대조시켰다
- 4. 교정본이 이겼는데, 한 대목이 사라져 있었다
- 5. 누가 말했는지는 아직도 모른다
- 6. 지금 상태, 그리고 안 끝난 것
1. 짧은 메모랑 긴 녹음은 아예 다른 문제였다
혼자 30초 중얼거린 파일은 그냥 된다. 파일이 작으니 통으로 넘기면 되고, 목소리가 하나뿐이라 헷갈릴 일도 없고, 좀 틀리게 받아써도 내가 무슨 말 했는지 아니까 눈으로 고치면 그만이다.
회의 녹음은 세 군데서 다 걸린다. 파일이 크고, 사람이 여럿이고, 무슨 말이 오갔는지 내가 다 기억을 못 한다. 마지막 게 제일 크다. 받아쓴 게 틀렸는지 아닌지를 내가 판별을 못 하니까, 검수를 사람한테 못 맡긴다.
그래서 클로드코드한테 시킨 건 "받아쓰기를 잘하게 해줘"가 아니었다. 받아쓴 결과를 한 번 더 의심하는 단계를 파이프 뒤에 붙이는 일이었다. 설계 문서 하나 쓰고 하루 만에 실물이 나왔는데, 정작 판단이 필요했던 건 코드가 아니라 그다음이더라.
2. 통째로 못 넘겨서 10분씩 잘랐다
받아쓰기는 두 경로를 쓴다. 하나는 내 맥에서 도는 로컬 모델(mlx-whisper, 인터넷 없이 내 컴퓨터 안에서 돌아가는 받아쓰기 프로그램), 다른 하나는 그게 실패했을 때 넘어가는 외부 서비스다. 로컬은 시간이 오래 걸려서 60분 타임아웃을 걸어놨다.
문제는 폴백 쪽이다. 외부 서비스는 한 번에 보낼 수 있는 파일 크기 상한이 있고, 내 코드엔 25MB로 박혀 있다. 회의 녹음은 그걸 우습게 넘긴다. 그래서 나온 처리가 잘라 보내기다. 영상·음성 다루는 공용 도구(ffmpeg)로 10분씩 토막을 내고, 토막마다 3초씩 겹치게 자른다. 그리고 순서대로 하나씩 보내서 받아쓴 다음, 각 토막의 시간을 원래 위치로 밀어서 다시 이어 붙인다.
3초를 왜 겹치냐면, 딱 잘라버리면 경계에 걸친 말이 통째로 날아가서다. "그래서 이번 분기에는" 하다가 10분이 끝나면, 안 겹칠 경우 그 문장이 앞뒤 어디에도 안 남는다.
근데 겹치면 겹치는 대로 값을 치른다. 3초 구간의 말이 앞 토막 끝과 뒤 토막 앞에 두 번 들어간다. 지금 코드는 그 중복을 안 지운다. 지우려면 두 토막의 문장이 같은 말인지 판정하는 로직이 필요한데, 그걸 대충 만들면 멀쩡한 반복 발언까지 지운다. 회의에선 같은 말을 진짜로 두 번 하는 사람이 있다. 그래서 중복을 남기는 쪽을 골랐다. 이음매에서 한 문장이 두 번 보이는 게, 있었던 말이 사라지는 것보다 낫다고 봤다.
▲ 10분 청크와 3초 겹침 구간을 표시한 분할 구조도 (자체 제작 이미지)
▲ 10분 토막, 3초 겹침. 겹치는 구간은 중복을 감수하고 그대로 둔다.
크기 자체도 미리 잰다. 500MB 넘으면 "이거 오래 걸린다"고 알림만 보내고 계속 돌리고, 1500MB 넘으면 아예 시작을 안 하고 중단한다. 어차피 안 끝날 걸 몇 시간 물고 있다가 실패하는 게 제일 나쁘다.
3. 두 번 받아쓰게 하고 서로 대조시켰다
받아쓰기가 틀리는 방식은 대체로 뻔하다. 고유명사, 업계 용어, 사람 이름. 발음은 비슷한데 사전에 없는 단어가 나오면 엉뚱한 소리로 적힌다.
처음 잡은 해법은 "미리 용어를 알려주자"였다. 받아쓰기 모델에 시작 문구를 넣어서 이런 단어가 나올 거라고 힌트를 주는 방식이 있다. 같은 90초짜리 클립으로 5번 돌려서 비교해봤는데, 이게 첫 구간을 오염시켰다. 힌트로 넣은 단어가 실제로는 나오지 않았는데도 메아리처럼 앞부분에 튀어나오더라. 없는 말이 생기는 건 잘못 받아쓴 것보다 나쁘다. 기각.
대신 용어 힌트를 정식 기능으로 받는 다른 받아쓰기 서비스로 갈아탔다. 그래서 지금 구조는 이렇다. 같은 녹음을 서로 다른 두 엔진이 각각 받아쓰고, 그 두 결과를 놓고 클로드코드가 대조해서 교정본을 만든다. 한쪽이 "휴택"이라고 적고 다른 쪽이 뭔가 다르게 적었으면, 앞뒤 맥락으로 어느 쪽이 말이 되는지 판단하는 식이다. 실제로 앞선 판에서 정체불명이던 대목 하나가 "풀스택 경쟁"으로 복원됐다.
부수 효과도 있었다. 새로 붙인 엔진이 화자 구분을 자체적으로 해줘서, 따로 돌리던 화자 분리 단계를 통째로 뺄 수 있었다. 전체 처리가 27분에서 12분으로 줄었다. 단계를 최적화한 게 아니라 단계 하나가 없어진 거다.
물론 새 엔진도 흠이 있다. 짧은 클립에서 중간에 뚝 끊고 끝내버리는 경우가 있어서, 받아쓴 길이가 원래 음성 길이의 80%에 못 미치면 조기 절단으로 보고 자동으로 다른 엔진에 다시 태운다.
4. 교정본이 이겼는데, 한 대목이 사라져 있었다
여기가 이 글의 본론이다.
20분짜리 녹음으로 교정 전후를 붙여봤다. 총평은 교정본 우세다. 못 알아듣던 단어들이 살아났고 문장이 읽힌다. 근데 원문에는 분명히 있던 언급 하나가 교정본에서 안 보였다. 특정 기관을 거론한 대목이었는데, 교정 과정에서 조용히 빠졌다.
이게 무서운 이유는, 알아채기가 거의 불가능해서다. 잘못 받아쓴 단어는 눈에 띈다. 문장이 이상하니까. 근데 없어진 문장은 아무 표시도 안 남긴다. 교정본만 놓고 보면 매끄럽게 잘 읽힌다. 원문과 나란히 놓고 한 줄씩 대보기 전엔 뭐가 빠졌는지 알 방법이 없다.
그래서 정한 게 이거다. 교정본은 교정본대로 만들되, 받아쓴 원문 노트는 지우지 않는다. 교정본이 원문을 대체하는 게 아니라 옆에 하나 더 생기는 구조로 뒀다. 저장 폴더도 따로 잡혀 있어서, 회의 녹음이면 회의록 폴더로, 그냥 녹음이면 수집함으로 나뉜다.
솔직히 처음엔 원문을 지우고 싶었다. 같은 회의가 파일 두 개로 남으면 나중에 뭘 봐야 할지 헷갈리니까. 근데 사라진 대목을 발견하고 나서 생각이 바뀌었다. 교정본은 원문의 개선판이 아니라 원문에 대한 해석이다. 해석이 원본을 덮어쓰면 해석이 틀렸을 때 돌아갈 데가 없다.
같은 이유로 뭔가를 지우는 자동화는 계속 의심하게 된다. 출처 검증에서도 비슷한 걸 겪었는데, 출처를 못 붙인 문장을 지우지 않고 딱지만 붙여 남긴 것도 결국 같은 판단이었다. 기계가 자신 없어 하는 자리를 사람이 볼 수 있게 남겨두는 것.
▲ 원문과 교정본을 나란히 비교해 복원된 단어와 누락된 대목을 표시한 카드 (자체 제작 이미지)
▲ 교정본이 총평은 낫다. 근데 원문에만 남은 대목이 있어서 원문을 못 지운다.
받아쓰기 자체에도 비슷한 방어를 하나 걸어놨다. 녹음 끝의 조용한 구간에서 마지막 단어를 무한 반복하는 고장이 있어서, 그걸 막는 설정을 따로 잡았다. 이런 건 진짜 아무 에러도 안 난다. 그냥 같은 말이 백 번 적혀 있을 뿐이다.
5. 누가 말했는지는 아직도 모른다
화자 분리가 붙어 있다고 했는데, 오해가 없게 짚어야겠다. 기계가 하는 건 "여기까진 A 목소리, 여기부턴 B 목소리"까지다. A가 누구인지는 모른다. 알 수가 없다. 목소리 주인의 이름은 음성 안에 없으니까.
그러니까 회의록을 자동으로 만들어도 "김 부장이 이렇게 말했다" 같은 건 안 나온다. 나오는 건 1번 화자, 2번 화자다. 이름표를 붙이려면 사람이 한 번은 들어봐야 하고, 결국 그 대목만큼은 손이 든다.
여럿이 동시에 말하는 구간은 더 답이 없다. 겹쳐 말하면 분리 자체가 흔들린다. 회의는 원래 사람들이 말을 자르고 끼어드는 자리라서, 제일 중요한 대목이 제일 안 잡히는 역설이 있다.
이 한계는 아직 안 풀었다. 풀 계획을 세워둔 것도 아니다. 지금은 화자 번호까지만 받고, 이름은 내가 필요할 때 붙인다.
6. 지금 상태, 그리고 안 끝난 것
만든 다음 검증을 돌렸다. 새 대화창을 띄운 검증자한테 결함만 찾아내게 시켰더니 6건이 나왔고, 고치고 다시 돌려서 통과. 엔진을 갈아끼운 뒤에도 2라운드를 돌려서 2건을 더 잡았다. 내가 채점하면 늘 통과가 나온다는 건 전에 한번 크게 데인 적이 있어서, 이 단계는 이제 안 건너뛴다.
그리고 첫 실제 녹음을 태워봤다. 라이브로 돌아가는 건 확인했고, 품질을 보고 나서 정한 게 있다. 기존에 쓰던 상용 받아쓰기 결과물도 계속 같이 올리기로 했다. 파이프가 그걸 감지해서 흡수하도록 돼 있다. 자동화가 다 됐으니 기존 방식을 끊자, 가 아니라 당분간 나란히 돌리는 쪽을 골랐다.
세 소스를 전부 대조에 쓰는 안은 검토만 하고 보류 중이다. 정확도는 오르겠지만 처리 시간과 복잡도가 같이 오르고, 아직 그만한 값을 하는지 판단할 데이터가 없다. 이 파이프가 쓸 만한지에 대한 최종 판정도 아직 안 내렸다. 실제 녹음이 몇 건 더 쌓여야 알 수 있는 거라서.
이 글은 정보 제공이 목적이고, 작성 시점 기준이다. 요금·기능·정책은 이후 바뀔 수 있으니 결제·설치 전 공식 페이지를 한 번 확인하는 게 좋다. 특정 제품 사용을 권유하거나 결과를 보장하지 않는다.
3줄 요약
- 긴 녹음은 통째로 못 넘겨서 10분씩 자르고 3초를 겹쳤다. 겹침 구간 중복은 안 지운다, 있었던 말이 사라지는 것보다 나아서.
- 두 엔진에 각각 받아쓰게 하고 대조해 교정본을 만들었다. 총평은 교정본이 나은데, 원문에 있던 대목 하나가 조용히 빠져 있었다.
- 그래서 교정본은 원문을 덮지 않고 옆에 하나 더 생긴다. 화자가 누구인지는 여전히 사람이 붙여야 한다.
빠진 문장은 비명을 안 지른다. 그래서 원문을 남긴다.
참고한 공식 자료
- 받아쓰기 모델 원본 프로젝트: openai/whisper (GitHub)
- 애플 실리콘용 구현: ml-explore/mlx-examples (GitHub)
- 화자 분리 도구: pyannote-audio (GitHub)
- 음성·영상 분할에 쓴 도구: FFmpeg 공식 사이트
댓글
댓글 쓰기