배포는 끝이 아니라 시작이 됐다
1주일 만에 SaaS를 만들어 배포하는 일이 더 이상 무용담이 아닌 시대다. Next.js App Router, Supabase, Stripe를 조합하면 인증·결제·DB를 갖춘 실서비스를 혼자서, 빠르면 며칠 안에 올릴 수 있다. dev.to에 올라온 SiteGrade 빌드 로그는 그 현실을 담담하게 증명한다. 인프라 비용은 초기에 거의 0, 아키텍처는 '지루할 만큼 검증된' 스택, 그리고 실제 사용자 문제("내 사이트 SEO 괜찮아요?")에서 출발한 명확한 가치 제안. 이 정도면 충분하지 않을까?
문제는 바로 그 다음 주다. 배포 직후의 흥분이 가라앉으면, 진짜 질문들이 줄을 선다. 웹훅이 가끔 씹히는 것 같은데 재현이 안 된다. 프롬프트를 조금 바꿨더니 결과물이 달라진 것 같기도 하고 아닌 것 같기도 하다. 사이트 25%가 감사 요청을 거부하는데 왜인지 모른다. 빠르게 만드는 능력과, 만든 것을 지속 가능하게 운영하는 능력은 근본적으로 다른 근육이다.
실전 빌드가 드러낸 것들
SiteGrade 빌드 로그에서 가장 인상적인 부분은 완성된 아키텍처가 아니라, 실패한 시도들의 밀도다. 첫 번째 페처는 단일 User-Agent를 썼고, 결과적으로 25%의 사이트가 403을 뱉었다. 해결책은 UA 로테이션—브라우저 UA 시도 → 실패 시 Googlebot UA → 실패 시 Bingbot UA 순으로 폴백하는 멀티패스 방식. 많은 WAF가 Googlebot을 기본 허용하는 점을 역이용한 것이다. 이 한 줄의 설계 변경으로 에러율이 25%에서 6%로 떨어졌다.
Stripe 웹훅 처리도 마찬가지다. 교과서적인 흐름—사용자 결제 → 웹훅 수신 → DB 업데이트—은 웹훅이 단 한 번이라도 유실되면 사용자는 돈을 냈는데 무료 티어에 갇히는 최악의 UX를 만든다. 해결책은 '웹훅을 1순위로 두되, 유일한 경로로 삼지 않는다'는 방어 설계다. 대시보드 진입 시 Stripe에서 직접 구독 상태를 재동기화하는 syncProfileFromStripe() 헬퍼를 구현해, 웹훅이 실패해도 사용자가 대시보드를 여는 순간 자가 복구된다. 이건 코드의 문제가 아니라 장애를 전제하는 사고방식의 문제다.
Vibe Computing이 바꾸는 전제
이 모든 맥락에서 'Vibe Computing'이라는 개념이 의미를 갖는다. dev.to에 소개된 이 개념은 Vibe Coding—AI에게 의도를 말하면 코드를 생성해주는 워크플로우—을 소프트웨어 개발 너머로 확장한다. 이메일 발송, CRM 업데이트, 일정 조율, 리포트 첨부를 개별 앱을 오가며 수동으로 실행하는 대신, 에이전트에게 의도를 넘기면 알아서 실행 경로를 찾아간다.
프론트엔드 개발자 관점에서 이 전환이 흥미로운 이유는 따로 있다. 실행의 자동화가 빨라질수록, 판단의 책임은 더 선명하게 인간에게 남는다. SiteGrade 빌더가 UA 로테이션을 설계하고, 웹훅 폴백 경로를 설계하고, Vercel Cron으로 주간 리포트 파이프라인을 설계한 것처럼—AI가 코드를 생성해줄 수는 있지만, 어떤 실패를 전제하고 어떤 복구 경로를 만들 것인지는 여전히 설계자의 몫이다. 'Vibe'가 높아질수록 '의도를 얼마나 정확하게 정의할 수 있는가'가 새로운 역량 기준이 된다.
검증 없는 빌드 루프의 함정
빠른 빌드 사이클의 또 다른 맹점은 AI 워크플로우 자체에 있다. 프롬프트를 조금 수정하고 "아까보다 나아진 것 같은데"라고 느끼며 배포하는 패턴—dev.to의 프롬프트 A/B 테스팅 글은 이 감각의 위험성을 데이터로 직격한다. 사람은 가장 최근의 출력을 가장 좋은 출력으로 기억하는 경향이 있다. 샘플 크기는 1이고, 비교 기준은 흐릿한 기억이며, 레이턴시·비용·출력 드리프트는 채팅 UI에서 전혀 보이지 않는다.
실제 실험 결과는 직관을 자주 배신한다. 1,800 토큰짜리 상세 시스템 프롬프트와 280 토큰짜리 간결한 버전을 같은 입력에 병렬로 돌렸더니, 탐지한 이슈 수는 7개 대 6개로 거의 같았지만 비용은 28% 차이, 레이턴시는 41% 차이가 났다. '더 나은 느낌'이 아니라 같은 입력을 두 프롬프트에 동시에 던져 숫자로 비교하는 것—이것이 Promise.all()로 두 요청을 병렬 실행하는 단순한 구조가 주는 실질적인 가치다.
모델 선택도 같은 프레임으로 볼 수 있다. Sonnet 4.5와 Haiku 4.5를 같은 프롬프트·같은 입력에 병렬로 돌리면 약 13배의 비용 차이가 드러난다. 태스크 유형에 따라 품질 차이가 무시할 만한 수준이라면, 비용 최적화는 '느낌'이 아닌 측정의 문제다.
빌드 이후를 설계하는 세 가지 기준
세 가지 소스가 함께 가리키는 방향을 정리하면 이렇다.
첫째, 실패를 전제한 설계. 웹훅은 유실된다. 사이트는 봇을 막는다. 결제는 성공했지만 DB는 아직 모른다. 이 모든 시나리오를 처음부터 예상하고 복구 경로를 설계하는 것이 '지루한 스택'의 진짜 의미다. 도구가 검증됐다는 건 실패 패턴도 알려져 있다는 뜻이다.
둘째, 의도의 정밀화. Vibe Computing이 확산될수록, 에이전트에게 넘기는 의도가 얼마나 명확한가가 결과물의 품질을 결정한다. 프롬프트 엔지니어링도, 에이전트 태스크 정의도, 결국 '무엇을 원하는지'를 정확하게 언어화하는 능력의 문제다.
셋째, 감각 대신 숫자. "더 나아진 것 같아"는 의사결정 기준이 아니다. 같은 입력, 병렬 실행, 레이턴시·비용·출력 세 숫자의 동시 비교—이 루프를 생략하면 조용한 회귀가 프로덕션에 쌓인다.
전망: 속도가 상수가 되면, 검증이 변수가 된다
빌드 속도가 계속 빨라진다면—그리고 모든 신호가 그 방향을 가리키고 있다면—경쟁 우위는 빠르게 만드는 능력에서 빠르게 만든 것을 제대로 검증하고 고도화하는 능력으로 이동한다. 1주일 만에 배포하는 것은 이제 진입 비용이다. 다음 주에도, 그다음 달에도 살아남으려면 실패를 전제하는 아키텍처, 의도를 정밀화하는 프롬프트 설계, 그리고 감각 대신 데이터로 반복하는 검증 루프가 필요하다. AI가 실행을 가속할수록, 설계 판단의 품질이 제품의 천장을 결정한다.