첫날 점심 직전, 4층 414+415호에서 들은 세션입니다. 발상이 단순해서 오히려 설득력이 있었습니다.
AIOps: (near) Zero-Touch Production Rollout Fixes
Kevin Dubois (IBM, CNCF Developer Experience TAG 테크 리드), Carlos Sanchez (Adobe)
🚨 왜 프로그레시브 딜리버리인가
발표는 CrowdStrike 장애 이야기로 시작했습니다. 사후 분석에서 나온 개선점 중 하나가 전 세계 동시 배포 대신 단계적 롤아웃이었다는 점을 짚었습니다.
GitOps는 Git이 단일 진실 공급원이라는 장점이 있지만 기본은 all-or-nothing 릴리스입니다. 여기에 Argo Rollouts나 Flagger를 얹으면 단계를 정의할 수 있습니다. 일정 비율 배포 → 대기 → 메트릭 수집 → 다음 비율로 확대. 문제가 있으면 자동 롤백.
📉 기존 방식의 한계
기존에는 AnalysisTemplate에 성공 기준과 PromQL을 작성합니다. 500 에러 비율이 5%를 넘으면 롤백하는 식이죠.
문제는 명확합니다. 그 쿼리로 잡히지 않는 종류의 오류는 놓칩니다. 모든 실패 시나리오를 미리 쿼리로 쓰는 건 사실상 불가능하고, 두 발표자가 수년간 반복해서 부딪힌 지점이 이거였다고 합니다.
그래서 나온 발상이 이겁니다. 로그와 메트릭을 그냥 LLM에 던져서 판단시키면 어떨까. stable과 canary의 로그를 함께 보내 비교시킬 수도 있고요.
🔧 구현 구조
- Argo Rollouts용 커스텀 플러그인(Go)이 A2A 프로토콜로 에이전트 플릿을 호출
- 에이전트가 클러스터의 파드·로그·메트릭을 수집
- LLM이 분석하고 결과를 Argo Rollouts에 반환
Rollout 템플릿에 넣는 건 플러그인 이름과 파라미터뿐입니다. 에이전트 위치, stable/canary 파드 라벨, 그리고 애플리케이션별 추가 프롬프트.
마지막 항목이 실용적이었습니다. 에이전트에도 시스템 프롬프트가 있지만 애플리케이션마다 봐야 할 지점이 다르니, 여기서 코드 수정 없이 조정할 수 있게 한 겁니다.
🔁 한 걸음 더 : 자동 교정
AI가 문제를 찾았으면 그걸로 뭔가를 해보자는 단계입니다.
- 분석 결과에 품질 스코어링 루프를 돌려 신뢰할 만한지 판단한 뒤 Argo Rollouts에 신호 전달
- 그와 별개로 비동기 에이전트가 원인을 계속 파악
- 단순한 수정이면 PR 자동 생성, 복잡하면 이슈 생성
외부 코딩 어시스턴트 없이 클러스터 안에서 돌아가는 구조라, 원하면 Gemma 같은 인클러스터 LLM으로 완전 폐쇄망 운영도 가능하다고 했습니다.
🖥️ 라이브 데모
케이스 1 — NullPointerException
버그를 심은 이미지를 배포합니다. 10% 카나리로 나가고 10초 대기 후 분석이 시작되는데, 에이전트가 데이터를 긁어모으더니 "canary에 심각한 문제, 롤백"이라는 판정을 내립니다. 롤백과 동시에 "remediation triggered"가 뜨고, 잠시 후 GitHub에 수정 PR이 올라와 있었습니다.
케이스 2 — 메모리 누수
"심각한 성능 저하와 메모리 압박, 롤백 권고" 판정. 이번엔 PR 대신 이슈를 생성했습니다. 대시보드에서 성공률 그래프가 잠깐 꺾였다가 복구되는 게 눈에 보였는데, 실제로 10% 사용자가 잠깐 영향을 받았다가 stable로 되돌아간 구간이었습니다. 스택은 Gemini LLM에 Google Kubernetes Engine 조합이었습니다.
📝 발표자들이 정리한 교훈
이 파트가 가장 실무적이었습니다.
- 성능이 관건이다. 분석에 몇 분씩 걸리면 MTTR 개선 효과가 없습니다. 초기 Python 구현이 느려서 Quarkus + LangChain4j(Java) 로 재작성했다고 합니다
- 모델은 용도별로 나눠 쓴다. 분석은 3B 파라미터급 소형 모델로 충분했지만, 교정은 코드를 읽어야 해서 훨씬 강한 모델이 필요했습니다
- 컨텍스트 엔지니어링에 며칠이 걸렸다. 문제를 놓치지 않으면서 오탐도 내지 않는 게 어렵습니다
- 리스크는 낮다. 최악의 경우가 "멀쩡한 릴리스를 롤백"이라 시도 비용이 작습니다
- 절대 임계값이 아니라 상대 비교로 판단해야 한다. 기존 애플리케이션은 이미 에러가 있습니다. 1%가 나온다고 롤백하면 안 되고, 그 1%가 2~3%로 악화될 때 롤백해야 합니다
마지막 항목은 AI를 붙이지 않더라도 프로그레시브 딜리버리 설계 원칙으로 그대로 유효합니다.
부수적으로 agent-sandbox 언급도 있었습니다. 로그를 분석하는 에이전트는 사용자 입력에서 온 로그를 읽게 되는데 프롬프트 인젝션 위험이 있으니, 신뢰할 수 없는 입력을 다루는 에이전트는 샌드박스에서 격리 실행하라는 것이었습니다.
🛫 마치며
"AI로 롤백을 판단한다"는 문장만 보면 과해 보이는데, 실제 구조를 보면 기존 AnalysisTemplate의 판정 로직 자리에 플러그인 하나를 끼우는 것이라 생각보다 침습적이지 않았습니다.
Q&A에서 "PR 리뷰까지 자동화하면 진짜 셀프 힐링 루프가 되는 것 아니냐"는 질문이 나왔는데, 발표자도 그 방향을 준비 중이라고 답했습니다.
플러그인은 Argo Project Labs에 공개돼 있고 데모 앱과 에이전트, 배포 매니페스트까지 함께 있으니 관심 있으신 분은 직접 돌려보셔도 좋겠습니다.
다음 글에서는 연구실 인프라 마이그레이션의 실패담을 솔직하게 공유한 GIST 팀 세션을 다룹니다.