도구는 빨라졌는데, 왜 현장은 여전히 느릴까
AI 코딩 도구가 일상이 된 지금, 아이러니한 장면이 반복된다. 프롬프트 한 줄로 컴포넌트를 뚝딱 만들어내지만, 정작 그 컴포넌트가 LCP를 0.5초 늦추거나 레이아웃을 흔들어놓는 건 아무도 알아채지 못한다. Cursor로 Next.js 앱을 빠르게 붙였더니 맥북이 50GB 메모리를 먹어치우는 사태가 벌어지기도 한다. 도구의 속도와 실제 제품의 성능은 별개의 문제다.
3초 안에 승부가 난다는 건, 설계의 문제다
dev.to에 게재된 Core Web Vitals 분석 글은 오래된 진실을 다시 각인시킨다. 모바일 사용자의 53%는 3초 이상 걸리는 사이트를 떠난다. 로드 시간을 0.1초 줄였더니 리테일 전환율이 8.4% 올랐다는 구글 데이터는 '성능은 UX 지표가 아니라 비즈니스 지표'라는 사실을 수치로 증명한다.
문제는 이 수치가 알려진 지 오래됐음에도, 현장에서 Core Web Vitals가 실제로 개선되는 속도는 더디다는 것이다. LCP(Largest Contentful Paint), INP(Interaction to Next Paint), CLS(Cumulative Layout Shift)—이 세 지표는 각각 '사용자가 콘텐츠를 봤는가', '클릭에 즉시 반응했는가', '레이아웃이 예측 가능하게 유지됐는가'를 측정한다. 그리고 이 세 가지 모두, AI가 생성한 코드에서 얼마든지 무너질 수 있다.
Critical Rendering Path는 AI도 대신 이해해주지 않는다
브라우저의 렌더링 파이프라인은 단순하다. DOM과 CSSOM이 모두 준비돼야 첫 픽셀이 찍힌다. defer나 async 없이 삽입된 스크립트는 파서를 멈춘다. 뷰포트 아래 콘텐츠를 위한 CSS까지 모두 로드되길 기다리면 LCP는 무너진다. 이 규칙들은 AI가 코드를 생성하든 개발자가 직접 쓰든 상관없이 동일하게 적용된다.
핵심은 이렇다. Critical CSS를 인라인으로 분리하고, 나머지는 media="print" onload 패턴으로 논블로킹 처리한다. 앱 코드에는 defer, 애널리틱스처럼 독립적인 스크립트엔 async를 구분해 붙인다. 폰트가 늦게 로드돼 텍스트가 밀리는 순간 CLS 점수는 오른다. 이 판단들은 DevTools 퍼포먼스 패널을 직접 열고 타임라인을 읽어야만 내릴 수 있다. 프롬프트로 위임할 수 없는 영역이다.
Cursor 50GB 사태가 가르쳐준 것
dev.to에 올라온 Cursor 메모리 누수 사례는 다른 각도에서 같은 교훈을 준다. Next.js 앱을 개발하던 중 Cursor가 50GB 이상의 메모리를 점유하기 시작했다. 개발자는 React 렌더 루프, useEffect 누수, Next.js 캐시 문제를 차례로 의심했다. 이 모든 용의자는 무죄였다.
범인은 .cursor 폴더였다. 프로젝트 루트가 아닌 app/some-folder/ 안에 숨어 있던 숨김 디렉터리 하나가 Cursor로 하여금 엉뚱한 경로를 무한 참조하게 만든 것이다. 수정 방법은 단순했다—폴더를 루트로 옮기고 재시작. 하지만 진단에 걸린 시간은 그렇지 않았다.
이 사례가 보여주는 건 AI 도구 자체의 취약성이기도 하지만, 동시에 '도구 주변 구조를 설계하지 않은 대가'이기도 하다. .gitignore처럼 프로젝트 구조 컨벤션을 팀이 명시적으로 관리했다면, 숨김 폴더 하나가 미아가 되는 일은 없었을 것이다.
컨텍스트 프릭션: AI 도구가 만드는 새로운 인지 부하
dev.to의 '컨텍스트 프릭션' 글은 이 문제를 인지 과학의 언어로 설명한다. 컨텍스트 프릭션이란 전환·중단·주의 회복의 비용이다. Slack 알림 하나가 플로우 상태를 깨뜨리는 데는 1분이면 충분하지만, 그 전의 멘탈 모델을 재구축하는 데는 그보다 훨씬 오래 걸린다.
AI 에이전트는 이 프릭션을 줄여주기도 하지만, 새로운 종류의 부하를 추가하기도 한다. 내 작업 계획, 에이전트의 작업 계획, 생성된 diff, 리뷰 코멘트, 실패한 체크, 숨겨진 가정—이 모든 걸 동시에 추적하는 것은 Cursor를 켜두는 것만으로 해결되지 않는다. 에이전트는 개발자보다 훨씬 빠르게 움직이고, 그 속도 차이를 감당하는 구조를 갖추지 않으면 감독 비용이 생산성 이득을 잠식한다.
실용적인 대응은 단순하다. 타임박스로 집중 세션을 구분하고, 작업 전환 전에 다음 실행 명령이나 실패한 테스트 이름 같은 '빵 부스러기'를 남겨두는 것. AI 에이전트를 병렬로 여러 개 돌리기 전에, 내 주의력의 한계를 먼저 설계해야 한다.
결국 성능은 설계의 산물이다
세 가지 사례를 겹쳐 보면 하나의 패턴이 보인다. Core Web Vitals는 브라우저 파이프라인을 이해한 개발자가 렌더링 전략을 설계할 때 개선된다. Cursor 메모리 누수는 도구 주변 디렉터리 구조를 팀이 명시적으로 관리할 때 예방된다. 컨텍스트 프릭션은 AI 에이전트의 속도에 끌려가지 않도록 주의력 흐름을 의도적으로 설계할 때 줄어든다.
공통분모는 설계 의도(design intent)다. AI가 코드를 생성하는 속도는 계속 빨라지겠지만, 그 코드가 실제 사용자 경험에서 얼마나 빠르고 안정적으로 작동하는지는 개발자가 무엇을 설계했느냐에 달려 있다. 도구를 잘 쓰는 것과 잘 설계하는 것은 여전히 다른 기술이다.
앞으로의 질문
AI 코딩 도구가 성숙할수록 '도구가 알아서 최적화해주겠지'라는 기대도 커진다. 하지만 지금의 궤적을 보면, 도구는 개발자의 판단을 빠르게 실행해줄 뿐, 그 판단 자체를 대체하지는 않는다. DevTools를 열고 LCP 타임라인을 읽는 일, 프로젝트 루트의 숨김 폴더를 점검하는 일, 에이전트를 몇 개까지 병렬로 돌릴지 결정하는 일—이것들은 앞으로도 한동안 개발자의 몫이다.
성능을 설계한다는 건 수치 목표를 세우는 것이 아니라, 그 수치가 어디서 깨지는지를 먼저 아는 것이다.