기술 요약: 에이전트형 NetOps 및 AIOps 를 위한 대규모 언어 모델

1. 문제 제기

현대 네트워크 운영 (NetOps) 과 IT 운영을 위한 AI(AIOps) 는 시스템 변경 속도 (배포, 정책 편집, 토폴로지 변화) 와 이를 관리할 인간 팀의 역량 사이에 커다란 괴리가 존재한다는 도전에 직면해 있습니다. 운영자들은 구성과 도달 가능성에 대한 추론을 위한 강력한 도구를 보유하고 있지만, 파편화된 증거, 고속의 변경 사항, 복잡한 사고 이전 (handover) 으로 인해 운영 부담은 더욱 가중되고 있습니다.

대규모 언어 모델 (LLM) 의 등장은 읽기, 추론, 실행의 단일 루프로 파편화된 운영 작업을 통합함으로써 잠재적인 해결책을 제시합니다. 그러나 LLM 을 자율 에이전트로 취급하는 것은 상당한 위험을 수반합니다. 일반적인 대화형 에이전트와 달리, 운영 에이전트는 중요한 제어 인터페이스와 상호작용합니다. 여기서의 실패는 단순히 '잘못된 답변'이 아니라, 안전하지 않은 구성 변경, 서비스 중단, 보안 침해로 이어질 수 있습니다. 핵심 문제는 현재 에이전트 설계가 고위험 운영 환경에 필요한 엄격한 제약 조건, 검증 메커니즘, 안전 계약 (safety contracts) 을 종종 결여하고 있다는 점입니다. 자율성, 안정적인 평가 작업, 실제 운영 도구 인터페이스에 부합하는 위협 모델에 대한 공유된 용어가 부족합니다.

2. 방법론 및 프레임워크

본 논문은 모델 중심의 능력에서 시스템 중심의 안전성과 신뢰성으로 초점을 이동시키는 에이전트 운영을 위한 계약 기반 프레임워크를 제안합니다. 방법론은 네 가지 핵심 기둥을 중심으로 구조화되어 있습니다:

A. 자율성 사다리

저자들은 자율성을 이진 상태가 아닌 '계단식 단계 (ladder of rungs)'로 모델링하며, 각 단계는 특정 능력 계약 ($A_k$) 으로 정의됩니다:
$$A_k = (T^{read}_k, T^{write}_k, G_k)$$

• $T^{read}_k$: 읽기 전용 도구 (쿼리, 검색).
• $T^{write}_k$: 쓰기 가능 도구이며, 제안 (diff 작성) 과 실행 (변경 사항 적용) 으로 세분화됩니다.
• $G_k$: 우회 불가능한 게이트 (정책 확인, 불변성, 승인, 캐나리/롤백 규칙).

이 프레임워크는 네 가지 명확한 자율성 수준을 정의합니다:

1. 코파일럿 (읽기 전용): 증거를 집계하고 검색합니다.
2. 분석가 (대부분 읽기): 진단을 수행하고 가설을 유지하며 RCA(근본 원인 분석) 보고서를 생성합니다.
3. 계획자 - 실행자 (제한된 쓰기): 실행 전에 검증 장벽을 통과해야 하는 변경 사항 (diff) 을 제안합니다.
4. 폐쇄 루프 (자가 치유): 자동 롤백과 지속적인 모니터링을 통해 제한된 작업을 실행합니다.

B. 워크플로우 계약

'안전한 자율성'을 보장하기 위해, 본 논문은 에이전트 행위를 규율하는 명시적인 워크플로우 계약 ($C$) 을 정의합니다:
$$C = (A_k, \Pi, I, R, B, S)$$

• $\Pi$: 조직 정책 (코드로서의 정책).
• $I$: 운영 불변성 (도달 가능성, 격리, SLO 가드).
• $R$: 필수 증거 의무 (행동 전 관찰해야 할 사항).
• $B$: 예산 벡터 (도구 호출, 토큰, 시간, 위험).
• $S$: 중지 규칙 (승급, 롤백 또는 중단 조건).

C. 검증 장벽

핵심 아키텍처 패턴은 제안과 커밋 사이의 우회 불가능한 게이트인 **검증 장벽 (Verification Wall)**입니다. 에이전트는 자유롭게 추론할 수 있지만, 모든 쓰기 작업 ($a$) 은 정책 준수와 불변성 충족을 검증하는 게이트 함수 $g(a, E, \Pi, I)$를 통과할 때만 실행됩니다. 이는 제안이 실행된 작업으로 전환되는 지점이 '신뢰 경계'임을 보장합니다.

D. 평가 및 벤치마킹

본 논문은 평가가 정적 질문 응답을 넘어 워크플로우 중심 평가로 이동해야 한다고 주장합니다. 주요 지표는 다음과 같습니다:

• 추적 품질: 도구 호출의 차별적 가치, 증거의 완전성, 그리고 출처.
• 안전 제약 조건: 정책 위반률, 불필요한 작업, 그리고 롤백 빈도.
• 운영 결과: 완화 시간 (MTTR), 신호 시간 (MTTD), 그리고 드리프트 강건성.
• 비용 및 지연: 도구 호출 횟수, 토큰 사용량, 그리고 종단 간 지연 시간.

3. 주요 기여

본 조사는 해당 분야에 네 가지 주요 기여를 합니다:

1. 워크플로우 기반 분류 체계: 내부 모델 아키텍처가 아닌 운영 단계 (관찰, 진단, 결정, 행동) 와 자율성 수준에 기반한 에이전트 기반 NetOps 및 AIOps 를 위한 분류 체계입니다. 이는 특정 역할을 도구 인터페이스 및 실패 모드와 연관시킵니다.
2. 아키텍처 패턴 및 가드레일: 신선도/출처 인식형 검색 증강 생성 (RAG), 도구 사용 루프, 그리고 '검증 장벽'을 포함한 반복적인 설계 패턴의 추출입니다. 이를 최소 권한 액세스, 단계적 롤아웃, 인간 승인 등의 가드레일에 매핑합니다.
3. 평가 관행 및 벤치마크 지침: 실제 운영 작업을 반영하는 평가 방법론의 종합입니다. 부분 관측 하의 진단 정확도 등의 작업 정의를 제안하며, 언어 유창성뿐만 아니라 종단 간 유틸리티와 안전성을 측정하는 벤치마크를 주장합니다.
4. 보안, 거버넌스, 규정 준수 분석: 티켓이나 실행 매뉴얼을 통한 프롬프트 주입, 검색 중독, 원격 측정 무결성 공격, 그리고 '과도한 에이전시'를 포함한 에이전트 운영에 특화된 위험 분석입니다. 기존 네트워크 검증 추상화를 강제 가능한 안전 제약 조건으로 재사용하는 것을 강조합니다.

4. 결과 및 발견

본 논문은 기존 문헌을 종합하여 몇 가지 중요한 결론을 도출합니다:

• 신뢰성은 시스템적이며 모델 중심이 아님: 운영 신뢰성은 주로 LLM 자체에서 비롯되는 것이 아니라, '모델 주변의 기계'에서 비롯됩니다. 이는 타입화된 도구 인터페이스, 출처 인식형 검색, 명시적 예산, 그리고 검증 게이트를 포함합니다.
• 자율성은 제약을 필요로 함: 자율성이 증가함에 따라 (사다리를 올라감에 따라) 엔지니어링 부담은 답변 품질에서 안전한 행동으로 이동합니다. 고자율 시스템은 엄격한 행동 범위, 자동 롤백, 그리고 지속적인 모니터링을 요구합니다.
• 인과 추론은 보완적입니다: 순수 LLM 기반 진단은 종종 취약합니다. LLM 이 의도 번역과 증거 수집을 처리하는 동안, 인과 추론이나 의존성 그래프를 사용하여 가설 공간을 좁히는 하이브리드 접근 방식이 더 견고한 길을 제공합니다.
• 평가 격차: 현재 벤치마크는 종종 도구 인터페이스, 중간 가설, 그리고 안전 제약 조건을 고려하지 못합니다. 많은 시스템이 데모에서는 견고해 보이지만, 롤백 인식 점수화 및 드리프트 테스트의 부재로 인해 실제 인프라 변경에는 너무 취약합니다.
• 보안 위험은 급박함: 에이전트가 운영 제어 인터페이스에 근접할 때, 티켓을 통한 프롬프트 주입이나 원격 측정 조작과 같은 위험이 중요해집니다. '혼란된 부하 (confused deputy)' 문제 (에이전트가 사기당해 자신의 권한을 남용하도록 유도됨) 는 주요 위협입니다.

5. 중요성 및 주장

본 논문은 지능형 NetOps 및 AIOps 의 진전은 자율성을 제약된 운영 제어 문제로 취급하는 것에 달려 있다고 주장합니다.

• 자율성에 대한 겸손한 주장: 저자들은 폐쇄 루프 자가 치유의 현재 상태에 대해 겸손합니다. 읽기 전용 지원과 강력한 검증을 통한 제한된 자가 치유는 실용적이지만, 크고 예측 불가능한 시스템에서의 광범위한 자가 치유는 여전히 중요한 과제라고 주장합니다.
• 패러다임의 전환: 중요성은 'LLM 을 어떻게 더 똑똑하게 만들 것인가'에서 '강제 가능한 안전 계약 내에서 LLM 을 어떻게 제약할 것인가'로 연구 초점을 이동하는 데 있습니다.
• 운영 현실: 본 논문은 운영 성공이 올바른 답변을 생성하는 것뿐만 아니라 과정에 달려 있음을 강조합니다. 즉, 어떤 증거가 수집되었는지, 어떤 도구가 사용되었는지, 증거가 불충분했을 때 시스템이 멈췄는지, 그리고 제안된 변경 사항이 정책과 롤백 트리거를 존중했는지입니다.
• 거버넌스를 아티팩트로: 거버넌스는 정책 텍스트가 아니라 검토 가능하고 감사 가능한 결정을 만드는 강제 가능한 아티팩트 (diff, 승인 번들, 감사 추적) 로 프레임됩니다.

결론적으로, 본 조사는 에이전트 시스템이 프로덕션 환경에 배포 가능하려면 '안전한 자율성'을 1 순위 요구 사항으로 설계해야 하며, 이를 보장 계약, 감사 가능한 아티팩트, 그리고 추론과 실행 간의 명확한 분리에서 지원받아야 한다고 주장합니다. 이러한 조치가 없다면 시스템은 데모에서는 견고해 보일 수 있지만, 실제 세계 인프라 관리에는 너무 취약한 상태에 머무르게 됩니다.