장애 감사를 위한 에이전트를 구축했지만, 수요일이 되면 화요일의 일을 잊어버렸습니다

엔터프라이즈 AI 에이전트 (Enterprise AI agent)를 구축할 때, 신혼의 달콤한 시기는 정확히 프로덕션 (Production)에 배포하기 직전까지만 지속됩니다. 저는 우리 엔지니어링 팀을 위해 컴플라이언스 리스크 (Compliance risks)와 운영 장애 (Operational incidents)를 감사하도록 설계된 AI 에이전트인 "SentinelOps"를 구축했습니다. 초기에는 엄청난 성공을 거두었습니다. 서버 로그의 JSON 덤프 (JSON dump)를 입력받아 메모리 누수 (Memory leak)를 완벽하게 진단하고, 단계별 복구 계획 (Remediation plans)을 제공할 수 있었습니다. 하지만 일주일 후, 정확히 동일한 메모리 누수가 발생했습니다. 저는 SentinelOps에게 어떻게 해야 할지 물었습니다. 에이전트는 불과 며칠 전 우리가 실행했던 성공적인 복구 계획을 완전히 잊어버린 채, 완전히 다른 세 가지 해결책을 환각 (Hallucinate)했습니다. 저의 똑똑한 AI가 심각한 건망증을 앓고 있었던 것입니다. 여기 제가 SentinelOps에 지속적이고 의미론적인 메모리 (Semantic memory)를 부여하기 위해 Hindsight를 사용하여 에이전트를 어떻게 재설계했는지에 대한 내용이 있습니다.

상태 비저장 에이전트 (Stateless Agents)의 문제점
대규모 언어 모델 (Large Language Models, LLM)은 본질적으로 상태 비저장 (Stateless) 방식입니다. 새로운 컨텍스트 윈도우 (Context window)를 열 때마다, 모델은 어제 태어난 것과 같습니다. 많은 개발자들이 원시 대화 로그 (Raw conversation logs)를 다시 컨텍스트 윈도우에 쏟아붓는 방식으로 이를 해결하려 합니다. 이는 끔찍한 아이디어입니다. 토큰 제한 (Token limits)에 믿을 수 없을 정도로 빠르게 도달할 뿐만 아니라, 에이전트의 집중 능력을 파괴합니다. 특정 컴플라이언스 문제를 해결하는 데 도움을 주겠다고 에이전트에게 100페이지 분량의 원시 채팅 기록을 먹이는 것은 에이전트를 혼란스럽게 만들 뿐입니다. 제가 필요했던 것은 진정한 에이전트 메모리 (Agent memory)였습니다. 즉, 에이전트가 과거의 경험을 의미론적으로 검색하고, 현재의 위기와 관련된 정확한 기억만을 검색하여 가져올 수 있는 방법이었습니다.

Hindsight 구현하기
저는 지속적인 메모리 계층 (Persistent memory layer)을 구축하기 위해 Hindsight 문서를 참고했습니다. 원시 채팅 로그를 저장하는 대신, 백엔드 (Backend)를 수정하여 결과와 결정 사항 (Outcomes and decisions)만을 저장하도록 했습니다. SentinelOps가 문제를 성공적으로 진단할 때마다, 구조화된 JSON 요약 (Structured JSON summary)을 생성하도록 강제했습니다. 그런 다음 그 요약을 Hindsight로 직접 파이프라인 연결했습니다:

// backend/services/memoryService.js
import { HindsightClient } from ' @vectorize-io/hindsight-client ' ;
const hindsight = new HindsightClient ({ url : process . env .

HINDSIGHT_URL }); export async function rememberDecision ( interactionId , query , decision ) { try { const memoryDocument = Incident Query: ${ query } Risk Level: ${ decision . riskLevel } Remediation: ${ decision . recommendedAction } Governance: ${ decision . governanceSeverity } ; await hindsight . store ({ id : interactionId , content : memoryDocument , metadata : { domain : decision . domain , timestamp : new Date (). toISOString () } }); } catch ( err ) { console . error ( " Failed to commit to memory: " , err ); } } 이제 새로운 인시던트가 발생하면, 에이전트는 가장 먼저 자체 기록을 조회합니다: export async function recallContext ( query ) { const matches = await hindsight . search ({ query , topK : 3 }); if ( matches . length > 0 ) { return matches . map ( m => m . content ). join ( '

' ); } return null ; } 캐스케이드플로우 최적화 에이전트가 메모리를 갖게 되면서, 컨텍스트 창(context window)의 크기가 조금씩 커졌고, 이는 API 비용 증가로 이어졌습니다. 이를 완화하기 위해 CascadeFlow를 구현했습니다. cascadeflow 문서를 활용하여 라우팅 엔진을 구축했는데, 이 엔진은 비싼 모델에 접근하기 전에 쿼리의 복잡성을 확인합니다. 만약 쿼리가 단순한 정책 조회라면 저렴한 8B 파라미터 모델로 경로를 지정하고, 중요 인프라 장애의 경우 Hindsight 메모리를 가져와 거대한 70B 추론(reasoning) 모델로 경로를 지정합니다. 결과 이 변화는 즉각적이었습니다. 다음 주에 반복적인 Kubernetes 충돌이 발생했을 때, SentinelOps는 추측하지 않았습니다. 대신 다음과 같이 응답했습니다: "4일 전 유사한 인시던트를 기반으로 볼 때, 이는 payment-gateway 서비스의 잘못 구성된 readiness probe일 가능성이 높습니다. 이전 복구 계획을 적용합니다..." 제가 배운 점 원본 로그를 저장하지 마십시오. 원본 대화 기록을 저장하는 것은 쓰레기 입력(garbage-in)이 쓰레기 출력(garbage-out)을 만듭니다. 에이전트가 메모리에 커밋하기 전에 자신의 결정을 요약하도록 강제하십시오. 컨텍스트가 왕입니다(Context is king). LLM에게 3개의 매우 관련성 높은 과거 예시를 제공하는 것이 제로샷 프롬프팅(zero-shot prompting)을 하는 것보다 훨씬 더 나은 결과를 가져옵니다.

메모리(Memory)에는 라우팅(routing)이 필요합니다. 만약 RAG(Retrieval-Augmented Generation)나 메모리 주입(memory injection)을 수행하고 있다면, 이러한 더 큰 컨텍스트 윈도우(context windows)의 연산 비용(compute costs)을 관리하기 위해 CascadeFlow와 같은 지능형 라우터(intelligent router)가 필요합니다.