코딩 에이전트를 켠 순간, 보이지 않는 청구서가 시작된다
AI 코딩 에이전트를 팀에 도입하면 첫 주는 마법 같습니다. PR 속도가 올라가고, 백로그가 줄고, 기획자까지 "오, 개발 빨라졌네요"라고 말합니다. 문제는 둘째 주부터입니다. dev.to에 올라온 한 시니어 개발자의 고백이 정확히 이 지점을 찌릅니다. 에이전트가 코드를 생성하는 동안 슬랙을 확인하고, 다른 파일을 리뷰하고, 돌아와서 AI 출력물을 평가하는 사이—컨텍스트 스위칭 세금이 누적됩니다. 그가 2주간 추적한 결과, 에이전트 없이 하루 평균 4회 × 45분의 딥 포커스 블록을 확보하던 것이, 에이전트 도입 후 7회 × 18분의 얕은 블록으로 쪼개졌습니다. 총 생산 시간은 비슷했지만, 사고의 질은 비교할 수 없을 만큼 떨어졌다는 겁니다.
토큰 비용? 진짜 비용의 10분의 1도 안 됩니다
API 청구서는 눈에 보이니까 누구나 관리합니다. 하루 $20~50, 최적화하면 줄일 수 있죠. 그런데 Claude Code 서브에이전트를 운영해 본 팀이라면 "보이지 않는 토큰 폭발"을 겪어봤을 겁니다. 또 다른 dev.to 기술 포스트에 따르면, Claude Code의 Task 도구로 서브프로세스를 생성할 때마다 ~/CLAUDE.md, 전체 플러그인 스킬, MCP 서버 도구 설명이 매 턴마다 재주입됩니다. 실측 결과 서브에이전트 1턴에 약 5만 토큰이 실제 작업 전에 소진됐고, 5턴이면 25만 토큰이 누적됐습니다. 이들은 작업 디렉터리 스코핑, .git/HEAD 경계 설정, 빈 플러그인 디렉터리 지정, --setting-sources 제한이라는 4레이어 격리 전략으로 10배 절감에 성공했습니다. 팀 차원에서 에이전트를 운영한다면, 이런 인프라 레벨 최적화는 선택이 아니라 필수입니다.
에이전트의 블라인드 스팟: '비효율'을 모른 채 구현을 완료한다
여기서 더 무서운 이야기가 나옵니다. 오픈소스 메모리 MCP를 유지보수하는 한 개발자가 HTTP 리랭커 어댑터를 구현하면서 발견한 사례입니다. 기존 코드는 리랭커가 점수 리스트를 반환하면 리포지토리에서 정렬을 처리하는 구조였는데, 새 HTTP 어댑터는 이미 정렬된 결과를 반환합니다. 그대로 두면 정렬을 두 번 하는 이중 비용이 발생하죠. 개발자는 이를 알아채고 리팩터링했습니다. 그런데 Claude Opus 4.6, Codex 5.3, Gemini Pro 3.0 세 모델 모두에게 동일한 구현을 맡겼더니, 세 모델 전부 이중 정렬 비효율을 감지하지 못하고 그대로 구현을 완료했습니다. 심지어 CLAUDE.md에 "기존 설계가 최적이라 가정하지 말고, 이상하면 사용자에게 먼저 물어보라"는 지침이 있었는데도 말입니다.
그래서 팀에 세워야 할 운영 규칙 4가지
AI 코딩 에이전트를 팀에 도입하면서 제가 실제로 적용하고 있는 규칙은 다음과 같습니다.
규칙 1: 생성 중 멀티태스킹 금지. 에이전트가 코드를 쓰는 동안 지켜보세요. 느려 보이지만, 컨텍스트를 유지하는 유일한 방법입니다. "에이전트 돌려놓고 슬랙 보는" 습관은 팀 전체의 사고 품질을 갉아먹습니다.
규칙 2: 주 1회 '수동 디버깅 데이'를 지정하라. AI 없이 버그를 잡는 날을 정해야 합니다. 한 달만 에이전트에게 디버깅을 맡기면, 정작 AI가 못 푸는 하드 버그 앞에서 자신이 느려진 걸 체감하게 됩니다. 디버깅은 코드베이스에 대한 멘탈 모델을 만드는 유일한 훈련입니다.
규칙 3: 시간 예산이 아닌 '토큰 예산'으로 관리하라. 일일 토큰 한도를 설정하고, 소진되면 수동 코딩으로 전환합니다. 특히 서브에이전트를 쓰는 팀이라면 4레이어 격리를 인프라 표준으로 잡아 토큰 낭비부터 차단해야 합니다. "Claude한테 물어보니까 서브프로세스 한 턴에 5만 토큰 날리고 있더라고요"—이런 걸 모르면 예산 관리 자체가 불가능합니다.
규칙 4: AI 출력물에 대한 '구조적 의심' 리뷰를 의무화하라. 세 개의 최상위 모델이 이중 정렬을 못 잡았다는 건, "AI가 구현 완료했다"가 "올바르게 구현했다"와 같지 않다는 뜻입니다. AI가 생성해준 걸 기반으로 우리가 다듬는 모델에서, '다듬기'의 핵심은 기능 동작 확인이 아니라 설계 의도와의 정합성 검증입니다.
AI-First는 'AI 올인'이 아닙니다
Vibe 코딩의 유혹은 강력합니다. 사이드 프로젝트 TaskGlitch에서 2년치 기능을 몇 달 만에 뽑아낸 한 개발자도 "스테이크가 낮을 때는 최고"라고 인정하면서, 결제·금융·보안 시스템에서는 "AI가 자신 있게 '완료'라고 말한 코드가 보안 재앙이었던 Moltbook 사례"를 경고합니다. METR의 무작위 대조 실험에서 경험 많은 오픈소스 개발자들이 AI 도구 사용 시 실제로는 19% 더 느렸지만, 본인은 20% 빨라졌다고 믿었다는 결과는 이 착각의 구조를 정확히 보여줍니다.
AI-First 팀 리빌딩이란 AI를 가장 많이 쓰는 팀을 만드는 게 아닙니다. 언제 쓰고 언제 내려놓을지 팀 전체가 아는 상태를 만드는 겁니다. 에이전트에게 위임할 범위를 명확히 하고, 위임하지 않을 영역을 지키는 규율이 있어야 속도와 깊이를 동시에 확보할 수 있습니다. 지금 당장 팀 위키에 위 네 가지 규칙을 올려놓고, 다음 스프린트부터 적용해 보세요. AI가 빨라진 만큼 우리가 약해지지 않도록.