Eclipse에서 Zed로: 한 개발자의 에디터 진화사

평범한 근무일이었습니다.

3개의 프로젝트를 동시에 진행하고 있었습니다 -- Next.js 프론트엔드, FastAPI 백엔드, 그리고 Flutter 모바일 앱. VS Code는 5개의 창이 열려 있고, Chrome이 또 대량의 메모리를 잡아먹고 있습니다. 팬이 웅웅거리기 시작하고, 마우스가 끊기기 시작하고, 짜증이 밀려옵니다.

"고작 텍스트 에디터가 왜 3GB나 메모리를 먹는 거지?"

그 순간, 개발 도구를 다시 살펴볼 때가 되었다는 것을 깨달았습니다.

돌이켜보면, 첫 코드를 작성한 때부터 지금까지 에디터를 몇 번이나 바꿔왔습니다. 매번의 전환은 단순히 소프트웨어를 바꾸는 것이 아니라, 전체 작업 방식이 바뀌는 것을 의미했습니다.

Java 시대: Eclipse → IntelliJ IDEA

제 프로그래밍 인생은 Java에서 시작되었습니다. Microsoft의 동기화 기능 덕분에 몇 년 전의 학습 노트도 아직 찾을 수 있습니다.

프로그래밍을 배우기 시작했을 때, Eclipse는 Java 개발의 거의 표준 장비였습니다. 솔직히 말해서 Eclipse의 기능은 완비되어 있었지만, 그 시대의 Eclipse에는 독특한 "무거움"이 있었습니다 -- 시작이 느리고, UI가 촌스럽고, 플러그인은 쉽게 충돌합니다. Eclipse를 열 때마다 소형 서버를 기동하는 기분이었습니다.

그 후, 이것저것 시도하다가 IntelliJ IDEA를 발견했습니다.

처음 열었을 때 놀랐습니다. 코드 자동 완성이 이렇게 똑똒할 수 있다니? 리팩토링이 이렇게 매끄러울 수 있다니? 전에 Eclipse에서 십여 개 파일을 수동으로 수정하던 리팩토링 작업이, IntelliJ에서는 단축키 하나로 완료되었습니다.

그 느낌은 노키아에서 아이폰으로 바꾼 것과 같았습니다.

하지만 솔직히 Java는 그리 오래 배우지 않고 Python으로 전향했습니다. 그래도 IntelliJ의 경험은 JetBrains에 대한 좋은 인상을 남겼고, 이후 자연스럽게 전체 제품군으로 확장되었습니다. 프론트엔드는 WebStorm, Python은 PyCharm, 데이터베이스는 DataGrip. 각 IDE에는 특정 언어에 특화된 깊은 최적화가 있어 정말 쾌적했습니다. 나중에 VS Code로 전환한 후에도, 이 JetBrains 제품들은 계속 컴퓨터에 설치해 두었습니다. 거의 열지 않지만 삭제할 마음은 들지 않았습니다.

풀스택으로의 전환

전환점은 풀스택 개발을 시작했을 때 찾아왔습니다.

풀스택이란 모든 것을 조금씩 알아야 한다는 뜻입니다. 백엔드에서 Python을 쓰고, 프론트엔드에서 Vue와 React를 배우고, 모바일에서 Flutter를 다루고, 가끔 Shell 스크립트를 쓰고, 거기에 Docker와 각종 설정 파일 등 잡다한 것들이 산더미입니다. 언어가 늘어나면서 도구를 바꿔야 할지 고민하기 시작했습니다. 물론 IntelliJ IDEA 자체도 플러그인으로 많은 언어를 지원할 수 있지만, 역시 너무 무겁습니다. 게다가 개인적으로는 블록을 쌓아가듯 직접 조금씩 개발 환경을 구축해가는 느낌이 좋지, 미리 전부 갖춰진 IDE를 사용하는 것과는 다릅니다.

"범용" 에디터가 필요했습니다.

VS Code를 찾기 전에 다른 것들도 시도해 보았습니다.

Sublime Text를 다운로드해서 사용해 보았는데, 확실히 빠르지만 내용이 너무 간소했습니다. 유일한 장점이 빠르다는 것뿐이고, 다른 면에서는 JetBrains와의 격차가 너무 컸습니다. Notepad++도 봤지만, 그것은 그저 고급 메모장이지 제가 원하는 개발 도구가 아니었습니다.

VS Code의 황금시대

VS Code의 등장이 제 문제를 완벽하게 해결해 주었습니다.

하나의 에디터에 다양한 플러그인을 설치하는 것만으로 모든 언어에 대응할 수 있습니다. Python에는 Pylance, Flutter에는 Dart 플러그인, Vue에는 Volar -- 모든 것이 하나의 창에서 완결됩니다.

그렇게 긴 "커스터마이징"의 여정이 시작되었습니다.

테마를 10번 이상 바꾸고, 아이콘 팩도 여러 세트를 시도하고, 단축키는 설정했다 바꾸고, 바꿨다 다시 설정합니다. 코드 스니펫, Git 플러그인, Docker 플러그인, 각종 Linter와 Formatter...... 어느새 200개 이상의 플러그인이 설치되어 있었습니다.

그 시절에는 VS Code의 커스터마이징 자체가 즐거움이었습니다. 커뮤니티와 포럼에서 편리한 플러그인을 찾아 돌아다니며, 하나 발견할 때마다 "보물을 발견한" 것 같은 흥분이 있었습니다. 솔직히 말해서, 플러그인 마켓은 정말 풍부하고, 어떤 것이든 확실하게 생산성을 향상시켜 줍니다 -- Python 개발 환경 플러그인만 해도 10개 이상은 설치했을 것입니다. 물론 vscode-pets 같은 독특한 플러그인도 있었습니다. 에디터 안에서 작은 애완동물을 키우는 것으로, 생산성과는 전혀 관계없지만 그냥 설치하게 됩니다.

모든 작업을 VS Code에 집약하기 위해 데이터베이스 플러그인의 유료 멤버십까지 구매했습니다 -- Database Client입니다. VS Code 안에서 직접 각종 데이터베이스에 접속하고, 데이터 미리보기와 조작이 가능한 매우 편리한 플러그인입니다. 이것을 도입한 후에는 DataGrip을 열 필요조차 없어졌습니다.

지금도 여전히 다양한 플러그인을 이것저것 다루고 있습니다. 이 커스터마이징 작업 자체가 즐거움의 일부입니다.

그것은 VS Code의 황금시대였습니다. 정확히 말하면, 도구 커스터마이징의 효율이 가장 높았던 시기이기도 했습니다.

AI 프로그래밍 시대의 도래

제가 처음 AI 프로그래밍을 접한 것은 GitHub Copilot을 통해서였습니다.

이동

당시 Copilot에는 아직 Chat 기능이 없었고, 코드를 작성할 때 다음에 무엇을 쓸지 살짝 제안해 주기만 했습니다. 주석 하나를 쓰면 자동으로 코드 한 단락 전체를 완성해 줍니다. 처음 봤을 때 정말 놀라웠습니다 -- 이것이 내가 무엇을 쓰려는지 어떻게 아는 거지?

물론, 지금 돌이켜보면 이것들은 이미 AI 프로그래밍의 기본 기능이 되었습니다.

이동

그 후 Cursor가 화제가 되었습니다. 솔직히 진입이 좀 늦었습니다. 당시 Copilot의 학생 패키지를 무료로 사용할 수 있었고, Cursor는 본질적으로 VS Code의 Fork이며, GitHub Copilot이야말로 진정한 의미에서 최초로 AI 프로그래밍에 착수한 것이었기 때문에, Copilot이 최고라고 계속 생각했고 전환할 동기가 없었습니다.

동료가 Cursor를 한번 써보라고 추천할 때까지는요.

다운로드해서 사용해 보니, VS Code 내 Copilot보다 훨씬 강력하다는 것을 알았습니다. 전체 상호작용이 더 매끄럽고, AI의 컨텍스트 이해도 더 깊습니다. Copilot이 왜 그런 결과물을 낸 것인지 정말 이해할 수 없습니다 -- 분명 먼저 시작했는데, 체험에서는 후발주자에게 밀리고 말았습니다.

그 후, Claude Code가 등장했습니다.

이동

Claude Code를 사용하여 코드를 작성하기 시작했을 때, 모든 것이 또 달라졌습니다. 이전의 코딩 흐름은: 에디터에서 작성 → 터미널에서 실행 → 에디터에서 수정이었습니다. 지금은: 터미널에서 AI에게 원하는 것을 전달 → AI가 작성 → 리뷰하기로 바뀌었습니다.

터미널 사용 빈도가 급증했습니다.

이전에 터미널은 npm run dev와 git push를 실행하는 곳에 불과했지만, 이제는 메인 프로그래밍 인터페이스가 되었습니다. 대부분의 시간을 Claude Code와의 대화에 쓰며, 코드를 작성하게 하고, 버그를 수정하게 하고, 리팩토링을 시킵니다. 에디터는 오히려 뒷전으로 밀려나 "코드를 보는" 도구가 되었습니다.

동시에 AI가 프로그래밍 속도를 높이면서, 동시에 진행하는 프로젝트 수도 늘어갔습니다. 전에는 한 달에 프로젝트 하나였지만, 지금은 3~4개를 동시에 병렬로 진행하기도 합니다.

이것이 직접적으로 다음 문제를 야기했습니다.

VS Code가 버텨내지 못하다

다중 프로젝트 동시 개발 + 200개 이상의 플러그인 = 재앙.

VS Code 창을 하나 더 열 때마다 수백MB의 메모리가 추가로 소비됩니다. 5개 창을 열면 가볍게 3GB를 돌파합니다. MacBook의 팬이 전력으로 회전하기 시작하고, UI가 끊기기 시작하고, 타이핑에도 지연을 느끼게 됩니다.

이것은 저만의 문제가 아닙니다. 인터넷에서 "VS Code high memory usage"를 검색하면 대량의 비슷한 불만을 찾을 수 있습니다. Electron 아키텍처 + 대량의 플러그인 + 다중 창에서는 메모리 폭발이 거의 필연적입니다.

다양한 최적화 방법을 시도했습니다 -- 사용하지 않는 플러그인 비활성화, Profile 기능으로 프로젝트별로 다른 플러그인 세트 로드, 백그라운드 프로세스 제한. 개선은 있었지만 근본적인 해결은 아니었습니다.

결국 VS Code는 Electron 기반 애플리케이션입니다. Electron이라는 것은 각 창이 완전한 Chromium 인스턴스를 실행한다는 뜻입니다. 5개 창을 열면 Chrome 5개를 여는 것과 같습니다.

터미널이 왕: Warp와의 만남

프로그래밍 작업의 대부분이 이미 터미널에서 이루어지고 있다면, 터미널 자체가 편리해야 합니다.

macOS 기본 Terminal은 너무 단순하고, iTerm2는 오래 사용했지만 약간 구식 느낌이 들었습니다. 그때 Warp를 발견했습니다.

이동

Warp의 첫인상은 빠르다는 것이었습니다. 시작이 빠르고, 렌더링이 빠르고, 반응이 빠릅니다. 그리고 Block 디자인 -- 각 명령어와 그 출력이 독립된 "블록"을 형성하여, 텍스트 에디터처럼 선택, 복사, 검색이 가능합니다.

일상적으로 사용하다 보면, 더 이상 돌아갈 수 없습니다. 몇 가지 세부 사항을 들어보면:

입력란이 진짜 에디터로, 멀티 커서, 구문 강조, 자동 완성을 지원합니다. 이전에는 터미널에서 긴 명령어를 잘못 입력하면 화살표 키로 조금씩 이동해야 했지만, 지금은 마우스로 잘못된 곳을 클릭해서 수정하면 됩니다 -- 당연하게 들리지만, 기존 터미널에서는 할 수 없었던 일입니다.

각 Block 우상단의 작은 버튼으로 출력 전체를 원클릭으로 복사할 수 있습니다. 이전에는 터미널 내의 텍스트를 선택하기 위해 마우스를 매우 정확하게 드래그해야 했고, 조금만 벗어나면 너무 많거나 적게 선택되었습니다. 지금은 그런 걱정이 전혀 필요 없습니다.

헤비 터미널 사용자에게 이러한 체험 향상은 매우 큽니다.

이 단계에서 제 워크플로는 이렇게 되었습니다: 90%의 시간은 Warp 터미널에서 Claude Code를 사용하여 프로그래밍하고, VS Code는 Git 이력을 확인해야 할 때만 엽니다 -- 주로 GitLens로 누가 언제 어떤 코드를 변경했는지 보기 위해서입니다.

Zed와의 만남

문제는 VS Code를 코드를 보기 위해서만 사용해도, 메모리 소비는 전혀 줄지 않는다는 것입니다.

어느 날 Twitter를 보다가 Zed를 발견했습니다. 클릭해서 보니 -- "A high-performance, multiplayer code editor from the creators of Atom and Tree-sitter". 창립 팀이 Atom 에디터의 원작자라는 점이 흥미를 끌었습니다.

다운로드, 설치, 실행.

빠릅니다. 매우 빠릅니다.

"왠지 빨라진 것 같다"는 정도의 빠르기가 아니라, "이것이야말로 에디터가 가져야 할 속도다"라는 빠르기입니다. 시작, 파일 열기, 검색, 점프, 모든 작업이 순식간에 완료됩니다.

구체적으로 얼마나 빠른가? 인터넷에는 다수의 성능 비교 데이터가 있습니다:

데이터 출처: Zed vs VS Code Performance Benchmark (2024)

Zed는 Rust로 작성되었으며, 네이티브 GPU 렌더링으로, Electron과 같은 오버헤드가 없습니다. 그래서 십여 개의 프로젝트를 동시에 열어도 메모리 합계가 VS Code 한 창 분량에도 미치지 않습니다.

또한 Zed는 최근 macOS 네이티브 창 탭 지원을 추가했습니다. 여러 프로젝트 창을 하나의 창으로 통합하고, 탭으로 전환할 수 있습니다. 저처럼 십여 개의 프로젝트를 동시에 여는 사람에게는, 데스크톱이 창으로 넘치지 않게 된 것이 정말 고맙습니다. 이 기능은 커뮤니티에서 오래전부터 요청하던 것으로, 드디어 실현되었습니다.

활성화 방법은 간단합니다. Zed의 settings에 "use_system_window_tabs": true 한 줄을 추가하면 됩니다. 재시작 불필요하고, 다음에 여는 창부터 자동으로 새로운 동작이 적용됩니다. macOS 시스템 환경 설정의 탭 동작(항상/사용 안 함/전체 화면 시)에도 자동으로 따르며, 시스템과 일관성을 유지합니다.

물론 솔직히 말하면, Zed에도 부족한 점은 있습니다. 가장 눈에 띄는 것은 플러그인 생태계입니다 -- 아직 초기 단계이며, VS Code에서 당연하게 사용하던 많은 플러그인을 Zed에서는 찾을 수 없습니다. GitLens 수준의 Git 시각화 도구도 없고, 일부 언어 지원도 아직 충분하지 않습니다.

하지만 저에게는 이것들이 치명적인 문제가 아닙니다. 왜냐하면 지금 에디터에 대한 핵심적인 요구는 두 가지뿐이기 때문입니다: 코드를 읽는 것과 가벼운 편집. 무거운 작업은 모두 Claude Code에 터미널에서 맡기고 있습니다.

현재 나의 워크플로

이 여정을 거쳐, 현재의 개발 도구 조합은 이렇게 되었습니다:

Zed + Claude Code -- 주력 개발 도구. Zed로 십여 개의 프로젝트를 동시에 열어도 전혀 문제없으며, 코드 읽기, 작은 수정, 정의로의 점프에 사용합니다. Claude Code도 Zed의 내장 터미널에서 직접 실행하여, 코드 작성, 버그 수정, 리팩토링까지 기본적으로 모두 하나의 창 안에서 완결됩니다.

Warp -- 터미널이 본래 있어야 할 역할로 돌아왔습니다. 다만 이 터미널은 지금까지 사용한 어떤 터미널보다 훨씬 편리하며, 진정한 의미의 모던 터미널입니다. 왜 각 OS에 기본 탑재된 터미널이 아직도 수십 년 전 그대로인지 전혀 이해할 수 없습니다. 물론 때로는 Warp에서 직접 Claude Code를 기동하여 작업하기도 합니다. 파일 패널과 Git 표시가 내장되어 있어 사용하기 편리합니다.

VS Code -- 가끔 게스트 출연. 주로 GitLens로 Git 그래프를 볼 때 사용합니다. 솔직히 사용 빈도가 점점 줄어들고 있습니다.

각자가 적재적소. Zed가 "읽기"와 "쓰기", Warp가 일상 명령어, VS Code가 "조사"를 담당합니다.

이 워크플로의 핵심 논리는: 에디터의 경량화, 터미널의 중점화입니다. AI 시대, 진정한 프로그래밍은 터미널에서 이루어집니다. 에디터에 요구되는 것은 편안하게 코드를 읽고, 빠르게 수정할 수 있는 것뿐입니다.

Claude Code를 사용하시는 분께는 "나의 Claude Code 모범 사례"에서 효율적인 사용 노하우를, "나의 Claude Code 품질 관리 워크플로"에서 AI 생성 코드의 품질을 보장하는 방법을 확인하시기를 권장합니다. Claude Code 뒤에 있는 설계를 깊이 이해하고 싶으시다면 "Claude 시스템 아키텍처 완전 해설"을 참고하세요.

마치며

에디터 진화의 여정을 돌아봅니다:

Eclipse → IntelliJ IDEA → JetBrains 제품군 → Sublime Text(스쳐 지나감) → VS Code + Copilot → Cursor → Claude Code + Zed + 터미널

매번의 전환은 기존 도구가 나빠져서가 아니라, 저의 작업 방식이 바뀌었기 때문이었습니다.

Java를 할 때는 IntelliJ가 최적해였습니다. 풀스택 다국어 개발을 할 때는 VS Code가 최적해였습니다. AI 시대 터미널 우선의 오늘날, Zed + Warp가 최적해입니다.

영원히 최고인 에디터는 없습니다. 있는 것은 현재의 워크플로에 가장 적합한 에디터뿐입니다.

만약 지금 "이 정도면 괜찮겠지"라고 느끼는 에디터를 사용하고 있다면, 스스로에게 물어보세요: 자신의 작업 방식은 이미 바뀌었는데, 도구는 아직 따라오지 못하고 있는 것은 아닌지?

도구는 사람을 위한 것입니다. 도구가 발목을 잡기 시작하면, 그것이 바꿀 때입니다.