IDE의 죽음? 아니, 탈중심화임

개발자 업무의 중심이 이동하고 있음. 사라지는 게 아니라 — 이동하는 것임. 에디터 안에서 한 줄씩 코드를 작성하던 시대에서, 에이전트를 감독하고 결과물을 리뷰하는 시대로 넘어가고 있음. Cursor가 Glass를 출시하고, Claude Code Web·GitHub Copilot Agent·Jules·Conductor·cmux·Vibe KanBan 같은 도구들이 동시다발적으로 같은 방향을 가리키고 있음.

에디터에서 오케스트레이터로

전통적 IDE의 내부 루프는 명확했음: 파일 열기 → 편집 → 빌드 → 디버그 → 반복. 이 루프가 생산성의 기본 단위였음.

차이점은 단순한 "자동완성 + 채팅창"이 아님. 에이전트가 도구를 직접 사용하는 자율성과, 그 자율성을 통제 가능하게 만드는 인터페이스가 결합된 것임.

Cursor가 최근 출시한 Glass가 대표적임. 에이전트 관리가 1순위 경험이고, 전통적 에디터는 "더 깊이 파고들 필요가 있을 때" 꺼내 쓰는 도구로 격하됨. 출시 직후 개발자들의 반응이 즉각적이었음 — "이제 Cursor는 IDE보다 에이전트 오케스트레이터에 더 가까움."

Claude Code Web과 Codex는 잘 정의된 태스크를 클라우드 격리 환경에서 돌아가는 에이전트에 넘기는 방식임. 터미널도 로컬 세팅도 필요 없음. GitHub Copilot Agent는 멀티파일 변경을 독립적으로 계획·실행하고 브랜치를 만들고 테스트를 돌린 뒤 PR을 올림. 개발자의 본업이 "각 단계를 지시하는 것"에서 "결과를 리뷰하고 반복하는 것"으로 바뀐 셈임.

핵심 멘탈 모델의 전환: 작업의 단위가 "파일"이 아니라 "에이전트"가 됨. 최적화해야 할 인터페이스는 타이핑 속도를 높여주는 것이 아니라 에이전트를 지시·모니터링·리뷰하는 것임.

수렴하는 패턴들

도구마다 접근이 다르지만, 놀라울 정도로 동일한 패턴들이 반복적으로 등장하고 있음.

1. 작업 격리(Work Isolation) — Git Worktree가 사실상 표준 병렬 에이전트가 서로 충돌하지 않으려면 격리가 필수임. Conductor는 각 에이전트 세션을 독립 워크스페이스에 매핑하고, Vibe KanBan도 칸반 기반 에이전트 워크플로에서 동일한 구조를 채택함. git worktree(또는 유사 메커니즘)가 거의 유비쿼터스하게 자리잡은 이유는 단순함 — 격리 없는 병렬 에이전트는 카오스를 만들기 때문임.

2. 계획·태스크 상태가 최상위 UI Vibe KanBan은 "탭과 파일" 대신 "태스크와 상태"를 최상위 멘탈 모델로 채택함. 태스크 카드(랜딩페이지, 백엔드 서비스, 이메일 연동 등)를 만들고, 각각에 에이전트와 모델을 할당하고, 전체를 경량 프로젝트 보드처럼 관리함. 다만 "팀"이 자율적으로 돌아가는 에이전트라는 점이 다를 뿐임.

3. 백그라운드 비동기 에이전트 Cursor, Copilot, Antigravity 등은 개발자가 자리를 비운 사이에도 돌아가는 백그라운드 에이전트를 지원함. Jules도 마찬가지로 태스크를 할당하고 나중에 디프를 확인하는 방식임. 암묵적 약속은 이것임: 개발자의 주의력은 프로그레스 바를 지켜보기엔 너무 비싼 자원임. IDE의 실시간·동기식 피드백 루프와 근본적으로 다른 설계 철학임.

4. 병렬 에이전트를 위한 어텐션 관리 다수의 에이전트가 동시에 돌아갈 때 진짜 병목은 "지금 당장 나를 필요로 하는 에이전트가 어느 것인지"를 아는 것임. Conductor가 세션 전체의 라이브 진행 상황을 표시하고, cmux가 터미널 패인에 알림 링과 미읽음 뱃지를 도입한 이유가 여기에 있음. **"에이전트가 주의를 필요로 함"**이 개발 환경의 일급 이벤트가 되고 있음.

5. 소프트웨어 라이프사이클 임베딩 GitHub Copilot 코딩 에이전트는 비동기적이고, 제어 레이어로 보안이 적용되며, GitHub Actions 기반으로 동작함. 코드가 "작성되는" 방식이 아니라 "실제로 배포되는" 방식(이슈 → PR → CI → 머지)에 직접 연결됨.

그래도 IDE가 필요한 이유

"IDE는 죽었다"에 대한 가장 설득력 있는 반론은, IDE가 여전히 진짜 어려운 문제들을 고밀도 피드백 루프로 압축해준다는 점임. 정밀한 네비게이션, 로컬 추론, 인터랙티브 디버깅, 직접 조작을 통한 시스템 이해 — 이 능력들은 오케스트레이션 도구로 대체되지 않음.

가장 야심찬 오케스트레이션 도구들도 수동 편집 탈출구를 유지하고 있음. 스레드 내에서 디프를 리뷰하고 코멘트를 달고, 그 결과를 에디터에서 수동 조정하는 워크플로가 의도된 설계임. 인간의 개입이 워크플로의 일부라는 인정임.

대규모 레포지토리에서의 멀티파일 리팩토링은 여전히 에이전트에게 가장 어려운 과제 중 하나임. 에이전트가 컨텍스트만으로 완전히 재구성할 수 없는 시스템의 멘탈 모델을 개발자가 직접 들고 있어야 하는 상황 — 바로 이때 인터랙티브 코드 네비게이션과 인간의 판단이 빛남.

새로운 비용: 리뷰 피로와 거버넌스

개발이 "다수의 에이전트를 병렬로 돌리기"가 되면, 텍스트 편집보다는 분산 시스템 관리에 가까운 문제들이 따라옴 — 관측성(observability), 권한(permissions), 격리(isolation), 거버넌스(governance).

리뷰 피로는 현실적 문제임. 에이전트 워크플로는 노동을 반전시킴. 작성 대신 리뷰함. 개선처럼 들리지만, 하루가 끝날 때 12개 병렬 에이전트가 만든 12개 디프를 보고 있으면 이야기가 달라짐. 가장 사려 깊은 도구들이 어텐션 라우팅, 구조화된 계획, 리뷰 우선 게이트에 집중하는 이유가 여기에 있음.

보안 표면도 확장됨. 에이전트가 웹 브라우징, DB 쿼리, 파일시스템 쓰기, 배포 트리거 등 더 많은 도구에 접근할수록, "무엇을 할 수 있는가"만큼 "무엇을 해도 되는가"가 중요해짐. IDE 통합 에이전트 모드들은 이미 명시적 도구 로그와 승인 게이트를 도입하고 있음.

에이전트가 비동기적으로 행동하고 CI 파이프라인을 건드리는 순간, 거버넌스 문제는 선택이 아니라 필수가 됨.

결론: 죽는 게 아니라 탈중심화

"IDE의 죽음"은 무게중심 이동의 방향에 대해서는 맞지만, 문자 그대로의 예측으로서는 틀림.

가장 강력한 버전의 주장은 이것임: IDE는 더 이상 주요 작업 공간이 아니게 되고, 여러 종속 도구 중 하나가 됨. 정밀 검사, 디버깅, 최종 편집에 사용됨. 한편 계획·오케스트레이션·리뷰·에이전트 관리는 대시보드, 이슈 트래커, 관측 터미널, 클라우드 컨트롤 플레인으로 이동함.

"더 큰 IDE" 프레이밍도 동등하게 유효함. 새로운 "IDE"는 멀티에이전트 오케스트레이션, 격리된 워크스페이스, 권한·감사 로그, 디프 우선 리뷰, 안정적 도구 연결성, 어텐션 라우팅을 제공하는 시스템임. 파일 에디터는 여전히 존재함. 다만 더 이상 정문이 아닐 뿐임.