Cognition AI가 Windsurf를 인수하며 코딩 에이전트 경쟁이 격화되는 지금, 한 가지 조용한 위험이 프로덕션 현장에서 동시에 커지고 있다. AWS AgentCore의 '에이전트 결제 관리' 기능 프리뷰, MCP 기반 DB 에이전트의 보편화, A2A 프로토콜을 타고 연결되는 멀티에이전트 오케스트레이션—이 모든 흐름의 교차점에 동일한 질문이 걸려 있다. 에이전트가 외부 리소스를 직접 건드릴 때, 우리는 어디서 선을 그을 것인가?
"작은 질문"이 DB를 통째로 읽는 이유
dev.to에 올라온 실전 경고 하나가 간결하게 문제를 짚는다. "Show me customers at risk" — 무해해 보이는 이 한 줄이 MCP 기반 DB 에이전트 손에 들어가면, accounts·subscriptions·invoices·usage events·support tickets·activity logs를 전부 조인하는 쿼리로 번질 수 있다. 첫 번째 결과가 질문에 충분히 답하지 못하면, 에이전트는 리트라이한다. 리트라이는 또 다른 풀 스캔이다.
문제의 핵심은 에이전트가 의도적으로 위험한 쿼리를 날리는 게 아니라는 점이다. 에이전트는 그저 질문에 답하려 할 뿐이다. 그 과정에서 row limit이 없으면 전체 테이블을 읽고, 집계 없이 원시 데이터를 끌어오고, 페이지네이션 없이 결과를 반환한다. Row limit은 UI 선호 설정이 아니라 안전 경계(safety boundary)다. 프로덕션 MCP DB 서버라면 preview-first 원칙, 집계 우선, 페이지 커서, unbounded 요청에 대한 구조화된 거절, 스캔된 rows 수가 담긴 감사 로그가 기본값으로 박혀 있어야 한다.
결제 권한은 read/write와 같은 등급의 퍼미션이다
DB 스캔 문제가 "얼마나 읽었나"의 리스크라면, 에이전트 결제는 "얼마나 썼나"의 리스크다. AWS AgentCore가 에이전트의 외부 API·MCP 서버·타 에이전트 결제를 관리하는 기능을 예고한 지금, 비용 통제는 월말 재무팀 이슈가 아니라 런타임 안전 문제가 됐다.
지금까지 AI 비용 이야기는 주로 토큰 레이어였다. 어느 팀이 같은 800페이지 문서를 매일 아침 요약하고 있는가, 값싼 모델로 라우팅하고 있는가, 캐싱은 하고 있는가. 이 질문들은 여전히 유효하다. 하지만 에이전트 결제는 모델 호출 바깥에서 돈이 나간다. 에이전트는 태스크를 생각하면서 토큰을 쓰고, 태스크를 실행하면서 외부 API 비용을 만든다. dev.to의 분석이 정확히 짚듯, 무서운 건 한 번의 호출 비용이 아니라 루프의 비용이다.
프로덕션 장애를 디버깅하는 에이전트를 상상해보자. 유료 로그 분석 API를 호출하고, 유료 의존성 그래프 서비스를 쓰고, 프리미엄 트레이스를 끌어오고, 롤백 플랜 생성을 위해 외부 에이전트를 고용한다. 각 단계는 단독으로 보면 합리적이다. 그런데 이미 배포가 롤백된 이후에도 에이전트가 프리미엄 분석을 계속 구매하고 있다면? 에이전트는 실패를 매우 바쁘게 보이게 만든다. 막힌 워크플로우가 비싼 이유는, 어떤 가드레일이 멈추라고 할 때까지 그럴듯한 다음 액션을 계속 시도하기 때문이다.
"예산 설정"만으로는 부족한 이유
월별 예산 알림은 유용하지만 둔하다. 80%에서 경보가 울리는 AWS 예산 알림은 토요일 밤에 시작된 루프를 막지 못한다. 불이 이미 계획을 세운 뒤에야 방이 뜨거워졌다는 걸 알려줄 뿐이다.
에이전트 결제에는 워크플로우 레벨의 통제가 필요하다. 벤더 단위나 계정 단위가 아니라. 실전에서 써먹을 수 있는 규칙은 이런 형태다: 이 인시던트 에이전트는 인시던트당 X달러까지만 쓸 수 있다. 이 리서치 에이전트는 승인된 출처에서만 문서를 구매할 수 있다. 이 코드 마이그레이션 에이전트는 프라이빗 레포를 다룰 때 외부 서비스에 결제할 수 없다. 리트라이 지출이 성공적 진행보다 빠르게 늘어나면 워크플로우를 정지한다. 마지막 규칙이 특히 중요하다.
청구서에는 콜 그래프가 필요하다
일반 클라우드 청구서는 어느 서비스가 비용을 발생시켰는지 알려준다. 에이전트 결제에서 유용한 질문은 다르다. 어떤 에이전트가 워크플로우를 시작했는가, 인간의 원래 요청은 무엇이었는가, 에이전트는 무엇을 산다고 생각했는가, 어떤 정책이 그걸 허용했는가, 산 결과물이 실제로 쓰였는가, 워크플로우는 성공했는가.
이건 비용 가시성과 에이전트 가시성이 합쳐지는 지점이다. 청구서에 "에이전트가 700달러를 제3자 API에 썼다"고 나왔을 때, 엔지니어링 팀이 tool call로 가득 찬 트레이스만 들이밀 수는 없다. 지출을 의도·정책·결과에 연결하는 구조가 없으면, 유용한 자동화와 정중한 돈 낭비를 구별할 방법이 없다. 로그 속에 묻혀 있다면 거버넌스가 아니라 고고학이다.
프로덕션 투입 전 설계해야 할 경계선
당장 팀에서 에이전트 결제 기능을 켜기 전에 박아야 할 규칙들을 정리하면 이렇다.
DB 에이전트 경계선: - Row limit은 설정이 아니라 안전 경계—기본값을 낮게 잡고, 더 많이 보려면 명시적 승인을 요구 - 원시 rows 전에 집계 먼저, 전체 내보내기 전에 미리보기 먼저 - 스캔된 rows와 반환된 rows를 감사 로그에 기록 - 모델이 50개 미리보기 rows를 전체 DB를 본 것처럼 요약하지 못하게 구조적으로 차단
결제 에이전트 경계선: - 결제 가능한 에이전트는 반드시 명명된 예산·명명된 오너·명명된 비즈니스 목적을 가져야 함 - 지출을 에이전트 아이덴티티가 아니라 워크플로우에 묶을 것 ("리서치 에이전트가 40달러 썼다"가 아니라 "고객 X의 시장 조사 워크플로우가 승인된 데이터 소스 Y에 40달러 썼다") - 구매했지만 사용되지 않은 결과물을 가시화—에이전트가 뭔가를 사고 쓰지 않으면 그건 신호다 - 비용 이벤트를 API 호출이 아니라 ledger event처럼 처리—who, what, why, amount, vendor, workflow, approval, result가 구조화된 형태로 남아야 함
지금 이 설계를 미루면 생기는 일
Cognition-Windsurf 통합이 IDE 안에 자율 에이전트를 심고, Google의 Antigravity 2.0이 93개 에이전트를 동시에 오케스트레이션하고, A2A 프로토콜이 크로스 프레임워크 에이전트 협업을 표준화하는 지금—에이전트가 외부 리소스를 건드리는 범위는 앞으로 더 빠르게 넓어진다.
과거의 클라우드 청구서 폭탄은 큰 인스턴스를 켜둔 채 잊어버리는 것이었다. 새로운 폭탄은 아무도 모델링하지 않은 루프 안에서 에이전트가 천 번의 합리적인 결제 결정을 내리는 것이다. 이건 재무팀 문제가 아니다. 런타임 안전 설계 문제다. 그리고 에이전트를 프로덕션에 붙이기 전에, 그 선은 반드시 먼저 그어져 있어야 한다.