Claude Code를 팀에 도입하고 나서 처음 몇 주는 대개 비슷한 흐름으로 흘러간다. 생산성이 눈에 띄게 오르고, 팀원들이 흥분한다. 그리고 두 번째 달쯤 되면 두 가지 문제가 동시에 터진다. API 비용이 예상보다 훨씬 많이 나오고, AI가 짠 코드에서 이상한 버그가 보이기 시작한다. 이건 운이 나쁜 게 아니다. 비용 구조와 품질 검증 체계를 사전에 잡지 않은 채 속도만 올린 결과다.
비용부터: 90% 절감의 실제 원리
멀티에이전트 시스템이나 오케스트레이션 루프를 운영 중이라면, 프롬프트 캐시 TTL을 모르는 것 자체가 돈 낭비다. dev.to에 공개된 분석에 따르면 Anthropic의 프롬프트 캐시는 TTL이 5분(300초)이다. 2026년 3월 이전까지는 기본값이 1시간이었는데, 이 시점 이후 5분으로 대폭 단축됐다. 그 전에 캐싱 설정을 해둔 팀이라면 지금 이 순간도 엉뚱한 가정 위에서 비용을 태우고 있을 가능성이 높다.
핵심은 간단하다. 오케스트레이터 루프가 300초 안에 돌아오면 캐시된 입력 토큰 비용—약 10% 수준—만 낸다. 300초를 넘기면 매 이터레이션마다 전체 컨텍스트를 풀 비용으로 다시 처리한다. 270초라는 숫자가 나오는 이유는 처리 시간, 컨텍스트 조립, 서버 간 클럭 편차를 감안한 안전 버퍼다. 루프 하나당 하루 $0.50~$1.20 수준의 절감이지만, 병렬 에이전트 수가 늘어날수록 이 숫자는 선형이 아니라 복리로 불어난다.
실제 적용법은 세 가지다. 첫째, API 응답에서 cache_read_input_tokens를 로깅해 캐시가 실제로 히트되고 있는지 확인한다. 두 번째 호출에서 이 값이 0이면 캐시가 깨져 있거나 TTL 경계에 걸린 것이다. 둘째, 오케스트레이터 루프 인터벌을 270초로 고정한다. 60초로 잡고 싶은 충동이 생기는데—"충분히 반응적"이라는 이유로—Claude 에이전트가 리서치, 코드 작성, 테스트 실행에 수분이 걸린다는 걸 감안하면 60초 틱은 그냥 4.5배 더 비싼 오케스트레이터를 운영하는 것뿐이다. 셋째, 시스템 프롬프트에 정적 인스트럭션을 몰아두고 동적 상태는 별도 메시지 롤로 분리해 컨텍스트 변화를 최소화한다.
비용 가시성: 숫자가 보여야 통제할 수 있다
비용 최적화의 전제는 가시성이다. dev.to의 Claude Code 비용 추적 가이드에 따르면 엔터프라이즈 배포 기준 개발자 1인당 평균 $150~250/월이 실제 지출이고, 상위 10%는 하루 $12 이상을 소진한다. 그런데 구독 플랜 사용자는 Anthropic 콘솔에서 달러 단위 비용을 볼 수 없다. 로컬 ~/.claude/projects/에 쌓이는 JSONL 파일이 유일한 상세 데이터 소스다.
실무에서 바로 쓸 수 있는 도구는 ccusage(GitHub 4,800+ stars)다. 별도 설정 없이 npx ccusage로 일간·월간·세션별 비용 리포트를 뽑아준다. 캐시 토큰을 별도로 집계하고 5시간 빌링 윈도우 분석까지 된다. CI/CD에 자동화 에이전트를 올린다면 --max-budget-usd 플래그로 단일 커맨드의 최대 지출을 캡으로 묶어두는 것도 필수다. 런어웨이 에이전트 한 번에 팀 예산이 날아가는 사고를 막는 가장 단순한 안전장치다.
품질 쪽: AI 코드는 왜 다르게 테스트해야 하나
비용을 잡았다면 이제 품질이다. dev.to에 공개된 실제 사고 케이스가 이 문제를 잘 보여준다. Claude Code가 작성한 레이트 리미터 함수가 에러를 조용히 삼키고 항상 true를 반환했다. 코드 모양새는 멀쩡했고, TypeScript도 통과했고, 해피패스 테스트도 통과했다. 머지 후 일주일 뒤, 누군가 2분에 4,000 요청을 날렸을 때 비로소 드러났다. 아이러니하게도 Claude Code는 해당 코드에 "에러 핸들링은 플레이스홀더"라는 주석을 달아뒀다. 아무도 읽지 않은 것이다.
AI 코드의 위험은 코드를 못 짜는 게 아니다. 자신감 있어 보이는 코드를 일관되게 생성한다는 점이다. 주니어 개발자 코드를 보면 뇌에서 자동으로 경계 신호가 켜진다. AI 코드는 그 신호가 안 켜진다. 시니어 엔지니어가 짠 것처럼 보이기 때문에 스캔 속도가 빨라진다. 그런데 AI는 '플럭시블하게 그럴듯한' 구현을 몇 퍼센트 확률로 섞어낸다. 아젠틱 코딩 도구가 주당 수백 개의 함수를 생성하는 팀이라면, 그 몇 퍼센트는 무시할 수 없는 버그 밀도다.
적대적 테스트: AI의 사각지대를 겨냥하라
실질적인 대응 전략은 세 레이어다.
첫째, 정적 분석을 CI에 강제한다. TypeScript strict 모드에 noUncheckedIndexedAccess까지 켜두면 AI가 자주 실수하는 배열 인덱스 undefined 케이스를 컴파일 단계에서 잡는다. eslint-plugin-security는 AI가 종종 흘리는 보안 안티패턴을 린트한다. 이걸 pre-commit 훅과 CI 파이프라인에 묶어두면, 리뷰 전에 기계가 먼저 걸러준다.
둘째, 경계값 테스트를 구현 전에 먼저 작성한다. AI 코드는 해피패스와 명백한 엣지케이스는 잘 처리한다. 실패하는 건 시스템 특수 경계다. 유효 범위 최솟값과 최댓값, 그 바깥 한 스텝, 빈 값과 null, 스펙상 유효하지만 의미적으로 극단적인 입력—이 네 가지를 구현 코드를 보기 전에 테스트로 먼저 정의하면 구현이 아닌 계약을 테스트하게 된다.
셋째, 에러 전파를 명시적으로 검증한다. AI가 가장 자주 틀리는 패턴이 에러를 삼키고 기본값을 반환하는 것이다. 성공 케이스만 테스트하지 말고 실패 케이스의 계약을 검증해야 한다. 레이트 리미터라면 스토어가 다운됐을 때 false를 반환하는지(fail-closed), 아니면 무조건 통과시키는지(fail-open)를 테스트가 명시적으로 확인해야 한다.
팀에 당장 심을 수 있는 것들
이 두 축—비용과 품질—은 별개의 문제처럼 보이지만 사실 같은 뿌리다. AI 도구를 쓰는 속도가 검증하는 속도를 앞질렀을 때 둘 다 망가진다. 비용은 캐시 TTL을 모르면 조용히 불어나고, 품질은 AI 코드를 시니어 코드처럼 스캔하다 보면 조용히 깨진다.
내일 당장 할 수 있는 것 세 가지를 정리하면 이렇다. 첫째, 팀의 오케스트레이션 루프 인터벌을 확인하고 270초 이내인지 점검한다. cache_read_input_tokens 로깅이 없다면 지금 추가한다. 둘째, ccusage를 팀 CI에 연결해 일별 비용 리포트를 슬랙으로 뿌린다. 숫자가 보여야 팀이 행동한다. 셋째, AI가 작성한 함수에 대해 에러 전파 테스트를 필수 리뷰 항목으로 체크리스트에 넣는다. 코드 리뷰어가 "이 함수가 실패할 때 어떻게 되는가"를 묻는 습관이 생기는 것만으로도 레이트 리미터 류의 사고는 상당수 막을 수 있다.
앞으로의 방향
AI 코딩 도구의 사용량은 팀에서 계속 늘어날 것이다. 그 말은 비용과 품질 리스크도 함께 스케일된다는 뜻이다. 지금 구조를 잡지 않으면 나중에는 숫자가 커서 고치기 더 어렵다. 비용 최적화는 인프라 설계의 문제고, 품질 검증은 테스트 문화의 문제다. 둘 다 도구를 더 사주는 게 아니라 지금 있는 도구를 더 잘 쓰는 방식으로 해결된다. AI-First 워크플로우에서 속도는 이미 확보됐다. 이제 그 속도가 팀을 해치지 않도록 구조를 다지는 단계다.