🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Micro-SaaS를 60 Minutes 안팎에 만들 수는 있었지만, Fable 5의 자동 생성 결과를 실제 제품으로 바꾸려면 계획 모드, 실제 테스트, 확장 로딩·권한·저장·결제 같은 검증 단계가 핵심이었다.

📌 핵심 요점

1. 이번 영상은 재미용 3D 데모가 아니라 geoextension.com이라는 실제 도메인을 바탕으로 중소기업용 GEO Chrome 확장 프로그램, 랜딩 페이지, 웹 앱을 만드는 실전형 마이크로 SaaS 프로토타입에 초점을 맞춘다.
2. 구현 전에 PRD 없이도 계획 모드에서 제품 목적, 대상 사용자, 사용 흐름, 초기 제약을 먼저 정리했고, 이를 통해 데모 데이터나 불필요한 기능이 섞이는 위험을 줄이려 했다.
3. V1은 사용자가 OpenAI, Anthropic, Gemini, Perplexity 같은 LLM API 키를 직접 넣는 bring-your-own-key 방식이며, 일부 키만 있어도 작동해야 하고 API 키가 없어도 on-page SEO audit 기반 테스트가 가능해야 한다는 제약이 설정됐다.
4. 약 1시간 넘게 진행된 빌드 이후 실제 검증 과정에서 manifest 위치, unpacked extension 로딩, 활성 탭 감지, permission, build 실행 위치 같은 현실적인 문제가 드러났고, 자동 생성 결과는 바로 완성품이 아니라 디버깅 가능한 초안에 가깝다는 점이 확인됐다.
5. 최종적으로 geoextension.com을 실제 배포 가능한 제품으로 발전시키려면 백엔드, 데이터 저장, 리포트 보존, 결제 또는 패스 모델, 온보딩 흐름 개선, 랜딩 페이지 디자인 보강이 다음 단계로 남았다.

🧩 배경과 문제 정의

• 이전 Fable 실험은 3D 축구 게임처럼 재미와 데모성에 가까운 프로젝트였지만, 이번 영상은 실제로 따라 만들 수 있는 마이크로 SaaS 프로토타입 구축에 초점을 둔다.
• 핵심 아이디어는 geoextension.com이라는 도메인을 기반으로, 중소기업이 LLM 답변과 생성형 검색 환경에서 더 잘 노출되도록 돕는 GEO 도구를 만드는 것이다.
• 제품 형태는 Chrome 확장 프로그램, 랜딩 페이지, 웹사이트, 가벼운 웹 앱까지 포함되며, 초기 사용자는 OpenAI, Anthropic, Gemini, Perplexity 같은 모델 제공자의 API 키를 직접 입력하는 bring-your-own-key 방식으로 설정된다.
• 초기 버전은 결제·저장·사용량 관리까지 갖춘 완성형 SaaS라기보다, 실제 제품화 가능성을 검증하는 V1 프로토타입에 가깝다.
• 주요 문제는 기획 없이 바로 구현에 들어갈 경우 데모 데이터, 불필요한 기능, 잘못된 권한 설정, 확장 프로그램 빌드 구조 문제 등이 뒤섞일 수 있다는 점이다.
• 따라서 영상의 핵심 흐름은 “먼저 계획 모드로 목적과 사용자 문제를 고정한 뒤, 제한된 시간 안에 실제 작동 가능한 제품 뼈대를 만들고 검증한다”는 방식으로 정리된다.

🕒 시간순 섹션별 상세정리

1. 실험 중심에서 실전형 마이크로 SaaS 구축으로 전환

• Fable 복귀 이후 이전 라이브에서는 고추론 모드로 3D 렌더링 축구 게임을 만들었지만, 이번에는 재미 중심 데모보다 실제 제품화 가능성이 있는 실용적 빌드를 목표로 삼는다 [00:24]
• 프로젝트의 출발점은 geoextension.com이라는 보유 도메인이며, 먼저 V1 프로토타입을 만든 뒤 다음 주에는 프로덕션 배포까지 이어가는 흐름이 나온다 [00:39]

2. PRD 없이 계획 모드에서 제품 목적과 사용자 문제를 먼저 고정

• 별도의 PRD나 마스터 프롬프트를 준비하지 않은 상태에서 plan mode로 들어가며, 바로 구현하지 않고 제품의 목적, 대상 사용자, 사용 흐름을 먼저 잡는다 [01:02]
• 제품 범위는 Chrome 확장 프로그램, 랜딩 페이지, 웹사이트, 웹 앱 버전까지 포함되며, 대상 사용자는 LLM 전반에서 노출을 늘리고 싶은 중소기업으로 설정된다 [01:14]

3. 구현 전 계획에서 범위, 제공자, UI 방향을 압축

• 초기 프롬프트에서는 기술 스택을 먼저 고정하지 않고, 무엇을 만들지, 왜 필요한지, 누구를 위한지에 집중하며 기술 선택은 계획이 나온 뒤 조정하는 순서로 진행된다 [02:29]
• 빌드 순서는 확장 프로그램을 우선하되 Chrome extension, landing page, lightweight web app을 함께 만들고, LLM provider는 가능한 항목을 넓게 포함하는 방향으로 잡힌다 [03:02]

4. BYOK, 선택형 LLM, 무키 기반 감사 기능으로 V1 제약을 명확화

• 계획 문서의 핵심은 GEO toolkit extension, landing page, web app이며, 중소기업이 LLM 답변에서 가시성을 높이도록 돕는 generative engine optimization 도구라는 방향으로 압축된다 [04:30]
• 사용자는 OpenAI, Anthropic, Gemini, Perplexity API 키를 직접 입력하며, 서버에는 거의 아무것도 닿지 않고 웹 앱의 pass-through proxy만 예외로 남는 구조가 제안된다 [04:56]

5. 프런트엔드 취향과 테스트 원칙으로 자동 생성의 방향을 통제

• 기본 프런트엔드 디자인 스케일은 유지하되 shadcn component library를 사용하고, 패키지 매니저는 PNPM 대신 bun을 쓰는 개인 선호가 계획에 추가된다 [06:40]
• browser core나 extension permission 같은 위험 요소가 계획에 포함되며, extension page와 host permission 문제를 구현 전에 미리 고려하는 흐름이 생긴다 [07:17]

6. 1시간 빌드 이후 검증 단계에서 빌드·확장 로딩 문제가 드러남

• 계획이 정리된 뒤 바로 구현으로 넘어가며, 세부 스타일링을 더 깊게 조정하기보다는 Fable이 만든 기본 구조를 먼저 확인하는 선택이 이뤄진다 [09:18]
• 빌드는 약 1시간 조금 넘게 걸렸고, 중간의 Claude API 오류와 서비스 장애가 없었다면 60분 안쪽으로 끝났을 가능성이 있었다고 압축된다 [09:43]

7. Chrome 확장 로딩 과정에서 manifest 위치 문제가 드러남

• Chrome 확장을 unpacked extension으로 불러오려는 단계에서 manifest를 찾지 못했고, Fable 5가 중요한 빌드 세부사항을 놓친 것처럼 보이는 문제가 발생한다 [12:52]
• manifest는 실제로 누락된 것이 아니라 숨김 폴더인 .output 아래 Chrome 빌드 산출물에 있었고, 숨김 폴더를 켠 뒤 확장 프로그램을 로딩할 수 있었다 [13:08]

8. API 키 온보딩과 활성 탭 감지 버그가 초기 사용 흐름을 막음

• 온보딩 첫 단계는 OpenAI와 Anthropic API 키를 직접 입력하는 방식이며, 베타 단계에서는 사용자가 자기 키를 가져오는 구조가 핵심 사용 조건으로 드러난다 [13:45]
• 비즈니스 이름 단계에서 “No active tab found” 오류가 발생했고, 확장 프로그램이 현재 탭을 감지하지 못하면 웹페이지 데이터를 자동으로 가져오는 온보딩 가치가 크게 떨어진다 [14:18]

9. 프로토타입에서 Micro-SaaS로 가려면 저장·결제·사용 흐름이 보강돼야 함

• 현재 구조는 bring-your-own-key 확장이기 때문에 백엔드와 데이터베이스가 빠져 있으며, 생성된 리포트와 출력물을 저장하려면 별도 저장 계층이 중요한 요구사항이 된다 [15:04]
• 다음 버전은 Fable 5로 실제 프로덕션 버전을 배포하는 방향이며, Micro-SaaS 기능, 결제 모델, 사용량 기반 플랜 대신 사용자 API 키 기반 모델을 함께 검토한다 [15:21]

10. 실제 배포 목표와 장시간 작업 모델의 가능성이 정리됨

• 결과물은 화려한 3D 데모는 아니지만 실제로 출시하고 싶은 확장 프로그램 수준에 도달했고, 다음 주 목요일까지 geoextension.com을 라이브로 만드는 목표가 생긴다 [17:33]
• 수정은 작성됐지만 Anthropic 서비스 장애 때문에 Claude가 rebuild를 실행하지 못했고, 외부 모델 서비스 상태가 프로토타입 검증 속도에 직접 영향을 줄 수 있다는 점이 마지막 리스크로 남는다 [18:13]

🧾 결론

• Fable 5와 Claude를 활용하면 마이크로 SaaS의 초기 골격을 짧은 시간 안에 만들 수 있지만, 성공 여부는 생성 속도보다 실제 사용자 흐름을 테스트하고 막히는 지점을 빠르게 고치는 능력에 달려 있다.
• 이번 프로토타입의 핵심 가치는 “LLM 답변과 생성형 검색 환경에서 중소기업이 어떻게 더 잘 노출될 수 있는가”라는 구체적인 문제를 Chrome 확장 프로그램과 가벼운 웹 리포트 도구로 연결한 점이다.
• 반대로 아직 완성된 SaaS라고 보기는 어렵다. 현재 단계에서는 BYOK 확장, 랜딩 페이지, 웹 앱 초안이 만들어졌고, 저장 계층·결제·사용량 모델·프로덕션 배포·온보딩 안정성은 추가 검증이 필요하다.
• 영상에서 가장 실용적인 교훈은 자동 생성 도구에 바로 “만들어 달라”고 맡기기보다, 먼저 사용 대상, 입력값, 출력물, 실패 조건, 테스트 원칙을 좁혀야 결과물이 실제 제품에 가까워진다는 점이다.

📈 투자·시사 포인트

• 마이크로 SaaS 관점에서는 “사용자 API 키 기반 BYOK 모델”이 초기 인프라와 운영 부담을 낮추는 방식으로 제시된다. 다만 일반 사용자에게 API 키 입력은 진입장벽이 될 수 있어, 실제 전환율은 별도 검증이 필요하다.
• 생성형 검색 최적화, 즉 GEO에 대한 수요가 중소기업 대상으로 존재할 수 있다는 가정이 깔려 있다. 하지만 영상 안에서는 시장 규모, 지불 의향, 경쟁 제품 비교가 검증되지는 않았으므로 투자 판단에는 추가 시장 조사가 필요하다.
• Fable 5 같은 장시간 자동 빌드 도구는 초기 프로토타입 제작 속도를 크게 높일 수 있다. 그러나 manifest, permission, active tab 감지처럼 브라우저 확장 특유의 세부 오류는 여전히 사람이 직접 확인해야 한다.
• SaaS화의 핵심 병목은 코드 생성 자체보다 배포, 저장, 결제, 반복 사용 흐름, 리포트 관리, 신뢰 가능한 결과 품질에 있다. 즉 “만드는 속도”보다 “운영 가능한 제품으로 다듬는 과정”이 더 큰 가치 구간이다.
• 검증 필요 항목은 geoextension.com의 실제 라이브 배포 여부, 사용자가 생성한 리포트 저장 방식, 유료 패스 모델의 가격·전환율, API 키 입력 방식의 UX 부담, LLM 기반 가시성 점수의 신뢰도다.

⚠️ 불확실하거나 확인이 필요한 부분

• 제목의 “Claude's Fable 5” 표현은 영상 내에서 언급된 Fable 5와 Claude 기반 작업 흐름을 가리키는 것으로 보이지만, Fable 5가 정확히 어떤 제품·기능·통합을 의미하는지는 별도 확인이 필요하다.
• “60분 안에 Micro-SaaS 구축”이라는 표현은 실제로는 약 1시간 조금 넘게 걸렸고, Claude API 오류와 서비스 장애가 없었다면 60분 안쪽이었을 가능성이 있다는 맥락이므로, 완전한 60분 완성 사례로 단정하기는 어렵다.
• geoextension.com을 다음 주 목요일까지 라이브로 만들겠다는 목표는 언급됐지만, 영상 시점에서 실제 배포 완료 여부는 확인되지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 마이크로 SaaS를 자동 생성 도구로 만들기 전에 PRD 수준의 긴 문서가 없더라도 목적, 대상 사용자, 핵심 사용 흐름, 제외할 기능을 먼저 고정한다.
• V1에서는 demo data를 넣지 않고 실제 URL, 실제 비즈니스 정보, 실제 API 키 조건에서 테스트 가능한 흐름을 우선한다.
• Chrome 확장 프로그램을 테스트할 때는 루트 폴더가 아니라 실제 빌드 산출물 폴더, 특히 .output 아래 manifest 위치를 확인한다.
• “No active tab found” 오류처럼 온보딩 핵심 흐름을 막는 버그는 디자인 개선보다 먼저 수정 대상으로 둔다.

❓ 열린 질문

• BYOK 모델을 유지할 경우, 사용자의 API 키는 브라우저 로컬에만 저장되는가, 아니면 웹 앱이나 proxy 서버를 거치는가?
• 향후 유료화는 월간·연간 Pro Pass 중심이 될지, 사용량 기반 플랜이 될지, 아니면 BYOK 기반 저가 패스 모델이 될지 아직 열려 있다.
• “LLM 답변에서의 가시성”을 실제로 어떻게 측정할 것인가? 공개 LLM ranking이 없는 상황에서 SEO audit 점수만으로 충분한가?