저는 Opus 4.8 Ultracode(이전에는 Fable 사용)를 사용하여 Pro 플랜에서 매우 간단한 게임을 바이브 코딩(vibe coding)하고 있습니다. 2주간의 경험을 통해 토큰 사용량을 심각하게 줄여준다고 증명된 몇 가지 학습 내용을 공유합니다.
제가 여기서 발견한 아이디어들과, 추천된 Git 저장소들을 읽고 그 일부를 적용하며 얻은 다른 아이디어들을 몇 가지 빠른 팁으로 공유하고자 합니다.
1- 필요하지 않은 기능은 Claude 설정(전역 효과)에서 비활성화하거나, 각 프로젝트별로 특정된 settings.json 파일을 통해 비활성화하세요.
이는 Claude Code 세션을 처음 시작할 때 구축되는 컨텍스트 윈도우(context window)를 줄임으로써 큰 도움이 되는 것으로 보입니다. 저는 다음과 같이 사용합니다:
"deniedMcpServers": [
{"serverName": "computer-use"},
{"serverName": "Claude_in_Chrome"},
{"serverName": "Claude_Preview"},
{"serverName": "scheduled-tasks"},
{"serverName": "mcp-registry"},
{"serverName": "ccd_session_mgmt"}
]
2- 덜 복잡한 기능과 범위가 정해진 작업에는 에이전트 핸드오프(Agent handoff)를 사용하세요. Sonnet이 작업을 잘못 처리하여 기능 하나에 20만 개의 토큰을 추가로 낭비했기 때문에 이 부분에 대해 잠시 실험을 거쳐야 했습니다. 현재 제 claude.md에는 다음과 같이 작성되어 있습니다:
토큰 / 모델 정책 (Token / model policy)
- 구현 노가다(boilerplate, 테스트 작성, 콘텐츠 입력): \model: sonnet\ 또는
haiku (.claude/agents/)의 서브 에이전트(subagents)에게 위임하세요. 한 번에 전체 기능을 위임하지 말고, 점진적으로 위임하세요. 단위는 이미 고정된 계약(rule 8) 내에 있어야 하므로, 브리프(brief)는 상세할 수 있으며(파일, 시그니처, 데이터, 테스트 케이스), 설계적 판단을 남기지 않아야 합니다. 만약 통합 지점(integration point)이 아직 고정되지 않았다면, 먼저 인라인으로 탐색한 다음 연결 작업을 위임하세요. 항상 독립적으로 검증하세요. 에이전트의 자기 보고(self-report)를 신뢰하지 마세요.
- 오케스트레이터(Orchestrator)는 취향이 아닌, 명세서의 수락 기준(acceptance criteria)에 따라 diff를 검토합니다.
- 훅(Hooks)은 수정 후 린터(linter) + 테스트를 실행합니다. 훅이 잡아낼 수 있는 것에 대해 오케스트레이터 검토 시간을 소비하지 마세요.
- 주기적인 아키텍처 감사 (ultracode/x-high effort): 명시적인 요청이 있을 때만, 대략 한 단계(phase)당 한 번 수행합니다.
참고로, rule 8은 다음과 같습니다:
8.
복잡도가 높은 사양(spec)은 하나의 브랜치에서 점진적으로 배포합니다. 사양에 약 4개 이상의 독립적인 수락 기준(acceptance criteria)이 있거나, 상태(state) + UI + 시스템 간 결합(cross-system coupling)을 아우르는 경우, 한 번의 세션에서 이를 구축하지 마십시오. 먼저 사양 내에 스키마/명명 계약(schema/naming contract)(데이터 필드 이름, 하위 객체 API, 시그널(signals) — 다른 사양이 재사용할 안정적인 인터페이스)을 확정합니다. 그런 다음 단일 feature/<spec> 브랜치에서 커밋당 하나의 기준 클러스터(criterion-cluster)를 구축하며, 다음 단계로 넘어가기 전 각 단계를 통과(green)시키고, 중간에 /clear를 수행합니다. 어떤 세션에서도 재개할 수 있도록 NEXTSTEPS.md에 증분 기록(완료된 사항 / 다음 사항)을 유지하십시오.``
- 매우 짧은 세션을 유지합니다(수시로
/clear를 할 수 있어 토큰을 절약할 수 있습니다). 이를 위해서는 다음이 필요합니다: 무엇을 구축할지에 대한 명확한 계획, 모든 단계와 사양에 대한 적절한 문서화(로드맵 / 체크리스트), 그리고 Claude에게 직접 생성해 달라고 요청할 수 있는 "nextsteps.md" 시스템입니다.
사양이나 단계가 완료될 때마다, 모든 테스트가 통과(green)되고 커밋/푸시(commit/push)되었다고 가정하면, 해당 단계나 사양의 다음 작업을 담은 Nextsteps.md가 생성됩니다.
이렇게 하면 많은 토큰을 절약할 수 있으므로, /clear를 한 뒤 Claude에게 해당 md 파일을 읽으라고 요청하고 바로 진행하면 됩니다. 그렇지 않으면 Claude가 프로젝트 파일의 대부분을 훑게 됩니다.
솔직히 저는 5시간 세션 제한당 3~4배 더 많은 작업을 처리하고 있습니다.
운이 좋으면, 저는 그냥 /clear를 하고 Claude에게 nextsteps를 열고 작업을 시작하라고 말합니다. 모든 것(코드, 테스트, 커밋, 푸시)이 정상 작동한다고 가정하면, Claude가 이를 한 번에 처리하고 다시 nextsteps를 생성한 뒤 /clear를 합니다. 대부분의 경우 100k 토큰 미만으로 작업이 완료됩니다.
저는 Godot MCP를 사용하지 않고 있으며(Claude가 어떤 이유에서인지 권장하지 않았습니다), 각 단계를 승인하고 다음 단계로 넘어가기 위해 초고성능 코드 아키텍처 감사(ultracode architecture audits)를 실행하기 전에 복잡한 기능에 대해서는 직접 인게임 테스트를 수행합니다.
코딩 배경지식이 거의 없는 사람(저는 20년 전에 약간의 C#, C++, lua를 알았습니다)에게 도움이 되는 또 다른 점은, Opus가 많은 것을 설명하며 진행하기 때문에 그 과정을 읽는 것입니다. 물론 이를 싫어하는 사람들도 있다는 것을 알고 있습니다...
저는 계속 읽으면서 토큰 수를 확인하고 있습니다.
저는 언제 토큰 사용량이 급증하는지 파악하는 데 익숙해지고 있으며, 제가 이의를 제기하면 그는 무슨 일이 일어났는지 설명하고 해결책을 제안하는 데 매우 뛰어납니다. 다만, 약간의 지연이 있는 것 같아서 토큰 추적 (token tracking)이 실시간으로 이루어진다면 도움이 될 것 같습니다!
submitted by /u/Common-Suit4816
[link] [comments]