왜 긴 세션은 '조종'이 필요한가
짧은 작업은 프롬프트를 넣고 결과를 지켜보면 끝난다. 하지만 열 몇 개 파일에 걸친 리팩터링이나 새 기능 구현처럼 몇 시간이 걸리는 작업은 다르다. 게다가 올바른 방향으로 계속 잡아 줄수록 오히려 시간이 더 걸릴 수도 있다. 그래서 긴 세션에는 '맡겨 두기'가 아니라 '조종하기'가 필요하다.
조종의 핵심 습관은 두 가지다. 첫째, Claude가 시작하기 전에 작업 범위를 좁힌다(scope). 둘째, 진행되는 동안 방향을 잡아 준다(steer). 아래 여섯 도구가 이 두 습관을 실제로 가능하게 해 준다 — Plan Mode, Compact, Rewind, Goal, Loop, 그리고 Worktree다.
시작 전 범위 좁히기 — Plan Mode

Plan Mode(플랜 모드)를 켜면 Claude는 파일을 고치지 않고 읽기 전용으로 코드를 조사한 뒤, '무엇을 어떻게 하겠다'는 계획을 만들어 건넨다. 계획이 나오면 반드시 그것을 끝까지 읽어 본다. 계획이 촘촘할수록 이후 실행 단계에서 삐끗할 여지가 줄어든다.
계획을 고치고 싶으면, 원하는 자리에 내용을 추가해 달라고 Claude에게 그냥 말하면 된다. 무작정 잘되기를 바라며 실행부터 시키는 것보다, 계획 단계에서 몇 번 다듬는 편이 훨씬 빠르고 안전하다.
컨텍스트를 비우며 방향 유지 — Compact

Compact는 지금까지의 대화를 요약해 그것을 새 컨텍스트로 삼고, 옛 대화는 지워 컨텍스트 창(context window)을 확보한다. 긴 세션에서 대화가 쌓여 무거워질 때 유용하다. 다만 위험이 하나 있다 — 요약 과정에서 중요한 무언가가 빠지면 Claude가 엉뚱한 방향으로 흐를 수 있다.
그래서 compact 명령을 쓸 때는 '무엇을 남기고 무엇을 버릴지'를 함께 지시한다. 명령 뒤에 지시를 덧붙이면 Claude에게 어떻게 요약할지를 알려 주는 셈이다. 예를 들어 디버깅은 한참 전에 끝났고 지금은 API 변경에만 집중하고 싶다면, 바로 그렇게 지시해 디버깅 로그는 버리고 API 변경만 남기게 할 수 있다.
잘못 갔을 때 되돌리기 — Rewind

Claude가 잘못된 길로 들어섰을 때, 프롬프트로 억지로 빠져나오려 애쓸 필요가 없다. Rewind가 마지막 체크포인트로 되돌려 준다. 여는 방법은 빈 프롬프트에서 ESC를 두 번 두드리는 것이다 — 그러면 rewind 메뉴가 뜬다. 사용자가 넣은 모든 프롬프트가 하나의 체크포인트가 되어, 그 지점으로 되돌아갈 수 있다.
선택지는 여러 가지다. 코드만, 대화만, 또는 둘 다 복원할 수 있다. 'Summarize from here'는 체크포인트 이후의 모든 것을 요약한다 — 곁길로 샌 대화를 정리해 공간을 비우고 싶을 때 좋다. 반대로 'Summarize up to here'는 체크포인트 이전의 모든 것을 요약한다 — 긴 준비 단계는 요약해 접고, 실제 구현 부분은 그대로 남기고 싶을 때 유용하다.
완료 조건을 맡기기 — Goal

지금까지가 '내가 손을 대고 조종하는' 방식이라면, 조금 더 자율적으로 맡기고 싶을 때 쓰는 것이 Goal이다. Goal은 완료 조건을 설정한다. '끝난 상태'가 어떤 모습인지 묘사해 두면, Claude는 스스로 끝났다고 여기는 첫 순간에 멈추지 않고, 빠른 평가자(evaluator)가 그 조건이 충족됐다고 확인할 때까지 여러 턴에 걸쳐 계속 일한다.
예를 들어 'src/billing의 모든 테스트가 통과하고 타입 체커가 오류 0을 보고할 때'처럼 조건을 걸 수 있다. 취소하려면 goal을 비우면 된다. 한 가지 제약이 있다 — 평가자는 대화 기록(transcript)만 읽는다. 그래서 조건은 Claude가 만들어 내는 출력, 예컨대 실제로 돌린 테스트 결과로 확인 가능한 것이어야 한다.
외부 상태를 지켜보며 반응 — Loop

Loop는 프롬프트를 턴과 턴 사이에 일정 간격으로 반복 실행한다 — 간격은 고정할 수도, 스스로 조절하게 할 수도 있다. 쓰임새는 CI 실행이나 배포처럼 바깥에서 벌어지는 상태를 끌어와 지켜보다가, 그 상태가 바뀌면 반응하는 것이다.
예컨대 백로그에 새 항목이 올라오는지 주기적으로 확인하다가 심각한 오류가 잡히면 워크트리를 만들어 수정을 올리게 할 수 있다. 멈추고 싶으면 ESC를 누르면 된다.
여러 에이전트의 충돌 방지 — Worktree

지금까지의 조종은 '한 대의 차에 운전대 하나'를 가정한다. 하지만 여러 에이전트가 같은 코드베이스에서 동시에 일할 때는, 한 차에 운전대가 둘이면 위험하다. 여기서 워크트리(worktree)가 등장한다. 워크트리는 둘 이상의 Claude 세션이 한 저장소의 파일을 두고 서로 다투는 것을 막는다. 각 세션에 독립된 파일 트리를 줘서 충돌을 방지하는 것이다.
세션을 끝내면, 변경이 없는 깨끗한 워크트리는 자동으로 정리된다. 그리고 저장소 루트의 `.worktreeinclude` 파일에는, 각 워크트리로 복사해 넣을 gitignore된 파일들을 적어 둔다. 버전 관리에 커밋하고 싶지는 않지만 작업에는 필요한 환경 변수 파일이나 로컬 설정 같은 것을 여기에 지정한다.
결론 — 범위를 먼저 좁히고, 그다음 조종한다
긴 클로드 코드 세션을 다룰 때는 먼저 작업 범위를 좁히고 그다음 조종한다. 압축(compact)은 요약이 중요한 것을 남기도록 방향을 지시하고, rewind 메뉴로 궤도를 바로잡는다. 단계를 설명하기보다 '끝난 상태'를 더 잘 묘사할 수 있을 때는 Goal을 걸고, 병렬 작업은 워크트리로 돌린다.
이렇게 하면 긴 실행을 곁에 붙어 지키지 않고도 믿고 맡길 수 있다. 결국 몇 시간짜리 세션을 신뢰할 수 있게 만드는 건 방치가 아니라 조종이다.
