JetBrains ThinkRail: pi 코딩 에이전트를 기반으로 구축된 에이전틱 IDE

JetBrains가 ThinkRail을 공개했습니다. 이는 오픈소스 "에이전틱 IDE"로, pi 코딩 에이전트를 풍부한 워크벤치에 통합하고 각 작업을 자체 git worktree로 격리합니다. JetBrains 브랜드의 IDE이면서도 JetBrains 자체 편집기 엔진을 사용하지 않는다는 점에서 주목할 만합니다. UI는 Monaco, 런타임은 Bun, 에이전트는 JetBrains가 구축한 모델 스택이 아닌 타사 npm 패키지입니다.

프로젝트는 github.com/JetBrains/thinkrail에 있으며 Apache 2.0 라이선스로 배포됩니다. 저장소에는 "JetBrains 인큐베이터 프로젝트" 배지가 있으며, README는 ThinkRail을 "사용할수록越来越好 — 오늘은 living specs를 통해 프로젝트를 학습하고, 내일은 자체 역량을 구축하는 에이전틱 IDE"라고 설명합니다. 프로젝트 전용 사이트는 thinkrail.ai, 블로그는 thinkrail.ai/blog입니다.

ThinkRail이 실제로 무엇인가

ThinkRail은 pi 코딩 에이전트를 프로세스 내에서 실행하고 웹 UI에 연결하는 얇은 호스트입니다. README는 책임 분담을 명시적으로 밝힙니다: "pi는 모델, 스킬, 압축, 비용, 세션 상태를 소유하고, 앱은 워크스페이스, 편집기, 연결을 소유합니다 — 앱은 사용자 몰래 프롬프트를 조합하지 않습니다."

에이전트는 npm 패키지 @earendil-works/pi-coding-agent입니다. ThinkRail은 워크스페이스 모델, 편집기, 채팅 인터페이스, 그리고 이들 간의 프로토콜을 추가합니다. 명시된 로드맵은 "완전한 확장 지원으로, ThinkRail이 사용자의 실제 작업 방식에 따라 필요한 도구를 직접 만들 수 있게 하는 것"입니다.

격리된 워크스페이스가 핵심 추상화

ThinkRail의 핵심 설계 결정은 모든 에이전트 작업이 작업 체크아웃이 아닌 별도의 git worktree에서 실행된다는 것입니다. 모든 git 저장소를 프로젝트로 열고 git worktree로 워크스페이스를 분할할 수 있으며, 각 워크스페이스는 자체 브랜치와 작업 디렉터리를 가지므로 에이전트는 체크아웃을 건드리지 않고 병렬로 작업할 수 있습니다. 기존 worktree를 연결하거나 프로젝트 폴더 자체에서 명시적으로 작업할 수도 있습니다.

완료되었거나 휴면 상태인 워크스페이스는 "풀 리퀘스트가 병합되거나 닫히면, 또는 조용한 한 주가 지나면 자동으로 프로젝트별 선반에 정착하며, 작업을 시작하는 순간 다시 돌아옵니다." 상단 바에는 활성 브랜치가 origin 및 해당 풀 리퀘스트와 비교하여 어디에 있는지 표시되며, 게시, 푸시, PR 열기 작업이 한 번의 클릭으로 가능합니다. PR 설명은 계획, 커밋, PR 템플릿 또는 에이전트가 작성한 초안에서 초안을 작성할 수 있습니다. GitHub PR이 열리면 ThinkRail은 CI 검사와 리뷰 결정을 표시하고, 준비 완료로 표시하거나, 실패한 검사나 분기된 브랜치를 에이전트에 넘기거나, 저장소에서 마지막으로 사용한 방법으로 병합하거나, 다시 열거나, 원격 브랜치를 삭제할 수 있습니다.

편집기는 Monaco이지 JetBrains 엔진이 아님

ThinkRail의 워크벤치는 분할 가능한 레이아웃의 Monaco 편집기 탭, 실시간 git 변경 마크가 있는 파일 트리와 변경 보기, 터미널, 문서로 구성되며 모두 활성 워크스페이스에 범위가 지정됩니다. 파일과 diff에 고정된 리뷰 주석을 남기고 구조화된 컨텍스트로 채팅에 보내거나 설치된 IDE에서 worktree를 열 수 있습니다.

이 세부 사항은 Hacker News에서 가장 많은 비판을 받았습니다. 댓글 작성자 @theptip는 다음과 같이 썼습니다:

음, 이건 대부분 2025년에 최첨단일 것 같네요. 그리고 왜 Monaco를 사용하려는 건가요? JetBrains 생태계에 있다면 그들의 IDE를 VSCode보다 선호하기 때문 아닌가요? 버전이 지정되고 연결된 스펙 기능은 다소 흥미로워 보이지만요.

댓글 작성자 @tiku는 더 직설적으로 말했습니다: "JetBrains가 vs code를 사용한다니 정말 슬프네요." 또 다른 댓글 작성자 @TehCorwiz는 같은 점을 지적하며 JetBrains 자체 엔진을 선호한다고 말했습니다: "이건 VSCode 기반인 것 같네요, 그들의 일반적인 엔진 대신에. 그것에 대해 복잡한 감정이 있습니다. 저는 실제로 그들의 엔진을 좋아합니다."

채팅, 계획, 스펙

ThinkRail은 워크스페이스당 여러 동시 pi 세션을 지원하며, 각 세션은 자체 모델과 실시간 토큰 및 비용 표시를 가집니다. 진행 중인 턴을 조종하거나 후속 작업을 큐에 넣거나, 서브에이전트에 위임하거나, 에이전트가 업데이트하고 사용자가 편집하는 공유 계획을 작업할 수 있습니다. 각 완료된 단계는 자체적으로 커밋하고 검토할 수 있습니다.

세션 간 컨텍스트 손실에 대한 프로젝트의 답변은 "living specs"입니다: 코드 옆에 있는 연결된 SPEC.md 파일 그래프입니다. 에이전트는 전용 spec_* 도구를 통해 이 그래프를 읽고, 검색하고, 유지 관리하며, 읽기 전용 Specs 도구는 워크벤치에서 트리로 렌더링합니다. ThinkRail 자체도 스펙 우선으로 개발됩니다 — 모든 모듈 옆에 SPEC.md가 있으며, 경계, 계약 또는 결정을 변경하는 변경 사항은 동일한 변경에서 스펙을 업데이트합니다. 표준 제품 및 설계 스펙은 goal-and-requirements.md 및 architecture.md입니다.

한 댓글 작성자 @photios는 SPEC.md 형식과 워크플로우에 대해 더 자세히 알아볼 곳을 물었고, thinkrail.ai/blog/thinkrail-sdd/에서 답을 찾았습니다.

스킬, MCP 서버, 에이전트 도구

다른 코딩 에이전트를 위해 이미 보유하고 있는 이식 가능한 에이전트 스킬은 제자리에서 읽힙니다. 번들된 워크플로우는 프로젝트 설정, 설계 브레인스토밍, 풀 리퀘스트 출시를 안내하며 — 워크스페이스 브랜치를 푸시하고 자체 gh를 통해 GitHub PR을 열거나 업데이트합니다.

셸 외에도 에이전트는 웹 리서치와 다이어그램, 옵션 비교, 파일 미리보기를 채팅에서 직접 인라인 렌더링합니다. 에이전트가 UI 변경을 제안하면 diff처럼 주석을 달 수 있는 before/after 목업을 표시합니다. 설정 → 확장에는 에이전트가 받는 ThinkRail 확장이 나열되며 각각을 끌 수 있습니다.

MCP 서버는 pi mcp.json에서 오거나 설정에서 추가할 수 있으며, 몇 가지 사전 설정이 포함됩니다. ThinkRail은 서버가 읽기 전용으로 표시하지 않은 호출 전에 채팅에서 묻고(또는 프로젝트에서 신뢰하는 도구를 항상 허용), 저장소가 정의한 서버는 승인할 때까지 유지하며, 설정에서 OAuth 서버에 로그인하고, 각 채팅의 서버를 백그라운드 명령 및 서브에이전트 옆에 표시합니다.

공급자 및 자격 증명

ThinkRail에는 자체 계정이 없습니다. JetBrains AI로 로그인하거나 pi의 자체 인증을 통해 모든 공급자를 연결할 수 있습니다. 댓글 작성자 @lousken은 지원 범위에 의문을 제기했습니다: "로컬 모델 지원과 그냥 openai 호환 API 지원은 어디에 있나요? Pi 에이전트는 더 많은 것과 호환됩니다."

설치: 데스크톱 앱 및 CLI

ThinkRail은 두 가지 추가 형태로 제공됩니다 — 네이티브 데스크톱 설치 프로그램과 자체 포함된 thinkrail CLI — 둘 다 릴리스 페이지에 SHA256SUMS와 함께 게시됩니다.

데스크톱 빌드는 macOS Apple Silicon(DMG, Intel 데스크톱 빌드 없음), Windows x64(전체 setup ZIP을 추출하고 그 안의 setup 실행 파일을 제자리에서 실행), Linux x64/ARM64(setup tarball을 추출하고 installer 실행)용으로 제공됩니다. Linux 데스크톱 빌드는 glibc 2.38+와 GTK 3, WebKitGTK 4.1, Ayatana AppIndicator 3, librsvg 2가 필요하므로 Ubuntu 24.04 이상, 패키지 libgtk-3-0 libwebkit2gtk-4.1-0 libayatana-appindicator3-1 librsvg2-2가 필요합니다.

CLI 설치 프로그램은 올바른 바이너리를 다운로드하고 SHA-256 체크섬을 확인한 다음 thinkrail을 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"

그런 다음 thinkrail을 실행하고, 선택적으로 프로젝트로 열 git 저장소를 지정합니다: thinkrail ~/code/my-repo. CLI는 PATH에 git과 모델 공급자(앱에서 JetBrains AI 로그인 또는 자체 공급자 자격 증명)가 필요합니다. thinkrail --help는 플래그를, thinkrail --version은 빌드를 출력합니다.

설치 프로그램은 --channel stable|nightly 및 --version을 허용하며, 고정 버전은 선택한 채널에 속해야 합니다. Windows에서 이러한 옵션은 환경 변수입니다: THINKRAIL_CHANNEL, THINKRAIL_VERSION, THINKRAIL_PREFIX, THINKRAIL_NO_MODIFY_PATH. thinkrail update는 설치된 채널에 대해 설치 프로그램을 다시 실행하고 <prefix>/bin/thinkrail[.exe]를 교체합니다. thinkrail uninstall은 실행 파일, 설치 프로그램이 추가한 PATH 항목, 설치 메타데이터를 제거하고 ~/.thinkrail 앱 상태를 삭제할지 묻습니다 — 기본적으로 유지되며, --remove-data로 삭제하고 -y로 질문을 건너뜁니다.

패키지된 안정 및 야간 데스크톱 빌드는 백그라운드에서 업데이트를 확인하고 설정 → 업데이트에서 제공하며, 다운로드 → 업데이트 준비 → 설치 및 다시 시작 흐름을 따릅니다. 사용자가 설치 및 다시 시작을 선택하기 전에는 아무것도 적용되지 않습니다. 업데이트 프로그램은 패키지에 유효한 HTTPS 피드 ID가 있을 때만 나타납니다. 해당 ID 이전의 설치본은 먼저 수동 설치가 필요합니다.

플랫폼 및 서명 참고 사항

JetBrains는 Windows CLI, 데스크톱 setup 실행 파일, 데스크톱 앱이 설치하는 모든 실행 파일과 DLL에 서명합니다. macOS CLI는 서명되었지만 아직 공증되지는 않았습니다. 서명되고 공증된 데스크톱 DMG는 조정된 JetBrains 서비스 파이프라인이 필요하므로 이전에 게시된 DMG와 로컬로 빌드된 패키지는 여전히 서명되지 않아 Gatekeeper에 차단될 수 있습니다. Linux 아티팩트는 서명되지 않습니다. 사전 빌드된 macOS Intel CLI는 없습니다 — 소스에서 빌드해야 합니다.

아키텍처: 세 개의 링

ThinkRail은 세 개의 레이어로 구성됩니다:

  • 엔진 호스트 — packages/server(+ packages/shared): Bun.serve HTTP+WS 호스트로, 채팅당 하나의 인프로세스 pi 세션을 가지며 apps/cli 또는 apps/desktop에 의해 시작됩니다.
  • 연결 — packages/contracts: 호스트와 UI 간의 타입이 지정된 버전 프로토콜.
  • UI 클라이언트 — apps/web: React 19 + Zustand + Tailwind v4, 독립적으로 제공되며 연결을 통해 호스트에 연결하고 계약에만 의존합니다.

데스크톱 앱과 브라우저 CLI 모두 동일한 엔진 호스트를 포함하며, 앱 상태는 ~/.thinkrail 아래에 있습니다. 소스에서 빌드하려면 Bun 1.4.4(고정 패키지 관리자이자 런타임), Node.js ≥ 22.19(인프로세스 pi 엔진에 필요), 에이전트 작업을 위한 인증된 pi 공급자가 필요합니다. README의 개발 명령은 bun install, bun run dev(호스트와 웹 클라이언트 동시), bun run build:binary(독립 CLI 아티팩트), bun run desktop:dev / bun run desktop:build(Electrobun 앱)입니다.

Bun 의존성은 @photios의 반응을 불러일으켰습니다: "그리고... 왜 bun인가요?! 방금 모든 시스템에서 제거했는데, 하! 일반 pnpm 지원이 있으면 좋겠네요."

현지화

설정 → 언어는 시스템 언어 또는 선택한 언어를 따릅니다. 영어와 중국어 간체가 내장되어 있습니다. ThinkRail이 아직 제공하지 않는 언어는 번역된 en.json을 ~/.thinkrail/locales에 넣어 추가할 수 있으며, 저장하면 적용됩니다. 에이전트 응답과 도구 출력은 에이전트가 작성한 그대로 유지됩니다.

분석 및 개인정보 보호

ThinkRail은 기본 사용 이벤트(실행, 채팅 생성, 메시지 전송, 공급자 연결)를 수집하며 임의의 설치 ID에 연결됩니다. 사용 분석에는 프롬프트, 코드, 파일, 자격 증명 또는 계정 ID가 포함되지 않습니다. 오류 보고서는 항상 전송되며 동일한 설치 ID에 연결되고 오류 유형과 코드 및 ThinkRail 자체 코드에서 발생한 위치를 포함합니다. 오류 메시지, 파일 경로, 이름, URL 또는 프로젝트나 확장의 어떤 것도 포함하지 않습니다.

추가 제품 사용 데이터 및 ThinkRail을 찾은 경로는 "추가 사용 데이터 공유"가 켜져 있을 때만 공유됩니다. 이 스위치는 첫 실행 시 제공되며 설정 → 개인정보 보호에 있습니다. thinkrail --no-analytics(또는 THINKRAIL_NO_ANALYTICS=1 설정)를 실행하면 해당 실행에 대해 추가 공유가 꺼집니다. 추가 공유가 켜진 경우 패키지된 빌드는 설치를 사용자를 데려온 웹사이트 방문에 연결하기 위해 ThinkRail 블로그를 브라우저에서 한 번 열 수 있습니다 — 웹사이트에서 마케팅 쿠키를 수락했거나 동의가 필요하지 않은 경우에만 — 그리고 링크는 30일 후 만료됩니다.

Hacker News 댓글 작성자들이 반박한 점

토론은 대체로 회의적이었으며 몇 가지 뚜렷한 비판이 반복되었습니다.

README 자체가 의문시되었습니다. 댓글 작성자 @exizt88은 다음과 같이 썼습니다: "AI 생성 README가 있는 저장소를 진지하게 받아들이지 않겠습니다. README를 작성하지 않았다면, 또 무엇을 하지 않았을까요? (Pangram에 따르면 100% AI라고 합니다)"

JetBrains의 다른 AI IDE 노력과의 중복. @Deukhoofd가 물었습니다: "JetBrains가 최근에 JetBrains Air를 출시하지 않았나요? 이것은 기본적으로 같은 전제인데 구현만 다른 것처럼 보입니다. 그들의 전략은 무엇인가요, 경쟁 제품을 출시하는 건가요?" @rcr-anti는 JetBrains 전체 제품 팩을 오랫동안 구독해온 사용자로, "모든 IDE를 플러그인으로 통합하거나 Fleet이 가까워졌던 것 같은 더 가벼운 범용 편집기"를 원한다고 말하며, "Air로 그 방향으로 가는 줄 알았는데 또 죽었네요. Air는 이제 플러그인이지만 다시 특정 IDE로 돌아간 셈이죠."라고 덧붙였습니다.

worktree 플러스 에이전트 패턴은 새롭지 않습니다. @sigotirandolas는 주장했습니다: "이런 새 IDE의 요점을 모르겠습니다. 대부분 worktree+sandbox+tabs+prompts일 뿐인데, 이는 git+docker+tmux+생각하기일 뿐입니다. 그러나 IDE가 취하는 방식에 에이전트를 묶지 않고 실제로 이러한 도구를 사용하는 법을 배우면 훨씬 더 행복하고 효과적일 것입니다. (그래서 이런 IDE가 많은 이유이기도 합니다: 그렇게 어렵지 않고, 알아내면 모두 천재처럼 느껴지며, AI 시대에 이력서를 쌓는 좋은 방법이기 때문입니다.)"

격리가 불충분합니다. @collimarco는 다음과 같이 썼습니다: "컨테이너 밖에서 에이전트를 실행하는 것은 나에게 미친 짓으로 보입니다... 적어도 각 에이전트/작업에 대해 별도의 마이크로VM이나 컨테이너를 시작해야 합니다."

엔터프라이즈 청구 마찰. @hkchad는 말했습니다: "모든 AI IDE의 문제는 대부분 엔터프라이즈/팀 계정에서 사용할 수 없고, API를 사용해야 하며 이는 엔터프라이즈 플랜보다 최대 10배 더 비쌀 수 있다는 것입니다. 저는 JetBrains를 정말 좋아하고 오랫동안 사용해왔지만, 이제는 하루의 99%를 iterm과 sublime으로 보내고 있습니다."

Worktree 대 다른 버전 관리 워크플로우. @VMG는 관찰했습니다: "jj에 익숙해진 바로 다음 날 모두가 git worktree에 집착하게 된 느낌입니다."

기존 제품에 대한 충성도, 단서 포함. 10년 넘게 JetBrains IDE를 사용해온 @dr_faustus는 "여러 worktree에서 동시에 작업하는 것이 매우 답답하고 낭비적이기 때문에 더 이상 자주 열지 않는다"고 말하고, 회사의 AI 전략이 "여기저기 흩어져 있고" "불투명하고 비싼 토큰"이라고 비판했습니다. @throwaw12는 "JetBrains가 죽어가고 있으며 매우 열심히 살아남으려고 하는 것 같다"고 말했고, @johnhamlin은 간단히 "여전히 이들을 응원합니다"라고 썼으며, @jwpapi는 "시도해볼 의향이 있다"고 말했습니다.

경쟁 도구가 언급되었습니다. @aliasxneo는 "oh-my-pi와 Paseo를 떠나려면 강하게 설득해야 할 것"이라고 말했습니다. @dangoodmanUT는 출시가 늦었다고 평가했습니다: "JetBrains가 마침내 깨어나 2024년의 Cursor 경쟁 제품을 더 이상 팔 수 없다는 것을 깨닫는 것을 보니 좋네요. JetBrains가 새 IDE를 작성한다는 것은 대담해 보입니다... 맞는 느낌인지 확실하지 않지만요."

기여 및 라이선스

기여는 저장소의 CONTRIBUTING.md(검사, 종단 간 스위트, 데스크톱 패키징, 저장소 레이아웃 포함) 및 행동 강령에 따라 관리됩니다. ThinkRail은 Apache License 2.0에 따라 라이선스가 부여됩니다.

Sources