'AI로 빠르게 만든다.' 요즘 프론트엔드 개발 커뮤니티에서 가장 자주 듣는 말이다. 실제로 Vibe Coding으로 아이디어를 하루 만에 배포하거나, 에이전트에게 태스크를 던지고 커피 한 잔 마시는 사이 코드가 완성되는 경험은 분명 실재한다. 문제는 그 '빠름'이 프로덕션에서도 유효한가 하는 질문이다. 세 가지 실전 사례를 들여다보면, 속도의 이면에는 우리가 쉽게 지나치는 함정이 조용히 쌓여 있다.
함정 1. 프롬프트 품질을 도구 탓으로 돌리는 착각
dev.to에 올라온 Vibe Coding 실전 회고에는 흥미로운 고백이 하나 있다. 작성자는 처음 AI 코딩을 시작했을 때 결과물이 엉망이었고, 그 이유를 도구 탓으로 돌렸다고 한다. Gemini Studio를 쓰다 다른 툴로 옮기고, 또 다른 툴을 시도하면서 '완벽한 도구'를 찾아 헤맸다. 결론은 단순했다. 문제는 도구가 아니라 프롬프트였다.
프론트엔드 개발자 입장에서 이 교훈은 꽤 구체적으로 번역된다. "Do this only."처럼 범위를 명시적으로 제한하는 한 줄이 AI의 불필요한 사이드이펙트를 막는다. 수정할 파일명을 직접 지정하면 관련 없는 컴포넌트가 건드려지는 사고를 예방할 수 있다. 이건 단순한 팁이 아니라 AI를 쓰는 개발자의 표현력이 곧 결과물의 품질을 결정한다는 원칙에 가깝다.
더 흥미로운 건 이 글이 제안하는 메타 전략이다. AI를 써서 프롬프트 자체를 개선하라는 것. 거칠고 모호한 지시를 AI에게 한 번 정제시킨 뒤, 그 구조화된 프롬프트를 실제 작업에 쓰면 할루시네이션이 눈에 띄게 줄었다고 한다. AI를 생산 도구로만 보지 않고 설계 파트너로 쓰는 관점이다.
함정 2. 컨텍스트 없이 AI에게 먼저 물어보는 습관
dev.to의 또 다른 글은 레거시 코드 분석 도구를 만든 경험에서 출발하지만, 그 핵심 교훈은 모든 AI 코딩 워크플로우에 그대로 적용된다. 저자가 반복해서 부딪힌 패턴은 이것이다. 파일 하나를 LLM에 붙여넣고 "이게 뭐 하는 코드야?"라고 묻는 순간, AI는 모르는 부분을 그럴듯한 말로 채운다. 이건 지능이 아니라 '넥타이 맨 자동완성'이라는 표현이 정확하다.
해결책은 AI에게 묻기 전에 시스템이 먼저 구조를 추출하는 것이다. 의존성 체인, SQL 블록, 호출되는 클래스, UI 액션과 엔드포인트—이 모든 맥락을 먼저 수집하고 나서야 AI가 개입한다. 그러면 프롬프트는 "이 미스터리한 코드를 설명해줘"가 아니라 "여기 메서드가 있고, 이 의존성들이 있고, 이 SQL 조각이 있어. 실제로 어떤 일이 일어나는지 설명해줘"가 된다. 이 차이가 결과의 신뢰도를 근본적으로 바꾼다.
프론트엔드 개발에서도 이 원칙은 직접적으로 쓸 수 있다. 컴포넌트 리팩토링을 AI에게 맡기기 전에 props 흐름, 상태 의존성, 연결된 훅 목록을 먼저 정리하라. 디자인 시스템 작업이라면 현재 토큰 구조와 사용 패턴을 먼저 추출하라. AI의 품질은 모델보다 주변 스캐폴딩에 더 많이 달려 있다는 이 글의 결론은, 컨텍스트 설계를 AI 워크플로우의 핵심으로 다시 위치시킨다.
함정 3. 비전 에이전트의 숨겨진 45배 비용
세 번째 함정은 가장 수치로 명확하다. reflex.dev의 벤치마크는 같은 관리자 패널 작업을 비전 에이전트(스크린샷+클릭)와 API 에이전트(구조화 응답 직접 호출) 두 방식으로 수행하고 결과를 비교했다. 숫자가 모든 걸 말한다. Claude Sonnet 기준으로 비전 에이전트는 평균 53단계, 약 17분, 입력 토큰 550,976개를 소비했다. API 에이전트는 8회 호출, 19.7초, 입력 토큰 12,151개로 끝났다. 비용 격차는 약 45배.
더 중요한 건 왜 이런 차이가 나는가다. 비전 에이전트는 화면에 보이는 것만 읽는다. 리뷰 페이지에서 스크롤 아래 숨겨진 항목 3개를 놓쳤고, 결국 4개 중 1개만 처리하고 완료로 판단했다. 이건 모델의 추론 실패가 아니다. 렌더링된 UI가 전체 데이터를 보여주지 않는다는 신호 자체가 없었기 때문이다. API 에이전트는 같은 핸들러를 호출하지만 구조화된 전체 응답을 받으므로 이런 실수가 원천적으로 발생하지 않는다.
비전 에이전트에게 14단계 UI 안내를 추가하자 작업은 완료됐다. 하지만 그 14단계를 작성하는 비용 자체가 별도의 엔지니어링 작업이 된다는 사실이 핵심이다. 프롬프트 엔지니어링 비용은 토큰 수에 잡히지 않는다. 그리고 비전 경로의 실행 변동성(토큰 40만~75만, 시간 749~1257초)은 예산 예측 자체를 불가능하게 만든다.
시사점: 개인 개발자가 지금 바꿔야 할 판단 기준
이 세 가지 사례가 공통으로 가리키는 방향은 하나다. AI 코딩 도구의 실제 비용은 실행 중이 아니라 그 이전에 결정된다. 프롬프트를 어떻게 구성하느냐, 컨텍스트를 얼마나 사전에 정제하느냐, 그리고 어떤 인터페이스 방식을 선택하느냐—이 세 가지 판단이 결과물의 품질과 비용을 이미 90% 결정하고 있다.
개인 개발자나 프론트엔드 관점에서 실천 가능한 기준을 정리하면 이렇다. 첫째, AI에게 요청하기 전에 수정 범위를 명시적으로 제한하라. "이 파일의 이 함수만 바꿔"가 "이 기능을 개선해"보다 언제나 낫다. 둘째, 컴포넌트나 모듈을 AI에게 분석시키기 전에 의존성 맵을 먼저 만들어라—AI가 아니라 내가. 셋째, 내부에서 직접 만드는 도구라면 비전 에이전트보다 API 기반 접근을 기본으로 고려하라. 45배의 비용 차이는 프로토타입 단계에선 무시할 수 있지만 반복 실행되는 에이전트 워크플로우에서는 치명적이다.
'빠르게 만든다'는 약속은 틀리지 않다. 다만 그 빠름은 실행 속도가 아니라 올바른 판단을 내리는 속도에서 온다. 프롬프트 품질, 컨텍스트 설계, 인터페이스 선택—이 세 가지를 먼저 설계한 사람이 AI 도구의 진짜 속도를 얻는다.