성능 세금: 개발자들이 JetBrains를 떠나 가벼운 에디터를 선택하는 이유

많은 개발자에게 통합 개발 환경(IDE)의 선택은 단순한 선호도를 넘어 일상적인 워크플로우의 근본적인 부분입니다. 수년 동안 JetBrains는 심층적인 정적 분석부터 정교한 디버깅까지 모든 것을 처리하는 포괄적인 도구 모음을 제공하며 전문적인 개발의 표준으로 자리 잡아 왔습니다.

하지만 개발자 커뮤니티 사이에서 '모든 것을 하나로' 해결하는 방식이 한계에 부딪히기 시작했다는 의견이 늘어나고 있습니다. 고성능의 가벼운 에디터와 무거운 IDE 사이의 격차가 벌어짐에 따라, 많은 이들이 스플래시 화면이나 재인덱싱 주기를 기다리는 인지적 비용이 더 이상 제공되는 기능 세트의 가치를 상회한다고 느끼고 있습니다. 이러한 변화는 최근 Hacker News에서 화제가 된 토론에서 잘 드러나는데, 한 개발자가 새로운 Zed 에디터를 사용하기 위해 JetBrains와 '결별'한 과정을 상세히 설명했습니다.

"무거운" 도구의 마찰

JetBrains를 떠나는 개발자들이 언급하는 주요 불만 사항은 기능의 부족이 아니라 성능 오버헤드입니다. 도구가 '모든 것'을 해결하는 솔루션으로 설계될 때, 종종 프로그래머의 몰입 상태(flow state)를 방해할 수 있는 리소스 세금이 부과됩니다.

일반적인 고충은 다음과 같습니다:

  • 시작 및 프로젝트 로딩: "지독하게" 느린 시작 시간과 스플래시 화면은 업무를 시작하는 데 심리적 장벽을 만듭니다.
  • 인덱싱 피로도: 지속적이고 종종 불투명하게 진행되는 코드베이스의 재인덱싱은 CPU 코어를 점유하고 시스템 전체를 느리게 만들 수 있습니다.
  • UI 반응성 저하: 현대적인 하드웨어에서도 새 파일을 생성하거나 제안 상자를 보는 것과 같은 간단한 작업이 지연되는 것처럼 느껴질 수 있습니다.
  • 리소스 소비: 높은 RAM 사용량과 매일 IDE를 재시작해야 하는 메모리 누수 현상이 발생합니다.

고성능 사양의 머신(Ryzen 9950x, 64GB RAM)을 사용하는 한 개발자는 최상급 하드웨어에서도 WebStorm이 "고통스러울 정도로 느리다"고 언급했습니다. git commit 시 코드 분석에 몇 분이 걸리고, TypeScript 에러가 새로고침되는 데 최대 30초가 소요된다고 합니다.

"속도 우선" 에디터의 부상

이와 대조적으로, Zed, Helix, Neovim과 같은 에디터들은 반응성을 최우선으로 하여 인기를 얻고 있습니다. 목표는 생각과 화면에 나타나는 결과 사이의 간격을 없애는 것입니다.

"한순간은 터미널에서 즐겁게 작업하고 있습니다. 1초 뒤에는 제가 원하는 모든 도구를 갖춘 풀 기능 에디터를 보고 있습니다. 그것이 성능의 기준이자 기대치입니다."

이러한 "즉시 실행" 경험은 새로운 벤치마크가 되고 있습니다. 프로젝트를 자주 전환하거나 터미널 중심의 워크플로우를 사용하는 개발자들에게, 프로젝트를 1초 만에 여는 능력은 혁신적인 생산성 향상을 가져다줍니다. 이는 일부 개발자들이 '하이브리드' 방식을 채택하도록 이끌었습니다. 즉, 대부분의 작업은 가벼운 에디터로 수행하고, 무거운 IDE는 특정하고 복잡한 디버깅 작업에만 사용하는 방식입니다.

AI 통합의 갈등

성능을 넘어, AI가 개발 경험에 어떻게 통합되는지에 대해서도 긴장이 고조되고 있습니다. AI 어시스턴트는 강력하지만, 많은 개발자들은 JetBrains 제품의 현재 구현 방식이 방해된다고 느낍니다.

비판론자들은 AI 제안이 UI를 어지럽히거나 타이핑 흐름을 방해한다고 주장하며, 일부는 이 경험을 "불쾌하거나" "품위가 없다"고고 설명합니다. AI가 코드 라인 중간에 제안을 밀어넣는 방해 요소가 아니라, 측면이나 커넥터를 통해 접근할 수 있는 지원적인 도구로서 존재하기를 바라는 명확한 요구가 있습니다.

반론: 진정한 IDE의 가치

이러한 불만 사항에도 불구하고, 많은 개발자들은 텍스트 에디터가 아무리 빠르더라도 풀 기능 IDE를 대체할 수 없다고 주장하며 JetBrains에 충성도를 유지하고 있습니다. 도구의 깊이, 특히 디버거와 대화형 라이브 스택 편집(interactive live stack editing) 기능은 여전히 강력한 매력 요소입니다.

일부 사용자들은 성능 문제를 설정(configuration)을 통해 완화할 수 있다고 제안합니다. JVM 설정을 조정하고, 할당된 RAM을 늘리는 것(예: Xms=4g) 방식, 그리고 ZGC (Z Garbage Collector)를 사용하는 것이 환경의 반응성을 크게 개선할 수 있습니다. 이 사용자들에게는 몇 초의 로딩딩 시간이라는 트레이드오프는 통합된 도구 세트의 엄청난 강력함에 비해 작은 비용입니다.

결론: 에디터의 미래

"무거운 IDE"와 "가벼운 에디터" 사이의 논쟁쟁은 개발자가 코드와 상호작용하는 방식의 더 넓은 변화를 반영합니다. LSP(Language Server Protocols)와 LLM의 부상과 함께, 단순한 텍스트 에디터와 풀 기능 IDE 사이의 경선계가 흐려지고 있습니다.

개발자들이 점점 더 몰입(flow)과 반응성을 우선시함에 따라, legacy IDE들은 성능을 급격히 최적화하거나, 속도를 일급 시민(first-class feature) 속성으로 다루는 새로운 세대의 도구들에게 사용자 기반을을 잃을 위험을 처면면합니다.

Sources