프로젝트 개발 중 Claude 계정 3개를 돌려쓰다가,
토큰이 아니라 내 사용 방법에 문제가 있지 않을까 의문을 가지게 되었고,
갖가지 방법들을 시도하여 성공적으로 Claude를 다루게 된 과정에 대한 기록.
Claude Code?
여러 프로젝트를 다루며 LLM을 통해 개발을 하게 되었다.
처음엔 무료 사용량이 어느 정도 제공되고 범용성이 좋은 ChatGPT, 대학생 전용 1년 무료인 Gemini를 통해 개발을 시작했다.
간단한 규모에서는 코드 짜달라고 하면 짜주고, 에러를 붙여넣으면 고쳐주는 ChatGPT, Gemini가 편리했다.
그런데 프로젝트 규모가 조금씩 커지게 되고, 파일이 여러 개로 쪼개지기 시작하며
"파일 전체 복사해서 붙여넣기 → 수정 요청 → 다시 복사해서 내 파일에 덮어쓰기"를 반복하는 과정에서 개발의 비효율성을 느끼기 시작했다.
그러다 코딩에 좋다고 소문이 난 Cursor를 접하게 되었다.
그리고 그 결과는 충격적이었다.
몇 주 동안 질질 끌던 작업들을 체험판 단 3일 만에 끝낼 수 있었다.
IDE에 LLM이 통합되어, 파일 복붙 없이 코드베이스 전체를 이해한 채로 작업이 가능하다는 게 얼마나 효율적인지 느낀 뒤로 LLM이 통합된 개발 도구에 더 관심이 생겼다.
본격적으로 CLI 기반 LLM을 사용하고 싶었다. 구독에는 돈이 들기 때문에 내 돈을 합당하게 가져갈 이 분야 최고의 도구를 찾아나섰다. 그리고 코딩 분야에서는 Claude Code가 최고라는 소문을 들을 수 있었다. 문득 Cursor와의 차이가 무엇인지 궁금해졌다.
| 항목 | Cursor | Claude Code |
|---|---|---|
| 실행 환경 | VS Code 기반 IDE | 터미널 (CLI) |
| 편집기 종속 | O (VS Code 전용) | X (편집기 무관) |
| 컨텍스트 제어 | 자동 (불투명) | 수동 (직접 지정) |
| 프로젝트 지시 관리 | .cursorrules | CLAUDE.md |
| 서브에이전트 | 미지원 | 지원 |
| 외부 도구 연결 | 제한적 | MCP 프로토콜 |
| 진입장벽 | 낮음 | 상대적으로 높음 |
| 커스터마이징 | 제한적 | 높음 |
| 성격 | 완성된 제품 | 설계 가능한 도구 |
정리하자면,
Cursor는 IDE에 종속되는 구조였다.
VS Code 기반이라 다른 편집기와 함께 쓰기 불편했다.
(자바 기반의 프로젝트를 할 때, IntelliJ를 사용했기 때문에 두 앱을 번갈아 사용해야 했다.)
반면,
Claude Code는 터미널에서 돌아가니까 편집기를 가리지 않았고, 내가 컨텍스트에 무엇을 넣을지 직접 결정할 수 있었다.
(물론 더 편리한 부분과 차이점이 있었지만 이미 Claude를 글쓰기나 코딩에 이용하며 신뢰를 가진 상태였기 때문에 가볍게 살펴본 뒤 막연하게 Claude Code 또한 좋겠다고 생각하고 넘어갔다.)
토큰 문제
그렇게 Claude Code를 쓰기 시작했고, 개발 속도는 확실히 올라갔다.
마침 CJ 올리브네트웍스 부트캠프인 CloudWave에서 프로젝트를 시작하게 되어서 개발에 유용하게 사용할 수 있었다.
그런데 문제가 생겼다.
토큰이 내 예상보다 빠르게 닳았다.
처음엔 "프로젝트를 시작하면서 처음부터 제작하기 때문에 단순히 많이 드나보다" 하고 넘겼는데, 한도 초과가 반복되고, 토큰 재사용 시간을 기다리는게 일상이 되었다.
프로젝트 마감이 가까워지면서는, 다른 작업을 하고 있는 팀원의 계정 2개를 빌려 총 3개의 계정으로 토큰을 한계까지 돌려써가면서 작업했다.
A 계정 한도 차면 B로, B 차면 C로. 당시엔 그게 최선인줄로 알았다.
토큰이 너무 적다고 불평하던 와중, 문득 이런 생각이 들었다.
토큰이 문제가 아니라, 내 사용 방법이 문제 아닐까?
원인부터 찾았다
프로젝트 마감까지 시간은 촉박했기에, 막연하게 "덜 써야겠다"는 결론은 내릴 수 없었다. 토큰이 왜 이렇게 빨리 닳는지 원인을 먼저 파악해야 했다.
그리고 몇 가지 원인을 찾을 수 있었다.
첫째, 긴 대화가 누적되면 이전 대화 전체가 매 요청마다 컨텍스트로 들어간다.
채팅창을 닫지 않고 계속 이어가면, Claude는 처음부터 지금까지의 모든 대화를 매번 읽고 답한다. 대화가 길어질수록 요청 한 번에 소모되는 토큰이 기하급수적으로 늘어난다.
둘째, CLAUDE.md에 수백 줄짜리 프롬프트를 때려박으면 매 세션마다 전부 로드된다.
정성껏 작성한 지시사항이 오히려 독이 된다. 쓸 때마다 전부 토큰으로 소모되는 구조였다.
셋째, 계획 없이 구현을 요청하면 수정 반복이 발생한다.
"이렇게 만들어줘 → 아 이건 아닌데 → 저렇게 바꿔줘 → 다시"를 반복하면 토큰이 2~3배로 낭비된다.
넷째, 필요 없는 파일까지 컨텍스트에 포함된다.
관련 없는 파일을 통째로 넘기면 Claude는 그걸 전부 읽는다.
토큰을 많이 쓴 게 아니라, 비효율적으로 쓰고 있었던 거였다.
Claude Code는 이미 에이전트 프레임워크다
원인을 파악하고 나서 해결책을 찾는 과정에서 중요한 사실을 하나 깨달았다.
많은 사람들이 Claude Code 위에 또 다른 제어 로직을 얹으려 한다. 복잡한 프롬프트 체인을 만들거나, 외부 스크립트로 동작을 제어하거나. 그런데 이건 이중 레이어 구조로 오히려 비효율적이다. Claude Code 자체가 이미 에이전트 프레임워크로 설계되어 있기 때문이다.
네이티브 기능만 제대로 써도 충분하다.
| 기능 | 설명 | 토큰 절약 효과 |
|---|---|---|
| Progressive Disclosure | 필요한 스킬만 그때그때 로드 | 불필요한 컨텍스트 차단 |
| Context Forking | 서브에이전트 실행 시 컨텍스트 격리 | 메인 컨텍스트 오염 방지 |
| 네이티브 구조 | .claude/agents·skills·rules/ | Anthropic 업데이트 즉시 수혜 |
커스텀 레이어를 쌓는 대신, 이 구조를 따르는 것만으로도 강력한 에이전트 운영이 가능하다.
토큰을 아끼는 워크플로우
그리고 핵심적인 관점 전환이 있었다.
"코드를 잘 쓰게 만드는 것이 아니라, 코드를 쓰기 전에 무엇을 써야 하는지를 확실하게 만드는 것"
토큰 낭비의 근본 원인은 잘못된 방향으로 구현한 뒤 수정을 반복하는 것이다. 이 사이클을 끊으면 토큰은 자연히 줄어든다. 그래서 5단계 워크플로우를 정착시켰다.
Step 1 - Research
이 [폴더]를 깊이 읽고 세부 사항 파악 후 research.md에 작성해라채팅으로 주고받지 않고 파일로 저장한다. 컨텍스트가 오염되지 않는다. "깊이", "세부 사항" 키워드가 없으면 Claude는 고수준 요약으로 끝낸다. 사전 리서치가 잘못된 구현으로 인한 수정 반복 사이클을 차단한다.
Step 2 - Plan
research.md 바탕으로 plan.md에 구현 계획 작성해라. 아직 구현하지 마.plan.md에는 접근 방식, 코드 스니펫, 파일 경로, 트레이드오프, 체크리스트가 들어간다. Claude Code 내장 플랜 모드 대신 MD 파일을 쓰는 이유는 에디터에서 직접 편집할 수 있기 때문이다. 의사결정을 이 단계에서 완료하면 구현 중 방향 전환이 없다.
Step 3 - Review
plan.md를 에디터에서 열고 직접 주석을 단다.
<!-- PUT이 아니라 PATCH여야 함 -->
<!-- 캐싱 불필요, 제거 -->
<!-- 이 함수 시그니처 변경 불가 -->피드백 후에는 반드시 이렇게 요청한다.
메모 반영해서 업데이트해라. 아직 구현하지 마."아직 구현하지 마"는 필수 문구다. 없으면 Claude는 즉시 구현을 시작한다.
Step 4 - Implement
plan.md대로 전부 구현해라.
완료 시 체크리스트 체크. 매 단계 타입 체크 실행.이 단계에서 개발자의 역할은 설계자(Architect)에서 감독자(Supervisor)로 바뀐다. 이미 확정된 계획을 실행하는 것뿐이라 토큰 낭비 없는 직선 경로로 끝난다.
Step 5 - Refine
UI 오차가 있으면 말 대신 스크린샷을 넘긴다. 말로 설명하다 생기는 오해를 없애준다. 방향이 완전히 틀어졌다 싶으면 git reset 후 재시작한다. 반복되어 덧칠되는 수정을 반복하는 것보다 토큰도 결과물 퀄리티도 낫다.
스킬 시스템으로 반복을 없앴다
워크플로우를 정착시키고 나서 한 가지가 더 거슬렸다. 반복되는 작업마다 같은 설명을 매번 해야 한다는 것.
그래서 스킬 시스템을 구축했다.
스킬은 특정 상황에서만 로드되는 전문 매뉴얼이다.
평소엔 컨텍스트에 없다가, 관련 요청이 들어올 때만 동적으로 로드된다.
평소 → 메모리에 없음 (토큰 0 소비)
관련 요청 감지 → description 키워드 매칭 → 자동 로드직접 구축한 구조는 이렇다.
~/.claude/skills/skill-creator/
├── SKILL.md ← 트리거 + 핵심 요약
└── references/
└── skill_creator.md ← 상세 가이드 (필요 시만 로드)"스킬 만들어줘", "스킬 검토해줘", "스킬이 안 불러와져" 같은 말이 나오면 자동으로 로드된다.
반복 작업 패턴을 스킬로 등록하면 매번 설명할 필요가 없어진다.
최종 셋업
결국 정착한 파일 구조는 이렇다.
~/.claude/
├── rules/
│ └── guidelines.md ← 매 세션 자동 로드 (2.7KB, 61줄)
└── skills/
└── skill-creator/
├── SKILL.md
└── references/
└── skill_creator.md
프로젝트별 작업 파일:
├── research.md ← 코드베이스 분석 결과
├── plan.md ← 구현 계획 + 체크리스트
└── skill_creator.md ← 스킬 제작 상세 전략guidelines.md는 매 세션마다 자동으로 로드되어 프롬프트 품질을 실시간으로 진단한다.
| 감지 패턴 | 문제 | 대응 |
|---|---|---|
| 계획 없이 구현 요청 | 잘못된 방향 위험 | Step 1~3 먼저 제안 |
| "더 좋게 해줘" | 기준 없음 | 구체적 기준 요구 |
| 범위 과대 요청 | 누락·오류 | 분리 제안 |
| CLAUDE.md 긴 프롬프트 | 토큰 낭비 | 네이티브 구조 유도 |
결론
위 과정을 거친 뒤, 계정 3개로 돌려써야 겨우 가능했던 작업들을 계정 1개로 감당할 수 있었다.
또, plan.md 파일을 만들고 구현하기 시작하니까 구현 후 수정 반복이 거의 사라졌다. 같은 작업에 드는 대화 턴 수가 눈에 띄게 줄은 것을 체감할 수 있었다.
결과적으로, 3가지로 정리할 수 있었다.
확실한 구조가 토큰을 아끼는 방법이다.
잘못된 구현 후 수정 반복이 토큰의 가장 큰 낭비다. Research → Plan → Review가 이 사이클을 차단한다.
네이티브를 이기려 하지 마라.
Claude Code는 이미 프레임워크다. 그 위에 중복 레이어를 쌓는 건 역효과다. 공식 구조를 따를수록 Anthropic 업데이트 혜택을 즉시 받는다.
방법론이 도구보다 오래간다.
모델이 바뀌어도 "계획 → 검증 → 실행"의 구조는 어떤 LLM에도 그대로 적용된다. GPT-5가 나오든 Gemini Ultra가 나오든 상관없다.
이번 과정을 통해
도구를 탓하기 전에 도구를 어떻게 쓰고 있는지를 먼저 봐야 한다는 것을 깨달았다.
좋은 개발자는 코드를 많이 쓰는 사람이 아니라, 잘못된 코드를 쓰지 않도록 사고하는 사람이라고 생각한다.
나는 도구를 소비하는 개발자가 아니라, 문제와 구조를 설계하는 엔지니어가 되기 위해 노력할 것이다.
