ThinkRail: Pi 코딩 에이전트를 Git 워크트리별로 병렬 실행하고 턴 단위로 검토하는 IDE (feat. JetBrains)

9bow · 10월 30, 2026, 8:30오전

핵심 요약

ThinkRail은 JetBrains가 인큐베이터 프로젝트로 공개한 에이전틱 IDE로, 터미널용 코딩 에이전트 Pi를 라이브러리로 내장해 웹 UI와 데스크톱 앱에서 쓰게 해 줍니다.
작업 공간마다 별도의 git worktree와 브랜치를 만들어 여러 Pi 세션을 병렬로 실행하고, 에이전트가 한 번 실행되는 동안 바뀐 파일을 한 화면에 모아 검토할 수 있습니다.
코드 옆에 둔 SPEC.md 파일들을 스펙 그래프로 묶고, 에이전트가 전용 spec_* 도구로 이를 읽고 고치게 해서 세션이 끝나도 설계 의도가 남게 합니다.
안정판은 2026년 10월 18일 공개된 v0.2.0입니다. README에 적힌 일부 기능(인터페이스 언어, Pi 설정 폴더 선택, macOS Intel 빌드 등)은 그 이후 main에 병합되어 아직 안정판에 없습니다.

ThinkRail 소개

Pi ( Gemma 4와 Pi Coding Agent로 완전히 로컬에서 실행하는 코딩 에이전트 만들기 (feat. LM Studio))는 Earendil과 Pi 커뮤니티가 개발하는 터미널 코딩 에이전트입니다. 기능을 최소한으로 두고, 확장(Extension)과 스킬(Skill)로 환경을 맞춰 쓰는 에이전트 하네스(Agent Harness)입니다. ThinkRail 개발팀은 이 유연함에 비용이 따른다고 설명합니다. 처음 쓰는 사람은 Pi를 다루는 법을 익히는 데 시간을 들여야 하고, 익숙한 사람도 에이전트 주변의 작업을 터미널에서 하기는 불편하다는 것입니다. 개발팀이 제품 목표 문서에 적은 문제는 세 가지입니다: 여러 에이전트가 한 작업 트리에서 서로의 변경과 충돌하는 문제, CLI에서 변경을 읽고 특정 줄에 의견을 달기 어려운 문제, 채팅에서 내린 결정이 세션과 함께 사라지는 문제입니다. 이번에 소개하는 ThinkRail 은 이 세 가지 문제를 다루기 위해 JetBrains가 만든, Pi 전용 에이전틱 IDE입니다.

ThinkRail은 Pi를 포크하거나 다시 구현하지 않고, npm 패키지 @earendil-works/pi-coding-agent를 같은 프로세스 안에서 라이브러리로 실행합니다. 모델 목록, 시스템 프롬프트, 스킬과 확장, 컨텍스트 압축, 비용 계산, 세션 상태는 모두 Pi가 맡습니다. ThinkRail은 작업 공간과 편집기, 그리고 호스트와 UI를 잇는 통신 계층만 맡습니다. 개발팀은 이 원칙을 "never assembles prompts behind your back" 라고 표현합니다. ThinkRail 기능은 Pi에 컨텍스트와 파일, Pi 자체의 스킬과 확장을 넘겨주는 방식으로만 에이전트에 영향을 줍니다.

ThinkRail은 Pi의 설정 폴더 ~/.pi를 함께 쓰고, Pi CLI에서 하던 세션을 ThinkRail에서 이어 가거나 반대로 옮겨 갈 수 있습니다. Pi에 없는 공개 API, Pi의 결함, 패키징 제약 때문에 호스트 쪽 코드로 보완한 부분은 pi-compatibility.md에 따로 정리해 두고, Pi를 업그레이드할 때마다 각 항목을 다시 확인합니다.

아래 화면은 ThinkRail의 기본 작업 화면입니다: 왼쪽에 프로젝트와 작업 공간 목록, 가운데에 Pi 대화와 그 대화가 만든 diff, 오른쪽에 스펙 트리와 변경 목록이 있습니다.

ThinkRail은 세 계층으로 구성되어 있습니다: 엔진 호스트(packages/server), 통신 프로토콜(packages/contracts), 웹 UI(apps/web)입니다. 엔진 호스트는 Bun의 Bun.serve로 HTTP와 WebSocket을 제공하고 대화마다 Pi 세션 하나를 띄웁니다. 통신 프로토콜은 타입과 버전이 정해진 계약이고, 웹 UI는 React 19와 Zustand, Tailwind v4로 만들었습니다. 같은 호스트를 Electrobun으로 감싼 데스크톱 앱과, 터미널에서 실행하면 브라우저로 같은 화면을 여는 thinkrail CLI 두 가지 형태로 배포합니다. 편집기는 VS Code의 편집기 엔진인 Monaco를 쓰고, 터미널과 파일 트리, 변경 목록이 모두 현재 작업 공간 범위로 묶입니다. 개발팀은 블로그에서 ThinkRail이 아직 초기 개발 단계라고 밝혔습니다. 이 점을 감안해 살펴보시기 바랍니다.

ThinkRail vs. JetBrains Air와 Emdash

여러 에이전트 작업을 병렬로 실행하고 그 결과를 GUI에서 검토하는 도구는 ThinkRail 말고도 있습니다. JetBrains도 여러 에이전트를 연결해 쓰는 JetBrains Air를 운영하고 있고, 오픈소스 쪽에는 작업마다 Git 워크트리를 만드는 Emdash가 있습니다. 세 도구의 공개 자료에서 확인한 차이는 다음과 같습니다:

구분	ThinkRail	JetBrains Air	Emdash
연결하는 에이전트	Pi 하나 (같은 프로세스에서 라이브러리로 실행)	이미 쓰는 에이전트(Claude Agent 등)와 ACP(Agent Client Protocol) 호환 에이전트	Claude Code, Gemini, Qwen Code 등 23개 이상의 CLI 에이전트 (PyTorchKR 소개 글 기준)
병렬 작업	작업 공간마다 `git worktree`와 브랜치	프로젝트마다 여러 세션, 변경 파일과 커밋 추적	작업마다 `git worktree`와 브랜치
변경 검토	실행 한 번(턴)의 변경 묶음 보기, 브랜치 diff에서 변경 단위별 유지/되돌리기	세션에서 diff를 열고 특정 줄에 코멘트	Diff 검토, PR 생성
실행 형태	데스크톱 앱, 브라우저용 CLI	JetBrains IDE, 웹, CLI, 모바일	데스크톱 앱

ThinkRail은 두 번째 에이전트 런타임(Runtime)을 두지 않는다는 원칙을 목표 문서의 비목표(Non-goals) 항목에 명시해 두었습니다. 그래서 Claude Code나 Codex CLI를 그대로 붙여 쓰는 방식은 지원하지 않습니다. 대신 그 에이전트용으로 만들어 둔 스킬 파일을 읽어 Pi에서 쓰게 합니다(아래 호환 범위 절 참고). Pi 위에 기능을 더한 Step Code와 Jeff-Code는 Pi 코드를 가져와 직접 고친 터미널 에이전트입니다. ThinkRail은 Pi를 바꾸지 않고 그 위에 화면과 작업 공간만 더한다는 점이 다릅니다.

ThinkRail을 사용하면 좋을 사용자

ThinkRail은 이미 Pi를 쓰고 있는 개발자, 그리고 Pi를 쓰고 싶지만 터미널 UI가 부담스러운 개발자에게 맞습니다. Pi 설정과 세션을 그대로 공유하므로 옮겨 오는 비용이 작습니다. 여러 작업을 동시에 맡기고 변경을 작업 공간별로 나눠 검토하려는 경우에는 워크트리 격리와 턴 단위 검토가 바로 쓰입니다. 반면 Claude Code나 Codex CLI 같은 다른 에이전트를 계속 주력으로 쓸 팀에게는 ThinkRail이 적절한 선택지가 아닙니다. 엔진이 Pi 하나로 고정되어 있기 때문입니다. 또한 Intel Mac용 배포 파일은 아직 없어서 소스에서 직접 빌드해야 합니다(설치 절 참고).

ThinkRail의 워크트리 작업 공간

ThinkRail은 로컬 Git 저장소를 프로젝트로 열고, 그 저장소에서 git worktree로 작업 공간을 잘라 냅니다. 워크트리(Worktree)는 한 저장소에 연결된 별도의 작업 디렉토리로, 저장소를 다시 복제하지 않고도 브랜치마다 다른 파일 상태를 동시에 가질 수 있게 해 주는 Git 기능입니다. 각 작업 공간은 자기 브랜치와 작업 디렉토리(~/.thinkrail/worktrees/<프로젝트명>/workspace-1 등)를 가지며, 파일과 diff, 터미널, 대화가 모두 그 작업 공간에 묶입니다. 그래서 한 에이전트가 기능을 구현하는 동안 다른 작업 공간의 두 번째 에이전트에게 스펙 갱신을 맡겨도 서로의 파일을 건드리지 않습니다. 원래 프로젝트 폴더를 IDE로 열면 에이전트가 바꾸기 전의 코드가 그대로 보입니다.

프로젝트 폴더에서 직접 작업하는 Default 작업 공간도 있지만, 개발팀은 이를 기본값이 아니라 사용자가 명시적으로 고르는 선택지로 두었습니다. 블로그에서는 프로젝트 폴더에서 바로 작업하면 저장하지 않은 변경을 에이전트가 지우거나, Git 작업 권한이 있는 에이전트가 저장한 변경까지 덮어쓸 수 있다고 그 이유를 설명합니다. 이미 만들어 둔 워크트리를 그대로 연결할 수도 있으며, 이 경우 ThinkRail은 그 워크트리를 목록에서 뺄 수는 있어도, 워크트리 자체를 지우거나 이름을 바꾸지 않습니다.

v0.2.0부터는 끝난 작업 공간이 프로젝트별 Settled 선반으로 자동으로 옮겨집니다. 기준은 해당 PR이 병합되거나 닫혔을 때, 또는 7일 동안 작업이 없을 때이며, 기간은 1, 3, 7, 14일이나 사용 안 함 중에서 고를 수 있습니다. ThinkRail은 사용자의 gh CLI로 작업 공간 브랜치를 푸시하고 PR을 열거나 갱신하며, GitHub 토큰을 따로 저장하지 않습니다. gh를 쓸 수 없으면 미리 채운 비교 URL로 대신합니다. v0.2.0 이후 main에서는 상단 표시줄이 현재 브랜치가 origin과 PR 대비 어떤 상태인지, 다음에 할 일(푸시, PR 열기 등)이 무엇인지 항상 보여 줍니다.

ThinkRail의 턴 단위 변경 검토

턴(Turn)은 사용자가 메시지를 보낸 뒤 에이전트가 작업을 마칠 때까지의 실행 한 번을 말합니다. v0.2.0에서 ThinkRail은 변경이 있었던 턴의 끝에 3 files changed · +27 −4 같은 요약 줄과 Review turn 버튼을 표시합니다. 이 수치는 에이전트의 도구 호출 기록이 아니라, 호스트가 실행 시작과 끝에 워크트리 상태를 찍어 비교해서 얻습니다. 그래서 셸 명령이 고친 파일, 포매터가 바꾼 파일, 이름 변경까지 모두 집계되고, 이 과정에서 HEAD와 인덱스, reflog는 건드리지 않습니다.

Review turn을 누르면 그 턴에 바뀐 파일이 한 탭에 이어져 열립니다. 브랜치 전체 diff(All changes)에서는 변경 단위(Hunk)마다 유지(Keep), 되돌리기(Revert), 에이전트에게 질문하기 버튼이 있습니다. 파일의 마지막 변경 단위를 유지하면 그 파일이 검토 완료로 표시됩니다. 유지 표시는 줄 번호가 아니라 변경 내용에 묶여 있어서, 줄이 밀려도 남고 에이전트가 그 부분을 다시 고치면 풀립니다. 아래는 개발팀이 v0.2.0 소개 글에 실은 변경 단위별 검토 화면입니다:

개발팀이 직접 밝힌 제약도 있습니다. 턴 하나만 보는 화면은 읽기 전용이라 유지 버튼은 브랜치 diff에서만 동작하고, 400줄 넘게 바뀐 파일이나 잠금 파일, 생성된 파일은 접힌 상태로 열립니다. 파일과 diff에 줄 단위 리뷰 코멘트를 남겨 구조화된 컨텍스트로 대화에 보낼 수도 있습니다. 에이전트는 추측하는 대신 대화 안에서 객관식 질문을 던질 수 있고, v0.2.0 이후 main에서는 UI 변경을 제안할 때 diff처럼 코멘트를 달 수 있는 전후 비교 목업도 보여 줍니다. 에이전트와 사용자가 함께 고치는 TODO 계획에서는, 완료한 단계의 변경이 그 단계만의 것으로 확인되면 단계별로 따로 커밋되고 독립된 리뷰어가 검토할 수 있습니다. 대화 하나가 동시에 띄울 수 있는 서브에이전트 수는 1에서 16 사이로 설정하며 기본값은 4입니다.

ThinkRail의 스펙 그래프

ThinkRail은 그 자체를 스펙 우선으로 개발하고, ThinkRail로 여는 프로젝트도 스펙 주도 개발(Spec-Driven Development, SDD) 방식으로 작업하도록 돕습니다. 스펙 주도 개발은 구조화된 명세를 먼저 쓰고, 코딩 에이전트가 그 명세를 기준으로 코드를 만들고 검증하게 하는 방식입니다. ThinkRail에서는 모듈마다 코드 옆에 SPEC.md를 두고, 각 파일 맨 앞의 YAML 헤더에 적은 식별자로 서로를 참조하게 해서 하나의 스펙 그래프를 만듭니다. 개발팀이 블로그에서 제안한 헤더 형식은 다음과 같습니다:

---
id:   # a unique id, this is how other specs reference this one
type: # goal-and-requirements | architecture-design | module-design | submodule-design | task-spec
title: # full title
status: # draft | active | stale | done | deprecated
parent: # the id of the spec directly above it in scope
depends-on: # the ids of other SPEC.md files important to this one
tags: # tags describing the contents
---

id, type, title이 필수이고 나머지는 필요할 때만 씁니다. 에이전트는 작업하는 코드에 가장 가까운 SPEC.md를 중심으로 읽고 다른 스펙은 필요할 때만 찾아 읽으므로, 컨텍스트가 한 번에 커지지 않습니다. ThinkRail에 함께 들어 있는 pi-spec-graph 확장이 스펙을 검색, 탐색, 수정하는 spec_* 도구를 에이전트에게 제공합니다. 오른쪽 Specs 도구는 이 그래프를 접고 펼 수 있는 트리로 보여 줍니다. 아래 화면은 ThinkRail 저장소 자체의 스펙 트리와 제품 목표 스펙입니다:

ThinkRail 저장소에서는 루트의 goal-and-requirements.md와 architecture.md가 제품과 설계의 기준 문서이고, 경계나 계약, 결정을 바꾸는 변경은 같은 변경 안에서 스펙도 함께 고칩니다. v0.2.0에서는 설계 인터뷰가 기본 동작으로 돌아왔습니다. 기능 추가, 동작 변경, 버그 수정은 아무리 작아도 에이전트가 사용자에게 질문하는 단계로 시작하고, 검토 후 버린 대안도 보여 주어야 합니다. 스펙은 구현이 끝난 뒤 에이전트가 직접 고칩니다. 동작을 바꾸지 않는 오타, 문서, 설정 수정과 기계적인 리팩터링만 이 단계 없이 바로 진행됩니다.

ThinkRail과 Pi의 호환 범위

ThinkRail은 Pi의 스킬과 확장을 자동으로 인식합니다. 스킬은 ~/.pi뿐 아니라 ~/.claude, ~/.codex, ~/.copilot, ~/.gemini에서도 찾고, Pi와 Claude, Gemini는 프로젝트 안의 해당 폴더도 함께 찾습니다. 다른 코딩 에이전트용으로 만들어 둔 Agent Skills 형식의 스킬을 복사하지 않고 그 자리에서 읽어 쓰는 방식입니다. 다만 개발팀은 블로그에서 세 가지 주의 사항을 밝혔습니다:

ThinkRail이 내장한 Pi와 따로 설치한 Pi의 버전이 다를 수 있어, 일부 스킬과 확장이 제대로 동작하지 않을 수 있습니다.
Pi의 터미널 화면을 바꾸는 확장(테마 등)은 동작하지 않습니다.
같은 도구 이름을 등록한 확장이 둘이면 Pi가 충돌을 보고하고, 불러온 순서로 사용할 쪽이 정해집니다.

첫 번째 항목과 관련해, 2026년 10월 28일 기준 main이 고정한 Pi 버전은 1.4.0이고 v0.2.0 안정판에는 Pi 1.2.0이 들어 있습니다.

저장소가 에이전트에 끼워 넣을 수 있는 것은 신뢰 승인 전까지 불러오지 않습니다. 신뢰하지 않은 프로젝트에서는 그 저장소의 .pi 설정과 확장, 스킬, 프롬프트, SYSTEM.md를 읽지 않습니다. 신뢰 안내 창은 신뢰하면 무엇을 불러오게 되는지 이름으로 보여 줍니다.

MCP(Model Context Protocol) 서버는 사용자의 mcp.json에서 읽어 Pi의 내장 MCP 엔진으로 실행합니다. 데이터를 바꿀 수 있는 호출은 대화 안의 도구 카드에서 인자 목록과 함께 거부, 한 번 허용, 이 대화에서 허용, 항상 허용 중 하나를 고르게 합니다. 저장소가 .pi/mcp.json으로 정의한 서버는 실행할 명령을 사용자가 승인하기 전까지 시작하지 않습니다. 항상 허용 기록은 저장소 파일이 아니라 프로젝트 기록에 저장되고, 서버의 명령이나 URL이 바뀌면 초기화됩니다. 저장소가 미리 승인된 상태로 배포될 수 없게 한 설계입니다.

아래는 MCP 호출 승인 화면입니다:

모델 제공자는 Pi의 인증을 그대로 쓰며, ThinkRail 자체 계정은 없습니다. JetBrains AI 계정으로 로그인하려면 사용자의 JetBrains central CLI가 필요합니다. ThinkRail은 이 CLI가 만든 Pi 확장으로 JetBrains AI 모델을 불러오고, 할당량 표시를 켜 두면 central quota로 남은 AI 크레딧을 따로 읽어 상단에 표시합니다. 다른 기기의 브라우저에서 호스트에 접속하는 경우, 접근 제어는 앱의 로그인 화면이 아니라 Tailscale의 ACL(Access Control List) 같은 네트워크 계층에 맡기도록 설계되어 있습니다(architecture.md).

ThinkRail 설치와 사용

ThinkRail을 실행하려면 PATH에 git이 있어야 하고, 앱에서 JetBrains AI로 로그인하거나 Pi가 지원하는 제공자의 자격 증명이 있어야 합니다. 데스크톱 앱은 릴리스 페이지에서 운영체제에 맞는 thinkrail-desktop-* 파일을 받아 설치합니다. Linux 데스크톱 빌드는 glibc 2.38 이상과 GTK 3, WebKitGTK 4.1이 필요하므로 Ubuntu 24.04 이상을 기준으로 합니다.

CLI는 설치 스크립트가 맞는 바이너리를 내려받아 SHA-256 체크섬을 확인한 뒤 ~/.local/bin에 두고, 셸 설정 파일에 PATH를 추가합니다. macOS와 Linux(Windows의 Git Bash 포함)에서는 다음 명령으로 설치합니다:

curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash

Windows의 cmd와 PowerShell에서는 다음 명령을 씁니다:

powershell -c "irm https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.ps1 | iex"

설치가 끝나면 프로젝트로 열 Git 저장소 경로를 넘겨 실행합니다. 브라우저에 ThinkRail 화면이 열립니다:

thinkrail ~/code/my-repo

nightly 채널은 bash -s -- --channel nightly로 설치하고, thinkrail update로 갱신합니다. thinkrail uninstall은 실행 파일과 PATH 항목을 지우고 ~/.thinkrail 앱 데이터는 기본으로 남깁니다. 작업 공간 워크트리도 ~/.thinkrail/worktrees 아래에 있으므로, --remove-data로 앱 데이터까지 지우기 전에는 커밋하지 않은 작업 공간 변경이 없는지 확인해야 합니다.

플랫폼별로 확인할 점이 두 가지 있습니다. 첫째, main의 README 설치 안내에는 macOS Intel용 DMG가 있지만 2026년 10월 28일 기준 v0.2.0과 최신 nightly(v0.3.0-nightly.7) 릴리스 파일에는 macOS용이 Apple Silicon(darwin-arm64)뿐입니다. Intel용 데스크톱 빌드는 10월 26일 main에 병합되었으나 아직 릴리스 파일로 올라오지 않았고, 설치 스크립트도 Intel Mac에서는 존재하지 않는 thinkrail-darwin-x64 파일을 찾게 됩니다. 둘째, JetBrains는 Windows용 실행 파일에 서명합니다. macOS CLI는 서명만 되어 있고 공증(Notarization)은 아직 받지 않았으며, Linux 파일은 서명되어 있지 않습니다.

ThinkRail은 실행, 대화 생성, 메시지 전송, 제공자 연결 같은 기본 사용 이벤트를 무작위 설치 ID와 함께 PostHog로 보냅니다. v0.2.0 이후 main에서는 오류 보고(오류 종류와 오류 코드, ThinkRail 자체 코드 안의 발생 위치)도 항상 보내도록 바뀌었습니다. 개발팀은 여기에 프롬프트, 코드, 파일, 자격 증명, 계정 정보는 포함되지 않는다고 밝히고 있으며, README에는 기본 이벤트와 오류 보고를 끄는 방법이 안내되어 있지 않습니다.

그 밖의 추가 사용 데이터 공유는 첫 실행 때 표시되는 창의 스위치로 정하는데, 저장소의 테스트 코드(e2e/analytics-consent.spec.ts)를 보면 이 스위치는 켜진 상태로 나오고 창을 그냥 닫아도 켜짐으로 저장됩니다. 추가 공유를 원하지 않으면, 첫 실행 창에서 스위치를 끄거나 나중에 Settings → Privacy에서 꺼야 합니다. CLI로 실행할 때는 thinkrail --no-analytics 또는 THINKRAIL_NO_ANALYTICS=1로 그 실행에서만 추가 공유를 끌 수 있습니다.

ThinkRail의 라이선스

ThinkRail은 Apache-2.0 라이선스로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다.

ThinkRail 공식 홈페이지

ThinkRail 프로젝트 GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임에서 이런 글들을 계속 정리하고 있습니다. 회원 가입으로 주요 글들을 이메일로, 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로 새 글 알림을 받아보세요!

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~