AI가 생성한 README가 있는 저장소는 진지하게 받아들이기 어려움. README조차 직접 쓰지 않았다면, 또 무엇을 소홀히 했을지 의심하게 됨. 참고로 Pangram에서는 AI 작성 확률이 100%로 나옴.
그게 왜 중요한지 모르겠음. 개인적으로는 구분도 못 하지만, 구분할 수 있더라도 AI가 어떤 인간보다 완전하고 정확한 정보를 제공했을 가능성이 훨씬 높다고 봄.
중요한 건 README의 품질이지 누가 썼는지가 아님. README 자체는 평가하지 않고 머릿속으로 추정한 작성자만 비판한다면, 정작 무엇을 더 소홀히 하고 있는 걸까?
Pangram 결과가 무슨 상관인지 모르겠고, 나는 신경 쓰지 않음. AI 작성 여부를 탐지하는 건 불가능함. AI가 아니라 케냐 사람이 쓴 글일 수도 있지 않을까? https://marcusolang.substack.com/p/im-kenyan-i-dont-write-li....
굳이 직접 읽을 필요가 있을까? 에이전트에게 저장소를 넘기고 자신에게 맞춘 프로젝트 탐색 스킬을 쓰면 됨.
왜 AI 생성을 곧 소홀함으로 받아들이는지 모르겠음. 설계 문서와 명세, 기존 저장소 전체를 에이전트에게 주고 X, Y, Z를 담은 README를 만들라고 하면 무엇이 문제일까?
저품질 생성물을 거부한다고 해서 AI가 만든 글 전체를 거부할 필요는 없음.
JetBrains IDE를 10년 넘게 썼지만, 여러 워크트리를 동시에 다루는 일이 너무 답답하고 비효율적이라 요즘은 거의 열지 않음. AI 전략도 갈피를 못 잡고, 불투명하고 비싼 토큰을 팔려는 데 집착하는 것도 납득하기 어려움. 제대로 방향을 잡기를 바람.
약 12년 만에 구독을 해지함. 설정에 신경 쓰지 않아도 잘 돌아가는 도구, 리팩터링, 코드 탐색처럼 장점이던 기능들이 이제는 별로 필요하지 않다는 걸 깨달았기 때문임.
지금은 주로 내 지시에 따라 에이전트가 코드를 작성하고, 에이전트 실행 도구나 GitHub에서 검토함. 한동안 IDE를 열지 않았고, 필요할 때도 Zed 정도면 충분했음.
워크트리 지원은 아주 최근에 급하게 끼워 넣은 듯하고, 실제로도 잘 작동하지 않음. 워크트리마다 IDE 프로젝트 목록에 중복 항목이 생기고, 프로젝트 설정도 공유되지 않으며, 전환할 때마다 기존 솔루션을 여는 대신 어떤 프로젝트를 열지 다시 물어봄.
대체로 훌륭한 IDE들이 이런 기본 작업 흐름에서 완전히 실패한다는 게 황당함. 이를 구현한 제품 책임자와 개발자들이 무슨 생각이었는지 궁금함.
나도 그렇게 생각했지만, GitHub 패널의 탭 안에 전용 워크트리 전환기가 숨어 있다는 걸 알게 됨. 이제 각 워크트리를 독립 프로젝트처럼 별도 창으로 열 수 있고, 이게 내가 99%의 상황에서 원하는 방식임.
다만 AI 보조 개발에는 쓰지 않으며, 확실히 AI 에이전트보다는 사람을 위한 기능임.
아주 오랫동안 유료 사용자였지만, 이제는 Claude Code와 Codex가 일을 해주니 JetBrains가 더는 필요하지 않음. 이 회사의 AI 전략은 도무지 이해할 수 없었음.
제품은 좋아하지만 기능 비대화와 설계 부채가 문제임. AI 도구는 지나치게 눈앞에 들이밀면서도 성능은 기대 이하라, 구독을 갱신할지 모르겠음.
이런 새로운 IDE가 왜 필요한지 모르겠음. 대부분 워크트리·샌드박스·탭·프롬프트를 묶은 것으로, 결국 git·docker·tmux·사고 과정에 해당함. IDE가 정해 놓은 방식에 에이전트를 묶어두기보다 이 도구들을 제대로 배우는 편이 더 만족스럽고 효과적일 것임.
비슷한 제품이 쏟아지는 이유도 여기에 있음. 만들기가 그리 어렵지 않고, 방법을 알아내면 누구나 자신이 천재처럼 느껴지며, AI 시대에 이력서를 채우기에도 좋기 때문임.
JetBrains가 최근에 JetBrains Air를 출시하지 않았나? 구현만 다를 뿐 기본 발상은 거의 같아 보임. 서로 경쟁하는 제품을 계속 내놓는 게 전략인가? https://www.jetbrains.com/air/
몇 년 전 Fleet 개발을 시작해 알파 버전을 몇 차례 내놓더니, 정식 출시도 하기 전에 접어버림. 이유는 사실상 기존 핵심 IDE에 집중하겠다는 것이었는데, 무엇이 달라졌는지는 제대로 설명하지 못함.
Fleet에 관심이 있었던 터라 이후의 신제품도 회의적으로 보게 됨. Fleet을 중단한 논리가 다른 거의 모든 제품에도 적용될 수 있어 보이기 때문임.
추측하자면 기존 IDE 판매의 장기 수익성을 확신하지 못하는 것 같음. 개발 비용은 저렴하니 가능한 제품을 던져 보고, 반응이 없는 것은 없애려는 듯함.
Air는 전략 제품, Thinkrail은 실험적 제품에 가까워 보임. 둘 다 에이전트 기반 개발 도구지만, Air는 여러 에이전트 관리에, Thinkrail은 명세 우선 개발에 초점을 맞춘 듯함.
JetBrains가 쇠퇴하면서 생존을 위해 안간힘을 쓰는 듯함. 제품은 좋아했지만, 개인적으로는 에이전트로 모든 일을 처리하는 것 외에 한 단계 진보한 개발 경험은 아직 보이지 않음.
jj에 겨우 익숙해지자마자 모두가 git 워크트리에 빠져든 듯한 느낌임.
최신 jj는 워크스페이스 기능의 일부로 Git과 같은 위치를 사용하는 워크트리를 지원함.
여기서 jj가 무엇인가?
AI IDE의 문제는 대부분의 기업용·팀 계정으로 이용할 수 없다는 것임. API를 써야 해서 기업용 요금제보다 비용이 최대 10배까지 들 수 있음. JetBrains를 좋아하고 오랫동안 썼지만, 이제 일상 업무의 99%는 iTerm과 Sublime에서 처리하게 됨.
에이전트를 컨테이너 밖에서 실행하는 건 무모해 보임. 적어도 에이전트나 작업마다 별도의 마이크로VM 또는 컨테이너를 띄워야 함.
수년째 JetBrains 전체 제품 패키지를 구독하고 있지만, 지금 가장 원하는 건 플러그인 기반 IDE 통합이나 Fleet이 거의 구현했던 가벼운 범용 편집기임. 에이전트 덕분에 예전에는 엄두도 못 냈던 언어로 작업하게 되면서 RustRover, Rider, WebStorm, IntelliJ를 동시에 여는 일이 흔해짐. MCP를 통한 코드 분석 기능이 코딩 에이전트에 도움이 되는지도 궁금함. 효과가 있다면 화면 없는 MCP 서버 형태라도 좋은 코드 분석 기능에는 계속 돈을 낼 의향이 있음. Air가 그 방향으로 가는 줄 알았는데 또 접어버렸고, 이제 플러그인이 되면서 다시 특정 IDE에 종속되는 형태로 돌아감.
Intelligence는 유료 제품이라 시험해 볼 수 없음. 에이전트가 지금처럼 코드를 더듬거리며 수정하는 대신 코드 분석과 제대로 된 리팩터링 지원을 제공하는 것이 IntelliJ의 바로 다음 단계라고 봄.
에이전트가 무엇을 왜 하는지, 어떤 추론을 거쳤는지 이해할 수 있는 기능도 필요해 보임. 동시에 훌륭한 IDE로 남아주길 바람. 여전히 필요하며, 우리 대규모 코드베이스에서는 에이전트들이 갈피를 못 잡고 결함만 만들어내고 있음.
로컬 모델과 OpenAI 호환 API 지원은 어디에 있나? Pi 에이전트가 호환되는 대상은 더 많음.