IDE의 죽음?

개발자 작업의중심은 이동하고 있다. 사라지는 것이 아니라, 이동하고 있다. 하나의 창 안에서 줄 단위로 계속 편집하는 방식에서 벗어나, 계획을 세우고 파일을 다시 작성하고 테스트를 실행하며 검토를 위한 변경 사항을 제안할 수 있는 에이전트를 감독하는 방향으로 향하고 있다. 우리가 알고 있는 IDE는 소프트웨어 작업의 주된 도구가 아니게 되거나, 크게 진화할 수 있다.

나를 포함해 많은 개발자들이 이미 매일 사용하고 있는 여러 도구들, Conductor, Claude Code Web, GitHub Copilot Agent, Jules, Vibe KanBan, 심지어 cmux 전반에서 같은 변화가 계속 나타나고 있다. 제어 평면이 주된 표면이 되고 있고, 에디터는 그 아래에 있는 여러 도구 중 하나가 되고 있다.

Cursor는 방금 Glass를 출시했다. 이는 “에이전트와 함께 일하는 것을 명확하고, 직관적이며, 사용자가 통제할 수 있게” 만들기 위해 명시적으로 설계된 새로운 인터페이스로, 에이전트 관리가 핵심 경험이 되고 전통적인 에디터는 더 깊이 들어가야 할 때 찾는 도구가 된다. 개발자들의 반응은 즉각적이었다.

이제 Cursor는 IDE라기보다 Agent Orchestrator처럼 느껴진다. 에이전트를 병렬로 관리하기가 더 쉬워졌다.

하지만 Glass는 훨씬 더 큰 패턴 안의 하나의 데이터 포인트일 뿐이다. cmux 같은 터미널 UI는 우리가 익숙한 표면들이 에이전트 워크플로를 더 잘 관리하도록 어떻게 진화하고 있는지를 보여준다.

역사적으로 IDE는 긴밀한 내부 루프에 최적화되어 있었다. 파일 열기 → 편집 → 빌드 → 디버그 → 반복. “죽음”이라는 주장의 핵심은, 에이전트가 이 과정의 대부분을 자율적으로 실행할 수 있게 되면 이 루프가 더 이상 생산성의 지배적인 단위가 아니라는 데 있다.

새로운 루프는 이렇게 생겼다. 의도 명시 → 위임 → 관찰 → diff 검토 → 병합. 이것이 “채팅 창이 달린 자동완성”과 다른 이유는, 도구를 사용하는 자율성과 그 자율성을 통제 가능하게 만드는 인터페이스 설계가 결합되어 있기 때문이다.

이것이 이미 활발히 사용되는 여러 도구에서 어떻게 펼쳐지고 있는지도 볼 수 있다. Claude Code Web(또는 Desktop)과 Codex는 개발자가 잘 정의된 작업을 격리된 클라우드 환경에서 실행되는 에이전트에게 넘길 수 있게 해주며, 진행 상황은 브라우저에서 볼 수 있다. 터미널도, 로컬 설정도 필요 없다.

GitHub Copilot의 Agents는 다중 파일 변경을 독립적으로 계획하고 구현하며, 브랜치를 만들고, 테스트를 실행하고, 검토를 위한 PR을 띄운다. 개발자의 주된 일은 각 단계를 지시하는 것이 아니라 결과를 검토하고 반복 개선하는 일이 된다.

Conductor는 다른 접근을 취한다. 격리된 작업 공간에서 여러 Claude Code 에이전트를 동시에 실행할 수 있게 하는 데스크톱 앱이며, 모든 세션의 진행 상황을 실시간으로 모니터링할 수 있다. 그리고 Google의 Jules는 비동기 백그라운드 작업을 처리한다. 작업을 할당하면 실행하고, 끝나면 결과를 검토하면 된다.

이 도구들이 공유하는 정신 모델은 다음과 같다. 작업의 단위는 파일이 아니라 에이전트다. 최적화할 가치가 있는 인터페이스는 더 빨리 타이핑하게 도와주는 것이 아니라, 에이전트를 지시하고 모니터링하고 검토하도록 도와주는 것이다.

이 대체 서사가 설득력을 가지려면 여러 도구에서 수렴하고 있는 구체적인 인터페이스 패턴을 봐야만 한다.

기본 요소로서의 작업 격리. 병렬 에이전트는 서로의 작업을 방해하지 않아야 한다. 이 분야의 사실상 모든 진지한 도구는 git worktree(또는 유사한 방식)를 해답으로 채택했다. Conductor는 각 에이전트 세션을 고유한 격리 작업 공간에 매핑한다. Vibe Kanban(위 그림)은 칸반 기반 에이전트 워크플로에 대해 같은 방식을 사용한다. 이 패턴이 거의 어디에나 존재하는 이유는 문제가 현실적이기 때문이다. 격리가 없으면 병렬 에이전트는 혼란을 만들어낸다.

주된 UI로서의 계획과 작업 상태. Vibe Kanban 같은 도구는 최상위 정신 모델을 “탭과 파일”에서 “작업과 상태”로 바꾸었다. 작업 카드(랜딩 페이지, 백엔드 서비스, 이메일 통합)를 만들고, 각각을 에이전트와 모델에 할당한 뒤, 전체 작업을 가벼운 프로젝트 보드처럼 관리한다. 다만 “팀”이 자율적으로 실행된다는 점이 다르다. 이것은 구현을 수행하는 에이전트가 붙어 있는 프로젝트 관리 표면이다.

백그라운드 에이전트와 비동기 우선 설계. 이 분야에서 가장 흥미로운 몇몇 도구는 실행 중에 사용자를 루프 안에 붙잡아 두려 하지도 않는다. Cursor, Copilot, Antigravity는 사용자의 지속적인 참여 없이 실행되는 백그라운드 에이전트를 지원한다. 의도를 정의하고 자리를 떠난 뒤, 끝나면 검토하면 된다. Jules도 비슷하게 동작한다. 작업을 할당하고, 나중에 돌아와 diff를 본다. 암묵적인 약속은 당신의 주의력이 진행 막대를 바라보는 데 쓰기엔 너무 소중하다는 것이다. 이는 IDE의 실시간 동기식 피드백 루프에서 상당히 벗어난 변화다.

병렬 에이전트를 위한 주의력 관리. 많은 에이전트가 동시에 실행될 때, 진짜 병목은 지금 당장 어느 에이전트가 당신을 필요로 하는지를 아는 일이 된다. 이것이 바로 Conductor 같은 도구가 세션 전반의 실시간 진행 상황을 표시하고, cmux가 터미널 창을 위한 알림 링과 읽지 않음 배지를 도입한 이유다. “에이전트가 주의를 필요로 함”은 개발자 환경에서 일급 이벤트가 되고 있다. 그저 눈치채는 것이 아니라 라우팅하고 분류해야 하는 대상이 되는 것이다.

소프트웨어 생명주기에 내장된 에이전트. GitHub의 Copilot 코딩 에이전트는 비동기식이며, 제어 계층으로 보호되고, GitHub Actions로 구동된다. 즉 코드가 실제로 배포되는 방식(이슈 → PR → CI → 병합)에 연결되어 있지, 단지 코드가 작성되는 방식에만 연결되어 있는 것이 아니다.

이 도구들 중 어느 것도 IDE가 쓸모없어졌다고 주장하지는 않는다. 많은 도구가 여전히 IDE와 상호운용된다. 그러나 반복해서 나타나는 패턴들(병렬 작업 공간, diff 우선 검토, 작업 상태, 백그라운드 실행, 생명주기 통합)은 “IDE의 죽음”을 말하는 사람들이 무게중심의 이동을 언급할 때 정확히 의미하는 바다.

“IDE는 죽었다”라는 주장에 대한 가장 강한 비판은, IDE가여전히몇 가지 정말 어려운 문제를 고충실도 피드백 루프로 압축하고 있다는 점이다. 정확한 탐색, 로컬 추론, 대화형 디버깅, 그리고 시스템을 직접 조작하면서 그것을 _이해_할 수 있는 능력 말이다.

가장 야심찬 오케스트레이션 도구조차 수동 편집을 위한 탈출구를 남겨 둔다. 예를 들어 스레드 안에서 diff를 검토하고, 변경 사항에 코멘트를 달고, 그 다음 결과를 에디터에서 열어 수동으로 조정하는 식이다. 이는 인간의 개입이 의도된 워크플로의 일부라는 사실을 인정하는 것이다.

에이전트 도구 자체도 한계가 여전히 어디에 있는지를 드러낸다. 대규모 리포지토리에서의 다중 파일 리팩터링은 여전히 소프트웨어 엔지니어링 에이전트에게 가장 어려운 과제 가운데 하나다. 바로 이런 상황에서 대화형 코드 탐색과 인간의 판단이 가장 중요하며, 에이전트가 문맥만으로는 완전히 재구성할 수 없는 시스템의 정신 모델을 붙들고 있어야 한다.

개발자들이 IDE 수준의 점검에 계속 묶여 있게 만드는 실패 양상은 에이전트가 거의 맞는 경우다. 무언가가 90%는 맞지만 미묘하게 망가져 있을 때, 문제를 찾아내는 비용은 종종 처음부터 직접 작성하는 비용을 넘어선다. 위험도가 높은 변경에 대해서는, 그런 종류의 깊고 정밀한 점검에 IDE가 여전히 가장 좋은 도구다.

개발이 “많은 에이전트를 병렬로 실행하는 것”이 된다면, 그 워크플로는 텍스트 편집보다는 분산 시스템 관리에 더 가까운 문제를 물려받게 된다. 관측 가능성, 권한, 격리, 거버넌스 같은 문제들이다.

에이전트 워크플로는 노동의 성격을 뒤집는다. 작성하는 대신 검토하게 된다. 그것은 개선처럼 들리지만, 하루가 끝날 때 열두 개의 병렬 에이전트가 만든 열두 개의 diff를 바라보고 있다면 이야기가 달라진다. 검토 피로는 현실적인 문제이며, 이 분야에서 가장 사려 깊은 도구들이 기본적으로 완전한 자율성을 밀어붙이기보다 주의력 라우팅, 구조화된 계획, 검토 우선 게이트에 초점을 맞추는 이유 중 하나다.

에이전트가 더 많은 도구, 리포지토리, 외부 시스템에 접근할수록 보안 표면도 확장된다. 에이전트가 웹을 탐색하고, 데이터베이스를 조회하고, 파일 시스템에 쓰고, 배포를 트리거할 수 있게 되면, 그들이 무엇을 할 수 있는지 만큼이나 무엇을 허용받는지 가 중요해진다.

관측 가능성과 통제 측면에서, IDE에 통합된 에이전트 모드조차 이미 명시적인 도구 로그와 승인 게이트 쪽으로 나아가고 있다. 에이전트가 비동기적으로 동작하고 CI 파이프라인을 건드리기 시작하면 거버넌스 문제는 선택 사항이 아니다.

이 환경을 명확하게 읽으면, “IDE의 죽음”은 무게중심 에 대해서는 방향성 면에서 맞지만, 문자 그대로의 예측으로서는 틀리다.

이 주장의 가장 강한 형태는 이것이다. IDE는 주된 작업 공간이기를 멈추고 여러 하위 도구 중 하나가 된다. 즉 목표 지향적인 점검, 디버깅, 최종 편집에는 사용되지만, 계획, 오케스트레이션, 검토, 에이전트 관리는 대시보드, 이슈 추적기, 관측 터미널, 클라우드 제어 평면으로 이동한다.

“더 큰 IDE”라는 틀도 마찬가지로 충분히 뒷받침된다. 새로운 “IDE”는 다중 에이전트 오케스트레이션, 격리된 작업 공간, 권한과 감사 로그, diff 우선 검토, 신뢰할 수 있는 도구 연결성, 주의력 라우팅을 제공하는 시스템이다. 파일 에디터는 여전히 그 안에 있다. 다만 더 이상 정문이 아닐 뿐이다.

IDE는 죽어가고 있는 것이 아니다. 탈중심화 되고 있다. 작업은 바깥으로 이동하고 있다. 인간이 의도를 정의하고, 병렬 에이전트 런타임에 위임하고, 타이핑보다 감독과 검토와 거버넌스에 더 많은 시간을 쓰는 오케스트레이션 표면으로 말이다.

IDE는 정확성, 이해, 그리고 에이전트가 여전히 어려워하는 문제들에 대해 여전히 핵심적이다. 하지만 이제 IDE는 프로그래밍이 일어나는 유일한 장소가 아니다. 그리고 점점 더 많은 사람들에게, 더 이상 가장 먼저 향하는 장소도 아니다.