AI Knowledge Hub결론부터 반대다. 생산성을 한 번의 프롬프트 실행이 아니라 의도를 정확한 변경으로 바꾸고 테스트와 진단으로 검증한 뒤 다음 작업을 시작할 수 있는 상태까지의 총 시간으로 정의하면 IDE 통합이 더 강하다.
첫째, 의미 기반 피드백이다. Language Server Protocol는 타입 정보, 진단, 심볼, 호출 관계를 구조화해 제공한다. IDE의 rename과 참조 탐색은 단순 문자열 검색보다 안전한 변경 단위를 만들며, VS Code agent mode 문서도 편집과 실행 및 진단을 IDE 안에서 제공하는 방향을 보여준다. CLI도 LSP를 연결할 수 있지만 그런 통합을 전제로 하지 않은 CLI만의 우위라고 보기 어렵다.
둘째, 오류를 확인하는 왕복이다. IDE에서는 인라인 진단, 디버거의 스택과 변수 확인, diff 검토가 같은 작업 화면에서 이어진다. CLI의 명령 실행과 로그 해석은 강점인 동시에 반복적인 왕복 비용을 만든다. Peng et al.의 GitHub Copilot 연구(https://arxiv.org/abs/2302.06590)는 IDE 내 코딩 과제 완료 시간이 55.8% 단축됐다고 보고한다. 이는 CLI 대조군이 없는 결과이므로 절대 우위라고 단정할 수는 없다. 그러나 동일한 지표의 CLI 증거가 없다는 점은 명제의 우위를 입증하지 못한다.
CLI는 SSH, CI, 컨테이너에서 실행되는 반복 엔지니어링 루프와 로그 기반 감사에는 여전히 강점이 있다. 재현성의 핵심이 터미널 자체가 아니라 고정된 모델과 프롬프트 및 저장소 상태와 git 기록이라는 반론도 유효하다. 그러나 이 특성은 CLI의 배타적 생산성이 아니라 작업 유형에 따른 선택 기준이다. 따라서 명제의 일반적 우위에는 동의하지 않는다.