RecallOps 구축하기: 과거 장애로부터 학습하는 AI 장애 대응 에이전트

현대적인 소프트웨어 시스템에서 운영 장애(Operational incidents)는 피할 수 없는 일입니다. API가 실패하고, 키 로테이션(key rotation) 이후 로그인 시스템이 고장 나며, 릴리스(releases)가 잘못되고, 인프라 의존성(infrastructure dependencies)이 최악의 순간에 병목 현상이 됩니다. 오픈 소스 커뮤니티와 기술 팀에게 있어 진정한 과제는 단순히 장애를 빠르게 해결하는 것이 아니라, 각 장애를 통해 다음 대응을 더 개선할 수 있도록 만드는 것입니다. 이것이 바로 우리가 해커톤 프로젝트에서 다룬 문제인 RecallOps의 핵심입니다. RecallOps는 과거의 장애를 기억하고, 지난 실패로부터 패턴을 이해하며, 유사한 문제가 다시 발생했을 때 그 기억을 사용하여 더 나은 조치를 권장하는 AI 장애 대응 에이전트(AI incident response agent)입니다.

문제 정의 (Problem Statement)

전통적인 장애 대응(incident response)은 종종 인간의 기억력에 너무 많이 의존합니다. 팀이 사후 분석 보고서(postmortems)를 작성하더라도, 그 지식은 대개 문서, 채팅, 또는 티켓(tickets) 속에 묻혀 있게 됩니다. 따라서 새로운 장애가 발생하면 대응자들은 종종 처음부터 다시 시작해야 합니다. 최근 배포(deploys)를 확인하고, 대시보드(dashboards)를 스캔하며, 압박감 속에서 근본 원인(root cause)을 추측하려고 노력합니다. 이는 더 느린 분류(triage), 일관성 없는 결정, 그리고 반복되는 실수를 초래합니다. 우리의 목표는 장애 지식—근본 원인, 신호(signals), 완화 조치(mitigations), 해결(resolutions), 그리고 예방 조치(preventive actions)—을 보유하고, 향후 유사한 운영 또는 보안 장애가 발생했을 때 그 지식을 재사용할 수 있는 에이전트를 구축하는 것이었습니다.

핵심 아이디어 (The Core Idea)

우리는 '기억이 첫 번째 대응을 변화시켜야 한다'는 하나의 단순한 믿음을 바탕으로 RecallOps를 설계했습니다. 시스템은 단순히 일반적인 문제 해결 체크리스트를 제공하는 대신, 다음 두 가지 경로를 나란히 비교합니다:

상태가 없는(stateless) 일반적인 분류(triage) 계획,
유사한 과거 장애를 바탕으로 정보가 제공된 기억 기반(memory-backed) 권장 사항.

이로 인해 메모리(memory)의 가치가 명확히 드러납니다. UI에서 “메모리 없음 (Without Memory)” 패널은 광범위하고 절차적인 상태를 유지하는 반면, “사후 기억 포함 (With Hindsight Memory)” 패널은 Redis 캐시 스탬피드 (Redis cache stampedes), JWKS 로테이션 실패 (JWKS rotation failures), CoreDNS 포화 (CoreDNS saturation), 데이터베이스 마이그레이션 잠금 (database migration locks), 토큰 유출 (token leaks), 패키지 배포 오류 (broken package releases)와 같은 구체적인 패턴을 회상합니다. 그 결과, 더 빠른 가설 생성, 더 정밀한 완화 단계 (mitigation steps), 그리고 에이전트가 왜 해당 조치를 권장하는지에 대한 더 명확한 설명을 제공하게 됩니다.

솔루션 접근 방식 (Solution Approach)

RecallOps는 실제 장애 대응 담당자(incident responders)가 사고하는 방식에서 영감을 얻은 메모리 시스템을 사용합니다. 먼저, 과거의 장애 사례들로 시스템에 시드(seed)를 심습니다. 각 장애 사례는 서비스 이름, 심각도 (severity), 증상 (symptoms), 텔레메트리 신호 (telemetry signals), 근본 원인 (root cause), 완화 (mitigation), 해결 (resolution), 예방 (prevention), 그리고 타임라인과 같은 구조화된 필드를 포함합니다. 새로운 장애가 제출되면, 에이전트는 이를 검색 가능한 쿼리 (query)로 변환하고, 유사한 기억을 검색하며, 일치하는 증거를 바탕으로 응답을 합성합니다. 장애가 해결된 후에는 사후 분석 (postmortem) 내용을 다시 메모리에 보관하여 시간이 지남에 따라 시스템이 개선될 수 있도록 합니다. 이는 기억(remember) → 검색(retrieve) → 권장(recommend) → 보관(retain)으로 이어지는 폐쇄형 학습 루프 (closed learning loop)를 생성합니다.

Hindsight를 사용한 이유

우리 프로젝트는 AI 에이전트를 위해 특별히 설계된 메모리 시스템인 Hindsight와 통합됩니다. Hindsight는 우리 솔루션의 핵심인 세 가지 기능, 즉 기억을 저장하는 retain(), 관련 과거 지식을 검색하는 recall(), 그리고 해당 기억을 바탕으로 추론하여 근거 있는 응답을 생성하는 reflect()를 제공합니다. 또한 Hindsight는 다양한 메모리 유형과 다중 전략 검색 (multi-strategy retrieval)을 지원하므로, 단순한 의미론적 검색 (semantic search)만 사용하는 것보다 장애 지식 (incident knowledge) 처리에 더 적합합니다.

Hindsight에서 검색 (retrieval)은 벡터 유사성 (vector similarity)에만 국한되지 않습니다. 문서화된 다중 전략 검색 (multi-strategy search)에는 의미론적 (semantic), 키워드 (keyword), 그래프 (graph), 그리고 시간적 (temporal) 검색이 포함됩니다. 이는 대응자가 단순히 의미론적으로 유사한 텍스트뿐만 아니라, 정확한 기술 용어, 시간 관계, 또는 상관관계가 있는 엔티티 (entities)에 관심을 갖는 경우가 많은 장애 대응 (incident response) 상황에서 특히 유용합니다. 장애 조사 (outage investigation)가 서비스 이름, 메트릭 (metrics), 토큰 식별자 (token identifiers), DNS 장애, 그리고 타임라인 단서와 같은 신호에 크게 의존하기 때문에, 이는 우리의 유스케이스 (use case)와 잘 부합합니다.

아키텍처 및 설계 (Architecture and Design)

높은 수준에서 살펴보면, RecallOps는 프론트엔드 장애 콘솔 (frontend incident console), 백엔드 오케스트레이션 레이어 (backend orchestration layer), 그리고 메모리 레이어 (memory layer)의 세 가지 레이어로 구성됩니다. 프론트엔드는 React로 구축되었으며, 사용자가 활성 장애를 선택하거나 입력하고, 분석을 실행하며, 증거를 검토하고, 새로운 사후 분석 (postmortem)을 유지할 수 있도록 합니다. 백엔드는 Express로 구축되었으며 제어 평면 (control plane) 역할을 합니다. 백엔드는 장애 페이로드 (incident payloads)를 검증하고, 메모리 뱅크 (memory bank)에 데이터를 심으며, 분석을 수행하고, 새롭게 학습된 장애를 저장합니다. 메모리 레이어는 Hindsight를 기반으로 작동하며, 장애 이력을 위한 장기 지식 시스템 (long-term knowledge system) 역할을 합니다.

이 설계의 가장 뛰어난 부분 중 하나는 시스템이 일반적인 추론 (generic reasoning)과 메모리 기반 추론 (memory-backed reasoning)을 명시적으로 비교한다는 점입니다. 백엔드에서 일반적인 추천 함수 (generic recommendation function)는 배포 중단 (freezing deploys), 의존성 확인 (checking dependencies), 상태 통보 (communicating status)와 같은 표준 작업에 집중된 광범위한 분류 플레이북 (triage playbook)을 생성합니다. 반면, 메모리 기반 경로는 관련 장애를 검색하여 이를 더욱 구체적인 근본 원인 가설 (root-cause hypotheses), 완화 계획 (mitigation plans), 검증 단계 (verification steps), 그리고 예방 가이드 (prevention guidance)로 변환합니다. 이러한 병렬 비교는 문제 정의를 명확하게 보여줍니다. 즉, 과거의 지식이 미래의 장애 관리 (incident management)를 측정 가능한 수준으로 개선한다는 것입니다.

또한 설명 가능성 (explainability)을 개선하기 위해 증거 패널 (evidence panel)을 추가했습니다. 시스템은 단순히 권장 사항 (recommendation)만을 출력하는 대신, 기억된 어떤 장애 (incidents)들이 답변에 영향을 미쳤는지 보여줍니다. 이는 장애 대응 (incident response)에서 매우 중요한데, 대응 인력들이 권장 사항을 신속하게 신뢰해야 하기 때문입니다. 관련 장애, 시그널 (signals), 그리고 소스 텍스트를 보여줌으로써 AI는 블랙박스 (black box) 같은 존재가 아니라, 과거의 사후 분석 보고서 (postmortems)를 참조하는 숙련된 팀원처럼 느껴지게 됩니다.

워크플로우 작동 방식

워크플로우는 사용자가 “플래시 쿠폰 출시 후 Checkout API 타임아웃 발생” 또는 “긴급 키 로테이션 후 로그인 실패”와 같은 장애 상황을 입력할 때 시작됩니다. 시스템은 해당 입력을 백엔드 (backend)로 전송하며, 백엔드에서는 스키마 규칙 (schema rules)을 사용하여 이를 검증합니다. 그런 다음 백엔드는 장애의 제목, 서비스, 심각도 (severity), 증상 (symptoms), 시그널 (signals), 그리고 이미 시도된 조치 사항들을 바탕으로 쿼리 (query)를 생성합니다. 만약 Hindsight를 사용할 수 있다면, 앱은 메모리 뱅크 (memory bank)에서 관련 장애를 회상 (recalls)한 다음, 성찰 (reflection) 과정을 거쳐 해당 기억들에 근거한 권장 사항을 생성합니다. Hindsight를 사용할 수 없는 경우에도, 앱은 로컬에 심어진 (seeded) 장애들과 유사도 매칭 (similarity matching)을 위한 점수 시스템을 사용하는 오프라인 데모 모드로 작동합니다.

분석이 끝나면 사용자는 두 가지 출력물을 보게 됩니다: 일반적인 계획 (generic plan)과 메모리에 기반한 계획 (memory-backed plan)입니다. 메모리에 기반한 권장 사항에는 이전 장애들의 영향을 받은 예상 근본 원인 (root causes), 즉각적인 조치, 완화 단계 (mitigation steps), 커뮤니케이션 가이드, 검증 단계, 그리고 예방 아이디어 등이 포함됩니다. 마지막으로, 현재 장애가 해결되면 사용자는 “해결 사항 유지 (Retain Resolution)” 흐름을 통해 근본 원인, 완화, 해결 및 예방 노트를 제출할 수 있으며, 이를 통해 시스템이 해당 장애를 향후 재사용할 수 있도록 저장할 수 있습니다.

우리가 심어놓은 장애 코퍼스 (Incident Corpus)

데모를 현실적으로 만들기 위해, 우리는 다양한 역사적 장애 세트를 준비했습니다. 여기에는 다음이 포함됩니다:

Redis 캐시 스탬피드 (cache stampede)로 인한 체크아웃 지연 (checkout latency),
CoreDNS 포화 (saturation)로 인한 클러스터 전역 DNS 장애,
JWKS 키 로테이션 (key rotation) 이후의 로그인 실패,
데이터베이스 마이그레이션 락 (migration locks)으로 인한 대시보드 중단,
오픈 소스 인프라에서의 퍼블릭 토큰 노출,
오래된 빌드 캐시 (stale build caches)로 인한 패키지 배포 오류.

이러한 예시들은 운영 장애 (operational incidents)와 보안/배포 장애 (security/release incidents)를 모두 다루도록 의도적으로 선택되었으며, 이를 통해 에이전트가 실제 기술 커뮤니티와 오픈 소스 유지 관리 워크플로우를 더 잘 대표할 수 있도록 했습니다.

사용된 기술 (Technologies Used)

RecallOps는 현대적인 TypeScript 우선 스택을 사용하여 구축되었습니다. 프론트엔드(Frontend)는 인터페이스를 위해 React를, 개발 및 번들링을 위해 Vite를 사용합니다. 백엔드(Backend)는 TypeScript에서 실행되는 Express를 사용합니다. 요청 검증 (request validation)을 위해 Zod를 사용하였으며, 이는 장애 입력값과 저장된 사후 분석 보고서 (postmortems)가 잘 구조화되도록 돕습니다. 메모리 작업 (memory operations)을 위해 공식 @vectorize-io/hindsight-client 패키지를 통합했습니다. 개발 워크플로우에는 프론트엔드와 백엔드를 함께 실행하기 위해 tsx와 concurrently를 사용합니다.

또한 우리는 Hindsight Cloud와 로컬/오픈 소스 Hindsight를 모두 지원하도록 프로젝트를 설계했습니다. Hindsight Cloud는 호스팅된 API 엔드포인트와 API 키 흐름을 제공하며, 로컬 설정은 개발자가 실험을 위해 Docker를 통해 Hindsight를 실행할 수 있도록 합니다. 이를 통해 데모의 신뢰성과 향후 확장성 모두를 확보할 수 있는 유연한 프로젝트를 만들 수 있었습니다.

우리가 직면한 과제 (Challenges We Encountered)

가장 큰 과제 중 하나는 사후 분석 보고서 (postmortems)를 재사용 가능한 메모리로 전환하는 것이었습니다. 장애 보고서는 종종 무질서하고, 장황하며, 일관성이 없습니다. AI를 유용하게 만들기 위해 우리는 장애에 대한 명확한 구조를 정의해야 했습니다: 트리거 (trigger), 증상 (symptoms), 신호 (signals), 근본 원인 (root cause), 완화 (mitigation), 해결 (resolution), 예방 (prevention), 그리고 타임라인 (timeline)입니다. 이 구조는 검색 품질 (retrieval quality)과 설명 가능한 권장 사항 (explainable recommendations) 모두를 위한 토대가 되었습니다.

또 다른 과제는 해커톤 데모 중에 가치를 명확하게 입증하는 것이었습니다. "이 AI는 메모리(memory)를 가지고 있습니다"라고 말하기는 쉽지만, 그것이 왜 중요한지 보여주는 것은 훨씬 더 어렵습니다. 이것이 바로 나란히 비교하는 방식(side-by-side comparison)이 매우 중요한 설계 결정이 된 이유입니다. 단 하나의 답변만을 보여주는 대신, 일반적인 분류 (triage)와 메모리 기반 분류 (memory-backed triage)가 어떻게 다른지 보여줍니다. 이를 통해 개선 사항을 가시적이고 직관적이며, 심사위원들이 이해하기 쉽게 만들 수 있었습니다.

우리는 또한 회복 탄력성 (resilience)과 데모의 안정성도 처리해야 했습니다. 라이브 발표 중에 외부 AI나 메모리 서비스에 항상 접속할 수 있는 것은 아니기에, 오프라인 폴백 모드 (offline fallback mode)를 구현했습니다. 이 모드에서는 동일한 시드 기반 장애 코퍼스 (seeded incident corpus)와 로컬 유사도 매처 (local similarity matcher)를 사용하여 UI가 여전히 작동합니다. 이를 통해 외부 메모리 서비스가 실패하더라도 제품이 핵심 개념을 계속해서 보여줄 수 있도록 보장했습니다.

마지막 과제는 구체성과 신뢰성 사이의 균형을 맞추는 것이었습니다. 장애 대응 (incident response)에서 지나치게 자신만만한 AI는 위험합니다. 시스템은 확신하는 척하지 않으면서도 가능성 높은 패턴을 제안해야 합니다. 우리의 설계는 근거 (evidence), 신뢰도 (confidence), 일치하는 장애 사례 (matching incidents), 그리고 검증 단계 (verification steps)를 드러냄으로써 이 문제를 해결하며, 이를 통해 대응자가 권장 사항을 맹목적으로 따르는 대신 실시간 텔레메트리 (live telemetry)를 통해 이를 검증할 수 있도록 합니다.

이 프로젝트가 차별화되는 점

많은 AI 어시스턴트가 경고 (alerts)를 요약하거나 문제 해결 체크리스트를 생성할 수 있지만, RecallOps는 더 실용적인 것, 즉 장애를 위한 조직적 메모리 (organizational memory)에 집중합니다. 단순히 "지금 무엇을 해야 하나요?"라고 묻는 것에 답하는 것이 아니라, "이것과 유사한 일이 이전에 무엇이 있었고, 우리는 그것을 어떻게 해결했는가?"에 답합니다. 이러한 전환은 중요합니다. 왜냐하면 장애 대응은 단순히 가공되지 않은 지능만으로 이루어지는 것이 아니라, 압박 속에서 패턴을 인식하고 이전의 학습을 바탕으로 행동하는 것이기 때문입니다.

메모리 유지 (memory retention), 유사도 기반 검색 (similarity-based retrieval), 성찰 (reflection), 그리고 설명 가능한 근거 (explainable evidence)를 결합함으로써, RecallOps는 챗봇이라기보다는 이전에 유사한 장애를 실제로 경험해 본 장애 대응자 (incident responder)처럼 동작합니다.

향후 범위

이 프로젝트가 해커톤 이후에 발전할 수 있는 몇 가지 방법이 있습니다. 첫째, RecallOps를 PagerDuty, Slack, GitHub Issues, Statuspage 또는 사후 분석 (postmortem) 데이터베이스와 같은 실제 장애 소스(incident sources)와 통합하여, 메모리를 수동으로 입력하는 대신 자동으로 보관할 수 있습니다. 둘째, 에이전트가 메트릭 (metrics), 로그 (logs), 배포 이벤트 (deployment events), 트레이스 (traces)를 직접 소비하여 장애 쿼리 (incident query)를 풍부하게 함으로써 관측 가능성 (observability) 인지 능력을 높일 수 있습니다. 셋째, 대응자가 회상된 장애가 실제로 유용했는지 평가하는 피드백 루프 (feedback loops)를 통해 추천 품질을 개선할 수 있습니다.

우리는 또한 팀별 특화된 메모리 뱅크 (memory banks)에 대한 강력한 잠재력을 보고 있습니다. 조직마다 장애에 대응하는 방식이 다르며, 메모리는 그러한 문화에 적응해야 합니다. Hindsight는 미션 및 추론 (reasoning) 설정을 통해 구성 가능한 뱅크 동작을 지원하며, 이는 플랫폼 팀, 오픈 소스 유지 관리자, DevOps 팀 또는 보안 대응자 (security responders)에게 맞춤화된 장애 에이전트로 나아가는 문을 열어줍니다.

장기적으로 이 개념은 완전한 장애 지휘 코파일럿 (incident command copilot)으로 성장할 수 있습니다. 즉, 발생 가능한 근본 원인 (root causes)을 제안하고, 이해관계자 업데이트 초안을 작성하며, 롤백 (rollback) 또는 격리 (containment) 조치를 권장하고, 해결 후 교훈 (lessons learned)을 자동으로 보존하는 역할을 수행하게 됩니다.

결론

RecallOps는 매우 실질적인 엔지니어링 문제를 해결하려는 우리의 시도였습니다. 팀은 장애로부터 계속 학습하지만, 그들이 사용하는 도구는 거의 학습하지 못합니다. 메모리를 갖춘 AI 장애 대응 에이전트를 구축함으로써, 우리는 과거의 지식이 어떻게 미래의 장애 처리 능력을 향상시킬 수 있는지 보여주었습니다. 이 프로젝트는 더 나은 장애 대응이 단순히 더 빠른 AI 생성에 관한 것이 아니라, 구조화된 메모리, 관련성 있는 회상 (recall), 근거 있는 추천, 그리고 모든 장애 이후의 지속적인 학습에 관한 것임을 입증합니다. 이것이 우리가 이번 해커톤에 가져오고자 했던 아이디어이며, 실용적인 AI 툴링이 나아가야 한다고 믿는 방향입니다.