Claude Code를 한 달 써본 사람들의 후기는 대개 두 가지로 갈린다. "생산성이 폭발했다"거나, "생각보다 별로였다"거나. 그런데 흥미롭게도 이 두 반응은 도구의 차이가 아니라 쓰는 방식의 차이에서 비롯된다. 실제로 ProdDraft를 프로덕션에서 운영하며 30일간 Claude Code를 매일 쓴 개발자의 사례(dev.to)와, 2026년 6월 Anthropic의 청구 구조 변경 이후 비용 누수 패턴을 추적한 분석을 함께 놓고 보면, '잘 쓰는 법'의 윤곽이 선명하게 드러난다.
1주차의 함정: 속도에 취하면 2주차가 무너진다
첫 주는 누구에게나 허니문이다. FastAPI 코드베이스를 동기에서 비동기 SQLAlchemy로 전환하는 작업—집중해서 3~4시간은 걸릴 일—을 Claude Code는 45분 만에 끝냈다. API 엔드포인트 추가, 레이트 리미팅, CI 파이프라인 설정까지 모조리 통과. 이쯤 되면 "나 이제 코딩 안 해도 되는 건가?" 싶은 생각이 스친다.
그런데 2주차에 현실이 찾아온다. 8개 파일에 분산된 비즈니스 로직—그것도 6개월 전 밤 11시에 내가 혼자 결정한 암묵적 규칙들—을 포함한 기능을 요청했을 때, Claude Code는 20분 동안 코드베이스를 탐색하고 깔끔한 PR을 만들어냈다. 코드는 아름다웠다. 그리고 완전히 틀렸다. 한 파일의 주석과 다른 파일의 변수명에 흩어진 비즈니스 규칙을 잘못 연결한 것이다.
핵심 교훈은 여기에 있다. Claude Code는 코드를 이해하는 데 탁월하지만, 의도를 이해하는 데는 평범하다. 의도가 명확히 문서화되어 있으면 맞추고, 머릿속이나 암묵적 패턴에만 있으면 추측한다. 그리고 그 추측이 틀렸을 때 진짜 비용이 발생한다—구독료 $200이 아니라, '겉으로 맞아 보이는 코드'를 리뷰하는 시간과 인지 부하.
마이크로스펙: 정확도를 70%에서 95%로 끌어올린 방법
3주차에 워크플로우를 바꿨다. 막연한 기능 요청 대신 마이크로스펙을 먼저 작성하기 시작했다. 형식은 단순하다: 기능이 무엇을 하는지, 엣지 케이스는 무엇인지, 테스트는 무엇을 커버해야 하는지—딱 3~5문장. 결과는 즉각적이었다. 정확도가 ~70%에서 ~95%로 뛰었고, 마이크로스펙 작성 시간은 잘못된 구현을 수정하던 시간보다 훨씬 짧았다.
실제로 작동하는 흐름은 이렇다. 마이크로스펙 작성 → Claude의 코드베이스 탐색 및 질문 → 코드 작성 전 계획 검토 → 테스트와 함께 구현 → 비즈니스 로직 중심으로 diff 리뷰. '절대 지치지 않는 빠른 주니어 개발자와 페어 프로그래밍하는 느낌'이라는 표현이 이 흐름을 잘 설명한다. 단, 가끔 존재하지 않는 라이브러리 메서드를 hallucinate하는 그 주니어와.
잘하는 것과 못하는 것의 경계
4주차가 되면 능력의 경계가 선명해진다. 리팩토링(다수 파일에 걸친 구조적 변경), 그린필드 기능(명확한 스펙, 레거시 제약 없음), 테스트 작성, 문서화, 보일러플레이트—여기서는 압도적이다. 반면 미묘한 로직 버그 디버깅, 성능 최적화(가독성 우선으로 수렴하는 경향), 암묵적 비즈니스 규칙 이해에서는 평범하다.
그리고 아예 못하는 영역도 있다. 아키텍처 결정(옵션 제시는 하지만 트레이드오프 판단은 못 한다), 보안 리뷰(명백한 이슈는 잡지만 미묘한 취약점은 놓친다), 그리고 언제 멈출지 모른다는 것—해결된 문제를 계속 최적화하려 든다. 개발자가 "이제 됐으니 배포하자"고 말해줘야 한다.
구독료 뒤에 숨은 진짜 비용 구조
$200/월이면 시간당 환산 시 2시간 절약만으로 손익분기점을 넘는다. 첫 주에만 15시간을 절약했으니 수익 계산은 쉽다. 하지만 여기서 끝이 아니다. 2026년 6월 15일 Anthropic이 청구 구조를 개편하면서, 지금까지 '구독'으로 뭉뚱그려지던 비용이 실제로는 여러 갈래로 누수되고 있었음이 드러났다(dev.to 분석).
다섯 가지 숨겨진 비용 패턴이 있다. 첫째, 헤드리스 크론 자동화. claude -p를 크론으로 돌리면 구독이 아닌 별도 과금 경로로 라우팅된다. 데이터 수집은 평범한 셸 스크립트에 맡기고, 모델 호출은 인터랙티브 세션으로만 한정해야 한다. 둘째, reasoning effort 과잉 설정. 변수명 하나 바꾸는데 최대 추론 티어를 쓰는 건 혈압 재는데 심장외과 전문의를 부르는 격이다. 루틴 유지보수는 낮은 티어, 디버깅과 아키텍처 결정에만 높은 티어를 써야 한다.
셋째, 5분 캐시 절벽. 프롬프트 캐시 TTL은 약 5분이다. 커피 한 잔 마시고 돌아오면 긴 컨텍스트 전체가 캐시 미스가 나 full rate로 재청구된다. 세션 모멘텀을 유지하거나, 깔끔하게 컨텍스트를 압축(compact)하고 새로 시작하는 편이 낫다. 넷째, CI/CD 자동화의 팬아웃. PR마다, 이슈마다 모델을 호출하면 10명이 하루 40번 푸시하는 팀에서 비용이 기하급수적으로 늘어난다. 자동화 전에 최악의 이벤트 볼륨 기준으로 비용을 먼저 계산해야 한다. 다섯째, 항상 로딩된 툴 서버. 연결된 툴 서버의 정의가 모두 컨텍스트에 올라가며, 쓰지 않더라도 세션 내 모든 요청에 토큰 비용을 낸다. 실제로 쓰는 것만 연결해두는 것이 원칙이다.
결국 설계의 문제다
이 모든 패턴을 관통하는 하나의 원칙이 있다. 구독을 속도 제한(rate cap)으로 보되, 지출 한도(spend cap)로 착각하지 마라. 비용 누수는 버그가 아니다. 시스템이 시킨 대로 정확히 돌아간 결과다. 대시보드에는 '구독'이라고 쓰여 있지만, 실제 비용은 토큰 레이어 아래에서 조용히 쌓인다.
마이크로스펙이 정확도를 높이는 것도, 비용 구조를 의식적으로 설계하는 것도, 결국 같은 맥락이다. Claude Code는 빠르고 지치지 않는다. 하지만 방향을 잡는 것, 의도를 명확히 하는 것, 어디에 모델 호출을 배치할지 결정하는 것—그건 여전히 개발자의 일이다. AI 코딩 에이전트가 최고의 개발자를 극적으로 더 생산적으로 만드는 동시에, 나쁜 코드를 더 빠르게 배포하기 쉽게 만드는 이유가 바로 여기에 있다. 어느 쪽이 되느냐는, 리뷰를 얼마나 잘 하느냐가 아니라 얼마나 잘 설계하느냐에 달려 있다.