회의 음성 인식은 정확도보다 화자 구분과 보존 기간으로 고른다

회의 음성 인식 서비스를 글자 오류율 표 하나로 고르면 두 곳에서 탈이 납니다. OwlAI가 비교하고 채택하지 않은 서비스 가운데 하나는 글자 오류율만 보면 앞서 있었는데, 두 사람이 나눈 회의를 5분 창으로 나눠 보내자 창 22개 가운데 12개에서 두 사람을 한 사람으로 합쳤습니다. 화면에서는 질문과 대답이 말풍선(한 사람이 이어 말한 발화를 묶어 보여 주는 칸) 하나로 붙어 나옵니다. 관리형 서비스는 받아쓴 글을 서비스 쪽에 남기기도 합니다. AssemblyAI의 공개 문서에 따르면 계정에 따로 설정하지 않으면 받아쓴 결과가 30일 동안 남습니다.

OwlAI는 회의를 두 길로 받아씁니다. 구축형의 기본은 고객 망 안의 GPU에서 도는 자체 호스팅 모델 MOSS이고, GPU가 없는 OwlAI SaaS는 관리형 서비스 AssemblyAI를 씁니다. 이 글은 두 길을 고른 기준을 순서대로 다룹니다. 결과가 어떤 모양으로 오는지를 먼저 보고, 같은 조건에서 품질을 잰 뒤, 창 설정으로 지연과 비용을 고르고, 마지막으로 음성이 어디에 얼마나 남는지를 봅니다. 관리형 서비스에 남는 것을 제품이 어떻게 지우는지도 함께 설명합니다.

#화자 구분은 받아쓰기와 같은 응답에 와야 한다

회의는 일정 주기마다 창(window, 한 번에 받아쓰는 오디오 구간) 하나씩 받아씁니다. 구축형 기본값은 60초마다 앞 30초를 겹친 90초 창입니다(「회의가 겹치면 받아쓰기가 멈춘다, 큐는 쓰는 자원마다 나눈다」). 말풍선을 가르려면 창 안에서 목소리가 바뀌는 자리를 알아야 하므로, 음성 인식 결과에는 발화마다 시각과 화자 라벨이 함께 실려야 합니다. 받아쓰기와 화자 분리를 따로 부르면 두 결과의 시각을 맞추는 단계가 더 생깁니다.

화자 라벨은 사람을 가리키지 않습니다. 모델은 창마다 라벨을 새로 매기므로 앞 창의 「화자 1」과 다음 창의 「화자 1」이 같은 사람이라는 보장이 없습니다. 그래서 라벨은 창 안에서만 비교합니다. 새로 확정한 첫 발화가 새 말풍선인지는 같은 창의 겹친 구간에 있는 바로 앞 발화와 라벨이 같은지로 정합니다. 저장하는 것은 발화마다 「여기서 다른 목소리가 시작된다」는 표시 하나입니다. 화면의 말풍선과 회의록 모델에 넣는 받아쓰기는 같은 함수가 이 표시로 만듭니다.

이렇게 하면 서비스에 요구하는 것이 줄어듭니다. 회의 전체에서 같은 사람에게 같은 라벨을 붙이는 기능은 필요 없고, 요청 하나 안에서 목소리를 가르면 됩니다. 대신 그 구분은 받아쓰기와 같은 응답에 와야 합니다.

설정은 이 조건을 기동할 때 확인합니다. 회의 받아쓰기(meetingStt)에는 발화마다 화자와 시각을 함께 돌려주는 자체 호스팅 모델(transcriptFormat: moss)과 AssemblyAI만 올 수 있고, 다른 조합은 기동 단계에서 거절합니다. 짧은 음성을 글 한 줄로 받으면 되는 마이크 입력은 요구가 달라서 stt 섹션으로 따로 고릅니다. 회의에는 언어 설정이 없습니다. 회의에는 여러 언어가 섞이는데, 언어를 고정하면 모델이 모든 발화를 그 언어로 읽어 다른 언어 발화를 뭉갭니다.

#정확도는 제품과 같은 창으로 자르고, 뜻이 같은지로 잰다

관리형 서비스를 평가할 때도 음성을 제품과 같은 창으로 자르고 같은 규칙으로 이었습니다. 자체 호스팅 모델의 수치도 같은 조건에서 쟀습니다. 한쪽은 창을 이어 붙인 결과이고 다른 쪽은 회의 전체를 한 번에 넣은 결과라면, 창 경계에서 잃는 발화가 한쪽에만 들어가 결론이 뒤집힙니다.

채점은 글자 일치 대신 뜻이 같은지로 했습니다. 한국어 회의는 사람이 들어도 글자 단위로는 애매한 곳이 많아서, 엔진끼리의 글자 오류율이 14~27% 벌어져도 뜻은 같은 경우가 흔합니다. 그래서 받아쓰기는 30초 안팎의 구간마다 뜻을 얼마나 지켰는지 0~4점으로 매겨 길이로 가중하고, 화자는 사람이 고친 말풍선 경계와 ±2초 안에서 맞는지로 쟀습니다. 사내 회의 녹음은 외부 전송을 허락받은 두 건만 썼고, 나머지는 공개 회의 음성 코퍼스 AMI와 한국어 낭독 코퍼스를 썼습니다.

화자 경계까지 보면 글자 오류율로 매긴 순위가 바뀌었습니다. 다음 결과를 낸 서비스는 채택하지 않았습니다.

• 두 사람 회의에서 두 사람을 한 사람으로 합친다(앞의 5분 창 22개 중 12개)
• 네 사람 회의 녹음에서 화자를 12~19명으로 쪼갠다
• 열화된 음성에 오류 대신 내용 없는 성공 응답을 낸다(재시도가 돌지 않고 말이 없던 구간으로 저장된다)
• 언어를 한국어로 지정했는데 다른 언어로 받아쓴다

#창 설정은 품질이 같아서 지연과 비용으로 고른다

창을 길게 잡으면 품질이 나아질 것 같지만, 60초 주기부터는 차이가 없었습니다. AMI에서 자체 호스팅 모델의 단어 오류율(WER)은 60초 주기·90초 창이 23.8%, 300초 주기·330초 창이 23.5%였고 차이는 유의하지 않았습니다(p=0.72). 회의 전체를 한 번에 넣으면 22.8%였습니다(2026년 9월 측정). 반대로 주기를 30초로 줄이면 WER이 6%p, 15초면 17%p 올랐고, 창을 늘려 앞 문맥을 더 줘도 회복되지 않았습니다. 짧은 조각에서는 모델이 문장을 끝맺지 못한 채 잘리기 때문입니다. 그래서 60초가 주기의 바닥이고, 설정 검증은 창과 주기의 겹침을 최소 30초로 강제합니다. 겹침 6초에서는 다음 창이 넘겨받은 발화 106건 가운데 33건의 앞머리가 잘렸고, 30초에서는 1건이었습니다.

품질이 같으니 두 설정은 지연과 비용으로 고릅니다.

오디오 길이로 청구하는 관리형 서비스에서는 보내는 오디오의 배수가 그대로 요금이 됩니다. 그래서 OwlAI SaaS는 300/330을 씁니다. GPU를 직접 쓰는 구축형은 GPU 시간 차이가 7초뿐이라 지연이 짧은 60/90을 씁니다. 메커니즘과 코드는 하나이고 설정값(meeting.transcribeStrideSeconds·meeting.transcribeWindowSeconds)만 다릅니다.

#관리형 서비스는 음성과 받아쓴 글을 서비스 쪽에 남긴다

자체 호스팅 모델은 요청 한 번에 결과를 돌려주고, 고객 망 밖에는 아무것도 남지 않습니다. 관리형 서비스는 비동기 작업입니다. 음성 파일을 올리고, 받아쓰기 작업을 만들고, 끝났는지 묻고, 결과를 받습니다. 그동안 올린 음성과 받아쓴 결과는 서비스 쪽에 있습니다. 그래서 설정 예시(config.example.yaml)는 AssemblyAI를 켜면 회의 음성이 외부로 나간다고 적고, 음성이 사내에 남아야 하는 구축형에서는 쓰지 않도록 안내합니다.

관리형 서비스를 쓰면 그 서비스의 보존 정책이 곧 회의 음성의 보존 기간입니다. AssemblyAI 공개 문서의 내용은 다음과 같습니다(2026년 11월 확인). 의료 정보 보호 계약(BAA) 같은 별도 계약이 있으면 기본값이 달라지므로, 도입할 때 그때의 문서와 계약 조건으로 다시 확인해야 합니다.

• 올린 음성 파일: 업로드 24시간 뒤 삭제가 시작되고 최대 48시간 안에 끝난다.
• 받아쓴 결과(transcript): 계정에 데이터 보존 기간(TTL)을 걸지 않으면 30일 뒤 삭제가 시작된다.
• 계정 TTL: 걸면 음성과 결과 모두 그 시각에 삭제가 시작되고, 1시간까지 낮출 수 있다.
• 모델 학습: 계약이 허용하는 일부 파일만 학습에 쓰고, 유럽 서버를 쓰거나 BAA가 있거나 학습 제외(opt-out)를 켠 계정의 파일은 쓰지 않는다.
• 올린 파일만 따로 지우는 API는 없고, 받아쓰기 작업을 지우면 그 작업에 쓴 파일도 함께 지워진다.

OwlAI SaaS는 유럽 엔드포인트로 요청을 보내고, 운영 계정에 TTL을 짧게 걸고 학습 제외를 켰습니다. 이 설정은 계정 쪽 안전장치이고, 제품은 그와 별개로 쓴 것을 바로 지웁니다.

#받아쓴 직후 지우고, 놓친 것은 기록해 두었다가 다시 지운다

관리형 서비스로 창 하나를 받아쓰는 순서는 다음과 같습니다. 음성을 올린 직후, 받아쓰기 작업을 만들기 전에 삭제 기록에 그 창의 행을 적습니다. 작업을 만든 직후에는 그 행에 작업 ID를 채웁니다. 결과를 받아 저장하면 바로 서비스 쪽 작업을 지우고, 이때 올린 파일도 함께 지워집니다.

행을 먼저 적는 이유는 워커가 결과를 기다리다 죽거나 삭제 요청이 실패하는 경우가 있어서입니다. 그때도 행이 남아 있으므로, 10분마다 도는 정리 작업이 행을 만든 서비스로 남은 것을 다시 지웁니다. 설정에 지금 적힌 서비스가 아니라 행을 만든 서비스로 지우는 것은, 서비스를 바꾼 뒤에도 옛 서비스 쪽에 객체가 남아 있을 수 있기 때문입니다. 실패한 행은 10분부터 두 배씩 간격을 늘려 6시간까지 다시 시도하고, 포기하지 않습니다. 포기하면 몇 시간짜리 장애(키 교체, 계정 정지)가 그대로 서비스 쪽 영구 보존이 됩니다. 간격이 6시간에 닿은 행은 하루 한 번 오류 로그로 알립니다.

재시도는 음성을 새로 올리지 않습니다. 아직 지우지 않은 작업이 있으면 그 작업을 이어서 기다리고, 음성만 있으면 같은 업로드 주소로 작업을 만듭니다. 같은 창이 두 번 청구되지 않게 하려는 것입니다. 같은 이유로 정리 작업은 창이 아직 끝나지 않았으면 재시도가 이어받을 때까지 그 행을 건드리지 않습니다.

작업 ID가 빈 행은 그대로 믿지 않습니다. 작업 생성 요청이 시간 초과로 끝났다면 서비스에는 작업이 있는데 기록에는 ID가 없을 수 있습니다. 이 행을 「만든 적 없음」으로 읽으면 그 작업은 영영 지워지지 않고, 재시도가 작업을 하나 더 만들어 두 번 청구됩니다. 그래서 서비스의 최근 작업 목록에서 그 업로드 주소를 쓴 작업을 찾아, 재시도는 이어받고 정리 작업은 지웁니다. 정해진 범위 안에서 찾지 못하면 새로 만들지 않고 실패로 끝냅니다. 모르는 채로 새로 만들면 앞 작업을 잃기 때문입니다.

남는 경우가 하나 있습니다. 음성은 올렸는데 작업 생성이 끝내 실패하면, 그 파일을 지울 API가 없어 서비스의 보존 기한까지 남습니다. 재시도가 같은 음성을 다시 쓰므로 이런 파일은 창 하나에 많아야 하나이고, 정리 작업이 경고 로그로 남깁니다. 업로드 응답을 받고 행을 적기 전에 워커가 죽으면 기록조차 없습니다. 이런 파일까지 지우는 것이 계정 TTL입니다.

제품 안에 있는 회의 원본 음성은 회의록을 만든 뒤 지우고(「회의를 끝내면 마지막 발언이 빠진다, 음성은 받아쓰기를 마친 뒤 지운다」), 회의가 끝난 뒤에는 받아쓴 글과 회의록만 남습니다.

#설계에서 고른 것

회의 전체에서 화자를 이어 붙이는 대신 창 안의 발언 전환만 씁니다. 화자를 이어 붙이면 「화자 A」에 이름을 붙이는 기능을 만들 수 있지만, 그러려면 목소리 특징을 저장하거나 누가 무슨 말을 했는지를 회의 기록에 남겨야 합니다. 받아쓰기 행에는 발언 전환 표시만 있고 화자 칸이 없으며, 목소리 특징도 남지 않습니다. 그 대가로 회의록은 「누가 말했다」를 적지 못하고, 할 일의 담당과 기한은 회의에서 누군가 실제로 말했을 때만 채웁니다. 서비스 쪽 요구가 「요청 하나 안에서 목소리를 가른다」로 줄어든 것은 이 선택 덕분입니다.

OwlAI SaaS는 지연보다 비용을 골라 300/330을 씁니다. 품질이 같은 상태에서 보내는 오디오가 1.48배에서 1.07배로 줄어드는 대신, 말풍선은 최대 약 5분 반 늦게 뜹니다. 화면은 그 사이를 「음성인식 중…」으로 채웁니다.

서비스의 보존 정책이나 계정 TTL에만 맡기는 대신 제품이 쓴 즉시 지우고, 놓친 것을 기록으로 다시 지웁니다. TTL은 계정 대시보드에서만 바꿀 수 있고 바꾼 값은 그 뒤 요청부터 적용되며, 보존 정책은 서비스가 바꿀 수 있습니다. 그 대가로 제품은 삭제 기록 테이블과 주기 정리 작업, 목록을 넘겨 가며 잃어버린 작업을 찾는 코드를 갖게 됐습니다.

관리형 음성 인식을 붙이는 제품이라면 정확도 표를 보기 전에 두 가지를 먼저 확인하는 편이 빠릅니다. 화자 구분이 받아쓰기와 같은 응답에 오는지, 그리고 올린 음성과 결과가 서비스에 얼마나 남고 무엇으로 지울 수 있는지입니다.