점포형 자영업 창업 AI Co-Founder 서비스 기획
작성일: 2026-08-20
상태: 아이디어/기획 정리
범위: 카페, 음식점, PC방, 노래방, 편의점, 의류매장, 무인매장, 생활서비스 등 물리적 점포 기반 자영업 창업
1. 한 줄 정의
사용자의 조건을 먼저 이해하고, 어떤 가게를 어디에 얼마로 열어야 하는지 조사·비교·검증한 뒤 실제 오픈까지 지속적으로 밀어주는 AI Co-Founder.
기존 서비스가 상권 데이터, 프랜차이즈 정보, 창업 견적, 상담, 체크리스트를 각각 제공한다면, 이 서비스는 여러 데이터를 한데 모아 창업 의사결정 자체를 대신 구조화하고 다음 행동까지 이어주는 것을 목표로 한다.
핵심 사용자 경험은 다음 질문에 답하는 것이다.
“내 조건으로 무슨 가게를, 어디에, 얼마를 들여 열어야 하고, 실제로 돈이 남을 가능성이 있는가?”
2. 왜 스코프를 ‘창업 전체’에서 ‘점포형 자영업’으로 줄이는가
처음에는 SaaS, 제조업, 온라인 비즈니스까지 포함하는 domain-agnostic 창업 Multi-Agent를 생각했다. 그러나 창업 전체는 도메인마다 핵심 변수가 너무 다르다.
- SaaS: CAC, LTV, Churn, MRR, 개발 기간, 투자
- 제조업: 설비, 생산, 공급망, 인증, 물류
- 콘텐츠/프리랜스: 개인 역량, 채널, 브랜딩, 수주
- 점포형 자영업: 상권, 임대료, 권리금, 초기투자, 객단가, 고객 수, 원가, 인건비, 영업시간
반면 점포형 자영업은 업종이 달라도 공통 의사결정 구조가 강하다.
flowchart LR
A[내 자본과 조건] --> B[어떤 업종]
B --> C[어느 지역/상권]
C --> D[어떤 점포]
D --> E[초기비용]
E --> F[예상 매출/비용]
F --> G[손익분기점/ROI]
G --> H[리스크 검증]
H --> I[계약/인허가/오픈]
따라서 MVP의 제품 정의는 **‘오프라인 점포형 자영업 창업 의사결정 및 실행 지원’**으로 제한한다.
포함 업종 예시
- 음식/음료: 카페, 일반음식점, 베이커리, 주점
- 소매: 편의점, 의류, 잡화, 애견용품
- 오락: PC방, 노래방, 보드게임카페
- 생활서비스: 세탁소, 무인빨래방, 사진관
- 뷰티: 미용실, 네일, 피부관리
- 공간/교육: 스터디카페, 독서실, 학원
초기 제외 범위
- SaaS/앱 스타트업
- 제조업
- 프리랜서/컨설턴트
- 유튜버/크리에이터
- 온라인 쇼핑몰만 운영하는 형태
- VC 투자 중심 스타트업
3. 핵심 타깃 사용자
Primary Persona
“회사 생활을 하거나 퇴사를 고민 중이며 자본은 있지만, 무슨 장사를 어디서 해야 하는지 판단하기 어려운 예비 자영업자.”
대표적인 상황:
- 자본은 수천만 원 정도 있지만 어떤 업종이 적합한지 모름
- 카페/식당/무인매장 등 몇 개 후보만 가지고 있음
- 상권분석 서비스가 많지만 데이터를 어떻게 해석해야 할지 모름
- 프랜차이즈와 개인창업 중 무엇이 나은지 모름
- 임대료, 권리금, 원가, 인건비를 합친 실제 수익성 계산이 어려움
- 창업 절차가 여러 사이트와 업체에 흩어져 있음
사용자 Entry Point
1. 아무 아이디어가 없음
2. 관심 업종 2~3개가 있음
3. 구체적인 사업 아이디어가 있음
4. 이미 점포/매물을 보고 있음
5. 기존 사업을 인수할지 고민 중
시스템은 Entry Point에 따라 Opportunity Discovery / Market Validation / Location Analysis / Launch Workflow 중 시작 단계를 바꾼다.
4. 온보딩: ‘무엇을 하고 싶은가’보다 ‘누구인가’를 먼저 받는다
너무 Open-ended한 대화형 시작은 피한다. 사용자가 처음부터 좋은 프롬프트를 작성해야 하는 구조가 아니라 온보딩 폼으로 Founder Constraint Profile을 먼저 만든다.
기본 온보딩 항목
| 구분 | 항목 | 활용 목적 |
|---|---|---|
| WHO | 이름 | 사용자 프로필 |
| WHO | 나이대 | 지원사업/생활 단계 참고 |
| WHO | 활동 지역 | 상권/지역/법규/지원사업 |
| WHO | 보유 역량/경력 | Founder fit |
| RESOURCE | 투입 가능 총예산 | 사업 규모 상한 |
| RESOURCE | 최대 감수 가능한 손실액 | 실질적인 Risk Budget |
| RESOURCE | 현재 상태 | 직장인/퇴사/사업중 등 |
| RESOURCE | 주당 투입 가능 시간 | 운영 형태 필터링 |
| RESOURCE | 팀/동업자 여부 | 실행 가능 범위 |
| GOAL | 목표 월소득 | 필요한 사업 규모 역산 |
| GOAL | 시작 희망 시점 | 실행 속도/일정 |
| PREFERENCE | 직접 운영 정도 | 자가노동 의존도 판단 |
| PREFERENCE | 위험 선호도 | 안정형/중립/공격형 |
| PREFERENCE | 오프라인 운영 선호 | 업종 필터링 |
| CONSTRAINT | 절대 하기 싫은 것 | 후보 업종 제거 |
반드시 분리할 값
총자산/투입 가능 예산과 최대 손실 가능액은 다르다.
예:
가용자금: 50,000,000원
사업에 넣을 수 있는 최대금액: 40,000,000원
실제로 감수 가능한 손실액: 15,000,000원
AI는 4,000만 원을 넣을 수 있다는 이유만으로 4,000만 원을 모두 소진하는 사업을 추천하면 안 된다.
성향 질문 예시
- 월 300만 원의 안정적인 사업 vs 월 1,000만 원 가능하지만 실패 확률이 높은 사업
- 검증된 시장에서 경쟁 vs 아직 작은 새로운 시장 선점
- 내가 직접 일해서 수익 vs 사람/시스템을 활용해 운영
‘절대 하기 싫은 것’ 예시
- 직원을 많이 쓰는 사업
- 음식점
- 야간근무
- 전화/영업
- 재고를 많이 쌓는 사업
- 큰 대출
- 주말근무
- 규제가 많은 업종
Founder Profile 예시
founder_profile:
location: "수원"
capital: 50000000
max_loss: 15000000
available_time: "full_time"
target_income_monthly: 5000000
launch_horizon: "6_months"
skills:
- software_engineering
- ai
preferences:
operational_involvement: low
risk_tolerance: medium
innovation_preference: medium_high
avoid:
- large_staff
- night_work
- heavy_debt
이 객체가 이후 모든 Agent가 공유하는 최초 State가 된다.
5. 제품의 핵심 Flow
flowchart TD
A[Founder Onboarding] --> B[Founder Constraint Profile]
B --> C[업종 후보 Screening]
C --> D[시장/경쟁 조사]
D --> E[지역/상권 분석]
E --> F[재무 모델링]
F --> G[Risk / Critic 검증]
G --> H{Go / Kill / Pivot}
H -->|Kill| C
H -->|Pivot| D
H -->|Go| I[매물/점포 탐색]
I --> J[견적/인허가/계약]
J --> K[Opening Project]
K --> L[오픈]
시스템이 해야 하는 질문
단순히 “이 사업 괜찮습니다”가 아니라 아래처럼 가장 위험한 가정을 찾아내야 한다.
현재 가장 위험한 가정은 ‘해당 상권에서 평일 일평균 고객 70명을 확보할 수 있다’는 것이다.
주변 동종업종, 유동/주거인구, 임대료를 추가 조사한 뒤 Go/No-Go를 판단해야 한다.
즉 제품의 핵심은 답변 생성이 아니라 불확실성을 줄이는 의사결정 루프다.
6. Multi-Agent Architecture
Agent를 업종별로 만들지 않는다.
잘못된 예:
CafeAgent
RestaurantAgent
PCBangAgent
LaundryAgent
...
대신 사고 역할을 기준으로 범용 Agent를 구성하고, 도메인별 데이터/규칙/계산식은 Domain Pack으로 분리한다.
Core Agent
| Agent | 역할 | 핵심 질문 |
|---|---|---|
| Orchestrator | 전체 진행/의사결정 | 지금 무엇을 확인해야 하는가? |
| Business Discovery | 업종 후보 생성/필터링 | 이 Founder에게 어떤 업종이 현실적인가? |
| Research | 시장/경쟁/가격/사례 조사 | 실제 근거는 무엇인가? |
| Location | 지역/상권/경쟁점/입지 분석 | 어디에서 해야 하는가? |
| Finance | 초기비용/손익/BEP/ROI | 돈이 남는 구조인가? |
| Critic / Risk | 반론/실패요인/민감도 | 왜 망할 수 있는가? |
| Launch / Execution | 실제 준비 Task 관리 | 이제 무엇을 실행해야 하는가? |
권장 구조: Supervisor Pattern
Agent끼리 자유 토론시키지 않고 Orchestrator가 작업을 배분한다.
flowchart TD
U[Founder] --> O[Orchestrator]
O --> B[Business Discovery]
O --> R[Research]
O --> L[Location]
O --> F[Finance]
O --> C[Critic]
O --> X[Launch]
B --> V[(Venture State)]
R --> V
L --> V
F --> V
C --> V
X --> V
V --> O
왜 자유 토론형 Multi-Agent가 아닌가
- 토큰 낭비
- 상태 불일치
- 근거 없는 합의
- 어떤 Agent가 최종 책임자인지 모호
- 실행 순서 통제 어려움
따라서 Agent ↔ Agent 대화보다는 Agent → Shared State ← Agent 구조를 중심으로 한다.
7. Venture State: 서비스의 핵심 자산
멀티에이전트의 핵심은 Agent 숫자가 아니라 **하나의 지속적인 창업 상태(Venture State)**다.
venture:
founder_profile: {}
goal: {}
constraints: {}
hypotheses:
- id: H-001
statement: "해당 상권에서 일평균 70명의 고객을 확보할 수 있다"
confidence: 0.55
status: testing
evidence:
- claim: "반경 500m 내 동종 경쟁점이 7개다"
source: "..."
confidence: 0.9
business_model:
customer: {}
value_proposition: {}
revenue_model: {}
cost_structure: {}
location_candidates: []
financial_models: []
risks: []
decisions: []
experiments: []
tasks: []
metrics: []
learnings: []
Memory 구분
- Founder Memory: 사용자의 자본, 경력, 시간, 성향, 제약
- Venture Memory: 현재 사업의 가설, 후보 업종, 지역, 재무, 결정, 실험
- General Learning: 여러 창업 사례에서 반복적으로 얻은 패턴
이 세 가지를 섞지 않는다.
8. Evidence 중심 설계
Research Agent는 글을 잘 쓰는 역할보다 근거를 수집하고 구조화하는 역할이 중요하다.
예시:
{
"claim": "A 지역에서 카페 경쟁밀도가 높은 편이다",
"evidence": ["..."],
"confidence": 0.82,
"source": ["..."],
"updated_at": "2026-08-20"
}
모든 주요 추천에는 다음이 남아야 한다.
- Claim
- Evidence
- Source
- Confidence
- Updated At
- 어떤 Decision에 사용됐는지
그래야 “LLM이 그렇게 말해서”가 아니라 어떤 데이터로 어떤 결정을 했는지 추적할 수 있다.
9. 업종별 Domain Pack
Core Agent는 유지하고 업종별 계산 지표와 규칙만 교체한다.
Cafe Pack
- 객단가
- 회전율
- 테이크아웃 비율
- 원가율
- 좌석 수
- 일평균 주문 수
PC방 Pack
- PC 대수
- 시간당 이용료
- 가동률
- 시간대별 이용률
- F&B 매출
- 전기료
노래방 Pack
- 룸 수
- 룸당 회전
- 시간당 가격
- 야간 매출 비중
편의점 Pack
- 일매출
- 상품 마진
- 폐기율
- 본사 수수료
- 점주 근무시간
공통 Core는 다음과 같다.
상권 + 임대료 + 보증금 + 권리금 + 초기투자
+ 객단가 + 고객수 + 원가 + 인건비 + 운영비
→ 매출 / 영업이익 / BEP / ROI / Runway
10. Financial Agent 원칙
LLM이 숫자를 직접 암산하게 하지 않는다. LLM은 모델을 구성하고 실제 계산은 Calculator / Python / Spreadsheet / Code Tool이 수행한다.
기본 계산 구조:
월매출 = 일평균 고객수 × 객단가 × 영업일
영업이익 = 매출
- 원가
- 임대료
- 인건비
- 공과금
- 수수료
- 기타비용
단일 예상치가 아니라 반드시 다음 시나리오를 비교한다.
- Bear Case
- Base Case
- Bull Case
그리고 다음 지표를 생성한다.
- 초기 투자비
- 월 고정비/변동비
- BEP
- 예상 월 영업이익
- 투자금 회수기간
- Runway
- 민감도 분석
11. 경쟁사 조사 정리
해외
Foundora
- AI CEO / CTO / CMO / CFO / Investor 형태의 AI Co-Founder Team
- 아이디어 검증, 시장/전략, MVP, 재무, 마케팅, 투자자 피치 등을 지원
- Agent 간 Shared Context/Memory를 강조
- 테크 스타트업 중심이고 CTO/Investor 비중이 큼
- 점포형 자영업의 상권, 임대료, 권리금, 인허가, 오픈 실행과는 거리가 있음
시사점: 멀티에이전트 자체는 차별점이 아니다. 데이터와 workflow가 차별점이어야 한다.
StorIQ
- 이름 때문에 처음에는 유사 서비스로 보였으나 실제로는 Self-storage 사업자를 위한 마케팅 AI Agent
- Google Business Profile, Google Ads, 전화/전환, SEO 등 이미 운영 중인 사업의 마케팅 자동화에 초점
- 창업 설계 서비스와는 직접 경쟁이 아님
시사점: Tool을 통해 실제 외부 시스템을 수정하고 결과를 다시 학습하는 Closed-loop Agent 구조는 참고할 가치가 높다.
Launch30
- Physical business를 30일 안에 오픈하도록 돕는 workflow
- Foundation → Legal → Brand → Location → Buildout → Launch
- 매일 Task + 해당 Task용 AI Assistant
- 점포형 자영업 사용자 여정은 우리와 매우 가까움
- 다만 공개된 구조는 AI가 붙은 창업 Playbook / Checklist에 가까움
- Founder 조건에서 업종을 탐색하고 여러 실데이터를 합쳐 Go/Kill/Pivot을 수행하는 구조는 확인되지 않음
시사점: 오픈 이후 단계의 30-day task-driven UX는 강하게 벤치마킹할 가치가 있다.
ZeroToOpen 관련 정정
이전 검색 과정에서 ZeroToOpen을 실제 독립 서비스처럼 언급했으나, 이후 exact-match 재확인에서는 공식 제품을 검증하지 못했다. 경쟁사 목록에는 확정 서비스로 포함하지 않는다.
12. 국내 서비스 조사 정리
위아오너
실제 AI 기능은 생각보다 제한적이다.
- AI 추천견적: 견적 DB 기반 업종/평수별 필요 수량 및 평균 비용 추천
- AI 일정비서: 계약서 등에서 일정/계약기간 정리
- 상권분석, 인테리어, 장비, 세무/노무 등은 외부 시스템·창업 플래너·제휴업체 중심
즉 **“뭘 열지 정한 사용자에게 얼마 드는지와 업체를 연결”**하는 구조에 더 가깝다.
창업인
- 예산/선호업종/관심지역 기반 프랜차이즈 매칭
- 상권분석, ROI Simulation, 견적, 본사 미팅, 계약, 오픈
- Founder onboarding 측면에서 일부 유사
- 하지만 프랜차이즈 중심
마이프차
- 프랜차이즈 정보/비교/상권/양도양수/전문가 동행
- 프랜차이즈 데이터와 실제 컨설팅이 강함
- 개인 브랜드 창업 전체를 다루는 서비스와는 차이가 있음
SANAI
- 소상공인/예비창업자 대상 AI 기반 상권/마케팅/문서 도구
- 주소/업종 기반 AI 상권분석
- 공공데이터 기반 입지/경쟁/인구/수익 시뮬레이션
- 현재 포지션은 AI 자영업 도구 모음에 가까움
핀다 오픈업
- 상권/매출/매장/인구/결제 패턴 등 Location Intelligence에 강함
- 창업 workflow보다 데이터 분석 레이어
- 경쟁자이면서 동시에 우리 서비스가 직접 구축하기 어려운 데이터 영역의 참고/잠재 인프라 후보
소상공인365
- 전국 단위 상권, 매출, 유동인구, 정책정보 등 공공 기반 서비스
- 무료 baseline으로 중요
서울시 상권분석서비스
- 지역별 유망업종, 점포 증감, 매출, 생존율, 폐업 등 제공
- 업종 미정 사용자에게 상위 업종 추천 가능
- 서울 지역에서는 매우 강한 무료 baseline
싸장님들
- 점포/사업 양도양수 및 매물 중심
- 신규창업 vs 기존점포 인수 의사결정에서 참고 가능
NICEbizmap
- 업종별 평균매출, 고객특성, 임대시세 등 상권 데이터 도구
- 직접 경쟁보다는 데이터 레이어 참고 대상
13. 현재 시장에서 보이는 빈자리
국내에는 이미 다음 기능이 각각 존재한다.
상권 데이터 → 오픈업 / 소상공인365 / 서울시 / NICE
프랜차이즈 탐색 → 마이프차 / 창업인
견적/업체 연결 → 위아오너
AI 분석 도구 → SANAI
매물/양도양수 → 싸장님들
문제는 사용자가 이들을 직접 돌아다니며 정보를 합쳐야 한다는 점이다.
소상공인365
→ 오픈업
→ 지도/경쟁점 검색
→ 부동산 매물
→ 프랜차이즈 정보
→ 엑셀 재무계산
→ 정부/지자체 인허가
→ 견적업체
→ 일정/할 일 관리
우리의 제품 기회는 새로운 데이터를 하나 더 보여주는 것이 아니라, 이 조각들을 AI가 대신 연결해 하나의 의사결정과 실행 과정으로 만드는 것이다.
14. 우리의 핵심 차별점
1. Founder-first Onboarding
업종부터 묻지 않고 사용자의 지역, 자본, 손실한도, 시간, 목표소득, 경험, 운영성향, 금지조건부터 구조화한다.
2. 업종 추천이 아니라 Business Screening
“카페가 좋다”가 아니라 여러 업종을 같은 기준으로 비교한다.
- 초기자본 적합도
- 지역 수요
- 경쟁 강도
- 예상 수익성
- 노동집약도
- 위험
- 회수기간
- Founder fit
3. 여러 데이터의 통합 판단
상권, 경쟁점, 임대료, 예상매출, 인허가, 창업비, 지원사업 등 흩어진 정보를 한 Venture State에 통합한다.
4. Critic / Go-Kill-Pivot
LLM의 낙관적 추천 문제를 피하기 위해 별도의 Critic Agent가 가설을 공격한다.
Go → 다음 검증/실행 단계
Kill → 후보 제거
Pivot → 업종/지역/규모 조정 후 재검증
5. 보고서가 아니라 지속형 창업 프로젝트
한 번의 분석 리포트로 끝나는 것이 아니라 사용자와 사업 상태를 유지한다.
후보 선정
→ 심층조사
→ 지역 선정
→ 매물
→ 견적
→ 인허가
→ 계약
→ 공사/장비
→ 오픈
6. Agentic Execution
장기적으로는 단순 “어떻게 하세요”가 아니라 실제 Tool을 연결한다.
- Web Research
- 지도/POI/상권 데이터
- 매물 검색
- 이메일/견적 요청
- Calendar
- Task Manager
- 문서 생성
- 인허가/정부 정보 조회
- 재무 Spreadsheet/Calculator
경쟁사 대비 한 줄
오픈업은 상권 데이터를 보여주고, 마이프차/창업인은 프랜차이즈를 연결하며, 위아오너는 견적과 업체를 연결한다. 우리는 사용자의 조건에서 출발해 ‘무슨 장사를 어디서 해야 하는지’를 조사·검증하고 오픈까지 프로젝트를 지속 관리한다.
15. MVP 제안
처음부터 Agent 7~10개를 모두 독립 Agent로 만들지 않는다.
MVP Agent 4개
-
Orchestrator
- Founder Profile 관리
- 다음에 줄여야 할 불확실성 선택
- 다른 Agent 호출
- 최종 Decision 생성
-
Research Agent
- 시장/업종/경쟁/가격/지원사업 조사
- Evidence Store 업데이트
-
Finance + Critic Agent
- 창업비/수익/BEP/ROI 모델링
- Bear/Base/Bull
- 실패요인과 민감도 분석
-
Execution Agent
- 결정된 사업을 실제 Opening Task로 분해
- 체크리스트/일정/Venture State 진행
MVP에서 우선 지원할 업종
5~8개 정도만 깊게 지원한다.
- 카페
- 일반음식점
- 편의점
- PC방
- 노래방
- 스터디카페
- 의류소매
- 무인빨래방
MVP에서 가장 중요한 것
Agent 수가 아니라 아래 네 가지가 먼저다.
- Founder Profile Schema
- Venture State Schema
- Evidence / Hypothesis 구조
- Decision → Execution Loop
16. 제품 UX 방향
첫 화면 카피 후보
내 돈과 지역에 맞는 가게를 찾아보세요.
온보딩 완료 후:
가용자금: 5,000만원
지역: 수원
목표소득: 월 500만원
직접운영: 가능
야간영업: 비선호
리스크: 중간
조건에 맞는 점포형 사업을 분석합니다.
결과 예시:
1위 무인빨래방 적합도 82
2위 소형 카페 적합도 74
3위 애견용품점 적합도 69
→ 각 후보에 대해 시장/상권/재무/리스크 심층 분석
최종적으로는 추천 점수보다 왜 이 후보가 남았고 어떤 근거로 탈락했는지가 보여야 한다.
17. 네이밍 논의
초기 후보:
- StoreMate: 직관적이지만 국내외 동일/유사 서비스가 많고 영문 검색 독점성이 낮아 탈락
- MERAVO: 검색 중복은 낮았지만 의미가 즉시 전달되지 않는 조어라 보류
- ReadySetOpen:
Ready → Set → Open으로 창업 준비부터 오픈까지의 의미가 직관적 - GoodToOpen: Go/No-Go 판단 느낌
- ReadyOpenGo / SetToOpen: 의미는 명확하나 브랜드성이 상대적으로 약함
네이밍 원칙:
- 한글 설명형 이름은 지양
Store + 단어,Founder + 단어,Launch + 단어는 선점률이 높아 주의- 5~10자 내외
- 한국어로 발음하기 쉬움
.ai와 함께 사용해도 어색하지 않음- 현재 점포형 자영업에서 시작하더라도 향후 SMB 영역으로 확장 가능한 이름
- 뜻 설명을 길게 하지 않아도 제품 이미지가 어느 정도 떠오르는 이름 선호
현재 네이밍은 미확정 상태이며, 상표(KIPRIS)·도메인·앱스토어까지 확인한 뒤 결정해야 한다.
18. 제품을 한 문장으로 설명하는 후보
제품 정의형
사용자의 조건을 이해하고, 현실적으로 가능한 점포형 사업을 조사·검증한 뒤 실제 오픈까지 함께 진행하는 AI Co-Founder.
소비자 카피형
무슨 가게를, 어디에, 얼마로 열어야 하는지 AI가 대신 조사하고 결정해주는 서비스.
차별점 강조형
정보를 보여주는 창업 플랫폼이 아니라, 사용자의 조건을 이해하고 창업 의사결정부터 오픈까지 계속 밀어주는 AI Co-Founder.
19. 다음 기획 과제
P0 — 바로 정의해야 할 것
- ☐ Founder Profile JSON Schema 확정
- ☐ 온보딩 질문 수 및 UI 확정
- ☐ Venture State Schema 확정
- ☐ Candidate Business Scoring 기준 설계
- ☐ Evidence/Source/Confidence 스키마 정의
- ☐ Go / Kill / Pivot Decision 규칙 정의
- ☐ MVP 지원 업종 5~8개 확정
P1 — Agent 설계
- ☐ Orchestrator System Prompt
- ☐ Research Agent Prompt + Tool 목록
- ☐ Finance/Critic Prompt + 계산 Tool
- ☐ Execution Agent Prompt
- ☐ Agent 권한 및 Human Approval 규칙
- ☐ Shared State 동시성/수정 규칙
P1 — 데이터
- ☐ 소상공인365 활용 가능 데이터 조사
- ☐ 서울시 상권분석 데이터 조사
- ☐ 공공데이터포털 상가/상권 데이터 조사
- ☐ 지도/POI 데이터 후보 조사
- ☐ 상업용 부동산/임대료 데이터 후보 조사
- ☐ 업종별 인허가 데이터 구조화
P2 — 제품
- ☐ 온보딩 Prototype
- ☐ 업종 Screening UI
- ☐ 후보별 Evidence 화면
- ☐ Financial Scenario 화면
- ☐ Critic/Risk 화면
- ☐ Opening Project / Checklist UI
- ☐ 경쟁사 대비 Landing Page 카피
- ☐ 서비스명 확정
20. 현재 핵심 결론
이 서비스에서 Multi-Agent라는 구현 방식 자체는 제품의 차별점이 아니다. Foundora처럼 역할 기반 Agent를 제공하는 서비스는 이미 존재한다.
진짜 차별점은 다음 네 가지다.
- Founder Constraint Profile — 사용자 조건에서 출발한다.
- Venture State + Evidence — 창업 프로젝트의 판단 근거와 상태를 지속적으로 관리한다.
- Go / Kill / Pivot Decision Loop — 추천이 아니라 실제 의사결정을 수행한다.
- Decision → Opening Execution — 분석에서 끝나지 않고 개업 Task까지 연결한다.
즉 최종 제품은 단순 창업 챗봇이나 상권 분석기가 아니라 점포형 자영업 창업을 위한 지속형 AI 의사결정·실행 시스템을 목표로 한다.