내가 채팅 기록(Chat History) 사용을 중단하고 사후 기억(Hindsight Memory)을 사용하게 된 이유

고객 지원을 위한 프로덕션급 LLM 에이전트(LLM agent)를 구축해 본 적이 있다면, 토큰 비용이 급증하고 에이전트의 응답 품질이 낭떠러지처럼 떨어지는 정확한 순간을 알고 있을 것입니다. 그것은 에이전트에게 "장기 기억(long-term memory)"을 부여하려는 순진한 시도로, 전체 가공되지 않은 채팅 기록(raw chat history)을 시스템 프롬프트(system prompt)에 전달하기로 결정하는 바로 그 순간입니다.

우리가 처음 고객 지원 에이전트를 구축했을 때—Groq를 통해 Llama 3.3에서 실행되는 전체 PERN 스택 애플리케이션(PostgreSQL, Express, React, Node.js)으로 설계되었습니다—우리는 정확히 이 경로를 따랐습니다. 우리는 모든 과거 사용자 메시지와 에이전트 응답을 순환하는 컨텍스트 윈도우(context window)에 추가했습니다. 작고 단발적인 상호작용이 일어나는 데모 환경에서는 아름답게 작동했습니다. 하지만 실제 환경에서는 빠르게 문제가 발생했습니다. 에이전트는 컨텍스트 윈도우 피로(context window fatigue)를 겪었고, 과거의 문제 해결 세션들을 혼동했으며, 시스템 프롬프트 길이가 확장됨에 따라 엄청난 지연 시간(latency) 급증을 겪었습니다.

다음은 우리가 가공되지 않은 채팅 기록 주입 방식에서 벗어나 Hindsight를 사용하는 구조화된 이중 뱅크 인지 메모리 아키텍처(dual-bank cognitive memory architecture)로 어떻게 전환했는지, 그리고 왜 벡터 데이터베이스(vector databases)나 일반적인 RAG 해킹 방식에 의존하지 않기로 했는지에 대한 내용입니다.

시스템 아키텍처: 어떻게 구성되어 있는가
우리의 고객 지원 시스템은 PERN 스택 아키텍처를 기반으로 구축되었으며, 세 가지 별도의 계층을 조정합니다:

1. 운영 데이터베이스 (PostgreSQL): Neon DB 내부에 저장됨

Postgres는 티켓, 사용자, 메시지 세션의 가공되지 않은 기록과 같은 트랜잭션 엔티티(transactional entities)를 관리합니다. 이는 현재 상태에 대한 신뢰할 수 있는 원천(source of truth) 역할을 합니다.

2. AI 오케스트레이션 백엔드 (Express + Node.js): Groq API(llama-3.3-70b-versatile 모델 사용)와 인터페이스하는 컨트롤러를 실행하고 컨텍스트 컴파일(context compilation)을 조정합니다.

3. 인지 메모리 레이어 (Cognitive Memory Layer, Hindsight Cloud): 장기적인 의미론적 메모리 (semantic memory)를 처리하며, 이는 고객별 개인 기록 (private customer-specific history)과 고객 간 공통 해결책 (cross-customer global resolutions)으로 나뉩니다.

우리의 React 클라이언트에서 고객이 새로운 메시지를 제출하면, Express 백엔드는 단순히 Postgres에서 채팅 로그를 조회하는 것에 그치지 않습니다. 대신, 대화의 의미론적 본질 (semantic essence)을 추출하여 Hindsight에 호스팅된 두 개의 서로 다른 메모리 뱅크 (memory banks)에 쿼리를 보냅니다. 하나는 고객의 사용자 ID (user ID)를 키로 하는 개인용 뱅크이며, 다른 하나는 익명화된 글로벌 해결책 (anonymized global resolutions)을 나타내는 공유 뱅크입니다. 관련 사실들이 가져와져 깔끔한 지침 블록 (instruction block)으로 포맷팅된 후, 최종 응답을 생성하기 전 LLM 시스템 프롬프트 (system prompt)에 주입됩니다.

...