팀이 약속한 내용을 실제로 기억하는 회의 어시스턴트를 만든 방법

제가 함께 일했던 모든 엔지니어링 팀은 동일한 문제를 겪고 있습니다. 회의가 진행되고 사람들이 무언가를 말하지만, 3번의 스프린트(Sprint)가 지나면 누가 무엇을 약속했는지 아무도 동의하지 못합니다. 회의록은 여기저기 흩어져 있습니다. Slack 스레드는 묻혀버립니다. Jira 티켓은 존재하지만 맥락(Context)이 부족합니다. 매일 스탠드업(Standup) 미팅의 첫 10분은 이미 지나간 대화 내용을 재구성하는 데 소비됩니다.

저는 이에 지쳤습니다. 그래서 단순히 전사(Transcription)만 하는 것이 아니라, 세션 전반에 걸쳐 팀의 패턴을 학습하고 실제 증거를 바탕으로 모두에게 책임을 묻는 AI 회의 어시스턴트를 만들었습니다.

이것이 어떻게 작동하는지, 에이전트 메모리(Agent Memory)에 대해 무엇을 배웠는지, 그리고 왜 가장 어려운 부분이 전사가 아니었는지에 대해 설명하겠습니다.

문제점: 회의는 쓰기 전용(Write-Only)이다

우리는 회의를 쓰기 전용 저장소처럼 취급합니다. 정보는 입력되지만, 어떤 유용한 형태로도 다시 나오지 않습니다. 진짜 비용은 회의실에서 보낸 1시간이 아닙니다. 다음 주에 Sarah가 실제로 인증 미들웨어(Auth Middleware)를 리팩토링하기로 동의했는지, 아니면 단순히 "검토해 봐야 할 사항"이었는지 파악하는 데 드는 20분입니다.

저는 세 가지를 원했습니다:

1. 화자 맥락(Speaker Context)을 포함한 실시간 전사 (Transcription)
2. 실제 약속 사항의 자동 추출 — 모호한 아이디어가 아니라 "Sarah가 목요일까지 X를 수행할 것이다"와 같은 내용
3. 세션 간 메모리 (Cross-session memory) — 이를 통해 어시스턴트는 10번째 회의쯤 되면 당신의 팀이 인프라 작업을 항상 2배 정도 과소평가한다는 사실을 알게 됩니다.

기술 스택 (The Stack)

• Next.js 14 — 웹 앱 및 대시보드
• FastAPI — 백엔드 API 및 웹훅(Webhook) 핸들러
• MongoDB — 원시 전사 데이터, 작업 상태, 감사 로그(Audit logs)
• Redis — 인간의 검토를 위한 스테이징 버퍼, 채팅 기록 (TTL 7일)
• Hindsight Cloud — 에이전트가 실제로 학습할 수 있게 만드는 지속성 메모리 계층 (Persistent memory layer)
• Electron 데스크톱 클라이언트 — 가상 루프백(Virtual loopback, VB-CABLE/BlackHole/PipeWire)을 통해 시스템 오디오를 캡처하고 로컬에서 faster-whisper를 실행

아키텍처는 간단합니다: 오디오 입력 (audio in) → 전사 결과 출력 (transcript out) → LLM 추출 (LLM extraction) → 인간 검토 (human review) → 메모리 저장 (memory retain) → 코파일럿 회상 (copilot recall).

어려운 부분: 에이전트에게 기억하는 법 가르치기 (스스로를 오염시키지 않고)

대부분의 AI 프로젝트가 실패하는 지점이 바로 여기입니다. 모든 것을 기억하려고 시도한다는 점이죠. 가공되지 않은 전사 데이터 (Raw transcripts), 모든 LLM 응답, 모든 상태 업데이트까지 말입니다. 그것은 기억이 아니라 데이터 덤프 (data dump)입니다. 그리고 거기서 정보를 검색하는 데는 비용이 많이 듭니다.

저는 네 가지 별개의 메모리 네트워크 (memory networks)로 생각하도록 강제하는 Hindsight를 사용했습니다. 이 구조는 가장 중요한 설계 결정이 되었습니다.

이로 인해 강제되는 규율: 가공되지 않은 전사 데이터는 MongoDB에 남습니다. 현재 작업 상태 (Current task state)는 MongoDB에 남습니다. 채팅 기록은 Redis에서 만료됩니다. 오직 검증되고 합성된 통찰 (synthesized insight)만이 Hindsight로 들어갑니다.

이는 에이전트가 질문에 답할 때마다 10시간 분량의 전사 데이터를 뒤지는 것이 아님을 의미합니다. 대신 구조화된 경험을 회상합니다: "회의 4에서 Sarah는 인증 리팩토링 (auth refactor)을 약속했습니다. 회의 6에서 그녀는 OAuth 범위 (OAuth scope)에 대한 차단 요소 (blocker)를 제기했습니다. 회의 8에서 그것은 완료로 표시되었습니다."

스테이징 패턴 (The Staging Pattern): 환각 (Hallucinations)이 장기 메모리에 들어오지 못하게 하라

AI 어시스턴트를 망치는 가장 빠른 방법은 발생하지 않은 일을 확신을 가지고 기억하게 만드는 것입니다. 만약 LLM이 작업 할당을 환각 (hallucinate)하고 이를 메모리에 기록한다면, 향후 모든 응답은 오염됩니다.

저는 Redis에 스테이징 버퍼 (staging buffer)를 구현했습니다. 어떤 정보든 Hindsight에 들어가기 전 5분간의 검토 창을 두는 방식입니다:

워크플로우 (The flow):
신뢰도 (Confidence) > 0.9 → 메모리로 자동 승격
신뢰도 (Confidence) < 0.9 → 팀 리더의 승인을 위해 검토 대기열 (review queue)에 머무름
거부됨 (Rejected) → 감사 추적 (audit trail)에 기록되며, 메모리에 절대 반영되지 않음
추출 스키마 (extraction schema)는 반드시 축자적 증거 (verbatim evidence) 필드, 즉 정확한 녹취록 인용구를 요구합니다. 인용구가 없으면 작업도 없습니다. 이는 번거로운 작업처럼 들릴 수 있지만, 실제로는 환각 (hallucination) 필터 역할을 합니다. 만약 LLM이 "Sarah가 목요일까지 인증 리팩토링 (auth refactor)을 처리할 것입니다"라는 정확한 문구를 찾을 수 없다면, 작업을 생성할 수 없습니다.

에이전트가 실제로 학습하는 방법
학습은 마법이 아닙니다. 두 가지 피드백 루프 (feedback loops)를 통해 이루어집니다.
루프 1: 경험 축적 (Experience accumulation)
회의 1회차: 코파일럿 (copilot)은 업로드된 문서에만 기반하여 답변합니다. 당신의 팀에 대해서는 아무것도 모릅니다.
회의 5회차: 회의 후 모든 유지 (retain) 과정에서 구조화된 컨텍스트 (structured context)가 추가되었습니다. 코파일럿이 Hindsight에서 회상할 때, 신뢰도 가중치가 적용된 경험들을 가져오게 됩니다:

루프 2: 의견 교정 (Opinion correction)

리더가 추출된 작업을 거부하거나 사용자가 답변에 '싫어요(thumbs-down)'를 누르면, 해당 신호가 의견 네트워크 (Opinion network)를 업데이트합니다. 에이전트는 당신의 팀이 사용하는 전문 용어 (jargon)를 인식하기 시작하고, 신뢰도 임계값 (confidence thresholds)을 조정하며, 어떤 토론 패턴이 실제 약속으로 이어지는지 아니면 단순한 추측에 그치는지 학습합니다.

회의 10회차 시점의 결과:

"이전 3번의 논의를 바탕으로 볼 때, API 성능 문제가 제기되었으나 공식적으로 할당되지는 않았습니다. 과거 기록을 보면, 귀하의 팀은 인프라 작업에 있어 차단 요소 (blocker) 언급과 작업 생성 사이에 3주의 시차가 있었습니다."

이것은 일반적인 LLM의 답변이 아닙니다. 특정하여 유지된 경험과 관찰된 팀의 행동으로부터 도출된 답변입니다.

루프 닫기: 약속에서 증거로 (Closing the Loop: From Promises to Proof)

사람들이 말하는 내용만 추적하는 회의 어시스턴트는 절반의 유용함만을 가집니다. 나머지 절반은 그 일이 실제로 일어났는지 아는 것입니다.
모든 칸반 (Kanban) 태스크는 고유 키(MM-A1B2C3D4)를 부여받습니다. 개발자들은 이를 PR (Pull Request) 제목이나 커밋 메시지에 포함합니다. GitHub App 웹훅 (webhook)이 머지 (merge)를 감시합니다:

[

]

이제 모든 태스크 카드는 양면을 모두 보여줍니다:

• 약속 (The promise): "Sarah가 목요일까지 인증 리팩토링 (auth refactor)을 처리할 것입니다 — 회의 4, 14:32"
• 증거 (The proof): PR #47, @sarah-dev에 의해 머지됨, CI 통과. 이러한 상호 참조 (cross-reference)가 사후 분석 (post-mortem)과 책임 소재 파악 시 시스템을 신뢰할 수 있게 만드는 핵심입니다.

배운 점 (요약 버전)

1. 무엇인가를 저장하기 전에 메모리 구조를 설계하세요. "모든 것을 저장하라"는 함정입니다. 단 하나의 리테인 (retain) 호출을 작성하기 전에 각 정보 조각이 무엇을 의미하는지 결정하십시오.
2. 스테이징 (Staging)은 선택 사항이 아닙니다. 신뢰도가 낮은 추출 결과에 대한 인간의 검토 (human review)는 메모리 레이어 (memory layer)를 깨끗하게 유지해 줍니다. 확신이 있는 것만 자동으로 승격 (auto-promote)시키세요.
3. 증거 요구 사항은 환각 (hallucination)을 걸러냅니다. 문구 그대로의 인용 (verbatim quotes)을 강제하는 것이 관료적으로 들릴 수 있지만, 사실 이는 구축할 수 있는 가장 좋은 가드레일 (guardrail)입니다.
4. 학습에는 단순히 더 많은 컨텍스트 (context)가 아닌 피드백 루프 (feedback loops)가 필요합니다. 프롬프트 (prompt)가 길어진다고 해서 에이전트 (agent)가 더 똑똑해지는 것은 아닙니다. 행동을 업데이트하는 수정 신호 (correction signals)가 에이전트를 똑똑하게 만듭니다.
5. 인간의 검토는 하나의 기능 (feature)입니다. 저는 완전 자동화를 원했습니다. 하지만 실제로는 스테이징 큐 (staging queue)가 팀 리더들이 실제로 신뢰하는 요소였습니다. 잘못된 추측을 조용히 하기보다는 모호한 부분을 인간의 눈으로 확인하도록 플래그 (flag)를 지정하는 것이 더 낫습니다.

결과

10번의 회의를 거친 후, 이 코파일럿 (copilot)은 회의 번호를 인용하며 과거의 결정 사항들을 언급합니다. 공식적으로 할당되지 않은 채 반복되는 주제들을 플래그 (flag)로 표시합니다. 또한 팀의 이력을 바탕으로 확신을 나타내는 언어 표현을 조정합니다.

더 실질적인 변화는 다음과 같습니다: