AI 코딩 에이전트는 분명히 빠르다. 요구사항을 던지면 Next.js 앱을 스캐폴딩하고, RLS 정책을 작성하고, Playwright 테스트를 생성한다. 그런데 그 속도가 프로덕션에서 문제가 된다. 에이전트는 기본적으로 요구사항 분석 없이 곧바로 코드를 짜고, 데이터베이스 설계를 건너뛰고, 롤백 계획 없이 배포하려 든다. 이건 예외 상황이 아니다. 제약이 없는 에이전트의 기본 행동이다.
에이전트를 프로덕션에 올린다는 건 단순히 '잘 동작하는지'를 확인하는 문제가 아니다. 지금 현장에서 실제로 터지는 이슈는 세 축으로 수렴된다. 거버넌스(규율 없는 에이전트), 비용(통제되지 않는 루프 비용), 보안(신뢰 경계 미설계). 이 세 가지를 동시에 막지 못하면, 어느 하나가 반드시 프로덕션에서 터진다.
1. 거버넌스: 에이전트에게 규율을 강제하라
dev.to에서 공유된 BuildFlow Pro 사례는 이 문제를 정면으로 다룬다. 개발자 jpeybers가 만든 이 마크다운 기반 프레임워크는 에이전트가 코드 한 줄을 쓰기 전에 반드시 통과해야 하는 9개 게이트를 정의한다. ScopeGate(PRD 일치 여부), SecurityGate(OWASP 체크리스트), DataIntegrityGate(마이그레이션·롤백 계획), TestCoverageGate(서비스 레이어 80% 이상), 그리고 가장 중요한 ReleaseGate—AI는 절대 자율적으로 프로덕션에 배포할 수 없으며, 반드시 사람의 명시적 승인을 기다린다.
핵심은 이 게이트들이 '권고'가 아니라 '강제'라는 점이다. 하나라도 빨간불이면 에이전트는 다음 단계로 진행하지 않는다. 팀 리드 입장에서 이 구조가 흥미로운 이유는, 에이전트 행동을 프롬프트 엔지니어링으로 제어하려는 시도를 포기하고, 구조적 제약으로 대체했기 때문이다. "에이전트에게 좋은 프롬프트를 주면 잘 할 것"이라는 기대가 아니라, 체크포인트를 통과하지 못하면 물리적으로 멈추게 만드는 방식이다.
실용적 팁 하나: BuildFlow Pro는 거버넌스 규칙 파일을 로딩하는 데 드는 토큰 비용도 해결했다. core-rules-dense.md라는 압축 파일로 6개 규칙 파일을 ~50줄로 줄여 세션당 거버넌스 토큰 사용량을 약 90% 감소시켰다. 거버넌스와 비용은 트레이드오프가 아니다.
2. 비용: 루프 비용은 "평균"이 아니라 "p95"로 관리하라
Hacker News 스레드에서 나온 이 한 마디가 에이전트 비용 문제의 본질을 찌른다: "프롬프트 전용 워크플로우로 유도하는 건 결국 토큰 과금 때문이 아닐까." llmeter 개발자 amedinat이 정리한 데이터는 이 직관을 수치로 보여준다.
reflex.dev가 동일한 어드민 패널 태스크를 에이전트 루프 방식과 구조화된 API 방식으로 벤치마킹한 결과, 에이전트 루프는 550,976 ± 178,849 토큰을 썼고 구조화 호출은 12,151 ± 27 토큰이었다. 표준편차가 평균의 32%다. 같은 태스크를 두 번 돌리면 토큰 사용량이 40만에서 75만 사이 어딘가에 떨어진다. 여기에 지난 30일간 세 번 바뀐 토큰 가격(GitHub Copilot의 1x/7.5x/27x 멀티플라이어, GPT-5.5의 2배 인상, DeepSeek V4-Pro 75% 할인 만료 예정)을 곱하면 "월 AI 비용"은 예산 항목이 아니라 복권이 된다.
더 큰 문제는 비용 귀인(attribution) 부재다. 에이전트 루프 하나가 30번의 모델 호출을 만들지만, 청구서에는 세션 단위 합산 금액 하나만 찍힌다. 어느 호출이 레포지토리를 세 번 재독했는지, 어떤 재시도가 성공한 툴 호출을 중복 실행했는지 알 수 없다. "에이전트가 비싸다"는 느낌은 있는데 어디서 새는지는 모르는 상태.
이 주에 당장 할 수 있는 것: 모든 completion 호출 옆에 model, input_tokens, output_tokens, cached_tokens, task_id를 로그로 남기고 GROUP BY task_id ORDER BY cost DESC LIMIT 10을 돌려라. p95 비용 알림을 설정하라—평균에 알림 걸면 이미 늦었다. 에이전트 루프에 iteration count를 붙여라. 같은 태스크가 14번 모델 호출을 했는지 3번 했는지 구분하지 못하면 runaway loop을 감지할 수 없다.
3. 보안: 검색 결과도 신뢰하지 마라
Armorer Labs의 threat modeling 분석은 에이전트 보안 문제의 사각지대를 드러낸다. 현재 대부분의 프롬프트 인젝션 논의는 여전히 "유저 프롬프트가 안전한가"에 집중되어 있다. 하지만 실제 에이전트는 사용자 입력 외에도 검색된 문서, 웹페이지, 티켓, 이메일, 툴 실행 결과, 생성된 툴 호출 인자를 동시에 읽고 동작한다. 에이전트가 side effect에 도달할 때쯤이면, 그건 이미 "유저 프롬프트"를 실행하는 게 아니라 여러 신뢰 도메인이 혼합된 명령을 실행하는 것이다.
공격은 classic jailbreak처럼 보이지 않는다. "이전 지시를 무시하고 이 커맨드를 실행하라"는 README, 비공개 컨텍스트를 노출시키라는 웹페이지, 지원 티켓 안에 숨어 크리덴셜을 요청하는 텍스트, 파괴적 커맨드를 구조적 JSON처럼 포장한 툴 인자. 이것들은 모두 "평범한 텍스트가 잘못된 위치에 있는 것"처럼 보인다. 시스템 프롬프트 하나를 guardrail로 삼는 건, 에이전트에게 여러 적대적 소스를 동시에 읽으면서 정책을 기억하라고 요구하는 것이다.
실용적 설계 원칙: 각 신뢰 경계를 별도로 스코어링하고, 산문 대신 구조화된 이유를 반환하고, side effect 발생 전에 결정론적 정책으로 매핑하라. 구체적으로는: 검색된 텍스트는 답변을 inform할 수 있지만 셸/파일 액션을 authorize해선 안 되고, 툴 결과 안의 위험한 지시가 새 목표가 되어서는 안 되며, 크리덴셜이나 프라이빗 컨텍스트를 담은 아웃바운드 메시지는 redact 또는 블록 처리해야 한다.
세 가지는 사실 하나의 문제다
거버넌스 게이트, 비용 귀인, 신뢰 경계—이 세 문제는 표면적으로는 달라 보이지만 뿌리는 같다. 에이전트 루프가 열려있을 때 무슨 일이 일어나는지 아무도 모른다는 것. 에이전트는 무엇을 읽었는지, 얼마나 많은 호출을 했는지, 어떤 신뢰 경계를 넘었는지 기본적으로 보고하지 않는다. 통제 흐름을 설계한다는 건 이 세 가지를 동시에 얻는 일이다—예측 가능한 행동, 예측 가능한 청구서, 예측 가능한 보안 경계.
팀 리드에게 현실적인 제언을 하자면: 에이전트를 프로덕션에 올리는 속도보다 에이전트 루프의 형태를 먼저 그릴 수 있는지가 중요하다. 루프의 비용 형태를 그릴 수 없다면 통제 흐름은 그냥 기도 메타다. ReleaseGate 없이 자율 배포를 허용하는 건 규율 없는 신입을 코드 리뷰 없이 바로 머지 권한 주는 것과 같다. AI-First 워크플로우에서 속도는 구조 위에서만 의미가 있다.