AI 코딩 도구가 프론트엔드 개발의 속도 방정식을 바꿔놓고 있다. 자연어 프롬프트 하나로 React 앱 스켈레톤이 생성되고, 라우팅과 레이아웃이 수 분 안에 붙는다. 그런데 그 결과물이 실제로 잘 만들어진 코드인지를 누가, 어떻게 판단하는가? 생성 속도와 구조적 품질 사이의 간극—이것이 지금 AI 코딩 도구를 실무에 도입한 팀들이 마주하는 진짜 문제다.
속도는 얻었다. 판단력은?
dev.to에 공개된 Vibe Coding 실험기는 이 질문을 가장 솔직하게 드러낸다. 저자는 Google AI Studio의 빌드 모드를 활용해 개인 블로그를 처음부터 구축했다. 결론은 흥미롭다. "Vibe coding이 압축하는 건 빈 페이지 문제이지, 판단력 문제가 아니다." 작동하는 무언가를 빠르게 만드는 속도는 극적으로 빨라졌다. 하지만 그게 좋은 무언가인지를 아는 능력은 전혀 빨라지지 않았다는 것이다.
실제로 Vibe Coding 워크플로우에서 AI가 잘한 것은 명확하다. 라우팅·빌드 설정·프로젝트 구조 같은 '설정 세금'을 건너뛰고 동작하는 스켈레톤에서 시작하게 해준다. 어노테이션 모드로 미리보기 화면을 클릭해 시각적 수정을 빠르게 반영하고, 긴 대화 맥락을 잃지 않고 이어가는 것도 인상적이다. 그러나 AI는 프로젝트에서 '완성'이 무엇을 의미하는지 알지 못한다. 에러 처리, 엣지 케이스, 보안 강화—미리보기가 완성된 것처럼 보일 때 코드는 여전히 미완성일 수 있다. 프리뷰를 믿지 말고 실제 코드 탭을 읽는 것이 선택이 아닌 필수인 이유다.
번들 최적화: AI가 손대지 않는 영역
생성 속도의 문제는 코드 품질에서 더 구체적인 형태로 드러난다. AI가 만들어낸 프론트엔드 애플리케이션이 배포 직전 단계에 이르면, 개발자는 번들 구조라는 또 다른 현실과 마주한다. dev.to의 코드 스플리팅 분석 아티클은 이 지점을 정밀하게 짚는다. 코드 스플리팅을 구현했는데도 앱이 여전히 느리거나 오히려 더 느려지는 상황—이건 꽤 흔한 경험이다.
원인은 대개 세 가지다. 과도한 분할(over-splitting)—너무 잘게 쪼갠 탓에 네트워크 요청 오버헤드가 오히려 성능을 갉아먹는다. 부족한 분할(under-splitting)—청크가 여전히 거대해 온디맨드 로딩의 이점을 못 누린다. 공유 모듈 중복—여러 동적 컴포넌트가 같은 서드파티 라이브러리를 각자 포함하면 총 다운로드 크기가 폭발한다. AI가 생성한 코드는 이 균형을 설계해주지 않는다. Webpack Bundle Analyzer나 Vite Visualizer로 실제 번들 구조를 시각화하고, optimization.splitChunks의 minSize·maxSize·minChunks를 조율하며 벤더 청크와 런타임 청크를 분리하는 작업—이 판단은 도구가 아닌 개발자의 몫이다.
라우트 기반 스플리팅이 출발점이다. React의 React.lazy와 Suspense로 현재 뷰에 필요한 코드만 내려받게 하고, 모달·차트·리치 텍스트 에디터 같은 무거운 비핵심 컴포넌트는 뷰포트 진입이나 사용자 인터랙션 시점에 조건부로 로드한다. 자주 쓰이는 내부 유틸리티나 디자인 시스템 요소는 별도의 공유 청크로 묶어 중복 다운로드를 막는다. 스플리팅은 구현이 아니라 설계이며, AI는 그 설계도를 그려주지 않는다.
드래그앤드롭은 끝나지 않았다—다른 역할로 살아있다
GoodBarber의 아티클은 또 다른 각도에서 같은 질문을 던진다. 프롬프트 인터페이스가 추가된 노코드 플랫폼에서, 드래그앤드롭은 구시대 유물이 됐는가? 답은 명확히 '아니오'다. 이 판단이 단순한 방어적 반응이 아닌 이유가 인상적이다.
직접 조작(direct manipulation)이 압도적으로 유리한 영역이 있다. 이 버튼을 2픽셀 아래로, 이 이미지를 섹션 상단에, 이 메뉴 순서를 바꾸기—이런 의도는 보여줄 수 있는 것이다. 이걸 AI에게 설명하는 문장이 직접 드래그하는 동작보다 길다면, 인터페이스 선택이 잘못된 것이다. 반면 프롬프트가 빛나는 곳은 '롱테일'—어떤 설정 패널로도 감당할 수 없는 특수하고 단수적인 요구다. "세 개의 입력 필드, 월 납입금을 자동 계산하고, 콜백 요청 버튼이 있는 대출 시뮬레이터"—이건 합리적인 설정 패널이 제공할 수 없지만, 한 문장이면 된다.
핵심은 두 인터페이스가 경쟁하지 않는다는 것이다. 그들은 다른 필드에서 플레이한다. 드래그앤드롭은 보여줄 수 있는 의도를 라우팅하고, 프롬프트는 그릴 수 없었던 의도를 라우팅한다. 그리고 두 경로 모두 같은 종착지—디자인 시스템 위에 올라타야 한다—로 수렴해야 한다. GoodBarber가 AI 팔레트 생성기의 출력을 '어떤 색'이 아닌 '4색 시맨틱 시스템에 진입하는 팔레트'로 강제하는 이유가 여기 있다. AI가 만든 결과물이 나머지 시스템과 '같은 세계'에 착지하게 하는 것—이것이 진짜 엔지니어링 문제다.
시사점: 생성 이후의 설계가 경쟁력이다
세 가지 맥락이 하나의 신호로 수렴한다. AI는 빈 페이지를 채워주는 속도를 가져왔지만, 구조적 품질의 설계는 여전히 개발자의 판단력에 달려 있다. Vibe Coding 워크플로우에서 프리뷰를 믿지 않고 코드 탭을 읽는 습관, 번들 분석 도구로 스플리팅 구조를 검증하는 루틴, 드래그앤드롭과 프롬프트 중 어떤 인터페이스가 어떤 의도에 적합한지를 판단하는 아키텍처 감각—이것들은 AI가 대신해줄 수 없는 영역이다.
실무적으로 이 흐름은 세 단계로 구체화된다. 첫째, AI 생성 코드는 PR처럼 리뷰한다—프리뷰가 아닌 실제 소스를 기준으로. 둘째, 번들 구조는 배포 전 반드시 시각화한다—Webpack Bundle Analyzer나 Vite Visualizer를 CI 파이프라인에 연결하면 회귀를 방지할 수 있다. 셋째, 인터페이스와 생성 결과물 모두 디자인 시스템 위에 착지시킨다—AI가 만든 컴포넌트가 토큰 체계 밖으로 이탈하는 순간, 일관성은 깨진다.
전망: '속도 이후'의 역량이 다음 차별점
AI 코딩 도구의 성숙은 앞으로도 계속될 것이다. 더 정교한 스캐폴딩, 더 긴 컨텍스트, 더 정확한 코드 생성. 그러나 이 방향이 선명해질수록, 역설적으로 개발자에게 요구되는 역량의 윤곽도 더 또렷해진다. 어떤 청크를 언제 분리할지를 결정하는 번들 설계 감각, 프롬프트와 직접 조작 중 어떤 경로가 이 의도에 최단인지를 판단하는 인터페이스 아키텍처 감각, 그리고 미리보기가 완성을 뜻하지 않는다는 걸 아는 프로덕션 감각. 추상화 사다리의 새 가로대는 아래 가로대를 없애지 않는다—더 선명한 역할을 준다. AI가 속도를 가져갈수록, 개발자가 가져야 할 것은 더 명확해지고 있다.