JetBrains ThinkRail, 코딩 AI의 기억을 명세로 남기다

코딩 에이전트가 프로젝트를 오래 기억하면 개발이 쉬워질까. 기억의 양만 늘면 오래된 전제가 더 오래 남을 수도 있다. JetBrains의 인큐베이터 프로젝트 ThinkRail은 프로젝트 지식을 코드 옆의 명세 파일로 유지하고 작업을 별도 worktree로 나누는 접근을 제시한다.

ThinkRail이 제공한다고 설명하는 기능

2026년 10월 26일 확인한 공식 저장소의 README에 따르면 ThinkRail은 pi 코딩 에이전트에 풍부한 작업 인터페이스를 결합한 에이전트형 IDE다. Monaco 편집기, 파일 트리, 터미널, 변경점 보기와 여러 채팅을 작업 공간 안에서 제공한다.

프로젝트를 열고 Git worktree를 생성하면 각 작업이 별도 브랜치와 디렉터리를 갖는다. 변경점에 리뷰 의견을 달고 이를 대화의 구조화된 문맥으로 보낼 수 있다. GitHub PR의 검사와 리뷰 상태도 인터페이스에 표시한다고 설명한다.

제품은 데스크톱 앱과 브라우저에서 여는 CLI 형태를 제공한다. 웹 인터페이스가 있다는 것이 프로젝트 코드가 자동으로 특정 클라우드에 업로드된다는 의미는 아니다. 다만 실제 모델 호출의 데이터 경로는 선택한 공급자와 설정에 달려 있다. 이 기사는 저장소 문서 분석이며 설치 후 성능을 측정한 리뷰가 아니다.

살아 있는 명세는 자동 기억과 무엇이 다른가

ThinkRail은 코드 옆에 연결된 SPEC.md 그래프를 두고 에이전트가 전용 도구로 읽고 검색하며 유지하도록 한다. 설계 문서와 제품 요구사항은 구조를 검토할 수 있는 출발점이다.

명세가 파일로 남는다면 사람도 diff를 검토하고 버전 관리할 수 있다. 반대로 에이전트가 코드를 바꾸면서 잘못된 설명까지 동시에 갱신하면 그럴듯하지만 틀린 명세가 생긴다. 문서의 존재가 곧 정확성을 보장하지 않는다.

팀이 얻을 수 있는 이점은 ‘모델이 알아서 배운다’는 추상적 약속보다 의도와 변경 이력을 확인할 수 있다는 데 있다. 요구사항 변경, 테스트 결과, 구현 변경을 같은 리뷰에서 연결해야 한다. 원문의 향후 자체 기능 확장 구상과 현재 제공 기능도 구분해서 읽어야 한다.

worktree는 충돌을 줄이지만 보안 샌드박스는 아니다

Git worktree 문서가 설명하듯 하나의 저장소에 여러 작업 트리를 둘 수 있다. 병렬 에이전트가 같은 체크아웃을 동시에 수정하는 문제를 줄이는 데 도움이 된다. 성공한 브랜치를 병합하고 필요 없는 작업을 정리하기도 쉽다.

그러나 디렉터리와 브랜치가 나뉜다고 프로세스 권한, 네트워크, 파일 접근, 공유 데이터베이스까지 격리되는 것은 아니다. 동일한 사용자 계정으로 실행되는 터미널이나 도구가 어떤 자원에 접근할 수 있는지는 별도 설정이다. 제품 문서의 ‘isolated workspaces’를 운영체제 수준의 완전한 보안 경계로 번역하면 과장이다.

Docker Agent의 실행 재현성에서 다룬 환경 정의와 Scion의 저장소 병목은 서로 보완되는 문제다. 작업 분리, 실행 재현, 최종 병합의 품질은 각각 검증해야 한다.

IDE 경쟁은 모델보다 검토 흐름으로 이동한다

README는 모델과 스킬, 세션 상태, 비용 관리의 상당 부분을 pi가 담당하고 ThinkRail이 작업 공간과 편집기, 연결 인터페이스를 담당한다고 설명한다. 이는 독자적인 모델 성능만으로 경쟁하는 제품과 다른 구조다. 공식 제품 사이트도 확인할 수 있지만, 기능 상태는 해당 시점의 릴리스와 문서를 기준으로 판단하는 편이 낫다.

한국 개발팀의 평가 질문은 ‘어느 모델이 더 많은 코드를 만드나’에서 ‘여러 작업을 얼마나 쉽게 검토하고 되돌릴 수 있나’로 넓어질 수 있다. 코드 증가와 리뷰 병목처럼 생성량이 늘어도 검토가 따라오지 않으면 완료 시간은 줄지 않는다.

작은 저장소에서 작업 두세 개를 나누고, 명세와 구현이 함께 바뀌는지, 서로 다른 작업의 충돌을 발견할 수 있는지, 실패한 작업을 안전하게 닫을 수 있는지부터 평가할 수 있다. 이는 도입 제안이지 ThinkRail의 생산성 향상이 실증됐다는 뜻이 아니다.

한국어 환경도 확인할 항목이다. 확인한 README는 기본 제공 언어로 영어와 간체 중국어를 명시하고, 별도 번역 파일을 추가하는 방식을 설명한다. 에이전트 답변 언어와 UI 번역은 다른 문제다. 기본 사용 이벤트와 오류 보고, 추가 공유 설정도 구분해 검토해야 하며, 추가 공유를 끄는 옵션을 모든 통신이 중단되는 기능으로 해석해서는 안 된다.

자주 묻는 질문

JetBrains의 기존 IDE를 대체하는 정식 제품인가?

공식 저장소는 인큐베이터 프로젝트로 표시한다. 기존 IDE 전체의 대체 가능성이나 장기 지원을 문서만으로 확정할 수 없다.

worktree를 쓰면 에이전트가 다른 파일에 접근하지 못하나?

그렇지 않다. 작업 파일을 분리하는 기능과 실행 권한을 제한하는 보안 기능은 다르다.

명세는 한 번 만들면 끝인가?

아니다. 요구사항과 구현이 바뀔 때 함께 검토해야 한다. 오래된 명세는 오히려 잘못된 전제를 반복시킬 수 있다.

한국어로 쓸 수 있나?

답변 언어는 사용하는 모델과 지시에 영향을 받는다. README의 기본 UI 언어 목록에는 한국어가 없으며 별도 번역 확장 방식을 설명한다.

도입 성공은 무엇으로 측정하나?

코드 줄 수보다 리뷰 소요 시간, 재작업, 명세 불일치, 병합 후 결함을 비교하는 편이 적절하다. 같은 과제를 기존 흐름과 나란히 평가해야 한다.