기술 요약: OpsCortex – 자기 진단형 마이크로서비스 시스템을 위한 운영 메모리(Operational Memory)

문제 정의

현대적인 마이크로서비스 아키텍처는 심각한 비대칭성에 직면해 있다: 장애 탐지는 성숙하고 자동화되어 있지만, 근본 원인 국지화(root-cause localization)와 설명은 여전히 수동적이고 느리며 문맥 손실에 취약하다. 결함이 서비스 의존성을 통해 전파될 때, 이는 엔지니어를 압도하는 "경보 홍수(alert floods)"를 유발한다. 확인된 핵심 과제는 다음과 같다:

1. 경보 피로(Alert Fatigue): 임계값 기반 시스템은 기억력이 없다(memoryless). 즉, 무해한 반복 이벤트(예: 야간 배치 작업)와 실제 위기 상황을 구분하지 못한다.
2. 문맥 상실(Lost Context): 라이브 콜 그래프(call graph), 시간대별 베이스라인, 최근 구성 변경 사항과 같은 중요한 진단 데이터는 종종 일시적이거나 분산되어 있어, 진단을 "고고학" 작업으로 만든다.
3. 연쇄 문제(The Cascade Problem): 장애 신호는 위상적(topological)이고 시간적(temporal)이다(누가 먼저 고장이 났고 어떻게 피해가 확산되었는가). 그러나 평면적인 경보 스트림은 이러한 구조를 버려두기 때문에, 근본 원인과 그로 인한 하위 피해자를 구분하기 어렵게 만든다.

본 논문은 자율 운영의 누락된 요소가 더 나은 이상 탐지기나 더 큰 거대언어모델(LLM)이 아니라, 바로 운영 메모리(operational memory), 즉 시스템 동작, 의존성 및 과거 장애에 대한 지속적이고 구조화된 표현이라고 주장한다.

방법론

OpsCortex는 운영 메모리를 4단계 계층 구조로 조직하고, 근본 원인 도출과 설명을 분리하는 멀티 에이전트 프로토타입이다.

1. 4단계 운영 메모리 아키텍처

시스템은 재시작 시에도 시스템이 "눈먼" 상태가 되지 않도록 수명과 목적에 따라 메모리를 계층화한다:

• Tier 1 (Hot Working Memory - Redis): 현재 메트릭 값, 슬라이딩 윈도우, 경보 스트림을 저장하며 짧은 TTL(Time-To-Live)을 가진다. 이는 시스템의 "현재 시제"를 나타낸다.
• Tier 2 (Live Dependency Graph - NetworkX): CALLS 엣지를 가진 3단계 직접 그래프(Service → Category → Metric)이다. 상태는 상향 전파된다(최악의 메트릭이 카테고리 상태를 결정하는 방식 등). 빠른 탐색을 위함이다.
• Tier 3 (Snapshot History - Neo4j): 전체 그래프를 60초마다 직렬화한다. 이를 통해 시스템은 사고 발생 전 몇 분 동안 상태가 어떻게 변했는지 분석하여, 서서히 발생하는 누수(slow leaks)와 갑작스러운 충돌(sudden crashes)을 구분할 수 있다.
• Tier 4 (Permanent Brain - SQLite): "학습된" 상태이다. 서비스/메트릭/시간/요일별 베이스라인, 신뢰도 카운트가 포함된 확정된 호출 엣지, 구조적 노이즈 레지스트리, 그리고 전체 사고 이력을 저장한다. 콜드 스타트(cold start) 시, 이 계층은 새로운 텔레메트리가 도착하기 전에 그래프와 베이스라인을 재구성하여 재시작 시에도 지식을 유지하도록 보장한다.

2. "도출 후 설명(Derive, Then Explain)" 파이프라인

진단 프로세스는 결정론적 로직과 생성형 AI의 강점을 활용하기 위해 두 가지 별개의 단계로 의도적으로 분리된다:

• 단계 1: 결정론적 도출 (Deterministic Derivation):
  • 근본 원인 계산: 시스템은 확정된 CALLS 엣지에 대해 너비 우선 탐색(BFS)을 수행하여 결함과 연결된 모든 서비스를 식별한다.
  • 시간적 순서 지정: 근본 원인은 경고 임계값을 가장 먼저 통과한 서비스($arg \min t_{amber}$)로 식별된다. 이는 원인과 그로 인한 피해자를 분리한다.
  • 노이즈 처리 (Suppress-Then-Detect): 시스템은 구조적 노이즈(예: 무해한 야간 작업)를 학습하고 이에 대한 경보를 억제한다. 그러나 억제는 급격한 스파이크(self z-score), 점진적 드리프트(trend z-score), 또는 동료 서비스와의 상관관계가 있는 이상 징후에 의해 오버라이드(override)된다.
  • 시간 인식 베이스라인: 탐지는 주기적 변동을 고려하기 위해 (서비스, 메트릭, 시간, 요일)별로 버킷화된 베이스라인을 사용한다.
• 단계 2: 생성형 설명 (Generative Explanation):
  • LLM은 결정론적 계층이 근본 원인을 식별하고 증거(결함 경로, z-score, Isolation Forest 점수, 상태 진행 상황)를 수집한 후에만 호출된다.
  • LLM의 임무는 원시 텔레메트리로부터 인과관계를 추론하는 것이 아니라, 제공된 증거를 바탕으로 설명하고, 확인하며, 해결책을 권고하는 것으로 제한된다.
  • 패턴 매칭: 만약 새로운 사고가 영구 브레인(permanent brain)의 알려진 시그니처와 일치하면, 시스템은 이전의 진단을 재구성하여 LLM 호출을 우회한다. 이를 통해 비용과 변동성을 줄인다.

주요 기여

1. 4단계 메모리 아키텍처: 현재 상태, 라이브 토폴로지, 변경 이력, 영구 지식을 분리하여 재시작 시 문맥 손실을 방지하는 설계.
2. 2단계 근본 원인 방법론: 규칙 기반 시스템을 통해 근본 원인을 계산(BFS + 시간적 순서 지정)하고, LLM을 엄격하게 설명자 역할로 한정하여 증거를 사용하는 결정론적 접근 방식.
3. 학습된 Suppress-Then-Detect 라이프사이클: 구조적 노이즈를 침묵시키면서도, 실제 저하(스파이크 또는 드리프트)가 발생할 때 동적으로 억제를 해제하는 메커니즘.
4. 명시적 결함 모드 매핑: 각 설계 선택이 기록된 운영 사고(Slack 2021 및 2022 중단 사례)에서 관찰된 특정 결함 모드를 해결하도록 하는 직접적인 아키텍처 매핑.

결과 및 검증

프로토타입은 요청 급증, 큐 지연, 연쇄 실패, 리소스 고갈을 포함한 8가지 주입 가능한 실패 시나리오가 포함된 계측된 이커머스 벤치마크에서 검증되었다.

• 학습 행동: 시스템은 무해한 반복 패턴(배치 작업)을 학습하고 억제하는 동시에, 해당 작업이 저하될 때 즉시 탐지하고 억제를 해제하는 능력을 성공적으로 입증했다.
• 패턴 우회: 시스템이 알려진 패턴을 식별하여 LLM을 우회하는 데 성공함으로써, 시스템이 "학습"함에 따라 발생하는 비용 효율성 이득을 입증했다.
• 검증 범위: 저자들은 이것이 실세계 데이터나 MicroRCA와 같은 다른 도구와의 비교 정확도 평가가 아니라, 엔드 투 엔드(end-to-end) 메커니즘의 검증임을 명시적으로 밝히고 있다.

의의 및 주장

본 논문은 자율 운영의 병목 현상이 인지가 아니라 메모리라고 단언한다. 탐지 시스템은 풍부하지만, 정상 상태, 의존성 및 이력을 "이해하는" 시스템은 드물다.

OpsCortex는 다음을 위한 구체적인 아키텍처적 논거로서 의의를 갖는다:

• 목표의 재정의: 매 경보마다 처음부터 근본 원인을 추론하는 것에서, 정답이 이미 알려져 있는 "살아있는 모델"을 유지하는 것으로 전환한다.
• 역할 분담: 결정론적 작업(국지화, 순서 지정)은 규칙 기반 시스템에 할당하고, 생성적 작업(설명, 권고)은 LLM에 할당함으로써, LLM의 근본 원인 환각(hallucination) 위험을 줄인다.
• 비용 절감: 노이즈를 억제하고 알려진 패턴에 대해 값비싼 LLM 호출을 우회하도록 학습함으로써 시스템을 시간이 지날수록 "저렴하게" 만든다.

저자들은 프로토토입의 현재 상태에 대해 겸허한 태도를 유지하며, "최초 통과(first-crossing)"를 인과관계의 대리 지표로 사용하는 점(피드백 결합 시스템에서는 실패할 수 있음)과 실제 라벨링된 사고 코퍼스에 대한 평가가 부족하다는 점 등 한계를 인정했다. 향후 연구 과제로 시간적 휴리스틱에서 인과 추론으로의 이동과 실제 사후 분석(post-mortem) 데이터를 통한 검증을 꼽았다.