소프트웨어 엔지니어 올렉산드르 프로코렌코(Oleksandr Prokhorenko)는 여러 코딩 에이전트를 동시에 돌릴 때 jj의 workspaces를 쓰면 각 에이전트의 작업을 하나의 공유 기록에서 살펴보고, 다른 작업의 변경 사항을 반영하거나 실수를 복구할 수 있다고 설명한다. 이 방법은 jj 0.46과 git 2.56에서 실행한 사례를 바탕으로 하며, git과 함께 쓰려면 저장소가 colocated 상태여야 한다.
각 workspace는 별도 디렉터리이자 공유 기록에 연결된 작업 사본이다. colocated 저장소에서는 새 workspace가 git worktree로 등록되므로 git status, IDE, gh, pre-commit 훅 같은 도구를 계속 쓸 수 있다. jj는 파일과 기록 사이에 스테이징 단계를 두지 않는다. 에이전트가 jj 명령을 실행하면 작업 디렉터리의 파일을 해당 작업의 변경 사항으로 기록한다. 따라서 에이전트가 아직 커밋하지 않은 수정도 다른 디렉터리에서 jj diff -r fix-retry@로 확인할 수 있다. 다만 마지막 jj 명령 뒤에 만든 수정은 다음 명령을 실행하기 전까지 공유 기록에 들어가지 않는다.
한 에이전트의 작업을 main에 반영한 뒤에는 다른 작업을 한 번에 rebase할 수 있다. 충돌이 생겨도 rebase가 중단되는 대신 충돌이 해당 커밋에 기록되며, 에이전트는 작업을 이어갈 수 있다. 외부에서 작업 기록을 다시 쓴 workspace는 오래된 상태가 되므로 그 디렉터리에서 jj workspace update-stale을 실행해야 한다. 프로코렌코는 각 workspace에서 먼저 jj st를 실행해 최근 수정 사항을 기록한 뒤 rebase하고, 마지막에 stale workspace를 갱신하는 흐름을 제시한다.
작업 중 실수로 파일을 지워도 jj가 기록한 작업 디렉터리의 스냅샷은 jj evolog에서 찾아 jj restore로 복구할 수 있다. 복구 범위는 에이전트가 마지막 jj 명령으로 기록한 시점까지다. 그 뒤의 수정은 git에서처럼 복구되지 않는다. jj undo는 다른 workspace에서 수행한 마지막 작업을 기본적으로 되돌리지 않으며, 특정 작업을 되돌릴 때는 jj op revert <id>를 쓸 수 있다.
완료한 작업을 다른 에이전트에게 넘길 때는 jj workspace add로 기존 작업의 변경 사항 위에 새 workspace를 만들 수 있다. 여기에는 원래 에이전트가 마지막 jj 명령으로 기록한 수정까지 포함된다. 원래 에이전트가 계속 작업하면 새 workspace가 stale 상태가 될 수 있다.
이 방식은 무시된 파일을 복사하지 않는다. 새 workspace에는 target/, .env, node_modules 등이 없으므로 빌드가 의존성을 다시 컴파일할 수 있고, .env를 읽는 테스트는 파일을 복사하기 전까지 실패할 수 있다. 모든 workspace가 같은 CARGO_TARGET_DIR을 쓰면 재빌드를 줄일 수 있지만, cargo가 해당 디렉터리의 잠금을 두고 에이전트들이 기다릴 수 있다. workspace를 제거하면 그 안의 파일도 삭제된다. 또 colocated가 아닌 저장소나 구버전 jj에서는 git 도구가 workspace 디렉터리를 저장소로 인식하지 못한다.
에이전트가 익숙한 git 명령으로 기록을 바꾸거나 푸시하지 않도록 프로코렌코는 쓰기 작업에는 jj만 쓰고, git의 status, diff, log, blame은 읽기용으로 허용하는 규칙을 둔다. JJ_EDITOR=false로 메시지 옵션 누락 시 편집기에서 대기하는 일을 막고, Claude Code의 PreToolUse 훅과 각 workspace의 pre-push 훅으로 푸시도 차단한다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요