Bian Que: 온라인 시스템 운영을 위한 Flexible Skill Arrangement 기반 Agentic Framework

TL;DR Highlight

검색/추천/광고 대규모 시스템의 장애 대응을 자동화하는 LLM 에이전트 프레임워크로, alert를 75% 줄이고 장애 해결 시간을 50% 단축했다.

Who Should Read

대규모 온라인 서비스의 SRE(사이트 신뢰성 엔지니어)나 DevOps 엔지니어. 특히 수십 개의 서비스 모듈에서 매일 수십 건의 배포가 일어나는 환경에서 운영 자동화를 고민하는 팀.

Core Mechanics

O&M(운영 및 유지보수) 작업을 3가지 패턴으로 추상화: 릴리즈 차단(Release Interception), 선제적 점검(Proactive Inspection), 장애 근본 원인 분석(Alert RCA). 기존 도구들이 마지막 단계(장애 대응)에만 집중한 것과 달리 장애 발생 전 단계부터 커버.
Flexible Skill Arrangement가 핵심: 각 Skill은 특정 비즈니스-모듈 조합에서 어떤 데이터(메트릭, 로그, 변경 이벤트)와 지식을 가져올지 명세하는 구조체. LLM이 자동으로 생성하고 업데이트하며, 엔지니어가 자연어로 수정도 가능.
Skill 구조는 3개 필드로 구성: LoadDataSchema(뭘 가져올지 JSON 명세), Prompt(어떻게 추론할지 템플릿), Meta(이름/버전/태그). 코드 변경 없이 자연어 피드백만으로 업데이트 가능.
피드백 신호 하나로 두 가지를 동시에 학습: Knowledge Pathway(실패 패턴을 장기 지식으로 증류)와 Skill Pathway(데이터 라우팅 로직 개선). 기존 RAG가 정적 지식베이스를 쓰는 것과 달리 지속적으로 공진화.
LLM 백본은 모델 교체 가능한 플러그인 방식. 실험 결과 약 35B 파라미터 이상이면 DeepSeek-V3.2, GLM5, Qwen3.5-35B-FP8 모두 pass@1 72~78%로 비슷한 성능. 9B 이하는 급격히 성능 저하.
피드백 없이 13일 운영하면 정확도가 75%→32%로 폭락. 피드백 루프를 켜면 80% 이상 유지. 새로운 장애 유형에도 자가 수정으로 장기 안정성 확보.

Evidence

6개월 프로덕션 배포 결과: 발생 alert 75% 감소, 비실행 alert(non-actionable) 절대 수치 약 95% 감소 (0.25 × 0.15/0.80 ≈ 4.7%).
RCA(근본 원인 분석) 정확도 80%, 발생 alert의 95%가 5분 내 구조화된 진단 반환, MTTR(평균 해결 시간) 50% 이상 단축.
104개 실제 운영 이벤트 오프라인 평가: Skill 자동 생성 pass@1 78.8%, pass@5 94.2%. 엔지니어 자연어 수정 1라운드 추가 시 pass@1 97.1%, 3라운드 후 99.0% 달성.
Flexible Skill을 정적 수동 작성(STATIC)으로 교체하면 pass@5가 94.2%→83.7%(-10.5pp), 지식 검색 비활성화(NOKNOW)는 94.2%→86.5%(-7.7pp) 하락.

How to Apply

여러 비즈니스 모듈/팀이 있는 대형 서비스라면, 각 모듈마다 Skill YAML을 만들어 '어떤 메트릭/로그를 봐야 하는지'와 '어떻게 판단하는지'를 분리 관리하면 된다. 처음엔 LLM에게 기존 데이터 소스 목록과 시나리오 설명을 주고 자동 생성시키고, 온콜 엔지니어가 자연어로 수정하는 방식으로 운영.
장애 대응 파이프라인을 구축할 때, alert 발생 후 대응하는 RCA 에이전트만 만들지 말고 릴리즈 배포 시점에 자동 점검하는 에이전트를 앞단에 붙이면 alert 자체를 줄일 수 있다. 배포 이벤트 → Skill 기반 데이터 수집 → LLM 판단 → 문제 있으면 자동 차단 흐름으로 구성.
LLM 백본 선택 시 35B 파라미터 이상을 써야 한다. 비용 절감을 위해 9B 이하 모델 사용을 고려한다면 pass@1이 47% 수준으로 떨어져 실 운영에 부적합. DeepSeek-V3.2나 Qwen3.5-35B-FP8 수준이 현실적인 최소 기준.

Code Example

snippet

# Skill YAML 구조 예시 (논문의 Skill = <LoadDataSchema, Prompt, Meta> 구조)

name: recommendation-recall-availability
version: 1.2
description: 추천 recall 모듈 가용성 점검 Skill
tags: [recommendation, recall, availability]

LoadDataSchema:
  data_sources:
    - type: time_series_metric
      name: recall_module_qps
      mandatory: true
      params:
        module: recommendation_recall
        metrics: [qps, latency_p99, error_rate]
        window: 30m
    - type: structured_log
      name: recall_error_log
      mandatory: false
      params:
        service: recall-service
        level: ERROR
        limit: 100
    - type: change_event
      name: recent_releases
      mandatory: true
      params:
        module: recommendation_recall
        lookback: 2h
  knowledge_queries:
    - index: KV
      key: recommendation.recall.behavioral_norms
    - index: KKV
      key1: recommendation_recall
      key2: gmv_impact
    - index: vector
      query: "recall module availability degradation patterns"
      top_k: 3

Prompt: |
  당신은 추천 시스템 recall 모듈 전문가입니다.
  
  ## 분석 절차
  1. 최근 30분 QPS/레이턴시/에러율 추이 확인
  2. 최근 2시간 내 배포 변경사항과 지표 변화 시점 교차 검증
  3. 지식베이스의 알려진 장애 패턴과 비교
  4. 판정: [정상 / 경고 / 장애] 중 하나와 근거 제시
  5. 권장 조치 (롤백 / 모니터링 강화 / 추가 조사 필요) 명시
  
  ## 출력 형식
  {
    "verdict": "정상|경고|장애",
    "confidence": 0.0~1.0,
    "root_cause": "원인 설명",
    "evidence": ["근거1", "근거2"],
    "recommended_action": "권장 조치"
  }

Terminology

O&MOperations & Maintenance의 약자. 서비스를 배포하고, 모니터링하고, 장애를 대응하는 운영 유지보수 업무 전반을 말함.

RCARoot Cause Analysis. 장애가 왜 발생했는지 근본 원인을 찾는 과정. 단순히 증상(서버 다운)이 아니라 원인(특정 배포로 인한 메모리 누수)을 찾는 것.

MTTRMean Time To Resolution. alert 발생부터 문제 해결까지 평균 걸리는 시간. 이 숫자가 낮을수록 장애 대응이 빠른 것.

AIOpsAI for IT Operations. AI를 활용해 IT 인프라 운영(장애 감지, 로그 분석, 이상 탐지 등)을 자동화하는 분야.

pass@kk번 시도했을 때 최소 1번이라도 정답을 맞출 확률. LLM은 같은 질문도 여러 번 돌리면 다른 답을 내므로, 반복 시도 시 성공률을 측정하는 지표.

Knowledge Distillation여기서는 모델 압축 기법이 아니라, 실제 장애 사례(case memory)에서 재사용 가능한 패턴과 인사이트를 뽑아내 지식베이스에 저장하는 과정을 의미함.

SRESite Reliability Engineer. 서비스의 안정성과 가용성을 책임지는 엔지니어. 개발과 운영의 경계에서 인프라와 장애 대응을 담당.

ANNApproximate Nearest Neighbor. 벡터 검색에서 완전히 정확한 가장 가까운 이웃을 찾는 대신 근사치를 빠르게 찾는 알고리즘. 대규모 벡터 DB에서 속도를 위해 사용.

Related Resources

https://github.com/benchen4395/BianQue_Assistant

Original Abstract (Expand)

Operating and maintaining (O&M) large-scale online engine systems (search, recommendation, advertising) demands substantial human effort for release monitoring, alert response, and root cause analysis. While LLM-based agents are a natural fit for these tasks, the deployment bottleneck is not reasoning capability but orchestration: selecting, for each operational event, the relevant data (metrics, logs, change events) and the applicable operational knowledge (handbook rules and practitioner experience). Feeding all signals indiscriminately causes dilution and hallucination, while manually curating the event-to-(data, knowledge) mapping is intractable under dozens of daily releases. We present Bian Que, an agentic framework with three contributions: (i) a \emph{unified operational paradigm} abstracting day-to-day O&M into three canonical patterns: release interception, proactive inspection, and alert root cause analysis; (ii) \emph{Flexible Skill Arrangement}, where each Skill specifies which data and knowledge to retrieve for a given business-module context and can be automatically generated and updated by LLMs or iteratively refined through natural-language instructions from on-call engineers; (iii) a \emph{unified self-evolving mechanism} in which one correction signal drives two parallel pathways, case-memory-to-knowledge distillation and targeted Skill refinement. Deployed on the e-commerce search engine of KuaiShou, the major short-video platform in China, Bian Que reduces alert volume by 75%, achieves 80% root-cause analysis accuracy, and cuts mean time to resolution by over 50%. Our framework achieves 99.0% pass rate on offline evaluations. Our code is available at https://github.com/benchen4395/BianQue_Assistant.