코딩 에이전트 두 개를 같은 저장소에서 동시에 돌리면 먼저 부딪히는 것은 파일입니다. JetBrains의 ThinkRail은 이 문제를 작업공간마다 git worktree를 하나씩 주는 방식으로 푸는 오픈소스 IDE입니다.
저장소 README를 읽고 정리하면, 파일 충돌은 worktree가 해결하지만 설계 충돌은 해결하지 않습니다. 이 글은 그 차이를 로컬에서 직접 실행해 보여 주고, ThinkRail의 현재 기능과 계획 단계 기능을 나눠 적습니다. 제가 ThinkRail을 설치해 실행해 본 것은 아닙니다. 아래 ThinkRail 설명은 모두 README에 근거하며, 실행한 것은 일반 git 명령뿐입니다.
README가 말하는 현재 기능
ThinkRail은 pi 코딩 에이전트를 감싼 Apache-2.0 IDE로, 데스크톱 앱이나 브라우저 기반 thinkrail CLI로 씁니다. README 기준으로 제공되는 기능은 다음과 같습니다.
- 작업공간: 각 작업공간은 자체 브랜치와 디렉터리를 가진
git worktree입니다. 에이전트가 사용자의 체크아웃을 건드리지 않고 병렬로 일할 수 있습니다. 끝났거나 한 주 동안 조용한 작업공간은 선반(shelf)으로 옮겨집니다. 기존 worktree를 붙이거나 프로젝트 폴더에서 직접 작업하는 것도 가능하다고 합니다. - SPEC.md 그래프: 코드 옆에 연결된
SPEC.md파일 그래프가 있고, 에이전트가spec_*도구로 읽고 검색하고 갱신합니다. 워크벤치의 읽기 전용 Specs 도구가 이를 트리로 보여 줍니다. - MCP 도구 승인:
pi의mcp.json서버를 쓰되, 읽기 전용이 아닌 도구를 호출하기 전에 채팅에서 묻습니다. 프로젝트별로 신뢰하는 도구를 미리 승인할 수 있고, 저장소가 정의한 서버는 승인 전까지 꺼져 있습니다. - 그 밖에: 채팅별 모델과 토큰·비용 표시, 파일과 diff에 다는 검토 코멘트,
gh를 통한 PR 생성, 기존 Agent Skills 읽기.
계획 단계인 것
README의 앞으로의 계획은 한 문장입니다. 전체 확장 지원을 추가해 ThinkRail이 사용 방식에 맞는 도구를 스스로 만들 수 있게 하겠다는 것입니다. 작동 방식이나 출시 시점은 적혀 있지 않습니다. 따라서 "도구를 스스로 만드는 IDE"는 현재 기능으로 읽으면 안 됩니다. 슬로건인 "쓸수록 나아지는 IDE"도 README의 표현이며, 제가 확인한 성능 근거는 없습니다.
공개 시점도 확인되지 않았습니다. README에는 최초 공개일이 없고, 릴리스 페이지에서 확인한 것은 v0.2.0이 2026년 10월 18일 최신 정식 버전이고 이후 0.3.0 나이틀리(사전 릴리스)가 10월 28일까지 이어지고 있다는 점입니다. 2차 출처에는 8월 공개라는 언급이 있으나 확인하지 못했습니다.
파일 충돌과 설계 충돌
worktree가 해 주는 일은 정확합니다. 같은 저장소(.git)를 공유하면서 브랜치와 작업 디렉터리를 분리합니다. 두 에이전트가 같은 파일을 동시에 덮어쓰는 일은 없어집니다. 하지만 두 브랜치가 같은 설계 문서를 다르게 고치면, 합치는 순간 충돌합니다.
아래 스크립트는 임시 디렉터리에서 직접 실행했습니다. 에이전트 두 개가 각자 worktree에서 api/SPEC.md의 같은 계약 줄 뒤에 서로 다른 내용을 덧붙이고 커밋한 상황입니다.
git worktree add -q ../ws-a -b agent/a
git worktree add -q ../ws-b -b agent/b
# ws-a: "GET /items returns {items: [...]}" 추가 후 커밋
# ws-b: "GET /items supports ?limit" 추가 후 커밋
git merge -q agent/a # fast-forward
git merge --no-edit agent/b # 충돌
/privateTMP/app efbe9f0 [master]
/privateTMP/ws-a 425311a [agent/a]
/privateTMP/ws-b 5eaa885 [agent/b]
--- main SPEC.md untouched:
# api
Contract: GET /items returns a JSON array.
merged agent/a (fast-forward)
CONFLICT (content): Merge conflict in api/SPEC.md
<<<<<<< HEAD
Contract: GET /items returns {items: [...]}
=======
Contract: GET /items supports ?limit
>>>>>>> agent/b
main의 SPEC.md는 병합 전까지 손대지 않았고, 두 작업공간은 서로 보지 못했습니다. 그런데 한쪽은 응답 형식을 바꾸고 다른 쪽은 쿼리 매개변수를 추가했으니, 텍스트 충돌이 잡힌 것은 운이 좋은 경우입니다. 줄이 다르게 놓였다면 git은 조용히 합쳤을 것이고, 두 계약이 서로 모순인 채로 남았을 수 있습니다(이 부분은 위 실행에서 확인한 것이 아니라 git 병합의 일반적 성질에 따른 추론입니다).
병렬 에이전트 작업을 실험하는 방법
ThinkRail 없이도 같은 구조를 시험해 볼 수 있습니다.
- 작업을 파일 경계가 겹치지 않는 단위로 쪼갠다.
- 단위마다 worktree와 브랜치를 만들고 에이전트를 하나씩 붙인다.
- 계약(
SPEC.md나 인터페이스 문서)을 건드려야 하는 작업은 병렬에서 빼고 한 곳에서 먼저 정한다. - 병합 전에 모든 브랜치에서 같은 테스트를 돌린다.
이 구조의 이득은 비교로만 확인할 수 있습니다. 같은 과제를 직렬 한 에이전트와 worktree 병렬로 돌려 소요 시간, 병합 충돌 횟수, 테스트 통과율, 비용을 기록하세요. 제가 이를 측정한 것은 없습니다.
한계와 주의
- 설치·macOS 14+/Windows x64/Linux 요구사항, 비공증 CLI, 기본 켜진 분석 수집(
--no-analytics로 끔) 같은 제약은 README가 스스로 적어 두었습니다. - 에이전트가
SPEC.md를 직접 갱신한다는 것은 설계 문서도 에이전트의 출력이 된다는 뜻입니다. 사람이 검토하는 경로가 없으면 문서가 코드와 함께 틀려집니다. - 이 글은 ThinkRail의 품질이나 생산성 향상을 평가하지 않습니다. 직접 써 보지 않았습니다.
정리
worktree는 에이전트 병렬 작업의 파일 충돌을 막는 싸고 확실한 도구입니다. 하지만 설계 충돌은 계약을 누가 먼저 정하느냐의 문제입니다. ThinkRail이 흥미로운 지점은 worktree와 명세 문서, 도구 승인을 한 작업 화면에 묶었다는 것이고, 확장 생성 기능은 아직 약속일 뿐입니다.
글 끝의 유료 홍보 링크는 Claude Code를 제대로 쓰는 법과 하네스 구성을 다루는 강의입니다. ThinkRail이나 JetBrains 제품을 다루는 강의가 아닙니다.