[Release] #532 #533 #545 v0.1.67 운영 배포 기록

- v0.1.66 이후 미배포 15커밋을 www.tasteby.net 에 반영
- Colima(aarch64) 빌드 → OCIR push → kubectl set image → rollout 완료
- 운영 검증: min_mentions=0/3/5 → 500/36/5곳 (서버사이드 필터 정상)
- Redmine #532/#533/#545 → 08-Documenter 전진

Refs #532, #533, #545

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -4,6 +4,23 @@
 
 ---
 
+## 2026-09-15
+
+### 🚀 [Release] v0.1.67 운영 배포 — #532 / #533 / #545
+- 대상: 2026-07-27 이후 main에 누적된 15개 커밋 (v0.1.66 이후 미배포분)
+  - #532 지역 표시 계층화(`한국|서울` → `한국 › 서울`), #533 언급 적은 식당 제외 필터(min_mentions), #545 해외 식당 예약버튼 숨김
+- 절차: Colima(aarch64) 빌드 → OCIR push(`icn.ocir.io/idyhsdamac8c/tasteby/{backend,frontend}:v0.1.67`) → `kubectl set image` → rollout 완료
+- 운영 검증: `min_mentions=0` → 500곳, `=3` → 36곳, `=5` → 5곳 — 서버사이드 필터 정상 동작
+- git tag `v0.1.67` 생성 및 Gitea push. Redmine #532/#533/#545 → 08-Documenter 전진
+
+### 📄 [Docs] 모두의 창업 2차 지원서 작업방 신설 — `docs/ir/modu-startup-2026-09/`
+- `questions.md`(문항 원문·제약), `v1.md`(1차 지원서 원고 보존), `v2.md`(Codex 작성분 이관), `v3.md`(실측 반영), `v4.md`(Q8 완성)
+- 실측 지표 확보: 채널 6곳 / 영상 909편 / 노출 식당 500곳(좌표 100%) / 해외 60여 곳(일본 28) / LLM 미검증 1,071건
+- v3에서 로드맵 수정: "3개월 내 식당 5,000곳"(현재의 10배, 달성 불가) → 1,500곳 + 미검증 1,071건 정리를 0~3개월 과제로 재정의
+- Redmine #791 연계
+
+---
+
 ## 2026-07-27
 
 ### ✅ [Reviewer] #533 언급 적은 식당 제외 필터 — 승인 (게이트 통과)

docs/ir/modu-startup-2026-09/README.md

@@ -0,0 +1,90 @@
+# 모두의 창업 2차 — Tasteby 지원서 작업방
+
+- **지원 아이템**: Tasteby — 신뢰하는 유튜버/유명인의 맛집을 AI가 자동 정리해 한 지도에 모아주는 디스커버리 플랫폼
+- **구분**: 2차 지원(재도전) — Q8 재도전 가점 항목 존재
+- **서비스**: https://www.tasteby.net (MVP 운영 중)
+
+## 파일 구성
+
+| 파일 | 역할 |
+|------|------|
+| `questions.md` | 지원서 문항 원문·제약 (고정, 수정하지 않음) |
+| `v1.md` | 최초 스냅샷 (보유 원고를 문항에 매핑) |
+| `v2.md` | Codex(gpt-5.6) 작성분을 이관 |
+| `v3.md` | v2에 실측 지표 반영 |
+| `v4.md` | **현재 제출안**. Q8 완성 |
+
+## 버저닝 규칙
+
+1. 수정할 때 이전 버전을 고치지 않는다. `cp v1.md v2.md` 후 v2를 고친다.
+2. 각 버전 머리말에 **무엇을 왜 바꿨는지** 한 줄씩 남긴다.
+3. 최종 제출 시 `FINAL.md` 로 복사하고, 실제 폼에 붙여넣은 시각을 기록한다.
+
+## 버전 이력
+
+| 버전 | 날짜 | 요약 |
+|------|------|------|
+| v1 | 2026-09-15 | 보유 원고를 12개 문항에 매핑한 최초 스냅샷. Q1/Q2는 폼 입력 원문 보존 |
+| v2 | 2026-09-15 | Codex 작성. 전 문항 작성 완료. "출처 기반 발견 → 비공개 기록 → 선택적 공유"로 논리 재편. Redmine #791 |
+| v4 | 2026-09-15 | Q8 완성 — 1차 원문이 `v1.md`임을 확인하고 1차의 약점 4가지와 2차 수정을 1:1 대응 |
+| v3 | 2026-09-15 | 실측 반영. Q4-1의 "3개월 5,000곳"(10배, 달성 불가) → 현재 500곳 기준 배수 목표로 교체. 미검증 1,071건 정리를 0~3개월 과제로. 해외 60여 곳을 Q3-1/Q4-1 근거로. 깨진 링크 3개 제거 |
+
+## 현재 진척 (v2 기준, 글자수 실측)
+
+| 문항 | 글자수 | 제한 | 상태 |
+|------|--------|------|------|
+| Q1 한 줄 소개 | 54 | 100 | 🟡 v1(62자)과 문구 다름 — 택1 필요 |
+| Q2 배경 이야기 | 996 | 2,000 | 🟡 폼에 든 v1 원문과 다름 — 교체 여부 결정 |
+| Q3-1 차별점 | 1,286 | 2,000 | ✅ v3에서 해외 데이터 근거 추가 |
+| Q3-2 수익 창출 | 1,050 | 2,000 | ✅ 원칙·구조 有 / 숫자 無 |
+| Q4-1 사업화 계획 | 1,302 | 2,000 | ✅ v3에서 실측 기반 재작성 |
+| Q4-2 멘토 도움 | 846 | 2,000 | ✅ 질문에 맞게 재작성됨 |
+| Q5 소개 영상 | 구성안 | - | ⬜ 촬영·편집 필요 |
+| Q6 사업 분야 | 선택 기준 | - | ⬜ 드롭다운 실물 확인 |
+| Q7 창업 여부 | 판단표 | - | ⬜ 법적 사실 확인 |
+| Q8 1차 대비 개선점 | 1,118 | - | ✅ v4에서 완성 |
+| Q9 본인 역량 | 916 | 2,000 | 🟡 경력·배경 한 단락 추가 여지 |
+| Q10 팀원 수 | - | - | ✅ 팀원 없음 |
+| Q11 자랑하기 | 183 | - | ✅ 문구 有 / 스크린샷 필요 |
+| Q12 서약 동의 | - | - | ⬜ 제출 직전 |
+
+## v2 검증 결과 (2026-09-15)
+
+**사실로 확인된 것**
+- 찜·공개 리뷰·비공개 메모 기능 실존: `MemoController`/`MemoService`(사용자별, 공개 엔드포인트 없음), `ReviewController`, 프론트 `RestaurantDetail.tsx`
+- MVP 운영 중: PM2 `tasteby-api`/`tasteby-web` 가동, www.tasteby.net
+
+**확인되지 않은 것**
+- v2 머리말의 참조 문서 3개(`docs/design/705-tasteby-bm-v1-1/`, `docs/strategy/tasteby-personalization-…`, `docs/design/711-tasteby-marketing-v1-5/`)가 **리포에 없음**
+- Codex가 보고한 산출 경로 `docs/applications/moduui-changup-round2/`, 워크트리 `~/claude-workspace/business-model`, 커밋 `f50bbab` 모두 이 머신에 **없음** (Redmine #791은 실존)
+- 로드맵 수치(식당 5,000곳/채널 10곳/MAU 5만)의 출발점이 될 현재 실측치 미확인
+
+## 남은 과제 (우선순위)
+
+1. **Q1·Q2 택1** — 폼에는 v1 문구가 이미 들어가 있음. v3 문구로 교체할지 결정.
+2. **Q3-2에 숫자** — 원칙은 섰으나 단가·매출 추정이 없어 "언제 돈을 버는가"가 불명확.
+3. **Q4-1 획득 경로** — "검색·커뮤니티·콘텐츠"가 아직 범주 수준. 다만 v3에서 공개 모집 전 단계임을 명시해 과장은 제거됨.
+4. **Q5 영상** — 구성안만 있고 미제작.
+5. **사진 8장 확보** — 도식 3장 제작 필요.
+6. **Q9 경력 보강**
+7. **미배포 15커밋** — Q8이 언급한 개선(#532/#533/#545)이 main에만 있고 운영 미반영. 제출 전 배포 필요 — 공개 가능한 경력·수상이 있으면 한 단락.
+
+## 실측 지표 (2026-09-15 확인)
+
+| 항목 | 현재 | 확인 방법 |
+|------|------|-----------|
+| 등록 채널 | **6개** | Admin 채널 관리 |
+| 수집 영상 | **909편** | 채널별 합계 (성시경52·김사원세끼270·더들리188·떡볶퀸92·비밀이야196·버거코치111) |
+| 노출 식당 | **500곳** | `GET /api/restaurants?limit=100000` |
+| 좌표 보유 | 500/500 (100%) | 동 API |
+| 해외 식당 | 일본 28 · 미국 9 · 싱가포르 8 · 이탈리아 4 · 홍콩 3 (국내 417) | region 집계 |
+| 2회 이상 언급 | 63곳 (3회 이상 21곳) | `video_count` 집계 |
+| LLM 미검증 | 1,071건 | Admin 식당 관리 |
+| 가입자 수 | **공개 모집 전** | 지원서에 수치로 쓰지 않고, "제품·데이터 우선 확보 단계"로 서술 |
+
+**로드맵 대비 위치**: 채널 6→10(1.7배). 식당 500→5,000은 10배로, 채널당 평균 83곳 기준 채널 60개 수준의 커버리지를 요구해 3개월 내 달성 불가 → **v3에서 1,500곳으로 조정하고 0~3개월 과제를 미검증 1,071건 정리로 재정의함**.
+
+## 참고 자산
+
+- `docs/ir/bunkershot-2026-06-29/` — 6월 벙커샷 IR 자료 (피치덱, 1pager, 예상 QA, 시연 시나리오). Q5 영상 대본·Q3 소재로 재활용 가능
+- `screenshots/` — 서비스 스크린샷 (사진 첨부용, 전체 합산 10장 제한)

docs/ir/modu-startup-2026-09/questions.md

@@ -0,0 +1,26 @@
+# 모두의 창업 2차 — 지원서 문항 원문
+
+> 출처: 지원서 작성 화면 캡처 (2026-09-15 확인)
+> 이 파일은 **문항 원문 보존용**이다. 답변은 `vN.md` 에 쓴다.
+
+| 문항 | 필수 | 글자수 | 비고 |
+|------|------|--------|------|
+| Q1. 나의 아이디어를 한 줄로 소개해주세요. | 필수 | 10~100자 | |
+| Q2. 아이디어를 떠올린 배경 이야기를 들려주세요. | 필수 | 2,000자 | 사진 첨부 가능 |
+| Q3-1. 기존 제품 및 서비스 대비 차별점과 어떤 문제를 해결할 수 있나요? | 필수 | 2,000자 | 사진 첨부 가능 |
+| Q3-2. 어떻게 수익을 창출할 계획인가요? | 선택 | 2,000자 | 사진 첨부 가능 |
+| Q4-1. 아이디어를 어떻게 사업화 하실 계획이신가요? | 필수 | 2,000자 | 사진 첨부 가능 |
+| Q4-2. 책임멘토를 통해 어떤 도움을 받고 싶은가요? | 선택 | 2,000자 | 사진 첨부 가능 |
+| Q5. 나의 아이디어를 소개하는 영상을 링크로 제출해주세요. | 선택 | URL | **유튜브 링크만** |
+| Q6. 사업 분야를 선택해주세요. | 필수 | 드롭다운 | |
+| Q7. 지원자의 현재 창업 여부를 알려주세요. | 필수 | 택1 | 예비창업자 / 기창업자 |
+| Q8. 2차 지원서에서는 1차 지원서보다 어떤 점이 더 개선되었나요? | 선택 | - | **재도전 가점 반영** |
+| Q9. 아이디어를 사업화 시킬 수 있는 본인의 역량을 알려주세요. | 선택 | 2,000자 | |
+| Q10. 함께하는 팀원이 있다면 본인을 제외한 팀원 명수를 알려주세요. | 선택 | 드롭다운 | 기본값 "팀원 없음" |
+| Q11. 내 아이디어를 사람들에게 자랑해보세요. | 선택 | - | **홈페이지 공개 + 좋아요** |
+| Q12. 서약서 동의 | 필수 | 체크 | 참여/본인아이디어/비밀유지 |
+
+## 운영 제약
+- **사진은 전체 문항 합산 최대 10장.** 문항별이 아니라 총량 제한이므로 배분 계획 필요.
+- Q7 기창업자 기준: 창업일이 **2019.08.21.~2026.08.20.** 범위이고, 기존 사업과 **다른 아이템(이종창업)** 희망자.
+- Q8/Q11은 선택이지만 각각 **가점**과 **공개 노출** 효과가 있어 실질적으로 작성 권장.

docs/ir/modu-startup-2026-09/v1.md

@@ -0,0 +1,163 @@
+# 모두의 창업 2차 지원서 — v1 (초안 스냅샷)
+
+- **작성일**: 2026-09-15
+- **상태**: 보유 원고를 문항에 매핑한 최초 스냅샷. 문장 다듬기·수치 검증은 v2에서.
+- **원칙**: Q1/Q2는 **이미 폼에 입력된 원문 그대로** 보존(오타 포함). 손대지 않는다.
+
+---
+
+## Q1. 나의 아이디어를 한 줄로 소개해주세요. (필수 / 100자)
+
+내가 신뢰하는 유튜버/유명인의 맛집을, AI가 영상/글에서 자동으로 정리해 한 지도에 모아주는 디스커버리 플랫폼
+
+> [현황] 폼 입력 완료 (63자). 원문 유지.
+
+---
+
+## Q2. 아이디어를 떠올린 배경 이야기를 들려주세요. (필수 / 2,000자)
+
+평소 유튜브로 맛집 영상을 자주 보는 한 사람으로서, 한 가지 반복되는 답답함이 있었습니다. "성시경 채널에서 본 그 가게, 어디였더라?" 영상을 다시 뒤져 자막에서 가게 이름을 받아 적고, 지도에 옮겨야 합니다. 좋아하는 채널 5개만 구독해도 한 달치 영상이 수십 개. 그중 정작 가고 싶은 가게를 다시 꺼내는 일은 사실 불편하고 번거로웠습니다.
+
+기존 맛집 서비스를 써봐도 갈증은 풀리지 않았습니다. 익명 다수의 별점에 의존하는 서비스는 가짜 리뷰 논란이 끊이지 않고, 광고성 콘텐츠가 상위에 노출됩니다. 정작 제가 신뢰하는 사람, 음식을 진심으로 다루는 유튜버의 추천은 그 어디에도 정리되어 있지 않았습니다. 이 문제는 해외여행 때 더 극심해졌습니다. 일본 여행을 준비하며 성시경의 일본 맛집 시리즈를 다 보고 갔지만, 정작 도쿄 거리에서 그 가게를 찾는 데 오랜 시간이 걸렸습니다. 영상 속 정보가 활용에는 그 식당을 언급하는 장면을 다시 돌려본다던가 하는 불편함이 있어 쉽지 않았습니다. 그래서 이런생각을 했습니다. "신뢰하는 사람의 선택을 한 지도에 모아주는 서비스." 그러나 손으로 정리하는 건 불가능합니다. 영상 한 편에서 식당 정보를 추출하는 데 사람이 30분씩 걸리는데, 한 채널만 해도 영상이 수백 개입니다.
+
+LLM(거대언어모델)의 발전이 이 문제를 해결해 주었습니다. 영상 자막을 LLM에 넣으면 식당 정보를 구조화해 추출할 수 있고, 추출한 주소를 지오코딩해 지도에 꽂으면 됩니다. 더 이상 사람이 손으로 정리할 필요가 없습니다. 이 깨달음이 Tasteby의 출발점입니다. 기술이 가능하게 만든 "신뢰 기반 큐레이션" 알고리즘이 아닌 사람의 신뢰를, 기계가 자동으로 정리해 모두에게 열어주는 플랫폼입니다.
+
+> [현황] 폼 입력 완료 (854자). 원문 유지.
+> [v2 검토 예정] 마지막 문단 두 문장(“영상 속 정보가 활용에는…”, “기술이 가능하게 만든 …열어주는 플랫폼입니다.”)이 비문. 2,000자 중 854자만 사용 — 여유 1,100자.
+
+---
+
+## Q3-1. 기존 제품 및 서비스 대비 차별점과 어떤 문제를 해결할 수 있나요? (필수 / 2,000자)
+
+**1차 타겟: 외식·맛집에 진심인 한국인**
+20~40대 약 1,500만 명. 유튜브 맛집 콘텐츠를 일상적으로 소비하지만, 영상 속 정보가 분산되어 있어 정작 가고 싶을 때 활용하지 못합니다. "그 곱창집이 어디였지?", "이 셰프가 추천한 동네 중식당이 어디였더라?" 매번 영상을 거꾸로 돌려 찾아야 합니다.
+
+**2차 타겟: 해외여행을 자주 가는 한국인**
+연 700만 명 이상의 일본 여행객을 비롯해, 좋아하는 한국 유튜버의 해외 콘텐츠를 신뢰하는 사람들. 익명의 외국 리뷰 사이트보다 자신이 신뢰하는 한국 유튜버의 추천을 따르고 싶지만, 현지에서 그 정보를 활용할 도구가 없습니다.
+
+**3차 타겟: 콘텐츠를 만드는 유튜버**
+음식 콘텐츠 크리에이터는 자신이 다녀온 가게가 영상 한 편으로 소비되고 끝납니다. 새로운 시청자가 그 가게를 나중에 검색해도 영상에 도달하지 않습니다. 자신의 큐레이션이 자산화되지 않는 구조입니다.
+
+**기존 서비스가 풀지 못한 이유**
+- 망고플레이트·다이닝코드: 익명 리뷰 의존 → 신뢰 붕괴
+- 캐치테이블: 예약 중심 → 발견 기능 약함
+- 구글 지도: 별점 평균만 표시 → "누가" 추천했는지 알 수 없음
+- 유튜브 직접 검색: 정작 위치·주소 정보가 영상 속에 묻혀있음
+
+**Tasteby가 해결하는 본질**
+사용자에게는 "신뢰하는 사람의 선택"이 한 지도에 정리되어 보입니다. 가게를 클릭하면 그 유튜버가 영상에서 어떤 평가를 했는지 즉시 확인하고, 원본 영상으로 회귀할 수 있습니다.
+
+결정적 차별화는 **"분야별 전문 큐레이터" 포지셔닝**입니다. 성시경은 노포·국밥 전문, 더틀리는 호텔·파인다이닝, 떡볶퀸은 분식 전문, 버거코치는 햄버거 전문 같이 각 채널을 분야별 권위자로 포지셔닝합니다. 사용자는 "오늘은 떡볶이가 먹고 싶다 → 떡볶퀸이 검증한 가게"라는 직관적 경로를 가지고, 유튜버는 자신의 전문성을 명확한 정체성으로 자산화합니다. 잡지 에디터 모델을 디지털·자동화로 옮긴 구조이고, 이것은 국내 이용자와 해외 여행자 모두에게 동일하게 적용됩니다.
+
+**핵심 기술: LLM 자동 추출 + 벡터 시맨틱 검색**
+YouTube 자막·메타데이터 수집 → OCI GenAI(LLM)가 식당명·주소·메뉴·유튜버 평가를 구조화 추출 → Cohere Embed v4로 벡터 임베딩 후 Oracle 23ai Vector DB 저장 → 키워드가 아닌 의미 기반 유사도 검색으로 큐레이션. "혼술하기 좋은 분위기", "성시경 스타일의 노포" 같은 의미 단위 질의가 가능합니다.
+
+> [현황] 폼 미입력. 보유 원고를 배치한 상태.
+> [v2 검토 예정] 분량 초과 여부 확인 → 아래 글자수 표 참조. 타겟 3종을 앞세우는 현재 구성은 "차별점" 질문에 대한 답이 뒤에 나오므로, **차별점을 먼저 → 타겟은 압축**하는 재배치 검토.
+
+---
+
+## Q3-2. 어떻게 수익을 창출할 계획인가요? (선택 / 2,000자)
+
+**수익 모델 (3단계 점진 확장)**
+- 단기: 유튜버 큐레이터 파트너십(채널 페이지 + 수익 분배), 식당 B2B 제휴(검증된 노출/예약)
+- 장기: 글로벌 확장(일본→동남아), 외식 트렌드 데이터 인사이트 B2B
+
+> [현황] 폼 미입력. **원고 부족** — 현재 2줄. 2,000자 대비 태부족.
+> [v2 필수 보강] ① 3단계인데 단기/장기 2개만 기술됨(중기 누락). ② 단가·과금 방식·예상 매출 규모 없음. ③ "12개월에 첫 매출 발생" 로드맵과 연결 필요.
+
+---
+
+## Q4-1. 아이디어를 어떻게 사업화 하실 계획이신가요? (필수 / 2,000자)
+
+**현재 단계: MVP 운영 중**
+- 도메인: www.tasteby.net (안정 가동 중)
+- 기술 스택: Spring Boot 3.3 + Java 21, Next.js 16, Oracle 23ai 벡터 DB, Redis, Kubernetes(OKE) — 프로덕션 인프라 구축 완료
+- 구현 기능: LLM 식당 정보 추출, YouTube 자막 처리, 지오코딩, 클러스터링 지도, 회원·찜·리뷰·메모, 모바일 최적화, 자체 디자인 시스템(Saffron)
+- 풀스택 1인 개발자가 설계·구현·배포 전 과정을 완료한 검증된 실행력 보유
+
+**12개월 단계별 로드맵**
+- 3개월: 식당 DB 5,000+, 등록 유튜브 채널 10+
+- 6개월: 일본 식당 베타 출시, 유튜버 큐레이터 파트너십 3건 체결
+- 12개월: MAU 5만, B2B 식당 제휴 20건, 첫 매출 발생
+
+Tasteby의 경쟁우위는 "모든 가게의 평균"이 아닌 **"분야별 권위자의 검증된 모음"**입니다. 채널의 전체 영상을 LLM이 분석해 전문성을 자동 태깅/큐레이션합니다.
+
+> [현황] 폼 미입력. 보유 원고를 배치한 상태.
+> [v2 검토 예정] ① "MAU 5만"에 도달하는 **획득 경로(마케팅)** 가 비어 있음 — 심사에서 가장 먼저 찔릴 지점. ② 유튜버 파트너십 3건의 **접근 방법**(저작권/초상 이슈 포함) 필요. ③ 현재 실측 지표(식당 수/채널 수/가입자) 기재 시 설득력 급상승.
+
+---
+
+## Q4-2. 책임멘토를 통해 어떤 도움을 받고 싶은가요? (선택 / 2,000자)
+
+**본 사업 자금·멘토링 활용 계획**
+1. 인플루언서 파트너십 확보 — 계약·법무 비용, 채널별 큐레이션 페이지 개발
+2. LLM 처리 인프라 확장 — 영상 처리량 10배 확대
+3. 글로벌 확장 — 다국어·다지역 처리 모듈 개발 (일본 우선)
+
+> [현황] 폼 미입력. 현재 원고는 **자금 사용 계획**이지 "멘토에게 받고 싶은 도움"이 아님.
+> [v2 필수 재작성] 멘토 질문에 맞게 전환: 크리에이터 IP 계약 실무, 콘텐츠 인용 저작권 자문, B2B 식당 영업 채널, 초기 트래픽 획득 전략 등 **1인 개발자가 못 메우는 영역** 중심으로. 자금 사용 계획은 Q4-1로 이동 검토.
+
+---
+
+## Q5. 아이디어 소개 영상 (선택 / 유튜브 링크)
+
+> [미정] 제작 여부 결정 필요. 기존 `docs/ir/bunkershot-2026-06-29/04-시연-시나리오.md` 를 대본 베이스로 재활용 가능.
+
+---
+
+## Q6. 사업 분야 (필수 / 드롭다운)
+
+> [미정] 선택지 목록 확인 필요. 후보: 플랫폼/O2O, AI·데이터, 관광·여행, 푸드테크.
+
+---
+
+## Q7. 현재 창업 여부 (필수 / 택1)
+
+> [미정] 예비창업자 / 기창업자 — 본인 확인 필요.
+
+---
+
+## Q8. 2차 지원서에서는 1차 지원서보다 어떤 점이 더 개선되었나요? (선택 / 재도전 가점)
+
+> [미작성] **1차 지원서 원문이 리포에 없음.** 원문 확보 후 작성.
+> 작성 축(안): ① 1차 이후 실제 개발 진척(프로덕션 배포, 기능 추가), ② 포지셔닝 구체화("분야별 전문 큐레이터" 개념), ③ 수익모델 단계화, ④ 1차 심사 피드백 반영 내용.
+
+---
+
+## Q9. 아이디어를 사업화 시킬 수 있는 본인의 역량 (선택 / 2,000자)
+
+> [미작성] 소재: 풀스택 1인 개발자로 설계→구현→운영 배포 전 과정 완수. Spring Boot/Next.js/Oracle 23ai 벡터 DB/Kubernetes(OKE) 프로덕션 운영. LLM 파이프라인 직접 구축. 8단계 AI 페르소나 개발 파이프라인 등 **혼자서도 팀 수준 산출물을 내는 운영 체계** 보유.
+> [확인 필요] 경력·이력(직장/프로젝트), 수상·자격 등 서술 가능한 배경.
+
+---
+
+## Q10. 팀원 수 (선택)
+
+팀원 없음
+
+---
+
+## Q11. 내 아이디어를 사람들에게 자랑해보세요. (선택 / 홈페이지 공개)
+
+> [미작성] 공개 노출 + 좋아요 대상. Q1의 한 줄 + 실제 서비스 링크(www.tasteby.net) + 스크린샷 조합으로 짧고 감각적으로. 심사문서 톤이 아니라 **일반 독자 대상 톤**.
+
+---
+
+## Q12. 서약서 동의 (필수)
+
+> 제출 직전 체크: 참여 서약서 / 본인 아이디어 확인 서약서 / 비밀유지 서약서.
+
+---
+
+## 사진 배분 계획 (전체 합산 10장 제한)
+
+| 문항 | 장수(안) | 내용 |
+|------|---------|------|
+| Q2 | 1 | "영상 → 지도" 문제 상황 대비 이미지 |
+| Q3-1 | 3 | 지도 화면, 식당 상세(유튜버 평가), 채널별 큐레이션 |
+| Q4-1 | 2 | 아키텍처 다이어그램, 로드맵 |
+| Q11 | 2 | 대표 스크린샷(모바일/데스크톱) |
+| 예비 | 2 | |
+
+> [확인 필요] 스크린샷은 `screenshots/` 디렉토리 기존 자산 활용 가능 여부 점검.

docs/ir/modu-startup-2026-09/v2.md

@@ -0,0 +1,184 @@
+# 모두의 창업 2차 지원서 — v2 개선안
+
+> 작성일: 2026-09-15
+> 상태: 문항별 붙여넣기 초안. `제출 전 확정` 표기가 있는 항목은 사실 확인 뒤에만 확정한다.
+> 수익·사업화의 근거: [Tasteby BM v1.1](../../design/705-tasteby-bm-v1-1/README.md), [개인화 전략](../../strategy/tasteby-personalization-as-taste-translation.md), [공유 성장 루프](../../design/711-tasteby-marketing-v1-5/README.md)
+
+> ⚠️ **[2026-09-15 검증] 위 참조 문서 3개는 현재 리포에 존재하지 않는다.** Redmine #705/#711 이슈는 열려 있으나(08-Documenter) 문서 파일이 없다. 링크를 살리려면 문서를 작성하거나, 링크를 제거해야 한다.
+
+## v1 → v2 변경 요약
+- Q1: 한 줄 소개를 "AI 자동 정리 플랫폼" → "발견에서 나의 기록으로 연결" 관점으로 교체
+- Q2: 비문 정리 + "다시 쓸 수 있게"라는 문제 정의로 재구성
+- Q3-1: 타겟 나열 → 차별점 3가지(출처 있는 발견 / 큐레이터 기준 탐색 / 비공개 맛 기억) 구조로 재배치
+- Q3-2: 111자 → 수익 원칙 + 4개 수익원의 단계적 검증 순서로 전면 작성
+- Q4-1: 로드맵 나열 → 쐐기시장(큐레이터 1 × 지역 1 × 메뉴 1) 전제의 0-3/4-6/7-12개월 검증 계획
+- Q4-2: 자금 사용 계획 → 멘토에게 받을 도움 4가지로 재작성
+- Q5~Q12: 전부 신규 작성 (영상 구성안, 분야 선택 기준, Q7 판단표, Q8 재도전 답안 틀, Q9 역량, Q11 공개 소개문, 사진 배분)
+
+---
+
+## Q1. 나의 아이디어를 한 줄로 소개해주세요. (필수 / 10~100자)
+
+> 신뢰하는 미식 큐레이터의 영상 속 맛집을 찾아, 나의 다음 식사와 기록으로 연결하는 Tasteby
+
+- v2 검증: 54자. 제출 화면의 실제 글자 수를 최종 확인한다.
+
+## Q2. 아이디어를 떠올린 배경 이야기를 들려주세요. (필수 / 2,000자)
+
+저는 맛집 영상을 보는 것을 좋아하지만, 막상 식사 약속이 잡히면 같은 문제를 반복해서 겪었습니다. "성시경 영상에서 본 그 국밥집이 어디였지?" 기억나는 것은 사람과 메뉴의 인상뿐이었습니다. 다시 영상을 찾아 자막을 넘기고, 식당 이름을 받아 적어 지도에 옮겨야 했습니다. 좋아하는 채널이 늘수록 저장한 정보도 늘었지만, 정작 필요한 순간에는 더 찾기 어려워졌습니다.
+
+이 불편은 일본 여행에서 더 선명해졌습니다. 여행 전에 한국 미식 유튜버의 일본 맛집 영상을 여러 편 봤지만, 현지에서는 어느 영상의 어느 장면에 나온 식당인지 다시 찾는 데 시간이 들었습니다. 별점과 후기 수가 많은 식당은 쉽게 찾을 수 있었지만, 제가 실제로 궁금했던 것은 "내가 신뢰하는 이 사람이 왜 이곳을 골랐는가"였습니다. 영상, 지도, 메모앱이 각각 답의 일부만 갖고 있었습니다.
+
+그래서 출발한 질문은 "맛집을 더 많이 모으려면 어떻게 해야 할까?"가 아니었습니다. **신뢰하는 사람의 선택을, 다음 식사를 고를 때 다시 쓸 수 있게 하려면 어떻게 해야 할까?**였습니다.
+
+Tasteby는 미식 큐레이터의 영상·글 속 식당, 메뉴, 언급 맥락을 구조화해 지도와 탐색 화면에서 찾게 하는 서비스입니다. 사용자는 원본 콘텐츠로 다시 돌아가 맥락을 확인할 수 있고, 마음에 드는 곳은 자신의 찜과 비공개 메모에 남길 수 있습니다. 즉, Tasteby는 원본 영상을 대체하거나 익명 다수의 평가를 더 크게 만드는 서비스가 아니라, 흩어진 신뢰의 단서를 실제 외식 결정에 쓸 수 있게 연결하는 도구입니다.
+
+AI는 이 일을 가능하게 하는 수단입니다. 영상 자막과 공개 정보를 바탕으로 식당 후보를 구조화하되, 원본 출처를 남기고 오류는 정정할 수 있게 설계합니다. 저는 "AI가 맛집을 대신 추천한다"보다 "사람이 쌓아 온 신뢰를 사용자가 다시 쓸 수 있게 한다"는 방향이 더 오래 갈 수 있다고 믿습니다. Tasteby는 좋은 한 끼를 찾는 순간과, 좋았던 한 끼를 다시 기억하는 순간을 하나의 경험으로 만들고자 합니다.
+
+## Q3-1. 기존 제품 및 서비스 대비 차별점과 어떤 문제를 해결할 수 있나요? (필수 / 2,000자)
+
+Tasteby는 또 하나의 맛집 순위 서비스가 아닙니다. 출발점이 "평점이 높은 곳은 어디인가?"가 아니라 **"내가 신뢰하는 사람이 어느 콘텐츠에서, 어떤 메뉴를, 왜 언급했는가?"**이기 때문입니다.
+
+기존 맛집 서비스는 대체로 다수 이용자의 별점·후기, 예약 가능 여부, 지역 검색을 중심으로 설계돼 있습니다. 이 방식은 넓은 선택지를 빠르게 보여 주는 데 유용하지만, 영상을 보고 특정 사람의 선택을 기억한 사용자에게는 두 가지 공백이 남습니다. 첫째, 영상 속 식당의 이름·주소·메뉴가 콘텐츠 안에 흩어져 있어 나중에 다시 찾기 어렵습니다. 둘째, 평균 별점만으로는 왜 그 사람이 그 식당을 언급했는지, 내가 오늘 갈 이유가 있는지 판단하기 어렵습니다.
+
+Tasteby의 차별점은 세 가지입니다.
+
+첫째, **출처가 있는 발견**입니다. 식당을 보여 줄 때 원본 콘텐츠와 메뉴·언급 맥락을 함께 연결합니다. 사용자는 Tasteby의 요약만 믿을 필요 없이 원본으로 돌아가 확인할 수 있습니다. 추천인지 단순 언급인지, 협찬 또는 정정 정보가 확인되는 경우에는 이를 구분해 보이는 방향으로 신뢰를 설계합니다.
+
+둘째, **분야별 큐레이터의 선택을 탐색 기준으로 사용**합니다. 사용자는 무작위 목록이 아니라 자신이 신뢰하는 미식 큐레이터, 먹고 싶은 메뉴, 갈 지역을 함께 놓고 후보를 좁힐 수 있습니다. 이는 "유명해서"가 아니라 특정 음식과 상황을 꾸준히 다뤄 온 사람의 관점을 발견의 출발점으로 삼는 방식입니다.
+
+셋째, **개인의 맛 기억을 기본 비공개로 보존**합니다. 사용자는 방문 뒤 좋았던 이유와 다음에 갈 조건을 자기 메모로 남길 수 있습니다. 공개 리뷰를 많이 쓰게 하는 대신, 먼저 나를 위한 기록이 다음 선택에 다시 쓰이도록 하는 것이 목표입니다. 나중에 사용자가 원할 때만 일부 후보를 동행에게 공유할 수 있으며, 비공개 메모는 공유되지 않습니다.
+
+Tasteby가 해결하려는 문제는 정보 부족이 아니라 **신뢰할 만한 정보를 다시 쓸 수 없는 문제**입니다. 음식 콘텐츠를 보는 사람은 다음 식사를 더 쉽게 결정하고, 크리에이터는 자신의 콘텐츠가 일회성 조회를 넘어 정정 가능하고 탐색 가능한 아카이브로 이어질 수 있습니다. AI는 이 구조를 빠르게 만들지만, 경쟁력의 핵심은 AI 자체가 아니라 출처를 보존하고 개인의 선택으로 이어 주는 제품 경험입니다.
+
+## Q3-2. 어떻게 수익을 창출할 계획인가요? (선택 / 2,000자)
+
+Tasteby의 수익 원칙은 분명합니다. **사용자의 비공개 찜과 메모를 판매하지 않고, 돈을 낸 식당이 자연 추천·큐레이터 출처·사용자 기록의 순서를 바꾸지 않게 한다**는 것입니다. 신뢰가 제품의 출발점이므로 단기 매출을 위해 이 원칙을 훼손하면 사업 자체가 약해집니다.
+
+첫 번째 수익원은 공개 탐색 화면의 **명시형 문맥 광고와 프로모션**입니다. 예를 들어 사용자가 공개된 식당·메뉴·상황 페이지에서 정보를 찾을 때, 해당 맥락에 맞는 행사·신메뉴·예약 가능 정보 등을 `광고` 또는 `프로모션`으로 명확히 구분해 노출합니다. 광고주는 의사결정을 앞둔 공개 독자에게 도달할 기회를 구매하고, 사용자는 광고와 큐레이터의 자연 언급을 혼동하지 않습니다. 이 모델은 충분한 공개 탐색 세션과 신뢰 기준이 생긴 뒤 소규모로 검증합니다.
+
+두 번째는 식당·브랜드의 **투명한 캠페인 상품**입니다. 신메뉴, 지역 행사, 예약 가능 정보처럼 사용자의 의사결정에 실질적으로 도움이 되는 정보를 공개 페이지의 별도 영역에서 제공합니다. 유료 여부는 표기하고, 광고비가 검색·추천·공개 리뷰의 순위를 바꾸지 않게 운영합니다. 따라서 판매 단위는 "상위 노출 보장"이 아니라, 표기된 캠페인의 도달과 행동 결과입니다.
+
+세 번째는 사용자가 거래를 원할 때만 연결하는 **예약·주문 제휴 수수료**입니다. Tasteby가 사용자를 수수료가 높은 식당으로 유도하지 않고, 사용자가 이미 고른 식당에서 예약·주문을 원할 때만 제휴 경로를 제공합니다. 이 수익원은 사용자 행동과 파트너 연동이 검증된 뒤 도입합니다.
+
+추가로, 크리에이터가 자신의 출처·정정·아카이브 관리를 원한다면 공식 큐레이터 페이지와 관리 도구를 유료 또는 수익 분배 방식으로 검토할 수 있습니다. 다만 기존 콘텐츠를 단순 재포장해 과금하지 않고, 크리에이터와 시청자의 재탐색 문제를 실제로 줄이는 경우에만 추진합니다.
+
+초기 12개월의 목표는 매출을 과장하는 것이 아니라, 출처 기반 탐색 → 후보 저장 → 재열람이 반복되는 공개 의사결정 문맥을 검증하는 것입니다. 그 증거가 생긴 뒤 광고·프로모션·제휴를 순서대로 시험해 신뢰를 지키며 매출을 만든다는 계획입니다.
+
+## Q4-1. 아이디어를 어떻게 사업화 하실 계획이신가요? (필수 / 2,000자)
+
+Tasteby는 아이디어 단계에 머물지 않고, 큐레이터 출처·식당·메뉴 탐색, 지도 기반 발견, 회원·찜·공개 리뷰·비공개 메모를 갖춘 MVP를 개발해 왔습니다. 서비스의 핵심은 영상·글에서 식당 후보 정보를 구조화하고, 지오코딩과 검색을 통해 사용자가 큐레이터·지역·메뉴 기준으로 다시 찾게 하는 것입니다. 저는 Spring Boot와 Next.js를 중심으로 백엔드·프론트엔드·데이터 파이프라인·배포 환경을 직접 설계하고 구현해 왔습니다.
+
+다음 단계의 사업화는 전국의 모든 맛집을 한꺼번에 늘리는 방식이 아닙니다. `큐레이터 1명 × 지역 1곳 × 메뉴 또는 식사 상황 1개`라는 작은 시장에서 출처 정확도와 실제 사용 행동을 먼저 증명하겠습니다.
+
+**0~3개월**에는 첫 쐐기시장의 원본·식당·메뉴 데이터를 검수하고, 오류 정정 경로와 발견→원본 확인→후보 저장의 행동 계측을 갖추겠습니다. 식당 DB 5,000곳 이상과 등록 채널 10곳 이상은 단순 수량 목표가 아니라, 원본 출처와 메뉴 연결의 정확도를 통과한 데이터만 늘리는 품질 목표로 관리하겠습니다.
+
+**4~6개월**에는 검색·커뮤니티·콘텐츠를 통해 이미 영상 속 식당을 찾는 사용자를 정확한 출처 페이지로 데려오겠습니다. 광고성 무차별 유입보다 "영상 속 그 집을 오늘의 후보로"라는 문제를 가진 사용자의 탐색·저장 행동을 검증하겠습니다. 동시에 큐레이터 또는 매니저에게는 단순 홍보 요청이 아니라, 오래된 콘텐츠의 출처 정리·정정·시청자 재탐색이라는 가치를 제안해 파트너십 3건을 목표로 협의하겠습니다.
+
+**7~12개월**에는 한국의 검증 결과를 바탕으로 일본 여행 콘텐츠의 제한된 베타를 검토하고, 사용자가 찜한 후보를 동행과 함께 고를 수 있는 공유 기능을 도입하겠습니다. 목표 지표는 MAU 5만, B2B 식당·브랜드 캠페인 20건이지만, 이 수치는 단순 방문자 수가 아니라 출처 확인·후보 저장·재열람·공유 수신자의 탐색으로 검증하겠습니다. 첫 매출은 자연 추천과 분리된 공개 문맥 광고 또는 투명한 캠페인 상품에서 만들 계획입니다.
+
+사업화의 핵심 위험은 기술보다 신뢰입니다. 따라서 원본 링크를 보존하고, 협찬·정정 상태를 관리하며, 비공개 메모를 광고 타기팅에 쓰지 않겠습니다. 저는 기술 개발, 데이터 품질, 사용자 경험, 초기 유통을 하나의 반복 실험으로 운영해 "더 많은 식당"이 아니라 "다시 쓰이는 신뢰"를 증명하겠습니다.
+
+> 제출 전 사실 확인: `MVP 운영 중`, 실제 도메인 접속 상태, 현재 식당/채널 수는 제출일에 확인하여 위 첫 문단 또는 로드맵 표현을 조정한다.
+
+## Q4-2. 책임멘토를 통해 어떤 도움을 받고 싶은가요? (선택 / 2,000자)
+
+저는 Tasteby의 제품과 기술 구현은 직접 추진해 왔지만, 다음 단계에서 필요한 것은 개발 조언보다 **신뢰를 훼손하지 않는 시장 진입과 계약의 기준**입니다. 책임멘토에게 네 가지 도움을 받고 싶습니다.
+
+첫째, 크리에이터 파트너십의 실무입니다. Tasteby는 타인의 콘텐츠를 대신 소비시키는 서비스가 아니라 원본으로 다시 연결하는 서비스여야 합니다. 큐레이터·매니저에게 어떤 가치 제안을 해야 하는지, 출처·초상·인용·협찬 표기를 어떤 계약과 운영 절차로 정리해야 하는지 조언을 받고 싶습니다.
+
+둘째, 초기 B2B 상품의 검증입니다. 식당이나 브랜드가 돈을 낸다고 해서 자연 추천 순위가 바뀌면 Tasteby의 차별점은 사라집니다. 공개 탐색 문맥에서 사용자가 받아들일 수 있는 광고·프로모션의 형태, 가격 이전에 검증해야 할 성과 지표, 첫 고객을 찾는 영업 경로를 함께 설계하고 싶습니다.
+
+셋째, 초기 사용자 획득 전략입니다. 검색·커뮤니티·콘텐츠 중 어떤 좁은 시장에서 출처 탐색과 후보 저장이 실제로 반복되는지, 작은 예산으로 무엇을 먼저 검증해야 하는지에 대한 피드백이 필요합니다. '바이럴'이나 조회 수가 아니라 재방문과 결정 행동으로 판단하는 방법을 배우고 싶습니다.
+
+넷째, 해외 확장 우선순위입니다. 일본 여행 콘텐츠는 분명한 사용 사례이지만, 국내에서 어떤 데이터 품질과 파트너십 기준을 먼저 증명해야 하는지, 다국어·현지 정보·권리 이슈를 어떤 순서로 풀어야 하는지 검토받고 싶습니다.
+
+멘토링을 통해 막연한 인맥 소개보다, 파트너십·수익·유통에서 반복 가능한 의사결정 기준을 얻고 싶습니다. 이를 바탕으로 1인 개발자가 만든 MVP를 신뢰할 수 있는 소비자 서비스와 지속 가능한 사업으로 확장하겠습니다.
+
+## Q5. 나의 아이디어를 소개하는 영상을 링크로 제출해주세요. (선택 / 유튜브 링크만)
+
+**권장: 제출한다.** 75~90초 분량으로 아래 흐름을 사용한다.
+
+1. 0~15초 — "그 영상의 그 식당, 어디였지?"라는 개인 경험과 재검색 장면
+2. 15~40초 — Tasteby에서 큐레이터·식당·메뉴·원본을 연결해 찾는 실제 화면
+3. 40~60초 — 찜과 비공개 메모, 동행과 후보를 고르는 공유 카드의 가치
+4. 60~80초 — AI는 정보를 구조화하고, Tasteby는 사람의 신뢰를 다시 쓰게 한다는 차별점
+5. 80~90초 — 12개월 검증 목표와 멘토링 요청
+
+> 제출 전 입력: `[YouTube URL]`
+> 제작 원칙: Tasteby 자체 화면·직접 제작한 도식만 사용한다. 타인의 유튜브 영상·썸네일·음원을 무단 삽입하지 않는다.
+
+## Q6. 사업 분야를 선택해주세요. (필수 / 드롭다운)
+
+**제출 전 실제 선택지 확인 후 선택한다.**
+
+1순위는 `AI·데이터`다. Tasteby의 사용자 가치는 외식 발견이지만, 영상·글에서 식당 정보를 구조화하고 출처 기반으로 탐색하게 하는 핵심 실행 수단이 AI·데이터이기 때문이다. 해당 선택지가 없으면 2순위는 `플랫폼/O2O`, 그다음은 `푸드테크`다. 예약·배달 거래가 현재 핵심이 아니므로 관광·여행은 일본 베타 이후의 보조 분야로 둔다.
+
+## Q7. 지원자의 현재 창업 여부를 알려주세요. (필수 / 택1)
+
+**법적 사실 확인 전 선택하지 않는다.**
+
+| 확인 결과 | 선택 |
+|---|---|
+| 본인 명의 사업자/법인의 창업일이 기준 기간에 없거나, 기창업자 요건에 해당하지 않음 | `예비창업자` |
+| 창업일이 2019-08-21~2026-08-20이고 Tasteby가 기존 사업과 다른 이종 창업 아이템임 | `기창업자` |
+
+MVP를 개발하거나 도메인을 운영했다는 사실만으로 Q7을 판단하지 않는다. 사업자등록·법인 설립·공고의 세부 기준을 제출 전에 확인한다.
+
+## Q8. 2차 지원서에서는 1차 지원서보다 어떤 점이 더 개선되었나요? (선택 / 재도전 가점)
+
+**1차 원문/피드백 확보 후 제출할 답안이다. 현재는 아래 대괄호만 1차 사실로 교체한다.**
+
+1차에서는 [1차에 제시한 핵심 문제와 해결 방식]을 중심으로 아이디어를 설명했습니다. 2차에서는 이를 단순한 맛집 정보 서비스가 아니라, `큐레이터 출처로 발견 → 개인 찜과 비공개 기록으로 재사용 → 선택한 후보를 동행과 공유`하는 제품 구조로 구체화했습니다.
+
+또한 아이디어 수준의 설명에서 나아가, MVP에 구현한 출처·식당·메뉴 탐색과 찜·리뷰·메모 기능을 기준으로 사업화 순서를 다시 설계했습니다. 수익도 여러 가능성을 나열하는 대신, 공개 탐색 문맥의 명시형 광고·프로모션을 먼저 검증하고 예약·주문 제휴와 크리에이터 관리 도구는 조건이 충족될 때 단계적으로 검토하도록 정리했습니다.
+
+마지막으로 2차에서는 기술 자체보다 신뢰를 핵심 경쟁력으로 명확히 했습니다. 원본 콘텐츠를 대체하지 않고 출처를 보존하며, 사용자의 비공개 메모를 광고 타기팅이나 외부 판매에 쓰지 않는 원칙을 세웠습니다. 이번 지원서는 "AI로 맛집을 모으겠다"는 설명에서 한 단계 더 나아가, 어떤 사용자가 왜 다시 쓰고 어떤 방식으로 사업이 되는지를 검증 가능한 계획으로 보완한 결과입니다.
+
+## Q9. 아이디어를 사업화 시킬 수 있는 본인의 역량을 알려주세요. (선택 / 2,000자)
+
+Tasteby의 가장 큰 강점 중 하나는 아이디어를 설명하는 데서 멈추지 않고, 제품으로 만들고 운영 가능한 형태로 옮겨 왔다는 점입니다. 저는 1인 풀스택 개발자로서 문제 정의부터 데이터 구조, 백엔드·프론트엔드 구현, AI 처리 파이프라인, 배포 환경까지 직접 설계하고 연결해 왔습니다.
+
+Tasteby에서는 Spring Boot와 Java 기반의 서비스 로직, Next.js 기반의 사용자 화면, Oracle 23ai 벡터 데이터베이스와 Redis를 활용한 데이터 처리 구조를 구성했습니다. 영상·글에서 식당 후보 정보를 구조화하고, 지오코딩·지도·검색으로 사용자가 다시 찾을 수 있게 만드는 파이프라인도 직접 만들었습니다. 기술을 개별 기능으로 쌓기보다, "출처를 찾는다 → 후보를 저장한다 → 방문 뒤 기억한다 → 다음 선택에 다시 쓴다"는 한 사용 흐름이 완성되도록 설계한 경험이 있습니다.
+
+저의 실행 방식은 작은 가설을 빠르게 제품으로 옮기고, 실제 사용 행동으로 다음 우선순위를 정하는 것입니다. 예를 들어 Tasteby의 비공개 메모는 리뷰를 많이 받기 위한 기능이 아니라, 사용자가 좋았던 경험을 다음 외식에 다시 쓰게 하기 위한 기능입니다. 찜 공유 역시 전체 취향을 공개하는 기능이 아니라, 사용자가 고른 후보만 동행과 함께 결정하게 하는 기능으로 분리했습니다. 이처럼 기술의 가능성보다 사용자의 신뢰와 권한을 먼저 설계하는 것이 저의 제품 역량입니다.
+
+또한 혼자서도 기획·개발·운영을 연결할 수 있지만, 모든 것을 혼자 해결하려 하지 않습니다. 크리에이터 계약, 저작권·표기, 초기 B2B 영업, 해외 확장은 멘토와 파트너의 전문성이 필요한 영역으로 분명히 인식하고 있습니다. 저는 빠르게 만들 수 있는 실행력과, 모르는 영역을 검증 가능한 질문으로 바꾸는 운영 방식을 바탕으로 Tasteby를 사업으로 성장시키겠습니다.
+
+> 제출 전 보강 후보: 공개 가능한 직장 경력, 이전 프로젝트, 수상·자격, 서비스 운영 수치가 있으면 사실 확인 뒤 한 단락만 추가한다.
+
+## Q10. 함께하는 팀원이 있다면 본인을 제외한 팀원 명수를 알려주세요. (선택 / 드롭다운)
+
+`팀원 없음`
+
+현재는 1인 창업자로 제품을 직접 개발·운영한다. 다만 법무·크리에이터 파트너십·B2B 영업은 외부 전문가 및 멘토와 보완할 계획이다.
+
+## Q11. 내 아이디어를 사람들에게 자랑해보세요. (선택 / 홈페이지 공개 + 좋아요)
+
+> **맛집 영상을 보다가 "그 집 어디였지?"를 되묻는 사람을 위해 만들었습니다.**
+> Tasteby는 신뢰하는 미식 큐레이터가 언급한 식당과 메뉴를 원본 출처와 함께 찾고, 마음에 드는 곳은 내 찜에 남겨 다음 식사에 다시 쓰게 합니다.
+> 좋은 한 끼를 발견하는 순간과, 좋았던 한 끼를 기억하는 순간을 연결합니다.
+> `www.tasteby.net`
+
+> 게시 전: 실제 접속 URL과 대표 스크린샷을 확인한다.
+
+## Q12. 서약서 동의 (필수)
+
+제출 직전에 아래를 각각 읽고 동의한다.
+
+- 참여 서약서
+- 본인 아이디어 확인 서약서
+- 비밀유지 서약서
+
+## 사진 배분 계획 (전체 10장 제한)
+
+| 문항 | 장수 | 권장 이미지 | 심사에서 보여 줄 사실 |
+|------|---:|---|---|
+| Q2 | 1 | 직접 만든 `영상 속 정보 → Tasteby 출처·지도 → 다음 식사` 흐름 도식 | 왜 이 서비스가 필요한가 |
+| Q3-1 | 3 | 지도 탐색, 식당 상세의 원본/메뉴 근거, 찜·비공개 메모 화면 | 출처·개인 기록의 차별점 |
+| Q4-1 | 2 | 데이터 처리·정정 흐름 도식, 12개월 로드맵 | 이미 만든 것과 다음 검증 순서 |
+| Q9 | 1 | 실제 서비스 아키텍처 또는 개발·배포 흐름 | 1인 실행 역량 |
+| Q11 | 1 | 모바일 또는 데스크톱 대표 화면 한 장 | 공개 소개의 첫 인상 |
+| 예비 | 2 | 수신자 공유 카드, 모바일 탐색 화면 | 심사 코멘트 대응 또는 품질이 높은 화면 교체 |
+
+총 8장을 기본으로 사용하고 2장은 예비로 남긴다. 모든 화면은 제출일 기준 실제 동작·표현과 일치해야 하며, 원본 영상 캡처·타인 음식 사진은 사용권을 확인하지 못하면 사용하지 않는다.

docs/ir/modu-startup-2026-09/v3.md

@@ -0,0 +1,180 @@
+# 모두의 창업 2차 지원서 — v3
+
+> 작성일: 2026-09-15
+> 상태: v2에 **실측 지표**를 반영한 판. `제출 전 확정` 표기 항목은 사실 확인 뒤에만 확정한다.
+
+## v2 → v3 변경 요약
+- **Q4-1 전면 수정**: "3개월에 식당 5,000곳"(현재의 10배, 달성 불가) → 현재 실측치(채널 6·영상 909·식당 500)에서 출발하는 배수 목표로 교체. 0~3개월 과제를 수량이 아니라 **LLM 미검증 1,071건 정리**로 재정의
+- **Q4-1에 사용자 현황 명시**: 공개 회원 모집을 아직 시작하지 않은 단계임을 밝히고, 4~6개월의 핵심 과제를 첫 사용자 집단 확보로 지정
+- **Q3-1·Q4-1에 해외 데이터 반영**: 일본 28곳 포함 해외 60여 곳이 이미 축적됨 → 일본 확장이 "구상"이 아니라 "이미 시작된 축적"임을 근거로 제시
+- **깨진 참조 링크 3개 제거** (`docs/design/705-…`, `docs/strategy/…`, `docs/design/711-…` — 리포에 존재하지 않음)
+
+> 실측 출처: 2026-09-15 Admin 화면 및 `GET /api/restaurants?limit=100000` 조회. 상세는 `README.md` 실측 지표 표.
+
+## Q1. 나의 아이디어를 한 줄로 소개해주세요. (필수 / 10~100자)
+
+> 신뢰하는 미식 큐레이터의 영상 속 맛집을 찾아, 나의 다음 식사와 기록으로 연결하는 Tasteby
+
+- v2 검증: 54자. 제출 화면의 실제 글자 수를 최종 확인한다.
+
+## Q2. 아이디어를 떠올린 배경 이야기를 들려주세요. (필수 / 2,000자)
+
+저는 맛집 영상을 보는 것을 좋아하지만, 막상 식사 약속이 잡히면 같은 문제를 반복해서 겪었습니다. "성시경 영상에서 본 그 국밥집이 어디였지?" 기억나는 것은 사람과 메뉴의 인상뿐이었습니다. 다시 영상을 찾아 자막을 넘기고, 식당 이름을 받아 적어 지도에 옮겨야 했습니다. 좋아하는 채널이 늘수록 저장한 정보도 늘었지만, 정작 필요한 순간에는 더 찾기 어려워졌습니다.
+
+이 불편은 일본 여행에서 더 선명해졌습니다. 여행 전에 한국 미식 유튜버의 일본 맛집 영상을 여러 편 봤지만, 현지에서는 어느 영상의 어느 장면에 나온 식당인지 다시 찾는 데 시간이 들었습니다. 별점과 후기 수가 많은 식당은 쉽게 찾을 수 있었지만, 제가 실제로 궁금했던 것은 "내가 신뢰하는 이 사람이 왜 이곳을 골랐는가"였습니다. 영상, 지도, 메모앱이 각각 답의 일부만 갖고 있었습니다.
+
+그래서 출발한 질문은 "맛집을 더 많이 모으려면 어떻게 해야 할까?"가 아니었습니다. **신뢰하는 사람의 선택을, 다음 식사를 고를 때 다시 쓸 수 있게 하려면 어떻게 해야 할까?**였습니다.
+
+Tasteby는 미식 큐레이터의 영상·글 속 식당, 메뉴, 언급 맥락을 구조화해 지도와 탐색 화면에서 찾게 하는 서비스입니다. 사용자는 원본 콘텐츠로 다시 돌아가 맥락을 확인할 수 있고, 마음에 드는 곳은 자신의 찜과 비공개 메모에 남길 수 있습니다. 즉, Tasteby는 원본 영상을 대체하거나 익명 다수의 평가를 더 크게 만드는 서비스가 아니라, 흩어진 신뢰의 단서를 실제 외식 결정에 쓸 수 있게 연결하는 도구입니다.
+
+AI는 이 일을 가능하게 하는 수단입니다. 영상 자막과 공개 정보를 바탕으로 식당 후보를 구조화하되, 원본 출처를 남기고 오류는 정정할 수 있게 설계합니다. 저는 "AI가 맛집을 대신 추천한다"보다 "사람이 쌓아 온 신뢰를 사용자가 다시 쓸 수 있게 한다"는 방향이 더 오래 갈 수 있다고 믿습니다. Tasteby는 좋은 한 끼를 찾는 순간과, 좋았던 한 끼를 다시 기억하는 순간을 하나의 경험으로 만들고자 합니다.
+
+## Q3-1. 기존 제품 및 서비스 대비 차별점과 어떤 문제를 해결할 수 있나요? (필수 / 2,000자)
+
+Tasteby는 또 하나의 맛집 순위 서비스가 아닙니다. 출발점이 "평점이 높은 곳은 어디인가?"가 아니라 **"내가 신뢰하는 사람이 어느 콘텐츠에서, 어떤 메뉴를, 왜 언급했는가?"**이기 때문입니다.
+
+기존 맛집 서비스는 대체로 다수 이용자의 별점·후기, 예약 가능 여부, 지역 검색을 중심으로 설계돼 있습니다. 이 방식은 넓은 선택지를 빠르게 보여 주는 데 유용하지만, 영상을 보고 특정 사람의 선택을 기억한 사용자에게는 두 가지 공백이 남습니다. 첫째, 영상 속 식당의 이름·주소·메뉴가 콘텐츠 안에 흩어져 있어 나중에 다시 찾기 어렵습니다. 둘째, 평균 별점만으로는 왜 그 사람이 그 식당을 언급했는지, 내가 오늘 갈 이유가 있는지 판단하기 어렵습니다.
+
+Tasteby의 차별점은 세 가지입니다.
+
+첫째, **출처가 있는 발견**입니다. 식당을 보여 줄 때 원본 콘텐츠와 메뉴·언급 맥락을 함께 연결합니다. 사용자는 Tasteby의 요약만 믿을 필요 없이 원본으로 돌아가 확인할 수 있습니다. 추천인지 단순 언급인지, 협찬 또는 정정 정보가 확인되는 경우에는 이를 구분해 보이는 방향으로 신뢰를 설계합니다.
+
+둘째, **분야별 큐레이터의 선택을 탐색 기준으로 사용**합니다. 사용자는 무작위 목록이 아니라 자신이 신뢰하는 미식 큐레이터, 먹고 싶은 메뉴, 갈 지역을 함께 놓고 후보를 좁힐 수 있습니다. 이는 "유명해서"가 아니라 특정 음식과 상황을 꾸준히 다뤄 온 사람의 관점을 발견의 출발점으로 삼는 방식입니다.
+
+셋째, **개인의 맛 기억을 기본 비공개로 보존**합니다. 사용자는 방문 뒤 좋았던 이유와 다음에 갈 조건을 자기 메모로 남길 수 있습니다. 공개 리뷰를 많이 쓰게 하는 대신, 먼저 나를 위한 기록이 다음 선택에 다시 쓰이도록 하는 것이 목표입니다. 나중에 사용자가 원할 때만 일부 후보를 동행에게 공유할 수 있으며, 비공개 메모는 공유되지 않습니다.
+
+이 구조는 국내에만 적용되는 것이 아닙니다. 현재도 한국 큐레이터가 다룬 일본·미국·싱가포르 등 해외 식당 60여 곳이 같은 방식으로 쌓이고 있습니다. 여행지에서 익명 리뷰를 처음부터 다시 읽는 대신, 이미 신뢰하는 사람의 선택을 그대로 꺼내 쓸 수 있다는 뜻입니다.
+
+Tasteby가 해결하려는 문제는 정보 부족이 아니라 **신뢰할 만한 정보를 다시 쓸 수 없는 문제**입니다. 음식 콘텐츠를 보는 사람은 다음 식사를 더 쉽게 결정하고, 크리에이터는 자신의 콘텐츠가 일회성 조회를 넘어 정정 가능하고 탐색 가능한 아카이브로 이어질 수 있습니다. AI는 이 구조를 빠르게 만들지만, 경쟁력의 핵심은 AI 자체가 아니라 출처를 보존하고 개인의 선택으로 이어 주는 제품 경험입니다.
+
+## Q3-2. 어떻게 수익을 창출할 계획인가요? (선택 / 2,000자)
+
+Tasteby의 수익 원칙은 분명합니다. **사용자의 비공개 찜과 메모를 판매하지 않고, 돈을 낸 식당이 자연 추천·큐레이터 출처·사용자 기록의 순서를 바꾸지 않게 한다**는 것입니다. 신뢰가 제품의 출발점이므로 단기 매출을 위해 이 원칙을 훼손하면 사업 자체가 약해집니다.
+
+첫 번째 수익원은 공개 탐색 화면의 **명시형 문맥 광고와 프로모션**입니다. 예를 들어 사용자가 공개된 식당·메뉴·상황 페이지에서 정보를 찾을 때, 해당 맥락에 맞는 행사·신메뉴·예약 가능 정보 등을 `광고` 또는 `프로모션`으로 명확히 구분해 노출합니다. 광고주는 의사결정을 앞둔 공개 독자에게 도달할 기회를 구매하고, 사용자는 광고와 큐레이터의 자연 언급을 혼동하지 않습니다. 이 모델은 충분한 공개 탐색 세션과 신뢰 기준이 생긴 뒤 소규모로 검증합니다.
+
+두 번째는 식당·브랜드의 **투명한 캠페인 상품**입니다. 신메뉴, 지역 행사, 예약 가능 정보처럼 사용자의 의사결정에 실질적으로 도움이 되는 정보를 공개 페이지의 별도 영역에서 제공합니다. 유료 여부는 표기하고, 광고비가 검색·추천·공개 리뷰의 순위를 바꾸지 않게 운영합니다. 따라서 판매 단위는 "상위 노출 보장"이 아니라, 표기된 캠페인의 도달과 행동 결과입니다.
+
+세 번째는 사용자가 거래를 원할 때만 연결하는 **예약·주문 제휴 수수료**입니다. Tasteby가 사용자를 수수료가 높은 식당으로 유도하지 않고, 사용자가 이미 고른 식당에서 예약·주문을 원할 때만 제휴 경로를 제공합니다. 이 수익원은 사용자 행동과 파트너 연동이 검증된 뒤 도입합니다.
+
+추가로, 크리에이터가 자신의 출처·정정·아카이브 관리를 원한다면 공식 큐레이터 페이지와 관리 도구를 유료 또는 수익 분배 방식으로 검토할 수 있습니다. 다만 기존 콘텐츠를 단순 재포장해 과금하지 않고, 크리에이터와 시청자의 재탐색 문제를 실제로 줄이는 경우에만 추진합니다.
+
+초기 12개월의 목표는 매출을 과장하는 것이 아니라, 출처 기반 탐색 → 후보 저장 → 재열람이 반복되는 공개 의사결정 문맥을 검증하는 것입니다. 그 증거가 생긴 뒤 광고·프로모션·제휴를 순서대로 시험해 신뢰를 지키며 매출을 만든다는 계획입니다.
+
+## Q4-1. 아이디어를 어떻게 사업화 하실 계획이신가요? (필수 / 2,000자)
+
+Tasteby는 아이디어 단계에 머물지 않고, 큐레이터 출처·식당·메뉴 탐색, 지도 기반 발견, 회원·찜·공개 리뷰·비공개 메모를 갖춘 서비스를 직접 개발해 운영하고 있습니다. 2026년 9월 기준 등록 채널 6곳, 수집 영상 909편에서 추출해 좌표까지 연결한 식당 500곳을 확보했고, 그중에는 일본 28곳을 포함한 해외 식당 60여 곳이 이미 포함돼 있습니다. 저는 Spring Boot와 Next.js를 중심으로 백엔드·프론트엔드·데이터 파이프라인·배포 환경을 직접 설계하고 구현했습니다.
+
+다음 단계의 사업화는 전국의 모든 맛집을 한꺼번에 늘리는 방식이 아닙니다. `큐레이터 1명 × 지역 1곳 × 메뉴 또는 식사 상황 1개`라는 작은 시장에서 출처 정확도와 실제 사용 행동을 먼저 증명하겠습니다.
+
+**0~3개월에는 수량보다 신뢰도를 먼저 올리겠습니다.** 현재 LLM 검증을 거치지 않은 영상-식당 연결이 1,071건 남아 있습니다. 이를 정리해 출처와 메뉴 연결이 검증된 데이터만 노출하고, 오류 정정 경로와 `발견 → 원본 확인 → 후보 저장`의 행동 계측을 갖추겠습니다. 데이터는 채널을 10곳으로 늘려 식당 1,500곳 규모를 목표로 하되, 정확도 기준을 통과한 것만 셈에 넣겠습니다.
+
+**4~6개월에는 첫 사용자 집단을 만들겠습니다.** 현재는 공개 회원 모집을 시작하지 않았고 제품과 데이터 품질을 먼저 확보하는 단계입니다. 따라서 이 구간의 핵심 과제는 방문자 수를 늘리는 것이 아니라, "영상 속 그 집을 오늘의 후보로"라는 문제를 이미 가진 사용자를 검색·커뮤니티·콘텐츠를 통해 정확한 출처 페이지로 데려와 탐색과 저장이 반복되는지 확인하는 것입니다. 동시에 큐레이터 또는 매니저에게 단순 홍보 요청이 아니라 오래된 콘텐츠의 출처 정리·정정·시청자 재탐색이라는 가치를 제안해 파트너십 3건을 협의하겠습니다.
+
+**7~12개월에는 검증 결과를 확장하겠습니다.** 이미 확보한 일본 28곳은 한국 큐레이터가 현지에서 남긴 기록이므로, 새로운 데이터 수집 없이도 여행 사용 맥락을 검증할 출발점이 됩니다. 여기에 사용자가 찜한 후보를 동행과 함께 고르는 공유 기능을 더하겠습니다. 목표는 MAU 5만과 B2B 캠페인 20건이지만, 이 수치는 단순 방문자 수가 아니라 출처 확인·후보 저장·재열람·공유 수신자의 탐색으로 검증하겠습니다. 첫 매출은 자연 추천과 분리된 공개 문맥 광고 또는 투명한 캠페인 상품에서 만들 계획입니다.
+
+사업화의 핵심 위험은 기술보다 신뢰입니다. 따라서 원본 링크를 보존하고, 협찬·정정 상태를 관리하며, 비공개 메모를 광고 타기팅에 쓰지 않겠습니다. 저는 "더 많은 식당"이 아니라 "다시 쓰이는 신뢰"를 증명하겠습니다.
+
+> 제출 전 사실 확인: 위 실측치(채널 6·영상 909·식당 500·미검증 1,071·해외 60여)는 2026-09-15 기준이다. 제출일에 다시 조회해 갱신한다.
+
+## Q4-2. 책임멘토를 통해 어떤 도움을 받고 싶은가요? (선택 / 2,000자)
+
+저는 Tasteby의 제품과 기술 구현은 직접 추진해 왔지만, 다음 단계에서 필요한 것은 개발 조언보다 **신뢰를 훼손하지 않는 시장 진입과 계약의 기준**입니다. 책임멘토에게 네 가지 도움을 받고 싶습니다.
+
+첫째, 크리에이터 파트너십의 실무입니다. Tasteby는 타인의 콘텐츠를 대신 소비시키는 서비스가 아니라 원본으로 다시 연결하는 서비스여야 합니다. 큐레이터·매니저에게 어떤 가치 제안을 해야 하는지, 출처·초상·인용·협찬 표기를 어떤 계약과 운영 절차로 정리해야 하는지 조언을 받고 싶습니다.
+
+둘째, 초기 B2B 상품의 검증입니다. 식당이나 브랜드가 돈을 낸다고 해서 자연 추천 순위가 바뀌면 Tasteby의 차별점은 사라집니다. 공개 탐색 문맥에서 사용자가 받아들일 수 있는 광고·프로모션의 형태, 가격 이전에 검증해야 할 성과 지표, 첫 고객을 찾는 영업 경로를 함께 설계하고 싶습니다.
+
+셋째, 초기 사용자 획득 전략입니다. 검색·커뮤니티·콘텐츠 중 어떤 좁은 시장에서 출처 탐색과 후보 저장이 실제로 반복되는지, 작은 예산으로 무엇을 먼저 검증해야 하는지에 대한 피드백이 필요합니다. '바이럴'이나 조회 수가 아니라 재방문과 결정 행동으로 판단하는 방법을 배우고 싶습니다.
+
+넷째, 해외 확장 우선순위입니다. 일본 여행 콘텐츠는 분명한 사용 사례이지만, 국내에서 어떤 데이터 품질과 파트너십 기준을 먼저 증명해야 하는지, 다국어·현지 정보·권리 이슈를 어떤 순서로 풀어야 하는지 검토받고 싶습니다.
+
+멘토링을 통해 막연한 인맥 소개보다, 파트너십·수익·유통에서 반복 가능한 의사결정 기준을 얻고 싶습니다. 이를 바탕으로 1인 개발자가 만든 MVP를 신뢰할 수 있는 소비자 서비스와 지속 가능한 사업으로 확장하겠습니다.
+
+## Q5. 나의 아이디어를 소개하는 영상을 링크로 제출해주세요. (선택 / 유튜브 링크만)
+
+**권장: 제출한다.** 75~90초 분량으로 아래 흐름을 사용한다.
+
+1. 0~15초 — "그 영상의 그 식당, 어디였지?"라는 개인 경험과 재검색 장면
+2. 15~40초 — Tasteby에서 큐레이터·식당·메뉴·원본을 연결해 찾는 실제 화면
+3. 40~60초 — 찜과 비공개 메모, 동행과 후보를 고르는 공유 카드의 가치
+4. 60~80초 — AI는 정보를 구조화하고, Tasteby는 사람의 신뢰를 다시 쓰게 한다는 차별점
+5. 80~90초 — 12개월 검증 목표와 멘토링 요청
+
+> 제출 전 입력: `[YouTube URL]`
+> 제작 원칙: Tasteby 자체 화면·직접 제작한 도식만 사용한다. 타인의 유튜브 영상·썸네일·음원을 무단 삽입하지 않는다.
+
+## Q6. 사업 분야를 선택해주세요. (필수 / 드롭다운)
+
+**제출 전 실제 선택지 확인 후 선택한다.**
+
+1순위는 `AI·데이터`다. Tasteby의 사용자 가치는 외식 발견이지만, 영상·글에서 식당 정보를 구조화하고 출처 기반으로 탐색하게 하는 핵심 실행 수단이 AI·데이터이기 때문이다. 해당 선택지가 없으면 2순위는 `플랫폼/O2O`, 그다음은 `푸드테크`다. 예약·배달 거래가 현재 핵심이 아니므로 관광·여행은 일본 베타 이후의 보조 분야로 둔다.
+
+## Q7. 지원자의 현재 창업 여부를 알려주세요. (필수 / 택1)
+
+**법적 사실 확인 전 선택하지 않는다.**
+
+| 확인 결과 | 선택 |
+|---|---|
+| 본인 명의 사업자/법인의 창업일이 기준 기간에 없거나, 기창업자 요건에 해당하지 않음 | `예비창업자` |
+| 창업일이 2019-08-21~2026-08-20이고 Tasteby가 기존 사업과 다른 이종 창업 아이템임 | `기창업자` |
+
+MVP를 개발하거나 도메인을 운영했다는 사실만으로 Q7을 판단하지 않는다. 사업자등록·법인 설립·공고의 세부 기준을 제출 전에 확인한다.
+
+## Q8. 2차 지원서에서는 1차 지원서보다 어떤 점이 더 개선되었나요? (선택 / 재도전 가점)
+
+**1차 원문/피드백 확보 후 제출할 답안이다. 현재는 아래 대괄호만 1차 사실로 교체한다.**
+
+1차에서는 [1차에 제시한 핵심 문제와 해결 방식]을 중심으로 아이디어를 설명했습니다. 2차에서는 이를 단순한 맛집 정보 서비스가 아니라, `큐레이터 출처로 발견 → 개인 찜과 비공개 기록으로 재사용 → 선택한 후보를 동행과 공유`하는 제품 구조로 구체화했습니다.
+
+또한 아이디어 수준의 설명에서 나아가, MVP에 구현한 출처·식당·메뉴 탐색과 찜·리뷰·메모 기능을 기준으로 사업화 순서를 다시 설계했습니다. 수익도 여러 가능성을 나열하는 대신, 공개 탐색 문맥의 명시형 광고·프로모션을 먼저 검증하고 예약·주문 제휴와 크리에이터 관리 도구는 조건이 충족될 때 단계적으로 검토하도록 정리했습니다.
+
+마지막으로 2차에서는 기술 자체보다 신뢰를 핵심 경쟁력으로 명확히 했습니다. 원본 콘텐츠를 대체하지 않고 출처를 보존하며, 사용자의 비공개 메모를 광고 타기팅이나 외부 판매에 쓰지 않는 원칙을 세웠습니다. 이번 지원서는 "AI로 맛집을 모으겠다"는 설명에서 한 단계 더 나아가, 어떤 사용자가 왜 다시 쓰고 어떤 방식으로 사업이 되는지를 검증 가능한 계획으로 보완한 결과입니다.
+
+## Q9. 아이디어를 사업화 시킬 수 있는 본인의 역량을 알려주세요. (선택 / 2,000자)
+
+Tasteby의 가장 큰 강점 중 하나는 아이디어를 설명하는 데서 멈추지 않고, 제품으로 만들고 운영 가능한 형태로 옮겨 왔다는 점입니다. 저는 1인 풀스택 개발자로서 문제 정의부터 데이터 구조, 백엔드·프론트엔드 구현, AI 처리 파이프라인, 배포 환경까지 직접 설계하고 연결해 왔습니다.
+
+Tasteby에서는 Spring Boot와 Java 기반의 서비스 로직, Next.js 기반의 사용자 화면, Oracle 23ai 벡터 데이터베이스와 Redis를 활용한 데이터 처리 구조를 구성했습니다. 영상·글에서 식당 후보 정보를 구조화하고, 지오코딩·지도·검색으로 사용자가 다시 찾을 수 있게 만드는 파이프라인도 직접 만들었습니다. 기술을 개별 기능으로 쌓기보다, "출처를 찾는다 → 후보를 저장한다 → 방문 뒤 기억한다 → 다음 선택에 다시 쓴다"는 한 사용 흐름이 완성되도록 설계한 경험이 있습니다.
+
+저의 실행 방식은 작은 가설을 빠르게 제품으로 옮기고, 실제 사용 행동으로 다음 우선순위를 정하는 것입니다. 예를 들어 Tasteby의 비공개 메모는 리뷰를 많이 받기 위한 기능이 아니라, 사용자가 좋았던 경험을 다음 외식에 다시 쓰게 하기 위한 기능입니다. 찜 공유 역시 전체 취향을 공개하는 기능이 아니라, 사용자가 고른 후보만 동행과 함께 결정하게 하는 기능으로 분리했습니다. 이처럼 기술의 가능성보다 사용자의 신뢰와 권한을 먼저 설계하는 것이 저의 제품 역량입니다.
+
+또한 혼자서도 기획·개발·운영을 연결할 수 있지만, 모든 것을 혼자 해결하려 하지 않습니다. 크리에이터 계약, 저작권·표기, 초기 B2B 영업, 해외 확장은 멘토와 파트너의 전문성이 필요한 영역으로 분명히 인식하고 있습니다. 저는 빠르게 만들 수 있는 실행력과, 모르는 영역을 검증 가능한 질문으로 바꾸는 운영 방식을 바탕으로 Tasteby를 사업으로 성장시키겠습니다.
+
+> 제출 전 보강 후보: 공개 가능한 직장 경력, 이전 프로젝트, 수상·자격, 서비스 운영 수치가 있으면 사실 확인 뒤 한 단락만 추가한다.
+
+## Q10. 함께하는 팀원이 있다면 본인을 제외한 팀원 명수를 알려주세요. (선택 / 드롭다운)
+
+`팀원 없음`
+
+현재는 1인 창업자로 제품을 직접 개발·운영한다. 다만 법무·크리에이터 파트너십·B2B 영업은 외부 전문가 및 멘토와 보완할 계획이다.
+
+## Q11. 내 아이디어를 사람들에게 자랑해보세요. (선택 / 홈페이지 공개 + 좋아요)
+
+> **맛집 영상을 보다가 "그 집 어디였지?"를 되묻는 사람을 위해 만들었습니다.**
+> Tasteby는 신뢰하는 미식 큐레이터가 언급한 식당과 메뉴를 원본 출처와 함께 찾고, 마음에 드는 곳은 내 찜에 남겨 다음 식사에 다시 쓰게 합니다.
+> 좋은 한 끼를 발견하는 순간과, 좋았던 한 끼를 기억하는 순간을 연결합니다.
+> `www.tasteby.net`
+
+> 게시 전: 실제 접속 URL과 대표 스크린샷을 확인한다.
+
+## Q12. 서약서 동의 (필수)
+
+제출 직전에 아래를 각각 읽고 동의한다.
+
+- 참여 서약서
+- 본인 아이디어 확인 서약서
+- 비밀유지 서약서
+
+## 사진 배분 계획 (전체 10장 제한)
+
+| 문항 | 장수 | 권장 이미지 | 심사에서 보여 줄 사실 |
+|------|---:|---|---|
+| Q2 | 1 | 직접 만든 `영상 속 정보 → Tasteby 출처·지도 → 다음 식사` 흐름 도식 | 왜 이 서비스가 필요한가 |
+| Q3-1 | 3 | 지도 탐색, 식당 상세의 원본/메뉴 근거, 찜·비공개 메모 화면 | 출처·개인 기록의 차별점 |
+| Q4-1 | 2 | 데이터 처리·정정 흐름 도식, 12개월 로드맵 | 이미 만든 것과 다음 검증 순서 |
+| Q9 | 1 | 실제 서비스 아키텍처 또는 개발·배포 흐름 | 1인 실행 역량 |
+| Q11 | 1 | 모바일 또는 데스크톱 대표 화면 한 장 | 공개 소개의 첫 인상 |
+| 예비 | 2 | 수신자 공유 카드, 모바일 탐색 화면 | 심사 코멘트 대응 또는 품질이 높은 화면 교체 |
+
+총 8장을 기본으로 사용하고 2장은 예비로 남긴다. 모든 화면은 제출일 기준 실제 동작·표현과 일치해야 하며, 원본 영상 캡처·타인 음식 사진은 사용권을 확인하지 못하면 사용하지 않는다.

docs/ir/modu-startup-2026-09/v4.md

@@ -0,0 +1,187 @@
+# 모두의 창업 2차 지원서 — v4
+
+> 작성일: 2026-09-15
+> 상태: Q8(재도전 가점)까지 채운 판. `제출 전 확정` 표기 항목만 사실 확인 뒤 확정한다.
+
+## v3 → v4 변경 요약
+- **Q8 완성**: 1차 지원서 원문이 `v1.md`(사용자 제공 원고)임을 확인 → 대괄호를 실제 1차 내용으로 채움. 1차의 실제 약점 4가지(제품 정의·수익모델 나열·근거 없는 수치·멘토 문항 오답)와 2차의 수정을 1:1로 대응시킴
+
+## v2 → v3 변경 요약
+- **Q4-1 전면 수정**: "3개월에 식당 5,000곳"(현재의 10배, 달성 불가) → 현재 실측치(채널 6·영상 909·식당 500)에서 출발하는 배수 목표로 교체. 0~3개월 과제를 수량이 아니라 **LLM 미검증 1,071건 정리**로 재정의
+- **Q4-1에 사용자 현황 명시**: 공개 회원 모집을 아직 시작하지 않은 단계임을 밝히고, 4~6개월의 핵심 과제를 첫 사용자 집단 확보로 지정
+- **Q3-1·Q4-1에 해외 데이터 반영**: 일본 28곳 포함 해외 60여 곳이 이미 축적됨 → 일본 확장이 "구상"이 아니라 "이미 시작된 축적"임을 근거로 제시
+- **깨진 참조 링크 3개 제거** (`docs/design/705-…`, `docs/strategy/…`, `docs/design/711-…` — 리포에 존재하지 않음)
+
+> 실측 출처: 2026-09-15 Admin 화면 및 `GET /api/restaurants?limit=100000` 조회. 상세는 `README.md` 실측 지표 표.
+
+## Q1. 나의 아이디어를 한 줄로 소개해주세요. (필수 / 10~100자)
+
+> 신뢰하는 미식 큐레이터의 영상 속 맛집을 찾아, 나의 다음 식사와 기록으로 연결하는 Tasteby
+
+- v2 검증: 54자. 제출 화면의 실제 글자 수를 최종 확인한다.
+
+## Q2. 아이디어를 떠올린 배경 이야기를 들려주세요. (필수 / 2,000자)
+
+저는 맛집 영상을 보는 것을 좋아하지만, 막상 식사 약속이 잡히면 같은 문제를 반복해서 겪었습니다. "성시경 영상에서 본 그 국밥집이 어디였지?" 기억나는 것은 사람과 메뉴의 인상뿐이었습니다. 다시 영상을 찾아 자막을 넘기고, 식당 이름을 받아 적어 지도에 옮겨야 했습니다. 좋아하는 채널이 늘수록 저장한 정보도 늘었지만, 정작 필요한 순간에는 더 찾기 어려워졌습니다.
+
+이 불편은 일본 여행에서 더 선명해졌습니다. 여행 전에 한국 미식 유튜버의 일본 맛집 영상을 여러 편 봤지만, 현지에서는 어느 영상의 어느 장면에 나온 식당인지 다시 찾는 데 시간이 들었습니다. 별점과 후기 수가 많은 식당은 쉽게 찾을 수 있었지만, 제가 실제로 궁금했던 것은 "내가 신뢰하는 이 사람이 왜 이곳을 골랐는가"였습니다. 영상, 지도, 메모앱이 각각 답의 일부만 갖고 있었습니다.
+
+그래서 출발한 질문은 "맛집을 더 많이 모으려면 어떻게 해야 할까?"가 아니었습니다. **신뢰하는 사람의 선택을, 다음 식사를 고를 때 다시 쓸 수 있게 하려면 어떻게 해야 할까?**였습니다.
+
+Tasteby는 미식 큐레이터의 영상·글 속 식당, 메뉴, 언급 맥락을 구조화해 지도와 탐색 화면에서 찾게 하는 서비스입니다. 사용자는 원본 콘텐츠로 다시 돌아가 맥락을 확인할 수 있고, 마음에 드는 곳은 자신의 찜과 비공개 메모에 남길 수 있습니다. 즉, Tasteby는 원본 영상을 대체하거나 익명 다수의 평가를 더 크게 만드는 서비스가 아니라, 흩어진 신뢰의 단서를 실제 외식 결정에 쓸 수 있게 연결하는 도구입니다.
+
+AI는 이 일을 가능하게 하는 수단입니다. 영상 자막과 공개 정보를 바탕으로 식당 후보를 구조화하되, 원본 출처를 남기고 오류는 정정할 수 있게 설계합니다. 저는 "AI가 맛집을 대신 추천한다"보다 "사람이 쌓아 온 신뢰를 사용자가 다시 쓸 수 있게 한다"는 방향이 더 오래 갈 수 있다고 믿습니다. Tasteby는 좋은 한 끼를 찾는 순간과, 좋았던 한 끼를 다시 기억하는 순간을 하나의 경험으로 만들고자 합니다.
+
+## Q3-1. 기존 제품 및 서비스 대비 차별점과 어떤 문제를 해결할 수 있나요? (필수 / 2,000자)
+
+Tasteby는 또 하나의 맛집 순위 서비스가 아닙니다. 출발점이 "평점이 높은 곳은 어디인가?"가 아니라 **"내가 신뢰하는 사람이 어느 콘텐츠에서, 어떤 메뉴를, 왜 언급했는가?"**이기 때문입니다.
+
+기존 맛집 서비스는 대체로 다수 이용자의 별점·후기, 예약 가능 여부, 지역 검색을 중심으로 설계돼 있습니다. 이 방식은 넓은 선택지를 빠르게 보여 주는 데 유용하지만, 영상을 보고 특정 사람의 선택을 기억한 사용자에게는 두 가지 공백이 남습니다. 첫째, 영상 속 식당의 이름·주소·메뉴가 콘텐츠 안에 흩어져 있어 나중에 다시 찾기 어렵습니다. 둘째, 평균 별점만으로는 왜 그 사람이 그 식당을 언급했는지, 내가 오늘 갈 이유가 있는지 판단하기 어렵습니다.
+
+Tasteby의 차별점은 세 가지입니다.
+
+첫째, **출처가 있는 발견**입니다. 식당을 보여 줄 때 원본 콘텐츠와 메뉴·언급 맥락을 함께 연결합니다. 사용자는 Tasteby의 요약만 믿을 필요 없이 원본으로 돌아가 확인할 수 있습니다. 추천인지 단순 언급인지, 협찬 또는 정정 정보가 확인되는 경우에는 이를 구분해 보이는 방향으로 신뢰를 설계합니다.
+
+둘째, **분야별 큐레이터의 선택을 탐색 기준으로 사용**합니다. 사용자는 무작위 목록이 아니라 자신이 신뢰하는 미식 큐레이터, 먹고 싶은 메뉴, 갈 지역을 함께 놓고 후보를 좁힐 수 있습니다. 이는 "유명해서"가 아니라 특정 음식과 상황을 꾸준히 다뤄 온 사람의 관점을 발견의 출발점으로 삼는 방식입니다.
+
+셋째, **개인의 맛 기억을 기본 비공개로 보존**합니다. 사용자는 방문 뒤 좋았던 이유와 다음에 갈 조건을 자기 메모로 남길 수 있습니다. 공개 리뷰를 많이 쓰게 하는 대신, 먼저 나를 위한 기록이 다음 선택에 다시 쓰이도록 하는 것이 목표입니다. 나중에 사용자가 원할 때만 일부 후보를 동행에게 공유할 수 있으며, 비공개 메모는 공유되지 않습니다.
+
+이 구조는 국내에만 적용되는 것이 아닙니다. 현재도 한국 큐레이터가 다룬 일본·미국·싱가포르 등 해외 식당 60여 곳이 같은 방식으로 쌓이고 있습니다. 여행지에서 익명 리뷰를 처음부터 다시 읽는 대신, 이미 신뢰하는 사람의 선택을 그대로 꺼내 쓸 수 있다는 뜻입니다.
+
+Tasteby가 해결하려는 문제는 정보 부족이 아니라 **신뢰할 만한 정보를 다시 쓸 수 없는 문제**입니다. 음식 콘텐츠를 보는 사람은 다음 식사를 더 쉽게 결정하고, 크리에이터는 자신의 콘텐츠가 일회성 조회를 넘어 정정 가능하고 탐색 가능한 아카이브로 이어질 수 있습니다. AI는 이 구조를 빠르게 만들지만, 경쟁력의 핵심은 AI 자체가 아니라 출처를 보존하고 개인의 선택으로 이어 주는 제품 경험입니다.
+
+## Q3-2. 어떻게 수익을 창출할 계획인가요? (선택 / 2,000자)
+
+Tasteby의 수익 원칙은 분명합니다. **사용자의 비공개 찜과 메모를 판매하지 않고, 돈을 낸 식당이 자연 추천·큐레이터 출처·사용자 기록의 순서를 바꾸지 않게 한다**는 것입니다. 신뢰가 제품의 출발점이므로 단기 매출을 위해 이 원칙을 훼손하면 사업 자체가 약해집니다.
+
+첫 번째 수익원은 공개 탐색 화면의 **명시형 문맥 광고와 프로모션**입니다. 예를 들어 사용자가 공개된 식당·메뉴·상황 페이지에서 정보를 찾을 때, 해당 맥락에 맞는 행사·신메뉴·예약 가능 정보 등을 `광고` 또는 `프로모션`으로 명확히 구분해 노출합니다. 광고주는 의사결정을 앞둔 공개 독자에게 도달할 기회를 구매하고, 사용자는 광고와 큐레이터의 자연 언급을 혼동하지 않습니다. 이 모델은 충분한 공개 탐색 세션과 신뢰 기준이 생긴 뒤 소규모로 검증합니다.
+
+두 번째는 식당·브랜드의 **투명한 캠페인 상품**입니다. 신메뉴, 지역 행사, 예약 가능 정보처럼 사용자의 의사결정에 실질적으로 도움이 되는 정보를 공개 페이지의 별도 영역에서 제공합니다. 유료 여부는 표기하고, 광고비가 검색·추천·공개 리뷰의 순위를 바꾸지 않게 운영합니다. 따라서 판매 단위는 "상위 노출 보장"이 아니라, 표기된 캠페인의 도달과 행동 결과입니다.
+
+세 번째는 사용자가 거래를 원할 때만 연결하는 **예약·주문 제휴 수수료**입니다. Tasteby가 사용자를 수수료가 높은 식당으로 유도하지 않고, 사용자가 이미 고른 식당에서 예약·주문을 원할 때만 제휴 경로를 제공합니다. 이 수익원은 사용자 행동과 파트너 연동이 검증된 뒤 도입합니다.
+
+추가로, 크리에이터가 자신의 출처·정정·아카이브 관리를 원한다면 공식 큐레이터 페이지와 관리 도구를 유료 또는 수익 분배 방식으로 검토할 수 있습니다. 다만 기존 콘텐츠를 단순 재포장해 과금하지 않고, 크리에이터와 시청자의 재탐색 문제를 실제로 줄이는 경우에만 추진합니다.
+
+초기 12개월의 목표는 매출을 과장하는 것이 아니라, 출처 기반 탐색 → 후보 저장 → 재열람이 반복되는 공개 의사결정 문맥을 검증하는 것입니다. 그 증거가 생긴 뒤 광고·프로모션·제휴를 순서대로 시험해 신뢰를 지키며 매출을 만든다는 계획입니다.
+
+## Q4-1. 아이디어를 어떻게 사업화 하실 계획이신가요? (필수 / 2,000자)
+
+Tasteby는 아이디어 단계에 머물지 않고, 큐레이터 출처·식당·메뉴 탐색, 지도 기반 발견, 회원·찜·공개 리뷰·비공개 메모를 갖춘 서비스를 직접 개발해 운영하고 있습니다. 2026년 9월 기준 등록 채널 6곳, 수집 영상 909편에서 추출해 좌표까지 연결한 식당 500곳을 확보했고, 그중에는 일본 28곳을 포함한 해외 식당 60여 곳이 이미 포함돼 있습니다. 저는 Spring Boot와 Next.js를 중심으로 백엔드·프론트엔드·데이터 파이프라인·배포 환경을 직접 설계하고 구현했습니다.
+
+다음 단계의 사업화는 전국의 모든 맛집을 한꺼번에 늘리는 방식이 아닙니다. `큐레이터 1명 × 지역 1곳 × 메뉴 또는 식사 상황 1개`라는 작은 시장에서 출처 정확도와 실제 사용 행동을 먼저 증명하겠습니다.
+
+**0~3개월에는 수량보다 신뢰도를 먼저 올리겠습니다.** 현재 LLM 검증을 거치지 않은 영상-식당 연결이 1,071건 남아 있습니다. 이를 정리해 출처와 메뉴 연결이 검증된 데이터만 노출하고, 오류 정정 경로와 `발견 → 원본 확인 → 후보 저장`의 행동 계측을 갖추겠습니다. 데이터는 채널을 10곳으로 늘려 식당 1,500곳 규모를 목표로 하되, 정확도 기준을 통과한 것만 셈에 넣겠습니다.
+
+**4~6개월에는 첫 사용자 집단을 만들겠습니다.** 현재는 공개 회원 모집을 시작하지 않았고 제품과 데이터 품질을 먼저 확보하는 단계입니다. 따라서 이 구간의 핵심 과제는 방문자 수를 늘리는 것이 아니라, "영상 속 그 집을 오늘의 후보로"라는 문제를 이미 가진 사용자를 검색·커뮤니티·콘텐츠를 통해 정확한 출처 페이지로 데려와 탐색과 저장이 반복되는지 확인하는 것입니다. 동시에 큐레이터 또는 매니저에게 단순 홍보 요청이 아니라 오래된 콘텐츠의 출처 정리·정정·시청자 재탐색이라는 가치를 제안해 파트너십 3건을 협의하겠습니다.
+
+**7~12개월에는 검증 결과를 확장하겠습니다.** 이미 확보한 일본 28곳은 한국 큐레이터가 현지에서 남긴 기록이므로, 새로운 데이터 수집 없이도 여행 사용 맥락을 검증할 출발점이 됩니다. 여기에 사용자가 찜한 후보를 동행과 함께 고르는 공유 기능을 더하겠습니다. 목표는 MAU 5만과 B2B 캠페인 20건이지만, 이 수치는 단순 방문자 수가 아니라 출처 확인·후보 저장·재열람·공유 수신자의 탐색으로 검증하겠습니다. 첫 매출은 자연 추천과 분리된 공개 문맥 광고 또는 투명한 캠페인 상품에서 만들 계획입니다.
+
+사업화의 핵심 위험은 기술보다 신뢰입니다. 따라서 원본 링크를 보존하고, 협찬·정정 상태를 관리하며, 비공개 메모를 광고 타기팅에 쓰지 않겠습니다. 저는 "더 많은 식당"이 아니라 "다시 쓰이는 신뢰"를 증명하겠습니다.
+
+> 제출 전 사실 확인: 위 실측치(채널 6·영상 909·식당 500·미검증 1,071·해외 60여)는 2026-09-15 기준이다. 제출일에 다시 조회해 갱신한다.
+
+## Q4-2. 책임멘토를 통해 어떤 도움을 받고 싶은가요? (선택 / 2,000자)
+
+저는 Tasteby의 제품과 기술 구현은 직접 추진해 왔지만, 다음 단계에서 필요한 것은 개발 조언보다 **신뢰를 훼손하지 않는 시장 진입과 계약의 기준**입니다. 책임멘토에게 네 가지 도움을 받고 싶습니다.
+
+첫째, 크리에이터 파트너십의 실무입니다. Tasteby는 타인의 콘텐츠를 대신 소비시키는 서비스가 아니라 원본으로 다시 연결하는 서비스여야 합니다. 큐레이터·매니저에게 어떤 가치 제안을 해야 하는지, 출처·초상·인용·협찬 표기를 어떤 계약과 운영 절차로 정리해야 하는지 조언을 받고 싶습니다.
+
+둘째, 초기 B2B 상품의 검증입니다. 식당이나 브랜드가 돈을 낸다고 해서 자연 추천 순위가 바뀌면 Tasteby의 차별점은 사라집니다. 공개 탐색 문맥에서 사용자가 받아들일 수 있는 광고·프로모션의 형태, 가격 이전에 검증해야 할 성과 지표, 첫 고객을 찾는 영업 경로를 함께 설계하고 싶습니다.
+
+셋째, 초기 사용자 획득 전략입니다. 검색·커뮤니티·콘텐츠 중 어떤 좁은 시장에서 출처 탐색과 후보 저장이 실제로 반복되는지, 작은 예산으로 무엇을 먼저 검증해야 하는지에 대한 피드백이 필요합니다. '바이럴'이나 조회 수가 아니라 재방문과 결정 행동으로 판단하는 방법을 배우고 싶습니다.
+
+넷째, 해외 확장 우선순위입니다. 일본 여행 콘텐츠는 분명한 사용 사례이지만, 국내에서 어떤 데이터 품질과 파트너십 기준을 먼저 증명해야 하는지, 다국어·현지 정보·권리 이슈를 어떤 순서로 풀어야 하는지 검토받고 싶습니다.
+
+멘토링을 통해 막연한 인맥 소개보다, 파트너십·수익·유통에서 반복 가능한 의사결정 기준을 얻고 싶습니다. 이를 바탕으로 1인 개발자가 만든 MVP를 신뢰할 수 있는 소비자 서비스와 지속 가능한 사업으로 확장하겠습니다.
+
+## Q5. 나의 아이디어를 소개하는 영상을 링크로 제출해주세요. (선택 / 유튜브 링크만)
+
+**권장: 제출한다.** 75~90초 분량으로 아래 흐름을 사용한다.
+
+1. 0~15초 — "그 영상의 그 식당, 어디였지?"라는 개인 경험과 재검색 장면
+2. 15~40초 — Tasteby에서 큐레이터·식당·메뉴·원본을 연결해 찾는 실제 화면
+3. 40~60초 — 찜과 비공개 메모, 동행과 후보를 고르는 공유 카드의 가치
+4. 60~80초 — AI는 정보를 구조화하고, Tasteby는 사람의 신뢰를 다시 쓰게 한다는 차별점
+5. 80~90초 — 12개월 검증 목표와 멘토링 요청
+
+> 제출 전 입력: `[YouTube URL]`
+> 제작 원칙: Tasteby 자체 화면·직접 제작한 도식만 사용한다. 타인의 유튜브 영상·썸네일·음원을 무단 삽입하지 않는다.
+
+## Q6. 사업 분야를 선택해주세요. (필수 / 드롭다운)
+
+**제출 전 실제 선택지 확인 후 선택한다.**
+
+1순위는 `AI·데이터`다. Tasteby의 사용자 가치는 외식 발견이지만, 영상·글에서 식당 정보를 구조화하고 출처 기반으로 탐색하게 하는 핵심 실행 수단이 AI·데이터이기 때문이다. 해당 선택지가 없으면 2순위는 `플랫폼/O2O`, 그다음은 `푸드테크`다. 예약·배달 거래가 현재 핵심이 아니므로 관광·여행은 일본 베타 이후의 보조 분야로 둔다.
+
+## Q7. 지원자의 현재 창업 여부를 알려주세요. (필수 / 택1)
+
+**법적 사실 확인 전 선택하지 않는다.**
+
+| 확인 결과 | 선택 |
+|---|---|
+| 본인 명의 사업자/법인의 창업일이 기준 기간에 없거나, 기창업자 요건에 해당하지 않음 | `예비창업자` |
+| 창업일이 2019-08-21~2026-08-20이고 Tasteby가 기존 사업과 다른 이종 창업 아이템임 | `기창업자` |
+
+MVP를 개발하거나 도메인을 운영했다는 사실만으로 Q7을 판단하지 않는다. 사업자등록·법인 설립·공고의 세부 기준을 제출 전에 확인한다.
+
+## Q8. 2차 지원서에서는 1차 지원서보다 어떤 점이 더 개선되었나요? (선택 / 재도전 가점)
+
+1차에서는 Tasteby를 "유튜브 맛집 영상에서 AI가 식당 정보를 자동으로 추출해 지도에 모아주는 서비스"로 설명했습니다. 타겟 규모와 기술 구성, 12개월 로드맵을 제시했지만 지원서를 다시 읽어 보니 네 가지가 비어 있었습니다. 제품을 정보 수집 기능으로만 설명했고, 수익 모델이 몇 줄의 나열에 그쳤으며, 목표 수치에 근거가 없었고, 멘토링 문항에는 멘토에게 받고 싶은 도움 대신 자금 사용 계획을 적었습니다.
+
+**첫째, 제품의 정의를 바꿨습니다.** "AI가 맛집을 모아준다"에서 "신뢰하는 큐레이터의 출처로 발견하고, 내 비공개 기록으로 남겨 다음 식사에 다시 쓰고, 필요한 후보만 동행과 공유한다"는 사용 흐름으로 다시 썼습니다. 경쟁력은 수집 기술이 아니라 사용자가 신뢰를 다시 쓰게 만드는 구조에 있다고 판단했기 때문입니다.
+
+**둘째, 수익 모델을 원칙과 순서로 정리했습니다.** 1차의 "유튜버 파트너십·식당 제휴·장기 데이터 사업" 나열 대신, 사용자의 비공개 기록을 판매하지 않고 광고비가 자연 추천 순위를 바꾸지 않는다는 원칙을 먼저 세웠습니다. 그 위에 공개 문맥 광고 → 투명한 캠페인 상품 → 사용자가 원할 때의 거래 제휴 순으로 검증 조건을 붙였습니다.
+
+**셋째, 목표 수치를 실측에서 다시 세웠습니다.** 1차에 적은 "3개월 내 식당 5,000곳"은 현재 500곳 기준으로 10배여서 달성 가능한 계획이 아니었습니다. 2차에서는 채널 6곳·영상 909편·식당 500곳이라는 현재 값을 밝히고, 0~3개월의 과제를 수량 확대가 아니라 아직 검증되지 않은 영상-식당 연결 1,071건을 정리하는 일로 바꿨습니다. 공개 회원 모집을 아직 시작하지 않았다는 사실도 그대로 적었습니다.
+
+**넷째, 멘토링 문항을 질문에 맞게 다시 썼습니다.** 자금 사용 계획 대신 크리에이터 계약 실무, B2B 상품 검증, 초기 사용자 획득, 해외 확장 우선순위 네 가지로 구체화했습니다.
+
+1차가 "무엇을 만들 수 있는가"에 대한 답이었다면, 2차는 "누가 왜 다시 쓰고, 어떤 순서로 검증하며, 어떻게 사업이 되는가"에 대한 답입니다. 그사이 서비스도 멈춰 있지 않았습니다. 지역 표시 계층화, 언급이 적은 식당을 걸러내는 필터, 해외 식당의 국내 전용 예약 버튼 제거처럼 신뢰와 정확도에 관한 개선을 계속 반영해 왔습니다.
+
+## Q9. 아이디어를 사업화 시킬 수 있는 본인의 역량을 알려주세요. (선택 / 2,000자)
+
+Tasteby의 가장 큰 강점 중 하나는 아이디어를 설명하는 데서 멈추지 않고, 제품으로 만들고 운영 가능한 형태로 옮겨 왔다는 점입니다. 저는 1인 풀스택 개발자로서 문제 정의부터 데이터 구조, 백엔드·프론트엔드 구현, AI 처리 파이프라인, 배포 환경까지 직접 설계하고 연결해 왔습니다.
+
+Tasteby에서는 Spring Boot와 Java 기반의 서비스 로직, Next.js 기반의 사용자 화면, Oracle 23ai 벡터 데이터베이스와 Redis를 활용한 데이터 처리 구조를 구성했습니다. 영상·글에서 식당 후보 정보를 구조화하고, 지오코딩·지도·검색으로 사용자가 다시 찾을 수 있게 만드는 파이프라인도 직접 만들었습니다. 기술을 개별 기능으로 쌓기보다, "출처를 찾는다 → 후보를 저장한다 → 방문 뒤 기억한다 → 다음 선택에 다시 쓴다"는 한 사용 흐름이 완성되도록 설계한 경험이 있습니다.
+
+저의 실행 방식은 작은 가설을 빠르게 제품으로 옮기고, 실제 사용 행동으로 다음 우선순위를 정하는 것입니다. 예를 들어 Tasteby의 비공개 메모는 리뷰를 많이 받기 위한 기능이 아니라, 사용자가 좋았던 경험을 다음 외식에 다시 쓰게 하기 위한 기능입니다. 찜 공유 역시 전체 취향을 공개하는 기능이 아니라, 사용자가 고른 후보만 동행과 함께 결정하게 하는 기능으로 분리했습니다. 이처럼 기술의 가능성보다 사용자의 신뢰와 권한을 먼저 설계하는 것이 저의 제품 역량입니다.
+
+또한 혼자서도 기획·개발·운영을 연결할 수 있지만, 모든 것을 혼자 해결하려 하지 않습니다. 크리에이터 계약, 저작권·표기, 초기 B2B 영업, 해외 확장은 멘토와 파트너의 전문성이 필요한 영역으로 분명히 인식하고 있습니다. 저는 빠르게 만들 수 있는 실행력과, 모르는 영역을 검증 가능한 질문으로 바꾸는 운영 방식을 바탕으로 Tasteby를 사업으로 성장시키겠습니다.
+
+> 제출 전 보강 후보: 공개 가능한 직장 경력, 이전 프로젝트, 수상·자격, 서비스 운영 수치가 있으면 사실 확인 뒤 한 단락만 추가한다.
+
+## Q10. 함께하는 팀원이 있다면 본인을 제외한 팀원 명수를 알려주세요. (선택 / 드롭다운)
+
+`팀원 없음`
+
+현재는 1인 창업자로 제품을 직접 개발·운영한다. 다만 법무·크리에이터 파트너십·B2B 영업은 외부 전문가 및 멘토와 보완할 계획이다.
+
+## Q11. 내 아이디어를 사람들에게 자랑해보세요. (선택 / 홈페이지 공개 + 좋아요)
+
+> **맛집 영상을 보다가 "그 집 어디였지?"를 되묻는 사람을 위해 만들었습니다.**
+> Tasteby는 신뢰하는 미식 큐레이터가 언급한 식당과 메뉴를 원본 출처와 함께 찾고, 마음에 드는 곳은 내 찜에 남겨 다음 식사에 다시 쓰게 합니다.
+> 좋은 한 끼를 발견하는 순간과, 좋았던 한 끼를 기억하는 순간을 연결합니다.
+> `www.tasteby.net`
+
+> 게시 전: 실제 접속 URL과 대표 스크린샷을 확인한다.
+
+## Q12. 서약서 동의 (필수)
+
+제출 직전에 아래를 각각 읽고 동의한다.
+
+- 참여 서약서
+- 본인 아이디어 확인 서약서
+- 비밀유지 서약서
+
+## 사진 배분 계획 (전체 10장 제한)
+
+| 문항 | 장수 | 권장 이미지 | 심사에서 보여 줄 사실 |
+|------|---:|---|---|
+| Q2 | 1 | 직접 만든 `영상 속 정보 → Tasteby 출처·지도 → 다음 식사` 흐름 도식 | 왜 이 서비스가 필요한가 |
+| Q3-1 | 3 | 지도 탐색, 식당 상세의 원본/메뉴 근거, 찜·비공개 메모 화면 | 출처·개인 기록의 차별점 |
+| Q4-1 | 2 | 데이터 처리·정정 흐름 도식, 12개월 로드맵 | 이미 만든 것과 다음 검증 순서 |
+| Q9 | 1 | 실제 서비스 아키텍처 또는 개발·배포 흐름 | 1인 실행 역량 |
+| Q11 | 1 | 모바일 또는 데스크톱 대표 화면 한 장 | 공개 소개의 첫 인상 |
+| 예비 | 2 | 수신자 공유 카드, 모바일 탐색 화면 | 심사 코멘트 대응 또는 품질이 높은 화면 교체 |
+
+총 8장을 기본으로 사용하고 2장은 예비로 남긴다. 모든 화면은 제출일 기준 실제 동작·표현과 일치해야 하며, 원본 영상 캡처·타인 음식 사진은 사용권을 확인하지 못하면 사용하지 않는다.