I Spent $31,141 & 1,000 Hours On Claude Code To Learn This

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Claude Code에 31,141달러를 쓰고 여러 모델을 1,000시간 이상 사용하며 얻은 핵심 교훈은 반복 평가, 컨텍스트 정리, 작업 분담으로 결과의 일관성과 비용 효율을 높이라는 것이다.

📌 핵심 요점

1. 첫 성공보다 반복 성공률을 확인한다. 같은 프롬프트를 10번 실행하고 수정 전후의 성공 횟수를 비교한다. 스크린샷·참고 예시·검사 도구를 기준으로 초안을 수정해 품질 편차를 줄인다.
2. 큰 작업은 목표와 완료 기준부터 구체화한다. 모델과 질문을 주고받으며 대상 독자, 좋은 결과의 기준, 참고 예시를 정한다. 수정에 앞서 문제를 진단하고 해결할 범위를 선택하며, 수행 방식에는 재량을 주되 테스트와 확인은 요구한다.
3. 컨텍스트는 현재 작업에 필요한 정보로 관리한다. 구현 설명은 코드·인라인 주석과 가깝게 유지하고, 선호와 교훈은 별도 지침에 둔다. 불필요한 MCP·스킬과 낡은 정보를 줄이고, 긴 대화는 사람이 검토한 인계 요약으로 새 세션에 연결한다.
4. 검증한 반복 업무와 독립 작업을 각각 최적화한다. MCP로 작동 여부를 빠르게 확인한 뒤 경제성이 확인된 업무는 필요한 기능만 담은 맞춤형 스킬로 좁힌다. 수정 대상이 겹치지 않는 작업은 에이전트에 병렬로 맡기고 통합 단계에서 확인한다.
5. 모델별 역할과 운영 지침을 계속 갱신한다. 저비용 모델은 넓은 조사에, 강한 모델은 종합 판단에 활용한다. 실패는 해결 방법이 포함된 지침으로 바꾸고, 모델 업데이트 때 지침을 재점검하며 장애에 대비한 대체 도구를 준비한다.

🧩 배경과 문제 정의

• 수개월간 Claude Code에 3만 달러 넘게 지출하고 여러 모델을 1,000시간 이상 사용한 경험을 바탕으로, 결과의 품질과 작업 효율을 높이는 방법을 다룬다.
• 언어 모델은 같은 프롬프트에도 서로 다른 결과를 낼 수 있다. 첫 성공만으로 프롬프트를 회사의 표준 업무 절차에 편입하면 이후 작업에서 품질 문제가 누적될 수 있다.
• 오래된 문서, 불필요한 도구 정의, 상충하는 대화가 컨텍스트에 쌓이면 비용이 늘고 판단이 흐려질 수 있다. 반복 평가와 수정, 최신 정보 유지, 작업 분담이 핵심 과제다.

🕒 시간순 섹션별 상세정리

1. 첫 결과보다 반복 평가로 프롬프트의 신뢰성을 판단한다

• 같은 프롬프트라도 결과 차이가 작을 때도 있고 완전히 달라질 때도 있다. 유튜브 대본이 처음 한 번 잘 나왔다는 이유만으로 해당 프롬프트를 회사 전체의 표준 업무 절차로 삼기는 어렵다. [01:28]
• 프롬프트 개선의 목표는 최고 품질의 결과를 한 번 얻는 데 그치지 않고, 실행마다 발생하는 품질 편차를 줄여 결과를 예측하기 쉽게 만드는 것이다. [02:22]

2. 검증 기준을 제공하고 초안을 반복 수정한다

• 한 번 생성한 결과는 완성본보다 첫 초안에 가깝다. 기대에 못 미치는 결과를 개선하려면 모델이 자신의 작업을 확인하고 수정한 뒤 다시 시도할 수 있어야 한다. [04:12]
• 스크린샷, 비교용 예시, 웹사이트의 Lighthouse·PageSpeed Insights 같은 검사를 수정의 기준으로 활용한다. 평가 체계가 완벽하지 않더라도 비교 대상이 있는 수정 과정은 일반적으로 품질을 높일 수 있다. [04:34]

3. 구현과 분리된 설명보다 코드에 가까운 컨텍스트를 유지한다

• 코드가 V1에서 V2·V3·V4로 바뀌어도 노트, 명세, 로그는 V1에 머물 수 있다. 이때 실제 구현과 모델이 참고하는 설명 사이에 불일치가 생긴다. [05:43]
• 필요한 설명을 스크립트와 인라인 주석에 함께 두면 모델이 수정 대상 코드와 관련 맥락을 같이 읽을 수 있다. 내비게이션에 로그아웃 버튼을 추가하는 예에서는 오래된 별도 문서보다 현재 코드와 주석을 직접 참고하는 방식이 더 나은 결과로 이어진다는 경험적 주장이다. [06:26]

4. 큰 작업은 모델과 함께 프롬프트부터 설계한다

• 원하는 결과와 대상 독자를 제시한 뒤 곧바로 실행시키기보다 프롬프트 작성을 도와달라고 요청한다. 대상이 누구인지, 좋은 결과의 기준이 무엇인지, 참고 예시가 있는지를 질문과 답변으로 구체화한다. [07:26]
• 메타 프롬프팅은 모델이 다른 에이전트에 작업을 전달하는 능력을 활용하는 접근이다. 핵심은 사람이 모든 지시문을 직접 완성하기보다 모델이 적절한 지시문을 만들도록 이끄는 데 있다. [07:52]

5. 컨텍스트 점유를 확인하고 불필요한 내용을 줄인다

• /context로 컨텍스트 구성을 확인할 수 있다. 시스템 프롬프트, 기본 도구, MCP 커넥터, 메모리, 스킬이 입력 전부터 공간을 차지하며, 약 30%가 이미 사용된다는 수치는 확실한 측정값이 아닌 개인적 추정이다. [08:58]
• 대화가 길어질수록 요청 비용이 커지고 컨텍스트 누적으로 성능이 저하될 수 있다. 사용하지 않는 MCP와 스킬을 줄이고, 창이 거의 찼거나 응답이 기대에 못 미치면 필요한 맥락을 담은 프롬프트를 새 세션으로 옮긴다. [09:51]

6. 세부 절차 대신 완료 조건과 핵심 원칙을 명확히 한다

• 과거 모델에 적용하던 촘촘한 단계별 통제를 줄이고, 작업 방식을 스스로 선택하는 외부 전문가처럼 모델을 대한다. 원하는 작업과 결과를 정의하되 수행 절차에는 재량을 주는 방식이다. [11:23]
• 어떤 조건이 충족되면 완료인지 명시하고, 모르는 부분은 질문하게 하며, 테스트는 생략하지 않도록 한다. 수많은 금지 문구보다 완료 기준과 중요한 행동 원칙에 집중한다. [11:53]

7. 수정 전에 문제를 진단하고 해결 범위를 선택한다

• “앱 전체를 고쳐 달라”는 요청보다 먼저 문제를 나열하고 아직 수정하지 말라고 요청한다. 모델이 문제라고 판단하는 대상과 사용자가 실제로 바꾸려는 대상은 다를 수 있다. [12:26]
• 글의 문제로 불명확한 도입, 중복, 지나치게 비격식적인 문체, 예시 부족이 나왔다면, 문체는 유지하고 나머지 세 가지만 수정하도록 선택할 수 있다. [12:42]

8. MCP로 빠르게 검증하고 반복 업무는 필요한 기능으로 좁힌다

• MCP 커넥터는 연결하고 로그인한 뒤 작동 여부를 빠르게 확인하기에 편리하다. 다만 초기 검증의 편리함이 대규모 반복 운영의 효율까지 보장하지는 않는다. [13:46]
• 범용 MCP는 불필요한 도구 명세까지 포함해 컨텍스트를 많이 차지할 수 있다. 경제적 효과를 확인한 업무는 필요한 도구 호출과 명세만 갖춘 맞춤형 스킬로 전환해 컨텍스트 부담을 줄이는 접근을 권한다. [14:32]

9. 겹치지 않는 작업을 병렬로 처리한 뒤 통합한다

• 작업을 작은 단위로 나누고 서브에이전트나 에이전트 팀에 동시에 맡긴다. 웹사이트의 서로 다른 부분처럼 범위가 분리된 작업이 병렬 처리의 대상이 된다. [15:31]
• 로그아웃 버그 수정, 히어로 영역 개선, 피드백 폼 변경을 각각 진행한 뒤 병합 단계에서 합칠 수 있다. 각 작업이 끝날 때마다 다음 일을 지시하는 순차 방식의 대기 시간을 줄이는 구조다. [15:52]

10. 장기 세션은 검토한 인계 메모로 다시 시작한다

• 긴 대화에서는 앞서 금지한 방식을 나중에 원하는 예시로 제시하는 등 지시가 충돌할 수 있다. 이런 누적은 모델이 서로 맞지 않는 요구 사이에서 부적절한 절충을 하게 만들 수 있다. [17:15]
• 완료한 일, 결정이 필요한 사항, 다음 작업, 미해결 문제를 요약하게 한다. 요약의 오류를 사람이 바로잡은 뒤 새 세션에 전달해 현재 상태를 기준으로 이어 간다. [17:39]

11. 작업 중 짧은 질문은 /btw로 분리한다

• 체크아웃 흐름 리팩터링 같은 긴 작업을 맡기면 중간 상태를 파악하기 어려워질 수 있다. 작업 완료를 기다리거나 전체 대화를 다시 훑는 대신 /btw로 용어나 진행 내용에 관한 짧은 질문을 던질 수 있다. [18:42]
• 작업이 진행되는 동안 별도로 답을 받아 이해를 보완한다. 설명을 위한 질문이 주 작업의 컨텍스트에 섞이는 것을 줄이고, 확인에 걸리는 시간도 단축하는 용도다. [18:54]

12. 저비용 모델로 넓게 조사하고 강한 모델로 종합 판단한다

• 논문, 블로그, Reddit 등에서 기존 해결 방법을 조사하면 작업 품질을 높일 수 있지만 조사 비용이 커질 수 있다. 저렴한 모델로 탐색 범위를 넓히고 강력한 모델에 최종 판단을 맡기는 역할 분담이 대안이다. [20:02]
• 팬아웃·팬인 방식에서는 저비용 서브에이전트가 주제별 정보와 최신 접근법을 찾는다. 문헌에서 일반적으로 지지되지 않는 아이디어나 가설도 근거가 있는지 살핀 뒤, 조사 결과를 하나의 프롬프트로 모아 강력한 모델이 판단하게 한다. [20:40]

13. 상시 지침 파일의 오래된 정보를 갱신한다

• Claude용 지침 파일에 오래된 정보가 남으면 현재 상황과 맞지 않는 판단이 나올 수 있다. 수개월 전 수입과 포트폴리오 정보를 사용한 사례에서는 위험 감수 여력과 지출 가능 금액을 낮게 보고, 제안할 수 있는 상품이나 서비스도 제한적으로 판단하는 문제가 생겼다. [21:20]
• 지침 파일의 내용을 점검해 현재에도 관련 있는 정보만 유지한다. 불필요하거나 낡은 정보는 토큰 예산을 소모하고 판단을 흐릴 수 있으므로, 계속 전달할 가치가 있는 내용인지 확인한다. [21:37]

14. 모델별 지침을 갱신하고 대체 도구로 업무 연속성 확보하기

• 지침에는 프로젝트에서 무엇이 어디에 있는지 요약하고, 파일의 전체 경로 표시나 Python 사용 같은 선호를 담는다. 작업 자율성을 주되 불확실하면 질문하도록 정할 수 있으며, 작은 모델 업데이트가 있을 때도 claude.md와 시스템 프롬프트의 품질을 다시 점검해야 한다. [22:16]
• Claude Code는 장애가 발생할 수 있고, 모델·토큰 경제성에 따른 작업 품질 변동도 있다는 설명이다. 대체 수단이 없으면 업무가 막히므로 Claude Code를 주 도구로 쓰면서 Codex나 다른 모델을 예비 도구로 준비한다. [22:54]

15. 실패를 실행 가능한 지침으로 바꾸고 반복 작업 줄이기

• 오래된 API 호출이 반복해서 실패할 때 “이 API를 쓰지 말라”는 금지 사항만 추가하는 방식은 충분하지 않다. 문제와 함께 해결 방법을 기록하고, 별도의 예로 파일 읽기를 한꺼번에 처리하라는 구체적인 행동 지침을 남긴다. 평가 루프에서는 “더 적은 토큰으로 더 빠르게 처리할 방법”을 물어 개선점을 찾는다. [24:42]
• 개선점과 /insights 같은 도구에서 얻은 정보를 지침에 누적하면 반복 실수를 줄일 수 있다. 개인 경험상 이 방식으로 주당 3~4시간을 절약했으며, 작업 완료 후 파일을 열어 달라는 작은 지침도 시간을 줄였다. 앱 안에서 직접 탐색하기 어려운 터미널 환경에서는 이런 편의 지침이 특히 유용할 수 있다. [25:20]

🧾 결론

• 프롬프트의 가치는 가장 잘 나온 결과뿐 아니라 반복 실행에서 유지되는 품질로 판단해야 한다.
• 오래된 설명과 충돌하는 지시를 정리하고 검증 기준을 제공하는 일이 작업 품질을 좌우한다.
• 병렬화와 모델 분담은 시간·비용을 줄일 수 있지만, 작업 경계 설정과 결과 통합 검토가 필요하다.
• 제시된 방법과 절감 수치는 사용자의 경험에 기반하므로 자신의 업무에서도 같은 효과가 나는지 확인해야 한다.

📈 투자·시사 포인트

• AI 도입의 경제성은 모델 사용료와 함께 재작업, 대기 시간, 컨텍스트 비용까지 살펴야 한다는 시사점을 준다.
• 범용 연결 도구로 업무의 가치를 먼저 검증하고 반복 운영에 필요한 기능으로 좁히는 접근은 자동화 투자 순서를 정하는 데 참고할 수 있다.
• 저비용 조사와 고성능 종합 판단을 분리하는 방식은 업무 단계별로 모델 비용을 배분하는 운영 전략이다.
• 대체 모델과 동기화된 지침을 준비하는 것은 도구 장애로 인한 업무 중단에 대비하는 방법이다. 이 영상은 특정 자산의 투자 수익이나 기업 가치에 관한 근거를 제공하지 않는다.

⚠️ 불확실하거나 확인이 필요한 부분

• 입력 전 컨텍스트가 약 30% 사용된다는 설명은 개인적 추정이다. MCP 축소로 실행당 3~5초, 지침 개선으로 주당 3~4시간을 절약했다는 수치도 개인 경험이며 일반적인 성과로 볼 수 없다.
• 프롬프트를 10번 실행해 성공 횟수를 비교하는 방법은 실무 예시다. 7회에서 8회로 늘었다는 결과만으로 개선 효과가 안정적으로 재현된다고 단정하기는 어렵다.
• /compact의 도구 정의 압축 문제와 다른 에이전트용 지침 파일 지원 여부는 버전에 따라 달라질 수 있다. /btw 등 소개된 기능도 실제 사용 환경에서 확인해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복 업무 하나를 골라 성공 기준을 정하고, 같은 프롬프트의 10회 실행 결과를 수정 전후로 비교한다.
• 큰 작업을 시작할 때 목표·대상·참고 예시·완료 조건을 정하고, 수정 전에 문제 목록과 변경 범위를 확인한다.
• /context로 구성을 살펴 사용하지 않는 MCP·스킬을 정리하고, 지침 파일의 오래된 정보와 반복 실패의 해결 방법을 갱신한다.
• 긴 세션을 마칠 때 완료 사항·결정 대기 사항·다음 작업·미해결 문제를 요약하고, 사람이 오류를 바로잡아 새 세션에 전달한다.

❓ 열린 질문

• 우리 업무에서 성공 여부를 일관되게 판정할 기준은 무엇이며, 몇 번의 반복 평가가 필요한가?
• 범용 MCP를 맞춤형 스킬로 바꿀 만큼 반복 빈도와 경제성이 충분한 업무는 무엇인가?
• 병렬화로 줄어드는 대기 시간과 추가되는 통합·검토 비용의 균형은 어디에서 맞는가?