AI 에이전트가 가상 네트워크, 데이터베이스 또는 로드 밸런서를 생성한다고 해서 작업이 끝나는 순간 문제가 사라지는 것은 아니다. 리소스가 계속 실행되면서 예산을 소모하고 유지보수를 필요로 할 수 있지만, 소유권 태그에는 해당 리소스에 연락하거나 책임을 물을 수 있는 사람이 아니라 deploy-agent 같은 자동화된 ID가 표시될 수 있다.
이 글은 이 문제를 클라우드 인프라의 거버넌스 공백으로 제시한다. 리소스를 생성한 실행 ID가 실제 소유자와 반드시 일치하는 것은 아니기 때문이다. 에이전트의 수와 생성 속도가 증가하면서 직원에 의존하는 기존 소유권 메커니즘은 충분하지 않게 된다.
에이전트가 소유한 리소스 탐지
첫 단계는 소유자 태그가 있는 리소스를 목록화한 다음, 해당 태그의 값을 조직의 ID 디렉터리와 비교하는 것이다. AWS와 Azure에서는 태그를 역할 또는 기본 서비스 엔터티의 기록과 대조할 수 있다. Google Cloud에서는 소유자 값이 직원 디렉터리에 존재하는지 확인할 것을 이 글은 제안한다. 검사에 사용되는 규칙에 따르면, 값이 직원 디렉터리에 없다면 인간 ID가 아니다.
자동화된 ID가 표시된다고 해서 해당 리소스가 부적법하다는 의미는 아니다. 자동화가 조직을 대신해 인프라를 운영하도록 설계되었을 수도 있기 때문이다. 그러나 이 검사를 통해 실제로 인간 소유자를 지정해야 하는 리소스로 검토 범위를 좁힐 수 있다.
실무적으로 무엇이 달라지는가?
배포 계획을 실행한 사람이나 계정을 자동으로 소유자로 받아들이는 대신, 승인 정책은 소유권 태그 자체를 확인해야 한다. 제안된 규칙은 태그를 지정할 수 있는 리소스에 소유자가 없거나, 소유자 값이 사람의 이메일 주소 형식이 아니거나, 알려진 에이전트 ID 중 하나와 일치하는 경우 어떤 배포도 통과시키지 않는 것이다.
이 글은 에이전트 ID 목록을 JSON 파일로 유지하고 이를 정책 엔진에 전달할 것을 권고한다. 목록이 없을 경우에는 검사 없이 배포를 허용하는 대신 정책이 폐쇄적으로 실패해야 한다. 또한 관리 권한을 가진 API 키의 사용을 경고하며, 각 에이전트에 별도 팀의 User 유형 키를 부여하고 해당 에이전트가 작업하는 환경에 대한 권한만 제한적으로 제공할 것을 제안한다. 공유 토큰은 피해야 한다.
환경의 수명 종료 시점 지정
배포 정책만으로는 에이전트가 이미 생성한 오래된 리소스를 처리할 수 없다. 따라서 이 글은 환경에 만료 기간을 설정할 것을 제안한다. 환경을 생성하고 수명을 지정하는 사람은 인간으로 두고, 에이전트는 그 환경 안에서 배포 작업을 수행하도록 하는 방식이다. 이렇게 하면 만료 경고가 조치를 취할 수 있는 인간에게 전달되며, 메일함이 없는 자동화된 ID로 보내지지 않는다.
이 글은 env zero가 환경 생성자에게 자동 삭제 전에 두 차례, 즉 이틀 전과 2시간 30분 전에 경고한다고 설명한다. 또한 Axiom에는 24시간 이내에 계정을 요청하지 않으면 계정을 자동으로 삭제하는 모델이 있다고 언급한다.
이 소식이 중요한 이유
이 글은 조직 내 에이전트 수가 증가하면서 문제가 확대되고 있다고 설명한다. Gravitee의 2026년 설문에 따르면, 기업 에이전트의 평균 수는 2025년 12월부터 2026년 4월 사이 4개월 동안 거의 두 배로 증가했으며, 조직의 3분의 1 이상이 100개가 넘는 에이전트를 운영하고 있었다. 또한 Larridin이 실시한 설문에서는 기업 환경에서 지정된 소유자가 없는 에이전트의 평균 수가 47개로 나타났다.
에이전트가 공유 서비스 계정을 사용할 경우 조사도 더 어려워진다. 로그를 통해 리소스가 생성된 사실은 입증할 수 있지만, 어떤 실행이나 요청 또는 결정이 그 결과로 이어졌는지는 설명할 수 없기 때문이다. 따라서 명시적인 인간 소유자를 지정하는 것은 비용 문제만 해결하는 것이 아니라 감사 기록의 책임성 공백도 일부 메운다.
해결되지 않은 제약도 분명하다. 이러한 통제가 성공하려면 ID 디렉터리가 정확해야 하고, 에이전트가 권한 정책을 우회하지 않아야 하며, 실제로 누가 리소스를 소유하는지에 대한 조직 차원의 정의가 일관되게 존재해야 한다. 또한 출처 자체가 env zero의 후원을 받은 가이드이므로, 제품 관련 권고는 시장의 유일한 표준이 아니라 제안된 해결책으로 보아야 한다.
뉴스 출처
The New Stack - Software Development
원문 보기 ↗