1주일 만에 프로덕션 SaaS가 나왔다
인도의 한 물리치료사가 건넨 질문 하나—"클리닉 전체를 운영할 수 있는 걸 만들어줄 수 있어요?"—가 제품으로 바뀌는 데 걸린 시간은 딱 일주일이었다. dev.to에 공개된 PhysioFlow 사례는 그 결과물이다. Next.js + Supabase + TypeScript 스택 위에 대시보드, 환자 파일 관리, QR 출석, GST 청구서 자동 생성, CSV/PDF 리포트, 환자 포털까지 올린 멀티테넌트 SaaS가 7일 만에 라이브로 올라갔다. 솔로 개발자가, 인도 시장의 맥락(루피, GST, WhatsApp, +91)을 모두 반영하면서.
이걸 "대단하다"로 소비하고 끝내면 아무 의미가 없다. 진짜 질문은 이거다. 어떤 구조로 일해야 이게 가능한가?
속도는 도구 스펙이 아니라 워크플로우에서 나온다
PhysioFlow가 빠를 수 있었던 이유는 Next.js나 Supabase가 빠른 프레임워크이기 때문이 아니다. 도구 선택 이전에 "무엇을 만들지"가 명확했기 때문이다. 실제 사용자(물리치료사)의 실제 문제(클리닉 운영 전체)를 단일 화면으로 해결한다는 스코프가 처음부터 고정되어 있었다. AI 도구가 생산성을 끌어올리는 건 맞지만, 스코프가 흔들리는 상태에서 빠르게 달리면 그냥 더 빠르게 길을 잃는다.
프로토타이핑 속도를 결정하는 건 세 가지다. 첫째, 컨텍스트 품질—AI에게 넘기는 정보가 얼마나 정확하고 간결한가. 둘째, 스택의 친숙도—직접 판단하고 수정할 수 있는 영역과 AI에게 위임할 영역을 구분할 수 있는가. 셋째, 검증 루프의 속도—만든 것을 실제 사용자에게 얼마나 빨리 보여줄 수 있는가.
AI 컨텍스트 최적화: 넘기기 전에 설계하라
dev.to에서 공개된 또 다른 사례는 이 첫 번째 조건을 정면으로 다룬다. 데이터 사이언티스트가 Repomix로 프로젝트 전체를 LLM에 넘겼더니 22,000KB짜리 파일이 나왔다. Claude는 그걸 소화하지 못했다. 그래서 직접 data2prompt라는 도구를 만들었는데, 핵심 아이디어는 단순하다. 파일 타입마다 다른 전략을 쓴다. CSV는 랜덤 샘플링 15행, SQL은 스키마만 보존하고 INSERT 행은 샘플링, Jupyter 노트북은 셀 소스만 유지하고 base64 이미지 출력은 제거. 결과적으로 동일한 프로젝트에서 Repomix 대비 98.9% 용량 감소, 241KB짜리 컨텍스트가 만들어졌다.
이게 프로토타이핑 워크플로우와 무슨 관계인가? AI에게 넘기는 컨텍스트가 나쁘면, 빠르게 나온 코드도 쓸 수 없는 코드가 된다. 프로토타이핑 속도를 높이고 싶다면 코드를 더 잘 쓰는 법보다, AI가 읽을 수 있는 형태로 프로젝트를 정리하는 법을 먼저 설계해야 한다. Repomix나 data2prompt 같은 도구가 그 사이에 끼어드는 이유다.
자동화 봇이 알려준 것: 반복을 없애야 속도가 생긴다
세 번째 사례는 방향이 다르다. Claude API와 GitHub Actions로 Twitter/X 타임라인을 자동 분류하는 봇을 만든 이야기인데, 핵심 교훈은 "반복 작업을 없애지 않으면 프로토타이핑 시간이 아무리 줄어도 개발자의 총 인지 부하는 줄지 않는다" 는 것이다.
이 개발자는 매일 아침 50분을 타임라인 정리에 쓰고 있었다. 312개의 키워드 뮤트를 걸어도 노이즈는 80%였다. 문제의 본질을 파악했을 때 해결책이 보였다. "뮤팅은 문자열 매칭 문제가 아니라 분류 문제다." gpt-4o-mini로 이진 판단(keep/mute)을 내리고, 이유를 한 줄로 요약하게 한 뒤 Discord로 다이제스트를 보내는 파이프라인을 GitHub Actions 크론으로 무료로 돌렸다. 결과: 50분 → 14.5분, 71% 감소.
이 구조가 프로토타이핑 워크플로우에 주는 시사점은 명확하다. 제품을 만드는 시간을 늘리려면 제품을 만들지 않는 시간을 줄여야 한다. 반복적인 정보 수집, 코드 리뷰 준비, 이슈 트리아지—이 모든 곳에 같은 원리가 적용된다.
세 사례를 엮으면 보이는 워크플로우 구조
세 사례는 각각 다른 문제를 다루지만, 하나의 패턴을 공유한다.
1단계 — 컨텍스트를 설계한다. AI에게 무엇을 어떤 형태로 넘길지를 먼저 결정한다. data2prompt 사례처럼, 넘기는 정보의 품질이 출력의 품질을 결정한다. 프롬프트 엔지니어링 이전에 컨텍스트 엔지니어링이 있다.
2단계 — 스코프를 고정하고 빠르게 만든다. PhysioFlow처럼, 사용자의 실제 문제를 명확히 정의한 뒤 AI 도구로 구현 속도를 끌어올린다. 이때 "1주일 완성"은 목표가 아니라 결과다. 스코프가 명확하면 속도는 따라온다.
3단계 — 반복을 자동화해서 인지 여유를 만든다. Claude + GitHub Actions 사례처럼, 반복 작업을 파이프라인으로 넘기면 개발자가 판단에 집중할 수 있는 시간이 늘어난다. 프로토타이핑 사이클이 빨라지는 건 이 여유에서 비롯된다.
지금 시작하려는 사람에게
"AI로 빠르게 만들기"를 실천하려는 사람에게 가장 자주 빠지는 함정은 도구 선택에 너무 많은 에너지를 쓰는 것이다. Cursor냐 Claude Code냐, v0.dev냐 직접 코딩이냐—이 질문들은 실제로 덜 중요하다.
더 먼저 물어야 할 것은 이거다. "사용자의 문제를 한 문장으로 말할 수 있는가?" "AI에게 넘길 컨텍스트가 간결하게 정리되어 있는가?" "만든 것을 사용자에게 보여줄 수 있는 가장 빠른 방법은 무엇인가?"
PhysioFlow는 이 세 질문에 답이 있었기 때문에 1주일 만에 나왔다. 도구는 그 다음이었다.
전망: 프로토타이핑 워크플로우가 개발자의 새 역량이 된다
앞으로 "AI로 만들었다"는 말은 차별점이 되지 않는다. 누구나 AI를 쓸 수 있게 되면, 경쟁 우위는 AI를 어떤 워크플로우 안에서 쓰느냐로 이동한다. 컨텍스트를 설계하는 능력, 스코프를 고정하는 판단력, 검증 루프를 짧게 유지하는 훈련—이 세 가지가 AI 시대 프론트엔드 개발자의 실질적인 역량이 된다.
도구는 계속 좋아진다. 하지만 좋은 도구를 어떻게 엮느냐는 여전히 사람의 몫이다.