AI 기반 어시스턴트가 7일 동안 제 온콜(on-call) 업무를 수행했습니다. 이 과정에서 11개의 알람을 처리하며 평균 문제 해결 시간을 45분에서 20분으로 단축했습니다. 이번 실험이 중요한 이유는, 적절한 규모의 언어 모델이 엄격한 인간의 감독 하에 장애 대응 시간을 30분가량 줄일 수 있음을 보여주었기 때문입니다.

AI를 온콜에 투입한 이유

클라우드 팀은 교대 근무 시간의 대부분을 로그를 뒤지고, 최근 배포를 확인하며, 스케일링 요청이 안전한지 검토하는 데 보냅니다. 이러한 "지루한" 작업들은 반복적이고 데이터 집약적이며, 인간의 피로도가 높습니다. 최근 대규모 언어 모델(LLM)의 발전은 이러한 패턴 매칭 작업을 자동화할 수 있을 것이라 약속했지만, 대부분의 공개 데모는 샌드박스 환경에서 실행됩니다. 저는 이 기대가 실제 유료 고객에게 서비스를 제공하는 프로덕션급 클러스터에서도 유효한지 확인하고 싶었습니다.

테스트 설정

  • 액세스 권한 – 에이전트는 모든 메트릭, 로그, 배포 정의를 읽을 수 있었습니다. 쓰기 권한은 포드(pod) 재시작, 레플리카(replica) 수 증가, 배포 스케일링과 같은 좁은 화이트리스트로 제한되었습니다. 그 외의 모든 작업은 저의 명시적인 승인이 필요했습니다.
  • 역할 – 모델을 첫 온콜 근무를 시작한 주니어 엔지니어로 취급했습니다. 모델은 알람을 수신하고, 분석을 수행한 뒤, 장애 채널에 권장 사항을 게시했습니다.
  • 안전장치 – 모든 쓰기 작업은 수동 "예/아니오" 프롬프트를 통해 제어되었습니다. 또한 비용을 예측 가능하게 유지하기 위해 모델의 토큰 사용량을 제한했습니다.

AI가 빛을 발한 순간

에이전트의 속도가 가장 눈에 띄는 이점이었습니다. 알람이 발생하자마자 관련 로그를 가져오고, 최근 메트릭을 도식화하며, 마지막 3개의 배포 내역을 나열했습니다. 제가 노트북을 열었을 때, 초기 탐색 작업은 이미 완료된 상태였습니다. 11개의 알람 중:

  • 8개는 일상적인 문제(메모리 급증, 컨테이너 재시작, 단순 설정 오류)였습니다. AI는 매번 근본 원인을 정확히 식별했습니다.
  • 마이크로서비스의 점진적인 메모리 증가를 감지하여 문제가 새벽 2시의 장애로 번지기 전에 팀이 조기에 개입할 수 있도록 했습니다.
  • 일주일 동안의 전체 토큰 소비량은 약 $30로, 제한을 두었을 때 일반적인 온콜 예산 범위 내에 있었습니다.

이러한 결과는 평균 복구 시간(MTTR)을 45분에서 20분으로 측정 가능한 수준으로 단축하여, 엔지니어가 더 영향력 있는 업무에 집중할 수 있게 해주었습니다.

실수가 있었던 부분

자신감이 곧 정확성을 의미하지는 않습니다. AI는 11개의 알람 중 3개에서 자신 있게 틀린 답을 내놓았습니다:

  1. 데이터베이스 연결 실패의 원인을 최근 코드 배포 탓으로 돌렸으나, 이는 잘못된 설명이었습니다.
  2. 생소한 네트워킹 이상 현상에 직면했을 때, 근본적인 문제를 해결하지 못하는 일반적인 해결책만 제시했습니다.
  3. 부하 관련 알람이 발생했을 때, 서비스 레플리카를 3개에서 30개로 늘릴 것을 제안했습니다. 문제는 부하가 아니라 잘못된 설정이었습니다.

쓰기 작업에 대해 수동 승인을 요구하는 가드레일 덕분에 모델의 실수가 피해로 이어지기 전에 발견될 수 있었습니다. 그럼에도 불구하고, 이 사례는 모델이 특히 새로운 문제에 대해 그럴듯해 보이지만 부정확한 권장 사항을 생성할 수 있다는 핵심적인 위험을 보여주었습니다.

비용 및 리스크 관리

$30의 토큰 비용은 사용량을 모니터링한다면 프로덕션 루프에서 LLM을 실행하는 것이 저렴할 수 있음을 보여줍니다. 하지만 진짜 비용은 운영 리스크입니다. 배포를 잘못 스케일링하면 클라우드 비용이 걷잡을 수 없이 늘어날 수 있고, 정상적인 릴리스를 롤백하면 고객의 신뢰를 떨어뜨릴 수 있습니다. 이번 실험을 통해 두 가지 안전장치의 중요성을 확인했습니다:

  • 작업 게이팅(Action gating) – 모델이 고영향 변경 사항을 제안만 하도록 하고, 인간의 클릭 없이는 절대 실행하지 못하게 합니다.
  • 예산 제한 – 토큰 소비량에 엄격한 한도를 설정하고, 모델이 한도에 도달하면 팀에 알림을 보냅니다.

향후 주시해야 할 사항

앞으로 팀은 다음 사항을 수행해야 합니다:

  • 수동 재지정(override)이 필요한 AI 생성 제안의 비율을 추적합니다.
  • 다양한 장애 카테고리(일상적 vs. 새로운 문제)에 따른 MTTR의 영향을 측정합니다.
  • 프로덕션 쓰기 권한을 부여하기 전에 스테이징 환경에서 합성 알람(synthetic alerts)을 사용하여 모델을 테스트합니다.

운영 팀을 위한 시사점

  • 지루한 80%를 자동화하십시오 – 로그 집계, 메트릭 상관관계 분석, 초기 가설 생성에 AI를 활용하십시오.
  • 위험한 20%는 인간을 위해 남겨두십시오 – 일정 임계값을 넘어서는 스케일링, 롤백, 삭제 작업은 수동 승인 단계를 거쳐야 합니다.
  • 모델을 대체재가 아닌 파트너로 대하십시오 – 시스템을 잘 아는 엔지니어는 신입보다 AI의 결과물을 더 빠르게 검증할 수 있으며, 이를 통해 어시스턴트를 역량 증폭기(force multiplier)로 만들 수 있습니다.

AI 에이전트가 아직 클라우드 운영을 단독으로 수행할 수는 없지만, 트리아지(triage) 파트너로서 이미 가시적인 속도 향상을 제공하고 있습니다. 핵심은 신뢰도를 적절히 관리하고 엄격한 가드레일을 적용하며, 모델이 반복적인 단순 업무를 처리하는 동안 인간의 전문성이 중요한 의사결정을 주도하도록 하는 것입니다.