요약
JetBrains Thinkrail은 코딩 에이전트 pi를 중심에 둔 가벼운 오픈소스 IDE입니다.
젯브레인스가 사내 인큐베이터 프로젝트로 GitHub에 공개한 데스크톱·브라우저용 IDE입니다. AI 코딩 에이전트와 함께 일하는 흐름에 맞췄고, 쓸수록 사용자의 작업 방식에 맞게 스스로 바뀌는 IDE를 목표로 내세웠습니다.
왜 중요한가
- 기존 IDE와 별도로, 젯브레인스가 에이전트와의 대화를 중심에 둔 가벼운 개발 도구를 직접 내놓았습니다.
- 자체 계정이 없어서 JetBrains AI 대신 pi가 지원하는 다른 AI 제공자를 연결해 쓸 수도 있습니다.
- 작업마다 git worktree(한 저장소의 여러 브랜치를 폴더별로 동시에 펼쳐 두는 기능)를 따로 만들어 에이전트 여러 개를 나란히 돌리기 쉽습니다.
핵심 내용
- 작업 공간마다 브랜치를 따로 두고, 상단 바에서 푸시, PR 생성, CI 확인, 병합까지 처리합니다.
- 한 작업 공간에서 pi 세션 여러 개를 동시에 열 수 있고, 세션마다 모델과 토큰 비용을 따로 보여 줍니다.
- 코드 옆에 SPEC.md 명세 파일을 두고 에이전트가 직접 고쳐 나가는 '명세 우선' 개발 방식을 씁니다.
- 확장 기능을 열어 IDE가 사용자에게 필요한 도구를 스스로 만들게 하는 것이 다음 목표라고 밝혔습니다.
- Apache 2.0 라이선스로 공개됐고, 맥·윈도·리눅스용 데스크톱 앱과 명령줄 도구를 제공합니다.
HN 반응
- README를 AI가 썼다며 젯브레인스답지 않게 성의가 없다는 비판이 먼저 나왔고, 겉보다 코드를 보라는 반론도 있었습니다.
- 최근 나온 JetBrains Air와 겹친다는 지적과 함께, 중도에 접은 Fleet처럼 사라질 수 있다는 회의론도 많았습니다.
AI가 쓴 readme가 달린 저장소는 진지하게 받아들일 수 없어요. readme 하나 직접 쓰기 귀찮아했다면, 또 뭘 귀찮아서 안 했겠어요?
(참고로 Pangram 기준으로는 100% AI가 쓴 글입니다)
고맙네요, JetBrains. 앱이 내 뒤에서 몰래 프롬프트를 조립할 거라고 생각하고 있었는데, 친절하게 해명해 줘서 다행이에요.
제대로 읽어봤다면 이런 문장은 빠졌을 거예요. 작은 팀이나 바이브 코더, 개인 프로젝트, 아니면 (나중에 고치고 다듬고 개선할) 첫 커밋이라면 이해합니다.
그런데 JetBrains가요? 업계에 나쁜 신호라고 봅니다. 사람이 읽을 만한 문서 좀 모아 달라고 제대로 된 테크니컬 라이터 한 명 붙이는 게 그렇게 빌어먹게 어려운 일인가요? 그냥 성의가 전혀 안 느껴져요.
AI가 쓴 코드가 들어 있는 저장소는 진지하게 받아들일 수 없어요. 코드 하나 직접 쓰기 귀찮아했다면, 또 뭘 귀찮아서 안 했겠어요?
저장소 소유자 중에는 다른 사람이 올린 코드를 리뷰만 하고 본인은 아무것도 직접 쓰지 않는 경우도 있습니다. 리뷰 과정이 그대로라면 그게 문제가 됩니까? 잘못은 AI로 코드를 생성한 데 있는 것이 아니라, 리뷰 과정이 부실하거나 코드에 신경 쓰지 않거나 읽지 않는 데 있습니다. 그건 별개의 문제입니다.
readme 수정도 다른 사람들이 올립니다.
차라리 코드에 시간을 쓰고 readme는 AI한테 맡기세요. readme로 코드 품질을 판단하는 거라면, 아키텍처를 살펴보는 쪽이 프로젝트를 평가하는 더 나은 방법일 겁니다. 표지만 보고 책을 판단하는 것처럼 좀 피상적으로 보이네요…
정말 멍청한 소리네요. 애정을 쏟아서 직접 뭔가를 만들어 본 적이 없는 게 분명해요. 만들어 봤다면 지금 하는 말이 전혀 말이 안 된다는 걸 알았을 텐데요.
10년 넘게 JetBrains IDE를 써 왔지만 요즘은 거의 열지 않습니다. 여러 워크트리를 동시에 작업하는 게 정말 답답하고 비효율적이기 때문입니다. 그들의 AI 전략은 갈피를 못 잡고 있고, 늘 내용을 알 수 없는 데다 비싸기만 한 자사 토큰을 팔려고 했는데 말이 안 됩니다. 정신 좀 차렸으면 좋겠습니다.
저는 12년쯤 쓰다가 구독을 해지했습니다. IDE를 대단하게 만들어 주던 것들이 더는 별로 필요하지 않다는 걸 깨달았거든요. "그냥 알아서 잘 되는" 도구들, 리팩터링, 코드 사이 이동 같은 것 말입니다.
이제는 에이전트가 제 지시에 따라 코드를 주로 작성하고, 저는 그걸 하네스 안에서나 GitHub에서 리뷰합니다.
열어 본 지 한참 됐고, 정말 IDE가 필요할 때는 Zed 같은 것으로도 충분하고도 남았습니다.
제가 JetBrains 도구를 좋아한 이유 중 하나는 대규모 코드베이스에서의 탐색 기능과 깊이 있는 의미 분석이었습니다. Zed는 그 면에서 꽤 기본적인 수준입니다. 에이전트가 대체로 필요한 건 해 주지만, 궤도를 이탈하면 뒷정리가 만만치 않아집니다.
그래도 실력이 녹슬지 않도록, 제 프로젝트 중 일부는 AI를 쓰지 않고 직접 작업한다는 점은 인정합니다.
코드 리뷰가 제가 지금 해법을 찾으려고 애쓰는 문제입니다. GitHub PR은 한 번도 마음에 든 적이 없는데, 그럼 뭘 원하는지는 저도 100% 확신이 없어요. (어쩌면 그냥 VS Code 플러그인이면 될 것 같은 느낌인데… 사실 VS Code 인터페이스도 그다지 좋아하지 않을 수도 있고요?)
IntelliJ는 에디터 안에서 꽤 괜찮은 GitHub 코드 리뷰를 지원합니다. 수정된 코드와 리뷰 댓글을 거터에 보여 줍니다.
PR을 깊이 이해해야 할 때 저는 그걸 씁니다.
요즘은 linear를 써 보고 있어요. 티켓 시스템으로서 정말 마음에 듭니다. 그러다 PR 기능도 생겼더라고요… 당분간은 거기서 리뷰해 보려고요.
네, 워크트리 구현은 아주 최근에 급하게 끼워 넣은 거라 제대로 동작하지 않습니다. IDE 프로젝트 목록에는 워크트리마다 항목이 중복으로 생기고, IDE 프로젝트 설정은 워크트리 사이에 넘어가지 않고, 다른 워크트리로 전환할 때마다 이미 열어 둔 같은 솔루션을 그냥 열지 않고 어떤 프로젝트를 열 거냐고 또 묻습니다.
대체로 꽤 괜찮은 IDE 모음이 이 기본적인 워크플로에서 완전히 무너진다는 게 황당합니다. 이걸 구현한 프로덕트 오너와 개발자들은 대체 무슨 생각이었는지 정말 궁금합니다.
저도 여러 워크스페이스에서 동시에 작업해야 하는데, IDE 창 하나가 멈출 때마다 (가끔은 Tab 하나 입력했을 뿐인데도) 미칠 지경입니다. 그러면 전부 다 같이 멈춰 버리니까요.
JetBrains가 최근에 JetBrains Air를 출시하지 않았나요? 이것도 구현 방식만 다를 뿐 기본 전제는 사실상 같아 보이는데요. 여기서 그들의 전략이 뭔가요, 그냥 경쟁 제품을 연달아 내놓는 건가요?
https://www.jetbrains.com/air/
몇 년 전에는 Fleet도 개발을 시작해서 알파 버전을 몇 번 냈는데, 정식 출시도 되기 전에 접어 버렸죠. 이유라는 게 결국 "핵심 IDE에 집중하고 싶다"는 정도였는데, 그게 뭐가 달라졌다는 건지 설명이 되진 않았어요. 저는 Fleet에 관심이 있었기 때문에, 그 뒤로 나온 새로운 것들은 뭐든 의심스러울 수밖에 없어요. Fleet을 접은 논리가 다른 거의 모든 제품에도 똑같이 적용되지 못할 이유가 뭔지 모르겠거든요.
Fleet은 비극이었어요. 정말 기대했는데 영원히 작업 중(WIP)인 상태였죠.
그래도 어떻게 해도 곤란한 처지였을 것 같긴 합니다. AI 시대 이전에 개발을 시작했으니, 어느 쪽이든 방향을 틀어야 했을 거예요.
저는 그게 있었다는 것도 잊고 있었어요. 여러 번 써 봤지만 만족스럽지 않았고, 결국 더 나은 Zed로 갈아탔습니다. 아마 Zed가 Fleet을 죽였을 겁니다.
개선점과 새로 단장한 디자인 중 상당수는 기존 IDE로 "백포트"됐습니다.
그리고 Fleet은 VSCode 세대를 끌어들이려고 만든 거였습니다. 신규 사용자 증가세를 그쪽에 빼앗기기 시작하던 참이었으니까요. 하지만 이제 VSCode가 가장 큰 위협은 아닙니다.
그래요, 그런데 그 뒤로 나온 새 제품들에도 똑같은 일이 일어나지 말란 법은 없잖아요? 저한테 Fleet의 매력은 상당 부분 IDE 전체가 아니라는 점에 있었어요. 제가 보기엔 너무 무거운 것에 새 껍데기를 씌운다고 제가 그 IDE에서 느끼던 근본적인 문제가 해결되진 않습니다.
아, 이상적이진 않다는 데는 동의합니다. 하지만 새 IDE로 옮길 의향이 있던 사람들은 이제 IDE 자체를 가장 먼저 버릴 사람들이기도 합니다. 기존 IDE를 고수한 사람들이 구독료를 내는 쪽일 가능성이 크고요.
저는 사실 오늘날 (알파 단계지만 써 보면 인상적인) ArtCraft 앱들이나 Bun 같은 번역 사례를 보고 나니, Fleet보다 더 급진적인 일을 할 수 있다고 생각합니다. 여전히 최고의 전통적 IDE로 남으면서, 그들 특유의 똑똑함은 그대로 옮기고 무거운 부분은 많이 덜어내는 거죠. ArtCraft 앱들에서 인상 깊었던 건 원래 앱들에 비해 인터페이스가 얼마나 빠르고 가볍게 느껴지는가였어요.
제가 아는 한 Fleet이 바로 Air입니다. 이름만 바꾸고 AI 중심 워크플로를 더 추가한 거예요.
추측이지만, 풀 IDE를 파는 사업이 장기적으로 재정적 타당성이 있을지 확신이 없는 거겠죠. 개발 비용은 저렴하니까 일단 만들 수 있는 건 다 내놓고 뭐가 먹히나 보다가, 안 되는 건 접으려는 걸 겁니다.
문제는 그래 봤자 종말이라는 겁니다. 저는 그 제품의 기능 대부분을 쓰지 않으니, 가치를 놓고 경쟁하는 상대가 제 Claude 구독료인데요. 그건 제가 원하는 걸 정확히 만들어 주는 데 아주 능하거든요.
Air는 전략 제품이고 Thinkrail은 실험에 가까운 것 같습니다.
둘 다 "에이전틱 개발 도구"이긴 한데, Air는 주로 여러 에이전트를 관리하는 데 초점이 있고 Thinkrail은 명세 우선(spec-first) 개발을 다루는 것으로 보입니다.
JetBrains가 죽어 가고 있고, 살아남으려고 정말 필사적으로 애쓰는 것 같아요.
저는 그들의 제품을 좋아했습니다. 그리고 개인적으로는 모든 걸 에이전트로 처리하는 것 말고는, 아직 한 단계 더 높은 개발자 경험이라고 할 만한 건 보이지 않아요.
다음 제품도 똑같은 걸 더 만드는 데만 너무 집착합니다.
솔직히 오픈 하네스 중 하나를 골라서 그 팀을 인수 채용하고, 거기서부터 새로 시작하는 게 나을 겁니다.
맞아요. Opencode, OpenChamber, Cursor를 보세요. 그쪽이 그들이 가야 할 방향이고, 어제 갔어야 했어요.
요즘 제가 Rubymine을 열어 두는 유일한 이유는 습관 때문이고, git UI가 아직 마음에 들어서인데 매일 그럴 이유는 점점 줄고 있어요. 게다가 RAM도 엄청나게 먹고요. JetBrains, 제발 다른 곳들처럼 가볍고 채팅 우선인 IDE를 만들어 주세요.
사용량 통계가 곤두박질치는 걸 보고 당황하고 있을 가능성이 아주 높아 보입니다.