Claude Code로 긴 작업을 이어가다 보면 메인 문제와 직접 관계없는 일이 끼어든다. 방금 만든 파서의 테스트 케이스를 따로 뽑거나, 앞에서 본 설정 이름을 확인하거나, 현재 접근과 다른 가설을 시험하는 일이다.
전부 메인 대화에서 처리하면 기록이 계속 불어난다. 반대로 새 에이전트를 깨끗한 컨텍스트로 시작하면 지금까지 쌓은 코드 이해와 의사결정을 다시 설명해야 한다.
2026년 4월 29일, 이 곁다리 작업을 다루는 Claude Code의 /branch, 당시의 /fork, /btw를 정리했다. 이후 6월과 7월에 /fork의 동작과 이름이 다시 바뀌었다. 원래 비교는 그대로 두고, 바뀐 내용은 아래 버전 표에 보충했다.
먼저 /fork라는 이름이 바뀌었다
검색 결과마다 /fork 설명이 달랐던 이유는 실제 동작이 여러 번 바뀌었기 때문이다.1 2026년 4월에는 현재 대화에서 새 가지를 만드는 /branch, 컨텍스트를 상속한 in-session 작업자, /btw를 비교했다. 6월과 7월 변경을 보충한 현재 기본 구성은 다음과 같다.
/branch: 사용자가 새 대화 가지로 이동한다./subtask: 현재 컨텍스트를 상속한 in-session 작업자를 실행한다./fork: 현재 대화를 복사한 별도 세션을 백그라운드에서 실행한다./btw: 메인 컨텍스트를 읽고 도구 없이 한 번 답하며 본 대화에는 기록을 남기지 않는다.
Agent view를 끈 구성은 예외다. /subtask를 사용할 수 없고 /fork가 계속 in-session 작업자를 실행한다. 명령 이름만 보지 말고 Claude Code 버전과 Agent view 설정을 함께 확인해야 한다.
/branch — 내가 다른 가지로 이동한다
/branch는 현재 시점의 대화를 복제하고 사용자를 새 가지로 옮긴다. 원본 세션은 남아 있고 당시에는 /resume으로 돌아갈 수 있었다.
[원본 대화]──────●
│
└── [새 가지, 현재 위치] ──● ──●Git으로 비유하면 분기를 만들고 바로 체크아웃하는 것에 가깝다. 두 접근을 동시에 실행하는 도구는 아니다.
잘 맞는 경우는 다음과 같았다.
- 지금 가설 대신 다른 디버깅 가설을 끝까지 시험한다.
- 큰 리팩터링을 별도 대화에서 시도하고 원본으로 돌아올 여지를 둔다.
- 같은 분기점에서 여러 접근을 직렬로 비교한다.
결과가 별도 대화로 남기 때문에 두 가지 결론을 자동으로 합쳐 주지는 않는다.
forked subagent와 /subtask — 작업자가 가지를 친다
4월에 /fork로 실행했던 메커니즘은 v2.1.212 이후 기본 구성에서 /subtask라는 이름을 쓴다. 일반 subagent처럼 빈 컨텍스트에서 시작하지 않고, 부모의 시스템 프롬프트, 도구, 모델, 메시지 기록을 상속한다. 메인이 이미 파악한 코드와 합의를 다시 설명하지 않아도 되는 것이 장점이었다.
[메인 세션] ─────●────────────●────
│ ▲
▼ │ 최종 결과
[컨텍스트를 상속한 작업]
├── 탐색과 도구 실행
└── 결과 정리도구 실행 과정 전체 대신 최종 결과만 메인에 합류해, 본 작업을 계속하면서 독립된 곁다리를 병렬로 처리할 수 있었다.2
하지만 컨텍스트 상속은 장점만은 아니었다. 부모가 잘못된 가정을 갖고 있으면 분기된 작업도 같은 가정에서 출발한다.
현재까지의 이해가 자산인 작업 → 컨텍스트 상속
현재까지의 가정을 의심하는 리뷰 → 깨끗한 subagent보안 감사나 적대적 리뷰처럼 기존 결론을 의심해야 하는 작업에는 새로운 관점이 더 중요했다. 부모 컨텍스트가 이미 비대하면 상속한 작업도 처음부터 비대하다는 한계도 있었다.
/btw — 이미 아는 것에 답만 받는다
/btw는 반대 방향이었다. 메인 대화 전체를 볼 수 있지만 도구는 없었다. 새 파일을 읽거나 코드를 검색할 수 없고, 이미 대화에 나온 내용을 바탕으로 한 번 답한다.
/btw 아까 확인한 설정 파일 이름이 뭐였지?당시 UI에서는 답을 오버레이로 보여주고 본 대화 기록에는 넣지 않았다. 메인 작업이 진행 중일 때도 짧은 질문을 던질 수 있었다.
잘 맞는 질문:
- 앞에서 본 함수나 설정 이름을 다시 확인한다.
- 이미 읽은 코드의 의미를 짧게 묻는다.
- 기록으로 남길 필요 없는 방향 확인을 한다.
맞지 않는 질문:
- 코드베이스를 새로 탐색해야 한다.
- 결론을 작업 기록에 남겨야 한다.
- 여러 번 대화를 이어가야 한다.
도구가 없다는 제약은 단점이라기보다 사용 목적을 분명하게 했다. 새 사실을 알아내는 도구가 아니라, 컨텍스트에 이미 있는 사실을 잠깐 꺼내는 도구였다.
세 가지를 나눈 기준
| 질문 | 선택 |
|---|---|
| 답만 받고 기록은 남기지 않아도 되는가 | /btw |
| 본 작업을 멈추고 다른 방향으로 이동할 것인가 | /branch |
| 본 작업을 계속하며 같은 문맥의 작업을 병렬로 돌릴 것인가 | /subtask 계열, Agent view를 끈 구성에서는 /fork |
| 현재 대화를 복사해 별도 세션에서 병렬로 돌릴 것인가 | /fork (Agent view를 켠 기본 구성) |
| 기존 가정을 의심할 깨끗한 관점이 필요한가 | 일반 subagent |
긴 세션에서 곁다리를 분리하는 이유는 토큰 비용만이 아니었다. 중요하지 않은 대화와 실행 로그가 쌓일수록 정작 중요한 제약을 다시 찾기 어려워진다. 메인 세션을 깨끗하게 유지하는 일은 비용 관리이면서 출력 품질 관리였다.
명령어 이름은 이후에도 바뀔 수 있다. 그래도 “내가 새 가지로 갈지”, “같은 문맥을 가진 작업자를 보낼지”, “답만 잠깐 받을지”를 먼저 고르면 도구를 구분하기 쉽다.