모두가 이제 AI 에이전트가 운영(operations)을 수행할 수 있다고 말합니다. 그래서 저는 데모가 아닌 실제 환경에서 AI 에이전트에게 7일간의 시간을 주었습니다. 거의 잘못될 뻔했던 상황을 포함하여 실제로 어떤 일이 일어났는지 소개합니다.

설정 (The setup)

먼저 AI 에이전트를 모니터링 스택(monitoring stack) 및 클러스터(cluster)에 읽기 권한(read access)으로 연결한 다음, 멈춘 포드(pod)를 재시작하거나 배포(deployment)를 스케일링(scaling)하는 것과 같은 몇 가지 안전한 작업에 대해서만 제한적인 쓰기 권한(write access)을 부여했습니다. 에이전트는 로그(logs), 메트릭(metrics), 최근 배포(deploys)를 볼 수 있었고, 사전 승인된 소수의 작업을 제안하거나 수행할 수 있었습니다. 그보다 큰 작업은 모두 저의 승인이 필요했습니다.

제가 스스로 세운 규칙은 다음과 같습니다: 첫 온콜(on-call) 근무를 시작한 신입 주니어 엔지니어처럼 대하는 것입니다. 유용하고 빠르지만, 아직 열쇠를 완전히 맡길 수는 없는 상태 말이죠.

잘된 점 (What went well)

분류(triage) 속도가 정말 놀라웠습니다. 알람(alert)이 발생했을 때, 제가 노트북을 열기도 전에 에이전트는 이미 관련 로그, 급증(spike) 전후의 메트릭, 그리고 마지막 배포 내역을 모두 가져온 상태였습니다. 평소라면 그런 컨텍스트(context)를 수집하는 것이 가장 느린 작업이었을 것입니다. 에이전트는 그저 저에게 전달해 주었을 뿐입니다.

7일 동안 살펴볼 가치가 있는 11개의 알람이 있었습니다. 크래시 루프(crash loop)에 빠진 포드나 과열된 노드(node)와 같은 일상적인 문제들에 대해, 에이전트는 11번 중 약 8번 정도 원인을 정확히 식별했습니다. 지루한 탐정 작업이 이미 완료되었기 때문에, 해당 사고들에 대한 저의 대략적인 평균 복구 시간(mean time to resolution)은 약 45분에서 20분에 가깝게 단축되었습니다.

또한 제가 놓쳤을 수도 있는 부분도 잡아냈습니다. 아직 알람이 울리지 않은 서비스의 느린 메모리 상승(memory climb)을 발견한 것입니다. 에이전트는 해당 추세(trend)를 표시하고, 새벽 2시에 호출(page)이 발생하기 전에 재시작을 제안했습니다. 이 한 번의 방어만으로도 이번 일주일은 가치가 있었다고 느껴졌습니다.

고장 난 점 (What broke)

이제 솔직한 이야기를 해보겠습니다. 홍보성 게시물들은 이 부분을 생략하니까요.

에이전트는 11번 중 3번이나 자신 있게 틀렸습니다. 한 번은 실제로는 다운스트림 데이터베이스(downstream database) 문제였던 이슈를 배포(deploy) 때문이라고 비난했습니다. 그 설명은 깔끔하고 전문적이었지만, 완전히 틀렸습니다. 만약 제가 확인하지 않았다면, 멀쩡한 릴리스(release)를 롤백(rollback)했을 것이고 장애는 여전히 지속되었을 것입니다.

또한 에이전트는 이전에 본 적 없는 상황에 대해서도 어려움을 겪었습니다. 알려진 패턴에 대해서는 훌륭했습니다. 하지만 우리 설정에 대한 암묵적 지식(tribal knowledge)이 필요한 기이한 네트워킹 문제에 대해서는 갈팡질팡하며 일반적인 해결책만을 계속 제안했습니다. 에이전트는 자신이 무엇을 모르는지조차 몰랐는데, 이는 운영(ops)에서 결코 원치 않는 특성입니다.

아찔했던 순간 (The near-miss)

가장 기억에 남는 부분은 이 대목입니다. 한 장애 상황에서 에이전트는 "부하를 처리하기 위해" 배포(deployment)의 복제본(replica) 수를 3개에서 30개로 확장(scaling)할 것을 제안했습니다. 문제는 부하가 아니라 잘못된 설정(config)이었습니다. 만약 이 작업이 자동으로 실행되었다면, 고장 난 서비스를 10배로 증폭시키고 비용(bill)만 폭등시켰을 것이며, 정작 아무것도 해결하지 못했을 것입니다.

이 작업이 실행되지 않은 이유는 제가 그런 종류의 작업을 수동 승인(manual approval) 단계 뒤에 두었기 때문입니다. 하지만 이는 명확한 교훈을 주었습니다. 에이전트의 자신감(confidence)과 정확성(correctness)은 별개의 문제이며, 그 사이의 간극이 바로 당신이 피해를 입는 지점이라는 사실입니다. 가드레일(guardrail)이 제 역할을 다한 것입니다.

비용 (What it cost)

올해 AI 지출이 면밀히 검토되고 있는 만큼 언급할 가치가 있습니다. 일주일 동안의 토큰(token) 사용량은 대략 30달러였습니다. 절약된 시간에 비하면 적은 금액이지만, 에이전트가 제한 없이 큰 환경에서 마음껏 돌아다닌다면 이 비용이 빠르게 치솟을 것이라고 쉽게 상상할 수 있습니다. 여기서는 예산 상한선(budget caps) 설정이 선택이 아닌 필수입니다.

실제로 배운 점 (What I actually learned)

세 가지입니다.

첫째, 가치는 지루한 80%에 있습니다. 컨텍스트 수집(context gathering), 상관관계 분석(correlation), 1차 분류(first-pass triage)와 같은 작업들이 에이전트가 진정으로 시간을 아껴주는 부분입니다. 에이전트가 그 일을 하게 두십시오.

둘째, 위험한 20%는 사람 뒤에 두십시오. 프로덕션 상태를 변경하는 모든 것, 즉 스케일링(scaling), 롤백(rollback), 삭제(delete) 등은 설정을 깊이 신뢰할 수 있을 때까지 승인이 필요해야 합니다. 저의 아찔했던 순간도 이 규칙이 없었다면 실제 장애(incident)로 이어졌을 것입니다.

셋째, 에이전트가 시스템에 대한 지식을 대체할 수는 없습니다. 에이전트는 이를 검증(sanity-check)할 수 있는 엔지니어에게는 역량을 증폭시키는 도구(force multiplier)였습니다. 하지만 검증할 수 없는 사람에게는 자신 있게 실수를 저지르는 매우 빠른 방법이 되었을 것입니다.

계속 사용할 것인가 (Would I keep it

네, 하지만 정확히 제가 운영했던 방식 그대로라면요. 읽기 권한(Read access)은 넓게 개방하되, 쓰기 권한(Write access)은 좁고 승인된 범위로 제한하고, 예산(Budget)은 상한선을 두며, 중요한 모든 사항에 대해서는 여전히 제가 개입하는 방식 말입니다. 그런 형태라면 AI 에이전트는 제 일주일을 진정으로 수월하게 만들어 주었고, 제가 놓쳤을 법한 무언가를 잡아내기도 했습니다.

결론 (The bottom line)

AI 에이전트가 아직 독자적으로 클라우드 운영(Cloud Ops)을 수행할 수는 없습니다. 그렇지 않다고 주장하는 사람이 있다면, 그 사람은 고장 난 서비스의 규모를 10배로 확장하라고 자신 있게 제안하는 AI 에이전트를 본 적이 없는 것입니다. 하지만 당신이 위험한 20%를 통제하는 동안 지루한 초기 80%를 처리해 주는 분류 파트너(Triage partner)로서, AI 에이전트는 이미 오늘날에도 유용합니다. 지루한 작업은 AI에게 맡기되, 가드레일(Guardrails)은 엄격하게 유지하세요. 그리고 AI가 얼마나 확신에 찬 어조로 말하는지와 그것이 얼마나 옳은지를 절대 혼동하지 마세요.