Copilot CLI 워크트리 운영법: AI 코딩 세션을 안전하게 병렬화하는 기준

요약: GitHub Copilot의 8월 3일 주간 업데이트에는 CLI의 Sessions sidebar, experimental /worktree, Git 없이 쓰는 /rewind, tool-call duration timeline이 포함됐습니다. 별도 기능처럼 보이지만 실무 개발팀에는 하나의 메시지입니다. AI 코딩 에이전트는 이제 한 대화창이 아니라 여러 격리 세션을 병렬로 운영하는 도구가 되고 있습니다.

왜 병렬 AI 코딩 세션이 필요한가

AI 코딩 도구를 오래 쓰다 보면 한 세션이 모든 일을 떠안는 문제가 생깁니다. 버그를 고치다가 리팩터링 아이디어가 나오고, 문서 수정을 하다가 테스트 실패를 조사하며, 그 사이에 다른 질문이 끼어듭니다. 사람 개발자도 context switching이 힘든데, AI 세션도 마찬가지입니다. 한 thread 안에서 목표가 섞이면 결과가 흔들립니다.

GitHub changelog에 따르면 Copilot CLI는 여러 concurrent sessions를 Sessions sidebar에서 관리할 수 있게 했고, experimental /worktree 명령으로 현재 작업을 방해하지 않는 별도 workspace에서 새로운 conversation을 시작할 수 있게 했습니다. /rewind는 Git 없이도 Copilot이 바꾼 conversation과 files를 되돌리되 이후 edit은 보존하는 흐름을 제공합니다. timeline에는 live tool-call duration이 표시되어 느린 명령을 찾을 수 있습니다.

이 기능들은 단순 편의가 아닙니다. AI 코딩을 production workflow에 넣으려면 “격리”, “복구”, “관측”이 필요합니다. worktree는 격리, rewind는 복구, timeline은 관측에 해당합니다.

worktree를 써야 하는 작업과 쓰면 안 되는 작업

worktree는 같은 repository에서 별도 작업 디렉터리를 만들어 독립적인 branch 작업을 가능하게 합니다. AI 에이전트에게 맡길 때는 특히 유용합니다. 현재 main 작업을 망치지 않고 실험을 시킬 수 있기 때문입니다.

적합한 작업은 다음과 같습니다.

해결책이 2개 이상이라 비교가 필요한 버그
UI 리팩터링처럼 되돌릴 가능성이 높은 작업
dependency upgrade 영향 범위 조사
테스트 실패 원인 후보를 병렬로 확인
codemod 또는 대량 rename dry run
문서 생성과 코드 변경을 분리해서 검토

반대로 DB migration, production hotfix, release branch 수정처럼 순서와 승인 흐름이 중요한 작업은 worktree 남발이 위험할 수 있습니다. 이 경우에는 한 세션에서 작은 단계로 진행하고, 사람이 checkpoint를 확인하는 편이 낫습니다.

/rewind를 믿기 전에 정해야 할 원칙

/rewind 같은 복구 기능은 강력하지만, 팀의 버전 관리 원칙을 대체하면 안 됩니다. Git 없이 되돌릴 수 있다고 해서 commit을 미루면 오히려 위험합니다. AI가 긴 작업을 할수록 중간 checkpoint commit이 필요합니다.

tool-call duration을 운영 지표로 쓰는 방법

Copilot CLI timeline에서 live tool-call duration을 볼 수 있다는 점도 중요합니다. AI 코딩 세션이 느릴 때 모델이 느린지, 테스트가 느린지, package install이 느린지 구분해야 합니다. 대부분의 팀은 “AI가 오래 걸린다”고만 느끼지만, 실제 병목은 반복 실행되는 test command나 dev server startup인 경우가 많습니다.

세션별로 다음 값을 기록하면 좋습니다.

가장 오래 걸린 command
반복 실행된 command 횟수
실패 후 재시도 횟수
install/build/test에 쓴 시간
model 응답 대기 시간과 shell 실행 시간의 비율

이 데이터를 보면 agent prompt를 고칠 수 있습니다. 예를 들어 테스트 전체를 매번 돌리는 세션에는 “처음에는 관련 test file만 실행하고, 마지막에 full test를 돌려라”라고 지시할 수 있습니다. 느린 build가 반복된다면 watch mode나 targeted command를 제공해야 합니다.

사람 리뷰와 연결하는 방식

AI 세션을 병렬화하면 산출물도 많아집니다. 그래서 merge 전에 사람이 보기 쉬운 report 형식이 필요합니다. 각 세션은 마지막에 다음 정보를 남기게 해야 합니다.

목표
변경 파일 목록
핵심 diff 요약
실행한 명령과 결과
실패한 시도
남은 리스크
사람이 확인해야 할 화면 또는 케이스

이 report가 없으면 병렬화는 속도가 아니라 혼란을 만듭니다. worktree 4개에서 각자 코드가 바뀌었는데 무엇을 믿어야 하는지 알 수 없게 됩니다. AI 코딩의 품질은 최종 diff만이 아니라 사람이 판단할 수 있는 흔적에 달려 있습니다.

실행 체크리스트

작업 시작 전 clean working tree를 확인한다.
실험성 작업은 /worktree 또는 별도 branch에서 실행한다.
세션 이름은 목적과 날짜가 보이게 짓는다.
병렬 세션마다 “허용 작업”과 “금지 작업”을 명확히 쓴다.
/rewind 후에는 반드시 diff, test, typecheck를 확인한다.
긴 작업은 중간 checkpoint commit 또는 stash를 남긴다.
tool-call duration을 보고 느린 명령을 targeted command로 바꾼다.
각 세션 종료 시 변경 파일, 테스트 결과, 남은 리스크를 report로 남긴다.
최종 merge는 사람이 한 worktree씩 diff를 보고 결정한다.

Copilot CLI의 이번 변화는 AI 코딩이 “한 명의 똑똑한 조수”에서 “여러 격리 작업자를 운영하는 개발 시스템”으로 넘어가고 있음을 보여줍니다. 병렬화의 이득은 큽니다. 하지만 worktree, rewind, duration 관측을 규칙 없이 쓰면 속도보다 복잡도가 먼저 늘어납니다.