티켓마다 개발 환경을 세우다가 도구를 네 번 바꿨다

화면을 하나씩 옮기는 대신 여러 개를 한꺼번에 옮기기로 했다. 그러려면 워크트리가 필요했다. 그런데 워크트리는 소스만 있으면 되는 게 아니라 의존성이랑 빌드, dev 서버, 작업 창까지 한 세트로 딸려 온다.

그 한 세트를 세우는 손을 덜겠다고 일곱 달 동안 도구를 네 번 바꿨다. Cursor → 터미널 Claude Code → tmux → cmux → Orca. 끝에 가서는 스킬이 하던 일을 도구에 도로 넘겼다. 뭐가 실제로 도움이 됐는지 적어 둔다.

Cursor를 떠난 건 손이 많이 가서가 아니었다

1월 말에 사내 라이브러리로 Cursor project rule을 만들었다. 룰을 하나 만들 때마다 그때까지 쌓인 룰이 컨텍스트에 통째로 따라 들어왔다. 필요할 때만 꺼내 읽는 구조가 아니었다.

2월 4일에 룰을 전부 스킬로 옮겼다. 같은 날 트리거 테스트도 따로 잡아서 엉뚱한 질문에는 안 뜨는지까지 봤다. 닷새 뒤에 팀 세션을 켰다.

룰이 통째로 실려 오는 게 싫었다
에이전트를 여러 개 동시에 돌리고 싶었다
에디터로 코드를 안 쓰게 되니 IDE는 껍데기였다

셋 다 병렬 환경하고는 상관없는 이유다. 이때는 아직 폴더 하나, 세션 하나로 브랜치를 갈아타며 일했으니까.

떠나면서 .cursor/skills 심링크는 놔뒀다. 스킬 본문은 .agents/skills 한 곳에 두고 두 도구가 각자 심링크로 보게 했다. 옮긴 게 아니라 입구를 하나 더 낸 셈이다.

손이 얼마나 가는지는 tmux에서 알았다

~/.tmux.conf가 2월 중순이다. 한동안 손으로 세션을 만들어 쓰다가 3월 18일에 그 일을 스킬에 넘겼다.

워크트리 하나에 tmux 세션 하나. 브랜치명에서 Jira 티켓을 뽑아 세션 이름으로 쓰고, window 0에는 dev 서버를, window 1에는 작업 셸을 띄운다.

하루 뒤에는 두 건 이상 요청하면 서브에이전트를 나란히 띄워 각자 worktree add → install → build → 세션까지 알아서 끝내게 했다.

며칠 뒤에 커밋 하나가 붙었다. 세션을 죽이는 순서를 워크트리 삭제 앞으로 옮긴 것. 세션이 워크트리 디렉터리를 CWD로 잡고 있으면 git worktree remove가 실패한다.

세우는 쪽만 보고 있었는데 치우는 쪽에도 손이 갔다.

cmux는 tmux를 지우지 않았다

3월 25일에 cmux로 갈아탔다. 그런데 스킬에서 벌어진 일은 교체가 아니라 분기였다.

워크트리 문서를 쪼개고 멀티플렉서를 추상화했다. tmux.md 46줄, cmux.md 60줄이 생겼고 위쪽 흐름은 어느 쪽을 타든 같은 순서로 돌게 했다.

	tmux	cmux
세션	session	workspace
탭	window	surface
만들기	`new-session -d -s`	`new-workspace --cwd` + `rename-workspace`
보내기	`send-keys -t`	`send --workspace --surface`
닫기	`kill-session -t`	`close-workspace --workspace`

옮기고 나서 세 건을 한꺼번에 세워 재봤다.

	1번	2번	3번
install	35.3s	32.3s	31.3s
build	35.5s	34.4s	22.8s

다음 날 cmux 출력 파싱 버그를 고쳤다. 분기가 하나 늘면 버그도 하나 는다.

제일 손이 많이 간 건 창 이름 짓는 일이었다

tmux도 cmux도 이름밖에 없다. 사이드바만 보고 무슨 작업인지 알려면 스킬이 이름을 지어 줘야 한다.

그래서 절차가 이렇게 붙었다. 브랜치명에서 티켓을 뽑고, Jira CLI로 타이틀을 조회하고, 세션명과 탭명에 나눠 쓴다. 6월에는 dev 탭 이름에 실제 포트까지 넣었다. 설정 파일에 적힌 포트는 vite가 자리를 뺏기면 알아서 옆으로 옮겨 가 버려 믿을 수 없었다.

7월에는 같은 티켓을 두 번씩 조회하고 있는 걸 보고 Jira 응답에 한 시간짜리 캐시를 붙였다.

이름 짓는 데 스킬 분량이 계속 들어갔다.

Orca에서 그 코드를 지웠다

7월 21일에 orca 분기를 넣었다. Orca에는 세션이라는 게 없다. git worktree add로 밖에서 만든 워크트리도 사이드바에 알아서 뜬다. 그래서 orca 문서가 할 일은 세션을 만드는 게 아니라 터미널만 붙이는 거였다.

다음 날 표시명이랑 탭 타이틀을 자동으로 바꾸던 부분을 지웠다. 워크트리 카드가 브랜치를 이미 보여주는데 굳이 이름에 티켓을 박을 이유가 없었다. 작업 내용은 카드 comment 한 줄로 옮겼다.

엿새 뒤에는 dev 포트를 탭 타이틀에 넣는 것도 지웠다. 카드의 라이브 포트 칸이 이미 띄우고 있었다.

	도구가 알아서 보여주는 것	스킬이 직접 적어야 했던 것
tmux	세션명·창이름	티켓 추출 · 타이틀 조회 · 세션명 · 탭명 · 포트
cmux	브랜치·경로·포트·알림	티켓 추출 · 타이틀 조회 · 워크스페이스명 · 탭명
Orca	브랜치·comment·라이브 포트	타이틀 조회 · comment

orca.md가 276줄에서 256줄로 줄었다. 이 스킬에서 줄 수가 줄어든 건 이때가 처음이다.

시간을 줄인 건 순서를 바꾼 쪽이었다

같은 주에 느린 구간을 따로 잡았다. 그때까지는 dev 서버를 띄워 놓고 출력에서 포트를 거꾸로 읽었다. 부팅을 기다려야 하니 최대 30초가 걸렸고, turbo TUI에서는 URL 줄이 화면 밖으로 밀려 아예 못 읽기도 했다.

순서를 뒤집었다. 띄우기 전에 빈 포트를 훑어서 정하고 --port --strictPort로 박아 준다. vite가 뜰 때 하는 일 (자리가 차 있으면 +1)을 미리 해 두는 것뿐이다. 기다릴 게 없어졌다.

같은 커밋에서 두 개를 더 미뤘다.

Jira는 한 번만 조회하고 나머지는 캐시에서 꺼낸다
claude는 PRD 모드로 들어갈 때만 띄운다. 놀고 있는 인스턴스가 하나에 수백 MB씩 잡아먹어서다

셋 다 도구를 바꿔서 얻은 게 아니다. 하던 일의 순서만 바꿨다. 3월에 세션 kill을 워크트리 삭제 앞으로 옮긴 그 커밋하고 같은 종류다.

지금은 워크트리를 GUI로 만든다

7월 22일에 스킬이 git worktree add를 놨다. 정확히는 새 브랜치를 Orca 환경에서 만들 때만인데, 새 워크트리는 대부분 그 경우다.

이유는 또 이름이었다. orca worktree create CLI는 브랜치명을 슬러그로 바꿔 버린다. 슬래시가 대시로 눌려서 feature/abc가 feature-abc가 된다. 팀 브랜치 컨벤션을 지키려면 이름이 그대로여야 해서, CLI 대신 Orca UI가 쓰는 런타임 RPC를 그대로 부르게 했다. branchNameOverride에 정확한 이름을 실어 보내면 된다.

경로도 넘겼다. 그때까지 Path Policy가 계산하던 자리를 Orca가 정하게 뒀다. 그래서 폴더 이름 모양이 이때부터 바뀐다.

만든 쪽	경로 모양	기간	개수
git-ops	`worktrees/{저장소}-{브랜치}` (평평하게)	~7/21	7
Orca	`worktrees/{저장소}/{브랜치}` (한 겹 안으로)	7/28~	23

디스크에 남은 폴더만 세어 봐도 갈린 날이 보인다. 7월 21일이 스킬이 만든 마지막 워크트리다. 그 주에 orca 분기를 넣었고, 7월 28일 뒤로는 전부 Orca가 만들었다.

그러고 나서는 손이 아예 옮겨 갔다. 요즘은 사이드바에서 +를 눌러 만든다. 브랜치 하나 파는 걸 굳이 문장으로 시킬 이유가 없어졌다. 스킬은 그렇게 만들어진 걸 받아서 뒤를 처리한다. orca.md에는 “외부 생성 경로” 분기가 아홉 군데 있고, 제거 흐름은 Path Policy로 경로를 계산하기 전에 git worktree list에 등록된 실제 경로부터 본다. 밖에서 만든 건 규칙과 다른 데 있을 수 있으니까.

여러 개를 한꺼번에 띄우는 일은 Orca가 주는 오케스트레이션 스킬로 넘겼다. 8월 10일에 자식 워크트리 다섯 개가 한꺼번에 생겼는데, 그 스킬을 붙인 날이 바로 그날이다. 코디네이터가 웨이브 단위로 워커를 띄우고, 머지는 코디네이터가 혼자 순서대로 한다.

우리가 적은 건 문법이 아니라 정책이다. 명령 문법의 정본은 orca skills get orchestration이 바이너리에서 직접 내주고, 프로젝트 스킬에는 “테스트는 전체 2슬롯까지”, “워커는 plan 모드로 띄운다” 같은 결정만 남겼다. orca-cli 스킬도 79줄짜리 안내문이다. 본문을 안 쓴 게 아니라 쓰면 안 되는 것이다. 바이너리가 자기 버전에 맞는 가이드를 들고 있으니, 우리가 베껴 두면 그 순간부터 어긋나기 시작한다.

3월에 tmux 명령어를 46줄 적어 뒀던 것과는 정반대다.

세울 게 계속 늘었다

손을 더는 동안 “환경”이 뜻하는 범위가 같이 커졌다.

시점	세우는 범위	SKILL.md	전체	파일
3/06	worktree + install	60줄	362줄	5
3/18	+ dev 서버 + 세션	78줄	526줄	6
3/25	+ 멀티플렉서 2종	90줄	850줄	11
7/21	+ Orca	118줄	1,456줄	14
7/28	(이름 짓는 코드 제거)	123줄	1,797줄	14

한 건 세우는 데 드는 시간은 줄었는데 스킬은 다섯 배가 됐다. 코드를 지운 7월 28일에도 전체 분량은 늘었다.

다섯 달 가까이 붙이기만 했다. 줄어든 건 맨 끝에 와서였고, 그것도 규칙을 잘 써서가 아니라 도구가 대신 해 주면서였다.

아쉬운 것

버린 도구가 하나도 없다. .cursor/skills에는 심링크 열두 개가 6월 초에 멈춘 채로 남아 있다. Claude 쪽은 열일곱 개다. 차이 나는 다섯 개는 Cursor에서 보이지 않는다. 지우지도 맞추지도 않고 그냥 뒀다.

tmux는 떠난 적이 없다. 3월 10일에 넣은 teammateMode: tmux를 지금까지 한 번도 안 건드렸다. Orca 워크트리 안에서 도는 Claude Code가 팀메이트를 띄우면 그건 여전히 tmux 세션이다. 갈아탄 건 바깥 껍데기뿐이었다.

Path Policy는 아직 스킬에 있다. 경로를 Orca에 넘긴 뒤로 새 브랜치에는 안 쓰는 길인데 지우지 않았다. 비-Orca 환경과 네이티브 생성 폴백용으로 남겨 뒀다고 적어 놨지만, 그 규칙대로 생긴 폴더는 7월 21일이 마지막이다.

감지 분기가 여섯 개다. 환경변수로 셋, 설치 여부로 셋. 정작 매일 타는 건 하나다. 하나를 고르려고 나머지 다섯을 계속 끌고 다닌다.

문서가 또 늦었다. 위키의 git-ops 문서는 3월부터 일곱 판을 따라오다 7월 21일에 멈췄다. 그 다음 날과 엿새 뒤에 지운 코드가 아직 예시에 살아 있다. tmux·cmux·Orca 문서는 셋 다 8월 12일에 만들어 그날 끝냈다. tmux를 쓰기 시작하고 여섯 달 뒤, 쓰던 중이 아니라 다 쓰고 나서다.

지난 회고에 같은 얘기를 적었는데 이번에도 똑같았다.