에이전트 해체: AI 에이전트 라이프사이클의 누락된 절반
핵심 요약
- Gartner는 배포 후에야 발견된 거버넌스 격차로 인해 2027년까지 40%의 기업이 자율 AI 에이전트를 강등 또는 해체할 것으로 예측합니다 — 프로덕션에 도달한 에이전트조차 1년 내 40%의 폐기율에 직면하며, 대부분의 기업은 안전하게 폐기를 실행할 라이프사이클 인프라가 부족합니다 (Gartner).
- Gravitee의 2026년 설문조사에서 엔터프라이즈 에이전트 플릿이 분기마다 약 2배로 성장하는 반면, 에이전트 정체성을 개별화하는 팀은 약 20%만인 것으로 나타났습니다 — 해체되지 않은 에이전트는 "다크 매터"가 됩니다. 누구도 귀속시킬 수 없는 자격 증명과 행위자이며, 목적을 넘어 존속한 서비스 계정을 가진 에이전트도 포함됩니다 (Gravitee State of AI Agent Security 2026).
- TrueFoundry는 2026년 8월 8일 최초의 포괄적인 에이전트 해체 플레이북을 발표했습니다 — 6단계(인벤토리, 리디렉트, 취소, 보존, 툼스톤, 검증)이며, 각 단계에는 건너뛸 때의 실패 모드가 있습니다. 핵심 통찰은 폐기가 에이전트가 살아있는 동안 얼마나 잘 거버넌스되었는지에 비례하여 저렴하고 신뢰할 수 있다는 것입니다 (TrueFoundry).
- 88%의 AI 에이전트 프로젝트가 평균 $340,000의 실패 비용으로 프로덕션에 도달하지 못합니다 — 출하되는 12% 중 Gartner의 40% 해체율은 라이프사이클 과제가 배포뿐만 아니라 프로덕션에 도달한 후 실패하는 에이전트의 거버넌스된 폐기에 있음을 의미합니다 (digitalapplied.com).
- 설계 교훈은 프로비저닝까지 거슬러 올라갑니다. 모든 에이전트는 폐기를 염두에 두고 생성되어야 합니다 — 개별화된 정체성, 작업 파생 스코프, 강제된 예산, 앨리어스된 종속 항목, 중앙 추적. "이것을 어떻게 끌 것인가?"에 답할 수 없는 에이전트의 생성은 조직을 고고학 프로젝트나 영원히 폐기하지 않는 것 중 하나에 사전 헌신하게 만듭니다.
Gartner는 프로덕션 인시던트 이후에야 발견된 거버넌스 격차로 인해 2027년까지 40%의 기업이 자율 AI 에이전트를 강등 또는 해체할 것으로 예측합니다. 2026년 5월 26일 보도자료에서 발표된 이 예측은 엔터프라이즈 AI 문헌이 거의 다루지 않은 라이프사이클 문제를 지적합니다. 배포 가이드는 어디에나 있지만, 폐기 가이드는 극히 드뭅니다. 그 결과가 Gravitee의 2026년 설문조사가 "다크 매터"라고 부르는 것입니다 — 엔터프라이즈 에이전트 플릿은 분기마다 약 2배로 성장하는데, 에이전트 정체성을 개별화하는 팀은 5분의 1 정도뿐입니다. 끝났지만 서비스 계정이 끝나지 않은 파일럿. 더 나은 것으로 교체되었지만 이전 에이전트의 키가 계속 작동한 워크플로. 떠난 엔지니어의 실험이 여전히 토큰을 보유하고 있는 것. 이것들은 해체되지 않은 에이전트입니다. 불활성 공격 표면이 아니라 누구도 더 이상 유지하지 않는 목적 아래 실행되는 자율성입니다.
이 글은 TrueFoundry가 2026년 8월 8일에 발표한 6단계 해체 플레이북 — 인벤토리, 리디렉트, 취소, 보존, 툼스톤, 검증 — 을 매핑하고, IdeaBosque의 기존 글이 다루는 거버넌스 아키텍처와 배포 라이프사이클에 연결합니다. 이 글은 런타임 강제를 다루는 Kill Switch by Design: Agent Governance Architecture와 배포 프로세스를 다루는 From Pilot to Production: The Five-Phase Agent Deployment Playbook를 기반으로 구축됩니다. 여기서는 두 글이 생략하는 단계에 집중합니다. 에이전트가 유용한 수명의 끝에 도달했을 때 무슨 일이 일어나는지, 그리고 그 답이 에이전트가 애초에 거버넌스 가능했는지를 결정하는 이유입니다.
폐기가 라이프사이클의 어려운 절반인 이유
프로비저닝은 잘 수행하기 쉽습니다. 모든 것이 현재 시제이고 동기가 부여되어 있기 때문입니다. 팀은 에이전트를 원하고, 예산이 존재하며, 체크리스트는 론칭이 의존하므로 따라집니다. 폐기는 이러한 조건을 모두 반전시킵니다. 그래서 조용히, 그리고 자주 실패하는 것입니다. 동기는 사라졌습니다 — 팀은 대체품으로 이동했고, 파일럿의 스폰서는 팀을 옮겼으며, 누구의 OKR에도 "것을 끄세요"라고 쓰여 있지 않습니다. 지식은 사라졌습니다 — 에이전트의 키가 어디 있는지 아는 엔지니어는 떠났고, 에이전트 자체는 개별화된 적이 없으므로 인벤토리에 나타나지 않습니다. 그리고 인센티브가 반전되었습니다 — 무언가를 끄는 것은 누군가 잊어버린 종속성을 망가뜨릴 위험이 있고, 계속 실행하는 것은 오늘 눈에 보이는 위험은 없습니다. 따라서 국지적으로 합리적인 행동은 항상 그대로 두는 것입니다.
그 결과 메커니즘이 반대 없이 실행됩니다. 프로비저닝이 인벤토리와 폐기를 앞지르면, 정체성과 자격 증명은 원래 워크로드가 사라진 후에도 축적됩니다. 특히 에이전트적 에스컬레이션은 남은 것이 불활성 키가 아니라 실행 중인 자율성이라는 것입니다. 해체되지 않은 에이전트는 누구도 더 이상 유지하지 않는 목적 아래에서 행동하고, 소비하고, 데이터를 계속 다룹니다. 900명 이상의 경영진과 기술 실무자를 대상으로 한 Gravitee의 설문조사에서 85%의 조직이 AI 에이전트 행동에 대한 공식적 책임 구조가 없으며, 에이전트가 행동할 때 책임자로 지명된 개인을 확인할 수 있는 조직은 7.2%에 불과합니다. 아무것도 기억하지 못하는 에이전트가 잘못 행동할 때, 발견할 수 없으므로 격리할 수도 없습니다.
Gartner의 4단계 자율성 분류법은 정책 수준에서 문제를 프레이밍합니다. 레벨 4 에이전트는 "정의된 가드레일 내에서 독립적으로 행동을 실행하며, 인간은 개별 결정이 아닌 예외, 감사 로그 및 집계된 결과를 검토합니다." 레벨 4 에이전트가 해체될 때, 가드레일, 감사 로그, 집계된 결과 모두가 처리되어야 합니다 — 프로세스만이 아닙니다. 레벨 1 또는 레벨 2 에이전트(읽기 전용, 인간 실행)는 프로세스를 중지하여 폐기할 수 있습니다. 레벨 4 에이전트는 불가능합니다. 폐기 프로세스는 자율성 수준과 일치해야 하지만, 대부분의 기업은 레벨 1 폐기 프로세스(프로세스 중지)를 레벨 4 에이전트(몇 달간 자율적으로 행동하고, 데이터를 기록하고, 감사 추적을 축적한 것)에 적용합니다. 그 불일치가 Gartner가 지적하는 근본 원인입니다. "기업은 AI 에이전트 거버넌스를 이진법으로 취급하고 있으며, 잠그거나 완전히 신뢰하거나이고, 그것이 실패의 근본 원인이다."
6단계 폐기 플레이북과 그것이 완성하는 라이프사이클의 시각화:
6단계 플레이북
TrueFoundry의 플레이북은 폐기를 6단계로 정리하며, 각 단계에는 건너뛸 때의 실패 모드가 있습니다. 단계는 전형적인 해체 실수를 방지하도록 순서가 정해져 있습니다 — 리디렉트 전에 취소하여 프로덕션을 망가뜨리거나, 감사 의무를 가진 기록을 삭제하는 것 등입니다.
1. 인벤토리
에이전트가 보유하고 접촉하는 모든 것을 열거합니다. 자격 증명(공식 것과 복사본), 툴 스코프, 예산 라인, 예약된 트리거, 소비하는 큐, 호출하는 시스템, 참조하는 대시보드. 에이전트가 거버넌스된 플레인에서 개별화되었다면 인벤토리는 간단하고, 그렇지 않다면 고고학적 조사가 필요합니다. 이것을 건너뛰는 것이 3단계에서 프로덕션을 망가뜨리는 방법입니다 — 3개의 다른 워크플로와 공유된 것으로 밝혀지는 자격 증명을 취소하고, 그 워크플로들이 아무도 예상하지 못한 방식으로 실패합니다.
2. 리디렉트 및 드레인
무엇이든 취소하기 전에, 수신을 중지하고 종속 항목을 이동합니다. 예약된 트리거가 비활성화되어 새 작업이 시작되지 않습니다. 큐가 드레인되거나 이전됩니다. 실행 중인 작업이 체크포인트되거나 완료가 허용됩니다. 자식 에이전트가 중지됩니다. 호출자는 에이전트 수준의 서비스 앨리어스, 워크플로 레지스트리, 게이트웨이 라우트, 또는 애플리케이션 플랫폼이 유지하는 간접 레이어를 통해 후속 에이전트로 향합니다. 간접 참조를 통해 호출하는 종속 항목은 하나의 항목 변경으로 이전합니다. 엔드포인트를 하드코딩한 종속 항목은 조정된 이전입니다.
폐기 모드가 결정하는 하나의 주의사항. 리디렉트는 계획된 교체에 적합하지만, 침해되거나 안전하지 않은 에이전트는 일반적으로 페일 클로즈되어야 합니다 — 호출자는 오류를 받지, 잘못된 가정을 물려받는 조용한 후속 에이전트가 되지 않습니다. 부모 글의 킬스위치 아키텍처는 페일 클로즈드를 신뢰할 수 있게 만드는 런타임 강제를 다룹니다. 해체는 같은 격리의 영구 버전입니다.
3. 취소
모든 자격 증명이 무효화되고(자격 증명을 취소하는 것은 그 복사본을 취소하는 것입니다 — 같은 자격 증명입니다), 스코프가 제거되고, 정체성이 비활성화되며, 에이전트가 전용 가상 계정 또는 확실하게 전파된 식별자를 가진 경우, 추가 모델 호출이 게이트웨이를 통과하지 않도록 지출 규칙이 0으로 강제됩니다. 이것은 인시던트 런북의 격리 레버를 영구적으로 당긴 것입니다. 장기 실행 에이전트 패턴 글은 런타임 서킷 브레이커가 잘못 행동하는 에이전트를 몇 초 만에 중지시키는 방법을 설명합니다. 취소는 같은 원칙을 단일 툴 호출이 아닌 에이전트의 전체 정체성에 적용한 것입니다.
실패 모드. 11개의 다른 시스템이 사용하는 키를 취소할 용기는 아무에게도 없습니다. 공유 자격 증명은 폐기를 무기한 연기합니다 — 그래서 프로비저닝 시점의 개별화된 정체성은 보안의 사치가 아니라 폐기의 전제 조건입니다.
4. 보존
삭제 본능이 잘못되는 단계입니다. 폐기된 에이전트의 추적, 결정, 가드레일 결과, 평가 이력은 종종 에이전트보다 오래 지속되는 감사 및 법적 보존 의무를 가집니다. 폐기는 행위자가 더 이상 행동할 수 없다는 것을 의미하지, 행동했다는 증거가 자동으로 사라진다는 것을 의미하지 않습니다. 무엇을, 얼마나 오래 보존할지는 본능이 아닌 보존, 프라이버시, 삭제 정책을 따릅니다. 규제 산업에서 — EU AI Act의 제50조 투명성 의무는 2026년 8월 2일부터 집행 가능합니다 — 에이전트의 결정 기록은 에이전트 자체가 폐기된 후에도 수년간 지속되어야 할 수 있습니다.
5. 툼스톤
거버넌스 기록에서 에이전트 정체성을 폐기로 표시합니다. 이것은 오늘날 대부분의 시스템에서 플랫폼 라이프사이클 상태가 아닙니다 — 조직의 거버넌스 시스템이 유지하는 기록입니다. 툼스톤 항목은 다음을 포착해야 합니다. 에이전트가 언제 폐기되었는지, 누가 승인했는지, 어떤 후속 에이전트(있는 경우)가 교체했는지, 보존된 기록이 어디에 있는지.
지식 이전은 모두가 잊는 단계입니다. 폐기된 에이전트의 축적된 설정 — 프롬프트, 스코프, eval 케이스, 인시던트 파생 가드레일 — 은 배포와 함께 사라져서는 안 되는 조직적 학습이며, 후속 에이전트로 이전되어야 합니다. 어떤 공급업체 카탈로그 필드가 신뢰할 수 없는지 배우는 데 6개월을 보낸 에이전트는 그 지식을 전달해야 합니다. 그렇지 않으면 후속 에이전트가 같은 실수를 반복합니다.
6. 검증
취소 후, 귀속은 폐기된 에이전트의 성공 트래픽이 0임을 보여야 합니다. 취소된 자격 증명 시도는 인증 실패로만 나타나야 합니다. 거버넌스된 경로를 우회하는 문서화되지 않은 대체 정체성이나 경로에서의 호출이 없어야 합니다. 잔여 성공 트래픽은 취소가 불완전하거나 다른 자격 증명이 존재함을 의미하며, 그 발견이 플레이북의 가장 가치 있는 산출물입니다.
검증 단계는 폐기와 "아마도 폐기됨"을 구분하는 것입니다. 그것 없이는 조직은 에이전트를 중지했지만 중지 상태가 유지되었는지 확인할 수 없습니다. Gravitee 설문조사에서 7.2%의 조직만이 에이전트 행동에 책임이 있는 사람을 지명할 수 있다는 발견은, 대부분의 기업에서 폐기 검증에 책임이 있는 사람도 없다는 것을 의미합니다.
프로비저닝 테스트로서의 폐기
플레이북의 모든 단계는 에이전트의 운영 수명이 거버넌스된 레이어를 통해 실행된 경우 저렴하고, 그것을 우회한 비율에 비례하여 비쌉니다. 인벤토리는 에이전트가 스코프, 예산, 트래픽이 플레인 기록인 등록된 주체인 경우 쿼리이며, 그 접근이 환경 변수에 붙여넣은 공유 키인 경우 포렌식 프로젝트입니다. 리디렉트는 종속 항목이 간접 참조를 통해 호출하는 경우 하나의 레지스트리 항목이며, 엔드포인트를 하드코딩한 경우 조정된 다중 팀 이전입니다. 취소는 정체성이 개별화되었으면 외과적이고 자격 증명이 공유되었으면 부수적입니다. 보존은 추적이 중앙에서 기록되었으면 더 간단하고, 증거가 임시 배포 로컬 스토리지에 흩어져 있으면 취약합니다.
이것은 플레이북의 역방향 결론을 도출합니다. 해체는 프로비저닝 테스트입니다. "이것을 어떻게 끌 것인가?"라는 질문 — 론칭 날에, 첫 요청 전에 묻는 — 은 에이전트가 거버넌스하에 태어나고 있는지를 한 문장으로 감사합니다. 개별화된 정체성. 작업 파생 스코프. 강제된 예산. 앨리어스된 종속 항목. 중앙 추적. 생성 시 그것에 답할 수 있는 에이전트는 오후에 폐기됩니다. 답할 수 없는 에이전트의 생성은 조직을 고고학 프로젝트나, 더 가능성 있는, 영원히 폐기하지 않는 것 중 하나에 사전 헌신하게 만듭니다 — 그것은 에이전트가 다크 매터 집단에 합류한다는 것을 의미하며, 누구도 귀속시킬 수 없는 자격 증명과 행위자가 아무도 승인한 것을 기억하지 못하는 작업을 수행합니다.
5단계 배포 플레이북은 1~5단계를 다룹니다. 프로세스 고고학, 툴 스코핑, 관측 가능성 인프라, 카나리 섀도우 모드, 인간 인수 프로토콜입니다. 해체는 제6단계입니다 — 라이프사이클을 닫는 것입니다. 거버넌스 체크리스트는 배포 전 검토를 다룹니다. 폐기 감사(아래)는 배포 후 대응물입니다.
폐기 감사
두 가지 질문, 하나의 자산.
후방: 지난 1년간 폐기한 에이전트를 나열하세요. 각각에 대해 취소된 자격 증명, 0으로 강제된 예산 규칙, 보존된 추적, 툼스톤 기록을 보여줄 수 있습니까? 목록 자체가 없다는 것 자체가 발견입니다 — 조직이 폐기한 것을 기록하지 않고 에이전트를 폐기해왔다는 것을 의미하며, 이는 폐기하지 않은 것과 구별할 수 없습니다.
전방: 다음에 론칭할 에이전트에 대해, 첫 요청 전에 "이것을 어떻게 끌 것인가?"에 서면으로 답하세요. 답이 한 단락 이상이라면, 에이전트는 폐기 불가능한 상태로 태어나고 있습니다. AI Agent Governance Checklist는 이 질문의 배포 전 버전입니다. 폐기 감사는 배포 후 버전입니다 — 같은 원칙, 라이프사이클의 반대쪽.
NetSuite, BigCommerce, 3개의 공급업체 카탈로그를 RFQ 에이전트로 실행하는 중견 B2B 기업에게, 폐기 감사는 구체적인 윤곽을 가집니다. 에이전트는 NetSuite에 대한 OAuth 토큰(SuiteQL 읽기로 스코프), BigCommerce에 대한 API 키(카탈로그 읽기로 스코프), 3개의 공급업체 포털에 대한 자격 증명(다양한 스코프, 다양한 인증 방식)을 가집니다. 4시간마다 실행되는 예약된 트리거가 있습니다. 영업팀이 모니터링하는 견적 큐에 견적을 기록합니다. 다른 2개의 워크플로도 읽는 공급업체 카탈로그 캐시에서 읽습니다. 이 에이전트를 폐기하는 것은, 6개의 자격 증명 세트를 모두 인벤토리하고, 예약된 트리거를 비활성화하고, 견적 큐를 드레인하고, 2개의 하류 카탈로그 캐시 리더를 후속 에이전트 또는 인간 폴백으로 리디렉트하고, 6개의 자격 증명을 모두 취소하고, 회사의 7년 감사 정책에 따라 견적 결정 로그를 보존하고, 후속 귀속과 함께 거버넌스 기록에서 에이전트를 툼스톤화하고, 다음 24시간 이내에 폐기된 에이전트의 정체성으로 NetSuite 또는 BigCommerce API 호출이 나타나지 않는 것을 검증하는 것을 의미합니다. 에이전트가 개별화되었다면 한 오후의 작업입니다. 그렇지 않다면 몇 주간의 고고학 프로젝트입니다.
관련 자료
- Kill Switch by Design: Agent Governance Architecture — 런타임 강제를 다루는 부모 글: 정체성 게이트 액세스, 툴별 서킷 브레이커, 테넌트 격리, 빠른 롤백, 제4의 강제 레이어로서의 게이트 액세스. 해체는 같은 격리 원칙의 영구 버전입니다.
- From Pilot to Production: The Five-Phase Agent Deployment Playbook — 이 글이 제6단계로 확장하는 배포 프로세스. 88%의 프로덕션 실패 프레임워크와 $340K의 평균 실패 비용은 배포 전에 거버넌스 — 폐기 준비를 포함 — 를 구축하기 위한 ROI 근거입니다.
- AI Agent Governance Checklist: a Pre-Deployment Review for Production Agents — 배포 전 검토. 이 글의 폐기 감사는 배포 후 대응물입니다. 같은 거버넌스 원칙, 라이프사이클의 반대쪽.
대표 빌드 비그네트
다중 통화 가격 책정을 처리하는 후속 에이전트로 교체한 후, NetSuite, BigCommerce, 3개의 공급업체 카탈로그를 RFQ 견적 에이전트로 실행하는 중견 산업 유통업체가 에이전트를 폐기해야 합니다. 에이전트는 14개월간 프로덕션에 있었습니다. NetSuite에 대한 OAuth 토큰, BigCommerce에 대한 API 키, 3개의 공급업체 포털에 대한 자격 증명을 보유하고 있습니다. 4시간 트리거로 실행되며 견적 큐에 기록합니다. 프로비저닝 시 에이전트가 개별화되었기 때문에 폐기에는 한 오후가 걸립니다. 정체성, 스코프, 예산, 트래픽이 모두 하나의 거버넌스 플레인에 존재하기 때문입니다. 6단계는 트랜잭션으로 실행됩니다 — 하나의 주체를 취소하고, 하나의 예산 규칙을 0으로 만들고, 하나의 레지스트리 항목을 리디렉트하고, 하나의 툼스톤 기록을 제출 — 키가 붙여넣어진 모든 장소를 찾기 위해 시스템 간 스캐빈저 헌트를 하는 것이 아닙니다. 후속 에이전트는 폐기된 에이전트의 공급업체 신뢰성 가드레일을 상속받아, 어떤 카탈로그 필드가 신뢰할 수 없는지 배운 6개월을 반복하지 않습니다. 검증 단계는 24시간 내 제로 잔여 트래픽을 확인합니다.
스코프된 빌드를 요청하세요.
1주일 발견. 시스템 인벤토리, 워크플로 맵, 고정 스코프를 받습니다 — 당사와 빌드하든 안 하든.
귀하의 시스템을 위해 이것을 구축하고 싶으신가요?
여기의 각 문서는 실제 프로덕션 작업에서 나왔습니다. 대상 시스템과 워크플로가 있다면, 1주 내에 빌드를 범위 정의할 수 있습니다.
범위 정의 빌드 요청1주 발견. 시스템 인벤토리, 워크플로 맵, 고정 범위를 받습니다 — 우리와 빌드할지 여부와 관계없이.