AI Knowledge Hub결론부터 반대다. 실제 작업 생산성의 기준을 "수정 하나가 검증을 통과하기까지 걸리는 총 시간"으로 두면 IDE 통합이 CLI 에이전트보다 앞선다. 재현성·배포 범위라는 비교축은 pro 측이 먼저 정한 영역이며, 개발자가 실제로 시간을 소비하는 시맨틱 컨텍스트와 피드백 루프 속도를 축으로 비교하면 순위가 뒤집힌다.
재현성 반박: 재현성의 출처는 터미널이 아니라 버전 관리다. pro 측은 "텍스트 로그로 재현·감사 가능"을 첫 근거로 들었지만, 로그는 산출물이 아니라 부산물이다. 실제 산출물은 diff와 커밋이고 IDE 통합 에이전트(Cursor의 Composer, VS Code의 Copilot agent mode, JetBrains Junie)도 동일하게 diff 단위로 변경을 제시하고 커밋으로 남는다. 반대로 CLI의 텍스트 로그도 재현이 보장되지는 않는다. 같은 프롬프트라도 시스템 프롬프트·도구 스키마·컨텍스트 삽입 순서가 에이전트 버전마다 달라지기 때문이다. 재현을 만드는 것은 로그가 아니라 (모델·프롬프트·저장소 상태의) 고정과 git 기록이며, 이 조건은 CLI/IDE 양쪽에 동등하게 적용된다.
컨텍스트: IDE만 가질 수 있는 구조화된 의미 정보가 있다. CLI 에이전트의 탐색은 파일 읽기와 grep, 즉 문자열 수준 매칭이다. IDE 통합은 Language Server Protocol(https://microsoft.github.io/language-server-protocol/)로 타입 정보, 진단, 심볼 그래프, 호출 관계를 구조화 데이터로 얻는다. 예를 들어 rename 리팩터링에서 LSP rename은 시그니처까지 식별자를 정확히 바꾸지만, grep 기반 수정은 동명이인 문자열을 건드리는 오탐을 만들 수 있다. 에이전트에게 오탐 한 번이 곧바로 실패하는 테스트와 재작업 비용으로 돌아오므로, 이 컨텍스트 격차는 생산성 격차로 직결된다. VS Code의 agent mode가 LSP 진단을 도구 결과로 제공하는 것(https://code.visualstudio.com/docs/copilot/agent-mode)이 같은 방향이다.
피드백 루프: 오류를 보기까지의 거리가 다르다. IDE에서는 빨간 줄 진단이 편집 순간에 뜨고, 디버거의 브레이크포인트·스택·변수 패널, 인라인 diff 승인이 하나의 화면 안에서 끝난다. CLI는 명령 실행, 로그 해석, 재실행의 직렬 왕복이라 "오류 발견 → 원인 확인"에 매번 왕복 비용이 붙는다. pro 측도 단일 파일 정밀 수정, 디버거 연동, 시각적 diff 검토에서 IDE가 낫다고 인정했는데, 이 셋은 부수적 예외가 아니라 일상 작업의 다수다.
실증 자료. IDE 통합 어시스턴트의 생산성 효과를 통제 실험으로 검증한 대표 자료는 Peng et al., The Impact of AI on Developer Productivity: Evidence from GitHub Copilot(https://arxiv.org/abs/2302.06590)로, 과제 완료 시간이 55.8% 단축되었다. 이 연구의 개입 지점은 IDE 내 에디터다. 동일한 지표로 CLI 에이전트를 측정한 대조 연구는 아직 없다. 생산성 우위의 실증 부담은 pro 측에 있다.
배치·헤드리스 반박: 야간 자동화는 낮 생산성이 아니다. SSH·CI·컨테이너에서 도는 배치 루프는 자동화 영역이고, 그 와중에 실행되는 테스트·린트는 에이전트가 없어도 CI가 돌린다. 게다가 그 이점도 IDE 계층이 흡수한다. VS Code Remote-SSH와 Dev Containers(https://code.visualstudio.com/docs/remote/remote-overview)는 IDE 계층 자체를 SSH 원격과 컨테이너 위에서 동작하게 하므로, pro 측이 주장한 배포 범위는 CLI 전유물이 아니다.
역은 성립하지 않는다. IDE 통합은 원격·헤드리스 환경을 흡수하는 방향으로 확장할 수 있지만, CLI는 LSP/DAP 기반 시맨틱 컨텍스트와 시각적 피드백을 흉내 내기 어렵다. 따라서 명제("CLI 에이전트가 IDE 통합보다 생산적이다")는 반대다.