코딩 에이전트를 팀에 도입할 때 가장 먼저 받는 질문은 "어떤 모델이 제일 좋아요?"다. 현실에서 이 질문은 첫 청구서가 날아오는 순간 "왜 이렇게 비싸요?"로 바뀐다. 그리고 청구서 문제를 해결하고 나면, 이번엔 PR에 섞여 들어온 버그가 조용히 프로덕션으로 올라간다. 버그를 막는 리뷰 체계를 갖추고 나면, 에이전트가 아무도 요청하지 않은 리팩터링을 혼자 결정하고 있다는 걸 발견한다. 비용, 품질, 거버넌스—이 세 축은 순서대로 해결하는 문제가 아니라 처음부터 동시에 설계해야 하는 구조다.
출력 토큰이 청구서를 지배한다
dev.to에 공개된 모델별 코딩 에이전트 비용 분석은 실무자라면 반드시 읽어야 할 데이터를 담고 있다. 동일한 워크로드(월 입력 9천만 토큰 + 출력 2천5백만 토큰, 개발자 1인 기준)를 15개 모델에 적용했을 때 월 비용은 $19에서 $1,200까지 63배 차이가 난다. 핵심은 이 격차의 대부분이 출력 토큰 단가에서 비롯된다는 점이다. DeepSeek-V4-Flash는 출력 토큰 1M당 $0.28, Claude Sonnet 5는 $15—54배 차이다. 코딩 에이전트는 파일 전체를 읽고, 긴 diff를 생성하고, 여러 번 재시도한다. 입력 대비 출력 비중이 일반 챗봇보다 훨씬 높다. 챗봇 벤치마크에서 입력 가중치로 비교한 가격표를 그대로 믿으면 실제 청구서에서 배신당한다.
한 가지 더 짚고 넘어가야 할 것: 저렴한 모델이 저렴한 작업 단가를 보장하지 않는다. 약한 모델이 같은 태스크를 다섯 번 재시도하면, 한 번에 끝내는 프론티어 모델보다 토큰을 더 소비할 수 있다. 가격은 의사결정의 출발점이지 결론이 아니다. 내 팀의 실제 재시도율, 컨텍스트 크기, 프롬프트 캐싱 활용 여부를 측정하기 전까지는 어떤 모델도 "우리 팀에 최적"이라고 단정할 수 없다.
AI 코드 리뷰에서 '잘 읽힌다'는 신호가 오히려 위험하다
코딩 에이전트가 만든 코드를 리뷰할 때 가장 큰 함정은 코드가 유창하다는 점이다. dev.to의 AI 생성 코드 리뷰 체크리스트 아티클은 이 문제를 정면으로 다룬다. 사람이 쓴 코드는 작성자가 헤맨 지점에 흔적이 남는다—어색한 구조, "잘 모르겠음" 주석. 리뷰어는 그 흔적을 단서 삼아 주의를 집중한다. AI 코드에는 그 흔적이 없다. 잘못된 함수도 올바른 함수와 똑같이 매끄럽게 읽힌다. 리뷰어의 본능—깔끔한 곳은 빠르게, 지저분한 곳은 천천히—이 AI 코드 앞에서는 정반대로 작동한다.
체크리스트가 제시하는 우선순위는 발생 빈도가 아니라 오류 비용 순이다. 첫째는 할루시네이션된 API와 시그니처다. 존재하지 않는 메서드를 자신 있게 세 번 호출하는 코드는 읽어서는 잡을 수 없다—타입 체커와 컴파일러를 돌려야 잡힌다. "읽었는데 괜찮아 보였다"는 "확인하지 않았다"와 같다. 둘째는 도메인 불변식 누락이다. 멀티테넌트 필터, 소프트 삭제 조건, 권한 범위—이것들은 공개 학습 데이터에 없다. 에이전트는 스키마를 완벽하게 읽고도 테넌트 ID 필터를 빠뜨린다. 두 쿼리 모두 타입 체크를 통과하고, 데모 환경에서는 동일하게 동작하며, 프로덕션에서 조용히 데이터를 유출한다. 셋째는 보안 기본값이다. 에이전트는 공개 튜토리얼에서 배웠고, 공개 튜토리얼의 상당수는 안전하지 않다.
에이전트에게 메모리를 더 주는 게 아니라 거버넌스를 설계해야 한다
코딩 에이전트 워크플로우를 운영하다 보면 자연스럽게 MEMORY.md, project-rules.md, lessons-learned.md 파일이 늘어난다. 그런데 dev.to의 agent-loop 아티클이 지적하는 문제는 정확히 이것이다: 컨텍스트가 많아질수록 좋아지는 게 아니라, 올바른 컨텍스트와 잘못된 컨텍스트가 뒤섞인 쓰레기 더미가 된다. 트랜스크립트는 메모리가 아니고, 메모가 규칙이 아니며, 발견은 가이던스가 아니다.
voku/agent-loop가 제안하는 구조는 명확하다: 세션 상태(임시), 발견 증거(검토 대상), 승인된 가이던스(내구성 있는 지식)를 분리한다. 에이전트는 티켓을 읽고 알아서 시작하는 게 아니라, 목표·허용 범위·비목표·영향 파일·검증 명령을 담은 명시적 작업 브리프로 시작한다. 계획이 바뀌면 이전 버전은 폐기되고 새 버전이 다시 승인을 받는다. 검증은 구현 이후에 발명되는 게 아니라 구현 전에 선언된다. 에이전트가 "완료"라고 말하는 것은 증거가 아니다—선언된 검증 명령이 통과해야 완료다.
이 구조가 관료적으로 느껴질 수 있다. 그런데 아무도 요청하지 않은 리팩터링을 에이전트가 혼자 완료한 PR을 머지하고 나서 롤백하는 비용을 한 번이라도 경험하면 생각이 바뀐다. 승인은 태스크 ID에 영구적으로 부여되는 게 아니라 구체적인 계획 버전에 적용되어야 한다—태스크의 의미가 조용히 바뀌기 때문이다.
트리아드를 설계하지 않으면 하나씩 무너진다
비용·품질·거버넌스 중 하나만 설계한 팀이 겪는 패턴은 예측 가능하다. 비용만 최적화하면 품질 사고가 난다. 리뷰 체크리스트만 강화하면 에이전트가 범위를 벗어난 작업을 계속 생성한다. 거버넌스 루프만 만들면 모델 선택과 코드 품질이 비용을 초과하는 수준으로 올라간다.
실무적 시사점은 세 가지다. 첫째, 모델 선택 전에 팀의 실제 토큰 사용 패턴을 측정하라—입력 대비 출력 비율, 재시도율, 프롬프트 캐싱 적용 가능성. 둘째, AI 생성 코드 리뷰를 위한 체크리스트를 별도로 만들되, 발생 빈도가 아닌 오류 비용 순으로 우선순위를 잡아라—도메인 불변식과 보안 기본값은 가장 조용하게 가장 비싸게 터진다. 셋째, 에이전트에게 맥락을 더 주기 전에 임시 상태·검토 대상 발견·승인된 가이던스를 구분하는 레이어를 설계하라.
코딩 에이전트는 팀의 속도를 실제로 높인다. 하지만 그 속도가 올바른 방향으로 향하게 하는 건 도구가 아니라 구조다. 비용을 모르면 예산이 잘리고, 품질 체계가 없으면 프로덕션이 무너지고, 거버넌스가 없으면 에이전트가 팀의 결정을 대신 내린다. 세 축을 동시에 설계하지 않은 에이전트 도입은 결국 더 빠른 속도로 더 큰 사고를 향해 달리는 것과 같다.