서론

지난 1년 동안 저는 데모 중에는 인상적으로 보이지만, 실제 운영 워크로드(workloads)에 노출되면 빠르게 실패하는 여러 AI 에이전트들을 구축해 왔습니다.

패턴은 항상 동일했습니다.

에이전트는 질문에 답하고, 로그를 요약하며, 심지어 일반적인 문제들을 진단할 수도 있었습니다. 하지만 일단 배포되고 나면, 운영상의 문제들이 명확해졌습니다:

• 장애 간의 지속적인 메모리 (persistent memory) 부재
• 알람 폭풍 (alert storms) 발생 시 비용 제어 불가
• 디버깅을 위한 감사 추적 (audit trail) 부재
• 지능적인 모델 라우팅 (model routing) 부재
• 이전 해결책으로부터의 학습 부재

실제로 대부분의 AI 에이전트는 LLM (Large Language Model)을 감싸는 프롬프트 래퍼 (prompt wrappers)에 불과합니다.

운영 인프라를 위해서는 그것만으로는 충분하지 않습니다.

이 프로젝트는 Hindsight와 CascadeFlow를 결합하여 이러한 누락된 요소들을 해결하며, 런타임 실행 (runtime execution)을 지능적으로 관리하는 동시에 과거의 장애로부터 지속적으로 학습하는 장애 대응 에이전트를 생성합니다.

시스템 아키텍처 (System Architecture)

인프라 알람이 트리거될 때마다, 에이전트는 4단계 워크플로 (workflow)를 따릅니다.

1. 장애 심각도 분류
2. Hindsight를 사용하여 유사한 과거 장애 사례 회상
3. CascadeFlow를 사용하여 적절한 LLM으로 요청 라우팅
4. 현재 알람과 과거 컨텍스트 (context) 모두에 기반한 권장 사항 생성

장애가 해결되면, 최종 해결책은 다시 Hindsight에 저장되어 시스템이 시간이 지남에 따라 지속적으로 개선될 수 있도록 합니다.

그 결과, 모든 운영 장애가 미래의 지식이 되는 폐쇄형 학습 루프 (closed learning loop)가 형성됩니다.

왜 Hindsight와 CascadeFlow를 결합하는가?

두 기술이 함께 사용되지만, 이들은 완전히 다른 문제를 해결합니다.

Hindsight: 장기 에이전트 메모리 (Long-Term Agent Memory)

LLM은 Kubernetes, PostgreSQL, Docker, Nginx와 같은 기술에 대해 광범위한 일반 지식을 보유하고 있습니다.

하지만, 여러분의 인프라에 대해서는 아무것도 모릅니다.

그들은 다음을 기억할 수 없습니다:

• 이전의 중단 사고 (outages)
• 성공적인 복구 단계 (remediation steps)
• 서비스별 장애 패턴
• 내부 배포 특이사항
• 과거의 근본 원인 (root causes)

Hindsight는 의미론적 메모리 (semantic memory)를 제공하여, 에이전트가 이전 운영 경험으로부터 유사한 장애 사례를 검색할 수 있도록 합니다.

모든 대화를 제로 베이스에서 시작하는 대신, 에이전트는 조직의 지식 (organizational knowledge)을 바탕으로 시작합니다.

CascadeFlow: 운영 런타임 인텔리전스 (Production Runtime Intelligence)

아무리 유능한 AI 에이전트라 할지라도 다음과 같은 상황에서는 운영하기가 어려워집니다:

• 모든 알림에 대해 비용이 많이 드는 모델을 사용함
• 지출 제한 (spending limits)이 없음
• 실행 로그 (execution logs)를 생성하지 않음
• 라우팅 결정 (routing decisions)을 설명할 수 없음

CascadeFlow는 다음과 같은 기능을 제공함으로써 이러한 런타임 문제를 해결합니다:

• 지능형 모델 라우팅 (Intelligent model routing)
• 예산 집행 (Budget enforcement)
• 요청 로깅 (Request logging)
• 비용 가시성 (Cost visibility)
• 운영 수준의 실행 제어 (Production-grade execution controls)

이러한 도구들은 결합되어 지식 기반이 탄탄하면서도 운영 측면에서 신뢰할 수 있는 에이전트를 구축합니다.

Hindsight를 활용한 메모리 검색 (Memory Retrieval)

LLM에 질의하기 전에, 에이전트는 먼저 관련 있는 과거 장애 사례를 검색합니다.

def recall_similar(error_message: str):
results = client.recall(
pipeline_id=PIPELINE_ID,
query=error_message,
top_k=3
)

if not results:
    return "No similar incidents found."

...

키워드 검색과 달리, Hindsight는 의미론적 검색 (semantic retrieval)을 수행합니다.

예를 들어, 다음과 같은 장애 설명들은 모두 동일한 과거 해결책을 검색해냅니다:

• Database refusing connections (데이터베이스 연결 거부)
• PostgreSQL not accepting clients (PostgreSQL 클라이언트 수락 불가)
• Port 5432 connection refused (5432 포트 연결 거부)

표현 방식은 다르지만, 근본적인 의미는 동일합니다.

이는 전통적인 텍스트 매칭 (text matching) 방식과 비교했을 때 검색 품질 (recall quality)을 크게 향상시킵니다.

CascadeFlow를 활용한 런타임 라우팅 (Runtime Routing)

과거의 문맥 (historical context)이 검색되면, 요청은 CascadeFlow를 통해 전달됩니다.

SEVERITY_MODELS = {
"P0": "groq/llama3-70b-8192",
"P1": "groq/llama3-70b-8192",
"P2": "groq/llama3-8b-8192",
"P3": "groq/llama3-8b-8192",
"INFO": "groq/gemma2-9b-it"
}

심각한 운영 장애에는 더 큰 추론 모델 (reasoning models)을 할당하는 반면, 정보성 알림은 비용과 지연 시간 (latency)을 최소화하기 위해 경량 모델을 사용하여 처리합니다.

또한 각 요청은 런타임 예산 (runtime budget)에 의해 보호됩니다.

response = cf.complete(  
model=model,  
messages=messages,  
budget_limit=0.05  
)

이 안전장치는 경보 루프(alert loop)로 인해 90초 만에 60개 이상의 인시던트(incident)가 발생했던 한 배포 상황에서 매우 귀중한 역할을 했습니다.

예상치 못한 API 비용이 발생하는 대신, 모든 요청은 사전에 정의된 지출 한도 내에서 유지되었습니다.

학습 루프(Learning Loop) 닫기

마지막 단계는 인시던트가 해결된 후에 발생합니다.

def store_resolved(incident):  
    client.retain(  
        pipeline_id=PIPELINE_ID,  
        content=resolution_text,  
        metadata={
            "service": incident["service"],
            "severity": incident["severity"]
        }  
    )

가치 있는 운영 지식을 폐기하는 대신, 모든 성공적인 해결 과정은 에이전트의 장기 기억(long-term memory)의 일부가 됩니다.

다음에 유사한 인시던트가 발생하면, 시스템은 이전에 무엇이 효과적이었는지 이미 알고 있습니다.

주요 실행 흐름 (Main Execution Flow)

오케스트레이션 계층(orchestration layer)은 의도적으로 단순하게 유지됩니다.

def run_agent(alert):
    response = analyze_incident(alert)

    if alert.get("resolved"):
        store_resolved(alert)

지능의 대부분은 오케스트레이션 로직보다는 메모리 및 런타임 계층(memory and runtime layers) 내에 존재합니다.

실행 파이프라인(execution pipeline)을 경량으로 유지하면 시스템을 유지 관리, 디버깅 및 확장하기가 더 쉬워집니다.

에이전트가 시간이 지남에 따라 개선되는 방식

이 아키텍처의 가장 흥미로운 특징은 지속적으로 더 유용해진다는 점입니다.

첫째 날 (Day One)

과거의 기억이 없으므로, 응답은 전적으로 LLM의 사전 학습된 지식(pretrained knowledge)에 의존합니다.

경보(Alert):
Worker Node에서 OOM Killed 발생

응답(Response):
컨테이너 메모리 제한을 확인하고 사용 가능한 RAM 증설을 고려하십시오.

2주 후 (Two Weeks Later)

실제 운영 인시던트를 처리한 후, 응답은 조직의 경험에 기반하게 됩니다.

경보(Alert):
Worker Node에서 OOM Killed 발생

응답(Response):

유사한 인시던트 2개를 발견했습니다.

이전 근본 원인(root cause):
이미지 처리 배치(batch)가 메모리 할당량을 초과함.

성공적인 해결책:

• requests: 512Mi
• limits: 1Gi
• 배치 크기 서킷 브레이커(batch-size circuit breaker) 추가

해결 시간:
11분

오늘의 배치 프로세서(batch processor)가 현재 실행 중인지 확인합니다.

권장 사항은 더 이상 일반적이지 않습니다.

이는 팀 자체의 운영 이력을 반영합니다.

교훈 (Lessons Learned)

개발 과정에서 몇 가지 아키텍처 결정이 특히 가치 있는 것으로 증명되었습니다.

메모리와 런타임(Runtime)을 독립적으로 유지하기

Hindsight는 지식 검색(knowledge retrieval)만을 담당해야 합니다.

CascadeFlow는 실행(execution)만을 담당해야 합니다.

이러한 분리는 테스트와 디버깅(debugging)을 크게 단순화합니다.

프로덕션 투입 전 시드 메모리(Seed Memory) 구축하기

비어 있는 메모리 저장소는 가치가 거의 없습니다.

시스템을 배포하기 전, 우리는 약 30개의 과거 장애 보고서를 Hindsight로 가져왔습니다.

응답 품질의 향상은 즉각적으로 눈에 띄었습니다.

감사 로그(Audit Logs)의 중요성

CascadeFlow의 실행 로그는 빠르게 주요 디버깅 인터페이스가 되었습니다.

예상치 못한 권장 사항이 나타날 때마다, 로그는 다음 내용을 명확하게 보여주었습니다:

선택된 모델 (selected model)
요청 페이로드 (request payload)
실행 비용 (execution cost)
생성된 응답 (generated response)

시맨틱 검색(Semantic Search)은 인간의 가변성을 처리합니다

엔지니어들은 동일한 문제를 동일하게 설명하는 경우가 거의 없습니다.

시맨틱 검색(Semantic retrieval)은 복잡한 태깅 시스템이나 수동 정규화(manual normalization) 없이도 문구의 변화를 자연스럽게 처리합니다.

마치며 (Final Thoughts)

이 프로젝트는 프로덕션 AI 시스템에 관한 중요한 교훈을 강화해 주었습니다.

대규모 언어 모델(Large language models)은 아키텍처의 한 구성 요소일 뿐입니다.

실제 환경의 AI 에이전트에는 다음과 같은 요소들도 필요합니다:

지속적인 조직 메모리 (persistent organizational memory)
지능형 런타임 관리 (intelligent runtime management)
비용 제어 (cost control)
관측 가능성 (observability)
지속적 학습 (continuous learning)

Hindsight는 메모리를 제공합니다.

CascadeFlow는 런타임을 제공합니다.

이들은 함께 단순한 LLM 기반 어시스턴트를, 해결된 장애가 늘어날수록 함께 발전하는 프로덕션 준비 완료된 장애 대응 시스템으로 변모시킵니다.

AI 에이전트가 DevOps 및 사이트 신뢰성 공학 (SRE) 분야에서 점점 더 보편화됨에 따라, 장기 기억 (Long-term memory)과 지능형 실행 (Intelligent execution)을 결합한 아키텍처는 예외가 아닌 표준이 될 가능성이 높습니다.