에이전트를 켜는 건 쉽다. 문제는 그 다음이다. Cursor와 Claude Code가 팀 표준 도구로 자리 잡으면서, '어떻게 돌리나'는 이미 해결된 질문이 됐다. 지금 현장에서 터지는 이슈는 세 가지로 수렴된다. 토큰이 얼마나 나가는지 세션 중에 알 수 없고, 에이전트가 규칙을 얼마나 지켰는지 PR이 올라와야 알고, 코드가 돌아가는 것처럼 보이는데 보안 구멍이 숨어 있다. 이 세 가지를 각각 다뤄온 글들이 최근 동시에 나왔다. 조합해보면 에이전트 통제 설계의 3축이 보인다.
1축: 비용 — 알림은 통제가 아니다
dev.to에서 LoopBudget 개발자가 쓴 글의 제목이 이걸 정확히 짚는다. "Alerts aren't controls." 클라우드 FinOps 세계에서 수년 전에 배운 교훈이 에이전트 세계에 그대로 반복되고 있다. 예산 알림이 뜨는 시점은 이미 돈이 나간 뒤다. 에이전트는 트래픽 기반 오토스케일과 달리 자연적인 상한선이 없다. 인텐트에 따라 무한정 쓴다.
LoopBudget이 제안하는 구조는 Soft Warn과 Hard Stop의 이단 구성이다. Soft Warn은 세션 지출이 소프트 캡을 넘으면 영수증과 알림을 발행하되 세션은 계속 둔다. Hard Stop은 하드 캡 초과 시 정책 결정, 알림, 세션 마킹까지 수행한다. 다만 솔직한 고백이 있다. 현재 Hard Stop은 벤더 레벨의 강제 종료가 아니다. Cursor와 Claude Code가 서드파티에 'kill this agent now' 프리미티브를 노출하지 않기 때문이다. 지금 할 수 있는 건 '다음 툴 콜을 차단'하는 구조를 목표로, 현재 툴 콜이 끝난 뒤 게이트를 거는 방식이다.
이 설계의 핵심은 '세션 영수증'이다. 팀 레벨 집계가 아니라 이 태스크, 이 세션 단위로 가시성을 확보하는 것. 에이전트 비용을 AI 라인 아이템으로 묶어 한 달 뒤 청구서에서 확인하는 방식으로는 팀이 의사결정을 할 수 없다. 비용 통제는 리얼타임 정책 엔진이 붙어야 비로소 통제가 된다.
2축: 규칙 — 실행 불가능한 규칙은 없는 것과 같다
Agents Playbook 개발자가 dev.to에 쓴 글에서 나온 통찰이 이걸 잘 요약한다. AGENTS.md를 아무리 정교하게 써도, CI가 강제하지 못하는 규칙은 기억에 의존한다. 에이전트든 사람이든 마찬가지다. 리뷰 단계가 규칙 위반을 '발견하는 첫 번째 장소'가 되면, 그건 거버넌스가 아니라 운이다.
핵심 전환은 이렇다. 정책 문서는 '설명'이고, CI 게이트가 '강제'다. 그리고 게이트를 설계할 때 중요한 기준 네 가지가 있다. 반복되는 실패인가, 기계적으로 감지 가능한가, 체크 비용이 낮은가, 실패 시 다음 행동이 명확한가. 이 네 조건을 만족하지 못하는 규칙은 자동화 대상이 아니라 리뷰 레이어에 두는 게 맞다. '올바른 추상화를 선택하라'는 룰을 CI로 강제하려는 시도는 프록시를 자동화하는 것일 뿐이다.
또 하나 실용적인 설계 포인트는 이스케이프 해치 예산이다. 절대 규칙은 결국 위선이 된다. 레거시 의존성, 마이그레이션 중간 상태 같은 합당한 예외가 항상 존재한다. Agents Playbook의 접근은 예외를 허용하되 이유를 코드 옆에 명시하고, 예외 수가 증가하면 CI가 실패하게 만든다. 보이지 않는 우회가 아니라 감지 가능한 예외로 만드는 것이다. 에이전트가 로컬에서 즉시 게이트를 실행할 수 있다면, 위반을 컨텍스트가 살아있는 시점에 수정할 수 있다. PR 사이클을 한 번 더 기다리는 것과 5초 안에 고치는 것은 워크플로우에서 완전히 다른 경험이다.
3축: 보안 — 에이전트는 '보이는 것'만 배웠다
SafeWeave 블로그와 dev.to에서 다뤄진 CWE-639 사례는 AI 생성 코드의 보안 취약점이 얼마나 구조적으로 발생하는지를 잘 보여준다. Cursor에게 인보이스 조회 엔드포인트를 만들어달라고 요청하면, 인증 미들웨어가 붙고 DB 조회가 붙고 JSON 응답이 나온다. 코드는 깔끔하다. 문제는 다른 사용자의 인보이스 ID를 URL에 넣으면 그 데이터가 그대로 나온다는 것이다.
이게 반복되는 이유가 명확하다. 에이전트는 튜토리얼에서 학습했고, 대부분의 튜토리얼은 '로그인한 사용자'까지는 보여줘도 '이 오브젝트가 이 사용자 것인지'는 보여주지 않는다. 인증(Authentication)은 키워드가 있다. authenticate 미들웨어, req.user 같은 명시적 코드가 존재한다. 인가(Authorization)의 소유권 체크는 쿼리의 형태 안에 숨어있다. 에이전트가 복사할 키워드가 없다.
수정은 한 줄이다. Invoice.findById(req.params.id) 대신 Invoice.findOne({ _id: req.params.id, userId: req.user.id })로 쿼리 자체가 소유권을 강제하게 만들면 된다. 하지만 진짜 문제는 이 패턴이 전체 코드베이스에 얼마나 퍼져있느냐다. 인보이스, 주문, 메시지, 업로드 파일, 프로필 설정—클라이언트에서 ID가 오는 모든 라우트가 후보다. SafeWeave는 이 패턴을 MCP 서버로 Cursor와 Claude Code에 연결해 파일을 넘어가기 전에 플래그를 세운다.
통제 설계 없이 에이전트 운영은 없다
세 축을 합치면 하나의 원칙이 된다. 에이전트가 만든 결과물은 의도한 대로 작동할 수 있지만, 비용이 얼마 나갔는지, 팀 규칙을 지켰는지, 보안 구멍이 없는지는 별도의 통제 레이어가 없으면 알 수 없다. 이 세 가지는 에이전트가 '잘' 작동하는 것과 독립된 문제다.
실행 순서를 제안한다면 이렇다. 먼저 가장 아픈 축부터 하나 잡아라. 비용이 불투명하면 세션 단위 가시성을 먼저 확보하고, CI에 걸리지 않는 규칙 위반이 반복되면 그 규칙 하나에 게이트를 붙이고, IDOR 같은 패턴이 코드베이스에 보이면 소유권 체크를 코드 리뷰 체크리스트의 첫 번째 항목으로 올려라. 세 축을 한 번에 설계하려는 시도는 거버넌스 롤아웃이 되어버린다. 아무도 이해하지 못하고 모두가 우회하는 체크 리스트가 생길 뿐이다.
에이전트 도입이 빨라질수록 통제 설계는 뒤처진다. 그 간극이 커지는 지점이 바로 팀이 에이전트를 불신하기 시작하는 지점이다. 통제 설계는 에이전트를 막는 것이 아니라, 믿고 계속 쓸 수 있는 조건을 만드는 작업이다.