AmiVoice API와 생성 AI를 활용하여 '다시 들을 수 있는 회의록'을 만드는 설계 메모

이 기사에서는 음성 인식 API인 「AmiVoice API」와 생성 AI (Generative AI)를 조합하여, 회의나 상담의 녹음을 「나중에 다시 들을 수 있는 회의록」으로 바꾸는 설계를 정리합니다.

단순히 음성을 텍스트로 변환하는 것뿐이라면, 지금은 드문 일이 아닙니다. 문제는 그 다음입니다.

어떤 발언이 어떤 결정으로 이어졌는가
ToDo는 누구에게 할당되었는가
요약이 정말로 원래 발언에 기반하고 있는가
나중에 질문했을 때, 근거가 되는 시점까지 되돌아갈 수 있는가

여기까지 다루어야 비로소 「음성 경험 (Voice Experience)」이라고 부를 수 있습니다.

결론부터 말씀드리면, AmiVoice API는 입구이고, 생성 AI는 출구입니다. 경험의 품질을 결정하는 것은 그 사이에 있는 「인식 결과의 정규화 (Normalization)」, 「근거가 포함된 요약」, 「확인 UI」, 「재처리 가능한 잡 (Job) 설계」입니다.

예를 들어, 영업 회의나 사내 정례 회의의 녹음을 업로드하면 다음과 같은 화면이 돌아오는 앱을 가정해 보겠습니다.

회의 전체 요약
결정 사항
ToDo 및 담당자
미결 사항
중요 발언에 대한 타임스탬프 (Timestamp) 링크
「예산 이야기는 어디 있지?」와 같은 자연어 검색

여기서 중요한 것은 생성 AI의 답변을 그대로 믿게 만들지 않는 것입니다. 회의록은 업무의 근거가 됩니다. 답변에는 원래 발언으로 돌아갈 수 있는 링크가 필요합니다.

최소 구성은 다음과 같이 나눕니다.

계층	역할	주의 사항
프론트엔드 (Frontend)	음성 업로드, 진행 상황 표시, 요약 확인, 질문 UI	장시간 처리를 동기식 화면에서 대기하게 하지 말 것
...

구성을 도식화하면 상당히 수수합니다.

Browser / Mobile
-> API Gateway
-> Lambda: create transcription job
...

수수하지만, 이렇게 분할해 두면 실패 시 재실행이 쉽습니다. 음성 인식만 재실행하고 싶은지, 요약만 다시 만들고 싶은지, 검색 인덱스(Search Index)만 업데이트하고 싶은지를 구분할 수 있습니다.

음성 인식 API의 결과를 그대로 긴 문자열로 생성 AI에 전달하는 것은 추천하지 않습니다.

이유는 단순합니다. 나중에 근거로 돌아갈 수 없게 되기 때문입니다.

최소한 다음과 같은 단위로 정형화한 후 다룹니다.

{
"meeting_id": "mtg_20260522_001",
"segment_id": "seg_00042",
...

이 형식으로 해두면, 생성 AI가 「요금 플랜 비교표를 작성한다」라는 ToDo를 추출했을 때, 원래 발언의 segment_id와 시각을 함께 반환할 수 있습니다.

하나의 거대한 프롬프트 (Prompt)로 요약, ToDo, 리스크, 질의응답을 모두 시키면 유지보수가 어려워집니다.

저는 다음과 같이 나누는 것이 다루기 쉽다고 생각합니다.

회의 전체의 짧은 요약
결정 사항 추출
ToDo 추출
미결 사항·확 확인 사항 추출
사용자 질문에 대한 답변

각각 출력 형식을 고정합니다.

당신은 회의 로그를 정리하는 어시스턴트입니다.
다음의 transcript segments만을 근거로 ToDo를 추출해 주세요.
제약 사항:
...

여기서 중요한 것은 「모르면 모른다고」 출력하게 하는 것입니다. 회의록에서 가장 곤란한 것은 그럴듯한 거짓말입니다.

회의 로그에 대해 「다음 달 예산 이야기는 어떻게 되었지?」라고 물을 수 있게 하려면 RAG (Retrieval-Augmented Generation) 구성을 하고 싶어질 것입니다.

단, 청크 (Chunk)에서 시각 정보를 누락하면 순식간에 사용하기 불편해집니다.

검색 대상 청크에는 본문뿐만 아니라 다음 정보를 포함시킵니다.

meeting_id
segment_id의 범위
start_ms / end_ms
speaker
original_text
normalized_text
embedding text

답변 시에는 생성 AI에게 「인용 ID (Citation ID) 없는 답변은 금지」라고 지시합니다.

{
"answer": "예산은 다음 회의까지 재검토할 방침입니다.",
"citations": [
...

UI 측에서는 citation을 클릭하면 해당 시각부터 음성을 재생할 수 있도록 합니다. 이를 통해 「AI가 그렇게 말했다」가 아니라 「원래 발언으로 돌아갈 수 있다」는 경험이 됩니다.

음성 파일은 텍스트 입력보다 실패 패턴이 많습니다.

파일이 크다
무음 구간이 길다
여러 사람이 겹쳐서 말한다
노이즈가 많다
처리 시간이 길다
사용자가 화면을 닫는다

따라서 동기식 API (Synchronous API)로 전부 반환하는 설계로 하지 않는 것이 안전합니다.

POST /meetings
-> meeting_id를 반환
POST /meetings/{id}/audio
...

실패 시에는 어느 단계에서 실패했는지를 남깁니다.

upload_failed (업로드 실패)
transcription_failed (전사 실패)
normalization_failed (정규화 실패)
llm_summary_failed (LLM 요약 실패)
indexing_failed (인덱싱 실패)

이것을 남기지 않으면, 운영 시에 "왠지 의사록이 안 만들어집니다"라는 말밖에 알 수 없습니다. 지옥입니다.

음성에는 이메일보다 더 생생한 정보가 들어갑니다.

고객명, 가격, 장애, 평가, 채용, 개인정보. 회의 음성은 대체로 위험물입니다.

최소한, 다음 사항들을 설계에 포함하겠습니다.

업로드 시의 동의 표시
보관 기간 명시
원본 음성 및 생성 결과의 삭제 기능
프로젝트 단위의 액세스 제어 (Access Control)
감사 로그 (Audit Log)
LLM에 전달하기 전의 마스킹 (Masking)
외부 API로 보내는 데이터 범위에 대한 설명

특히, 생성 AI (Generative AI)의 요약만 지우고 원본 음성이 남아 있다면 의미가 없습니다. 삭제 요청은 원본, 인식 결과, 요약, 검색 인덱스(Search Index)까지 일관되게 처리해야 합니다.

음성 인식 (ASR)과 생성 AI를 결합하면, 자기도 모르게 자동화를 전면에 내세우고 싶어집니다.

하지만 업무에서 정말로 사용되려면, 자동화보다 확인성이 중요합니다.

좋은 UI는 예를 들어 다음과 같습니다.

요약문 옆에 근거 발언을 표시한다
ToDo에 "담당자 불명" 상태를 허용한다
사용자가 요약을 수정할 수 있다
수정 전의 AI 출력물과 수정 후의 확정본을 분리한다
중요한 결정 사항에는 "확인됨" 플래그를 붙인다

AI가 작성한 의사록을 그대로 공식 기록으로 만들 필요는 없습니다. AI는 초안을 만들고, 사람이 확정한다. 이 역할 분담이 더 현실적입니다.

AmiVoice API와 같은 음성 인식 API와 생성 AI를 결합하면, 단순한 전사를 넘어선 음성 경험을 만들 수 있습니다.

단, 품질을 결정하는 것은 모델의 화려함이 아닙니다.

인식 결과를 발화 단위로 저장한다
타임스탬프 (Timestamp)를 끝까지 잃지 않는다
LLM 처리를 용도별로 나눈다
답변에는 반드시 근거를 붙인다
장시간 음성을 잡 (Job)으로 취급한다
삭제, 권한, 감사를 처음부터 설계한다

이 정도까지 만들어야 비로소 "전사 도구"가 아니라 "다시 들을 수 있는 의사록 경험"이 됩니다.

음성 인식 API는 입구입니다. 생성 AI는 출구입니다. 그 사이의 설계를 소홀히 하면, 편리해 보이기만 하는 위험한 의사록이 만들어집니다. 그 부분을 정성스럽게 만드는 것이 음성 경험의 본체입니다.

AmiVoice API와 생성 AI를 활용하여 '다시 들을 수 있는 회의록'을 만드는 설계 메모

요약

핵심 포인트

댓글