모든 영업 이벤트를 메모리 쓰기(Memory Write)로 취급할 때 발생하는 일

LLM 애플리케이션을 구축하는 대부분의 엔지니어들은 메모리를 검색(Retrieval) 문제로 생각합니다. 사용자가 질문을 했을 때 어떻게 올바른 컨텍스트(Context)를 다시 가져올 것인가? 이는 필요하지만, 설계의 절반에 불과합니다. 나머지 절반 — 즉, 실제로 검색 품질을 결정하는 절반 — 은 쓰기 경로(Write path)입니다. 무엇을 저장하는지, 어떻게 구조화하는지, 그리고 언제 기록하는지가 이후의 모든 과정을 결정합니다.

Deal Intelligence Agent를 구축하면서 저는 쓰기 아키텍처(Write architecture)가 대부분의 팀이 조용히 실패하는 지점이라는 것을 배웠습니다. 그들은 너무 늦게 너무 적은 양을 저장하거나, 잘못된 형식으로 너무 많은 양을 저장하며, 그 후 왜 검색 결과에 노이즈가 많은지 의아해합니다. 제가 모든 영업 이벤트를 Hindsight에 대한 명시적인 메모리 쓰기(Memory write)로 취급하며 배운 점은 다음과 같습니다.

모든 것을 기록하는 원칙 (The write-everything principle)

에이전트 메모리(Agent memory)를 구축할 때의 본능은 선택적으로 행동하는 것입니다.

메모리 아키텍처(memory architecture)에서 가장 영향력 있었던 단 하나의 결정은 embedding_text 접두사(prefix) 형식이었습니다.

교훈은 이렇습니다: 모든 외부 의존성(external dependency)은 시스템이 고장 난 것처럼 느껴지는 대신 완성된 것처럼 느껴지게 만드는 로컬 폴백(local fallback)을 가져야 합니다. 폴백은 실제 기능은 아닙니다. 인프라 문제로 인해 작업이 중단되지 않고 실제 기능을 구축할 수 있게 해주는 비계(scaffolding) 역할을 할 뿐입니다.

쓰기 아키텍처(write architecture)가 가능하게 하는 것

모든 것을 기록하고 임베딩 텍스트(embedding text)를 신중하게 설계하면, 에이전트 메모리(agent memory) 레이어는 전체 거래에 대한 쿼리 가능한 감사 추적(audit trail)이 됩니다. 단순히 "무슨 일이 일어났는가"뿐만 아니라 "어떤 순서로, 어떤 채널을 통해, 어떤 결과로 일어났는가"까지 포함합니다.

이는 Autopilot(거래 간 패턴 매칭), Roleplay 시뮬레이터(이해관계자 정확도 기반 트레이닝), 사전 통화 브리핑(단일 쿼리로 포괄적인 컨텍스트 제공), 그리고 리스크 히트맵(입력된 이벤트 빈도를 통한 트렌드 분석)을 위한 기질(substrate)이 됩니다.

이러한 기능 중 그 어느 것도 별도의 데이터베이스나 파이프라인을 구축할 필요가 없었습니다. 쓰기 아키텍처(write architecture)가 첫날부터 이 기능들을 지원하도록 설계되었기 때문에, 이 모든 것은 동일한 Hindsight 메모리 저장소에 대한 쿼리일 뿐입니다.

핵심 통찰: 메모리의 품질은 쓰기 시점(write time)에 결정됩니다. 누군가가 질문을 던질 때쯤이면 답변을 개선하기에는 너무 늦습니다. 신호(signal)가 저장소에 있거나, 혹은 아예 없거나 둘 중 하나입니다.

GitHub: github.com/chaitanya07-ai/deal-intelligence-agent | Live: deal-intelligence-agent-1.onrender.com