비용 관리와 ROI

클로드 코드는 전기요금처럼 어쩔 수 없이 내는 비용이 아니라, 작은 공장을 월세로 들여오는 일에 가깝다. 문제는 공장을 들여놓고도 생산량을 재지 않으면, 어느 날 남는 것은 카드 명세서뿐이라는 점이다. 솔로 빌더에게 중요한 질문은 "비싼가?"가 아니라 "내 시간을 얼마나 더 비싼 일로 바꿔줬는가"다.

이 장에서는 감으로 쓰던 AI 비용을 숫자로 바꾼다. 월 청구서를 읽는 법, Sonnet과 Opus를 나누는 원칙, 시간과 매출 기준의 ROI 계산법, 그리고 언제는 과감하게 AI를 끄고 직접 코딩해야 하는지까지 정리해보자.

솔로 빌더의 월 청구서 분석

AI 비용은 구독료 한 줄로 끝나지 않는다. 솔로 빌더의 월 청구서는 보통 세 층으로 쌓인다.

• 첫째는 고정비다. 공식 가격 기준으로 개인 사용자는 Pro가 월 20달러, 연간 결제 시 월 17달러 수준이다. Max는 월 100달러부터 시작하며, Pro 대비 더 높은 사용량 한도를 제공한다.¹

• 둘째는 변동비다. API를 쓰면 토큰 단위 비용이 붙는다. 현재 기준으로 Opus 4.7은 입력 100만 토큰당 5달러, 출력 25달러, Sonnet 4.6은 3달러와 15달러, Haiku 4.5는 1달러와 5달러 수준이다. prompt caching도 별도 가격 구조가 있다.¹

• 셋째는 숨은비용이다. 검수, 되돌리기, 다시 지시하기, 테스트 실패를 추적하는 시간이다. 이건 청구서에 안 찍히지만 실제 비용이다.

여기서 많이 하는 실수가 있다. 20달러 플랜을 쓰면서 "나는 월 20달러만 쓰고 있어"라고 생각하는 것이다. 아니다. 진짜 비용은 아래처럼 계산해야 한다.

실질 월비용 = 구독료 + API/초과 사용료 + (검수 시간 × 내 시간가치)

이 식이 중요한 이유는, 솔로 빌더에게 검수 시간도 현금과 거의 같은 의미이기 때문이다. 토요일 오후 두 시간을 AI가 헛돌게 만들었다면, 그건 그냥 무료가 아니다. 기능 출시가 늦어지고, 마케팅 일정이 밀리고, 체력이 닳는다.

시간가치도 대충 잡으면 안 된다. 직장인의 시급처럼 계산하지 말고, "내 한 시간이 제품의 다음 단계에 얼마짜리인가"로 보는 편이 좋다. 보수적으로 잡고 싶다면 세금, 운영비, 기회비용까지 포함해 조금 넉넉하게 보는 편이 낫다.

가장 실용적인 방법은 월말에 카드 명세서를 보는 게 아니라, 매주 이 세 숫자를 적는 것이다. 얼마 냈나, 몇 시간을 아꼈나, 몇 시간을 다시 썼나. 이 세 줄만 있어도 감정이 아니라 운영이 된다.

손익분기점은 생각보다 낮다

손익분기점 절약시간은 아주 단순하다.

손익분기점 시간 = 월 현금비용 ÷ 내 시간가치

예를 들어 내 시간가치를 시간당 50달러로 본다면, Pro 20달러는 한 달에 24분만 아껴도 본전이다. Max 100달러는 두 시간, Max 200달러는 네 시간이다. 그래서 솔로 빌더에게 진짜 위험은 "AI가 비싸다"가 아니라 "AI를 비싸게 쓰는 습관"이다.

Sonnet으로 80%, Opus로 20% 원칙

모델 선택을 감으로 하면 비용이 새고, 반대로 무조건 싼 모델만 고집하면 시간이 샌다. 둘 다 손해다. 그래서 권하는 기본 원칙이 Sonnet 80%, Opus 20%다.

Sonnet은 일상 작업의 기본 엔진으로 쓰기에 좋다. CRUD 기능 추가, 테스트 초안, 문서 정리, 리팩터링 1차 시도, 일반적인 버그 수정, PR 리뷰 초안 같은 일은 대부분 Sonnet으로 충분하다. 반면 Opus는 문제의 단가가 큰 순간에 꺼내는 모델이다. 예를 들어 아키텍처 방향을 정해야 할 때, 복잡한 레이스 컨디션을 추적할 때, 대규모 마이그레이션 계획을 세울 때, 혹은 잘못된 답의 비용이 큰 결제·권한·데이터 무결성 영역에서 그렇다.¹

이 원칙을 더 실무적으로 바꾸면 이렇다.

• 먼저 Opus로 생각하게 하고, Sonnet으로 많이 만들게 한다.

• Sonnet이 같은 종류의 실수를 두 번 반복하면 그때 Opus로 승격한다.

• Opus가 설계와 리스크 목록을 뽑아주면 다시 Sonnet으로 내려서 구현량을 처리한다.

이렇게 하면 비싼 모델은 방향을 틀리면 큰일 나는 순간에만 쓰고, 실제 코드 생산량은 상대적으로 효율적인 모델에 맡기게 된다. 솔로 빌더에게 중요한 건 최고 성능 모델을 늘 켜두는 것이 아니라, 최고 성능이 필요한 순간을 구별하는 감각이다.

작업 흐름도 이렇게 짜면 좋다. 먼저 Opus에게 이 기능의 실패 포인트, 데이터 모델, 테스트 전략을 짧게 설계하게 한다. 다음으로 Sonnet에게 구현과 테스트 생성, 사소한 수정, 문서화를 맡긴다. 마지막으로 아주 반복적인 정리 작업은 더 가벼운 모델이나 짧은 요청으로 처리한다. 출력 토큰이 입력보다 훨씬 비싸기 때문에, 장황한 보고서를 매번 받기보다 "변경 계획 5줄 + diff 중심"처럼 응답 형식을 짧게 제한하는 것도 비용을 낮추는 데 도움이 된다.¹

모델 분배 원칙은 결국 돈 관리이면서 집중력 관리다. Opus를 남발하면 카드값이 올라가고, Sonnet을 과신하면 리뷰 시간이 올라간다. 둘 다 생산성이 아니라 마찰이다.

ROI 측정: 시간, 매출, 학습 곡선

ROI를 재려면 먼저 착각부터 버려야 한다. "오늘 엄청 바빴다"는 지표가 아니다. "코드가 많이 생성됐다"도 지표가 아니다. 솔로 빌더에게 ROI는 세 개의 장부로 봐야 한다.

첫째, 시간 ROI

시간 ROI는 가장 먼저 봐야 하고, 가장 속이기 어렵다. 계산식은 단순하다.

시간 ROI = (AI 없이 걸렸을 시간 - AI와 함께 실제로 쓴 시간) × 내 시간가치

중요한 것은 실제로 쓴 시간에 프롬프트 작성, 재시도, 테스트 확인, 롤백까지 다 넣는 것이다. 그래야 숫자가 정직해진다.

여기서 특히 빼먹기 쉬운 시간이 디버깅 시간이다. AI 작업은 처음 60%가 놀랄 만큼 빠른 대신, 마지막 40%에서 갑자기 늪이 생기기 쉽다. 그래서 생성 속도가 아니라 완료 속도로 재야 한다.

둘째, 매출 ROI

솔로 빌더에게는 이 장부가 종종 시간 ROI보다 더 중요하다. AI 덕분에 일주일 먼저 출시했다면, 그 일주일은 그냥 시간이 아니라 매출 기회다. 예를 들어 결제 페이지 개선을 사흘 앞당겨서 첫 유료 고객 두 명을 더 받았다면, 그 수익은 AI의 간접 성과다.

다만 여기서도 과장하면 안 된다. "언젠가 돈이 될 것 같음"은 매출 ROI가 아니다. 실제 결제, 실제 전환율 개선, 실제 해지율 감소처럼 숫자로 잡히는 것만 넣어야 한다. 출시 속도가 빨라진 효과를 넣고 싶다면, 며칠 앞당겼는가와 그 기간에 실제로 벌어들인 돈으로 계산하는 편이 가장 솔직하다.

셋째, 학습 ROI

이 장부는 가장 중요하면서도 가장 위험하다. 왜냐하면 거의 무엇이든 합리화할 수 있기 때문이다. "이번 달엔 돈은 못 벌었지만 많이 배웠다"는 말은, 대개 진실이기도 하고 핑계이기도 하다.

그래서 학습 ROI는 현금 장부와 분리해서 본다. 예를 들어 다음과 같은 자산이 남았다면 학습 ROI가 있다.

• 다음 프로젝트에도 재사용할 CLAUDE.md 템플릿

• 반복 작업을 줄여줄 슬래시 커맨드, 훅, 스킬

• 이후 기능 개발 속도를 높여줄 DB 스키마, 인증 구조, 배포 파이프라인

이것들은 당장 현금처럼 잡지 말고, 앞으로 몇 번 더 재사용할 것인가를 기준으로 보수적으로 적어두는 편이 좋다. 학습 ROI는 현재 월 손익을 예쁘게 보이게 만드는 화장품이 아니라, 미래 생산성을 올리는 설비투자에 가깝다.

솔로 빌더용 월간 ROI 계산식

실전에서는 아래 식 하나면 충분하다.

월 순가치 = (절약시간 × 시간가치) + 실제 추가매출 - 월 현금비용 - AI로 인해 추가된 검수시간 비용

그리고 ROI는 이렇게 본다.

월 ROI(%) = 월 순가치 ÷ 월 현금비용 × 100

예를 들어보자. 한 달 AI 현금비용이 100달러이고, 절약시간이 12시간이며, 내 시간가치를 40달러로 본다면 시간가치만으로 480달러다. 여기에 AI 때문에 추가로 리뷰한 시간이 2시간이라면 80달러를 빼서 400달러가 남는다. 추가 매출이 0이어도 순가치는 300달러다. 이미 3배다.

중요한 건 거창한 대시보드가 아니다. 매주 금요일 10분 동안 이번 주 AI가 벌어준 시간, 빼앗아간 시간, 앞당긴 출시만 적어도, 다음 달의 모델 선택과 위임 방식이 눈에 띄게 좋아진다.

언제 클로드 코드를 끄고 직접 칠 것인가

AI를 잘 쓰는 사람은 늘 켜두는 사람이 아니라, 꺼야 할 순간을 아는 사람이다. 솔로 빌더에게 가장 비싼 실수는 "이 정도는 내가 7분이면 끝낼 일을 25분 동안 AI와 씨름하는 것"이다.

다음 경우에는 직접 치는 편이 대체로 이긴다.

• 수정 범위가 너무 작을 때다. 변수명 하나 바꾸기, CSS 2픽셀 조정, 로그 한 줄 추가처럼 설명하는 시간이 구현 시간보다 길면 직접 하는 편이 낫다.

• 문제 정의가 아직 흐릴 때다. 무엇을 만들지도 모르는 상태에서 AI에게 만들라고 하면, 값비싼 혼란만 빨라진다.

• 같은 오류를 두 번 이상 반복할 때다. 같은 테스트를 계속 깨고 같은 방향으로 고치려 한다면, 잠깐 손으로 들어가서 핵심 원인을 잡아야 한다.

• 실수 비용이 큰 구간일 때다. 결제, 권한, 데이터 삭제, 마이그레이션, 보안 설정처럼 한 번 잘못 건드리면 복구 비용이 큰 부분은 사람이 직접 마지막 결정을 내려야 한다.

• 마감 직전의 핫픽스일 때다. 지금 필요한 것이 멋진 설계가 아니라 정확한 한 줄이라면, 그 한 줄은 직접 쓰는 편이 빠르다.

이 판단을 쉽게 만드는 실전 규칙도 있다. 10분 규칙은 프롬프트 작성부터 리뷰까지 포함해 10분 안에 AI가 끝낼 자신이 없으면 직접 한다는 것이다. 2회 루프 규칙은 같은 유형의 실패가 두 번 나오면 모델을 바꾸거나, 아예 내가 들어가서 끊는다는 뜻이다. 고위험 직접승인 규칙은 삭제, 권한, 결제, 운영 데이터 변경은 언제나 사람이 최종 커맨드를 친다는 원칙이다.

여기서 중요한 건 자존심이 아니다. 직접 코딩은 AI 활용의 실패가 아니라, 전체 시스템의 최적화다. 삽 대신 굴착기를 쓰는 날이 있고, 젓가락으로 콩을 집어야 하는 날도 있다. 솔로 빌더는 둘 다 할 수 있어야 한다.

계산 없이 쓰면 도구가 아니라 부담이 된다

AI 도구는 비용이 아니라 투자다. 하지만 투자에는 항상 기준선이 필요하다. 그 기준선은 거창하지 않다. 한 달에 얼마를 냈는가, 몇 시간을 아꼈는가, 얼마나 더 빨리 출시했는가, 그리고 몇 번은 차라리 내가 직접 하는 편이 나았는가. 이 네 가지만 추적해도 비용은 통제되고, ROI는 눈에 보이기 시작한다.

좋은 솔로 빌더는 AI를 믿는 사람이 아니다. AI를 숫자로 다루는 사람이다. 그리고 숫자로 다루기 시작하는 순간, 클로드 코드는 월 구독 하나 더가 아니라 혼자 일하는 사람에게 가장 싼 레버리지 중 하나가 된다.

참고

¹Plans & Pricing | Claude by Anthropic