"AI로 SaaS를 24시간 만에 완성했다"는 트윗을 본 적 있을 것이다. 실제로 해보면 그 24시간 이후가 문제라는 것도 알게 된다. 처음 며칠은 짜릿하다. 그런데 3주 차에 기능 하나를 바꾸려는 순간, 코드 전체가 낯설어진다. 내가 만든 건지 AI가 만든 건지 구분도 안 되고, 왜 이렇게 설계됐는지 설명도 못 한다. 이건 특정 도구의 문제가 아니다. 워크플로우 설계의 문제다.
병목 1: 플랫폼이 주는 속도, 플랫폼이 앗아가는 통제권
Replit, Lovable, Bolt.new 같은 AI-네이티브 플랫폼은 진입 장벽이 거의 없다. 브라우저에서 설명만 하면 앱이 올라온다. 데모와 초기 프로토타입에는 최고다. 문제는 그 이후다. dev.to에 게재된 Wasp 팀의 분석에 따르면, 이 플랫폼들은 공통적으로 "70% 문제"를 안고 있다. 인증 강화, 에러 핸들링, 성능 튜닝, 배포 설정—이 나머지 30%를 채우는 데 전문 개발 비용으로 5,000~20,000달러가 드는 경우도 있다는 추정이 나온다.
더 근본적인 문제는 인프라 결합도다. Lovable이 생성한 코드는 Supabase에 깊이 묶여 있고, Replit은 자체 인증·스토리지·DB에 종속된다. 컴포넌트 15~20개를 넘기면 AI 컨텍스트가 무너지기 시작해 코드 중복, 패턴 불일치, 일관성 붕괴가 연쇄적으로 발생한다. 누군가는 AI가 만들어낸 버그를 디버깅하는 데만 토큰 비용 1,000달러 이상을 썼다고 보고한다. 빠르게 시작했지만, 유지보수에서 오히려 더 느려지는 역설이다.
해법은 결국 로컬로 돌아오는 것이다. Claude Code, Cursor, Codex처럼 로컬 파일을 직접 다루는 AI 코딩 도구는 풀 컨트롤을 유지하면서도 원하는 스택으로 어디든 배포할 수 있다. 여기에 잘 구조화된 SaaS 보일러플레이트(인증·결제·이메일 등 반복 작업이 미리 해결된 스타터 킷)를 결합하면, AI에게 "빈 창고" 대신 "정돈된 작업실"을 주는 셈이다. AI가 구조적 결정을 임의로 내리는 게 아니라, 기존 패턴과 컨벤션을 따라 일관된 코드를 생성하게 된다.
병목 2: 매 세션마다 리셋되는 컨텍스트
로컬 도구로 넘어와도 또 다른 벽이 있다. Claude Code를 비롯한 대부분의 AI 코딩 에이전트는 세션 간 메모리를 유지하지 않는다. 매일 아침 새 세션을 열면, 어제 어디까지 했고, 어떤 네이밍 컨벤션을 쓰기로 했고, 왜 그 구조를 선택했는지를 처음부터 다시 설명해야 한다. 마치 매일 아침 천재적인 신입 사원에게 온보딩을 반복하는 것과 같다.
dev.to에서 이 문제를 직접 해결한 개발자의 접근 방식은 단순하지만 효과적이다. "AI는 파일을 읽는다"는 사실을 역이용하는 것이다. AGENTS.md(세션 부트 시퀀스), SOUL.md(에이전트 판단 기준과 커뮤니케이션 스타일), USER.md(작업자 정보와 선호 규칙), 그리고 날짜별 메모와 MEMORY.md(장기 컨텍스트 저장소)로 구성된 4파일 시스템이다. 세션이 시작될 때 에이전트가 이 파일들을 순서대로 읽으면, 50번째 세션도 1번째 세션처럼 처음부터 설명할 필요가 없다. 오히려 50번의 누적된 맥락을 갖고 시작한다.
특히 SOUL.md의 역할이 흥미롭다. 단순한 "설정 파일"이 아니라 AI의 판단 운영체제처럼 작동한다. "불확실하면 먼저 물어라", "외부 동작 전 확인을 받아라", "바꿨으면 작동 여부를 증명하라" 같은 원칙이 에이전트의 응답 일관성을 눈에 띄게 높인다. 여기에 복잡도에 따라 모델을 자동으로 전환하는 라우터를 추가하면 토큰 비용을 40~60%까지 줄일 수 있다는 실사용 결과도 나온다.
병목 3: 코드가 싸질수록 희소해지는 판단력
속도 문제와 컨텍스트 문제를 해결해도 세 번째 병목은 더 조용하고 더 위험하다. Moniepoint 엔지니어링팀의 분석이 정확히 짚는다. LLM은 이제 gRPC 서비스 정의부터 OAuth2 플로우, 마이크로서비스 간 계약 테스트까지 몇 시간 만에 뚝딱 만들어낸다. 표면적 품질은 더 이상 깊이의 신호가 아니다.
아름다운 README, 깔끔한 추상화, 자동 생성된 테스트 스캐폴딩—이 중 어느 것도 "파티션 리밸런싱 중 메시지 순서를 제대로 처리하는가"를 보장하지 않는다. 서킷 브레이커 임계값이 왜 40%가 아니라 60%인지, AI에게 다시 물어봐야 한다면 그건 이해가 아니라 의존이다. 코드 생성이 쉬워질수록 "왜 이렇게 설계했는가"를 설명할 수 있는 사람이 진짜 희소 자원이 된다.
이 변화는 PR 리뷰 문화에도 영향을 미친다. 생성하는 것보다 검토하는 것이 더 어려워지는 역전이 일어난다. AI가 데이터 파이프라인을 짜고, SQL을 최적화하고, 인프라를 설정했는데 아무도 전체 흐름을 이해하지 못한다면, 기술 부채는 눈에 보이지 않는 채로 쌓인다. 생산성 증가가 오늘의 취약성을 내일로 미루는 것에 불과해진다.
세 병목을 함께 잡는 워크플로우 설계
결국 AI 코딩 워크플로우는 세 층위를 동시에 설계해야 한다. 첫째, 플랫폼이 아닌 로컬 도구 + 구조화된 보일러플레이트로 통제권을 확보한다. 둘째, 컨텍스트 파일 시스템으로 세션 간 지식을 누적시킨다. 셋째, AI가 생성한 코드에 대한 소유권과 설명 책임을 팀 문화로 정착시킨다.
빠른 프로토타이핑의 가치는 부정할 수 없다. 하지만 속도는 도구가 준다. 3주 후에도 무너지지 않는 구조는 이 세 가지 병목을 얼마나 의식적으로 설계하느냐에 달려 있다. AI가 코드를 싸게 만들어줄수록, 설계하고 판단하고 설명할 수 있는 능력이 비싸진다. 그게 지금 프론트엔드 개발자에게 가장 중요한 경쟁력이다.