회의록 자동화를 만들다가 녹음 방식을 바꾼 이유

회의가 끝나면 녹음을 바탕으로 내용을 정리하고, 결정한 일과 다음에 확인할 일을 남기고 싶었습니다. AI 비서에 회의록 기능을 붙이면 녹음부터 문서 작성까지 이어갈 수 있을 것 같았습니다. 그래서 AI와 함께 녹음 버튼과 저장 기능부터 만들기 시작했습니다.

그러다 직접 다루는 범위가 커졌습니다. 음성을 잃지 않고 저장하는 일, 서버로 보내는 일, 말한 내용을 글로 옮기는 일, 누가 말했는지 구분하는 일을 모두 해결해야 했습니다. 저는 이 경로를 만든 뒤, 녹음과 화자 구분은 클로바노트에 맡기고 제 프로그램은 녹취록을 받는 방식으로 바꿨습니다.

이 글은 2026년 9월의 입력 방식 전환을 다룹니다. 전체 AI 업무 시스템 안에서 회의록이라는 한 기능의 범위를 정한 기록입니다.

녹음 버튼 뒤에 있던 일

처음 만든 웹 화면에서는 녹음을 시작하고 잠시 멈췄다가 이어갈 수 있게 했습니다. 녹음 중인 음성은 브라우저 저장소에 작은 조각으로 남겼습니다. 서버 업로드가 끝나기 전에 화면이나 연결에 문제가 생기더라도, 기기에 남은 원음을 다시 다룰 수 있도록 한 것입니다.

전송도 파일 하나를 보내는 것으로 끝나지 않았습니다. 조각의 순서와 내용이 맞는지 확인하고, 같은 조각을 다시 보냈을 때 중복으로 붙지 않게 했습니다. 서버가 전체 파일을 받았다고 확인한 뒤에야 전사와 회의록 생성을 시작하도록 했습니다. 전사는 음성을 글로 옮기는 단계입니다.

이렇게 하는 이유는 회의록 내용이 이상할 때 어디부터 살펴봐야 하는지 알기 위해서이기도 했습니다. 기기에서 녹음이 끊긴 것인지, 보내는 도중 파일이 달라진 것인지, 음성은 온전하지만 전사가 틀린 것인지에 따라 고칠 곳이 달라집니다.

저장 위치도 확인해야 했습니다. 브라우저에 있는 원음은 다른 기기의 브라우저에 저절로 나타나지 않습니다. 서버로 보내기 전이라면 해당 기기의 저장소를 지웠을 때 잃을 수 있습니다. 그래서 원음을 내려받을 수 있게 하고, 처리에 실패해도 자동으로 지우지 않도록 했습니다.

회의록 기능을 시작했는데, 그 앞단에서 다룰 일이 꽤 많아졌습니다.

짧은 시험이 알려준 범위

9월 17일에는 짧은 합성 음성으로 서버에 원음을 남기고, 전사한 뒤, 회의록 초안을 만드는 흐름을 확인했습니다. 별도의 브라우저 시험에서는 합성 음성을 녹음 장치처럼 넣어 버튼 조작부터 업로드까지 거쳤습니다. 브라우저를 닫았다가 다시 접속해 서버에 결과가 남는 것도 확인했습니다.

여기까지는 입력에서 결과 파일까지 이어지는 경로를 확인한 것입니다. 실제 회의에서 여러 사람이 겹쳐 말하거나, 전문용어를 쓰거나, 마이크에서 멀리 떨어져 말할 때의 품질은 더 살펴봐야 했습니다. 아이폰 화면을 잠근 채 두 시간 동안 녹음하는 조건도 확인하지 못했습니다.

아이폰에서 쓸 녹음 시제품도 시도했습니다. 다만 접속 화면이 열리는 것, 녹음이 저장되는 것, 장시간 녹음 뒤 서버에서 문서가 만들어지는 것은 각각 확인할 일이었습니다. 앞의 한 단계가 됐다고 뒤까지 끝났다고 말하기는 어려웠습니다.

처리 위치 역시 단계마다 달랐습니다. 초기에는 비서 서버 안에서 전사했지만, 그 결과를 회의록으로 정리하는 데에는 기존 비서의 외부 모델 호출을 사용했습니다. 원음이 서버 밖으로 나가지 않는다는 설명만으로 모든 처리가 서버 안에서 끝난다고 생각하면 맞지 않았습니다.

시험이 쌓이면서 제가 확인한 것과 앞으로 책임져야 할 것이 함께 보였습니다. 녹음 기능을 계속 주 경로로 쓰려면 문서 생성뿐 아니라 기기와 음성 처리의 조건도 계속 관리해야 했습니다.

원음 전달과 받아쓰기 오류를 나누어 봤습니다

다음 날에는 실제 시험 녹음의 받아쓰기 결과를 점검했습니다. 이때는 9월 17일의 서버 내부 전사와 다른 처리 경로를 사용한 결과였으므로 두 시험을 같은 조건의 비교로 묶지 않았습니다.

먼저 아이폰의 원음과 서버에 저장된 파일을 비교했습니다. 파일 내용으로 계산한 해시값이 같았습니다. 적어도 이 시험에서는 업로드 과정에서 원음의 바이트가 달라진 흔적은 없었습니다. 그렇다고 녹음 당시의 음질이나 받아쓴 문장까지 맞다는 뜻은 아닙니다.

그다음에는 전사에 넘긴 음성 구간과 결과를 살폈습니다. 구간을 자른 경계나 짧은 조각, 문맥 정보가 부족한 상태를 개선 후보로 남겼습니다. 하지만 지적된 표현이 아주 짧은 구간에서 나온 것도 아니었고, 원인을 확정할 만큼의 비교 시험도 없었습니다. 당시 진단은 파일과 결과를 대조한 범위였으며, 원음을 직접 듣고 정답 받아쓰기를 만든 품질 평가는 아니었습니다.

다음에 무엇을 비교해야 하는지는 구체화됐습니다. 같은 원음을 두고 조건을 바꾸고, 실제로 말한 내용과 대조해야 전사 방식의 차이를 설명할 수 있었습니다.

저는 그 진단과 별개로, 회의록 기능의 입력 범위부터 다시 정했습니다.

제 프로그램의 시작점을 녹취록으로 옮겼습니다

9월 20일에는 녹음과 화자 구분을 클로바노트에서 처리하고, 거기서 내보낸 txt 녹취록을 받기로 했습니다. 녹음 파일은 폰이나 맥에 두고 제 회의록 서버에는 올리지 않는 흐름입니다. 기존 구현과 변경 기록은 보존하고, 새 화면의 시작을 ‘회의 녹음’에서 ‘녹취록 가져오기’로 바꿨습니다.

직접 만들 범위는 이렇게 달라졌습니다.

단계	처음의 주 경로	바꾼 주 경로
녹음과 음성 전송	녹음 화면·기기 저장·서버 업로드를 구현	외부 녹음 도구에서 처리
전사와 화자 구분	서버 처리 경로를 구성하고 품질을 확인	클로바노트에서 내보낸 녹취록을 입력으로 사용
문서 작성	전사 결과로 회의록 초안 생성	녹취록 형식과 화자를 확인하고 회의록 작성
사람의 확인	생성 결과를 검토	입력 수정부터 문서 목적에 맞춘 검토까지 화면에서 안내

이 선택이 클로바노트의 정확도를 비교 시험으로 입증했다는 뜻은 아닙니다. 제가 직접 녹음 경로를 계속 다듬는 것보다, 이미 만들어진 녹취를 받아 사람이 확인할 수 있는 문서로 만드는 쪽에 작업을 집중하기로 한 결정입니다.

입력이 txt로 좁아졌다고 아무 텍스트나 받게 하지는 않았습니다. 프로그램이 기대한 화자·시각 형식으로 읽을 수 있는지 먼저 검사하고, 맞지 않으면 가져오기를 멈추도록 했습니다. 일부만 읽힌 내용을 전체 회의처럼 요약하는 상황을 피하려는 선택이었습니다.

또한 ‘참석자 1’ 같은 화자 표시는 사람 이름으로 확정된 정보가 아닙니다. 녹취록을 받는 단계 뒤에도 이름을 확인하고, 잘못 적힌 표현을 고치고, 결정과 제안을 구분하는 일이 남습니다. 제 프로그램이 맡을 다음 작업은 이 부분이었습니다.

회의록에 더 가까운 문제부터 풀기

직접 만든 녹음 경로는 원음을 어디에 보관하고 어떤 순서로 처리할지 생각하게 해줬습니다. 짧은 시험에서 처리 흐름을 확인했고, 실제 녹음의 전달과 전사 결과를 따로 보는 진단도 해봤습니다. 그 기록은 남겨두되, 주 경로에서는 녹음 기능을 더 확장하지 않기로 했습니다.

이후의 작업은 받은 녹취를 어떻게 고치고, 사람이 확인한 회의록에서 어떤 문서를 만들지로 옮겨갔습니다. 녹음부터 모두 갖춘 도구를 만드는 것보다, 회의 뒤에 다시 읽고 공유할 기록을 얻는 데 필요한 부분을 먼저 만들기로 한 것입니다.

지금 제 회의록 프로그램의 시작점은 녹음 버튼이 아니라 녹취록 파일입니다. 만들려던 결과에 맞춰 시작점을 옮기니, 다음에 확인할 일이 더 분명해졌습니다.