Orca 로 worktree 세 개에 에이전트를 나눠 띄웠다
worktree 는 파일을 갈라준다. .git 은 안 갈라준다. 그 한 층 차이에서 다른 브랜치의 변경이 충돌도 없이 내 작업 트리에 얹혔다.
터미널을 세 개 열어놓고 쓰다 보면 10분쯤 지나서 어느 창이 무슨 작업이었는지 헷갈린다. 한쪽에서 로그인 버그를 잡고, 다른 쪽에서 테스트를 만들고, 나머지 창에서 리팩터링을 시키는데, 셋이 같은 폴더를 보고 있으니 결국 같은 파일을 건드리기 시작한다. 그래서 Orca 를 깔았다. 저장소를 붙이고 worktree 를 세 개 만들어 Claude Code 와 Codex 를 서로 다른 폴더에 띄웠다. 파일은 정말 안 섞였다. diff 세 개가 나란히 쌓이고 마음에 드는 것만 골라 PR 로 올릴 수 있었다.
한쪽 에이전트에게 "작업 중인 변경 잠깐 치워두고 확인해봐"를 시켰더니 git stash 를 썼고, 그게 다른 폴더에서 그대로 보였다. 거기서 꺼내니 다른 브랜치의 작업 트리에 얹혔다. 충돌조차 나지 않았다.
이름에 IDE 가 붙었지만 편집기는 아니다
제작사는 Orca 를 ADE 라고 부른다. Agent Development Environment 의 약자로, 코딩 에이전트를 여러 개 띄워놓고 작업별로 챙기는 공간이라는 뜻이다. GitHub 저장소 설명도 "병렬 에이전트 함대를 다루는 ADE" 라고 적혀 있다.
Cursor 나 VS Code 에도 AI 기능이 있는데 굳이 하나를 더 깔아야 하냐는 질문이 먼저 나온다. 역할이 다르다. Cursor 에서는 편집기 안에서 AI 와 코드를 함께 쓴다. Orca 에서는 코드를 직접 쓰지 않고, 여러 에이전트의 진행 상황을 보고 결과를 비교해 어느 변경을 가져올지 고른다. 편집기 자리에 앉아 있는 게 아니라 감독 자리에 앉는 도구다.
별도 AI 모델을 새로 결제하는 방식도 아니다. 컴퓨터에 이미 깔려 있는 CLI 와 로그인 정보를 불러와 실행한다. 그래서 목록에 에이전트가 안 뜨면 앱을 다시 깔기 전에 CLI 설치와 로그인, PATH 부터 보는 게 빠르다. 현재 문서에는 Claude Code, Codex, Gemini, Cursor CLI, OpenCode, Copilot CLI 를 포함해 40개가 넘는 에이전트가 올라와 있다.
오늘(2026-08-20) 저장소를 열어보니 숫자가 이렇다. 2026-03-17 에 만들어졌고 스타 49,472개, 포크 3,421개, MIT 라이선스, 릴리스 932개. 마지막 릴리스는 어제 나온 v1.4.185 다. 156일 동안 932번 배포했으니 하루 6번이다. 열린 이슈가 4,167개인 것도 같은 속도의 다른 얼굴이라고 본다. 반년 전에 없던 도구가 이 속도로 움직이고 있으면, 지금 읽는 설정 화면 설명이 다음 달에 그대로일 거라고 기대하기 어렵다.
한 바퀴만 먼저 돌려본다
익힐 흐름은 하나다. 저장소를 붙이고, worktree 를 만들고, 에이전트를 돌리고, diff 를 보고, 쓸 것만 반영한다.
macOS 에서 Homebrew 를 쓰면 설치는 한 줄이다.
brew install --cask stablyai/orca/orca
brew upgrade --cask orca
Windows 설치 파일과 Linux 용 AppImage 도 따로 올라와 있다. 처음 실행하면 홈 디렉터리 접근 권한을 요청하고, 기존 ~/.claude 와 ~/.codex 설정을 가져오겠다는 화면도 나온다.
저장소를 사이드바에 붙이면 이름 옆에 + 버튼이 생긴다. 여기서 만드는 작업 공간 하나가 사실상 Git worktree 하나다. 작업 이름은 결과가 아니라 할 일을 적는 게 낫다. 입력한 이름이 그대로 브랜치 이름이 되는데 test-1 이나 new-work 로 지어두면 에이전트가 서너 개 돌기 시작할 때 바로 헷갈린다.
Start from 은 특별한 이유가 없으면 origin/main 을 고른다. 생성 버튼을 누르면 백그라운드에서 fetch 와 git worktree add 가 돌아간다.
첫 프롬프트는 범위를 작게 잡는다. 재현 조건, 작업 순서, 바꾸면 안 되는 것, 완료 보고 형식을 같이 주면 결과를 비교하기 쉬워진다.
로그인 요청이 동시에 두 번 들어올 때 세션이 중복 생성되는 원인을 찾아줘.
먼저 재현 테스트를 추가하고, 테스트가 실제로 실패하는지 확인한 뒤 수정해.
기존 공개 API 는 바꾸지 말고 마지막에 변경 파일과 실행한 테스트를 알려줘.
Orca 가 프롬프트를 더 똑똑하게 만들어주지는 않는다. 같은 지시를 서로 다른 폴더에서 반복 실행하고 결과를 나란히 놓기 좋게 만들어줄 뿐이다. 그래서 쓸 만한 사용법은 같은 문제를 여러 접근으로 갈라놓는 쪽이다. worktree 를 세 개 만들어 하나는 Claude Code 에 원인 분석부터 수정까지, 하나는 Codex 에 똑같은 프롬프트를, 나머지 하나는 구현 없이 재현 테스트와 반례만 요청한다. 앞의 둘이 경쟁하고 마지막 하나가 심판을 본다.
터미널 옆의 작은 점이 은근히 요긴하다. 초록색이면 일하는 중, 노란색이면 내 답을 기다리는 중, 회색이면 쉬고 있다. 완료 알림과 질문은 사이드바의 Agents 피드로 모인다. 나는 노란색부터 눌러 답하는 쪽으로 쓰고 있다. 병렬 개수를 늘리고 싶어지지만 worktree 마다 브라우저 탭과 파일 감시자가 붙어서 메모리가 같이 올라간다. 두세 개로 시작하는 게 현실적이다.
시작 전에 권한 모드부터 자른다
여기서 설정 하나를 반드시 확인해야 한다. Orca 는 CLI 에이전트를 띄울 때 권한 확인을 건너뛰는 플래그를 미리 채워둔다. 지원 에이전트 문서에 적힌 그대로 옮기면 이렇다.
Claude Code 에는 --dangerously-skip-permissions 가 미리 채워진다. Codex 에는 --dangerously-bypass-approvals-and-sandbox 다. Gemini 와 Cursor 와 Crush 와 Kimi 와 Copilot CLI 쪽은 --yolo 가 붙는다.
플래그 이름이 저렇게 길고 험한 데는 이유가 있다. 문서는 worktree 가 버려도 되는 폴더라서 그 안에서는 매 셸 명령을 재확인할 필요가 없다고 설명한다. 토이 프로젝트에서는 맞는 말이다. 자격 증명이 들어 있는 업무용 노트북이라면 얘기가 달라진다.
모드는 Settings → Agents → Agent Permissions 에 Yolo 와 Manual 두 개가 있다. 처음 쓰는 동안에는 Manual 쪽을 권한다. 이미 특정 에이전트의 실행 인수를 직접 손댔다면 전역 설정이 안 먹을 수 있으니 그 에이전트 행도 펼쳐서 확인한다.
.git 은 하나다
worktree 가 뭘 나눠주고 뭘 안 나눠주는지는 문서를 읽는 것보다 직접 만들어보는 게 빠르다. 빈 저장소를 하나 만들고 worktree 두 개를 붙여서 확인했다. git 은 2.50.1(Apple Git-155)이다.
git worktree add 가 만드는 건 작업 트리다. 저장소를 복제하지 않는다. 새 폴더의 .git 을 열어보면 디렉터리가 아니다.
$ file ../fix-login-race/.git
../fix-login-race/.git: ASCII text
$ cat ../fix-login-race/.git
gitdir: /tmp/wt-lab/my-app/.git/worktrees/fix-login-race
한 줄짜리 포인터다. 저장소는 원래 자리에 하나뿐이고 새 폴더는 그쪽을 가리킨다. 그래서 hooks 가 공유된다. 말로만 들으면 그럴 수도 있겠다 싶은데, 실제로 해보면 다르다. 메인 저장소의 .git/hooks/pre-commit 에 훅을 심고 다른 폴더에서 커밋을 시도했다.
$ cd ../fix-login-race && git commit -m x
HOOK FROM MAIN WORKTREE
커밋이 막혔다. 에이전트 A 가 자기 폴더에서 훅을 손보면 B 와 C 의 커밋에도 그대로 걸린다는 뜻이다. git config 도 같다. 한쪽에서 remote.origin.url 을 바꾸고 다른 쪽에서 읽으면 바뀐 값이 나온다. object database 도 하나라서 한쪽이 git push --force 를 날리면 원격은 어차피 하나뿐이라 다른 폴더에 쌓아둔 커밋이 같이 사라진다.
같은 브랜치를 두 폴더에서 체크아웃하려고 하면 이렇게 거부한다.
fatal: 'fix-login-race' is already used by worktree at '/tmp/wt-lab/fix-login-race'
에이전트 셋에게 같은 버그를 던져놓고 브랜치 이름을 대충 지으면 두 번째부터 여기서 막힌다. Git 입장에서는 저장소가 하나니까 당연한 반응인데, 폴더가 따로 있는데 왜 막히는지는 처음 보면 바로 안 떠오른다.
전부 공유되는 건 아니다. .git/worktrees/fix-login-race/ 안을 들여다보면 HEAD, ORIG_HEAD, index, logs, refs 가 각자 하나씩 들어 있다. 한쪽에서 git add 를 해도 다른 쪽 스테이징은 안 바뀐다. 기대한 대로 동작하는 구간이다.
경계가 어중간한 건 stash 다. 위치부터 공용이다.
$ git rev-parse --git-path refs/stash
.git/refs/stash
worktrees/ 아래가 아니라 공통 디렉터리에 있다. A 폴더에서 stash 하고 B 폴더에서 목록을 보면 그대로 보인다.
$ cd ../add-auth-tests && git stash list
stash@{0}: On fix-login-race: from-fix-login-race
여기서 git stash pop 을 하면 A 의 변경이 B 의 작업 트리에 들어온다. 나는 브랜치가 다르니까 충돌이 나면서 지저분해질 거라고 예상했는데, 깨끗하게 적용됐다. add-auth-tests 브랜치 위에 다른 브랜치의 변경이 아무 경고 없이 얹혔다. 충돌이 났으면 오히려 눈에 띄었을 텐데 그게 없으니 더 안 좋다.
에이전트에게 "작업 중인 변경 잠깐 치워두고 확인해봐" 같은 지시를 하면 stash 를 꽤 자주 쓴다. 셋이 동시에 돌 때 이게 겹치면 원인을 찾는 데 시간이 걸린다. 각자 자기 폴더에서 자기 작업만 하고 있다고 생각하니까 stash 를 의심하는 순서가 늦다.
.gitignore 가 뚫어주는 쪽
worktree 를 새로 만들면 .gitignore 에 걸린 파일은 안 딸려온다. 실험용 저장소에서 확인해보니 새 폴더에는 .gitignore 와 src 만 있었고 .env 도 node_modules 도 없었다. 에이전트 입장에서는 방금 받은 저장소가 빌드도 안 되는 상태다.
그러면 찾으러 간다.
$ ls ../
my-app fix-login-race add-auth-tests
$ cp ../my-app/.env .
승인 모드가 꺼져 있으면 이 두 줄이 조용히 지나간다. 에이전트가 잘못한 것도 없다. 빌드를 통과시키라고 했고 통과시켰다.
문제는 결과 쪽이다. 실서비스 키가 든 .env 가 이제 폴더 세 곳에 복사돼 있고, 그중 둘은 실험이 실패하면 통째로 지워질 폴더다. 지울 때 --force 가 붙으면 확인도 안 한다. 파일 자체가 추적 대상이 아니니 Git 히스토리에도 안 남고, 어디까지 퍼졌는지 나중에 세보려면 find 를 돌리는 수밖에 없다.
이 불편함 때문에 worktree 를 만들 때 .env 를 심볼릭 링크로 걸어주는 스크립트를 쓰기도 한다. 매번 복사하는 것보다 나아 보이는데, 실제로는 모든 폴더가 같은 실서비스 키를 바라보게 만드는 설정이다. 실험용 폴더에서 에이전트가 마이그레이션 스크립트라도 돌리면 그 키가 가리키는 곳으로 그대로 간다. 빌드가 안 되는 상태를 그냥 두고 에이전트가 .env.example 로 더미 값을 채우게 하는 편이 낫다. 적어도 어디로도 안 나간다.
격리라는 말이 가리키는 세 곳
병렬 에이전트를 굴리다 보면 격리라는 단어를 최소 세 군데에 갖다 쓰게 된다. 섞어 쓰기 시작하면 어디까지 막아뒀는지 스스로도 헷갈린다.
위에서 본 작업 트리가 하나다. 브랜치와 체크아웃된 파일만 나눈다. cd .. 한 번이면 벗어난다.
그다음이 프로세스와 셸이다. 실제 방어선은 여기고, 앞에 나온 험한 이름의 플래그들이 끄는 게 이 층이다. 여기서 오해가 하나 붙는다. 에이전트가 worktree 를 현재 디렉터리로 삼아 실행되니까 읽고 쓰는 범위도 그 안일 것 같은데, 실행 디렉터리와 접근 범위는 상관이 없다. 프로세스는 내 사용자 계정 권한을 그대로 쓴다.
~/.ssh/id_ed25519
~/.aws/credentials
~/.claude/ # Claude Code 인증 토큰
~/.codex/ # Codex 인증 토큰
~/.config/gh/hosts.yml
전부 worktree 바깥이고 이 층이 꺼져 있으면 전부 읽힌다. 읽히면 나갈 수도 있다. curl 이 막혀 있을 이유가 없다.
에이전트가 나쁜 마음을 먹을 거라는 얘기가 아니다. 훨씬 흔한 경로는 이쪽이다. 테스트를 통과시키려고 npm install 을 돌리는데, 새로 들어온 패키지의 postinstall 이 뭘 하는지는 아무도 안 읽는다. 사고가 나면 원인은 의존성인데 통로는 내가 꺼둔 승인 모드다.
마지막이 화면과 OS 다. 에이전트에게 화면을 보고 클릭하게 하는 기능을 허용하는 순간, 대상은 저장소가 아니라 그 계정에서 열려 있는 창 전부가 된다. 로그인된 GitHub 탭도, 켜둔 Slack 도, 비밀번호 관리자 창도 같은 화면 안에 있다. 브랜치를 아무리 나눠도 브라우저 세션은 안 나뉜다.
온보딩 영상들이 이 세 개를 한 화면에서 연속으로 켠다. 스킬 설치, 스킬 설치, 권한 열기. 화면상으로는 똑같이 생긴 버튼들이라 안 짚어주면 서로 다른 층이라는 걸 알 방법이 없다. 도구를 사는 일과 권한을 자르는 일이 다른 작업이라고 전에 쓴 적 있는데, 여기서는 그 두 개가 같은 설정 화면에 붙어 있어서 더 헷갈린다.
승인 창은 스무 번째부터 안 읽힌다
Manual 로 두면 되는 거 아니냐고 하면, 켜두는 것만으로는 안 된다.
에이전트 하나를 돌릴 때는 승인 창이 하루에 몇 번 안 뜬다. 뜰 때마다 읽는다. 셋을 돌리면 세 배로 뜨는데, 사람 쪽은 세 배로 안 늘어난다. 처음 몇 번은 명령을 다 읽는다. 그다음부터 앞 단어만 본다. npm 으로 시작하면 통과, rm 으로 시작하면 멈춤. 좀 더 지나면 창이 뜨는 위치에 손이 먼저 간다.
보안 쪽에서 alert fatigue 라고 부르는 현상이라 새로울 건 없는데, 병렬 에이전트 환경이 이걸 만들어내기에 거의 최적으로 생겼다. 창이 자주 뜨고 내용이 매번 비슷하고 실제로 대부분 무해하다. 무해한 게 스무 번 지나가면 스물한 번째를 안 읽는다.
그래서 승인 모드를 켜는 것보다 승인 횟수를 줄이는 쪽에 시간을 썼다. 병렬 개수를 두세 개로 묶어두고, 자주 나오는 안전한 명령은 허용 목록에 넣어서 창이 아예 안 뜨게 만든다. 남는 창이 드물어야 읽게 된다.
목록에 넣은 건 읽기와 조회 쪽이다. git status, git diff, git log, ls, cat, 테스트 러너, 타입체커, 린터. 하루에 수십 번 돌고 결과를 되돌릴 일도 없다. 안 넣은 건 두 종류다. 패키지 매니저 설치 명령은 앞에서 말한 postinstall 때문에 남겨뒀고, git push 도 남겨뒀다. 푸시는 되돌리는 비용이 로컬 작업과 완전히 다르다. rm 이나 mv 도 당연히 그대로 뒀다.
이게 정말 더 안전한지는 나도 좀 애매하다. 승인 창 스무 개를 흘려보내는 것보단 낫다고 보는데, 허용 목록에 뭘 넣어뒀는지 두 달 뒤에 기억할 자신은 없다. 목록이 길어지면 그 자체가 안 읽는 설정이 된다.
Design Mode 가 같이 가져가는 것
앱 안에 띄운 브라우저 화면 위에 동그라미를 치고, 그 마크업을 복사해서 에이전트 프롬프트에 붙여 넣는 기능이 있다. 엘리먼트를 집으면 선택자까지 텍스트로 따준다. 말로 "헤더 오른쪽 세 번째 아이콘" 이라고 설명하던 걸 동그라미 하나로 끝낸다. 써보면 확실히 편하다.
붙여 넣는 게 이미지라는 게 걸린다. 내가 표시한 영역만 들어가는 게 아니라 그 순간 뷰포트에 렌더링돼 있던 게 전부 들어간다. 로컬 개발 화면이면 상관없는데, 스테이징 데이터를 띄워놓고 작업 중이었다면 목록에 찍혀 있던 고객명과 이메일이 같이 캡처된다. 사이드바에 열려 있던 관리자 메뉴도 마찬가지다. 그리고 그 이미지가 모델 API 로 올라간다.
세 층 어디에도 안 걸리는 경로다. 셸 명령도 아니고 파일 읽기도 아니고, 사람이 직접 복사해서 직접 붙여 넣으니 승인 프롬프트가 뜰 자리도 없다. 편하니까 반복하게 되고, 반복하다 보면 화면에 뭐가 떠 있는지 확인을 안 하게 된다. 시드 데이터가 들어간 로컬 환경에서만 쓰기로 했다. 재미없는 규칙인데 이 경로는 사고가 나면 되돌릴 방법이 없다.
모바일 앱도 결이 비슷하다. QR 로 페어링하면 폰에서 worktree 를 만들고 에이전트를 돌릴 수 있고, 승인 프롬프트도 폰에서 뜬다. 그런데 6인치 화면에서 스크롤 세 번 넘겨야 하는 diff 는 안 읽는다. 그냥 누른다. 설정상으로는 Manual 인데 실질은 자동 승인에 가까워진다. 그래서 모바일에서는 읽기 작업만 던진다.
분해 JSON 을 diff 보다 먼저 읽는다
에이전트 결과는 대화가 아니라 diff 로 판단한다. 변경 파일 수가 요청 범위를 벗어났는지 보고, 새 테스트가 원래 버그를 실제로 재현하는지 확인하고, lint 와 타입체크와 테스트를 직접 다시 돌린다. 아쉬운 데가 한두 군데면 diff 줄에 메모를 달아 되돌려보낸다. "전체를 다시 해줘" 보다 이 분기는 refresh token 이 없는 기존 사용자도 통과해야 한다 처럼 줄 단위로 주는 편이 수정 범위를 좁게 묶는다.
그런데 오케스트레이션 기능이 붙으면서 diff 보다 먼저 봐야 하는 화면이 하나 생겼다. /orchestrate 에 작업을 던지면 코디네이터 에이전트가 태스크를 JSON 으로 쪼개고 워커 에이전트에 배분한다. 분해는 실행보다 설계 쪽에 가깝다. "결제 실패 재시도 로직 추가해줘" 를 이런 모양으로 쪼갠다.
{
"tasks": [
{ "id": 1, "title": "재시도 정책 정의", "agent": "claude" },
{ "id": 2, "title": "지수 백오프 구현", "agent": "codex" },
{ "id": 3, "title": "실패 케이스 테스트", "agent": "claude" },
{ "id": 4, "title": "런북 문서 갱신", "agent": "codex" }
]
}
그럴듯하다. 멱등성이 빠져 있다. 같은 요청을 여러 번 보내도 결과가 한 번 보낸 것과 같아야 하는 성질을 말하는데, 결제 요청을 재시도한다는 건 같은 요청을 두 번 보낸다는 뜻이고 서버가 이걸 구분할 키를 안 받으면 두 번 결제된다. 재시도 로직에서 이건 부가 항목이 아니라 전제다.
빠진 채로 돌리면 워커 넷이 각자 맡은 걸 정확하게 끝낸다. 백오프도 잘 붙고 테스트도 통과하고 통합 diff 도 깨끗하다. 결제가 두 번 되는 것만 빼면 전부 잘된다. 이게 오케스트레이션에서 제일 까다로운 실패 모양이다. 상위 분해가 틀리면 하위 실행의 품질이 오히려 문제를 가려준다. 엉성하게 실패하면 눈에 띄는데, 정확하게 잘못된 방향으로 가면 diff 가 깨끗해서 그냥 통과시키게 된다.
그래서 저 JSON 을 읽을 때 두 가지를 본다. 순서 의존이 있는데 병렬로 잡혀 있는지가 하나다. 위에서 2번 백오프와 3번 테스트가 동시에 돌면 테스트를 쓰는 쪽은 아직 없는 함수 시그니처를 상상해서 쓰고 나중에 안 맞는다. 도메인 전제가 태스크로 안 올라온 게 있는지가 다른 하나고, 멱등성이 여기 걸린다. 코디네이터가 알아서 채울 수 있는 종류가 아니다. 결제 시스템이 어떻게 생겼는지는 이 저장소를 봐야 아는 정보인데 코디네이터가 받은 건 프롬프트 한 줄이다. 제목이 "구현" 한 단어로 끝나는 태스크도 대개 세 개짜리다. 쪼개진 것처럼 보이지만 안 쪼개져 있어서 그 워커의 diff 만 유독 크게 나온다.
문제는 저 화면이 볼 수 있게 만들어져 있고 읽게 만들어져 있지는 않다는 점이다. 태스크가 전부 초록색으로 진행 중이면 굳이 펼쳐보게 되지 않는다.
여기에 스케줄러가 붙으면 층이 하나 더 겹친다. 컴퓨터를 켜면 등록해둔 작업이 바로 도는 기능인데, 자동으로 도는 작업은 승인 창을 띄울 상대가 없다. 아침에 보면 작업 하나가 밤새 승인 대기 중이거나, 그게 싫어서 그 작업만 권한을 풀어놨거나 둘 중 하나다. 후자를 고르면 프로세스 층이 특정 작업에 대해서만 조용히 꺼진 상태가 된다. 설정 화면에는 여전히 Manual 이라고 적혀 있고. 이슈 분류나 로그 요약처럼 읽기만 하는 작업부터 자동화하는 게 낫다.
지금 걸어둔 규칙
저장소를 세 등급으로 나눴다.
토이와 실험용에서는 온보딩 영상 조언 그대로 간다. 권한 다 열고 오케스트레이션 돌리고 자동화도 건다. 날아가도 되는 저장소라 상관없다. 이 등급에서까지 Manual 을 고집하면 도구를 안 쓰느니만 못하다.
개인 실서비스에서는 프로세스 층을 Manual 로 유지한다. 오케스트레이션은 쓰되 분해 JSON 을 읽고 승인한 다음에 워커를 붙인다. 화면을 보고 클릭하는 기능은 안 켠다.
업무용이나 자격 증명이 있는 머신에서는 메인 계정에서 안 돌린다. 별도 사용자 계정이나 VM 을 파고 거기서만 돌린다. 자격 증명이 없는 계정이면 프로세스 층이 뚫려도 가져갈 게 없다. 귀찮은데 이게 제일 확실하다.
시크릿을 평문 파일로 두지 않는 것도 이 맥락이다. 1Password CLI 로 바꿨다. .env 에는 실제 키 대신 op://vault/stripe/api_key 같은 참조만 적어두고, 실행할 때 op run --env-file=.env -- npm run dev 형태로 주입한다. 디스크에 평문이 안 남는다. 앞에서 본 cp ../my-app/.env . 가 그대로 일어나도 결과가 다르다. 복사돼 간 파일 안에 든 게 참조 문자열이라 그 자체로는 아무 데도 못 들어간다. 실제 값을 꺼내려면 세션이 있어야 하고, 세션은 승인 화면을 한 번 거친다. 홈 디렉터리 어딘가에 .env 가 평문으로 앉아 있으면 프로세스 층 격리는 처음부터 성립을 안 한다.
나머지는 잔규칙이다. git worktree list 를 가끔 친다. Orca 화면에서 지운 줄 알았던 게 남아 있곤 하는데, 남아 있으면 아까 복사된 .env 도 같이 남아 있다. 그럴 때 git worktree prune 으로 정리한다. hooks 는 건드리지 말라고 프로젝트 지침 파일에 박아뒀다.
Orca 가 잘 만든 도구라는 판단은 그대로다. CLI 를 네 개 번갈아 쓰던 때와 비교하면 어느 창이 무슨 작업이었는지 되짚는 시간이 확실히 줄었다. 다만 다섯 달 만에 오케스트레이션과 화면 제어가 붙으면서 다뤄야 할 위험의 종류가 바뀌었다. worktree 격리 하나로 설명이 끝나던 시기는 지났고, 에이전트를 세 개 돌려도 마지막에는 사람이 분해 JSON 을 읽고 diff 를 읽고 테스트를 확인해야 한다. 병렬로 돌아가는 건 그 판단 앞까지다.
참고한 자료는 Orca 저장소, 지원 에이전트 문서, git-worktree 공식 문서다. worktree 동작은 git 2.50.1 로 직접 재현해 확인했다.
댓글
댓글 쓰기