회의 음성에서 RAG까지: 녹취록·요약·검색·업무 연결 파이프라인

RAG · LLM 시스템

회의 음성에서 RAG까지: 녹취록·요약·검색·업무 연결 파이프라인

AI아키텍트 2026. 7. 29. 14:59

회의를 녹음하고 AI 요약을 생성하는 것만으로 회의 데이터가 조직의 지식이 되지는 않습니다.

요약 문서는 회의 직후 내용을 빠르게 파악하는 데 유용하지만, 시간이 지나면 다시 찾기 어렵습니다. “지난 분기에 인증 방식 변경을 결정한 회의가 언제였지?”, “담당자가 이번 달까지 처리하기로 한 업무는 무엇이었지?” 같은 질문에 답하려면 여러 회의의 녹취록과 결정사항을 검색할 수 있어야 합니다.

검색 결과가 실제 업무 시스템과 분리돼 있으면 사용자에게 또 다른 수작업이 생깁니다. 관련 회의를 찾은 뒤 이슈 관리 시스템을 열고, 담당자와 기한을 다시 입력해야 하기 때문입니다.

회의 음성을 업무 자산으로 바꾸는 전체 흐름은 다음처럼 볼 수 있습니다.

회의 음성
   ↓
STT·화자·시간 정보
   ↓
녹취록 정규화
   ↓
요약·결정·업무·일정 추출
   ↓
주제별 Chunk·Embedding·Index
   ↓
권한 기반 검색·출처 포함 답변
   ↓
승인된 업무 Tool 실행

중요한 점은 이 흐름을 하나의 거대한 AI 요청으로 처리하지 않는 것입니다. 각 단계의 입력과 출력, 상태, 실패 복구 기준을 분리해야 다시 처리할 수 있고 운영 중인 데이터의 신뢰도를 확인할 수 있습니다.

1. 음성 원본과 처리 작업을 먼저 기록한다

첫 단계는 음성 파일을 STT 모델에 바로 넘기는 것이 아니라 원본과 처리 작업의 관계를 기록하는 것입니다.

업로드 방식은 브라우저 녹음, 실시간 스트림, 서버 녹화, 기존 파일 등록 등으로 달라질 수 있습니다. 어떤 방식이든 다음 정보는 모델 실행 전에 확정하는 편이 좋습니다.

회의와 파일을 구분하는 불투명 식별자
사용자와 조직 또는 테넌트
원본 파일의 저장 위치와 무결성 확인값
미디어 형식, 재생 시간과 언어
수집 시각과 보존 정책
처리 버전과 현재 작업 상태

{
  "meetingId": "opaque-meeting-id",
  "sourceId": "opaque-source-id",
  "tenantId": "opaque-tenant-id",
  "media": {
    "type": "audio",
    "durationMs": 3540000,
    "languageHint": "ko"
  },
  "pipeline": {
    "version": 3,
    "status": "uploaded"
  }
}

파일명이 같다고 같은 회의로 판단하거나, 재업로드할 때마다 새로운 회의를 만들면 중복 데이터가 쌓일 수 있습니다. 원본 식별자, 파일 무결성 확인값, 업무 키를 조합해 중복 등록과 재처리 정책을 정해야 합니다.

개인정보나 민감한 회의가 포함될 수 있으므로 원본 음성, 녹취록, 요약, 검색 Index의 보존 기간과 삭제 전파 정책도 이 단계에서 함께 결정해야 합니다.

2. STT 결과를 문장이 아니라 시간축 데이터로 저장한다

STT 결과를 긴 문자열 하나로 저장하면 읽을 수는 있지만 이후 단계에서 활용하기 어렵습니다.

검색 결과를 원본 음성 위치로 연결하거나, 특정 발언을 근거로 보여 주거나, 화자별 업무를 추출하려면 최소한 시작·종료 시각과 화자 정보를 유지해야 합니다.

{
  "segmentId": "segment-0042",
  "meetingId": "opaque-meeting-id",
  "startMs": 782000,
  "endMs": 795400,
  "speaker": "SPEAKER_02",
  "text": "다음 배포 전에 접근 권한 검증을 완료하겠습니다.",
  "confidence": 0.91
}

Faster-Whisper는 Segment와 단어 수준의 시작·종료 시각을 제공할 수 있고, VAD(Voice Activity Detection)를 이용해 음성이 없는 구간을 필터링할 수 있습니다. 하지만 STT와 화자 분리는 같은 작업이 아닙니다.

STT는 음성을 텍스트로 변환합니다.
화자 분리는 누가 어느 구간에서 말했는지 추정합니다.
참석자 이름 연결은 확인된 사용자 정보와 별도의 매핑이 필요합니다.

SPEAKER_02를 근거 없이 실제 참석자 이름으로 바꾸면 잘못된 발언 귀속이 발생할 수 있습니다. 자동 매핑 결과에는 신뢰도와 확인 상태를 두고, 중요한 결정이나 업무 지정에는 사람이 수정할 수 있는 경로를 제공하는 것이 안전합니다.

WebVTT 같은 형식은 시간에 맞춘 자막과 화자 표기를 내보낼 때 유용합니다. 다만 내부 데이터는 자막 파일보다 더 풍부한 Segment 구조로 보관해야 검색, 수정 이력과 원문 연결을 안정적으로 지원할 수 있습니다.

3. 원본 녹취록과 AI 생성 결과를 분리한다

녹취록을 문장 정리 모델에 통과시키면 맞춤법과 문맥이 좋아질 수 있지만, 원래 발언이 바뀔 위험도 생깁니다.

따라서 다음 데이터를 서로 다른 계층으로 관리하는 것이 좋습니다.

데이터	역할	수정 원칙
원본 음성	최종 근거	변경하지 않음
STT 원문	모델이 인식한 결과	버전과 모델 정보를 보존
교정 녹취록	사람이 읽기 좋은 문장	원문과 차이를 추적
AI 요약	회의 전체 이해	다시 생성 가능
결정·업무 구조	검색과 자동화	근거 Segment를 연결

요약 모델이 잘못된 일정을 만들어도 STT 원문과 원본 음성까지 덮어쓰지 않아야 합니다. 생성 결과는 파생 데이터로 관리하고, 어떤 녹취록 버전과 어떤 Prompt·모델로 만들었는지 기록하면 재생성과 오류 분석이 쉬워집니다.

4. 요약보다 구조화된 회의 사실이 중요하다

한 문단의 요약만 저장하면 읽기는 편하지만 검색과 업무 연결에 필요한 의미를 다시 추출해야 합니다.

회의 결과를 다음처럼 구조화하면 목적별로 사용할 수 있습니다.

{
  "summary": "접근 권한 검증과 배포 일정을 논의했습니다.",
  "decisions": [
    {
      "text": "배포 전에 권한 검증을 완료한다.",
      "evidenceSegmentIds": ["segment-0042", "segment-0043"]
    }
  ],
  "actionItems": [
    {
      "text": "권한 테스트 결과를 정리한다.",
      "assigneeRef": "participant-02",
      "dueDate": "2026-08-07",
      "status": "proposed",
      "evidenceSegmentIds": ["segment-0042"]
    }
  ],
  "openQuestions": [
    {
      "text": "외부 사용자 정책을 같은 배포에 포함할 것인가?",
      "evidenceSegmentIds": ["segment-0047"]
    }
  ]
}

여기서 핵심은 evidenceSegmentIds입니다. 결정사항과 업무가 어느 발언에서 나왔는지 연결해야 사용자가 AI 결과를 검증할 수 있습니다.

담당자와 기한이 녹취록에 명확하지 않다면 빈 값이나 proposed 상태로 남겨야 합니다. 모델이 그럴듯한 값을 채우는 것보다 “확인 필요”를 표현하는 것이 운영 시스템에서는 더 안전합니다.

5. 회의 RAG는 주제와 시간 흐름을 함께 Chunking한다

일반 문서는 제목과 문단 경계를 기준으로 나눌 수 있습니다. 회의 녹취록은 대화가 이어지고 화자가 바뀌며, 앞선 문장을 전제로 한 표현이 많다는 점이 다릅니다.

“그 방식으로 진행하죠”라는 문장만 검색 Index에 넣으면 무엇을 승인한 것인지 알 수 없습니다. 고정 글자 수로 기계적으로 나누면 질문과 답에 필요한 앞뒤 문맥이 서로 다른 Chunk로 갈라질 수 있습니다.

회의 Chunk는 다음 순서로 만드는 방법이 실용적입니다.

긴 무음, 안건 전환, 주제 변화로 후보 경계를 찾습니다.
너무 짧은 발언은 앞뒤 발언과 묶습니다.
질문과 답변, 제안과 결정은 가능한 한 같은 Chunk에 둡니다.
Chunk가 너무 길어지면 화자 전환과 시간 간격을 기준으로 다시 나눕니다.
각 Chunk에 회의·시간·화자·주제·근거 Segment 정보를 붙입니다.

{
  "chunkId": "meeting:opaque-meeting-id:v3:chunk:0012",
  "meetingId": "opaque-meeting-id",
  "transcriptVersion": 3,
  "startMs": 756000,
  "endMs": 821000,
  "speakers": ["SPEAKER_01", "SPEAKER_02"],
  "topic": "배포 전 권한 검증",
  "text": "질문과 답변을 포함한 주제 단위 녹취 내용",
  "sourceSegmentIds": [
    "segment-0039",
    "segment-0042",
    "segment-0043"
  ]
}

chunkId에 회의와 녹취록 버전을 포함하면 같은 파일이 다시 처리됐을 때 어떤 Index가 최신인지 판단하기 쉽습니다. 구체적인 멱등 인덱싱과 재처리 전략은 별도 글에서 더 자세히 다룰 수 있습니다.

6. Vector Search 앞에 권한과 메타데이터 필터가 있다

RAG는 언어 모델의 파라미터 안에만 의존하지 않고 외부 지식 저장소에서 관련 문서를 검색해 생성에 사용합니다. 회의 시스템에서는 이 외부 지식이 녹취 Chunk, 요약, 결정사항과 업무 항목이 됩니다.

검색 흐름을 단순화하면 다음과 같습니다.

사용자 질문
   ↓
사용자·테넌트·회의 접근 권한 확인
   ↓
기간·참석자·프로젝트·문서 유형 필터
   ↓
Vector Search + Keyword Search
   ↓
중복 제거·재정렬
   ↓
원문 근거와 함께 LLM에 전달
   ↓
출처가 포함된 답변

Vector Search가 권한 검사를 대신할 수는 없습니다. 다른 조직의 Chunk를 검색한 다음 답변 단계에서 숨기는 방식은 이미 검색 결과에 데이터가 노출된 뒤일 수 있습니다. 검색 대상 자체를 사용자와 테넌트 권한으로 제한해야 합니다.

pgvector 공식 문서도 여러 테넌트가 하나의 근사 Index를 공유하면 검색 재현율과 속도에 서로 영향을 줄 수 있다고 설명하며, 필요한 경우 Partition 또는 별도 Table을 이용한 격리를 제시합니다.

의미가 비슷한 문장을 찾는 Vector Search와 정확한 제품명·약어·이슈 번호를 찾는 Keyword Search는 장점이 다릅니다. pgvector는 PostgreSQL Full Text Search와 결합한 Hybrid Search, 순위 결합 또는 재정렬 방식을 안내합니다.

어떤 방식이 더 좋은지는 데이터와 질문에 따라 달라지므로 다음 지표를 실제 질문 세트로 측정해야 합니다.

관련 Chunk가 검색됐는가
올바른 회의와 시간 구간을 가리키는가
다른 테넌트의 결과가 섞이지 않는가
정답 근거가 상위 결과 안에 포함되는가
답변이 검색 근거 밖의 내용을 추가하지 않는가

7. 답변에는 회의로 돌아갈 수 있는 출처가 필요하다

“어느 회의에서 나온 이야기인지”만 보여 주는 것으로는 부족합니다. 사용자가 해당 발언을 바로 확인할 수 있도록 회의, 시간 구간과 화자를 출처로 제공해야 합니다.

{
  "answer": "배포 전에 접근 권한 검증을 완료하기로 결정했습니다.",
  "citations": [
    {
      "meetingId": "opaque-meeting-id",
      "startMs": 782000,
      "endMs": 810000,
      "speaker": "SPEAKER_02",
      "excerpt": "다음 배포 전에 접근 권한 검증을 완료하겠습니다."
    }
  ],
  "confidence": "supported"
}

출처는 모델이 답변 뒤에 임의로 만드는 문자열이 아니라 검색 결과의 메타데이터에서 구성해야 합니다. 답변에 사용할 근거가 없다면 “확인할 수 없음”을 반환할 수 있어야 합니다.

시간 정보는 UX에도 연결됩니다. 사용자가 출처를 클릭하면 녹음 또는 영상의 해당 위치로 이동하고, 관련 녹취 Segment를 강조하면 검증 비용을 크게 줄일 수 있습니다.

8. 검색과 업무 실행 사이에 승인 경계를 둔다

RAG 답변에서 업무 항목을 발견했다고 바로 이슈를 생성하거나 일정을 변경해서는 안 됩니다.

지식 검색과 업무 실행은 다음처럼 분리합니다.

[질문]
지난 회의에서 합의한 후속 업무를 알려줘
        ↓
[RAG]
업무 후보 + 근거 발언 + 담당자·기한
        ↓
[사용자 확인]
생성 대상과 입력값 검토
        ↓
[MCP Tool]
issue_create 또는 issue_status_update
        ↓
[업무 시스템]
권한 재검증 + 실행 + 감사 로그

MCP Tool 결과는 구조화된 데이터를 제공할 수 있으므로 생성된 업무의 ID, 상태와 원본 회의 연결 정보를 후속 흐름에서 사용할 수 있습니다. 하지만 회의 ID나 사용자 ID는 권한 자체가 아닙니다. Tool Server는 모든 호출에서 사용자·테넌트·대상 데이터의 접근 권한을 다시 검증해야 합니다.

회의 내용에 “업무를 등록해 줘”라는 문장이 포함돼 있더라도 그것은 녹취 데이터이지 현재 사용자의 실행 명령이 아닙니다. 회의 원문, 검색 결과와 외부 문서를 신뢰할 수 없는 입력으로 취급하고, 실제 변경은 현재 사용자의 명시적 의도와 승인에 따라 실행해야 합니다.

9. 전체 파이프라인은 비동기 상태 머신으로 운영한다

한 시간짜리 회의를 업로드한 HTTP 요청 안에서 STT, 요약, Embedding과 Index 저장까지 모두 끝내려고 하면 Timeout과 부분 실패를 처리하기 어렵습니다.

각 단계를 독립된 작업으로 구성하고 상태를 저장하는 편이 안전합니다.

UPLOADED
  → TRANSCRIBING
  → TRANSCRIPT_READY
  → STRUCTURING
  → STRUCTURED
  → INDEXING
  → READY

실패 상태도 전체 실패 하나로 표현하지 않습니다.

TRANSCRIPTION_FAILED
STRUCTURING_FAILED
INDEXING_FAILED

요약이 실패해도 이미 생성된 녹취록을 조회할 수 있고, Index 저장이 실패하면 STT를 다시 실행하지 않고 Index 단계만 재시도할 수 있어야 합니다.

다음 항목을 작업별로 기록하면 운영과 장애 분석이 쉬워집니다.

입력 데이터와 버전
시작·완료 시각
처리 모델과 설정 버전
재시도 횟수
오류 유형과 추적 ID
생성된 결과의 식별자
다음 재시도 가능 여부

재시도와 수동 재실행이 같은 결과를 중복 생성하지 않도록 단계별 멱등성 키와 Upsert 기준도 필요합니다.

운영 전 점검 체크리스트

점검 영역	확인 질문
원본	음성과 STT·요약·Index의 관계를 추적할 수 있는가
중복 방지	재업로드와 재처리 시 같은 회의가 중복 생성되지 않는가
STT	시간 구간과 모델·설정 버전을 보존하는가
화자	자동 화자와 실제 참석자 매핑의 확인 상태가 있는가
파생 데이터	원문, 교정본, 요약과 구조화 결과가 분리돼 있는가
근거	결정사항과 업무가 원본 Segment를 참조하는가
Chunk	주제와 대화 문맥을 유지하며 원문으로 돌아갈 수 있는가
검색 권한	Vector 검색 전에 사용자·테넌트 범위를 제한하는가
검색 품질	실제 질문과 정답 근거로 Retrieval을 평가하는가
답변	출처 회의·시간·화자를 제공하고 근거 없음을 표현하는가
업무 실행	검색 결과와 Tool 실행 사이에 사용자 승인이 있는가
복구	STT·요약·Index 단계를 독립적으로 재시도할 수 있는가
삭제	원본 삭제가 녹취록·요약·Chunk·Index에 전파되는가
감사	조회와 변경 작업을 추적하되 민감정보를 과도하게 남기지 않는가

마무리

회의 RAG의 핵심은 녹취록을 Vector Database에 넣는 것이 아닙니다.

신뢰할 수 있는 시스템을 만들려면 다음 연결이 모두 유지돼야 합니다.

원본 음성과 STT Segment가 시간축으로 연결돼야 합니다.
요약, 결정사항과 업무가 근거 발언으로 돌아갈 수 있어야 합니다.
Chunk와 Index가 회의·버전·권한 정보를 유지해야 합니다.
검색 답변에는 사용자가 검증할 수 있는 출처가 있어야 합니다.
업무 실행은 검색과 분리하고 사용자 승인과 서버 권한 검사를 거쳐야 합니다.
각 처리 단계는 실패 후 독립적으로 재시도할 수 있어야 합니다.

좋은 회의 AI는 회의 내용을 그럴듯하게 요약하는 시스템에서 끝나지 않습니다. 과거 결정의 근거를 다시 찾고, 필요한 업무를 확인한 뒤, 승인된 실행까지 연결하는 지식 파이프라인이어야 합니다.

다음 글에서는 이 파이프라인을 기업 시스템에 배치할 때 Java Security Gateway와 Python AI Orchestrator의 책임을 어떻게 나눌지 살펴보겠습니다.

참고 자료

이 글은 2026년 7월 29일 기준 공개된 공식 문서와 공개 가능한 상용 운영 경험을 바탕으로 작성했습니다. 실제 구현에서는 데이터 보안 등급, 사용 중인 STT·Embedding 모델, 검색 엔진과 업무 시스템의 지원 범위를 함께 확인해야 합니다.

'RAG · LLM 시스템' 카테고리의 다른 글

음성에서 인사이트까지: 실시간 STT·RAG로 만드는 실제 데이터 파이프라인 (1)	2026.08.02
웹 리서치 RAG: 공개 웹 문서 추출·청킹·Semantic Search를 MCP로 제공하기 (0)	2026.07.30
한국어 문서 청킹 설계: 종결어미·임베딩 토큰 한도·회의 발화 (0)	2026.07.30
RAG 운영 설계: 멱등 인덱싱 (Idempotent Indexing)과 중복 Chunk 방지 (0)	2026.07.29

현재글회의 음성에서 RAG까지: 녹취록·요약·검색·업무 연결 파이프라인

AI 아키텍처 기술 블로그

수년간 개발 경험으로 전하는 AI 에이전트, RAG, MCP와 시스템 아키텍처 실전 기록

Spring Security, ai 도입, tool calling, AI Agent 보안, Production Readiness, Secure coding, STT, owasp top 10, spring boot, Rag, SDK 설계, 기업 AI Agent, faster-whisper, embedding, MCP 보안, mcp, java, 엔터프라이즈 아키텍처, Private API, ai agent,

Today :
Yesterday :

일	월	화	수	목	금	토
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

AI 아키텍처 기술 블로그