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

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

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

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

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

상정하는 유스케이스 (Use Case)

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

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

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

전체 아키텍처 (Architecture)

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

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

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

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

인식 결과를 그대로 LLM에 전달하지 말 것

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

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

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

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

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

생성형 AI에 맡길 처리를 분리할 것

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

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

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

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

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

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

RAG로 만든다면, 청크 (Chunk)에 시각 정보를 포함할 것

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

하지만 청크에서 시각 정보를 누락하면 순식간에 사용하기 어려워집니다.

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

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

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

{
"answer": "예산은 다음 회의까지 재견적을 내는 방침입니다.",
"citations": [
...

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

장시간 음성은 작업 (Job)으로 취급할 것

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

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

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

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

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

• upload_failed
• transcription_failed
• normalization_failed
• llm_summary_failed
• indexing_failed

이를 남기지 않으면, 운영 시에 "뭔가 회의록이 안 됩니다"라는 말밖에 알 수 없습니다. 지옥입니다.

보안과 프라이버시를 뒤로 미루지 마라

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

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

최소한, 다음 사항들을 설계에 포함해야 합니다.

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

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

경험으로서 가장 효과적인 것은 「확인할 수 있는 것」

음성 인식과 생성형 AI를 결합하면, 자칫 자동화를 전면에 내세우고 싶어집니다.

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

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

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

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

요약

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

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

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

이 정도까지 만들어야 비로소 「받아쓰기 도구」가 아닌 「다시 들을 수 있는 회의록 경험」이 됩니다.

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

Discussion