Claude Code를 사용하여 6개의 프로젝트를 구축하는 데 $8,857를 사용했습니다. 제가 배운 점은 다음과 같습니다.

판매 목적이 아닙니다. Dev.to나 Reddit에 Claude Code에 대한 심층적인 사용 경험이 거의 없다는 점을 발견했습니다. 대부분 "보세요, 저는 할 일 목록(todo) 앱을 만들었습니다"와 같은 게시물뿐입니다. 거의 9천 달러를 써버린 후, 저는 공유할 수 있는 실제 데이터를 가지고 있습니다.

수치 (The Numbers)

14일. $8,857.62. 38억 8,400만 토큰 (3.884 billion tokens). 47,235회 API 요청 (API requests). 모두 Claude Opus 4.8 (1M 컨텍스트 창 (context window))을 사용한 결과입니다.

여러분은 아마 제가 미쳤다고 생각할 것입니다. 솔직히 저도 첫 주가 지난 후 청구서를 보고 약간 당황했습니다. 하지만 계산은 이렇습니다. 저는 6개의 프로젝트를 동시에 진행하고 있었고, 그중 2개는 풀스택 (full-stack) 프로덕션 앱이었습니다. 시간당 $150의 프리랜서 요율을 적용하면, 이 프로젝트들은 4~5주 분량의 작업에 해당합니다.

지출은 선형적이지 않았습니다. 처음 3일 동안은 도구를 효과적으로 사용하는 방법을 파악하느라 약 $800가 들었습니다. 피크 타임이었던 이틀 동안은 각각 $800 이상이 발생했습니다. 특히 6월 18일 하루에만 $828.74를 썼는데, SaaS 앱의 보안 강화 (security hardening)를 수행하는 동시에 비디오 파이프라인 (video pipeline)의 디버깅 (debugging)을 병렬로 진행했기 때문입니다. 마지막 며칠 동안은 하루 약 $300 수준으로 떨어졌는데, 설정이 최적화되자 주고받는 대화량이 급격히 줄어들었기 때문입니다.

프로젝트별 대략적인 내역은 다음과 같습니다:

대부분의 사람들은 토큰이 "입력 (input) + 출력 (output)"으로 나뉜다고 가정합니다. 틀렸습니다. 저의 실제 과금 구조를 보십시오:

이것이 바로 "무엇을 하는지 아는 사람"과 "대충 하는 사람" 사이의 비용 차이가 5배까지 벌어질 수 있는 이유입니다. 숙련된 사용자는 캐시 히트율 (cache hit rates)을 높게 유지하는 반면, 부주의한 사용자는 컨텍스트 (context)를 휘저어 놓아 몇 번의 턴마다 캐시를 무효화하기 때문입니다. (캐시 히트를 극대화하는 방법은 매뉴얼의 모듈 2에서 심도 있게 다룹니다.)

단일 요청의 실제 비용은 얼마인가요?

제 결제 상세 내역에서 몇 가지 항목을 가져왔습니다. 동일한 모델, Opus 4.8 기준입니다:

• 212 입력 토큰 (input tokens), 1,397 출력 토큰 (output tokens) = $1.91, 104초 소요
• 514 입력 토큰, 7 출력 토큰 (단순 확인) = $0.45, 2초 소요

패턴이 보이시나요? 출력 토큰 (output tokens)은 입력 토큰보다 5배 더 비쌉니다 (Opus 4.8: 입력 1M당 $15, 출력 1M당 $75). 따라서 Claude가 설명을 건너뛰고 코드만 작성하도록 하는 것이 실제로 돈을 아껴줍니다. 장황한 해설이 포함된 2,000줄의 응답은 깔끔한 코드 500줄보다 몇 배나 더 많은 비용이 듭니다. 이것이 제 CLAUDE.md에 "간결하게 작성하고, 요청받지 않은 것에 대해 설명하지 마시오"라고 명시적으로 적어둔 이유입니다.

Sonnet 대신 왜 Opus 4.8을 사용하나요?

단순한 규칙이 있습니다. 만약 제가 직접 수행하는 데 2시간 이상의 사고 시간이 필요한 작업이라면 Opus를 사용합니다. 만약 단순 반복 작업 (일괄 파일 변경, 주석 추가, 테스트 작성 등)이라면 Sonnet으로도 충분합니다.

Opus는 아키텍처 결정 (architectural decisions) 측면에서 눈에 띄게 뛰어납니다. 예를 들어, LightCraft의 멀티 엔진 페일오버 (multi-engine failover) — Runway의 API가 타임아웃될 때, 크레딧이 한 번만 차감되도록 보장하면서 자동으로 Kling으로 전환하는 기능 — 와 같이 상태 관리 (state management) 및 예외 케이스 (edge cases)를 포함하는 설계는 Opus가 첫 번째 시도에 완벽하게 해냅니다. Sonnet은 2~3번의 수정 과정을 거쳐야 할 수도 있습니다.

하지만 단순한 작업에서는 Sonnet이 더 나은 비용 효율성을 보여줍니다. 현재 저의 워크플로우는 settings.json에 두 개의 프로필을 설정하고 작업 복잡도에 따라 전환하는 방식입니다.

6개의 프로젝트: 가치가 있었던 것과 그렇지 않았던 것

1. LightCraft V2 (Image-to-Video SaaS) — 가치 있었음

가장 비용이 많이 들었지만, ROI (투자 대비 수익)가 가장 높았습니다. 사용자 인증, 크레딧 충전, 비디오 생성, 보안 강화 등을 포함한 완전한 Next.js 풀스택 앱입니다.

Claude의 결과물이 제가 직접 작성했을 것보다 더 나았던 몇 가지 영역:

• OWASP 보안 강화 (CSRF 토큰, 속도 제한 (rate limiting), 입력값 정제 (input sanitization))
• 크레딧 시스템 트랜잭션 일관성 (크레딧 차감과 작업 생성이 원자적 (atomic)으로 이루어져야 함)
• 멀티 엔진 페일오버 (failover) 로직 (Runway → Kling → Veo 폴백 (fallback) 체인)

보수적인 추정치: 개발 시간 3주를 절약했습니다. 동시성 크레딧 차감 문제 하나만 해결하려 해도 며칠은 걸렸을 것입니다.

2. 심리 퀴즈 앱 (sbti2) — 가치가 있음

0에서 배포까지 4시간이 걸렸습니다. Framer Motion 페이지 전환, 레이더 차트 시각화, QR 코드 공유 기능이 포함되어 있습니다. 이런 종류의 "작지만 완성도 높은" 프로젝트가 Claude Code의 스위트 스팟 (sweet spot)입니다. 명확한 요구사항, 잘 정의된 범위, 그리고 오후 한나절 만에 완료되는 작업 말이죠. 제 프롬프트 전체는 단 한 문장이었습니다: "사용자가 질문에 답하면 상세 분석이 포함된 레이더 차트를 볼 수 있고, 스크린샷 공유를 지원하는 심리 평가 앱을 만들어줘." Claude는 기술 스택을 선택하고, 프로젝트의 스캐폴딩 (scaffolding)을 수행하며, 모든 코드를 작성했습니다. 저는 색상 구성만 두 번 변경했을 뿐입니다.

3. AI 뉴스 비디오 파이프라인 — 가치가 있음

이 프로젝트는 가장 지속적인 투자 대비 수익 (ROI)을 제공합니다. Claude는 다음과 같은 자동화 파이프라인을 구축하는 데 도움을 주었습니다: RSS 뉴스 스크레이핑 (scraping) → LLM을 통한 보이스오버 스크립트 재작성 → TTS 오디오 생성 → 자동 매칭된 비주얼 → FFmpeg 비디오 조립. 이제 일일 기술 뉴스 브리핑을 제작하는 데는 인간의 개입이 30분 정도만 필요하며, 대부분 기술적인 운영보다는 콘텐츠 품질을 검토하는 데 사용됩니다.

언급할 만한 세부 사항이 하나 있습니다: 만약 비디오가 특정 제품을 다룬다면, 반드시 실제 제품 영상을 포함해야 합니다. 텍스트 카드로 가짜를 만들어서는 안 됩니다. Claude는 YouTube 비디오 다운로드 및 클립 추출 로직을 작성했으며, 다운로드에 실패할 경우 플레이스홀더 (placeholder) 이미지를 조용히 대체하는 대신 해당 비디오의 제작을 완전히 중단합니다. 이 "가짜를 만드느니 차라리 아무것도 하지 않는다"는 로직은 제 CLAUDE.md에 명시적으로 지정되었습니다.

4. 뉴질랜드 워킹홀리데이 (NZ WHV) 비자 슬롯 확보 도구 — 절반은 가치 있고, 절반은 그렇지 않음

Playwright 자동화는 깔끔했습니다: 양식 채우기, CAPTCHA 대기 로직, 재시도 메커니즘, 심지어 체크포인트 재개(checkpoint resumption)를 통한 네트워크 타임아웃 복구까지 가능했죠. 하지만 뉴질랜드 이민성에서는 __VIEWSTATE와 __EVENTVALIDATION 숨겨진 필드를 사용하는 ASP.NET Web Forms를 사용하는데, 이 값들이 양식 제출할 때마다 변경됩니다. Claude의 초기 버전은 이 값들을 하드코딩하여 즉시 500 에러가 발생했습니다. 제가 이를 지적하자 동적으로 파싱하는 방식으로 전환했지만, 그러다가 다단계(multi-step) 양식 상태 관리에서 어려움을 겪었습니다. 안정화시키는 데 5~6번의 시도가 필요했습니다.

교훈: 기술 스택이 더 오래되고 생소할수록 Claude가 저지르는 실수가 많습니다. 학습 데이터에 ASP.NET Web Forms보다 React 문서가 훨씬 많기 때문입니다. 만약 프로젝트에 레거시(legacy) 기술이 포함되어 있다면, 디버깅 시간이 30~50% 더 걸릴 것으로 예상해야 합니다.

5. 개발자 튜토리얼 — 가치가 있지만, 주의할 점이 있다

Claude는 문서를 작성할 때 지나치게 설명하는 습관이 있습니다. 간단한 export https_proxy=http://127.0.0.1:7890 명령어 하나에 배경 지식 200단어가 붙습니다. 저는 단어 수를 통제하기 위해 CLAUDE.md에서

// ~/.claude/settings.json
{
  "preferences": {
...

그다음은 권한 설정 (permission configuration)입니다. 기본적으로 Claude는 셸 명령 (shell command)을 실행할 때마다 확인을 요청합니다. 만약 본인의 개인 개발 환경이라면, 자주 사용하는 명령어를 허용 목록 (allowlist)에 추가할 수 있습니다:

{
  "permissions": {
    "allow": [
...

이 설정 하나만으로도 상호작용 중단(interaction interruptions)을 50% 이상 줄일 수 있습니다.

CLAUDE.md는 단순히 "TypeScript를 사용해 주세요"라고 말하는 곳이 아닙니다

제 CLAUDE.md는 거의 80줄에 달합니다. 가장 중요한 부분은 기술 스택 선언이 아니라, 바로 **행동 제약 사항 (behavioral constraints)**입니다:

## 코딩 원칙 (Coding Principles)
- 200줄의 코드를 50줄로 작성할 수 있다면, 다시 작성할 것
- 요청된 범위를 벗어나는 기능을 추가하지 말 것
...

이러한 제약 사항이 없다면, Claude는 당신이 요청하지 않은 것들을 멋대로 덧붙일 것입니다: 설정 파일 관리자, 커스텀 예외 계층 구조 (custom exception hierarchies), 과도하게 추상화된 팩토리 패턴 (over-abstracted factory patterns) 등 말이죠...

훅 시스템 (Hooks System)은 거의 논의되지 않습니다

Claude Code에는 특정 작업 전후에 스크립트를 자동으로 실행하는 훅 (hooks) 메커니즘(PreToolUse, PostToolUse, Notification 등)이 있습니다. 예를 들어, 저는 Claude가 프론트엔드 컴포넌트 파일을 수정하면 eslint --fix가 자동으로 실행되도록 PostToolUse 훅을 설정했습니다. 이를 통해 포맷팅을 수정하라고 반복해서 지시하는 수고를 덜 수 있습니다. 또한 PreToolUse를 사용하여 node_modules 외부의 디렉토리를 삭제하는 것을 차단하는 것과 같이 위험한 작업을 가로챌 수도 있습니다. 이 시스템을 한 번 설정해 두면, 많은 반복적인 확인과 포맷팅 작업이 자동으로 이루어집니다. 하지만 공식 문서에서는 이를 단 몇 문단으로만 다루고 있어, 대부분의 설정 패턴은 소스 코드를 읽거나 시행착오를 거치며 직접 알아내야 합니다.

5가지 값진 교훈

교훈 1: effortLevel을 xhigh로 설정하는 것이 모든 것을 바꿉니다

기본 노력 수준 (effort level)에서 Claude는 "컴파일되니까 그냥 배포하자" 식의 코드를 작성하는 경향이 있습니다. 이를 xhigh로 설정하면 Claude는 선제적으로 엣지 케이스 (edge cases)를 고려하고, 더 완전한 에러 핸들링 (error handling)을 작성하며, 심지어 설계 결정 사항을 설명하는 주석까지 추가합니다.

네, 요청당 비용은 더 많이 듭니다. 하지만 첫 시도에 바로 올바른 코드를 작성하는 것과 5번의 수정 과정을 거쳐야 하는 코드를 비교하면 — xhigh가 실제로 총비용 면에서는 더 저렴합니다. 기본 노력(default effort) 설정에서는 4번의 수정 과정을 거쳐야 했던 API 라우트(API route)가 있었는데, 매번 수정 사항이 불완전했습니다. xhigh로 전환한 후에는 유사한 작업들이 일관되게 단 한 번의 과정으로 완료되었습니다.

레슨 2: CLAUDE.md에서 "과잉 설계(Over-Engineer) 하지 마세요"라고 명시하는 것은 무엇보다 가치 있는 일입니다

Claude는 DNA 자체에 과잉 설계(over-engineering) 성향이 있습니다. 무엇을 요청하든 추상화 계층(abstraction layers)을 추가하고 싶어 합니다. 단순한 API 호출을 원하면, 전략 패턴(strategy pattern) + 의존성 주입(dependency injection) + 커스텀 예외 계층 구조(custom exception hierarchy)를 제공합니다.

CLAUDE.md에 다음 내용을 추가한 후에는:

요청된 것 이상의 기능을 추가하지 마세요
일회성 코드를 위해 추상화를 만들지 마세요
요청되지 않은 "유연성"이나 "설정 가능성"을 추가하지 마세요

코드 품질이 한 단계 올라갔습니다. 더 복잡해짐으로써가 아니라, 더 단순해짐으로써 말입니다.

레슨 3: 허니팟(Honeypot) 안티 봇 필드는 실제 사용자를 차단할 수 있습니다

LightCraft의 로그인 보안을 구축할 때, Claude는 허니팟 필드(honeypot field)를 추가할 것을 제안했습니다. 이는 인간은 볼 수 없고 채우지도 않지만, 봇은 자동으로 채우게 되어 봇으로 식별하게 만드는 CSS로 숨겨진 폼 필드(form field)입니다.

논리적으로는 완벽합니다.

하지만 배포 후, 저는 1Password, Bitwarden 및 기타 비밀번호 관리자(password managers)들도 숨겨진 필드를 자동으로 채운다는 사실을 발견했습니다. 실제 사용자들이 봇으로 분류되어 차단되고 있었습니다.

Claude는 이에 대해 경고하지 않을 것입니다. 왜냐하면 사용자들이 비밀번호 관리자를 사용한다는 사실을 모르기 때문입니다. AI가 생성한 코드는 논리적으로는 정확할 수 있지만, 실제 사용자 시나리오에서는 실패할 수 있습니다. 반드시 직접 시나리오 테스트를 수행해야 합니다.

레슨 4: 일일 보상에 너무 관대하게 설정하지 마세요

이것은 코드에 관한 것이 아니라 제품 디자인(product design)에 관한 것입니다.

크레딧 시스템을 설계할 때, 저는 Claude에게 "일일 체크인 시 10 크레딧 제공"을 구현하도록 했습니다. 이는 한 달에 300 크레딧입니다. 하지만 유료 Pro 플랜은 한 달에 200 크레딧만 제공했습니다.

무료 사용자가 유료 고객보다 더 많은 혜택을 받고 있었습니다.

Claude는 당신의 비즈니스 로직(Business logic)에 의문을 제기하지 않습니다. 당신이 일일 보상을 10이라고 말하면, Claude는 dailyReward: 10이라고 작성합니다.