누구도 알아채기 전에 수정하고, 수정할 때마다 더 강력해지기: 자가 치유(Self-Healing) + 재발 방지 (시리즈 4부)

안녕하세요, airCloset의 CTO인 Ryan입니다.

면책 조항 (Disclaimer): 이 글에서 언급되는 "cortex"는 airCloset에서 자체적으로 구축한 AI 플랫폼의 내부 코드네임입니다. 이는 Snowflake Cortex 또는 Palo Alto Networks Cortex와 같은 기존 상용 서비스와는 무관합니다.

3부에서는 AI가 AI의 PR(Pull Request)을 리뷰하는 것 -- 즉, PR 단계에서 품질을 방어하는 자동 리뷰 파이프라인에 대해 다루었습니다.

이 포스트는 그 반대편의 이야기입니다. 바로 **자가 치유 (Self-Healing)**를 통해 운영 환경(production)에서 품질을 방어하는 것입니다. 운영 환경에서 알람(alert)이 발생하면, AI가 이를 조사하고, 수정 PR을 생성하며, 해당 PR은 3부에서 설명한 것과 동일한 자동 리뷰 파이프라인을 거친 뒤, 자동으로 머지(merge)되고 자동 재배포(auto-redeployed)됩니다. 그리고 해당 수정 PR에는 린트 규칙(lint rule), CI 가드(CI guard), 타입 제약(type constraint) 또는 가이드라인 업데이트 등 새로운 가이드(Guide)를 추가하는 것이 필수적으로 요구됩니다. 이를 통해 동일한 안티 패턴(anti-pattern)이 이후부터는 자동으로 거부되도록 합니다. 가드레일(guardrails)이 매번 성장하는 것입니다.

"장애가 자동으로 수정된다"는 말 자체로도 매력적이지만, 장기적으로 그것만으로는 충분하지 않을 수 있습니다. 품질 게이트(quality gates)가 시간이 지남에 따라 복리로 쌓이기 전에, 장애를 수정하는 동시에 재발 유형(recurrence class)을 차단해야 합니다. 즉, 자가 치유(self-healing) 플러스 자가 강화(self-strengthening)가 이루어져야 합니다.

지난달 수치부터 시작해 봅시다

지난 30일 동안 115개의 자가 치유(Self-Healing) PR이 머지되었습니다.

사실상 그들 모두 인간의 개입 없이 머지되고 배포되었습니다.

인간은 AI가 "이것은 코드로 해결할 수 있는 문제가 아니다"라고 판단할 때만 개입합니다.

이것이 현재 cortex의 "장애 대응(incident response)" 상태입니다.

하지만 "115 = 사용자에게 영향을 미친 115건의 장애"라고 읽지는 마십시오. 대략적으로는 다음과 같습니다:

• 약 절반(54건)은 배포 실패(Deploy Failed) 스타일의 알림입니다 -- CI / Pulumi 배포 단계에서 실패를 포착했으며, AI가 이를 프로덕션(Production)에 배포되기 전에 흡수했습니다. 최근 [Recurrence] 루프(후술함)를 통해 이곳에 대한 대응책을 계속 쌓아 올리고 있어, 경험적으로 이 범주의 수치는 감소 추세에 있습니다.
• 나머지 61건은 프로덕션 런타임(Production-runtime) 알림입니다 (서비스 에러 로그 감지 / 파이프라인 실패 / 생성기 실패 등) -- 서비스가 프로덕션에서 실행 중이지만, 에러 로그 임계값 또는 연속 실패 임계값이 트리거되었습니다. AI는 이것이 사용자 영향으로 전파되기 전에 이를 흡수했습니다.

따라서 이는

한 가지 더 언급할 가치가 있는 점은, 이를 수동으로 수행하는 것은 전혀 지속 가능하지 않다는 것입니다. "알림 확인 -> 로그 읽기 -> 컨텍스트 스위칭 (Context Switch) -> 코드 이해 -> 수정 -> PR 생성 -> 리뷰 -> 배포"라는 과정을 115번의 수동 사이클로 반복하는 것은 어떤 팀의 엔지니어링 대역폭 (Engineering Bandwidth)도 파산하게 만들 것입니다. 시스템은 아무도 눈치채지 못하게 에러를 흡수하며, 동시에 그 수정 사항을 새로운 가이드 (Lint / CI Guard / Type Constraint / Guideline)로 변환합니다 -- 이것이 바로 이 포스트의 실제 주제입니다.

알림이 발생하는 순간, AI는 조사를 시작하여 Loki / Product Graph / git blame을 추적해 근본 원인 (Root Cause)을 찾아내고, 수정 PR을 생성하며, 3부의 자동 리뷰를 거쳐 APPROVE -> 자동 병합 (Auto-merge) -> 자동 재배포 (Auto-redeploy)를 수행합니다. 하나의 완전한 루프 (Loop)입니다.

시리즈

#	테마	주요 장면	기사
1	시리즈 소개: cortex harness	관리자 없이 병합되는 PR / 아무도 알아채기 전에 해결되는 장애	ai-harness-intro
...

큰 그림 -- 세 가지 계층: 관찰 (Observation), 복구 (Repair), 강화 (Strengthening)

자가 치유 (Self-Healing)가 작동하려면, 앞단에는 **관찰 계층 (Observation layer)**이 있어야 하고, 뒷단에는 **강화 계층 (Strengthening layer, 재발 방지)**이 있어야 합니다. 자가 치유 그 자체는 중간의 **복구 계층 (Repair layer)**입니다. "자가 치유 + 자가 강화" 루프는 이 세 가지가 모두 갖춰졌을 때만 돌아갑니다.

전제 조건 (Prerequisites): 이 세 가지 계층은 이전의 두 가지 요소인 cpg (Part 2에서 다룬 통합 코드 / 문서 / DB / 인프라 지식 그래프)와 이 포스트에서 다루는 관측성 스택 (Observability stack) 위에서만 구축될 수 있습니다.

• 관측성 (Observability) 부재 -> 관측 계층 (observation layer)이 비어 있어 아무것도 탐지되지 않으며 -> 복구 계층 (repair layer)이 실행조차 되지 않습니다.
• cpg 부재 -> AI가 "이 함정이 다른 어디에 존재하는가"를 볼 수 없습니다 -> 복구 계층은 기껏해야 증상 수준의 패치 (symptom-level patching)에 그치며, 강화 계층 (strengthening layer)의 수평적 확장이 작동을 멈춥니다.

달리 말하면: 이 두 가지 없이 이 설정을 복제하려고 시도하는 것은 단순히 장애 발생 건수를 배가시킬 뿐입니다. 에러 로그만 맹목적으로 바라보며 프로덕션 코드를 다시 쓰는 AI는 gh pr create가 사고를 배포하는 속도만 높일 뿐입니다. cpg와 관측성 (Observability)은 AI에게 자동 복구 (auto-repair)를 위임하기 위한 **최소한의 기준 (minimum bar)**입니다.

또한 cortex는 **수십만 줄 규모의 코드베이스 (codebase)**라는 점에 유의하십시오. 그 정도 규모에서는 전체 코드베이스를 AI 컨텍스트 (context)로 로드하는 것이 (인간은 말할 것도 없고) AI에게도 불가능합니다. AI에게 오직 grep과 파일 읽기만으로 영향도를 추적하라고 명령한다면, 무언가를 찾아내기도 전에 컨텍스트 윈도우 (context window)가 바닥날 것입니다. cpg는 AI가 "이 함수의 변경이 어떤 다른 코드에 파급 효과를 미치는가"라고 질문하고 단 한 번의 단계 (one hop) 만에 답을 얻을 수 있게 해주는 요소입니다. 작은 리포지토리 (repos)에는 이것이 필요하지 않을 수 있습니다. 하지만 일정 규모를 넘어서면 cpg는 선택 사항이 아니라 **필수 사항 (required)**입니다.

1부에서 다룬 Fowler의 가이드 (Guides) / 센서 (Sensors) 용어로 표현하자면, cpg와 관측성 (Observability)은 **가이드 (Guides, 린트(lint)와 같은 실행 전 제어 장치)와 센서 (Sensors, 자동 리뷰 및 자가 치유(Self-Healing)와 같은 실행 후 게이트)를 모두 지원하는 기질 (substrate)**입니다. 관측성 (Observability)은 알람을 발생시킴으로써 센서 (Sensors)에 데이터를 공급하고, cpg는 자동 리뷰에 영향 범위 파악을 위한 컨텍스트 (context)를 제공함으로써 가이드 (Guides) 측에 데이터를 공급합니다.

둘 중 어느 한쪽에만 속하는 것은 아닙 -- 이들은 양쪽 모두의 근간이며, 자가 치유 (Self-Healing)와 자동 리뷰 (auto-review)는 오직 이 기질 (substrate) 위에서만 작동합니다. 이것이 이 포스트를 관통하는 구조적 주장입니다.

계층 (Layer)	역할 (Role)	주요 구성 요소 (Key components)
Observation (관측)	운영 환경의 이상 징후 실시간 탐지	OTel SDK / Loki / Mimir / Tempo / Faro / trace_id가 포함된 Pino 로그
...

순서대로 살펴보겠습니다.

Observation (관측) -- 알림은 어디에서 오는가?

cortex의 운영 관측성 (observability)은 Grafana Cloud + OpenTelemetry를 기반으로 구축되었습니다:

• OTel SDK (공통 @cortex/otel 패키지) -- 모든 서비스는 진입점 (entry point)에서 initOtel({ serviceName })을 호출합니다. 추적 (Trace) / 메트릭 (metric) / 로그 (log)는 모두 OTLP를 통해 Grafana Cloud로 전송됩니다.
• Loki (로그) -- Pino 구조화된 로그 (structured logs)에는 자동으로 trace_id가 부여됩니다. 추적 (trace)과 로그 (log)는 상호 참조됩니다.
• Mimir (메트릭) -- Cloud Run / 파이프라인 (pipeline) / Gemini API 토큰 사용량 등.
• Tempo (추적) -- 분산 추적 (distributed tracing).
• Faro (프론트엔드) -- 브라우저 JS 에러 / 성능 / 네트워크 실패를 캡처합니다.
• Grafana -- 대시보드 (dashboards) + 알림 규칙 (Alert Rules) + 알림 정책 (Notification Policy).

우리는 또한 비즈니스 영향도 (business impact)에 기반한 엄격한 로그 레벨 (log levels) 정의를 가지고 있습니다:

레벨 (Level)	정의 (Definition)	예시 (Examples)
warn	비즈니스 측면에서 예측 가능하며, 즉각적인 조치가 필요하지 않음 (재시도 가능 / 자가 복구 가능).	검색 쿼리 결과가 0건임, 선택적 필드가 설정되지 않음

• UI 오류 (UI errors) -- 로직은 실행되었고 에러 로그도 없지만, 화면이 의도와 다른 것을 보여주거나 잘못된 값을 표시함. Faro는 클라이언트 측 JS 예외(JS exceptions)와 네트워크 실패를 포착하지만, "로직은 실행되었으나 결과값이 틀린" 상황은 경고(alert)를 발생시키지 않음
• 조용한 데이터 오염 (Silent data corruption) -- 집계된 값들이 서서히 드리프트(drift)되거나, 잘못된 값이 테이블에 입력됨. 임계값(threshold)을 넘거나 스키마 체크(schema check)를 통과하지 않는 한 아무것도 이를 감지하지 못함
• 체감되는 UX 저하 (Perceived UX degradation) -- 요청이 느리게 느껴지거나 UX가 어색함. SLO / 지연 시간(latency) 임계값이 트리거되어야만 포착 가능함

따라서 자가 치유(Self-Healing)란 "관측 계층(observation layer)이 포착할 수 있는 장애에 대해, 인시던트 처리 과정에서 인간의 개입(human in the loop)을 AI가 대체하는 것"입니다. 관측 계층 자체의 커버리지가 전제 조건입니다. 관측의 공백은 자동 검토(auto-review)나 자가 치유(Self-Healing)가 도달할 수 없는 사각지대로 남게 됩니다.

이것은 사실 자가 치유의 한계라기보다, 관측 스택(observation stack)을 확장하는 것의 중요성을 의미하며, cortex는 이를 지속적으로 투자하고 있습니다. (1부에 따르면, 관측 가능성(Observability)은 플라이휠(flywheel) 아래의 "지원 기반(supporting foundations)" 중 하나입니다.)

복구(Repair) -- 자가 치유(Self-Healing) 흐름

MODE=self-healing은 3부의 자동 검토 설정과 동일한 webhook-server 스크립트를 실행하지만, Grafana에서 발생하는 경고(alert)를 수신합니다.

텍스트 기반의 흐름은 다음과 같습니다:

[Grafana 경고 규칙(Alert Rule) 발생]
   ↓ POST /webhook/grafana
[이벤트 릴레이 (Event Relay, 사내 구축)] -- Firestore에 저장됨
...

AI가 "이것은 코드 내에서 수정할 수 없음"이라고 판단하면 어떤 일이 벌어지는가