AI 코딩 도구가 일상이 된 지금, 많은 개발자들이 IDE를 가볍게 치환하는 경험을 하고 있다. dev.to의 한 글은 "무거운 IDE를 버리고 AI를 IDE로 삼았다"는 선언으로 시작한다. PhpStorm 대신 VS Code와 터미널, 거기에 AI를 얹은 스택이 충분하다는 얘기다. 공감하는 사람이 많을 것이다. 실제로 이 조합은 가볍고 빠르며, 프로젝트 간 컨텍스트 전환 비용도 낮다.
그런데 이 흐름에서 잘 이야기되지 않는 게 있다. "AI가 IDE를 대체한다"는 명제는 로컬 환경 설정에서 한 번, 그리고 세션이 길어질수록 점점 더 빈번하게 균열이 생긴다는 사실이다. 환경 구성 단계에서 생기는 마찰은 그나마 가시적이다. 하지만 세션 중반부에 AI가 슬며시 둔해지는 현상은 무엇이 원인인지조차 특정하기 어렵다.
환경 설정에서 먼저 막힌다
크롬 확장 개발 사례 하나를 보자. Vite 8 + React 19 + TypeScript + Tailwind v4 + Zustand로 네이버 블로그 헬퍼를 만드는 프로젝트인데, 실제 작업 시간의 상당 부분이 MV3 manifest 구성, 멀티 엔트리 빌드 설정, Node.js 버전 충돌 해소에 쓰였다. content.js → content.ts 확장자 문제, public/ 폴더 위치 규칙, 아이콘 파일 누락으로 인한 로드 실패처럼, AI가 코드를 생성해줘도 환경 자체가 맞지 않으면 결과물이 실행되지 않는다.
이 지점이 중요하다. AI는 코드 생성에는 빠르지만, 로컬 환경의 상태를 감지하지 못한다. Node.js 버전이 v20인지 v22인지, manifest가 public/에 있는지 src/에 있는지—이런 맥락은 개발자가 직접 쥐고 있어야 한다. "AI가 IDE 역할을 한다"는 말이 성립하려면, 이 환경 레이어를 개발자가 먼저 정리해 두어야 한다는 전제가 붙는다.
세션이 길어지면 AI는 둔해진다—그런데 이유가 다를 수 있다
환경 설정을 마치고 본격적으로 AI와 작업을 이어가다 보면 또 다른 장벽이 나타난다. 세션 중반부에 AI가 앞서 설정한 제약 조건을 잊거나, 이미 답한 질문을 다시 하거나, 응답의 밀도가 눈에 띄게 낮아지는 현상이다. 이걸 경험한 개발자라면 직관적으로 "MCP 서버가 너무 많이 연결되어 있어서"라고 진단하기 쉽다. 연결된 툴이 컨텍스트를 잡아먹는다는 이야기를 어딘가서 읽은 기억이 있으니까.
dev.to의 또 다른 글은 이 직관을 실측으로 검증한 사례를 다룬다. 작성자는 MCP를 끊기 전에 먼저 컨텍스트 윈도우 사용량을 카테고리별로 분석했다. 결과는 예상과 달랐다. 컨텍스트의 가장 큰 비중을 차지한 것은 MCP 툴 정의가 아니라 대화 히스토리였다—전체 윈도우의 약 5분의 1을 홀로 차지했다. MCP 툴 스키마는 예상보다 훨씬 작은 슬라이스였다.
물론 이 결과를 "MCP는 문제없다"는 결론으로 일반화하면 곤란하다. 클라이언트가 툴 스키마를 앞단에서 전부 로드하는 방식이라면 MCP가 실제로 큰 병목이 될 수 있다. 핵심은 설정에 따라 병목 위치가 달라진다는 것이다. 따라서 "MCP를 끊어야지"가 아니라 "지금 무엇이 윈도우를 채우고 있는지 먼저 읽어야 한다"가 올바른 순서다.
컨텍스트 윈도우는 책상이다
이 실측 사례가 제안하는 멘탈 모델이 직관적이다. 컨텍스트 윈도우를 캐비닛이 아니라 책상 표면으로 보는 것이다. 모델이 동시에 참조할 수 있는 것은 책상 위에 펼쳐진 것뿐이다. 긴 세션은 대화 기록이라는 종이를 책상 위에 계속 쌓아 올리는 행위다. 공간이 좁아지면 모델이 추론에 쓸 여지도 줄어든다.
실용적인 대처는 단순하다. 하나의 탐색적 세션이 마무리되면 새 세션을 시작한다. 연속성이 필요한 경우엔 전체 히스토리를 끌고 가는 대신, AI에게 현재 상태를 요약하게 하고 그 요약만 새 세션으로 넘긴다. 전체 대화가 아니라 핵심 맥락만 이전하는 것이다. "더 큰 윈도우를 사는 것"보다 "책상을 자주 정리하는 것"이 현실적인 해법이다.
AI가 IDE를 대체한다는 말의 실제 의미
"VS Code + 터미널 + AI"가 무거운 IDE를 대체한다는 명제는 맞다—조건부로. AI는 코드 생성, 버그 설명, 테스트 작성, 벤치마크 실행까지 담당하며 IDE의 인텔리전스 레이어를 빠르게 흡수하고 있다. 하지만 그 인텔리전스가 제대로 작동하려면 두 가지가 개발자 손에 있어야 한다. 로컬 환경의 일관성과 컨텍스트 위생이다.
환경 설정은 AI가 대신해줄 수 없는 물리적 토대다. Node 버전, 빌드 도구 설정, manifest 구조—이것들이 틀어지면 아무리 좋은 코드 생성도 실행되지 않는다. 그리고 세션이 길어질수록 대화 히스토리가 컨텍스트를 조용히 잠식하며 AI의 추론 품질을 떨어뜨린다. 이 두 병목은 막연히 느껴지다가 어느 순간 전체 흐름을 멈추게 만든다는 공통점이 있다.
측정이 먼저, 진단이 나중
결국 이 모든 이야기가 수렴하는 지점은 하나다. AI 개발 환경에서 막히는 느낌이 들 때, 직관으로 먼저 손을 대지 말라는 것이다. 컨텍스트가 고갈되는 건 주관적인 인상이 아니라 측정 가능한 수치다. MCP를 끊기 전에 어느 카테고리가 윈도우를 채우고 있는지 읽고, 세션을 재시작하기 전에 무엇을 요약해서 넘길지 결정하고, 빌드가 실패하면 환경 레이어부터 점검하는 순서가 필요하다.
"AI가 IDE가 된다"는 말은 앞으로도 더 자주 들릴 것이다. 하지만 그 말이 완전히 성립하는 날이 오더라도, 환경을 세팅하고 컨텍스트를 관리하는 역할은 여전히 개발자의 몫으로 남을 가능성이 높다. 지금 당장은 더더욱 그렇다. AI를 잘 쓴다는 것은 AI에게 더 많이 맡기는 게 아니라, AI가 잘 작동하는 조건을 개발자가 먼저 설계한다는 뜻이다.