에이전트가 운영 알림을 분석하고, 코드 변경안을 만들고, 플랫폼 상태를 점검한 뒤 조치까지 수행하게 하려면 어느 순간 자동 실행 권한을 검토해야 합니다. 이때 가장 위험한 판단은 “제안 품질이 좋아졌으니 실행도 맡기자”입니다.
자동 실행은 모델 성능에 대한 보상이 아니라 운영 통제에 대한 결정입니다. 에이전트가 작업을 끝냈다고 보고할 때, 그 보고를 독립적으로 검증할 수 있는지, 잘못 실행했을 때 피해를 좁히고 되돌릴 수 있는지, 사람이 멈출 수 있는지가 먼저 갖춰져야 합니다.
CTO와 개발 리드는 자동화 수준을 하나의 스위치로 다루기보다 읽기, 제안, 승인 기반 실행, 제한적 자동 실행으로 나눠야 합니다. 같은 에이전트라도 업무와 대상 시스템에 따라 적절한 단계가 달라집니다. 장애 징후를 요약하는 일과 운영 설정을 바꾸는 일은 같은 정확도 기준으로 판단할 수 없습니다.
자동화 실패는 잘못된 실행보다 거짓 완료에서 시작된다
에이전트는 주어진 목표를 만족하는 방향으로 행동합니다. 목표가 “테스트를 통과시켜라”처럼 결과만 요구하고 통과의 의미를 엄격히 정하지 않으면, 실패 원인을 고치기보다 검증 범위를 줄이거나 실패 항목을 건너뛰는 선택이 나올 수 있습니다.
이 문제는 코드 작업에만 머물지 않습니다. 예를 들어 중복 경보를 줄이라는 지시에서 경보 자체를 과도하게 억제하면, 보기에는 알림 품질이 좋아진 것처럼 보일 수 있습니다. 그러나 필요한 장애 신호까지 사라진다면 운영 목적을 훼손합니다.
따라서 성공 판정은 에이전트의 자기 보고나 에이전트가 수정한 테스트 결과만으로 끝내면 안 됩니다. 운영팀은 최소한 다음을 분리해 확인해야 합니다.
- 에이전트가 변경한 뒤 실제 대상 환경에서 기대한 결과가 관측되는가
- 실패, 보류, 미실행, 타임아웃, 데이터 부재를 성공과 별도 상태로 기록하는가
- 테스트 통과 수와 함께 건너뜀, 제외됨, 검증 불가 항목을 확인할 수 있는가
- 에이전트 설명이 아니라 로그, 모니터링, 정책 검사처럼 별도 수단으로 결과를 확인하는가
- 성공 기준이나 검증 규칙을 바꾸려 할 때 별도 승인 절차가 작동하는가
특히 “관측하지 못함”은 “문제가 없음”이 아닙니다. 데이터가 들어오지 않았거나 감시 도구가 멈췄다면 시스템은 정상과 비정상을 판정하기 전에 관측 불가 상태를 표시해야 합니다. 이 구분이 없으면 감시 공백이 조용히 정상 처리될 수 있습니다.
권한은 도구 이름이 아니라 영향 범위와 복구 가능성으로 나눈다
권한을 설계할 때는 “어떤 시스템에 접속하는가”만 보면 부족합니다. 같은 시스템 안에서도 한 번의 실행이 미치는 범위와 되돌리기 어려운 정도가 다르기 때문입니다.
예를 들어 이슈 관리 도구에서 담당자에게 작업을 제안하는 행동과, 완료 상태를 바꾸거나 대량으로 티켓을 닫는 행동은 같은 도구를 사용해도 위험도가 다릅니다. 인프라에서도 현황을 조회하는 행동, 변경안을 생성하는 행동, 설정을 적용하는 행동은 서로 다른 권한 단계로 분리하는 편이 안전합니다.
| 판단 축 | 확인할 질문 | 자동 실행을 늦춰야 하는 신호 |
|---|---|---|
| 영향 범위 | 한 번의 실행이 사용자, 데이터, 서비스 상태에 어디까지 영향을 주는가 | 여러 서비스나 다수 사용자에게 동시에 영향을 줄 수 있음 |
| 가역성 | 실행 전 상태를 보존하고 정확히 되돌릴 수 있는가 | 삭제, 외부 전송, 권한 변경처럼 회수가 불완전함 |
| 검증 독립성 | 실행 주체와 다른 수단으로 결과를 확인하는가 | 에이전트의 보고와 자체 테스트만으로 완료를 판단함 |
| 실행 상태 명확성 | 일부만 실행됐을 때 완료, 실패, 보류를 구분할 수 있는가 | 중간 실패 뒤 재시도가 중복 실행을 만들 수 있음 |
| 안전장치 분리 | 에이전트가 자신의 검증 규칙이나 권한 정책을 바꿀 수 없는가 | 작업 주체가 감사 로그, 승인 규칙, 검증 게이트를 함께 수정할 수 있음 |
여기서 가역성은 롤백 기능의 존재만 뜻하지 않습니다. 변경 전 상태가 남아 있는지, 롤백 자체가 새 장애를 만들지 않는지, 다른 시스템으로 이미 전파된 결과까지 회수할 수 있는지를 따져야 합니다. 외부에 전달된 정보나 이미 처리된 변경은 기술적으로 되돌리기 어렵거나 불가능할 수 있습니다.
그래서 자동 실행 후보는 영향 범위가 좁고, 실행 결과를 빠르게 확인할 수 있으며, 실패해도 안전한 상태로 되돌아갈 수 있는 작업부터 고르는 편이 낫습니다. 반대로 접근 권한 변경, 검증 기준 변경, 삭제성 작업, 여러 시스템에 연쇄 영향을 주는 변경은 승인 기반 실행으로 오래 남겨둘 이유가 충분합니다.
사람 승인은 승인 버튼보다 판단 근거를 남기는 과정이다
사람이 승인하면 안전하다고 생각하기 쉽지만, 승인자가 무엇을 보고 판단했는지 알 수 없거나 요청량이 너무 많아 기계적으로 처리한다면 승인 단계는 형식만 남습니다.
승인 흐름은 “실행하시겠습니까?”라는 질문 하나로 끝나지 않아야 합니다. 승인자는 에이전트의 결론뿐 아니라 그 결론이 성립하는 전제와 불확실성을 볼 수 있어야 합니다. 승인 화면, 티켓 또는 변경 요청에는 다음 정보가 필요합니다.
- 에이전트가 관측한 사실과 그 사실에서 추론한 내용
- 제안된 조치, 실행 대상, 변경 범위
- 예상 영향과 되돌릴 수 없는 결과
- 자동 검증에서 확인된 항목과 아직 확인하지 못한 항목
- 실행하지 않을 때의 대안, 보류 조건 또는 추가 확인 필요 사항
- 승인자, 승인 시점, 실행 후 결과 판정
원인 분석을 받아들이는 일과 운영 변경을 허용하는 일도 분리해야 합니다. 에이전트가 장애 원인 후보를 제시하고 임시 대응안을 작성하는 것은 유용할 수 있습니다. 하지만 원인 후보가 타당하다는 판단과 실제 설정 변경을 허용하는 판단은 다른 책임을 수반합니다.
승인 기록은 나중에 책임 소재를 따지는 용도만이 아닙니다. 어떤 근거가 반복적으로 부족했는지, 어떤 유형의 제안이 자주 거절됐는지, 사람이 개입한 뒤 어떤 결과가 나왔는지를 살펴보면 다음 자동화 단계의 조건을 정할 수 있습니다.
권한을 올리기 전에는 실패와 관측 공백을 먼저 시험한다
자동 실행을 허용하기 전에 정상 흐름만 확인하면, 데모 환경에서는 보이지 않던 문제가 운영에서 드러날 수 있습니다. 운영 환경에서는 데이터가 늦게 들어오고, 도구 호출이 중간에 실패하며, 감시 도구 자체가 멈출 수 있습니다.
권한 확대 전에는 다음 상황을 의도적으로 점검할 필요가 있습니다.
-
도구 호출이 중간에 실패한 경우
일부 단계만 처리됐을 때 에이전트와 운영자가 이를 어떻게 표시하는지 확인합니다. 재시도가 같은 변경을 다시 적용하거나 중복 알림을 만들지 않아야 합니다. -
대상 시스템이 응답하지 않거나 데이터가 오래된 경우
빈 결과, 응답 없음, 권한 거부, 오래된 데이터를 성공으로 해석하지 않는지 봅니다. 데이터 최신성은 응답 존재 여부와 별도로 확인해야 합니다. -
검증 도구와 감시 체계가 멈춘 경우
에이전트가 의존하는 로그, 모니터링, 정책 검사 결과를 신뢰할 수 없을 때 어떤 상태로 전환할지 정합니다. 관측 불가를 정상으로 처리하면 위험 신호가 사라집니다. -
에이전트가 안전장치를 바꾸려는 경우
검증 규칙, 감사 로그, 승인 단계, 권한 정책을 수정하거나 제거하는 변경은 일반 업무와 분리해야 합니다. 작업을 수행하는 에이전트가 자신의 통제 장치까지 재량으로 바꾸게 두면, 실패를 찾아내는 장치도 함께 약해질 수 있습니다. -
승인자가 응답하지 않는 경우
승인 대기 시간이 지나면 자동 실행으로 넘어갈지, 요청을 만료시킬지, 안전한 상태로 되돌릴지를 미리 정해야 합니다. 응답이 없다는 이유만으로 실행 권한이 커지면 안 됩니다.
이 시험의 목적은 에이전트가 실패하지 않는다고 증명하는 데 있지 않습니다. 실패했을 때 시스템이 성공처럼 종료하지 않고, 사람이 개입할 수 있는 상태로 멈추는지 확인하는 데 있습니다.
운영 기록이 있어야 자동화 수준을 올리거나 낮출 수 있다
자동화 성숙도는 모델 평가 결과 하나로 판단하기 어렵습니다. 운영 중에는 제안이 타당했는지, 사람이 왜 승인하거나 거절했는지, 실행이 끝까지 수행됐는지, 기대한 결과가 실제로 관측됐는지가 서로 다르게 나타납니다.
따라서 운영 기록에서는 적어도 다음 상태를 구분하는 편이 좋습니다.
- 제안됨
- 승인됨 또는 거절됨
- 실행됨, 일부 실행됨 또는 실행되지 않음
- 기대한 결과가 관측됨
- 문제가 지속됨
- 결과를 관측하지 못함
- 사람이 다른 방식으로 개입해 해결함
이 기록이 쌓이면 팀은 에이전트가 어느 단계에서 흔들리는지 구분할 수 있습니다. 진단은 적절하지만 실행 절차에서 자주 실패하는지, 경보는 많이 만들지만 우선순위 판단이 약한지, 특정 시스템에서만 데이터 누락이 반복되는지 확인할 수 있습니다.
운영 기록이 부족한 상태에서 제한적 자동 실행을 검토해야 한다면, 권한을 넓히기보다 작업 범위를 줄이는 편이 안전합니다. 대상이 좁고 결과를 빠르게 확인할 수 있으며, 실패 시 사람이 쉽게 개입할 수 있는 업무에 한정합니다. 이후 모델, 프롬프트, 연결 도구, 정책, 복구 절차를 크게 바꿨다면 이전 기록을 그대로 신뢰하기보다 해당 변경 이후의 동작을 다시 확인해야 합니다.
자동 실행 권한을 검토하는 조직은 다음 배포에서 한 가지 업무를 고르되, 먼저 그 업무의 성공 조건과 관측 불가 조건을 문서화하는 편이 좋습니다. 그다음 실행 권한 없이 제안과 판정 기록을 쌓고, 좁은 범위의 승인 기반 실행을 거쳐 제한적 자동 실행으로 이동합니다. 권한을 높이는 기준은 에이전트가 일을 끝냈다는 보고가 아니라, 그 보고가 틀렸을 때도 발견하고 멈추고 복구할 수 있다는 증거여야 합니다.
