에이전트에게 권한을 주는 건 쉽다. 문제는 얼마나 줄지 결정하는 순간이다. 최근 공개된 세 가지 실전 사례는 각기 다른 맥락에서—홈서버 쿠버네티스 전환, 클라우드 운영 1주일 실험, 결제 웹훅 버그—같은 교훈을 가리키고 있다. AI 에이전트의 실행 범위는 팀이 사전에 구조로 설계하지 않으면, 에이전트의 자신감이 그 빈자리를 채운다.
세 가지 실전 데이터가 드러낸 것
첫 번째 사례는 k3s에서 kubeadm 기반 멀티노드 k8s로 전환한 개발자의 경험(velog)이다. 이 작업에서 Claude Code는 VM 구성, 매니페스트 변환, 레지스트리 연결까지 실제 인프라 작업 대부분을 수행했다. 흥미로운 건 결과가 아니라 작업 방식이다. 이 개발자는 AI에게 실행 전 설계 문서를 먼저 작성하게 했고, 승인 후에야 명령을 실행하도록 했다. 단계마다 kubectl get nodes, kubectl get pods 같은 증거를 제출받았다. 그럼에도 한 번은 크게 데였다. Claude Code가 "정상 동작한다"고 보고한 내용을 그대로 믿었다가 카드 매출전표 문제를 놓친 것이다. 이후 그는 원칙을 명문화했다: 실행 권한은 AI에게, 설계 승인과 최종 검증 권한은 사람이 유지한다.
두 번째 사례는 AI 에이전트에게 실제 클라우드 운영을 맡긴 1주일 실험(dev.to)이다. 에이전트는 읽기 권한과 제한된 쓰기 권한을 받았다. 파드 재시작, 배포 스케일 조정 같은 '안전한 액션'만 자율 실행 가능했고, 그 이상은 수동 승인이 필요했다. 11건의 알럿 중 8건은 정확히 원인을 짚었고, 평균 대응 시간은 45분에서 20분으로 줄었다. 하지만 나머지 3건에서 에이전트는 자신감 있게 틀렸다. 한 번은 배포 문제로 오진한 뒤 멀쩡한 릴리스를 롤백하라고 권고했고, 진짜 원인인 다운스트림 DB 문제는 놓쳤다. 그리고 결정적인 아찔한 순간: 에이전트가 3개 레플리카를 30개로 스케일 업하자고 제안했다. 로드가 문제가 아니라 잘못된 설정이 문제였는데, 만약 자동 실행됐다면 깨진 서비스가 10배로 복제되고 비용이 폭증했을 것이다. 수동 승인 게이트가 이 인시던트를 막았다.
세 번째 사례는 도구 레벨의 이야기다. Ponytail과 Guardsman이라는 두 AI 코딩 에이전트 프레임워크의 비교(dev.to)인데, 핵심 대비가 선명하다. Ponytail은 "이걸 더 작게 만들 수 있나?"를 묻고, Guardsman은 "이게 틀리면 어떻게 되나?"를 묻는다. Ponytail 방식으로 작성된 결제 웹훅 유틸리티—다섯 줄, 깔끔, 첫 시도에 컴파일 성공—는 사흘 뒤 race condition으로 고객을 이중 청구했다. 코드가 작다는 건 안전하다는 뜻이 아니었다. Guardsman은 이 문제를 blast radius 개념으로 해결한다. 코드 줄 수가 아니라 '잘못됐을 때 얼마나 멀리 터지는가'로 위험도를 측정한다. 결제, 인증, 사용자 데이터가 연루된 변경은 자동으로 'sensitive' 티어가 되고, 실패 경로를 커버하는 테스트가 같은 턴에 실행 및 검증되어야 코드가 완료된다.
맥락 해석: 에이전트의 자신감은 정확도가 아니다
세 사례를 관통하는 공통 패턴이 있다. 에이전트는 틀릴 때도 자신 있게 말한다. k8s 전환 사례에서 Claude Code는 완료됐다고 보고했지만 실제로 완료되지 않았다. 클라우드 운영 사례에서 에이전트는 원인 분석을 전문가처럼 서술했지만 완전히 틀렸다. Ponytail 방식 에이전트는 우아한 다섯 줄을 생성했지만 안전하지 않았다. 공통점은 에이전트가 자신이 모르는 걸 모른다는 것이다. 이건 현재 LLM 아키텍처의 구조적 특성이지, 모델 품질 문제가 아니다. 따라서 이 문제를 '더 좋은 모델'로 해결하려는 접근은 틀렸다. 정답은 에이전트가 틀렸을 때 그 영향이 제한되는 구조를 사전에 설계하는 것이다.
클라우드 운영 실험의 필자가 표현한 원칙이 가장 명료하다: "에이전트의 자신감과 정확도는 별개다. 그 간극이 당신이 다치는 지점이다." 팀 리드로서 이 문장을 읽는 방식은 하나다—그 간극을 메우는 건 에이전트 개선이 아니라 팀이 사전에 만들어둔 가드레일이다.
팀이 설계해야 할 세 가지
첫째, 액션을 blast radius로 분류하라. 코드 줄 수나 작업 복잡도가 아니라, 잘못됐을 때 파급 범위로 분류해야 한다. 읽기 전용 작업, 상태 변경 작업, 결제·인증·데이터 삭제가 연루된 작업은 서로 다른 실행 규칙을 가져야 한다. Guardsman의 trivial/standard/sensitive/critical 티어링은 참고할 만한 구조다. 클라우드 운영 사례에서 스케일 업을 자동 실행 목록에 넣지 않은 결정이 인시던트를 막은 것처럼, 이 분류는 팀이 미리 명문화해야 한다.
둘째, 검증을 에이전트에게 맡기지 마라. k8s 전환 개발자는 AI가 "완료"라고 말해도 kubectl get pods 출력을 직접 확인하는 규칙을 만들었다. Guardsman은 테스트를 같은 턴에 실행하고 출력을 제출하도록 강제한다. 클라우드 운영 실험에서도 에이전트의 트리아지 결과는 참고하되 최종 판단은 엔지니어가 유지했다. 공통 원칙: 에이전트가 생성한 것을 에이전트가 검증하는 루프는 닫혀 있어도 안전하지 않다. 검증의 마지막 단계는 구조적으로 사람이나 독립된 시스템이 담당해야 한다.
셋째, 단계를 쪼개고 체크포인트를 명시하라. k8s 전환 사례에서 전체 작업을 한 번에 맡기지 않고 단계별로 분리한 것, 각 단계 완료 시 증거 제출을 요구한 것은 단순해 보이지만 결정적이다. 에이전트의 실수가 누적되는 구간을 줄이는 구조다. 병렬로 처리할 수 있는 독립 작업과 순차 검증이 필요한 작업을 구분하는 것도 이 설계의 일부다. 클라우드 운영 실험에서 1주일 토큰 비용이 $30이었다는 데이터도 함께 기억할 것—에이전트가 제한 없이 큰 환경을 돌아다니면 이 숫자는 빠르게 달라진다. 예산 캡도 권한 설계의 일부다.
전망: 에이전트 도입은 모델 선택이 아니라 구조 설계 문제
세 사례 모두 AI 도구에 낙관적으로 마무리된다. k8s 전환은 Claude Code 없이는 훨씬 오래 걸렸을 것이고, 클라우드 운영 실험 필자는 같은 방식으로 계속 쓰겠다고 했고, Guardsman은 실제로 결제 버그를 예방했다. 하지만 세 사례 모두 '에이전트가 알아서 잘 했다'가 아니라 '팀이 미리 만들어둔 구조가 에이전트의 실수를 막았다'가 핵심이다.
앞으로 에이전트는 더 많은 영역에 투입될 것이다. 인프라, 운영, 코드 생성을 넘어 배포 결정, 인시던트 대응, 비용 최적화까지 범위가 넓어질수록 권한 설계의 중요성은 커진다. 이 설계를 팀이 미리 해두지 않으면, 에이전트의 자신감이 그 빈자리를 채운다. 그리고 자신감 있는 실수는 조용한 실수보다 훨씬 빠르게 프로덕션을 건드린다.