젯브레인스가 공개한 씽크레일(ThinkRail)은 'pi'라는 코딩 에이전트를 핵심에 둔 에이전트형 IDE다. 최근 등장한 다수의 'AI 코딩' 도구들이 기존 에디터에 챗봇 패널을 덧붙이는 방식이었다면, 씽크레일은 에이전트를 먼저 놓고 그 주위에 편집기와 작업 공간을 세운 구조라는 점이 다르다. 공식 설명은 이 도구를 '쓸수록 좋아지는' IDE로 규정한다. 오늘은 리빙 스펙(living spec)을 통해 프로젝트를 학습하고, 앞으로는 사용 방식에 맞춰 스스로 기능을 만들어내는 방향으로 발전시키겠다는 것이 개발진의 선언이다.
작업을 격리하고 지식을 축적하는 구조
실무자 입장에서 눈여겨볼 지점은 에이전트가 변경 작업을 다루는 방식이다. 씽크레일은 각 세션의 작업을 별도의 깃 워크트리(git-worktree) 기반 워크스페이스로 격리한다. 에이전트가 코드를 고치더라도 현재 브랜치나 작업 트리를 직접 흔들지 않고 독립된 공간에서 변경을 만든 뒤 확인할 수 있다는 의미다. 여러 에이전트 작업을 동시에 돌리거나, 결과를 비교하고 취사선택해야 하는 상황에서 충돌을 줄여주는 설계다.
또 하나의 축은 '리빙 스펙'과 재사용 가능한 스킬이다. 씽크레일은 프로젝트에 대한 지속적 지식을 에이전트에게 부여하기 위해 스펙을 문서로 유지한다. 실제로 이 프로젝트 자체가 스펙 우선(spec-first)으로 개발된다. 모든 모듈 옆에 SPEC.md가 놓이고, 경계·계약·설계 결정을 바꾸는 변경은 같은 커밋에서 스펙도 함께 갱신하도록 규율화되어 있다. goal-and-requirements.md와 architecture.md가 제품과 설계의 기준 문서 역할을 한다. 다음 단계로는 전면적인 확장(extension) 지원을 추가해, 사용자의 실제 작업 패턴에 맞는 도구를 에이전트가 직접 만들어내도록 하겠다는 로드맵을 제시한다.
얇은 호스트와 세 겹의 고리
내부 구조는 비교적 명확하게 공개돼 있다. 씽크레일은 pi를 인프로세스(in-process)로 실행하고 이를 풍부한 웹 UI에 연결하는 '얇은 호스트'다. 모델, 스킬, 컨텍스트 압축(compaction), 비용, 세션 상태는 pi가 소유하고, 작업 공간과 에디터, 그리고 둘을 잇는 통신 계층은 앱이 담당한다. 특히 앱이 사용자 몰래 프롬프트를 조립하지 않는다는 점을 명시한 대목은, 에이전트 도구에서 흔히 불투명하게 처리되는 프롬프트 가공 과정을 경계한 설계 의도로 읽힌다.
배포는 두 가지 형태로 이뤄진다. 네이티브 데스크톱 설치본과 자체 완결형 thinkrail CLI이며, 둘 다 릴리스 페이지에 SHA256SUMS와 함께 게시된다. 데스크톱 빌드는 macOS 애플 실리콘(인텔 빌드 없음), 윈도우 x64, 리눅스 x64/ARM64를 지원하는데, 리눅스는 glibc 2.38 이상과 GTK 3, WebKitGTK 4.1 등을 요구해 사실상 우분투 24.04 이상이 전제다. CLI 설치 스크립트는 플랫폼에 맞는 바이너리를 내려받아 체크섬을 검증하고 PATH에 등록한다. 구동에는 git과 모델 제공자가 필요하며, JetBrains AI로 로그인하거나 자체 제공자 자격 증명을 쓸 수 있다. 안정(stable)·나이틀리(nightly) 채널과 백그라운드 자동 업데이트도 갖췄다.
도입 전 따져볼 한계
프라이버시 처리는 상대적으로 보수적이다. 실행·채팅 생성·메시지 전송·제공자 연결 같은 기본 사용 이벤트는 무작위 설치 ID에 묶여 수집되지만, 프롬프트·코드·파일·자격 증명·계정 식별자는 포함하지 않는다고 못 박는다. 오류 리포트도 오류 유형과 코드, 발생 위치만 보내며 프로젝트 내용은 담지 않는다. 추가 사용 데이터 공유는 선택이며, 명령줄에서 --no-analytics로 끌 수 있다.
다만 실무 도입을 검토한다면 몇 가지 제약은 분명히 인식해야 한다. 코드 서명 상태가 플랫폼마다 고르지 않다. 윈도우 CLI와 데스크톱 설치 실행 파일은 서명돼 있으나 macOS CLI는 서명은 됐어도 아직 공증(notarize)이 되지 않았고, 리눅스 아티팩트는 서명되지 않는다. 과거 배포된 DMG나 로컬 빌드는 게이트키퍼에 막힐 수 있다. 플랫폼 요구사항도 최신 환경에 맞춰져 있어 구형 리눅스나 인텔 맥 사용자는 사실상 배제된다.
정리하면 씽크레일은 완성된 상업 제품이라기보다, 에이전트를 1급 시민으로 둔 IDE가 어떤 모습일 수 있는지를 보여주는 공개 실험에 가깝다. 워크트리 격리와 스펙 기반 지식 축적, 투명한 프롬프트 처리라는 아이디어는 사내 개발 도구를 설계하는 팀에게도 참고할 만한 지점이다. 반면 '스스로 기능을 만드는 IDE'라는 가장 야심 찬 목표는 아직 로드맵 단계이므로, 지금 시점의 평가는 실제 리빙 스펙과 워크스페이스 흐름이 일상 작업에서 얼마나 매끄럽게 작동하는지에 맞추는 편이 현실적이다.