운영 환경 장애 발생 시마다 45분을 허비하던 문제를 해결한 방법

모든 엔지니어링 팀에는 이와 유사한 이야기가 하나씩 있습니다.

새벽 2시입니다. Redis가 다운되었습니다. 온콜 (on-call) 엔지니어는 Slack을 열고 "Redis ECONNREFUSED"를 검색합니다. 847개의 메시지를 스크롤하며 8개월 전의 스레드를 찾아내고, 그날 밤 Arjun이 무엇을 했는지 이해하려고 노력합니다. 하지만 스레드가 불완전하다는 것을 깨닫고, 세 개의 런북 (runbook)을 열어보지만 구체적인 내용은 찾지 못합니다. 결국 팀이 이미 두 번이나 해결했던 문제를 파악하는 데 45분을 허비합니다.

우리는 이 문제를 해결했습니다. 더 나은 런북을 작성해서도, 더 나은 문서화 문화를 강제해서도 아닙니다. 우리의 AI 에이전트 (AI agent)에게 기억력을 부여함으로써 해결했습니다.

문제는 지식이 아니라 회상 (Recall)입니다.

모든 엔지니어링 팀은 이미 대부분의 장애를 해결할 수 있는 지식을 보유하고 있습니다. 그 지식은 Slack 스레드, 종료된 티켓 (tickets), 사후 분석 보고서 (post-mortems), 그리고 시니어 엔지니어들의 머릿속에 존재합니다. 문제는 검색 (retrieval)입니다. 즉, 장애 발생 후 첫 60초 이내에 적절한 사람에게 적절한 지식을 전달하는 것입니다.

일반적인 AI는 여기서 도움이 되지 않습니다. ChatGPT에게 Redis 연결 오류에 대해 물어보면 모든 주니어 엔지니어가 이미 알고 있는 체크리스트를 받게 됩니다. 'Redis가 실행 중인지 확인하세요.', 'redis-cli ping을 시도하세요.', '서비스를 재시작하세요.' 고맙기도 해라, 정말 도움이 되네요.

당신에게 실제로 필요한 것은, 귀사의 특정 인증 서비스 (auth-service)가 지난 3월 14일에 정확히 이 오류를 겪었다는 사실, 근본 원인 (root cause)이 트래픽 급증 시 발생한 maxclients 제한이었다는 사실, 해결 방법은 redis.conf에서 maxclients를 1000으로 늘리는 것이었다는 사실, 그리고 Arjun이 이를 해결하는 데 14분이 걸렸다는 사실을 기억해 주는 존재입니다.

그것이 바로 조직의 기억 (institutional memory)입니다. 그리고 최근까지 그것은 오직 사람들의 머릿속에만 존재했습니다.

우리가 구축한 것

우리는 DevOps 팀의 조직적 기억 역할을 하는 AI 에이전트 — 우리는 이를 장애 기억 에이전트 (Incident Memory Agent)라고 부릅니다 — 를 구축했습니다. 모든 운영 환경 장애는 구조화된 기억 (structured memory)으로 저장됩니다. 새로운 오류가 발생하면, 에이전트는 과거의 장애들을 의미론적 (semantically)으로 검색하여 가장 유사한 사례를 찾아내고, 누가 해결했는지, 얼마나 걸렸는지, 근본 원인이 무엇이었는지를 포함하여 이전에 작동했던 정확한 해결 방법을 반환합니다.

스택 (stack)은 간단합니다:

• React 프론트엔드 (frontend) — 엔지니어가 에러 로그를 붙여넣으면 구조화된 응답을 반환합니다.
• Python FastAPI 백엔드 (backend) — 에이전트 로직과 오케스트레이션 (orchestration)을 처리합니다.
• Hindsight — 과거의 장애 사례를 저장하고 의미론적으로 검색하는 메모리 계층 (memory layer)입니다.
...

아키텍처는 다음과 같습니다:

엔지니어가 에러 로그를 붙여넣음
↓
FastAPI 백엔드가 이를 수신함
↓
Hindsight가 과거 장애 메모리를 검색함
↓
Groq가 검색된 컨텍스트 (context)를 바탕으로 추론함
↓
에이전트가 구체적인 해결책 + 메타데이터 (metadata)를 반환함
↓
해결 방법이 Hindsight에 다시 저장됨

마지막 단계가 매우 중요합니다. 해결된 모든 장애 사례는 메모리로 다시 피드백됩니다. 팀이 장애를 해결할 때마다 에이전트는 더욱 똑똑해집니다.

실질적인 차이를 보여주는 전후 비교

메모리가 왜 모든 것을 바꾸는지 설명하는 가장 좋은 방법은 그 대조를 직접 보여주는 것입니다.

1라운드 — 메모리 없음

입력: FATAL: Redis ECONNREFUSED 127.0.0.1:6379
서비스: auth-service
시간: 오전 03:14

에이전트 응답:
이것은 Redis 연결 문제로 보입니다.
가능한 원인:

• Redis 서비스가 실행 중이 아님
• 잘못된 호스트/포트 설정
• 방화벽이 연결을 차단함

시도해 볼 것: redis-cli ping
확인할 것: systemctl status redis

기술적으로는 맞습니다. 하지만 구체적인 답변이 아니라 체크리스트가 필요한 새벽 3시에는 완전히 쓸모가 없습니다.

2라운드 — Hindsight 메모리 있음

동일한 입력. 에이전트 응답:

auth-service에서 이전에 3번 발생한 적이 있습니다.

가장 최근 일치 사례 — 3월 14일, 오전 02:31:
근본 원인: 트래픽 급증 중 maxclients 제한 도달
적용된 해결책: redis.conf에서 maxclients를 1000으로 상향, Redis 재시작
해결 소요 시간: 14분
해결자: Arjun

권장 해결책:
sudo nano /etc/redis/redis.conf
→ set maxclients 1000
sudo systemctl restart redis

귀하의 환경에 맞는 정확한 명령어를 생성해 드릴까요?

이것이 일반적인 챗봇 (chatbot)과 조직의 지식 (institutional memory) 사이의 차이입니다. 동일한 에러임에도 불구하고 가치는 완전히 다릅니다.

Hindsight가 이를 작동시키는 방법

메모리 계층 (memory layer)이 곧 제품의 전부입니다. 이것이 없다면 여러분은 조금 더 나은 Google 검색 기능을 갖게 될 뿐입니다. 하지만 이것이 있다면, 여러분의 팀이 무언가를 해결할 때마다 지식을 축적하는 에이전트 (agent)를 갖게 됩니다.

Hindsight는 AI 에이전트 (AI agents)를 위해 특별히 구축된 오픈 소스 메모리 시스템 (open-source memory system)입니다. 이는 에이전트 메모리의 두 가지 어려운 문제, 즉 정보를 의미론적으로 검색 가능한 (semantically searchable) 방식으로 저장하는 것과 새로운 입력값이 주어졌을 때 가장 관련성 높은 메모리를 검색 (retrieving)하는 문제를 처리합니다.

이 유스케이스 (use case)에서 Hindsight를 강력하게 만드는 것은 의미론적 검색 (semantic search)입니다. 엔지니어가 에러 로그 (error log)를 붙여넣을 때, Hindsight는 정확한 키워드 일치를 찾는 것이 아니라 의미를 이해합니다. 따라서 약간 다른 문구로 표현되거나 다른 서비스 이름이 포함된 새로운 Redis 에러가 들어오더라도, Hindsight는 근본적인 패턴이 동일하다는 것을 이해하기 때문에 여전히 관련 있는 과거의 인시던트 (incident)를 찾아냅니다.

각 인시던트 (incident)는 Hindsight에 구조화된 메모리 객체 (structured memory object)로 저장됩니다:

results = hindsight.recall(
query=error_log,
top_k=3
)

새로운 에러가 들어오면, 에이전트 (agent)는 메모리를 의미론적으로 검색합니다:

results = hindsight.recall(
query=error_log,
top_k=3
)

그러면 Groq이 검색된 결과에 대해 추론 (reasons)하고, 일반적인 문서가 아닌 여러분 팀의 실제 이력에 기반한 (grounded) 응답을 생성합니다.

에이전트 메모리 (agent memory)가 더 깊은 수준에서 어떻게 작동하는지에 대한 자세한 내용은 Hindsight 문서와 Vectorize 에이전트 메모리 페이지에서 확인할 수 있습니다.

학습 곡선 (Learning Curve)의 모습

이러한 점진적인 발전 과정이 바로 이것을 단순한 검색 도구와 진정으로 다르게 만드는 요소입니다.

1주 차 — 에이전트 (agent)에게 메모리가 없습니다. 모든 응답은 일반적입니다. 엔지니어들은 회의적입니다.

2주 차 — 팀이 15~20개의 인시던트 (incidents)를 해결했습니다. 에이전트 (agent)가 일반적인 에러에 대해 구체적인 해결책을 반환하기 시작합니다. 엔지니어들이 에이전트를 신뢰하기 시작합니다.

2개월 차 — 80건 이상의 장애 사례가 메모리에 축적되었습니다. 에이전트 (agent)는 장애 사례 전반에 걸친 패턴을 인식합니다. 에이전트는 다음과 같이 말하기 시작합니다: “이것은 auth-service가 월요일 아침에 연결 문제를 일으킨 네 번째 사례입니다. 패턴을 분석해 보면 주말 배치 작업 (batch job)이 연결을 해제하지 않고 점유하고 있는 것으로 보입니다.”

방금 언급한 마지막 능력, 즉 시간에 따른 패턴 인식 (pattern recognition)이야말로 메모리 기반 에이전트 (memory-powered agents)를 다른 모든 것과 차별화하는 요소입니다. 단 한 건의 장애는 무엇이 일어났는지를 알려주지만, 50건의 장애는 그것이 왜 계속 발생하는지를 알려줍니다.

이를 구축하며 배운 점

모델의 품질보다 메모리의 품질이 더 중요합니다. 초기에는 다양한 LLM (Large Language Models)을 테스트하며 시간을 보냈습니다. 하지만 가장 큰 개선은 모델을 교체하는 것이 아니라, 메모리에 저장하기 전 장애 기록 (incident memories)을 구조화하는 방식을 개선하는 데서 왔습니다. 데이터베이스 (database)와 마찬가지로, 에이전트 메모리에도 '쓰레기가 들어가면 쓰레기가 나온다 (Garbage in, garbage out)'는 원칙이 동일하게 적용됩니다.

시맨틱 검색 (Semantic search)은 타협할 수 없는 필수 요소입니다. 처음에는 키워드 기반 (keyword-based) 방식을 시도했습니다. 하지만 엔지니어들이 매번 동일한 에러를 서로 다르게 설명하기 때문에 즉시 실패했습니다. Hindsight의 시맨틱 검색은 우리 측의 추가 작업 없이도 이 문제를 해결해 주었습니다.

피드백 루프 (feedback loop)가 곧 제품입니다. 에이전트가 시간이 지남에 따라 더 똑똑해지는 것은 부수적인 효과가 아니라 핵심 가치 제안 (value proposition)입니다. 저장되는 모든 해결된 장애 사례는 다음 장애를 더 빠르게 해결할 수 있게 만듭니다. 두 달이 지난 후, 이러한 복리 효과 (compounding effect)는 극적입니다.

구조화부터 시작하세요. 구조화되지 않은 장애 기록 (unstructured incident notes)은 의미 있는 검색이 어렵습니다. 우리는 초기 단계에서 에러 유형 (error type), 근본 원인 (root cause), 해결책 (fix), 시간 (time), 해결자 (resolver), 결과 (outcome)라는 명확한 스키마 (schema)를 정의하고 이를 강제했습니다. 덕분에 검색 (retrieval)의 유용성이 극적으로 향상되었습니다.

새벽 3시 테스트 (3 AM test)가 여러분의 북극성 (north star)이 되어야 합니다. 우리가 내린 모든 설계 결정에 대해 우리는 다음과 같이 물었습니다: “이것이 새벽 3시에 당직 중인 엔지니어에게 도움이 될 것인가?” 만약 대답이 '아니오'라면, 우리는 그것을 삭제했습니다. 압박감이 심한 상황에서의 단순함 (simplicity)이 곧 제품의 전부입니다.

이것이 나아갈 방향

에이전트(Agent)는 현재 오류 해결에 집중하고 있습니다. 자연스러운 확장 방향은 명확합니다. 즉, 실제 모니터링 스택(monitoring stack)과 연결하여 경고(alert)를 자동으로 수집하고, 반복되는 문제를 선제적으로 표시하는 패턴 분석 레이어(pattern analysis layer)를 구축하며, 인시던트 관리 도구(incident management tools)와 통합하여 메모리 루프(memory loop)가 자동으로 완결되도록 하는 것입니다.

하지만 이를 어디로 확장하든 핵심적인 통찰은 변하지 않습니다. 조직의 지식(institutional knowledge)은 사람의 머릿속에 머물거나 Slack 스레드 속에 파묻혀 있어서는 안 됩니다. 그것은 쿼리(query)가 가능해야 하고, 누적되어야 하며, 새벽 3시에 그것이 필요한 누구에게나 사용 가능해야 합니다.

그것이 바로 우리가 만든 것입니다. 그리고 그것은 실제로 작동합니다.

-Akshara Sharma