/scratchpad을 추천했다가 /note로 옮기게 된 이유

이 글은 바이브 가이딩 (vibe guiding)으로 시작하여 효율성 감사 (efficiency audit)로 이어진 시리즈의 세 번째 포스트입니다. 두 달 전, 저는 네 가지 기술 루프 (four-skill loop)를 설명했습니다: /start-issue가 /scratchpad를 작성하고, /tackle-scratchpad-block이 한 번에 한 단계씩 실행하며, 상태 플래그 (status flags)가 대기 (pending)에서 완료 (done)로 전환되고, /finish-issue가 배포된 내용을 읽어 PR 제목과 설명을 작성하는 방식입니다.

왜 마음을 바꿨는가
동기는 토큰 소비 (token consumption)였습니다. 회사는 각 팀에 AI 도구 사용량 대시보드를 제공했는데, 저는 항상 제 팀에서 가장 많은 사용량을 기록했고 부서 차트에서도 상당히 높은 위치에 있었습니다. 그때 저는 제가 무엇을 만드느냐가 아니라, 도구를 어떻게 사용하느냐의 문제일지도 모른다는 의심을 하기 시작했습니다. /scratchpad의 JSON 단계 블록 (JSON step block)과 /tackle-scratchpad-block 체인은 모든 작업에 동일한 의식적 비용 (ceremony tax)을 지불하게 했습니다: 전환을 위한 상태 플래그, 검증을 위한 JSON, 파싱을 위한 펜스 블록 (fenced block). 몇 시간에 걸친 작업에는 유용한 스캐폴딩 (scaffolding)이었지만, 매 세션마다 제가 지불해야 하는 오버헤드 (overhead)였습니다. 만약 제 프로세스가 대시보드 상위권의 원인이라면, 이를 재검토하는 것이 제가 실행할 수 있는 가장 저렴한 실험이었습니다.

일단 살펴보기 시작하자, 중복성은 단순히 scratchpad 대 note의 문제만이 아니었습니다. 복합 기술 (composite skills)이 생성하는 템플릿들 — 즉 /start-issue, /start-side-quest, /tackle-pr-comment, /finish-issue가 출력 문서에 작성하는 내용들 — 은 불필요한 무게를 가지고 있었습니다. PR 130으로 이어진 감사 (audit)의 몇 가지 예시는 다음과 같습니다:

수정할 파일 (Files to Modify): 이미 계획 (Plan) 단계에서 명시된 정보를 파일별로 재그룹화한 것에 불과했습니다.

문서화 및 발견 가능성 (Documentation & Discoverability): /finish-issue가 마무리 단계에서 이미 체계적으로 재도출하는 내용을 미리 채워둔 체크리스트였습니다.

수락 기준 (Acceptance Criteria): Claude가 이미 컨텍스트에 가지고 있는 이슈 본문에서 기준을 그대로 복사해온 것이었습니다.

왜 이것을 분리했는가 (Why Split This Out): 지금까지 생성된 모든 사이드 퀘스트 (side-quest)와 일치하는 세 개의 하드코딩된 불렛 포인트였습니다.

이 각각은 개별적으로 보면 작았습니다. 하지만 누적되면 기술 (skill)이 실행될 때마다 지불해야 하는 세션당 추가 세금 (per-session surtax)이 되었습니다.

/scratchpad 대신 /note를 기본값으로 설정한 것이 단일 항목으로는 가장 큰 변화였지만, 변화의 패턴은 더 광범위했습니다. 즉, LLM이 동일한 정보를 서로 다른 형태와 서로 다른 문서에 두 번 작성하게 만드는 것을 중단하는 것이었습니다. Claude 자체도 그 몇 달 사이에 변화했습니다. 제가 이 주제에 대해 처음 글을 썼을 당시에는, 매 단계마다 가해지는 엄격한 제약(hard stops)이 당시의 Claude에게는 타당했습니다. 하지만 PR 130이 반영될 무렵, Claude는 하나의 이슈(issue) 전반에 걸쳐 다단계 자기 조직화 (multi-step self-organization) 능력이 눈에 띄게 향상되었습니다. 덕분에 저는 경계심을 조금 낮출 수 있었습니다. 제가 처음에 취했던 통제광 (control-freak) 같은 태도는 더 이상 필요하지 않았습니다. 만약 수동으로 검토하고 커밋 (commit)할 명시적인 체크포인트 (checkpoint)가 필요하다면, 생성된 /note 에 단순히 단계를 추가하기만 하면 되었습니다. 병렬성 (Parallelism) 또한 변화했습니다. Claude는 단일 세션 내에서 워커 (workers)를 확장하고 에이전트 (agents)를 병렬로 실행하는 능력을 갖추게 되었습니다. 이는 독립적인 요소들이 포함된 이슈의 경우, Claude가 제가 /tackle-scratchpad-block 체인을 통해 이끌어주는 것보다 더 빠르게 스스로 처리량 (throughput)을 조직할 수 있음을 의미했습니다. 한때 안전을 더해주었던 제약 사항들이 이제는 지연 시간 (latency)을 유발하기 시작했습니다. /tackle-scratchpad-block 으로 제약을 거는 것은, 더 많은 통제를 요구함으로써 Claude의 속도를 늦추는 일이었습니다.

어떤 /note가 생겼는지 봅시다. /scratchpad의 ## Implementation Plan 섹션은 상태 필드, 의존성 배열, 작업 목록을 가진 펜스드 JSON 블록입니다: { "finish_issue_on_complete" : false , "steps" : [ { "id" : "S001" , "title" : "토큰 라이브러리 교체" , "status" : "pending" , "done_when" : "Old lib removed from package.json, new one imported and passing existing tests" , "depends_on" : [], "files" : [ "package.json" , "src/auth/token.ts" ], "tasks" : [ "npm install new-token-lib, npm remove old-token-lib" , "Update src/auth/token.ts imports" , "Run the token test suite" ] }, { "id" : "S002" , "title" : "새 토큰 API에 맞게 호출자 업데이트" , "status" : "pending" , "depends_on" : [ "S001" ], "files" : [ "src/middleware/auth.ts" , "src/routes/login.ts" ], "tasks" : [ "Update verifyToken() call sites to new API shape" , "Run full test suite" ] } ] } 반면, /note의 ## Plan 섹션은 스캐폴딩(scaffolding) 없이 동일한 정보를 담고 있습니다: 1. 토큰 라이브러리 교체 — npm install new-token-lib, import 업데이트, 토큰 테스트 스위트 실행 2. 새 토큰 API에 맞게 호출자 업데이트 — verifyToken() 호출 사이트, 전체 테스트 스위트 펜스드 JSON 블록이 없습니다. 상태: pending도 없습니다. 이 계획은 무엇을 어떤 순서로 할지 말해주고, LLM(대규모 언어 모델)이 세션 내에서 자체적으로 실행합니다. 원래 워크플로우의 하드 스톱(hard stops)은 여전히 존재합니다: 저는

이는 동일한 프로젝트에서 두세 개의 워크트리(worktrees)를 동시에 다룰 때 특히 유용합니다. 반복적인 커밋(iterative commits)과 단계 추적(step tracking)은 제 주의력이 병렬 브랜치(parallel branches)들로 분산될 때 방향을 잡을 수 있게 도와줍니다. 제가 얻은 결론은 다음과 같습니다: /note 흐름은 여전히 어떤 일이 일어나기 전에 계획 검토(plan review)를 위해 멈추며, 그 후 LLM에게 더 많은 자율성을 부여하여 작업을 확장(fan out)하고 더 빠르게 움직일 수 있게 합니다. /scratchpad 흐름은 여전히 강력하지만, 파리를 잡기 위해 항상 바주카포가 필요한 것은 아닙니다. 대부분의 날에는 더 가벼운 도구만으로도 충분하며, 기분 좋게 마무리할 수 있습니다. 만약 이미 이 기술들을 사용 중이라면: 리포지토리(repo)에서 최신 내용을 가져온(pull) 후 ./setup.sh를 실행하여 업데이트된 세트를 심볼릭 링크(symlink) 하세요. /start-issue는 다음 호출 시 /note를 생성할 것입니다. 그 외 다른 것은 변경되지 않으며, 나머지 루프(loop)는 그대로 유지됩니다. 이전 동작을 원한다면 --scratchpad를 입력하세요. 이 글은 본문에서 설명하는 것과 동일한 기술을 사용하여 이슈(issue) #139부터 작성되었습니다. 이번 계획은 노트(note)였습니다.