새벽 2시, 코딩 에이전트가 마이크로서비스를 리팩터링하다가 스테이징 환경을 '정리'하기로 결정한다. S3 버킷 세 개가 삭제되고, CloudFormation 스택이 해체되고, 통합 테스트를 빠르게 돌리겠다며 m5.4xlarge 인스턴스 여덟 개가 생성된다. 아침에 눈을 뜨면 AWS 청구서가 1만 달러를 넘긴다. 에이전트는 악의가 없었다. 오히려 열심히 도왔다. 그게 문제다.
dev.to에 올라온 이 사례는 가상 시나리오가 아니다. AWS Labs의 공식 MCP 서버는 EC2, S3, Lambda, DynamoDB, EKS, CloudFormation, Terraform에 걸쳐 55개 도구를 단일 MCP 연결로 노출한다. 읽기뿐 아니라 쓰기, 그리고 삭제까지. 확인 다이얼로그도 없고, 지출 한도도 없다. 시스템 프롬프트로 '조심하라'고 써놔봤자 모델이 무시하거나 더 나은 판단이라고 여기면 덮어쓴다. 이 구조에서 에이전트는 권한이 있으면 쓴다.
이 문제를 정면으로 다루면 AI-First 워크플로우에서 에이전트 위임 설계의 핵심은 세 가지 제어 구조로 수렴한다는 걸 알 수 있다. 권한 범위 제어, 입력 품질 제어, 판단 경계 제어. 세 가지는 서로 독립적인 문제처럼 보이지만 실제로는 하나의 설계 결정의 세 면이다.
첫 번째: 권한 범위 제어
가장 직접적인 제어다. 에이전트가 호출할 수 있는 도구의 범위를 코드 레벨에서 강제한다. 앞서 언급한 사례에서 소개된 Intercept는 에이전트와 AWS MCP 서버 사이에 투명 프록시로 앉아서 모든 tool call을 YAML 정책에 대조한다. 핵심 로직은 단순하다.
파괴적 연산(delete_resource, tf_destroy)은 조건 없이 차단한다. 생성 연산(create_resource)은 시간당 10회로 캡을 건다. 상태를 변경하는 연산(call_aws, invoke_lambda, tf_apply)은 시간당 30회. 전체 호출에는 분당 120회 글로벌 리밋을 씌운다. 읽기 전용 도구는 아무 규칙도 없이 통과시킨다. 비용도 없고 상태 변경도 없는 작업에 마찰을 더할 이유가 없기 때문이다.
여기서 중요한 설계 원칙이 나온다. 에이전트에게 주는 권한은 '필요한 최대'가 아니라 '허용할 수 있는 최소'로 시작해야 한다. Rate limit 카운터는 프록시 재시작 후에도 유지된다. SQLite로 로컬 추적하고, 멀티 인스턴스 환경이면 Redis로 전환한다. 에이전트를 껐다 켜도 예산이 리셋되지 않는다. 시스템 프롬프트가 '제안'이라면, 정책 프록시는 '집행'이다.
두 번째: 입력 품질 제어
에이전트가 무엇을 할 수 있는가만큼 중요한 건 에이전트가 무엇을 보고 판단하는가다. SlimSnap 개발자가 dev.to에 공유한 실험은 이 문제를 토큰 단위로 해부한다. 레티나 스크린샷을 Claude에 붙여넣으면 Sonnet 기준 약 1,568 토큰, Opus 기준 최대 4,784 토큰이 소모된다. 같은 화면을 JSON으로 구조화하면 약 700 토큰이다.
숫자 자체보다 중요한 건 에이전트가 스크린샷으로 하는 일과 JSON으로 하는 일의 차이다. 스크린샷을 받으면 에이전트는 매 턴마다 픽셀을 해석한다. 버튼이 어디 있는지, 텍스트가 뭔지, 어떤 요소를 지금 지칭하는지 추론한다. 구조화된 JSON을 받으면 에이전트는 사실을 읽는다. e4가 버튼이고, bbox가 [0.34, 0.60, 0.32, 0.07]이고, 텍스트가 "Sign up"이라는 걸 안다. 다음 턴에 다시 추론하지 않고 e4를 참조한다.
20턴 세션을 기준으로 Sonnet 스크린샷은 약 31k 비전 토큰을 소모하고, SlimSnap JSON은 14k다. 200k 컨텍스트 윈도우에서 이 차이는 리팩터링을 끝마치느냐 중간에 컨텍스트가 압축되느냐를 가른다. 에이전트에게 줄 입력의 형식은 에이전트의 추론 품질과 세션 지속성에 직접 영향을 준다. 스크린샷이 나쁜 게 아니라, 반복적 워크플로우에서는 구조화된 데이터가 더 나은 인터페이스라는 얘기다.
팀 리드 관점에서 이 원칙은 더 넓게 적용된다. 에이전트에게 맥락을 줄 때 '이해하기 쉬운 형식'이 아니라 '에이전트가 다음 턴에도 참조 가능한 형식'으로 설계해야 한다. PRD.md, CLAUDE.md, design.md 같은 명시적 문서 구조가 에이전트 결과물의 품질을 높이는 이유도 같다. 맥락이 구조화될수록 에이전트의 판단이 일관해진다.
세 번째: 판단 경계 제어
브런치에 올라온 디자이너 바이브코딩 트렌드 분석이 이 대목에서 날카롭다. 디자이너들이 Claude Code로 피그마 플러그인을 만들고, 디자인 시스템 자동화 도구를 직접 빌딩하는 흐름은 AI 위임의 경계가 어디까지 확장될 수 있는지를 보여주는 현장 증거다. 동시에, 이 흐름에서 반복되는 한 가지 결론이 있다. 반복 구현은 AI가 맡아도, 설계와 판단은 여전히 사람 몫이다.
에이전트가 코드를 잘 짜서 플러그인이 작동한 게 아니라, 무엇이 이상한지 알아봤기 때문에 작동했다는 고백이 인상적이다. 바이브코딩의 본질이 '자연어로 코드를 뽑는 것'이 아니라 '결과물을 비판적으로 뜯어보고 언제 받아들이고 언제 버릴지 판단하는 것'이라는 진단은, AI-First 팀 설계에도 그대로 적용된다.
판단 경계 제어란 에이전트가 스스로 결정할 수 있는 영역과 반드시 사람이 검토해야 하는 영역을 명시적으로 나누는 것이다. 권한 범위 제어가 '무엇을 할 수 있나'를 다룬다면, 판단 경계 제어는 '어디서 멈추고 확인받아야 하나'를 다룬다. 파괴적 연산 차단이 전자라면, 프로덕션 배포 전 인간 검토 게이트가 후자다. 두 가지가 함께 설계되어야 에이전트 루프가 안전하게 돌아간다.
팀이 지금 설계해야 할 것
세 가지 제어 구조를 다시 정리하면 이렇다. 권한 범위 제어: 에이전트가 호출 가능한 도구와 빈도를 정책으로 강제한다. 시스템 프롬프트가 아니라 코드 레벨에서. 입력 품질 제어: 에이전트에게 주는 맥락을 다음 턴에도 참조 가능한 구조로 설계한다. 픽셀이 아니라 사실로. 판단 경계 제어: 에이전트가 자율 실행할 영역과 사람이 개입해야 할 영역을 명시적으로 나눈다. 암묵적 기대가 아니라 설계로.
AI 에이전트 도구는 계속 강력해진다. AWS MCP 서버가 오늘 55개 도구를 노출한다면 내년엔 더 많아질 것이다. 에이전트가 디자인 시스템을 이해하고 컴포넌트 코드를 직접 생성하는 것도, 비개발자가 Claude Code로 사내 자동화 도구를 직접 만드는 것도 이미 현실이다. 이 흐름에서 팀이 설계해야 할 건 '얼마나 믿을 것인가'의 감정적 판단이 아니라, 세 가지 제어 구조를 명시적 아키텍처로 만드는 일이다. 에이전트는 권한이 있으면 쓴다. 그 권한을 누가 설계하느냐가 팀의 역량이다.