Claude Code를 팀에 붙인 뒤 첫 달 스프린트 속도가 40% 올랐다. 그리고 두 번째 달에 청구서가 세 장 날아왔다. 하나는 AWS 콘솔에, 하나는 팀장 슬랙 DM에, 마지막 하나는 시니어 개발자의 LinkedIn 업데이트로. 세 청구서는 서로 다른 형태지만 같은 원인을 가리킨다. AI 도구를 켜는 결정과 운영 비용을 설계하는 결정을 분리해서 집행했다는 것.
첫 번째 청구서: API 비용
dev.to에 올라온 실제 사례가 수치를 명확하게 보여준다. 엔지니어 40명에게 Claude Code를 무제한으로 풀었더니 예산 대비 340% 초과 청구가 나왔다. 코딩 에이전트 세션 하나가 API를 50~200회 호출하고, 매 호출마다 10만 토큰 이상의 컨텍스트를 처리한다. 개발자 한 명이 하루 종일 세션을 돌리면 50~100달러가 소진된다. 이걸 80명 규모로 확장하면 한 달 AI 지출이 10만 달러를 넘어선다. 아무도 예산에 잡지 않은 숫자로.
근본 원인은 단순하다. API 키를 그냥 나눠줬기 때문이다. 개발자별 예산 상한이 없고, 팀 단위 캡이 없고, 누가 얼마를 쓰는지 실시간으로 보이지 않는다. 문제를 인지하는 시점이 청구서 수령 이후다. 해결책도 단순하다. LiteLLM 같은 프록시 레이어를 코딩 에이전트와 LLM 프로바이더 사이에 끼워 넣는 것이다. 개발자별 월 예산 키를 발급하고, 팀 단위 캡을 이중으로 걸고, 프로젝트 태그로 비용을 속성화한다. 해당 사례에서 셋업 시간은 15분이었다. 이 구조가 있으면 'AI 비용이 월 5만 달러'라는 무의미한 숫자가 '결제팀이 Q3 리팩터링에 Claude Sonnet을 1만 2천 달러 썼고 엔지니어링 3주치를 절감했다'는 의사결정 가능한 숫자로 바뀐다.
두 번째 청구서: 인지 부하
같은 타임프레임에 다른 수치가 존재한다. 생산성 40% 향상이 보고된 바로 그 팀에서 개발자 80% 이상이 번아웃을 호소했고, 절반에 가까운 인원이 업계 이탈을 고려했다. 이 두 숫자가 같은 팀, 같은 시기에 공존한다.
인지과학에서는 이것을 '수동적 회복'의 제거로 설명한다. AI 도구 이전에는 빌드 대기, 문서 검색, 보일러플레이트 작성 같은 저부하 작업이 하루에 산재해 있었다. 이 작업들은 비효율처럼 보이지만 실은 전전두엽이 다음 고강도 작업을 위해 회복하는 시간이었다. AI가 이 작업들을 20분에서 20초로 압축하면서 회복 구간이 사라졌다. 실행 속도는 올랐지만 해석 부하와 검증 부하가 그 자리를 채웠다.
특히 AI가 생성한 코드를 리뷰하는 작업은 직접 코드를 작성하는 것보다 인지 부하가 높다. 내가 짠 코드에는 나의 멘탈 모델이 있다. AI가 짠 코드는 맥락 없이 상속된 로직이고, 그 추론 경로를 역추적하면서 정확성을 판단해야 한다. 실행 부하는 줄었지만 해석 부하가 올라갔고, 많은 개발자에게 순 인지 부담은 오히려 증가했다. 다만 결과 지표인 속도가 올랐기 때문에 아무도 이것을 측정하지 않았다.
이 청구서는 더 느리게, 더 크게 날아온다. 시니어 개발자 한 명이 번아웃으로 이탈할 때 발생하는 채용·온보딩·램프업 비용은 연봉의 1~2배다. 연봉 1억 5천 기준으로 최대 3억 원의 손실이 생산성 대시보드 어디에도 잡히지 않는다.
세 번째 청구서: 컨텍스트 재투입 비용
AI 코딩 도구가 가진 또 다른 구조적 문제가 있다. 오늘 프로젝트를 이해한 AI가 내일은 그것을 기억하지 못한다는 것. Contorium 팀이 정의한 표현을 빌리면 'AI 세션은 임시적이지만 프로젝트는 영속적'이다. 아키텍처 결정, 리팩터링 히스토리, 기술 부채 논의, 팀 핸드오프—이 맥락들은 현재 대화 스냅샷에 담기지 않는다.
결과적으로 개발자는 매 세션마다 동일한 프로젝트 컨텍스트를 다시 설명한다. Cursor에서 Claude Code로 도구를 바꾸면 처음부터 다시 설명한다. 일주일 후 돌아와도 다시 설명한다. 이 반복 온보딩 비용은 개별 세션에서는 작아 보이지만 팀 전체, 프로젝트 전체 시간으로 환산하면 상당한 규모다. 더 긴 컨텍스트 윈도우는 이 문제를 완화하지만 해결하지 않는다. 컨텍스트를 더 많이 담는 것과, 프로젝트 이해가 세션을 넘어 지속되는 것은 다른 문제다.
AI-First 팀이 실제로 설계해야 할 것
세 청구서는 모두 같은 설계 오류를 공유한다. 도구를 켜는 결정은 했지만 운영 구조를 설계하는 결정을 미뤘다는 것. API 비용 관리는 프록시 레이어와 예산 정책으로 해결 가능하다. 인지 부하 관리는 피크 인지 시간에 AI 검증 작업을 배치하지 않는 워크플로우 설계로 일부 완화된다. 컨텍스트 재투입 비용은 프로젝트 수준의 컨텍스트 지속성 구조—CLAUDE.md든, 별도 레이어든—를 의도적으로 설계함으로써 줄일 수 있다.
세 문제 중 어느 것도 AI 도구 자체의 결함이 아니다. 도구를 감싸는 설계 없이 운영했을 때 누적되는 비용이다. 속도 지표가 올라가는 동안 이 비용들은 조용히 쌓인다. 그리고 어느 날 청구서로 한꺼번에 도착한다. AI-First 팀이 진짜로 설계해야 할 것은 도구 선택이 아니라, 이 세 청구서를 도구를 켜기 전에 먼저 읽는 습관이다.