AI Orphans: 주인 없는 에이전트를 찾아 책임자·권한·폐기 규칙으로 정리하는 5단계

에이전트가 늘수록 IT가 모르는 에이전트, 퇴사자가 남긴 에이전트가 생깁니다. 이런 AI orphans(주인 없는 에이전트)는 피하기 어렵습니다. 그러니 배포보다 정리 규칙을 먼저 세워야 합니다. 목록, 책임자, 권한 경계, 폐기 절차, 상시 감사 다섯 가지를 갖추면 에이전트를 넓게 풀어도 통제할 수 있습니다.

요약

InformationWeek의 Kelsey Ziser 선임 에디터가 에이전트 난립(agent sprawl)을 정리하는 방법을 CIO·CISO·AI 책임자 다섯 명에게 물었습니다. 응답자는 Geordie AI(에이전트 관리 회사)의 최고AI책임자 Hanah-Marie Darley, Fleet Device Management의 CIO Allen Houchins, RSA의 CISO Rob Hughes, Trua의 CEO Raj Ananthanpillai, ThreatLocker의 CEO Danny Jenkins입니다. 출발점은 IAM(identity and access management, 누가 무엇에 접근하는지 관리하는 체계)입니다. 사람 계정에 맞춰 만든 IAM에 에이전트가 들어오면서 기업은 이 체계를 다시 생각하고 있습니다. 기사는 정리 방법을 다섯 단계로 묶습니다. 에이전트를 목록화하고, lifecycle(배포부터 폐기까지의 주기)을 가치에 묶고, 에이전트마다 책임자를 두고, API·MCP 계층에서 권한을 통제하고, 감사 방식을 바꾸는 것입니다.

왜 다섯 단계가 모두 필요한지는 Darley가 든 고객 사례가 보여 줍니다. 이 고객은 AI 예산의 약 19%를 일정 자동화에 쓰고 있었습니다. 에이전트 하나하나는 제 일을 잘했지만, AI 투자의 5분의 1이 한 용도에 몰린 것을 놓고 보면 효율적이지 않았고 필요한 성과도 내지 못했습니다. 고객은 그 뒤 에이전트 lifecycle을 다시 짰습니다. 에이전트를 하나씩 점검해서는 이런 쏠림이 보이지 않습니다. 목록이 있어야 전체를 볼 수 있고, 책임자가 있어야 정리를 결정할 수 있습니다. 아래에서 여섯 가지 작동 원리와 두 사례를 보고, 실제로 돌릴 때 필요한 기술·현업 디테일을 붙입니다.

핵심 메커니즘

AI Orphans: IT 시야 밖에 남은 에이전트

AI orphan은 두 부류입니다. IT팀이 모르는 곳에서 돌아가는 에이전트, 그리고 퇴사자가 남기고 간 에이전트입니다. 직원이 떠나면 IT는 그 사람의 계정을 끕니다. 이때 그 사람이 만든 에이전트 계정도 끌지, 계속 관리할지 정해야 합니다. 경로는 퇴사만이 아닙니다. 벤더 소프트웨어에 딸려 들어온 에이전트도 IT가 지켜야 합니다. 한 사람이 아닌 서비스 계정에 묶인 에이전트는 권한을 누구 기준으로 줄지 흐려집니다. 큰 조직에서는 한 에이전트를 여러 사람이 여러 워크플로에서 함께 쓰므로, 쓰는 사람과 워크플로마다 권한이 달라야 합니다. 직원이 쓰던 Claude 에이전트를 버리고 다른 도구로 옮기면서 IT에 알리지 않으면, 옛 에이전트는 아무 규제 없이 잠든 채 남습니다.

Darley는 에이전트가 예전의 machine identity(서버·프로그램용 계정)와 다르다고 짚습니다. 예전 계정은 늘 같은 자원에 접근했지만, 에이전트는 훨씬 다양한 도구와 시스템에 그때그때 다르게 접근합니다. 한 번 정해 둔 권한표로는 따라가기 어렵다는 뜻입니다.

작은 예시(가상): 구매팀 과장이 공급사 견적 비교 에이전트를 만들어 쓰다가 다른 부서로 옮겼습니다. 인사 시스템에서는 부서만 바뀌었으므로 계정은 살아 있습니다. 에이전트는 여전히 구매 시스템 읽기 권한을 갖고 매일 밤 견적 메일함을 훑습니다. 결과를 보는 사람은 이제 아무도 없습니다.

Agent Inventory: 기기 속 MCP까지 목록에 넣는다

첫 단계는 보이게 만드는 일입니다. 사내에서 만든 에이전트와 외부 벤더의 에이전트를 모두 찾아야 하므로 개발팀과 보안팀이 함께 움직입니다. Darley는 대부분의 조직에 에이전트 운영 전체를 한눈에 보는 그림이 없다고 말합니다. 팀은 에이전트가 어디에 있는지, 활성 상태인지, identity(시스템이 에이전트를 구분하는 신원)가 어떻게 작동하는지, 폐기해야 하는지를 알아야 합니다. Houchins는 범위를 직원 기기까지 넓힙니다. 에이전트 지침 파일, 플러그인, MCP(Model Context Protocol, 에이전트가 외부 도구·데이터에 붙는 표준 연결 방식), 확장 프로그램, 로컬 AI 모델까지 봐야 한다는 것입니다. 보이지 않으면 통제할 수도, 사업 판단을 내릴 수도 없다는 것이 그의 설명입니다.

Value-tied Lifecycle: 성과가 끊기면 폐기 절차로 넘긴다

두 번째 단계는 에이전트의 일생을 가치에 묶는 일입니다. 배포하기 전에 이 에이전트가 낼 사업 성과와 측정 방법을 먼저 정합니다. 평가는 한 번으로 끝내지 않고 계속합니다. 성과를 내지 못하거나 유지비가 너무 커진 에이전트는 거의 실시간으로 표시돼야 재무·운영 피해를 줄일 수 있습니다. Darley는 에이전트가 결과로 평가받는 만큼 lifecycle 관리 전체를 가치에 묶어야 한다고 말합니다.

언제 폐기하거나 삭제할지도 정책으로 정해 둡니다. 폐기에는 두 가지 확인이 들어갑니다. 에이전트의 권한을 회수하는 것, 그리고 다른 에이전트와 더 이상 통신하지 않는지 확인하는 것입니다. Hughes는 다른 길도 제시합니다. 에이전트 뒤에 쌓인 지식이 그 자리에 올 후임에게 쓸모 있을 수 있으니 저장소에 보관해 두는 방법입니다. 어느 쪽을 고르든 에이전트의 접근 권한을 바꾸는 절차는 분명해야 합니다.

Named Owner: 모든 에이전트에 이름 있는 책임자

세 번째 단계는 책임입니다. 직원에게 관리자가 있듯 에이전트에게도 책임지는 사람이 있어야 합니다. Darley에 따르면 많은 고객이 에이전트마다 책임 소유자, 곧 사람 “parent user”를 지정합니다. Houchins는 이 원칙을 한 문장으로 말합니다. “You need to give every single agent a named owner.”

Trua의 Ananthanpillai는 한 걸음 더 나갑니다. 직원이 생체 정보와 정부 발급 신분증으로 검증을 받으면 trust token(검증된 사람임을 증명하는 토큰)을 받습니다. 이 토큰으로 온라인 거래 같은 일을 하는 에이전트를 검증된 사람에 묶습니다. 그는 이를 미국 교통안전청이 승객을 미리 심사해 검증 번호를 주는 TSA PreCheck에 빗댑니다. 회사 안의 모든 에이전트를 개인에게 묶어야 한다는 것이 그의 주장입니다.

API·MCP Layer Control: 권한은 연결 지점에서 묶는다

네 번째 단계는 에이전트가 어떤 데이터와 시스템에 접근하는지 통제하는 일입니다. 통제는 API나 MCP 계층에 겁니다. 에이전트는 결국 이 연결 지점을 거쳐 데이터에 닿기 때문입니다. Hughes가 든 사례가 이유를 보여 줍니다. 한 에이전트의 ID가 API에 연결되면서 조직 데이터 전체에 제한 없이 접근할 수 있게 됐습니다. 원래 설계는 그 에이전트를 만든 소유자의 접근 범위만 갖는 것이었습니다.

ThreatLocker의 Jenkins는 권한을 여러 층에서 분명히 정하라고 말합니다. 파일 권한, 애플리케이션, ring-fencing(애플리케이션이 닿을 수 있는 파일·네트워크·다른 프로그램을 울타리로 제한하는 방식), AI 통제 수준입니다. 그리고 에이전트가 실제로 행동할 때도 그 권한이 그대로 이어지는지 확인해야 합니다. 규모도 문제입니다. Darley의 큰 고객 가운데는 에이전트가 수천 개인 곳이 있어 하나씩 손으로 검토할 수 없습니다. 그는 관리 속도를 올리려면 독립된 AI 시스템이 필요하다고 봅니다.

Agentic Audit: 개별과 전체를 상시 본다

다섯 번째 단계는 감사 방식을 바꾸는 일입니다. Hughes는 서비스 계정에 하던 연간·분기 점검으로는 모자라다고 말합니다. 에이전트가 정해 둔 범위 안에서 움직이는지 계속 검토해야 합니다. 평가는 두 층으로 합니다. 에이전트 하나하나를 보고, 에이전트 전체도 묶어서 봅니다. 앞의 19% 사례가 두 번째 층이 왜 필요한지 보여 줍니다. Darley는 마지막으로, 누구나 언젠가는 고아 에이전트를 갖게 된다고 말합니다. 배포에만 매달리지 말고 lifecycle을 어떻게 관리할지 미리 계획하라는 뜻입니다.

통념과 다른 주장

저자가 든 사례

Geordie AI 고객: 일정 자동화에 AI 예산 약 19%

상황	한 일	결과	연결
일정 자동화 에이전트 여럿이 각자 잘 돌아감	전체 AI 예산 대비 비중을 확인	약 19%가 한 용도에 몰려 비효율, 필요한 성과 미달. lifecycle을 다시 설계. 에이전트 수와 절감액은 원문에서 밝히지 않음	Value-tied Lifecycle, Agentic Audit(전체 평가)

RSA CISO가 본 과다 권한 에이전트

상황	한 일	결과	연결
만든 사람의 접근 범위만 갖도록 의도한 에이전트	에이전트 ID가 API에 연결됨	조직 데이터 전체에 제한 없이 접근. 회사명과 발견 경위는 원문에서 밝히지 않음	API·MCP Layer Control, Named Owner

기술 디테일: 인벤토리, 레지스트리, 게이트웨이, 감사를 실제로 돌리려면

아래는 기사에 없는 구현 방법을 새로 작성한 것입니다. 필드명, 경로, 숫자는 시작값으로 삼을 가상 예시입니다.

Agent Inventory를 자동으로 채우려면 세 곳에서 모아 한 목록으로 합칩니다. 첫째, IdP(사내 로그인 시스템)와 API 게이트웨이 로그에서 사람이 아닌 호출 주체를 뽑습니다. 둘째, MDM(기기 관리 도구) 스크립트로 직원 기기를 훑어 에이전트 지침 파일, MCP 설정 파일, 브라우저 확장, 로컬 모델 실행기를 찾습니다. 셋째, 구매·보안 검토 기록에서 에이전트 기능이 붙은 벤더 제품을 뽑습니다. 세 결과를 agent_id로 합치고 중복을 지웁니다. 스캔은 주 1회로 시작하고, 새 MCP 서버가 처음 보이면 그날 바로 알림을 띄웁니다.

레지스트리 레코드는 고아 판정에 필요한 필드를 필수로 둡니다. 소유자, 성과 지표, 연결된 MCP 서버, 통신하는 다른 에이전트가 빠지면 등록을 받지 않습니다.

{
  "agent_id": "agt-proc-quote-0217",
  "origin": "internal | vendor | personal_device",
  "identity_type": "user_delegated | service_account",
  "owner": {"user_id": "u-20431", "backup_user_id": "u-31877"},
  "users": ["u-20431", "u-40922"],
  "business_outcome": "견적 비교 리드타임 단축",
  "kpi": {"name": "quote_cycle_hours", "baseline": 48, "target": 24},
  "monthly_cost_usd": 310,
  "use_case_category": "procurement.quote_compare",
  "mcp_servers": ["erp-read", "mail-read"],
  "data_scopes": ["purchasing:read"],
  "peer_agents": ["agt-proc-po-0033"],
  "last_active": "2026-11-13",
  "status": "active | flagged | retired | archived",
  "next_review": "2026-12-01"
}

고아 판정 규칙은 레지스트리를 HR·IdP와 매일 대조해 돌립니다. owner가 퇴사·휴직·부서 이동 상태면 orphan으로 표시하고 backup_user에게 넘깁니다. backup도 없으면 14일 안에 새 소유자가 나서지 않을 때 정지합니다. last_active가 30일을 넘으면 dormant입니다. data_scopes가 owner 권한보다 넓으면 over-privileged로 바로 막습니다. RSA 사례 같은 과다 권한은 이 마지막 규칙으로 잡습니다. 판정 결과는 소유자에게 “유지 / 이관 / 폐기 / 보관” 중 하나를 고르는 요청으로 보냅니다.

API·MCP 계층 통제는 에이전트가 도구를 부를 때 반드시 지나가는 게이트웨이 한 곳에 겁니다. 게이트웨이는 호출마다 세 가지를 확인합니다. 이 에이전트의 허용 도구 목록에 있는 도구인가, 요청한 데이터 범위가 owner 권한과 현재 사용자 권한 둘 다의 안쪽인가, 상태가 active인가. 여러 사람이 함께 쓰는 에이전트는 서비스 계정 대신 사용자 위임 토큰을 써서, 쓰는 사람마다 권한이 달라지게 합니다. 모든 호출은 agent_id, user_id, tool, scope, 결과 코드로 남깁니다. 이 로그가 상시 감사의 원재료가 됩니다.

폐기 절차는 체크리스트로 자동화합니다. (1) API 키와 토큰 폐기, (2) 게이트웨이 허용 목록에서 제거, (3) peer_agents 쪽 연결 해제, (4) 7일 동안 호출 0건 확인, (5) 지침·프롬프트·설정을 저장소에 보관하고 status를 archived로 바꿈. 4번에서 호출이 남아 있으면 그 호출 주체를 찾아 목록에 올립니다. 보관본은 후임이 다시 쓸 수 있게 use_case_category로 찾을 수 있게 둡니다.

상시 감사는 개별과 전체 두 층으로 돌립니다. 개별 층에서는 게이트웨이 로그를 하루 단위로 묶어 처음 보는 도구 호출, 처음 보는 데이터 범위, 호출량이 지난 4주 평균의 3배를 넘는 경우를 경고합니다. 전체 층에서는 월 1회 use_case_category별로 monthly_cost_usd를 합칩니다. 한 범주가 AI 예산의 10%를 넘으면 그 범주의 에이전트를 함께 검토합니다. 19% 사례 같은 쏠림을 잡는 장치입니다. use_case_category는 사람이 고르게 하되, 비어 있으면 LLM이 지침 파일을 읽고 정해진 범주 목록 안에서 JSON으로 고르게 합니다. 같은 입력으로 3회 돌려 2회 이상 같은 답이 나올 때만 채택하고, 나머지는 소유자에게 묻습니다.

실패하기 쉬운 곳과 대응

실패	증상	대응
기기 스캔 누락	개인 기기·비관리 기기의 로컬 모델이 빠짐	게이트웨이를 거치지 않는 사내 데이터 호출을 차단해 우회로를 닫음
서비스 계정 잔존	퇴사 후에도 에이전트가 계속 돎	신규 에이전트는 사용자 위임만 허용, 기존 것은 소유자 지정 후 전환
범주 쏠림 미탐지	개별 지표는 정상인데 비용만 큼	월간 범주별 비용 합계와 범주별 성과 지표를 같은 표에 둠
폐기 후 통신 잔존	다른 에이전트가 폐기된 에이전트를 계속 부름	폐기 전 peer_agents 확인, 7일 호출 0건을 폐기 완료 조건으로 둠

현업 실행 디테일: 누가, 언제, 무엇을

아래 역할, 일정, 판정 기준은 기사 내용을 바탕으로 새로 짠 가상 예시입니다.

역할	맡는 일	산출물
CIO·AX 추진	범위와 정책 확정, 월간 포트폴리오 점검 주재	에이전트 관리 정책 1장, 범주별 비용·성과표
CISO·IAM 팀	기기 스캔, 레지스트리, MCP 게이트웨이 운영	인벤토리, 고아 판정 리포트
개발팀	사내 에이전트 등록, 위임 토큰 전환	레지스트리 레코드, 전환 목록
현업 소유자	성과 지표 정의, 존치·폐기 결정	에이전트별 KPI, 월간 확인 기록
인사	퇴사·이동 이벤트를 레지스트리에 연동	퇴사 체크리스트에 에이전트 항목 추가
재무	AI 비용을 에이전트·범주별로 집계	월간 비용 집계

시작 전 준비물은 다섯 가지입니다. 현재 승인된 AI 도구와 벤더 목록, IdP의 비사람 계정 목록, MDM으로 스크립트를 돌릴 수 있는 기기 범위, 최근 6개월 퇴사·이동자 명단, AI 관련 비용이 찍히는 계정과목 목록입니다.

6주 일정 예시는 이렇습니다. 1주차에 CIO가 범위(사내·벤더·개인 기기)와 정책 초안을 정하고, CISO가 스캔 방식을 설계합니다. 2~3주차에 첫 인벤토리를 만들고, 소유자에게 “내 에이전트가 맞는지” 확인을 받으며, 인사가 퇴사 체크리스트에 에이전트 항목을 넣습니다. 4~5주차에 MCP 게이트웨이를 사내 데이터 연결 두세 곳에 먼저 걸고, 소유자는 에이전트마다 성과 지표 하나를 적습니다. 6주차에 재무가 범주별 비용을 집계하고, 첫 포트폴리오 점검에서 존치와 폐기를 정합니다.

소유자 확인 질문

• 이 에이전트가 멈추면 누가 가장 먼저 알아챕니까?
• 이 에이전트가 낸 성과를 어떤 숫자 하나로 보겠습니까?
• 이 에이전트는 당신이 못 보는 데이터를 볼 수 있습니까?
• 이 에이전트를 부르는 다른 에이전트가 있습니까?
• 당신이 자리를 옮기면 누가 이어받습니까?
• 같은 일을 하는 에이전트가 사내에 또 있습니까?

진행 판정 기준(예시): 소유자 없는 에이전트가 0건이 되기 전에는 새 에이전트 배포 승인을 늘리지 않습니다. over-privileged 판정은 발견 당일 차단을 원칙으로 합니다. 성과 지표가 없는 에이전트는 다음 점검까지 지표를 못 적으면 폐기 후보로 올립니다. 한 범주가 AI 예산의 10%를 넘으면 그 범주를 다음 달 점검 안건에 올립니다.

어디에 먼저 쓸까. 직원이 개인 기기에서 에이전트와 MCP 연결을 직접 만들기 시작한 회사라면 인벤토리와 퇴사 연동부터 시작하는 편이 가장 싸게 먹힙니다. 고아는 퇴사·이동 시점에 생기는데, 이 연결은 인사 체크리스트에 한 줄을 더하는 것만으로 걸 수 있기 때문입니다. 다음 순서는 MCP 게이트웨이입니다. 권한 사고는 연결 지점에서 막아야 비용이 작습니다. 포트폴리오 점검은 마지막에 붙이지만 경영진에게는 가장 설득력이 큽니다. “에이전트가 몇 개냐”보다 “AI 예산이 어느 용도에 몰려 있고 거기서 무엇을 얻었냐”를 보여 줄 수 있기 때문입니다. 현업 스폰서는 비용을 집계하는 재무와 퇴사를 처리하는 인사를 함께 세우는 것이 좋습니다.

원문 사례

항목	내용
원문	InformationWeek, Kelsey Ziser(선임 에디터), 2026년 11월 12일
응답자	Hanah-Marie Darley(Geordie AI 최고AI책임자), Allen Houchins(Fleet Device Management CIO), Rob Hughes(RSA CISO), Raj Ananthanpillai(Trua CEO), Danny Jenkins(ThreatLocker CEO)
AI orphan 정의	IT 시야 밖에서 도는 에이전트, 퇴사자가 남긴 에이전트
복잡하게 만드는 요인	벤더 에이전트, 서비스 계정, 다중 사용자·워크플로, 휴면 에이전트, 바뀌는 접근 방식
다섯 단계	목록화, lifecycle 설계, 책임자 지정, 통제와 거버넌스, 에이전트 감사
인벤토리 범위	지침 파일, 플러그인, MCP, 확장 프로그램, 로컬 AI 모델
폐기	권한 회수, 다른 에이전트와의 통신 차단 확인, 또는 저장소 보관
책임	named owner·parent user, trust token(생체·신분증 검증, TSA PreCheck 비유)
통제	API·MCP 계층, 파일·앱·ring-fencing·AI 통제 수준 권한
규모	일부 고객은 에이전트 수천 개, 독립 AI 시스템으로 관리
수치	AI 예산 약 19%를 일정 자동화에 쓴 고객 1곳

핵심 개념

agent sprawl

에이전트가 부서·개인 단위로 통제 없이 늘어나 전체를 아무도 모르는 상태.

parent user

에이전트의 행동과 결과에 책임지는 사람 소유자. 에이전트마다 한 명을 이름으로 지정합니다.

service account

특정 사람이 아닌 시스템·프로그램용 계정. 여기에 에이전트를 묶으면 퇴사해도 남고 권한 기준이 흐려집니다.

machine identity

서버·애플리케이션 같은 기계에 주는 신원. 예전에는 같은 자원에만 접근해 관리가 비교적 단순했습니다.

trust token

생체·신분증 검증을 거친 사람임을 증명하는 토큰. 에이전트를 검증된 개인에 묶는 데 씁니다.

ring-fencing

애플리케이션이 접근할 수 있는 파일·네트워크·다른 프로그램을 미리 정한 울타리 안으로 제한하는 통제.

내 메모

TODO: 내 생각 추가

원문은 InformationWeek의 「Stop the sprawl: 5 steps to wrangling AI orphans」(Kelsey Ziser, 2026년 11월 12일)입니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 기사에 실린 응답자들의 발언을 AX Review가 다시 정리했습니다. 작은 예시, 기술 디테일(수집 경로, 레지스트리 JSON, 고아 판정 규칙, 게이트웨이 확인 항목, 폐기 체크리스트, 감사 임계값), 현업 실행 디테일, 인포그래픽과 표는 실제로 돌릴 때 필요한 내용을 새로 작성한 것이며 숫자는 가상 예시입니다. 전체 내용은 원문에서 볼 수 있습니다.