6주. Next.js 14, Firebase, Gemini Flash, Vercel. 사이드바에 Workspace, Databases, Custom Agents, Notebook Templates까지 얹은 AI 데이터 분석 도구 WhyAnalyst가 탄생했다. dev.to에 공개된 이 빌딩 로그는 기술 스택 선택기가 아니다. AI SaaS를 혼자 짓는 개발자가 실제로 맞닥뜨리는 결정들—비용, 아키텍처, 그리고 가장 중요한 것—의 기록이다.
비용이 먼저 프로젝트를 죽일 뻔했다
첫 구현은 단순했다. CSV 전체를 GPT-4에 던지고 답을 받는 방식. 500행 10열 파일 하나에 쿼리당 5,000~10,000 토큰. 규모가 붙으면 비용이 폭발하는 구조였다. 해결책은 패러다임 전환이었다. 원본 데이터 대신 컬럼명·샘플 5행·행 수·타입 추론값만 보내고, AI가 분석 코드를 생성하면 실제 데이터는 클라이언트에서 실행하는 방식으로 바꿨다. GPT-4에서 Gemini 1.5 Flash로 모델도 교체했다. 결과: 비용 85% 절감. 체감 품질 차이는 거의 없었다.
이 결정이 흥미로운 이유는 단순한 비용 최적화가 아니기 때문이다. 데이터를 서버로 올리지 않고 브라우저에서 파싱하는 아키텍처는 사용자 프라이버시 보호라는 부수 효과를 낳았다. CSV와 Excel이 브라우저 안에서만 처리되고, 질문을 던지기 전까지 데이터는 외부로 나가지 않는다. 비용 압박이 더 나은 UX 설계를 강제한 셈이다. 제약이 오히려 올바른 방향을 가리키는 경우가 있다.
가장 비싼 실수는 코드가 아니었다
기술적으로 가장 값비싼 실수는 GPT-4 선택이었다. 하지만 프로덕트 관점에서 가장 비싼 실수는 따로 있었다. 사용자와 한 마디도 나누기 전에 사이드바를 가득 채운 것. Workspace, Databases, Custom Agents, Mission Log—대부분 빈 껍데기였고, 실제 사용자들이 원한 건 단 하나였다. 파일 올리고 질문하기. 그게 전부였다.
가장 많이 요청된 기능은 사이드바 어디에도 없던 'PNG 차트 다운로드'였다. 상상 속 사용자를 위해 6주를 쓴 결과다. 이건 AI 도구 활용의 문제가 아니라 프로덕트 빌딩의 고전적 함정—빠른 개발이 이 함정을 더 깊게 판다. AI가 구현 속도를 올려줄수록, 검증 없이 쌓이는 기능의 속도도 같이 올라간다.
AI는 가속기지, 판단 대체재가 아니다
dev.to의 또 다른 개발자 Kunal Pareek는 비슷한 시기에 다른 각도에서 같은 결론에 도달했다. 프론트엔드, API, 백엔드, WordPress 플러그인, 자동화 워크플로우를 넘나드는 풀스택 개발 루틴에서 AI를 맥락 전환의 마찰을 줄이는 가속기로 쓴다고 설명한다. 보일러플레이트 생성, 컴포넌트 구조 탐색, 디버깅 시 문서·이슈 탐색 시간 단축—여기까지는 많은 개발자가 공감하는 지점이다.
그런데 그가 특히 강조한 부분은 AI를 쓰지 않는 경우다. 아키텍처 결정, 시스템 설계, 확장성 고려, 유지보수성 트레이드오프—이 영역은 여전히 자신의 판단을 먼저 쓴다. 이유는 명확하다. "기술적으로 동작하는 코드가 프로덕션에 적합한 코드는 아니다." 생성된 코드를 그대로 쓰는 것이 아니라 로직 검증, 엣지 케이스 검토, 불필요한 복잡도 제거, 기존 아키텍처 적합성 판단을 거친다. AI 출력을 평가하는 능력 자체가 엔지니어링 역량이 되고 있다.
빠른 실험이 학습을 가속한다, 단 기반이 있을 때
두 사례가 공통으로 가리키는 지점이 있다. AI 도구가 실험의 비용을 극적으로 낮춘다는 것. WhyAnalyst 사례에서는 모델 교체, 아키텍처 전환, 다양한 사용자 획득 채널 시도가 6주 안에 이루어졌다. 예전이라면 각각이 며칠짜리 결정이었을 것들이다. Pareek의 경우도 낯선 라이브러리 탐색, 구현 패턴 비교, 아키텍처 프로토타이핑이 훨씬 빠르게 돌아간다고 말한다.
하지만 두 사람 모두 강조하는 전제가 있다. 기반 이해 없이 AI를 쓰면 취약한 시스템을 빠르게 만들 뿐이다. Pareek는 AI 툴이 없던 시절 WordPress 플러그인과 프로덕션 디버깅을 깊게 파고들었던 경험이 지금 AI 출력을 판단하는 기준이 된다고 말한다. WhyAnalyst 개발자도 "코드 한 줄 쓰기 전에 10명의 잠재 사용자와 이야기했어야 했다"고 회고한다. 빠른 도구가 잘못된 방향을 더 빠르게 가는 것을 막지는 못한다.
솔로 빌더에게 AI가 실제로 바꾼 것
팀 거버넌스나 에이전트 오케스트레이션 논의가 아닌, 혼자 제품을 짓는 개발자 관점에서 AI가 실질적으로 바꾼 것은 무엇인가. 인프라 비용 구조다. WhyAnalyst는 사용자 0명일 때 월 비용이 사실상 $0이다. 100명의 무료 사용자가 생겨도 크게 다르지 않다. Firebase, Vercel, Gemini Flash의 무료 티어가 초기 검증 단계를 통째로 커버한다. 이전 세대의 솔로 빌더가 부담해야 했던 인프라 진입 비용이 사라졌다.
동시에 AI가 낮추지 못한 것도 있다. 사용자가 실제로 원하는 것을 파악하는 비용. Reddit r/datascience에 데모 GIF를 올리고, 빌딩 인 퍼블릭으로 Twitter에 공유하고, 이런 글을 쓰는 것—이 모든 사용자 획득 실험은 AI가 대신할 수 없다. 그리고 가장 중요한 것: 무엇을 만들지 결정하는 순간도 마찬가지다.
만들기 전에는 알 수 없는 것들이 있다
두 사례가 남기는 가장 실용적인 통찰은 역설적으로 단순하다. AI가 개발 속도를 올리면 올릴수록, 만들고 나서야 보이는 것들—실제 사용자 행동, 예상치 못한 비용 구조, 진짜 필요한 기능—을 더 빨리 마주칠 수 있다. 이것이 '빠른 프로토타이핑 → 검증 → 고도화' 루프의 실제 가치다. AI는 이 루프를 더 많이, 더 빠르게 돌릴 수 있게 해준다. 하지만 루프 자체는 여전히 직접 돌려야 한다.
솔로 빌더에게 AI 도구가 주는 진짜 선물은 전지전능한 코드 생성이 아니다. 잘못된 방향을 빠르게 발견하고 수정할 수 있는 속도다. 단, 그 발견은 실제 사용자 앞에 제품을 내놓았을 때만 일어난다. 코드는 AI가 짜줄 수 있어도, 부딪히는 일은 직접 해야 한다.