더 큰 IDE가 필요하다 — Karpathy가 본 에이전트 시대의 관제탑

"tmux 그리드는 멋지다. 근데 이건 2026년의 vi 수준이다."

Andrej Karpathy가 3월 11일 X에 올린 트윗이 개발자 커뮤니티를 관통했다. 누군가 Claude Code의 실험적 기능인 Agent Teams를 tmux 창에 띄워놓고 자랑하자, Karpathy가 답했다. "진짜 필요한 건 에이전트 팀을 위한 Agent Command Center — 모니터별로 최대화하고, 누가 놀고 있는지 보고, 터미널이나 사용량 통계를 토글로 열 수 있는 IDE." 그리고 자신의 답글을 인용하며 한 문장을 더 얹었다.

"기대: IDE의 시대가 끝났다. 현실: 더 큰 IDE가 필요하다."

기본 단위가 파일에서 에이전트로 바뀔 뿐, 여전히 프로그래밍이라는 것이다. 8,500개의 좋아요와 3,700개의 북마크. 138만 뷰. 이 숫자가 말해주는 건 간단하다 — 모두가 같은 불편함을 느끼고 있었다는 것.

tmux 그리드: 영광스러운 땜빵

사건의 시작은 Numman Ali라는 개발자의 트윗이었다. CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=true claude를 tmux 안에서 실행하면 팀원 에이전트들이 자동으로 새 pane에 열린다는 걸 보여줬다. 멋진 데모였다. 16만 뷰에 1,300개 좋아요.

근데 Karpathy의 반응이 핵심이다. 그는 "awesome"이라고 인정하면서도 즉시 한계를 짚었다. tmux는 텍스트 스트림을 네모 칸에 배열할 뿐이다. 에이전트가 3개면 관리할 만하다. 10개면? 30개면? 어떤 에이전트가 멈춰 있는지, 얼마나 토큰을 먹고 있는지, 어떤 파일을 건드리고 있는지 — tmux는 이 중 어떤 것도 알려주지 않는다.

이건 마치 1990년대에 여러 서버를 관리하면서 터미널 창 20개를 띄워놓고 top을 돌리던 시절과 닮았다. 그때 우리가 만든 게 뭐였나? Kubernetes 대시보드, Grafana, Datadog 같은 "관제탑"이었다. 에이전트한테도 같은 게 필요한 시점이 왔다.

지금 있는 것들: 파편화된 전선

현재 에이전트 관리 도구 시장을 보면 상당히 파편화되어 있다.

Claude Code Agent Teams는 Anthropic이 만든 실험적 기능이다. 리드 에이전트가 팀원들에게 작업을 배분하고, 팀원들끼리 직접 소통할 수 있다. 서브에이전트와 다른 점은 팀원들이 공유 태스크 리스트를 갖고 자율적으로 작업을 claim한다는 것. 하지만 아직 실험 단계이고, 세션 재개나 종료 처리에 알려진 한계가 있다. 무엇보다 — UI가 터미널이다.

Cursor는 "self-driving codebases" 연구에서 수천 개의 에이전트를 동시에 돌리는 하니스(harness)를 만들었다. 그들의 발견이 흥미롭다. 에이전트들에게 자유로운 자기 조율(self-coordination)을 시키면 실패한다. 락을 잡고 놓지 않고, 작은 안전한 작업만 골라하고, 전체 그림을 보지 못한다. 결국 Planner → Executor → Worker 구조, 즉 명확한 역할 분리가 필요했다. 이건 소프트웨어 팀이 수십 년간 배워온 교훈과 정확히 같다. 에이전트도 조직이 필요하다.

OpenClaw는 다른 각도에서 접근했다. 셀프 호스팅 게이트웨이로 WhatsApp, Telegram, Discord를 통해 에이전트와 소통하고, 크론 작업과 세션 관리를 통합했다. "IDE"보다는 "에이전트 인프라"에 가깝다. 에이전트가 언제 돌았는지, 뭘 했는지, 에러가 났는지는 알 수 있다. 하지만 Karpathy가 원하는 "모니터에 에이전트 팀을 배치하고 실시간으로 관제하는" 비주얼 경험과는 거리가 있다.

Karpathy가 진짜 원하는 것

그가 열거한 기능을 정리하면 이렇다:

에이전트별 모니터 최대화 — 한 화면에 한 에이전트 작업을 full-screen으로. 에이전트 상태 대시보드 — 누가 활성이고 누가 idle인지 한눈에. 관련 도구 토글 — 특정 에이전트의 터미널, 브라우저, 파일 탐색기를 필요할 때만 열기. 사용량 통계 — 토큰, 비용, 실행 시간을 실시간으로.

이걸 합치면 그림이 나온다. 이건 VSCode나 Cursor 같은 "코드 편집기의 확장"이 아니다. 이건 에이전트 팀을 위한 미션 컨트롤 — NASA의 휴스턴 관제센터에 더 가깝다.

그리고 여기서 Karpathy의 통찰이 빛난다. "기본 단위가 파일이 아니라 에이전트다." 지금까지 IDE는 파일을 중심으로 설계됐다. 파일 탐색기, 탭, 디프 뷰, 검색 — 전부 파일이 원자 단위다. 에이전트가 기본 단위가 되면 IDE의 원자가 바뀐다. 탭 하나가 파일이 아니라 에이전트 세션이 된다. 사이드바에 파일 트리 대신 에이전트 목록이 뜬다. 상태바에 라인 수 대신 토큰 소모량이 나온다.

격차: 상상과 현실 사이

Karpathy가 그린 그림과 현실의 간극을 가장 잘 보여주는 건 Cursor의 연구 과정이다.

그들은 수천 개의 에이전트를 돌리면서 "적절한 관찰 가능성(observability)"에 먼저 투자했다고 밝혔다. 모든 에이전트 메시지, 시스템 액션, 명령어 출력을 타임스탬프와 함께 로깅했다. 왜? 에이전트가 뭘 하는지 모르면 디버깅이 불가능하기 때문이다. 그들은 이 로그를 다시 Cursor에 넣어서 패턴을 찾았다 — 에이전트를 관찰하기 위해 또 다른 에이전트를 쓴 것이다.

지금 개발자 대부분은 이 수준에 한참 못 미친다. Claude Code를 tmux에 3개 띄워놓고 스크롤을 올려다 내려다 하면서 "이 친구 뭐 하고 있지?"를 확인하는 게 현실이다. 에이전트가 멈추면 알려주는 사람은 아무도 없다. 토큰이 폭주해도 모른다. 한 에이전트가 다른 에이전트의 작업을 덮어써도 — 다 끝나고 나서야 발견한다.

이 격차가 바로 다음 유니콘의 영토다.

내일 주목할 것

Cursor가 multi-agent harness를 일부 사용자에게 공개하기 시작했고, Anthropic의 Agent Teams는 아직 실험 플래그 뒤에 있다. Karpathy의 트윗이 138만 뷰를 찍었다는 건 수요가 공급을 압도적으로 앞서고 있다는 뜻이다. 누가 먼저 "에이전트의 Kubernetes 대시보드"를 만드느냐 — 그게 다음 개발 도구 전쟁의 승부처다.

---

🔗 Sources

확신도 기준:

• 🟢 Observed: 직접 확인 가능한 사실 (공식 발표, 트윗, 제품 페이지)
• 🔵 Supported: 신뢰할 만한 출처가 뒷받침 (블로그 분석, 연구 보고서)
• 🟡 Speculative: 추론 또는 예측 (분석가 의견, 트렌드 해석)
• ⚪ Unknown: 출처 불확실

---

HypeProof Daily Research | 2026-03-12