[프롬프트] 프로젝트 아이디어 → 구현 단계 제안 프롬프트 - 최적 프롬프트 레시피
💡 한 줄 요약: "이런 서비스 만들고 싶은데 개발 단계 짜줘"라는 단순 질의 시 발생하는 뻔한 폭포수 기획론 나열, 오버엔지니어링 및 스코프 크립(Scope Creep), 기술 스택 선정 이유(ADR) 부재, 스프린트 단위 마이크로 태스크 결여를 완벽히 차단하고, 프롬프트 1회 입력 및 후속 프롬프트 체이닝(Prompt Chaining)으로 MoSCoW 매트릭스·아키텍처 의사결정(ADR)·데이터 스키마·AI 코딩 툴(Cursor/Claude Code) 실행 지시문까지 일사천리로 도출하는 실전 프롬프트 레시피입니다.
1. 페인포인트 & 작업 목표
- 실제 작업 시나리오: 사이드 프로젝트, 해커톤, 사내 PoC(개념 증명), 혹은 스타트업 신규 MVP를 구상하는 기획 단계에서 러프한 아이디어를 바탕으로 개발에 즉시 착수 가능한 '엔지니어링 로드맵 및 구현 태스크'를 구체화해야 하는 상황.
-
단순 프롬프트 요청 시 발생하는 4대 전형적 문제:
- 뻔한 폭포수 기획론 나열 (Generic Waterfall Theory): "1단계: 요구사항 정의, 2단계: UI 디자인, 3단계: 백엔드 개발, 4단계: 테스트 및 배포"처럼 교과서적인 뜬구름 잡는 일반론만 출력하여 실제 코딩 착수를 가로막음.
- 오버엔지니어링 & 스코프 크립 (Over-Engineering & Scope Creep): 첫 주차부터 Kubernetes 클러스터 구축, Kafka 분산 큐, 마이크로서비스(MSA) 분리, 결제 모듈 등 불필요하게 무거운 스택을 권장하여 프로젝트가 출시 전 피로감으로 좌초됨.
- 기술 스택 선정 이유와 트레이드오프(ADR) 부재: 특정 언어나 DB를 추천하면서도 대안 기술 대비 선택 이유나 출시 속도/러닝 커브에 미치는 영향에 대한 아키텍처 의사결정 근거(Trade-off analysis)가 전무함.
- 스프린트 단위 마이크로 태스크 결여: 개발자가 오늘 당장 터미널을 열고 코딩을 시작해야 할 구체적인 API 엔드포인트 목록, 데이터베이스 엔티티 스키마, 일자별 우선순위가 없어 결국 사용자가 처음부터 다시 쪼개야 함.
-
최종 해결 목표:
- 수석 스타트업 테크 리드 & 솔루션 아키텍트 페르소나 주입: 린 스타트업(Lean Startup) 철학과 프로덕션 엔지니어링 관점을 결합하여 최소 비용·최대 검증 속도의 현실적 로드맵 유도.
- MoSCoW 우선순위 매트릭스 강제: Must-Have(핵심 가치), Should-Have, Could-Have, Won't-Have(초기 절대 개발 금지)를 분리하여 스코프 크립 원천 차단.
- 후속 프롬프트 체이닝(Prompt Chaining) 연계: 1차 로드맵 출력에 그치지 않고, 2차 데이터 스키마/API 명세 정밀 추출, 3차 Cursor/Claude Code 주입용 일자별 실행 지시 프롬프트까지 유기적으로 이어지는 워크플로우 확립.
2. 프롬프트 레시피 비교
3. 실행 결과 비교: 레시피 A vs B vs C 실전 대조
❌ 레시피 A 실행 결과: [단순 질의의 한계] 추상적 폭포수 일반론
### 프로젝트 개발 단계 제안 1. 요구사항 분석: 기능 명세서 작성 및 시장 조사 2. 아키텍처 설계: 클라우드 인프라(AWS/GCP) 및 DB(MySQL/MongoDB) 선정 3. 개발 단계: 백엔드 API 서버 구축 및 프론트엔드 연동 4. 테스트 및 배포: 단위 테스트 작성 후 프로덕션 배포
👉 치명적 결함: 어떤 DB 테이블을 설계하고 어떤 웹훅/API를 파싱해야 하는지 코딩 착수점을 전혀 제공하지 못하며, 기술 선정 이유(ADR)와 스코프 크립 방지 목록이 전무합니다.
⚡ 레시피 B 실행 결과: [실전 사례 1 - DevTools] GitHub PR 자동 요약 봇 (4주 체계적 MVP 로드맵)
2단계의 [레시피 B: 실무 종결형 구현 로드맵 프롬프트]를 실제 프로젝트 아이디어에 적용했을 때 도출되는 프로덕션급 청사진과 후속 연계 프롬프트 체이닝 과정입니다.
개발팀의 코드 리뷰 시간을 단축하기 위해 GitHub PR 생성 시 AI가 변경 사항을 요약하고 위험도를 분석하여 Slack 카드로 전달하는 봇 서비스의 단계별 구체화 및 프롬프트 연계 과정입니다.
1) 1차 프롬프트 주입 예시 (레시피 B 적용)
영문 프롬프트 (복사용)
You are a Principal Software Architect and seasoned Startup Tech Lead specializing in rapid MVP delivery, lean product validation, and production-ready system architecture. Your mission is to transform the following raw project idea into a concrete, battle-tested engineering blueprint and phased implementation roadmap. ### Project Idea & Constraints: - Raw Idea: AI GitHub PR Auto-Reviewer & Slack Notification Bot for small dev teams. When a PR is opened, an AI bot summarizes the Git diff, analyzes potential security vulnerabilities or bugs, and posts an interactive card message to a designated Slack channel. - Target User: Senior Tech Leads & Solo Developers spending too much time reviewing boilerplate PRs. - Target Timeline: 4 Weeks to functional Beta Launch. - Resource / Stack Preference: TypeScript, Fastify/Node.js, PostgreSQL (Supabase), BullMQ/Redis (Upstash), OpenAI API, Railway. ### Execution Guidelines & Deliverable Structure: [Include sections 1 to 5 and Strict Negative Constraints from Recipe B]
한글 프롬프트 (1:1 매칭 복사용)
당신은 신속한 MVP 출시, 린 프로덕트 검증, 프로덕션 레디 시스템 아키텍처 설계를 전문으로 하는 수석 소프트웨어 아키텍트이자 베테랑 스타트업 테크 리드입니다. 당신의 임무는 다음의 가공되지 않은 프로젝트 아이디어를 구체적이고 실전 검증된 엔지니어링 청사진 및 단계별 구현 로드맵으로 변환하는 것입니다. ### 프로젝트 아이디어 및 제약조건: - 가공되지 않은 아이디어: 소규모 개발팀을 위한 AI GitHub PR 자동 리뷰어 및 슬랙 알림 봇. PR이 생성되면 AI 봇이 Git diff를 요약하고, 잠재적 보안 취약점이나 버그를 분석하며, 지정된 슬랙 채널에 인터랙티브 카드 메시지를 전송함. - 타깃 사용자: 보일러플레이트 PR 리뷰에 너무 많은 시간을 소모하는 시니어 테크 리드 및 1인 개발자. - 타깃 일정: 기능성 베타 런칭까지 4주. - 리소스 / 선호 스택: TypeScript, Fastify/Node.js, PostgreSQL (Supabase), BullMQ/Redis (Upstash), OpenAI API, Railway. ### 실행 지침 및 산출물 구조: [레시피 B의 1~5번 섹션 및 엄격한 음의 제약조건을 그대로 포함]
💡 프롬프트 구조 및 핵심 파라미터 해설란
- 구체적 아이디어 제약 명시: 단순 봇이 아니라 'Git Diff 요약 + 보안 취약점 분석 + 슬랙 인터랙티브 카드'라는 구체적인 핵심 동작 메커니즘을 명시하여 모델의 상상력을 실무 스펙으로 한정합니다.
- 현실적 리소스 스택 지정: Fastify, Supabase, BullMQ, Upstash, Railway 등 저지연 웹훅 처리에 최적화된 모던 스택을 선호 스택으로 미리 주입하여 모델이 무거운 AWS 인프라를 권장하지 못하도록 가이드합니다.
2) AI의 1차 출력 결과물 요약
North Star Metric: GitHub PR 생성 후 30초 이내에 위험도(Critical/Medium/Low) 분석 카드가 슬랙 스레드로 성공 전송되는 비율 99% 달성.
| 우선순위 | 기능명 | 세부 엔지니어링 요건 |
|---|---|---|
| Must-Have | GitHub Webhook 검증 | pull_request.opened 수신 및 X-Hub-Signature-256 HMAC-SHA256 검증 |
| Must-Have | Diff 청킹 & LLM 분석 | 락파일 제외, 4K 토큰 분할 청킹, 위험도별 JSON Schema 강제 분석 |
| Should-Have | 슬랙 스레드 질의응답 | 슬랙 댓글로 "@봇 이 함수 설명해줘" 질의 시 Diff 문맥 유지 답변 |
| Won't-Have | 자동 리팩토링 PR 생성 | LLM 환각으로 인한 소스 오염 방지를 위해 초기 MVP 절대 금지 |
| 계층 | 선정 기술 | 대안 기술 | 선정 이유 & 트레이드오프 (MVP 관점) |
|---|---|---|---|
| API / Runtime | Fastify (TypeScript) | FastAPI, Go Fiber | GitHub Octokit / Slack Bolt SDK 공식 TS 지원 우수, 저지연 웹훅 최적 |
| Database | PostgreSQL (Supabase) | MongoDB, DynamoDB | PR 메타데이터 및 토큰 소비량 집계에 관계형 무결성 필수. 비용 $0 |
| Queue | BullMQ + Upstash Redis | AWS SQS, Celery | LLM 10~25초 실행 시 GitHub Webhook 10초 타임아웃 회피 필수 |
3) 후속 연계 프롬프트 1 (Prompt Chaining: 1차 결과 → 2차 DDL & API 명세 추출)
영문 연계 프롬프트 (복사용)
Based on the MoSCoW matrix and ADR we just agreed on for the GitHub PR Reviewer Bot: Act as a Senior Database Architect & API Designer. Generate: 1. Production-ready PostgreSQL DDL with UUID primary keys, foreign keys, constraints, and indexes for `repositories` and `pr_reviews`. 2. A detailed HTTP REST API table for the GitHub Webhook receiver, Slack interactive handler, and health check. Ensure the SQL includes index optimization for querying PR reviews by repository and status. Output purely SQL and Markdown table.
한글 프롬프트 (1:1 매칭 복사용)
방금 우리가 GitHub PR 리뷰 봇에 대해 합의한 MoSCoW 매트릭스와 ADR을 바탕으로: 시니어 데이터베이스 아키텍트이자 API 디자이너로서 역할을 수행하십시오. 다음을 생성하십시오: 1. `repositories` 및 `pr_reviews` 테이블을 위한 UUID 기본키, 외래키, 제약조건, 인덱스가 포함된 프로덕션급 PostgreSQL DDL. 2. GitHub 웹훅 수신부, 슬랙 인터랙티브 핸들러, 헬스체크를 위한 상세 HTTP REST API 명세 표. SQL에 리포지토리별 및 상태별 PR 리뷰 조회를 위한 인덱스 최적화가 반드시 포함되도록 하십시오. 순수한 SQL과 마크다운 표 형식으로만 출력하십시오.
💡 프롬프트 구조 및 핵심 파라미터 해설란
- 선행 컨텍스트 바인딩: 1차 대화에서 도출된 MoSCoW와 ADR을 즉시 참조하여, 별도의 중복 설명 없이 논리적 일관성을 유지한 채 DDL을 생성합니다.
- 출력 포맷 강제: LLM의 사족 설명을 배제하고 터미널이나 마이그레이션 파일에 바로 복사할 수 있는 정제된 코드 및 테이블 형식만 추출합니다.
[AI의 2차 출력 결과 - PostgreSQL DDL]
CREATE TABLE repositories (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
github_repo_id BIGINT UNIQUE NOT NULL,
repo_full_name VARCHAR(255) NOT NULL,
slack_channel_id VARCHAR(64) NOT NULL,
webhook_secret VARCHAR(255) NOT NULL,
is_active BOOLEAN DEFAULT true,
created_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE TABLE pr_reviews (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
repository_id UUID REFERENCES repositories(id) ON DELETE CASCADE,
pr_number INT NOT NULL,
pr_title TEXT NOT NULL,
author_github_login VARCHAR(100) NOT NULL,
commit_sha VARCHAR(64) NOT NULL,
review_status VARCHAR(32) NOT NULL,
risk_level VARCHAR(16),
summary_markdown TEXT,
slack_message_ts VARCHAR(64),
created_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE INDEX idx_pr_reviews_repo_pr ON pr_reviews (repository_id, pr_number);
CREATE INDEX idx_pr_reviews_status ON pr_reviews (review_status);
4) 후속 연계 프롬프트 2 (Prompt Chaining: 2차 결과 → Cursor/Claude Code 주입용 일자별 실행 지시문)
영문 연계 프롬프트 (Cursor Composer / Claude Code 복사용)
Act as a Senior Backend Engineer. Implement Week 1 Day 2 task: Fastify router for GitHub Webhook receiving and HMAC-SHA256 signature verification.
Context & Rules:
1. Framework: Fastify with TypeScript.
2. Secret verification: Verify incoming `x-hub-signature-256` header against `process.env.GITHUB_WEBHOOK_SECRET` using `crypto.timingSafeEqual`.
3. Raw Body Preserving: Use Fastify's `addContentTypeParser` to retain the unparsed raw buffer required for signature hashing.
4. Handling Logic:
- If event header `x-github-event` is `pull_request` and action is `opened` or `synchronize`: extract `pr_number`, `repo_full_name`, `commit_sha`.
- Return HTTP 200 with `{ "received": true }` immediately (under 500ms).
- If signature is invalid, return HTTP 401 Unauthorized with `{ "error": "Invalid HMAC signature" }`.
5. Output the complete file: `src/routes/github-webhook.ts` without any placeholders or missing imports.
한글 프롬프트 (1:1 매칭 복사용)
시니어 백엔드 엔지니어로서 역할을 수행하십시오. Week 1 Day 2 태스크를 구현하십시오: GitHub 웹훅 수신 및 HMAC-SHA256 서명 검증을 위한 Fastify 라우터 작성.
컨텍스트 및 규칙:
1. 프레임워크: TypeScript 기반 Fastify.
2. 시크릿 검증: `crypto.timingSafeEqual`을 사용하여 인입된 `x-hub-signature-256` 헤더를 `process.env.GITHUB_WEBHOOK_SECRET`과 비교 검증할 것.
3. 원본 바디 보존: 서명 해싱에 필수적인 파싱되지 않은 원본 버퍼(Raw Buffer)를 보존하기 위해 Fastify의 `addContentTypeParser`를 사용할 것.
4. 처리 로직:
- 이벤트 헤더 `x-github-event`가 `pull_request`이고 액션이 `opened` 또는 `synchronize`인 경우: `pr_number`, `repo_full_name`, `commit_sha`를 추출할 것.
- 즉시(500ms 이내) HTTP 200과 `{ "received": true }`를 반환할 것.
- 서명이 유효하지 않은 경우, HTTP 401 Unauthorized와 `{ "error": "Invalid HMAC signature" }`를 반환할 것.
5. 어떠한 플레이스홀더나 누락된 import 없이 완전한 파일 `src/routes/github-webhook.ts`를 출력할 것.
💡 프롬프트 구조 및 핵심 파라미터 해설란
- 단일 일자별 마이크로 태스크 한정: 전체 백엔드를 한꺼번에 요청하지 않고 Week 1 Day 2의 웹훅 수신 라우터 하나만 명확히 지정함으로써 AI의 토큰 낭비와 환각을 방지합니다.
- 보안/엣지케이스 규칙 사전 명시: 타이밍 공격 방지를 위한 `timingSafeEqual`, Fastify 고유의 Raw Body 파싱 규칙, HTTP 200/401 응답 조건을 명시하여 추가 수정 없는 프로덕션 코드를 확보합니다.
5) 🛠️ 독자 따라하기: 4단계 프롬프트 체이닝 워크플로우 (Step-by-Step Prompt Flow)
- Step 1: 1차 아이디어 구체화 프롬프트 실행: [레시피 B]에 본인의 아이디어와 4주 이내의 타깃 일정을 채워 Claude 3.5 Sonnet 또는 GPT-4o에 전송합니다.
-
Step 2: MoSCoW 필터링 피드백 프롬프트: AI가 출력한 MoSCoW 중 초기 검증에 불필요한 기능은 피드백 프롬프트로 정제합니다.
[영문 피드백 프롬프트] "The current Must-Have list contains [FEATURE_X]. As an early MVP, move [FEATURE_X] to Won't-Have. Instead, ensure the core loop of [KILLER_ACTION] is as lean as possible. Re-adjust the Week 1-2 schedule accordingly."
[한글 1:1 매칭 프롬프트] "현재 Must-Have 목록에 [기능_X]가 포함되어 있습니다. 초기 MVP이므로 [기능_X]를 Won't-Have로 이동하십시오. 대신 [킬러_액션]의 핵심 루프가 가능한 한 린(Lean)하게 유지되도록 하십시오. 그에 맞추어 1-2주차 일정을 재조정하십시오."
- Step 3: 후속 연계 프롬프트 1 실행: 대화창에서 [후속 연계 프롬프트 1]을 입력하여 DDL과 API 명세를 정밀 추출한 뒤
docs/ARCHITECTURE.md에 저장합니다. - Step 4: AI 코딩 툴(Cursor/Claude Code) 실행 지시문 주입: 오늘 진행할 1개 태스크를 골라 [후속 연계 프롬프트 2] 형식으로 AI 코딩 툴에 전달하여 완성형 코드를 생성합니다.
🚀 레시피 C 실행 결과: [실전 사례 2 - B2C SaaS] AI 기반 북마크 & 아티클 태깅 서비스 (48시간 속도전 MVP)
2단계의 [레시피 C: 1인 풀스택 48시간 속도전 MVP 특화 프롬프트]를 적용하여 주말 48시간 내에 검증 가능한 최소 스펙을 도출하고 첫 커밋까지 연결하는 속도전 결과물입니다.
웹 서핑 중 저장한 URL의 본문 텍스트를 파싱하고 AI가 요약과 태그를 생성하며 시맨틱 검색을 지원하는 초경량 B2C 서비스의 속도전 구체화 과정입니다.
1) 1차 프롬프트 주입 예시 (레시피 C 적용)
영문 프롬프트 (복사용)
You are a High-Velocity Indie Hacker and Elite Full-Stack Prototyper. My objective is to build and deploy a working, public MVP within 48 HOURS based on the idea below. ### Idea Summary: AI-powered Developer Bookmark & Article Auto-Tagging SaaS. Users save technical blog URLs via a browser popup; an AI pipeline extracts clean text, generates a 2-sentence summary, tags technologies (e.g., React, Rust, Docker), and stores 1536-dim embeddings into Supabase pgvector for semantic natural language search. ### Output Requirements: 1. THE "ONE KILLER FEATURE" SCOPE: Ruthlessly strip away secondary features. 2. ZERO-CONFIG TECH STACK: Pick the fastest time-to-first-commit stack. 3. 48-HOUR TIME-BLOCK EXECUTION SCHEDULE: Broken down into 5 time windows. 4. IMMEDIATE NEXT PROMPT: The exact prompt to generate the foundation database & RPC logic.
한글 프롬프트 (1:1 매칭 복사용)
당신은 초고속 인디 해커이자 엘리트 풀스택 프로토타이퍼입니다. 나의 목표는 아래 아이디어를 바탕으로 48시간 이내에 실제로 동작하고 공개 배포되는 MVP를 구축하는 것입니다. ### 아이디어 요약: AI 기반 개발자 북마크 및 아티클 자동 태깅 SaaS. 사용자가 브라우저 팝업을 통해 기술 블로그 URL을 저장하면, AI 파이프라인이 본문 텍스트를 정제 추출하고, 2줄 요약을 생성하며, 기술 태그(예: React, Rust, Docker)를 부착하고, 시맨틱 자연어 검색을 위해 1536차원 임베딩을 Supabase pgvector에 저장함. ### 출력 요구사항: 1. "원 킬러 피처 (One Killer Feature)" 스코프: 부차적인 기능을 무자비하게 쳐낼 것. 2. ZERO-CONFIG 테크 스택: 첫 커밋까지의 시간이 가장 빠른 스택을 선정할 것. 3. 48시간 타임블록 실행 스케줄: 5개 시간대 윈도우로 분할할 것. 4. 즉시 실행할 후속 프롬프트: 기반 데이터베이스 및 RPC 로직을 생성할 수 있는 정확한 프롬프트를 제공할 것.
💡 프롬프트 구조 및 핵심 파라미터 해설란
- 단일 킬러 파이프라인 명시:
URL 수집 → 정제/요약/태깅 → pgvector 시맨틱 검색이라는 코어 루프만 명시하여 AI가 사용자 인증 옵션이나 관리자 기능 등 48시간 내에 불필요한 부가 기능을 일체 제안하지 못하도록 통제합니다.
2) AI의 1차 출력 결과물 요약
- One Killer Feature:
URL 입력 → 3초 내 2줄 요약 & 기술 태그 3개 생성 → 자연어 검색 시 북마크 즉시 발견. 유료 결제 및 협업 워크스페이스 전면 배제. - Zero-config 테크 스택: Next.js 15 (App Router) + Supabase (pgvector) + OpenAI API + Vercel 원클릭 배포.
- 48시간 타임블록: 00-06h(DB/pgvector/스캐폴딩) → 06-18h(요약/임베딩 파이프라인) → 18-30h(단일 검색창 대시보드) → 30-40h(유사도 튜닝 및 예외처리) → 40-48h(Vercel 배포 및 피드백 수집).
3) 후속 연계 프롬프트 (Prompt Chaining: 첫 30분 실행 집중 프롬프트)
영문 연계 프롬프트 (복사용)
Act as a Senior PostgreSQL & Vector Database Specialist. Write the complete, battle-tested SQL script for Supabase to support our 48-hour Bookmark MVP: 1. Enable the `vector` extension. 2. Create `bookmarks` table with `id (UUID)`, `user_id (UUID)`, `url (TEXT)`, `title (TEXT)`, `ai_summary (TEXT)`, `tags (TEXT[])`, `embedding (vector(1536))`, and `created_at`. 3. Create an HNSW index on `embedding` using cosine distance (`vector_cosine_ops`) with m=16, ef_construction=64. 4. Create a Postgres function (RPC) named `match_bookmarks` that accepts `query_embedding vector(1536)`, `match_threshold float`, `match_count int`, and `p_user_id uuid` and returns ranked matching bookmarks. Output purely executable SQL with concise comments.
한글 프롬프트 (1:1 매칭 복사용)
시니어 PostgreSQL 및 벡터 데이터베이스 전문가로서 역할을 수행하십시오. 우리의 48시간 북마크 MVP를 지원하기 위해 Supabase에서 즉시 실행 가능한 검증된 완성형 SQL 스크립트를 작성하십시오: 1. `vector` 확장 모듈을 활성화할 것. 2. `id (UUID)`, `user_id (UUID)`, `url (TEXT)`, `title (TEXT)`, `ai_summary (TEXT)`, `tags (TEXT[])`, `embedding (vector(1536))`, `created_at` 컬럼을 포함하는 `bookmarks` 테이블을 생성할 것. 3. 코사인 거리(`vector_cosine_ops`), m=16, ef_construction=64 파라미터를 사용하여 `embedding` 컬럼에 HNSW 인덱스를 생성할 것. 4. `query_embedding vector(1536)`, `match_threshold float`, `match_count int`, `p_user_id uuid`를 입력받아 유사도 순으로 일치하는 북마크를 반환하는 `match_bookmarks`라는 이름의 Postgres 함수(RPC)를 생성할 것. 간결한 주석과 함께 순수하게 실행 가능한 SQL 코드만 출력하십시오.
💡 프롬프트 구조 및 핵심 파라미터 해설란
- HNSW 인덱스 파라미터 고정 (m=16, ef_construction=64): Supabase 무료 티어 메모리 한도 내에서 가장 빠른 검색 성능과 적절한 빌드 인덱스 품질을 보장하는 최적 표준값을 모델에 직접 지시합니다.
- RPC 함수 인터페이스 명시: 백엔드 서버 없이도 Next.js 클라이언트에서
supabase.rpc('match_bookmarks', { ... })호출 한 줄로 고속 벡터 유사도 검색이 가능하도록 스키마를 단번에 완성합니다.
[AI의 출력 SQL 결과 - Supabase pgvector & RPC]
-- Supabase pgvector 활성화 및 유사도 검색 RPC
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE bookmarks (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
url TEXT NOT NULL,
title TEXT NOT NULL,
ai_summary TEXT,
tags TEXT[] DEFAULT '{}',
embedding vector(1536),
created_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE INDEX idx_bookmarks_embedding ON bookmarks
USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64);
CREATE OR REPLACE FUNCTION match_bookmarks (
query_embedding vector(1536), match_threshold float, match_count int, p_user_id uuid
)
RETURNS TABLE (id uuid, url text, title text, ai_summary text, tags text[], similarity float)
LANGUAGE plpgsql AS $$
BEGIN
RETURN QUERY
SELECT b.id, b.url, b.title, b.ai_summary, b.tags, 1 - (b.embedding <=> query_embedding) AS similarity
FROM bookmarks b
WHERE b.user_id = p_user_id AND 1 - (b.embedding <=> query_embedding) > match_threshold
ORDER BY b.embedding <=> query_embedding
LIMIT match_count;
END;
$$;
4) 🛠️ 독자 따라하기: 초고속 3단계 프롬프트 워크플로우 (Step-by-Step Prompt Flow)
- Step 1: 속도전 제약 프롬프트 주입: [레시피 C]를 통해 48시간 내에 작동 가능한 단일 킬러 피처와 Zero-config 스택을 확정합니다.
-
Step 2: Won't-Have 쳐내기 피드백 프롬프트: 출력된 스케줄 중 12시간 이상 걸릴 것 같은 작업이 보이면 피드백 프롬프트로 쳐냅니다.
[영문 Won't-Have 쳐내기 프롬프트] "Hour 18-30 has too much scope. Remove the folder organization feature and tag edit modal completely. We only support auto-generated tags and a single search bar. Re-allocate those hours to rock-solid vector search response times."
[한글 1:1 매칭 프롬프트] "18~30시간의 스코프가 너무 큽니다. 폴더 정리 기능과 태그 편집 모달을 완전히 제거하십시오. 우리는 자동 생성된 태그와 단일 검색창만 지원합니다. 해당 시간들을 탄탄한 벡터 검색 응답 시간 확보에 재할당하십시오."
- Step 3: 첫 커밋 지시 프롬프트 주입: [후속 연계 프롬프트]로 데이터베이스 RPC와 핵심 Server Action 코드를 즉시 도출해 첫 커밋 시간을 30분 이내로 단축합니다.
4. 메커니즘 심층 분석 (왜 차이가 나는가?)
1) Startup Tech Lead 페르소나 주입 (Attention Narrowing)
"개발 계획 짜줘"라고 질의하면 LLM은 위키피디아의 소프트웨어 공학 개론이나 전통 SI 폭포수 방법론을 검색해 일반론을 출력합니다. 반면 "Principal Software Architect and Startup Tech Lead specializing in rapid MVP delivery" 페르소나를 부여하면 어텐션이 '출시 속도', '단일 핵심 가치 검증', '최신 경량 스택(Supabase, Vercel, Upstash)'으로 집중됩니다.
2) MoSCoW 매트릭스 & 음의 제약조건 (Negative Constraints)
프로젝트 실패의 제1 원인은 기능 부족이 아니라, 출시 전 너무 많은 기능을 넣으려다 지쳐 쓰러지는 스코프 크립입니다. Won't-Have 섹션과 Reject premature scaling 제약조건을 강제함으로써 첫 주차부터 분산 카프카나 쿠버네티스, 복잡한 빌링 시스템을 도입하려는 모델의 환각을 원천 차단합니다.
3) Prompt Chaining의 토큰 낭비 방지 및 정밀도 극대화 원리
단 한 번의 거대한 프롬프트로 기획, 아키텍처, 데이터 모델, 전체 코드를 한꺼번에 뽑아내려 하면 모델의 출력 토큰 상한에 도달해 핵심 로직이 // TODO: implement later로 생략됩니다. [1차 로드맵 & MoSCoW] → [2차 DDL & API 명세] → [3차 단일 마이크로 태스크 구현 지시문]으로 프롬프트를 체이닝할 때 컨텍스트 윈도우 희석 없이 최고 순도의 프로덕션 코드를 확보할 수 있습니다.
5. 실전 응용 팁 & 플레이스홀더 템플릿
💡 즉시 재사용 가능한 범용 플레이스홀더 템플릿
영문 템플릿 (복사용)
You are a Principal Software Architect and Startup Tech Lead.
Transform the following idea into an actionable 4-week MVP engineering plan:
- Raw Idea: {YOUR_PRODUCT_IDEA}
- Target User: {PRIMARY_USER_PERSONA}
- Timeline: {WEEKS_OR_DAYS_AVAILABLE}
- Preferred Tech Stack: {PREFERRED_LANG_OR_FRAMEWORKS}
- Budget Constraints: {FREE_TIER_OR_PAID_INFRA}
Output strictly with:
1. Core Value Metric (North Star)
2. MoSCoW Scoping Matrix (Must/Should/Could/Won't-Have)
3. Architectural Decision Record (ADR) Table for Tech Stack
4. PostgreSQL DDL Schema for top 3 entities
5. Weekly Phased Roadmap with Definition of Done (DoD)
한글 템플릿 (1:1 매칭 복사용)
당신은 수석 소프트웨어 아키텍트이자 스타트업 테크 리드입니다.
다음 아이디어를 실행 가능한 4주 MVP 엔지니어링 계획으로 변환하십시오:
- 가공되지 않은 아이디어: {당신의_제품_아이디어}
- 타깃 사용자: {핵심_사용자_페르소나}
- 일정: {가용_주차_또는_일수}
- 선호 테크 스택: {선호_언어_또는_프레임워크}
- 예산 제약조건: {무료_티어_또는_유료_인프라}
반드시 다음 형식으로만 엄격히 출력하십시오:
1. 핵심 가치 지표 (North Star)
2. MoSCoW 스코핑 매트릭스 (Must/Should/Could/Won't-Have)
3. 테크 스택 선정을 위한 아키텍처 의사결정 기록 (ADR) 비교 표
4. 상위 3개 핵심 엔티티를 위한 PostgreSQL DDL 스키마
5. 완료의 정의 (DoD)가 포함된 주차별 단계별 로드맵
💡 프롬프트 구조 및 변수 가이드 해설란
{YOUR_PRODUCT_IDEA}: 만들고자 하는 서비스의 한 줄 설명과 핵심 사용자 행동.{PRIMARY_USER_PERSONA}: 이 서비스로 가장 큰 효용을 얻는 구체적 사용자 계층.{WEEKS_OR_DAYS_AVAILABLE}: '2주', '4주' 등 현실적인 타깃 일정 (짧게 설정할수록 오버엔지니어링 억제).{PREFERRED_LANG_OR_FRAMEWORKS}: 익숙한 언어/프레임워크 (예: TypeScript, Next.js, Python FastAPI).{FREE_TIER_OR_PAID_INFRA}: $0 인프라(무료 티어 위주)인지 유료 인프라 허용인지 여부.
실무 튜닝 팁: 모델이 지나치게 일반론적인 답변을 낼 때는
{FREE_TIER_OR_PAID_INFRA}에 "무료 티어만 사용(Supabase free tier, Vercel free tier)하며 결제 모듈은 일체 배제"라는 제약을 강제하면 훨씬 더 린(Lean)하고 구체적인 DDL과 로드맵이 도출됩니다.
⚙️ AI 코딩 도구(Cursor / Claude Code) 연계 팁
- PRD.md 및 .cursorrules로의 직접 안착: 레시피 B의 결과물로 생성된 MoSCoW 매트릭스와 데이터 스키마를
docs/PRD.md에 저장하고, Cursor Composer에서@PRD.md Week 1 Day 2 태스크를 구현해줘라고 프롬프팅하면 일관된 스키마 규칙을 유지할 수 있습니다. - 멀티턴 스프린트 체이닝: 4주 계획을 얻은 뒤 한 번에 전체 코드를 요청하지 말고,
Now, act as the Senior Backend Engineer. Write the complete Fastify router code for Week 1 Day 2.와 같이 일자별 마이크로 태스크 단위로 끊어서 요청할 때 결함 없는 프로덕션 코드를 얻을 수 있습니다.
