Netflix 관측성 지식 그래프 정리: AI 에이전트 장애 조사 설계

3줄 요약

• Netflix가 애플리케이션, 인시던트, 배포, 알림, 인프라 의존성 정보를 온톨로지(개념과 관계를 정의한 공통 모델) 기반 지식 그래프로 연결해 장애 조사 속도를 높이려 하고 있습니다 ^[1].
• RDF, OWL, SHACL, SPARQL 같은 시맨틱 웹 표준을 쓰며, 그래프는 Rust의 redb 스토리지 엔진 위에 만든 자체 분산 RDF 데이터베이스 QuipuDB에 저장합니다 ^[1].
• 이 그래프는 사내 에이전트형 근본 원인 분석 시스템 AutoRCA의 공통 인터페이스가 되며, 제안된 조치의 승인 권한은 사람이 유지합니다 ^[1].

무엇이 바뀌었나

발표에 따르면 Netflix는 하루 20억 건 이상의 요청과 초당 3,800만 건 이상의 실시간 로깅 이벤트를 처리하고, 2024년 11월 제이크 폴과 마이크 타이슨 경기 때는 약 6,500만 동시 스트림을 감당했습니다 ^[1]. 그런데 일반적인 애플리케이션 회귀(성능·기능 저하) 하나를 조사하는 데 약 4시간이 걸리고, 그 시간의 상당 부분이 데이터 분석이 아니라 시스템 간 관계를 다시 맞추는 데 쓰였다고 합니다 ^[1].

Netflix는 이미 MELT(메트릭, 이벤트, 로그, 트레이스)를 수집하고 있지만, 신호가 알림, 인시던트 관리, 배포 도구, 엔지니어 커뮤니케이션 플랫폼에 흩어져 있었습니다 ^[1]. 회귀 원인도 클라이언트 릴리스, 실험, 인프라 부하 차단(load shedding), 여러 단계 아래의 의존 서비스 등 다양해 사람이 증거를 손으로 이어 붙여야 했습니다 ^[1].

해법의 핵심은 다음과 같습니다. - Observability Ontology: 운영 엔티티와 속성, 엔티티 사이의 관계를 정의하는 공통 모델입니다 ^[1]. - Enricher 파이프라인: 운영 시스템의 정보를 받아 주어-술어-목적어 형태의 트리플로 바꿔 그래프에 넣습니다 ^[1]. 일부는 결정적 규칙으로, 일부는 LLM과 확률적 기법으로 비정형 정보를 해석합니다 ^[1]. - 인시던트 논의 보존: 가설, 기각된 설명, 완화 결정까지 그래프에 남겨 사람의 추론이 대화 종료와 함께 사라지지 않게 합니다 ^[1]. - 상관 엔진: 로그 오류, 메트릭 이상, 트레이스, 알림, 배포, 설정 변경, 실험, 코드 변경 등 13가지 신호를 살피고 시간 근접성과 심각도를 근거로 순위가 매겨진 가설을 만듭니다 ^[1].

Netflix는 이 흐름을 Observe, Enrich, Infer, Adapt로 이어지는 '지식 플라이휠'이라고 부릅니다 ^[1].

운영 관점에서 볼 점

• 에이전트 간 인터페이스: 전문 에이전트들이 느슨한 형식의 결과를 주고받는 대신 온톨로지를 공통 언어로 씁니다 ^[1]. 트레이스·로그·배포 분석 에이전트가 서로의 내부 구현을 몰라도 같은 엔티티에 정보를 보탤 수 있다는 점이 설계상 장점으로 소개됩니다 ^[1].
• LLM 출력 통제: 확률적 단계의 결과는 엔티티 타입 일관성, URI 명명 규칙, 소프트웨어 카탈로그 대조 같은 엄격한 검증 규칙으로 제한합니다 ^[1]. 생성형 AI를 관측 파이프라인에 넣을 때 참고할 만한 지점입니다.
• 거버넌스: 순위화된 근거 기반 설명을 만들되 변경과 복구의 승인은 사람이 맡는 구조입니다 ^[1].
• 상용 도구와의 차이: Datadog, Dynatrace, Splunk도 신호 상관 분석과 AI 기반 조사를 늘리고 있지만, Netflix는 신호 뒤의 의미 모델을 지속적으로 저장하고 사람과 기계가 모두 직접 조회할 수 있게 한다는 점을 강조합니다 ^[1].
• 호환성·비용: QuipuDB나 AutoRCA의 외부 공개 여부, 도입 비용, 버전 정보는 자료에서 확인되지 않았습니다. 현재로서는 사내 아키텍처 사례로 보는 것이 맞습니다.

적용해 보려면

자료에 나온 구조를 기준으로 단계를 나누면 다음과 같습니다. 1. 알림, 인시던트, 배포, 실험, 설정 변경 등 신호가 흩어진 시스템을 목록화합니다 ^[1]. 2. 서비스, 배포, 인시던트 같은 엔티티와 그 관계를 온톨로지로 정의합니다. Netflix는 RDF, OWL, SHACL, SPARQL 같은 기존 표준을 택했습니다 ^[1]. 3. 각 시스템의 데이터를 트리플로 바꾸는 enricher를 만들되, 구조화된 데이터는 결정적 변환부터 시작합니다 ^[1]. 4. LLM으로 비정형 정보를 해석하는 단계에는 타입·명명 규칙·카탈로그 대조 같은 검증을 먼저 둡니다 ^[1]. 5. 인시던트 채널의 가설과 기각 사유, 완화 결정을 구조화해 남깁니다 ^[1]. 6. 여러 신호의 시간 근접성과 심각도로 원인 후보를 순위화하고, 실제 조치는 사람이 승인하도록 설계합니다 ^[1].

정리

Netflix 사례의 요점은 신호를 더 모으는 것보다 신호 사이의 관계를 명시적으로 저장하는 데 있습니다 ^[1]. 회사는 이를 자동 근본 원인 분석에서 자동 복구와 자가 치유 인프라로 확장하고, Unified Data Architecture와의 연계도 검토할 계획이라고 밝혔습니다 ^[1]. AI 에이전트를 장애 대응에 들이려는 팀이라면, 에이전트가 공유할 운영 데이터 모델과 LLM 출력 검증 체계를 먼저 갖추는 것이 출발점이 될 수 있습니다.

참고 자료

1. Netflix Turns Operational Data Into a Knowledge Graph for AI-Driven Observability · InfoQ DevOps, 2026-11-13