Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 28. 22:52

Hindsight가 내 에이전트에게 기억력을 부여했다

요약

에이전트의 상태가 없는(stateless) 한계를 극복하기 위해 Hindsight를 활용하여 지속적인 기억력을 부여하는 Incident Response Agent 구축 사례를 소개합니다. 장애 이력을 의미론적 메모리로 저장하고 회상하여, 유사한 장애 발생 시 과거의 해결책을 바탕으로 근거 있는 대응을 제안합니다.

핵심 포인트

  • Hindsight를 통한 에이전트의 지속적 메모리(Retain, Recall, Reflect) 구현
  • 단순 로깅을 넘어선 의미론적 메모리(Semantic Memory) 인덱싱 활용
  • cascadeflow를 이용한 모델 라우팅으로 런타임 지능 최적화
  • Groq를 활용한 빠르고 효율적인 LLM 추론 환경 구축

우리 에이전트가 이미 세 번이나 보았던 Postgres 연결 오류에 대해 네 번째로 "서비스를 재시작하세요"라고 제안했을 때, 나는 문제가 에이전트의 추론 능력이 아니라 에이전트의 기억력에 있다는 것을 깨달았다. 에이전트에게는 기억이 전혀 없었다.

그 순간 나는 다른 무언가를 만들기 시작했다.

시스템이 하는 일

Incident Response Agent는 알람을 분류(triage)하고, 오류를 진단하며, 해결책을 제안하는 AI 기반의 온콜(oncall) 어시스턴트이다. 이는 일반적인 LLM 지식이 아니라, 귀하의 인프라가 이미 겪어온 실제 장애 이력을 바탕으로 작동한다.

장애가 해결될 때마다 에이전트는 발생한 상황을 저장한다: 오류 시그니처(error signature), 근본 원인(root cause), 효과가 있었던 해결책, 그리고 소요된 시간 등이다. 다음에 유사한 알람이 발생하면, 에이전트는 해당 이력을 회상하여 이를 바탕으로 대응을 주도한다. 더 이상 새벽 2시에 아무것도 모르는 상태에서 시작할 필요가 없다.

스택은 간단하다:

  • Hindsight: 에이전트의 지속적인 기억(persistent agent memory)을 처리한다 — 세션 전반에 걸쳐 유지(retain), 회상(recall), 성찰(reflect)한다.
  • cascadeflow: 런타임 지능(runtime intelligence)을 처리한다 — 긴급한 알람은 강력한 모델로, 일상적인 점검은 더 저렴하고 빠른 모델로 라우팅한다.
  • Groq: 기반이 되는 LLM 추론(inference)을 제공한다 (빠르고, 무료 티어 친화적이다).
  • Python 백엔드: 데모를 위한 간단한 CLI 인터페이스와 실제 알람 수집을 위한 웹훅(webhook) 엔드포인트를 통해 이 모든 것을 연결한다.

이 아키텍처는 세 가지 작업을 수행한다: 알람을 수집하고, 기억에서 유사한 내용을 검색하며, 이전에 실제로 효과가 있었던 내용을 바탕으로 근거 있는(grounded) 응답을 생성하는 것이다.

핵심 기술 이야기: 실제로 행동을 변화시키는 기억력

대부분의 에이전트는 설계상 상태가 없는(stateless) 방식이다. LLM에 대한 모든 호출은 백지 상태에서 시작된다. 이는 일회성 작업에는 괜찮지만, 컨텍스트(context)가 전부인 장애 대응(incident response)에서는 치명적이다.

기억력이 없다면 에이전트는 그저 값비싼 Stack Overflow 검색기에 불과하다. 하지만 기억력이 있다면, 모든 것을 경험하고 그 모든 것을 기억하고 있는 시니어 엔지니어에 더 가까운 존재가 된다.

실제 retain/recall 루프가 어떻게 작동하는지 다음과 같다.

장애 저장하기

장애가 해결되면, 우리는 Hindsight에 구조화된 메모리 (structured memory)를 저장합니다:

# memory.py
from hindsight import HindsightClient

...

이것은 단순한 로깅 (logging)이 아닙니다. Hindsight는 이를 의미론적 메모리 (semantic memory)로 인덱싱합니다. 향후 알람 (alert)이 발생했을 때, 키워드 검색 (keyword search)을 수행하는 것이 아니라 의미 검색 (meaning search)을 수행합니다. "5432 포트에서 데이터베이스 연결 거부"와 "Postgres가 새로운 클라이언트를 수락하지 않음"은 표현 방식이 완전히 다름에도 불구하고 동일한 과거 장애 사례를 찾아냅니다.

관련 이력 회상하기 (Recalling Relevant History)

새로운 알람이 발생하면, LLM (Large Language Model)에 접근하기도 전에 Hindsight에게 무엇을 기억하고 있는지 묻습니다:

def recall_similar(error_message: str, top_k: int = 3) -> str:
    results = client.recall(
        pipeline_id=os.getenv("HINDSIGHT_PIPELINE_ID"),
...

이렇게 회상된 메모리들은 프롬프트 컨텍스트 (prompt context)의 일부가 됩니다. 에이전트 (agent)는 해결책을 환각 (hallucinate)하지 않습니다. 대신 지난번에 실제로 무엇이 효과가 있었는지 읽고, 그로부터 추론합니다.

런타임 인텔리전스 (Runtime Intelligence): 모든 알람에 GPT-4가 필요한 것은 아니다

이 부분은 실제 운영 환경 (production)에서 저를 가장 놀라게 했던 지점입니다.

우리는 디스크 사용량 경고, 사소한 지연 시간 스파이크 (latency spike), 전체 데이터베이스 중단 등 모든 개별 알람을 동일한 비용으로 동일한 모델을 통해 라우팅 (routing)하고 있었습니다. 규모가 커지면 이 계산 방식은 성립하지 않습니다. 하루에 40번 발생하는 디스크 경고가 P0 등급의 데이터베이스 장애와 호출당 동일한 비용이 들기 때문입니다.

cascadeflow는 에이전트 루프 (agent loop) 내부에 존재하는 라우팅 레이어 (routing layer)를 통해 이 문제를 해결합니다:

# router.py
from cascadeflow import CascadeFlow

...

budget_limit 파라미터는 제가 더 일찍 알았더라면 좋았을 부분입니다. 이는 단일 호출이 사용할 수 있는 비용에 엄격한 상한선 (hard ceiling)을 설정합니다. 에이전트가 새벽 3시에 깨어나 20개의 병렬 진단 호출 (parallel diagnosis calls)을 실행할 때, 이러한 상한선이 반드시 필요합니다.

cascadeflow가 수행하는 모든 호출은 사용된 모델, 지연 시간 (latency), 비용, 그리고 라우팅 결정 근거 (routing decision rationale)와 함께 기록됩니다. 에이전트가 왜 롤백 (rollback)을 권장했는지 누군가 물었을 때, 이러한 감사 추적 (audit trail)은 매우 중요합니다.

실제 전/후 비교 (What the Before/After Actually Looks Like)

메모리가 없는 경우 (첫 번째 상호작용):

경고: 5432 포트에서 연결이 거부되었습니다.
에이전트: 이 오류는 일반적으로 PostgreSQL 데이터베이스 서비스가 실행 중이지 않거나 도달할 수 없음을 나타냅니다. 일반적인 원인은 다음과 같습니다:
...

일반적이고 교과서적입니다. 틀린 말은 아니지만, 정확히 이 오류를 여섯 번이나 이미 봤다면 유용하지 않습니다.

메모리가 있는 경우 (다섯 번의 유사한 사례가 저장된 후):

경고: 5432 포트에서 연결이 거부되었습니다.
에이전트: 메모리에서 3개의 유사한 사례를 발견했습니다.

...

두 번째 응답은 일반적인 LLM (Large Language Model)의 출력이 아닙니다. 그것은 조직적 지식 (institutional knowledge)입니다. 보통 지난달에 온콜 (on-call) 근무를 했던 사람의 머릿속에만 들어있는 바로 그 종류의 지식 말입니다.

교훈 (Lessons Learned)

1. 메모리의 품질은 해결 시점 (resolution time)에 무엇을 저장하느냐에 달려 있습니다.
에이전트는 자신이 본 장애 데이터 (incident data)만큼만 유용합니다. 우리는 AI 로직 자체보다 해결 워크플로 (resolution workflow)를 고민하는 데 더 많은 시간을 보냈습니다. 즉, 엔지니어가 근본 원인 (root cause)과 해결책을 명확하게 기록하도록 만드는 데 집중했습니다. 쓰레기가 들어가면 쓰레기가 나옵니다 (Garbage in, garbage out).

2. 에러 메시지에는 키워드 검색보다 의미론적 회상 (Semantic recall)이 더 효과적입니다.
에러 메시지는 일관적이지 않습니다. 엔지니어들은 동일한 문제를 열 가지 다른 방식으로 설명합니다. Hindsight의 벡터 기반 회상 (vector-based recall)은 이를 자연스럽게 처리합니다. 단순한 키워드 매칭 방식이라면 관련 기록의 절반은 놓쳤을 것입니다.

3. 운영 환경에서 예산 제한 (Budget caps)은 선택이 아닌 필수입니다.
경고 폭풍 (alert storm)이 발생하여 2분 만에 80번의 에이전트 호출이 일어나는 첫 순간, 당신은 budget_limit를 설정해 두길 잘했다고 생각할 것입니다. cascadeflow의 호출당 제한 (per-call cap) 덕분에 부하 테스트 (load testing) 중에 예상치 못한 청구서를 받는 일을 피할 수 있었습니다.

4. 기본값이 아닌 심각도 (severity)에 따라 라우팅하세요.
대부분의 장애 경고에는 가장 비싼 모델이 필요하지 않습니다. INFO 레벨의 경고는 더 가벼운 모델로 라우팅하고, P0(최우선 순위) 장애를 위해 무거운 모델을 예약함으로써, 응답 품질을 중요한 곳에 유지하면서도 추론 비용 (inference cost)을 크게 절감할 수 있었습니다.

5. 감사 추적 (Audit trail)이 곧 제품입니다.
특히 장애 대응 (incident response)의 경우, 에이전트가 왜 그런 권장 사항을 내놓았는지 아는 것이 권장 사항 자체만큼 중요합니다. cascadeflow의 결정 로그 (decision log)는 별도의 추가 계측 (instrumentation) 없이도 그 정보를 제공합니다.

향후 과제 (Where to Go From Here)

이 프로젝트의 코드는 Hindsight for persistent agent memory를 사용합니다. retain/recall/reflect 프리미티브 (primitives)에 대한 문서는 hindsight.vectorize.io에서 확인할 수 있으며, 에이전트 메모리 (agent memory)가 실제로 실무에서 무엇을 의미하는지에 대한 훌륭한 개념적 개요가 Vectorize 사이트에 마련되어 있습니다.

런타임 인텔리전스 레이어 (runtime intelligence layer)를 위해서는 cascadeflow가 오픈 소스로 제공되며, 한 줄의 명령어로 설치할 수 있습니다. cascadeflow 문서에는 모델 라우팅 (model routing), 예산 집행 (budget enforcement), 그리고 전체 감사 로그 (audit log) 형식이 다뤄져 있습니다.

핵심 통찰은 간단합니다. 기억하는 에이전트는 기억하지 못하는 에이전트보다 범주적으로 훨씬 더 유용하다는 것입니다. 여러분의 온콜 (oncall) 에이전트가 처음으로 "지난 화요일에 이런 일이 있었고, 해결 방법은 다음과 같습니다"라고 말하는 순간, 여러분은 이를 데모가 아닌 인프라 (infrastructure)로 생각하기 시작할 것입니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0