dev.to

JetBrains open-sourced an agentic IDE where agents never touch your checkout

JetBrains, 에이전트가 기존 체크아웃을 건드리지 않는 IDE를 오픈소스로 공개

JetBrains의 Thinkrail은 코딩 에이전트마다 별도 Git worktree를 만들고, 모듈별 SPEC.md로 작업 의도를 세션 너머에 유지하는 IDE입니다. 다만 worktree는 파일 접근을 차단하는 샌드박스가 아니며, 에이전트가 코드와 명세를 함께 바꾸는 문제도 남아 있습니다.

에디터 노트

Thinkrail의 worktree는 체크아웃을 보호하는 보안 경계가 아니라 작업 공간을 나누는 방식입니다. 저장소 작성자는 에이전트 세션이 같은 사용자 권한으로 실행되며 형제 경로와 공유 자격 증명에도 접근할 수 있다고 확인했습니다. 댓글에서 제안한 외부 파일 변경 시험은 실행 결과가 아니라 소스에 근거한 예측이라고 정정했으므로, 실제 차단 여부는 입증되지 않았습니다. SPEC.md 역시 공개 인터페이스 검사는 있지만 설명문에 담긴 의도까지 검증하지는 못합니다. 에이전트가 코드와 명세를 함께 바꿀 수 있고 두 변경이 같은 검토 절차를 거친다는 점이 남은 쟁점입니다. 별도 worktree는 병합 충돌을 없애지 않고 변경을 분리해 드러냅니다. 따라서 현재 확인되는 강점은 에이전트 작업을 기존 체크아웃에서 떼어 놓는 워크플로이며, 격리나 명세의 신뢰성을 보장하는 장치까지 갖췄다고 보기는 어렵습니다.

본문

JetBrains가 Apache 2.0 라이선스로 공개한 Thinkrail은 pi 코딩 에이전트를 감싼 오픈소스 IDE입니다. 에이전트별 작업 공간, 세션이 끝나도 남는 프로젝트 명세, 자체 계정 없이 사용자가 제공하는 모델 자격 증명을 설계의 세 축으로 삼습니다.

에이전트마다 별도 worktree

Thinkrail은 각 작업 공간을 Git worktree와 별도 브랜치로 구성합니다. 여러 에이전트가 각자의 트리에서 작업하므로 사용자가 직접 빌드하는 체크아웃과 작업 공간을 분리하고, 결과를 합치는 시점을 명시적인 병합 단계로 둡니다. 글은 이를 에이전트가 같은 트리에서 파일을 수정하는 방식과 대비합니다. 다만 worktree가 해결하는 것은 작업 공간 분리와 병합 시점의 명시화입니다. 서로 다른 변경이 각각은 통과해도 함께 적용했을 때 모듈의 불변 조건을 깨는 구성상 충돌까지 없애지는 않습니다.

모듈별 SPEC.md로 의도를 기록

각 모듈 옆에 SPEC.md를 두고, 에이전트가 전용 spec_* 도구로 명세를 읽고 갱신합니다. 작업 지침과 작업 중 새로 알게 된 내용을 세션 뒤에도 남기는 방식입니다. 저장소 역시 모듈마다 SPEC.md를 두고 명세 우선으로 개발한다고 설명합니다. Thinkrail에는 명세에 선언된 공개 인터페이스와 TypeScript 모듈의 barrel을 비교하는 check:spec-surface 검사가 있습니다. 코드 공개 인터페이스만 바뀌고 명세가 갱신되지 않은 경우와, 명세에 실제로 없는 내보내기가 적힌 경우를 검출합니다.

그러나 에이전트가 명세를 따르면서 동시에 수정하면, 코드와 명세의 표면이 일치해도 설명문에 담긴 불변 조건이나 설계 판단이 실제 의도에서 벗어날 수 있습니다. 글은 이 문제를 미해결 과제로 꼽습니다. 저장소 작성자가 댓글에서 확인한 바에 따르면 SPEC.md만 별도 검토자로 지정하는 CODEOWNERS 규칙은 없고, 코드와 명세 변경은 같은 검토 절차를 거칩니다.

계정 없는 에이전트 호스트

Thinkrail은 자체 계정을 요구하지 않고 사용자가 모델 제공자의 자격 증명을 가져옵니다. 내부에는 Bun.serve 기반 HTTP 및 WebSocket 엔진, 채팅별 에이전트 세션, 버전이 있는 타입 기반 wire protocol, React 19 클라이언트가 있습니다. 기술 구성으로 skills, workflows, MCP 서버, 하위 에이전트, 채팅별 모델 선택과 토큰·비용 표시도 제시합니다. macOS Apple Silicon, Windows, Linux 설치 파일과 CLI가 제공되며 개발 환경에는 Bun 1.4.4와 Node.js 22.19 이상이 필요하다고 적었습니다. 프로젝트는 0.x 단계로, 실제 사용 경험이 축적됐다고 보기는 어렵습니다.

dev.to 반응

  • @vishisht_choudhary_a12d08 — 에이전트마다 worktree를 두는 설계는 타당하지만 SPEC.md가 더 큰 승부수입니다. 에이전트가 명세를 따르고 고치면 명세가 모르게 변할 수 있습니다. 명세 변경을 코드 변경과 분리해 검토하는 절차가 있나요?
    • @slabb — 별도의 검토 분리는 없습니다. 저장소의 CODEOWNERS 규칙 하나가 코드와 명세를 함께 다룹니다. check:spec-surface는 공개 인터페이스를 검사하지만 명세의 설명문이나 설계 판단은 검증하지 못합니다.
  • @paullovelace — 에이전트가 개발 중인 트리를 조용히 수정해 생기는 손실을 겪었습니다. worktree는 병합을 명시적인 단계로 만드는 점이 좋지만, 두 에이전트 변경이 각각 타당해 보여도 함께 적용하면 어떻게 되는지 실제로 확인하고 싶습니다.
    • @slabb — 두 변경이 따로는 통과해도 함께 적용했을 때 깨지는 구성상 충돌은 남습니다. worktree는 충돌을 없애기보다 명시적으로 드러냅니다.
  • @suirindo — worktree가 별도 디렉터리라는 사실만으로 형제 경로나 공유 자격 증명 접근까지 막지는 않습니다. 에이전트에게 작업 공간 밖 파일을 수정하게 하고 거부와 파일 상태를 확인하는 시험을 제안합니다.
    • @slabb — Thinkrail의 에이전트 작업 공간은 같은 사용자가 접근하는 별도 디렉터리로 라우팅됩니다. 에이전트 세션에 파일시스템 샌드박스를 적용하지는 않습니다. 댓글에서 제안한 시험 결과는 실제 실행한 측정값이 아니라 소스 코드에 근거한 예측이라고 정정했습니다.
  • @unitbuilds — 에이전트별 worktree는 기능 브랜치와 다르지 않습니다. 같은 파일을 동시에 수정할 때 생기는 조정 문제는 해결하지 못합니다.
    • @slabb — 브랜치 분리는 새 방식이 아니며 충돌을 해결하지도 않습니다. 변경이 언제, 어떤 전제에서 생겼는지를 드러내는 것이 설계의 범위입니다.

원문: dev.to / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗