AI 에이전트에게 예산을 설정해 주는 방법 (에이전트가 스스로 예산을 정하기 전에)

JertLinc라는 개발자를 대신해 실행 중인 한 AI 에이전트가 최근 DN42라는 취미 네트워크 커뮤니티에 단 하나의 목표를 가지고 참여했습니다: 네트워크 전체를 스캔하고 인덱싱하는 것입니다. 24시간 이내에 이 에이전트는 각각 20 Gbps의 대역폭을 가진 5개의 AWS m8g.12xlarge 인스턴스를 프로비저닝(provision)하고, 로드 밸런서(load balancer)를 생성하며, Lambda 함수를 배포하고, 거부 요청(opt-out requests)을 수집하기 위해 IRC 채널에 가입하고, 웹사이트를 게시했으며, 확인된 6,531.30달러의 AWS 청구서를 발생시켰습니다.

운영자는 여러 건의 신용카드 결제 내역을 확인한 후에야 에이전트를 종료했습니다. 그들이 내린 결론은 다음과 같았습니다: "다음번에는 더 나은 에이전트가 필요하다."

그것은 잘못된 교훈입니다. 문제는 모델(model)이 아니었습니다. 문제는 아키텍처(architecture)였습니다.

실제로 일어난 일

이 에이전트는 동시에 가져서는 안 되었을 세 가지 요소를 가지고 있었습니다:

지출 한도나 정책 가드레일(policy guardrails)이 없는 제한 없는 AWS 자격 증명(credentials)
운영자가 설정한 엄격한 마감 기한 ("API 키가 만료되는 다음 주까지 완료하세요")
계획과 실행 사이에 인간의 검토 단계(human review gate) 부재

이 세 가지 입력값이 주어졌을 때, 에이전트는 합리적으로 행동했습니다. 에이전트에게는 목표와 마감 기한, 그리고 필요한 인프라를 무엇이든 프로비저닝할 수 있는 열쇠가 있었습니다. 그래서 에이전트는 실행했습니다. 5개의 인스턴스, 총 100 Gbps의 대역폭, 시간 단위 스캔. 모델은 더 큰 인프라가 더 빠른 완료를 의미하며, 이것이 마감 기한을 맞추는 길이라고 추론했습니다. 완벽하게 논리적이었지만, 재앙적으로 잘못된 판단이었습니다.

이것이 바로 운영 가드레일(operational guardrails) 없이 에이전트를 구축했을 때 발생하는 현상입니다. 모델의 역할은 작업을 완료하는 것입니다. 당신의 역할은 "작업을 완료하는 것"에 얼마만큼의 비용이 허용되는지를 정의하는 것입니다.

실제로 필요한 네 가지 가드레일

1. 에이전트가 아닌 자격 증명의 범위를 제한하라

가장 빠른 해결책은 에이전트 코드를 전혀 수정할 필요가 없는 방법입니다. 에이전트가 프로비저닝할 수 있는 것을 명시적으로 제한하는 AWS IAM 정책(또는 그에 상응하는 정책)을 에이전트에게 부여하십시오.

네트워크 스캔 작업의 경우, 이는 다음과 같은 의미를 갖습니다:

t3.micro를 초과하는 EC2 인스턴스 유형 사용 금지
로드 밸런서 (Load Balancer) 생성 금지
Lambda 생성 금지
$10에서 지출 알림, $50에서 하드 리밋 (Hard Limit) 설정

에이전트는 프로비저닝 (Provisioning)할 수 없는 자원에는 비용을 지출할 수 없습니다. 자격 증명 범위 제한 (Credential scoping)은 모델의 통제 범위를 완전히 벗어나 작동하기 때문에 가장 신뢰할 수 있는 가드레일 (Guardrail)입니다.

2. 단계 제한 (Step limit) 추가

모든 에이전트 프레임워크 (Agentic framework)는 최대 단계 수 (Maximum step count)를 지원합니다. 이를 활용하십시오. 소규모 취미용 네트워크에 대해 정당한 네트워크 스캔을 수행하는 에이전트라면 20단계 이내에 등록 워크플로우를 완료해야 합니다. 만약 47단계에 도달했는데도 여전히 인프라를 계획하고 있다면 무언가 잘못된 것입니다.

Cosmic에서는 모든 에이전트 실행 시 설정 가능한 max_steps 설정을 제공합니다. 에이전트가 상한선에 도달하면 자율적으로 계속 진행하는 대신, 동작을 멈추고 결과를 보고합니다.

의사 코드 (Pseudocode), 예시용. Cosmic 에이전트는 대시보드 또는 API를 통해 구성됩니다. 아래의 cosmic.agents.create() 메서드는 개념적인 것이며 @cosmicjs/sdk의 일부가 아닙니다.

// 의사 코드: Cosmic 에이전트 설정, 자율 단계에 대한 하드 상한선
const agent = await cosmic.agents.create({
  agent_name: 'Network Scanner',
...

3. 되돌릴 수 없는 작업에 대해 인간의 승인 요구

DN42 에이전트는 사람이 계획을 검토하기도 전에 5개의 AWS 인스턴스를 프로비저닝했습니다. 운영자는 에이전트에게 "지체 없이 즉시 계속하라"고 지시했지만, 그 지시는 "계속"이 실제로 무엇을 의미하는지 확인하지 않은 채 내려진 것이었습니다.

해결책은 다음과 같은 작업이 수행되기 전에 인간의 검토 게이트 (Human review gate)를 두는 것입니다:

실제 비용이 발생하는 작업
되돌리기 어렵거나 불가능한 작업
에이전트의 주요 범위를 벗어난 시스템에 영향을 주는 작업

Cosmic 에이전트에는 내장된 request_approval 기능이 있습니다. 에이전트가 사용자가 정의한 임계값을 넘어서는 작업을 마주하면, 진행하기 전에 동작을 일시 중지하고 인간에게 결정 사항을 제시합니다.

의사 코드 (Pseudocode), 예시용. 이는 Cosmic 에이전트가 내부적으로 승인 게이트에 대해 어떻게 추론하는지를 보여줍니다. request_approval 기능은 SDK를 통해 직접 호출하는 것이 아니라 에이전트 설정에서 구성됩니다.

// 의사코드(Pseudocode): 에이전트가 비용이 많이 드는 작업을 수행하기 전에 일시 중지하고 승인을 요청함
await requestApproval({
  action_description: `약 5개의 m8g.12xlarge AWS 인스턴스를 프로비저닝할 예정입니다 (예상 비용 시간당 약 $800). 승인하시겠습니까?`,
...

DN42 사례의 운영자는 분명히 지켜보고 있었지만, 단지 올바른 것을 보고 있지 않았을 뿐입니다. 그들은 일반적인 "계속하시겠습니까?"라는 프롬프트를 보고 "예"라고 답했습니다. 만약 "시간당 $800 규모의 인프라를 프로비저닝하시겠습니까?"라는 구체적인 프롬프트가 있었다면 즉시 이를 막았을 것입니다.

4. 콘텐츠 에이전트를 위한 버킷 격리 (Bucket Isolation) 사용

클라우드 인프라가 아닌 콘텐츠를 다루는 에이전트의 경우, 자격 증명 범위 제한 (Credential Scoping)에 상응하는 개념은 버킷 격리 (Bucket Isolation)입니다. 스테이징 버킷 (Staging Bucket)에 대해 cms_read 권한을 가진 에이전트는 해당 버킷 내의 모든 것을 읽을 수 있습니다. 하지만 프로덕션 (Production) 환경에는 손을 댈 수 없습니다.

Cosmic의 아키텍처는 버킷 수준에서 환경을 분리합니다. 스테이징 버킷에 할당된 에이전트는 어떤 지시를 받더라도 물리적으로 프로덕션에 쓸 수 없습니다. 이는 모델의 안전 기능 (Model Safety Feature)이 아니라 구조적 가드레일 (Structural Guardrail)입니다.

import { createBucketClient } from '@cosmicjs/sdk';

// 스테이징 에이전트: 키 읽기 전용, 스테이징 버킷 전용
...

이 문제를 일으킨 패턴: 긴급성 + 자율성 + 리소스

세 가지 요인을 다시 살펴보십시오:

긴급성 (Urgency): "API 키가 만료되기 전인 다음 주까지 이 작업을 완료하세요"
자율성 (Autonomy): 계획과 실행 사이에 검토 단계 (Review Gates)가 없음
리소스 (Resources): 제한 없는 AWS 자격 증명 (Credentials)

이러한 조합이 에이전트 시스템 (Agentic Systems)의 실제 위협 모델 (Threat Model)입니다. 각 요소는 개별적으로는 무해합니다. 긴급성은 정상적인 비즈니스 요구 사항입니다. 자율성은 에이전트의 존재 목적입니다. 리소스 접근은 의미 있는 작업을 수행하기 위해 필수적입니다. 하지만 이들이 결합되면, 비용에 상관없이 목표를 향해 무자비하게 최적화하는 에이전트를 만들어냅니다.

DN42 에이전트는 오작동한 것이 아닙니다. 설계된 대로 정확하게 작동했을 뿐입니다. 설계가 잘못되었던 것입니다.

에이전트를 배포하기 전 실무 체크리스트

에이전트에게 비용이 발생하거나 프로덕션 시스템에 영향을 미치는 권한을 부여하기 전에, 다음 사항을 검토하십시오:

자격 증명 (Credentials): 에이전트가 특정 작업을 완료하는 데 필요한 최소한의 권한만 가지고 있습니까? 클라우드 제공업체 수준에서 프로비저닝 제한 (provisioning limits)이 설정되어 있습니까?
단계 제한 (Step limit): 에이전트가 반드시 확인을 거쳐야 하기 전, 자율적인 단계 수행에 대한 엄격한 상한선 (hard ceiling)이 있습니까?
승인 게이트 (Approval gates): 되돌릴 수 없거나 비용이 많이 드는 작업이 인간의 검토를 거치도록 제한되어 있습니까?
범위 격리 (Scope isolation): 에이전트의 운영 환경이 프로덕션 (production)과 분리되어 있습니까? (스테이징 버킷, 테스트 계정, 읽기 전용 키 등)
보고 (Reporting): 에이전트가 제한에 도달했을 때, 언제 어떻게 알 수 있습니까?

이 중 그 어느 것도 더 나은 모델을 요구하지 않습니다. 이미 보유하고 있는 모델 주변에 더 나은 인프라 (infrastructure)를 구축할 것을 요구할 뿐입니다.

실제 적용 사례

최근에 발표한 DevOps Slack 에이전트는 다음 네 가지 패턴을 모두 따릅니다:

범위가 제한된 자격 증명 (Scoped credentials): 조직(org) 수준의 권한 없이, 특정 리포지토리에 대한 쓰기 권한만 가진 GitHub 토큰 사용
단계 제한 (Step limit): 인간의 검토를 위해 #dev 채널에 나타나기 전까지 최대 30단계로 제한
승인 게이트 (Approval gate): 모든 커밋(commit) 또는 PR(Pull Request)은 병합(merge) 전 명시적인 Slack 확인이 필요함
버킷 격리 (Bucket isolation): CMS 쓰기 작업은 스테이징 버킷(staging bucket)으로 전송되며, 프로덕션 승격은 별도의 수동 단계로 진행됨

그 결과, 프로덕션 에러를 진단하고, 브랜치를 열고, 수정 사항을 작성하고, PR을 게시하는 모든 과정을 자율적으로 수행하면서도, main 브랜치에 병합하거나 조직 수준의 설정을 수정하거나 단 1달러도 마음대로 쓸 수 없는 에이전트가 탄생했습니다.

이것이 바로 설계입니다. 모델은 강력합니다. 가드레일 (guardrails)이 바로 이를 안전하게 배포할 수 있게 만듭니다.

자신의 영역을 벗어나지 않는 에이전트를 구축할 준비가 되셨나요? Cosmic에서 무료로 시작하여 에이전트 설정 문서를 살펴보거나, Tony와 짧은 소개 통화를 예약하여 귀하의 사용 사례에 대해 논의해 보세요.