낭비되는 AI 크레딧은 모든 빌더의 어리석은 세금입니다. 대신 제가 하는 방법은 이렇습니다.

어떤 아침에는 다른 무엇보다 먼저 Claude 대시보드를 열어보곤 하는데, 리셋되기 몇 시간 전임에도 주간 크레딧의 15-20%가 그대로 남아 있는 것을 봅니다. 이미 지불한 크레딧입니다. 아무런 소득 없이 만료될 예정인 크레딧 말입니다.

대부분의 빌더들은 그 카운터가 0에 도달하는 것을 지켜봅니다. (어차피 그것들로 유용한 일을 할 계획은 없었을 테니까요, 그렇죠?)

저는 그 시간들을 다르게 사용합니다. 실제 프로젝트에 **자율 리팩토링 에이전트 (autonomous refactoring agent)**를 투입하고, 검증 가능한 종료 조건 (finish condition)을 부여한 뒤 다른 일을 하러 갑니다. 튜토리얼 프로젝트가 아닌 실제 운영 코드 (Live production code) 말입니다. 지난주에는 30분마다 업타임 (uptime)을 모니터링하는 118,000 라인의 TypeScript로 구성된 WooCommerce 카탈로그 백엔드 프로젝트를 진행했고, 또 다른 프로젝트로는 6개의 공급업체 통합 파일이 동일한 동기화 루프를 실행하는 프로젝트를 진행했습니다. 이 프로젝트는 6개 파일 전체에 걸쳐 약 500 라인의 코드가 복사되어 붙여넣기 되어 있었습니다. 설정은 Opus 4.8, /effort ultracode, /goal 이었습니다. 저는 두 가지를 모두 설정하고 떠났습니다.

요약하자면 (TLDR): 에이전트는 무언가를 "개선"하는 것이 아닙니다. 에이전트는 당신이 부여한 종료 조건 (finish condition)에 최적화될 뿐입니다. 모호한 조건은 모호한 결과를 낳습니다. 나쁜 프롬프트는 "완료"에 이르는 가장 짧은 경로를 찾아내는데, 그것이 때로는 잘못된 경로일 수도 있습니다. 🤓 이번 세션들은 바로 그 차이가 드러난 지점이었습니다.

Opus 4.8, /effort ultracode, /goal

이 세 가지 조합이 의미를 갖기 위해서는 먼저 분석이 필요합니다.

Opus 4.8은 xhigh 추론 (reasoning)과 호환되는 유일한 Claude 모델이며, 1M 토큰의 컨텍스트 윈도우 (context window)를 제공합니다. 118,000 라인의 TypeScript를 건네주며 스스로 길을 찾아내라고 명령할 때, 이 두 번째 특징이 매우 중요합니다.

/effort ultracode는 Claude Code의 세션 설정으로, v2.1.154로 5월 28일에 출시되었습니다. 이 설정을 활성화하면 xhigh 추론이 작동하고 **Dynamic Workflows(동적 워크플로우)**가 자동으로 가능해집니다. Claude는 어떤 하위 작업이 병렬 하위 에이전트(subagents)를 분산하여 처리할 가치가 있는지 스스로 결정합니다. 표준 장치에서 최대 16개, 실행당 최대 1,000개의 하위 에이전트가 동시에 작동할 수 있습니다. 일부 하위 에이전트는 문제를 독립적인 각도에서 공격하고, 다른 에이전트는 첫 번째 결과의 결론을 반박하려고 시도하며, 결과가 수렴할 때까지 반복합니다. **Adversarial verification(적대적 검증)**은 기본적으로 (절반의 그룹이 나머지 절반을 무력화시키기 위해 존재하는 급습팀과 같습니다). 중간 출력물은 메인 컨텍스트 창이 아닌 스크립트 변수에 저장되므로, 작업이 분산되어도 주 컨텍스트는 간결하게 유지됩니다. 저는 CLI(Command Line Interface) 네이티브 아키텍처가 AI 에이전트를 위한 MCP보다 왜 CLI가 우월한지에서 자율 에이전트에게 가능한 것을 어떻게 변화시키는지에 대해 깊이 파고들었습니다.

/goal은 v2.1.139 이상부터 사용 가능합니다. 일반 언어로 검증 가능한 종료 조건을 정의할 수 있습니다. 별도의 Haiku 인스턴스가 매 턴마다 세션 기록을 읽고 '예' 또는 '아니오'와 함께 1줄의 이유를 회신합니다. 만약 '아니오'라면, 그 이유가 Claude의 다음 지침이 됩니다. '예'라면, 목표가 달성되고 세션이 종료됩니다. /goal 없이 진행할 경우: 수동으로

공급업체 통합 세션: 404개 테스트 통과 (green). 코드베이스에 이미 존재하던 701개의 린트(lint) 에러는 첫 번째 변경 사항이 적용되기 전에 이미 집계 및 기록되었습니다.

이것은 선택적인 의례가 아닙니다. 자율 리팩터링 (autonomous refactoring)을 작동하게 만드는 메커니즘은 그것을 안전하게 만드는 메커니즘과 동일합니다. 즉, 에이전트 (agent)는 추상적인 '더 나은 코드'라는 개념이 아니라, 당신이 정의한 종료 조건 (finish condition)을 최적화합니다. 첫 번째 커밋 (commit) 전에 알려진 기준점 (baseline)이 설정되지 않으면, 최적화할 조건도 없고 변경 도중 무언가 깨졌을 때 되돌아갈 참조 상태 (reference state)도 없습니다. 기준점 (baseline)이 '그린 (green, 통과)'의 의미를 정의합니다. 세션 내의 모든 검증은 이 기준점을 지향합니다. 이를 건너뛰면 에이전트는 스스로 검증할 수 없는 변경을 수행하고, 중단하라는 지시가 없으므로 계속 진행하며, 당신이 차이점 (diff)을 확인했을 때는 이미 몇 시간 동안 작업이 진행되어 되돌릴 수 있는 깨끗한 경로가 없는 상태가 됩니다. 무언가를 건드리기 전에 기준점을 설정하는 데는 몇 분밖에 걸리지 않습니다. 이를 건너뛰는 것은 세션 전체를 망칠 수 있습니다.

스폰 지점 (spawn point)을 설정하지 않고 보스를 소환할 수는 없습니다. 기준점 (baseline)이 바로 그 스폰 지점입니다.

카탈로그 백엔드 (catalog backend)에서 관찰된 첫 번째 주목할 만한 동작은 다음과 같습니다: 에이전트가 단 한 줄의 코드를 작성하기 전에 코드베이스를 매핑하기 위해 병렬 서브 에이전트 (subagents)를 생성했습니다. 발견된 각 사항은 교차 검증을 위해 grep을 통해 다시 확인되었습니다. 그것은 단순히 코드를 훑어보는 것이 아니라, 논거를 구축 (building a case)하고 있었습니다.

검증에 관한 두 가지 순간

유령 에러 (Phantom error), 카탈로그 백엔드

컴포넌트 추출 도중 콘솔에 에러가 발생했습니다: CategoryEditor가 두 번 정의되었습니다. 즉시 롤백 (roll back)하고 싶게 만드는 종류의 에러였습니다.

에이전트는 타입 체크 (typecheck)를 실행했습니다. 깨끗했습니다. 코드베이스 내의 모든 중복 클래스 정의를 grep으로 검색했습니다. 발견된 것이 없었습니다. 브라우저에서 실제 페이지를 로드했습니다: 정상적으로 렌더링되었습니다.

그것은 개발 서버의 아티팩트 (artifact)였으며, 추출 과정 중 기존 모듈 경로와 새로운 모듈 경로 사이의 전환 과정에서 발생한 유령이었습니다. 다음 체크포인트 (checkpoint)에서 재시작하자: 에러가 0개가 되었습니다.

절차는 다음과 같습니다: 타입 체크 (typecheck), 그렙 (grep), 브라우저 렌더링 (browser render). 각 체크는 독립적입니다. 콘솔 에러는 2개의 독립적인 신호가 일치할 때까지는 노이즈일 뿐입니다. "컴파일이 된다"는 것은 라이브 테스트가 아닙니다. "터미널에서 한 번 에러가 떴었다"는 것도 마찬가지입니다.

잠시 옆길로 새자면: 공급업체 통합 (supplier integration) 세션 로그를 읽고 있는 동안, 한 클라이언트로부터 3개월 전 인보이스(invoice)에 대해 묻는 슬랙(Slack) 메시지를 받았습니다. 원본을 찾기 위해 이메일 스레드를 뒤지는 데 20분을 썼습니다. 그동안 에이전트(agent)는 40개의 파일을 처리했고 3개의 서브 에이전트 (subagents)를 병렬로 실행하고 있었습니다. 다른 종류의 처리량 (throughput)입니다.

배포 거부, 공급업체 통합 (Deploy refusal, supplier integration)

어느 시점에서 세션이 프로덕션 (production) 접근을 차단하는 가드레일 (guardrail)에 걸렸습니다. 에이전트는 이를 우회하려고 시도하지 않았습니다. 대신 테스트 스위트 (test suite)를 통해 가능한 부분을 검증하고, 핵심 변경 사항이 유지되었음을 확인한 뒤, 프로덕션 경로 없이 남은 범위(scope)에 대해 작업을 계속했습니다. 이것이 도구 (tool)와 부채 (liability)의 차이이며, 결코 작은 차이가 아닙니다.

에이전트가 건드리지 않기로 결정한 것들

카탈로그 백엔드 (catalog backend)에는 거의 동일해 보이는 2개의 슬러기파이 (slugify) 함수가 있었습니다. 자동 감사 (automated audit)라면 이를 명백한 병합 (merge) 후보로 표시했을 것입니다. 실제 코드를 읽어보니: 하나는 아포스트로피 (')를 다르게 처리하고, 다른 하나는 80자에서 자릅니다 (truncate). 이 둘의 차이는 외관상의 문제가 아닙니다. 어떤 제품이 어떤 URL을 갖게 되는가에 관한 문제이며, 해당 URL들은 이미 카탈로그 전체에 인덱싱 (indexed)되어 있습니다. 이를 병합했다면 경고 없이 라이브 제품 링크를 다시 작성하게 되었을 것입니다.

동일한 논리가 라이브 제품 레코드를 모두 다시 작성하는 메타데이터 파서 (metadata parser)의 5가지 변형 (variants)에도 적용되었습니다. 감사는 중복을 찾아냈습니다. 코드를 읽어보니 각 변형이 왜 존재하는지 알 수 있었습니다. 이들 사이에서 갈라지는 10%의 차이가 바로 라이브 데이터에서 중요한 바로 그 10%였습니다. 에이전트는 5개 모두에 플래그 (flag)를 표시하고, 아무것도 병합하지 않은 채 다음 단계로 넘어갔습니다.

Convex 백엔드는 판단하기 어려운 부분이었습니다. 이 백엔드는 단일 환경에서 실행되기 때문에 **개발(dev)이 곧 운영(prod)**입니다. 라이브 테스트를 하려면 프로덕션에 배포해야 합니다. 잠재적 이득은 미관상의 정리 정도였습니다. 하지만 위험성은 배포 없이는 검증할 수 없습니다. 에이전트는 이를 보류하고, 추적 파일에 기록한 후 그렇게 말했습니다. 솔직히 말씀드리자면, 실제 테스트 환경이 있어도 리팩토링(refactor) 자체가 가치가 있었을지는 모르겠습니다. 하지만 그것은 감독 없이 작동하는 에이전트가 아닌, 전체 맥락을 가진 인간의 판단 영역입니다.

공급업체 통합 세션은 여전히 334개의 lint 오류를 남긴 채 끝났습니다. 이 334개는 세션 시작 전부터 존재했던 것이며, 수백 개의 파일에 걸쳐 퍼져 있었습니다. 이것들을 일괄적으로 정리하려면 아무런 아키텍처적 이득 없이 모든 것을 건드려야 했을 것입니다. 오래된 마이그레이션 스크립트들은 작동하지 않는 것처럼 보였지만, 실제로는 비상시를 위한 수동 해치(manual emergency hatches)였습니다. 프로덕션이 불타고 자동 장애 복구 시스템이 작동하지 않을 때만 존재한다는 것을 기억하는 종류의 것이죠 (제가 어떻게 아는지 물어보세요). 에이전트는 저 대신 결정하기보다는 메모를 남기고 건너뛰었습니다.

'만족(Satisfied)'했다는 것은 모든 것을 만졌다는 의미가 아닙니다. 그것은 진짜 문제가 되는 부분들이 다루어지고 검증되었으며, 나머지 모든 것은 변경하기에 위험하거나 수정할 가치가 낮은 상태라는 뜻입니다. 추가적인 작업을 만들어내는 것이 성실함이 아니라 실패입니다.

상처를 입은 프롬프트 (The Prompt With Scars)

제가 카탈로그 백엔드 세션에 보낸 원래의 프롬프트에는 공백(gap)들이 있었습니다.

어디에도 프로덕션에 대한 언급이 없었습니다. 검증 가능한 엔드포인트가 없는 '만족할 때까지(Until satisfied)'라는 문구였습니다. 무엇을 기준으로 하는지 정의되지 않은 '라이브 테스트(Live-test)'도 있었습니다. 어떤 실제 Claude Code 명령어와도 일치하지 않는 '자동 검토(autoreview)' 지시사항이었습니다.

각 공백은 다르게 전개될 수 있었던 순간에 해당합니다. 슬러기화(slugify) 함수들은 병합되었을 것입니다. Convex 백엔드가 건드려졌을 수도 있습니다. 가짜 오류는 단일 확인되지 않은 신호에 대한 롤백(rollback)을 유발했을 수도 있습니다.

이 두 세션은 보존할 만한 무언가를 만들어냈습니다:

/goal 안전하고 점진적인 리팩터링 (refactoring)을 통해 이 프로젝트의 아키텍처 (architecture)를 개선합니다.
첫째: 프로젝트 자체의 체크/테스트/빌드/실행 명령 (package.json 스크립트, Makefile, justfile, CI 설정, README)을 찾아내고 녹색 베이스라인 (green baseline)을 구축합니다.
...

모든 구절은 그러한 기능이 없었던 세션에서 얻은 흉터입니다.

그것이 바로 프롬프트 계약 프레임워크 (the full prompt contracts framework)의 본질입니다. 단순히 구조를 위한 구조가 아니라, 무언가 잘못되었을 때 발생하는 제약 조건(constraints)에 관한 것입니다.

당신의 크레딧은 오늘 밤 만료됩니다

두 세션이 실제로 만들어낸 결과물은 다음과 같습니다:

Catalog 백엔드 (backend): 4개의 깔끔한 커밋 (commits), 비대해진 파일 2개 축소, 테스트 (tests) 303개에서 313개로 증가, 순수 -57 라인 감소. 운영 환경 (production)에서 깨진 부분 없음.

Supplier 통합 (integration): +288/-711 라인, 테스트 (tests) 404개에서 407개로 증가, 쓸모없는 504라인 컴포넌트 (component) 제거, 린트 (lint) 에러 701개에서 334개로 감소.

이 방법에 대해 더 깊이 알고 싶다면, _Vibe Coding, For Real_에서 AI로 실제 프로젝트를 출시하는 단계별 접근법을 다룹니다. Kindle Unlimited에서 무료로 볼 수 있습니다.

당신의 리셋 (reset)이 다가오고 있습니다. 대시보드 (dashboard)에 쌓여 있는 크레딧은 이미 지불된 것입니다.

프로젝트의 아키텍처 (architecture)를 개선하는 것이 만료 예정인 크레딧을 사용하는 가장 좋은 방법입니다.

출처

• Keep Claude working toward a goal, Claude Code 공식 문서
• Claude Code Ultracode: What It Does, When to Use It, and How to Control Cost, Vibe Coding Academy
• What Is "ultracode" Mode in Claude Code?, BitsMinds
• Claude Code /goal: Set a Finish Line, Walk Away, FindSkill.ai

이 포스트에는 제휴 링크(affiliate links)가 포함되어 있을 수 있습니다. 해당 링크를 클릭하시면 저에게 소정의 수수료가 지급될 수 있습니다 (사용자에게 추가 비용이 발생하지 않으며, 제가 매일 여러분의 즐거운 독서를 위해 양질의 글을 계속 발행할 수 있도록 도와줍니다).