Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
회의가 끝나고 자리로 돌아와 40분짜리 녹음 파일을 올린다. 3분 만에 텍스트가 떨어지고 오타도 거의 없다. 그런데 문장 앞에 붙은 이름이 전부 화자1, 화자2, 화자3이고, 정작 “그럼 그렇게 가죠”라고 말한 사람이 누구인지는 파일을 다시 들어야 안다. 도구를 바꾸는 것보다 회의 시작 30초에 손보는 쪽이 더 크게 먹히는데, 그 30초는 뒤쪽 소제목에서 따로 다룬다.
- 전사 정확도는 도구 간 차이가 이미 좁혀졌다. 남은 승부처는 화자 구분과 결정사항 추출, 두 군데다.
- 화자 구분은 목소리를 알아듣는 기능이 아니라 음성 특징을 군집으로 묶어 몇 명인지 추정하는 계산이다. 겹쳐 말하는 구간에서 가장 먼저 무너진다.
- 회의 플랫폼 내장 기록은 화자를 소리로 추정하지 않고 참가자 트랙으로 가른다. 전원 원격 회의라면 이 경로가 구조적으로 유리하다.
손으로 받아 적던 회의록, 병목이 옮겨간 자리
예전 회의록은 사람 손이 전부였다. 막내가 노트에 받아 적고, 놓친 부분은 녹음을 되감아 다시 듣고, 1시간 회의를 정리하는 데 2~3시간이 들어갔다. 초기 음성 인식을 붙여봐도 전문용어와 사투리에서 문장이 깨졌고, 고치는 시간이 처음부터 타이핑하는 시간과 비슷했다.
지금은 한국어 전사만 따로 떼어놓고 보면 도구를 고를 이유가 거의 없다. 조용한 회의실에서 한 대의 기기로 받은 음성이라면 어느 서비스든 읽을 만한 문장이 나온다. 그래서 불만이 생기는 지점도 바뀌었다. “글자를 못 알아듣는다”가 아니라 “누가 말했는지 모르겠다”, “결정된 게 뭔지 이 문서로는 모르겠다”로 옮겨왔다.
도구를 비교할 때 봐야 할 항목도 그만큼 줄었다. 전사 정확도 자리에 화자 구분, 결정사항 추출, 파일 길이 처리, 녹음 데이터의 행방이 들어왔다.
화자 구분이 틀리는 다섯 가지 상황
화자 구분은 음성을 짧은 조각으로 자른 뒤 각 조각에서 목소리 특징을 숫자 벡터로 뽑고, 비슷한 것끼리 묶는 방식으로 돌아간다. 이름을 아는 게 아니라 “몇 명이고 어디서 사람이 바뀌었는지”만 추정한다. 그래서 이름은 사람이 나중에 붙여야 하고, 군집 자체가 틀리면 이름을 붙일 기준도 사라진다.
무너지는 조건은 꽤 정해져 있다. 두 사람이 동시에 말하는 구간, 스피커폰 한 대로 받을 때 테이블 끝에 앉은 사람, 목소리 대역이 겹치는 동성 두 명, “네” “맞아요” 같은 1초짜리 맞장구, 그리고 회의 중간에 합류한 참석자다. 특히 짧은 맞장구는 앞사람 발언에 붙어버려서 화자 수를 실제보다 적게 만든다.
흔한 오해 하나. 화자 구분이 틀리는 건 목소리가 비슷해서라고 알려져 있지만, 실전에서 더 자주 무너지는 원인은 마이크 거리다. 같은 사람이 의자를 뒤로 빼거나 화이트보드 앞으로 걸어간 것만으로 다른 사람처럼 다른 군집에 들어간다.
요약과 결정사항 추출은 같은 작업이 아니다
요약은 많이 나온 화제를 압축하는 일이다. 결정사항 추출은 성격이 다르다. 누가, 무엇을, 언제까지 하기로 했는지를 발언에서 끄집어내야 하는데, 회의에서 그 문장이 명시적으로 나오지 않으면 모델도 뽑아낼 게 없다. “그건 좀 보고 하죠”가 결정인지 보류인지는 녹취록만으로 판단이 안 된다.
그래서 추출 단계에서는 빈칸 구조를 먼저 정해주는 편이 낫다. 전사 텍스트를 붙여 넣고 “① 확정된 사항 ② 보류·재논의 사항 ③ 담당자와 기한이 붙은 할 일 ④ 회의에서 언급된 숫자와 그 맥락, 이 네 칸으로만 표를 만들어라. 녹취록에 없는 내용은 칸을 비워 두고 추측하지 말 것” 정도로 지시하면 결과가 안정된다.
마지막 한 줄이 실제로 하는 일이 크다. 빈칸을 그럴듯하게 메우는 습성을 막아주기 때문에, 회의록을 받은 사람이 “이 기한 누가 정했지?” 하고 되묻는 상황이 줄어든다.
도구 네 갈래, 유리한 회의가 다 다르다
고를 때 비교할 기준은 네 개로 좁혀진다. 화자를 무엇을 기준으로 가르는지, 결정사항을 어디까지 대신 뽑아주는지, 1시간짜리 파일이 한 번에 들어가는지, 올린 녹음이 어디에 남는지. 이 네 항목으로 갈래를 나누면 아래와 같다.
| 갈래 | 화자 구분 방식 | 결정사항 추출 | 1시간 파일 | 유리한 회의 |
|---|---|---|---|---|
| 회의 플랫폼 내장 기록 | 참가자 접속 단위로 갈림, 소리로 추정하지 않음 | 플랫폼 AI 기능에 포함, 상위 요금제에서 열리는 경우가 많음 | 회의 시간 그대로 처리 | 전원 원격 정기 회의 |
| 녹음 전사 서비스 | 음성 군집 기반 참석자 구분, 이름은 수동 지정 | 요약·키워드까지, 결정 항목은 후편집 필요 | 무료 구간은 월 단위 분량 한도로 끊는 방식이 일반적 | 한 대로 녹음한 대면 회의 |
| 범용 챗봇에 전사 텍스트 투입 | 자체 구분 없음, 이미 붙은 라벨을 따라감 | 프롬프트 설계에 따라 가장 유연 | 오디오 지원 여부는 서비스·요금제마다 갈림, 텍스트는 길이가 관건 | 결정·할 일 정리가 목적일 때 |
| 오픈소스 직접 구축 | 화자 수 지정 등 조정 가능 | 추출 단계를 직접 붙여야 함 | 내 컴퓨터에서 돌리므로 길이 제약은 적고 시간은 오래 | 외부 업로드가 막힌 조직 |
참고로 잘 안 알려진 부분이 첫 줄이다. 원격 회의 플랫폼의 기록은 각 참가자 음성을 따로 받아 적기 때문에 화자 구분을 사실상 공짜로 해결한다. 대면 회의에서 아무리 좋은 모델을 돌려도 이 정확도를 따라가기 어렵다. 반대로 널리 쓰이는 오픈소스 전사 모델은 그 자체로는 화자를 나누지 못하고, 화자 분리 모델을 따로 붙여야 한다.
관련: KT 모두의 AI 컨소시엄, 16곳 명단보다 10월 베타에서 갈릴 3가지
1시간 녹음은 한 번에 올라가나?
업로드가 막히는 원인은 대개 용량보다 파일당 시간 상한이다. 다만 파일 형식을 잘못 고르면 용량에서 먼저 걸린다. 압축 형식으로 저장한 1시간 음성은 수십 MB 수준이지만, 무압축으로 받은 같은 1시간은 수백 MB로 불어난다. 회의 음성은 낮은 표본율에 모노로 받아도 전사 품질에 손해가 없으니, 녹음 앱 설정을 한 번 고쳐두면 이 문제는 다시 생기지 않는다.
길어서 잘라야 할 때 주의할 점이 하나 있다. 30분씩 기계적으로 자르면 화자 군집이 파일마다 새로 계산된다. 같은 사람이 앞 파일에서 화자1, 뒤 파일에서 화자3으로 잡히고, 이름 매핑을 두 번 해야 한다. 자를 거라면 안건이 넘어가는 지점에서 끊고, 각 조각의 앞부분에 이름을 다시 넣어주는 편이 낫다.
처리 시간은 대체로 녹음 길이보다 짧다. 예외는 직접 구축형이다. 그래픽카드 없이 돌리면 1시간 파일 하나에 그보다 긴 시간이 걸리기도 해서, 회의 끝나고 바로 회의록이 필요한 상황에는 맞지 않는다.
내 회의 녹음이 학습에 들어가나?
갈리는 기준은 서비스 이름이 아니라 요금제 성격이다. 업무용·기업용 계약은 고객이 올린 데이터를 모델 학습에 쓰지 않는다고 약관에 명시하는 쪽이 일반적이고, 개인용 무료 구간은 설정을 끄지 않으면 품질 개선 목적의 활용이 열려 있는 경우가 있다. 스위치 이름은 서비스마다 다르지만 데이터 관리나 모델 개선 항목에 들어 있다.
실무에서 챙길 건 세 가지다. 계정 설정에서 학습 활용을 껐는지, 올린 파일과 전사 결과가 서버에 얼마나 남고 어떻게 지우는지, 그리고 이 회의가 애초에 업로드해도 되는 회의인지. 인사 평가, 계약 조건, 공개 전 실적 숫자가 나오는 자리라면 표의 네 번째 갈래가 남아 있는 이유가 여기다.
녹음 자체를 알리는 문제도 같이 붙는다. 참석자 동의 없이 녹음해 두면 회의록의 정확도와 무관하게 뒤탈이 생긴다. 녹음 버튼을 누르고 “기록용으로 녹음합니다” 한마디를 넣는 것으로 정리되는 일이다.
회의 시작 30초에 하는 세 가지
첫째, 이름 라운드콜이다. 녹음을 켠 직후 참석자가 순서대로 “○○○입니다” 한 문장씩 말한다. 다섯 명이면 20초면 끝난다. 이 20초가 화자1~5에 이름을 붙일 기준 샘플이 되고, 손으로 매핑할 때도 파일 맨 앞만 들으면 되므로 40분을 되감을 일이 없어진다.
둘째, 마이크 기준점을 고정한다. 노트북 한 대로 받을 때는 테이블 중앙에 두고 발언자 쪽으로 옮기지 않는다. 옮기는 순간 같은 사람 목소리가 다른 군집으로 갈라진다. 같은 방에 있는 사람과 원격 참석자가 섞인 회의라면 각자 자기 기기로 접속해서 스피커만 끄고 마이크는 켜 두는 구성이 화자 구분에 가장 유리하다.
셋째, 안건을 결정문 형태로 적어둔다. “디자인 논의”가 아니라 “A안·B안 중 택1”, “예산 상한 확정”처럼 결정할 문장을 안건에 박아두는 방식이다. 이렇게 두면 회의 중에 “그럼 A안으로 갑니다” 같은 명시적 발화가 나오고, 추출 단계에서 그 문장이 그대로 잡힌다. 여기에 하나 더 붙이자면, 결정이 난 순간 진행자가 “A안, 담당 ○○, 다음 주 수요일까지”를 소리 내어 복창하는 습관이다. 회의록 품질을 가장 크게 끌어올리는 한 문장이다.
이런 회의는 이렇게
전원이 원격으로 들어오는 주간 회의라면 플랫폼 내장 기록에서 끝난다. 파일을 따로 내려받아 다른 서비스에 올릴 이유가 없다. 1:1 면담도 편하다. 화자가 둘이면 군집 오류가 거의 나지 않아서 어느 도구를 써도 결과가 비슷하다.
대면으로 여섯 명 이상 모여 말이 겹치는 브레인스토밍은 화자 구분 기대치를 낮추고 접근을 바꾸는 편이 낫다. 라벨은 포기하고 전사 텍스트만 받아서 결정과 할 일만 추출하는 쪽이 시간당 수확이 크다. 인사·계약이 걸린 회의는 업로드 경로 자체를 피하거나, 녹음 없이 사람이 요지만 적는 옛 방식이 여전히 안전하다.
도구별 항목을 표까지 만들어 비교해 놓고 보면 결말이 좀 허무하다. 결과 차이를 실제로 만든 변수는 도구가 아니라 회의 진행 방식이었다. 결정을 소리 내어 확인하고 안건에 결정문이 박혀 있는 회의는 어떤 도구를 붙여도 비슷한 회의록이 나오고, 그렇지 않은 회의는 가장 비싼 조합을 써도 화자1의 애매한 말줄임표만 남는다.
다음에 볼 것: 쓰고 있는 서비스의 데이터 보존 기간과 학습 활용 스위치, 그리고 다음 회의 안건에 결정할 문장이 몇 개 들어가 있는지.
