너는 제품 기획자, 시니어 풀스택 개발자, UI/UX 디자이너, QA 엔지니어의 역할을 함께 수행한다.

지금부터 내가 제공한 기획서와 현재 프로젝트, 참고 소스코드를 검토하고, 필요한 기획 수정부터 실제 구현, 서버 실행, 브라우저 QA, 배포까지 하나의 연속된 작업으로 진행하라. 기획 검토나 구현 계획만 제출하고 작업을 끝내지 마라.

1. 작업 배경과 목표

나는 Claude Fable 5.1을 이용해 “Can I Vibecode It?”의 한국판을 개발하기 위한 기획서를 작성해 두었다. 원본 서비스의 소스코드는 GitHub 공개 저장소에 공개되었거나 공유된 것으로 알고 있으며, 이 프롬프트 마지막에 당시의 첫 번째 원샷 제작 프롬프트를 그대로 첨부했다.

원본 프롬프트는 출발점이다. 내가 만들 서비스는 원본을 한국어로 번역한 디렉터리에 머무르지 않고, 한국 사용자가 다양한 소프트웨어의 대체 가능성을 확인하고, 직접 만들어 보고, 제작 과정과 결과를 공유하는 서비스여야 한다.

서비스의 핵심 질문은 “이 도구에서 내가 실제로 사용하는 기능을 AI 코딩으로 직접 만들어 대체할 수 있을까?”이다.

원본의 도구별 판정, 제작 프롬프트, 대체할 때 잃는 기능, 기존 대안 링크, 투표, 비용 티커, 검색, SEO, 공유 기능을 유지하면서 한국 서비스에 맞게 확장하라. 회원가입과 커뮤니티를 포함해 실제 사용자가 이용할 수 있는 수준으로 구현하라.

BM은 추후 설계한다. 이번에는 결제, 유료 구독, 유료 게시물, 광고 상품, 수익 배분, 포인트 결제 등의 수익화 기능을 선행 구현하지 않는다. 추후 확장을 방해하지 않는 구조만 마련하고, 현재 범위를 불필요한 추상화로 복잡하게 만들지 마라.

2. 입력 자료 검토와 요구사항 우선순위

작업 전에 다음 자료를 확인하라.

* 내가 첨부하거나 프로젝트에 넣어 둔 기획서와 참고 문서 전체.
* 현재 저장소의 코드, 디렉터리 구조, README, 설정, 데이터, 테스트, 기존 구현 상태.
* 프로젝트에 적용되는 AGENTS.md 등의 작업 지침.
* 제공된 원본 GitHub 저장소와 실제 라이선스, 원본 서비스에서 확인 가능한 기능.
* 이 프롬프트 본문과 마지막에 첨부한 원본 제작 프롬프트.

내가 GitHub URL을 제공했다면 해당 저장소부터 확인하라. URL이 없고 검색이 가능하다면 원본 후보를 조사하고, 제작자·공식 사이트·커밋 기록·라이선스 등을 근거로 원본인지 판단하라. 검색으로 찾은 재배포 저장소를 확인 없이 공식 원본이라고 단정하지 마라.

원본 코드를 확보하지 못하더라도 접근 가능한 기획서와 이 프롬프트를 바탕으로 구현을 계속하라. 확인하지 못한 소스나 문서를 읽었다고 보고하지 마라.

기획서가 보이지 않으면 첨부 파일과 프로젝트 문서를 확인한 후, 미제공 사실과 구현에 필요한 가정을 기록하고 이 프롬프트를 기준으로 작업을 진행하라. 기획서를 임의로 읽었다고 가정하지 마라.

요구사항 충돌은 다음 순서로 해결하라.

1. 내가 현재 명시한 목표와 이 프롬프트의 확장 요구사항.
2. 내가 제공한 한국판 기획서의 구체적인 기능과 서비스 방향.
3. 현재 프로젝트에서 유지할 이유가 있는 구현과 설계.
4. 원본 서비스 및 원본 제작 프롬프트.

특히 원본의 “No accounts”는 이번 요구사항의 회원가입·로그인·커뮤니티 기능으로 대체한다. “No payments”와 “No tracking beyond first-party analytics”는 유지한다. SaaS로만 한정한 범위는 설치형 프로그램, 무료 도구, 오픈소스, 업무용 소프트웨어까지 확장한다.

그 외 원본 요구사항은 명시적 충돌이 없는 한 삭제하지 마라. 기획서의 기능도 난도가 높거나 작업량이 많다는 이유로 임의 삭제하거나 다음 버전으로 미루지 마라.

검토 결과에는 다음을 남겨라.

* 유지한 요구사항.
* 충돌하거나 누락된 요구사항.
* 수정한 내용과 이유.
* 자료가 없어 합리적으로 가정한 내용.
* 각 요구사항이 연결되는 화면, API, 데이터 구조, QA 항목.
* 이번에 구현할 범위와 외부 설정 후 검증할 범위.

검토 결과와 수정된 기획서를 실제 문서로 저장하고, 검토 완료 승인을 기다리지 말고 구현을 이어가라.

3. 중단 없이 실행하는 원칙

이 작업은 기획 검토 → 기획 보완 → 구현 → 데이터 구축 → 서버 실행 → 실제 브라우저 QA → 발견한 오류 수정 → 재검증 → 가능한 배포까지 이어지는 하나의 작업이다.

* “진행할까요?”, “다음 단계에서 구현하겠습니다”, “나머지는 직접 연결하세요” 등의 말로 작업을 끊지 마라.
* 색상, 서비스 가칭, 폴더 구조, 기본 페이지 크기 등 되돌릴 수 있는 선택은 기존 기획을 우선하고, 없으면 합리적으로 결정한 뒤 기록하라.
* 기능 수나 데이터 수를 임의로 축소해 데모나 화면 목업만 만들지 마라.
* 진행 상황은 간결하게 공유하되, 진행 보고를 최종 결과처럼 제출하지 마라.
* 기존 사용자 코드와 데이터를 보존하고, 실제 사용자 데이터에 파괴적인 변경을 가하지 마라.
* 작업 도중 실패한 명령, 빌드 오류, 브라우저 오류는 원인을 찾아 수정하고 이어서 진행하라.
* 컨텍스트가 부족해지면 진행 상황, 결정 사항, 다음 작업, 실패한 검증을 문서에 기록해 이어갈 수 있게 하라. 자발적으로 “여기까지”를 완료로 처리하지 마라.
* 실행 환경의 하드 제한, 필요한 권한 부재, 외부 서비스 장애는 우회하거나 숨기지 마라. 영향을 받는 작업만 구분하고 진행 가능한 작업을 모두 마쳐라.
* 환경변수 부재는 해당 외부 연동의 실제 테스트를 보류할 이유이지, 나머지 기능 구현과 QA를 중단할 이유가 아니다.
* 실제로 수행하지 못한 배포나 검증을 완료했다고 보고하지 마라.

4. 한국판 제품 방향과 디자인

대상 사용자는 한국의 개발자, 바이브코딩 입문자, 1인 사업자, 스타트업 구성원, 크리에이터, 업무 도구를 직접 만들고 싶은 일반 사용자다.

기존 기획서에 서비스명과 브랜드가 있으면 이를 사용하라. 없으면 적절한 한국어 가칭을 정하고, 이름·도메인·소개 문구를 한 곳에서 변경할 수 있게 하라.

화면, 폼, 오류 메시지, 빈 상태, 도움말, SEO 문구, 이메일 템플릿은 자연스러운 한국어를 기본으로 작성하라. 서비스의 공식 영문명과 개발 도구 이름은 검색성을 위해 병기할 수 있다.

원본의 개발 도구 같은 분위기를 유지하라.

* 기본은 CRT를 연상시키는 검정 계열 다크 모드, 대안은 종이 같은 라이트 모드.
* 강한 브랜드 강조색은 형광 초록으로 통일.
* YES는 초록, KINDA는 황색, NOT REALLY는 빨강으로 의미를 전달하되, 색상만으로 상태를 구분하지 않도록 한국어 설명과 레이블을 제공.
* 영문 제목에는 Space Grotesk, 코드와 숫자에는 JetBrains Mono, 한국어에는 가독성 좋은 한글 폰트를 적용.
* 과도한 장식, 무의미한 카드 반복, 가짜 활동 수치로 화면을 채우지 마라.
* 모바일에서도 긴 도구명, 한글 제목, 코드, 표, 티커가 깨지지 않게 하라.
* 다크·라이트 모드 선택을 유지하고 초기 렌더링의 테마 깜빡임을 줄여라.
* 애니메이션은 숫자 롤링, 가격 테이프, hover lift, press scale, 복사 확인, 스크롤 등장 등에 절제해서 적용.
* prefers-reduced-motion을 존중하고, 움직임을 끄더라도 정보가 사라지지 않게 하라.
* 키보드 탐색, 포커스, 폼 레이블, 오류 안내, 색 대비를 고려하라.

5. 기술 구조와 데이터 영속성

기본 스택은 원본 요구사항을 따른다.

* Astro의 server output.
* Node adapter.
* better-sqlite3와 SQLite.
* 클라이언트 프레임워크 없이 vanilla JavaScript로 인터랙션 구현.
* 서버 렌더링을 기본으로 하고, 클라이언트 JavaScript가 필요한 부분만 점진적으로 강화.

기획서나 기존 저장소에 이미 다른 스택을 선택한 명확한 이유가 있다면 기능과 운영 요구에 비추어 검토하라. 변경이 꼭 필요할 때만 근거와 영향 범위를 문서화하고 변경하며, 취향만으로 프레임워크를 교체하지 마라.

현재 선택한 버전에 맞는 공식 문서를 확인하고 호환되는 의존성을 사용하라. 패키지 매니저와 lockfile을 통일하고, 재현 가능한 설치·개발·빌드·시작 명령을 제공하라.

앱·도구의 편집 가능한 기본 콘텐츠는 data/apps/ 아래의 도구별 JSON 파일 한 개를 원본으로 유지하라. 계정, 세션, 투표, 게시글, 댓글, 좋아요, 북마크, 알림, 신고, 대기자 명단 등 런타임 데이터는 DB에 저장하라.

* 데이터 스키마 검증, 마이그레이션, 초기 데이터 동기화, 필요한 인덱스와 고유 제약을 구현.
* 초기 데이터 스크립트를 반복 실행해도 중복 데이터나 초기화가 발생하지 않도록 구성.
* 운영 데이터에 테스트 데이터가 섞이지 않도록 테스트 DB와 seed를 분리.
* 회원이나 게시물 삭제, 도구 메타데이터 갱신 시 참조 관계와 통계가 깨지지 않도록 설계.
* 데이터는 서버 재시작 후에도 유지되어야 하며, localStorage만으로 핵심 데이터를 저장하지 말 것.
* SQLite의 동시 쓰기, 트랜잭션, busy timeout, 백업·복원, 실제 운영 프로세스 수를 고려.
* better-sqlite3를 실행할 수 있는 Node 런타임과 영속 디스크를 확보할 수 있는 배포 구조를 선택.
* 임시 파일시스템에 DB를 두고 영속성이 확보되었다고 보고하지 말 것.
* 영속 디스크가 없는 배포 대상이라면 적합한 저장소로 변경하거나 호환되는 호스팅을 선택하고, 그 이유와 마이그레이션 방식을 기록.

6. 도구 디렉터리의 범위와 초기 데이터

SaaS라는 표현에 범위를 가두지 마라. 웹 서비스, 데스크톱 프로그램, 로컬 퍼스트 도구, 무료 소프트웨어, 오픈소스, 일회성 구매 도구, 업무용 프로그램을 포함하라.

초기 정식 카탈로그는 실재하는 서로 다른 도구 100개 이상, 카테고리 12개 이상으로 구성하라. 한국 서비스와 글로벌 서비스를 함께 포함하고, Slack, Notion, Obsidian, Microsoft Excel은 반드시 포함하라.

다음 목록은 조사 후보이며, 현재 운영 여부·이름·기능·가격을 확인한 뒤 반영하라. 후보에 들어 있다는 이유만으로 “한국에서 많이 쓰는 도구”라고 단정하지 마라.

* 협업·채팅: Slack, Microsoft Teams, Discord, Mattermost, Google Chat, 네이버웍스, 카카오워크, 잔디.
* 문서·노트·지식관리: Notion, Obsidian, Evernote, OneNote, Logseq, Joplin, Roam Research, Craft, Bear, UpNote.
* 오피스·업무 문서: Microsoft Word, Microsoft Excel, Microsoft PowerPoint, Google Docs, Google Sheets, Google Slides, 한컴오피스, 폴라리스 오피스.
* 프로젝트·할 일: Jira, Trello, Asana, Linear, ClickUp, monday.com, Basecamp, Todoist, TickTick, 플로우, 두레이.
* 데이터·스프레드시트·대시보드: Airtable, Coda, Smartsheet, Baserow, NocoDB, Grist, Rows, Power BI, Tableau, Looker Studio, Metabase, Redash.
* 화이트보드·다이어그램: Figma, FigJam, Miro, Whimsical, Excalidraw, Lucidchart, diagrams.net, tldraw.
* 디자인·이미지: Canva, 미리캔버스, 망고보드, Adobe Photoshop, Adobe Illustrator, Affinity Photo, Photopea, Fotor.
* 영상·방송·오디오: OBS Studio, Streamlabs Desktop, DaVinci Resolve, Adobe Premiere Pro, CapCut, 브루, Audacity, Adobe Audition, Descript, Loom.
* 폼·설문: Google Forms, Microsoft Forms, Typeform, Tally, Jotform, SurveyMonkey, 네이버 폼.
* 자동화·연동: Zapier, Make, n8n, IFTTT, Pipedream, Power Automate, Activepieces.
* 고객관리·고객지원·메일: HubSpot, Salesforce, Zendesk, Intercom, Freshdesk, 채널톡, 스티비, Mailchimp, Brevo.
* 일정·예약·시간관리: Calendly, Cal.com, Google Calendar, 네이버 캘린더, Doodle, When2meet, Toggl Track, Clockify.
* 파일·클라우드: Dropbox, Google Drive, OneDrive, Box, pCloud, Synology Drive, 네이버 MYBOX.
* 개발·API 도구: GitHub, GitLab, Bitbucket, Postman, Insomnia, Bruno.
* 웹사이트·노코드: Webflow, Framer, Wix, WordPress, 아임웹, 카페24, 식스샵, Softr, Glide.

제품 이름만 바꾼 중복 항목이나 무의미한 플랜 분리로 개수를 채우지 마라. 출처 검증이 불가능한 항목은 운영 카탈로그와 분리하고, 검증된 데이터인 것처럼 표출하지 마라.

각 도구에는 최소한 다음 기존 필드를 유지하라.

slug, name, domain, category, priceMonthly, verdict, whatYouLose[], priorArt[], prompt, notes.

확장을 위해 다음 정보를 표현할 수 있도록 스키마를 보완하라.

* 한글 표시명, 검색 별칭, 요약, 태그, 공식 URL.
* 도구 유형과 실행 환경: SaaS, desktop, local-first, open-source 등.
* 가격 모델: free, freemium, subscription, one-time, usage-based, contact-sales 등.
* 원래 통화, 선택한 기준 플랜, 사용자당 과금 여부, 최소 좌석, 청구 주기.
* 실제 월 결제액과 연 결제 기준 월 환산액의 구분.
* 가격 출처 URL, 확인 날짜, 환율 출처·기준일·환산값이 필요한 경우 그 정보.
* 대체 대상으로 삼은 구체적인 사용 사례와 기능 범위.
* 구현 가능한 핵심 기능, 대체하기 어려운 기능, 예상 난도.
* verdict의 근거, 판정 확인일, 검증 수준.
* 필요한 외부 서비스·API·환경변수와 예상되는 운영 부담.
* 에이전트별 제작 프롬프트 또는 공통 프롬프트와 실행 지침.
* 관련 도구, 4개 FAQ, prior art의 공식 링크와 확인 가능한 라이선스.
* 프롬프트 버전과 변경 이력.

확인되지 않은 가격은 null 또는 “확인 필요”로 다루고, 무료를 의미하는 0과 혼동하지 마라. 일회성 구매 가격을 근거 없이 월 구독료로 환산하지 마라.

7. 대체 가능성 판정과 도구별 프롬프트 품질

verdict의 원래 값 yes, kinda, no를 유지하고 한국어 설명을 제공하라.

* YES / 대체 가능: 명시한 개인·소규모 사용 사례의 핵심 기능을 합리적인 범위에서 직접 구현할 수 있음.
* KINDA / 일부 대체 가능: 핵심 흐름 일부는 구현 가능하지만 협업, 연동, 안정성, 품질 등의 손실이 의미 있게 존재함.
* NOT REALLY / 대체 어려움: 주요 가치가 복잡한 엔진, 네트워크 효과, 독점 데이터, 인프라, 생태계 등에 있어 단일 프롬프트로 실용적인 대체가 어려움.

판정은 “제품 전체를 완벽하게 복제할 수 있는가”와 “내가 쓰는 일부 기능을 대체할 수 있는가”를 구분해야 한다. 사용 사례를 숨긴 채 제품 전체를 대체할 수 있다고 표현하지 마라.

예를 들어 Slack 전체의 안정성과 생태계, Notion 전체의 협업 기능, Excel의 완전한 계산 엔진·매크로 호환성, OBS의 실시간 방송 성능을 단일 프롬프트로 모두 대체할 수 있다고 과장하지 마라.

도구마다 복사해 실제 코딩 에이전트에 넣을 수 있는 구체적인 제작 프롬프트를 작성하라. 공통 구조는 재사용할 수 있지만, 제품명만 바꾼 동일한 프롬프트로 채우지 마라.

각 프롬프트에는 다음을 포함하라.

* 만들 결과물과 대상 사용자.
* 대체할 실제 사용 사례와 범위.
* 핵심 기능, 화면과 사용자 흐름.
* 데이터 구조, 저장 방식, 필요한 가져오기·내보내기.
* 적합한 스택과 실행 방식.
* 오류 처리와 필요한 보안.
* 구체적인 완료 조건과 테스트 방법.
* 필요한 환경변수와 외부 의존성.
* 의도적으로 구현하지 않는 범위와 원본 대비 손실.

no 판정에도 정직한 설명과 함께 구현 가능한 제한적 대안의 프롬프트를 제공하라. 완전 대체 프롬프트인 것처럼 소개하지 마라.

whatYouLose는 구체적으로 작성하고, 기존 오픈소스나 유사 도구가 이미 있다면 priorArt에 넣어라. 링크와 라이선스를 확인할 수 없으면 확인되지 않았다고 표시하라.

도구별 프롬프트를 실제 실행해 검증한 것과 편집 검토만 한 것을 구분하라. 이번 웹서비스의 QA 완료를 100개 도구 프롬프트의 제작 결과가 검증되었다는 의미로 사용하지 마라.

8. 홈페이지·디렉터리·도구 상세

홈페이지에는 다음을 구현하라.

* 서비스의 질문과 가치를 명확히 전달하는 한국어 히어로.
* 입력 즉시 목록이 갱신되는 검색.
* 한글명, 영문명, 별칭, 태그를 활용한 검색.
* 이모지가 포함된 카테고리 칩.
* 판정, 도구 유형, 가격 모델 필터.
* 인기순, 최신순, 가격순 등 목적이 분명한 정렬.
* 검색·필터·정렬·페이지 상태의 URL 반영과 새로고침·뒤로가기 복원.
* 원본의 “The Death List”에 대응하는 대체 인증 순위.
* 각 행의 favicon 또는 대체 아이콘, 이름, 카테고리, 가격, 판정, 대체 인증 수.
* 최신 제작 후기, 유용한 커뮤니티 글, 새로 등록한 도구로 이어지는 진입점.
* 로딩, 빈 결과, 오류, 긴 목록 처리.

비용 티커는 원본처럼 시각적으로 강한 주식 시세판 형태여야 한다.

* 숫자가 굴러가는 odometer.
* 앱 가격이 흘러가는 테이프.
* 서버에서 렌더링한 초기 값과 실제 DB 집계.
* 대체 인증 이후 갱신되는 값.
* 원본의 “COLLECTIVE MRR DESTROYED” 컨셉을 살리되, 실제 의미는 사용자가 대체했다고 신고한 도구 비용의 월 환산 추정 합계로 명확히 설명.
* 한국 사용자가 이해할 수 있도록 원화 합계를 기본으로 제공하고 원통화·환율 기준 확인 가능.
* 서로 다른 통화는 확인 가능한 동일 기준으로 환산한 뒤 합산.
* priceMonthly × 유효한 대체 인증 수를 기본 집계 구조로 유지하되, 기준 플랜·좌석 수·가격 모델을 명시.
* 무료 도구는 대체 인증 순위에 포함하되 월 비용 합계에 금액을 더하지 않음.
* 일회성 구매, 가격 미확인, 견적형·사용량형 등 월 비용을 확정할 수 없는 항목은 별도로 표시하고 무리하게 합산하지 않음.
* 같은 사용자가 같은 도구에서 반복 클릭해 합계를 늘릴 수 없도록 처리.
* 대체 인증은 자기신고이고, 이 숫자가 검증된 실제 절약액이나 원본 회사의 실제 MRR 감소액은 아님을 설명.
* 서버·모델 API·유지보수 비용까지 공제한 순절감액이라고 표현하지 않음.
* 테스트 투표와 샘플 수치가 운영 통계에 섞이지 않도록 분리.

도구 상세 페이지는 원본의 /:slug 구조를 유지하되, /community, /login, /admin 등의 예약 경로와 충돌하지 않도록 하라. 기존 기획에서 경로를 바꿔야 하는 사유가 있으면 리다이렉트와 canonical 정책을 포함해 정리하라.

각 상세 페이지에 다음을 구현하라.

* 도구 소개, 공식 링크, 가격 기준과 출처.
* 큰 판정 표시와 이유.
* “어떤 용도로 쓰는 경우 대체 가능한지”에 대한 범위 설명.
* 복사 가능한 원샷 제작 프롬프트 코드 블록.
* Claude Code / Codex / Cursor별 복사 버튼.
* 각 버튼이 해당 에이전트의 현재 실행 방식에 맞는 지침을 앞에 붙여 실제 클립보드에 복사하도록 구현.
* 지원되지 않는 CLI 명령이나 플래그를 만들어 넣지 않음.
* 복사 성공·실패 피드백과 clipboard API 사용 불가 시 대안.
* whatYouLose 목록, 운영 부담, prior art 링크.
* 관련 도구 3개.
* “직접 대체했어요” 투표와 현재 상태, 중복 방지.
* 북마크.
* 해당 도구와 연결된 제작 후기·질문·공유 글.
* 도구별 내용이 반영된 4개의 FAQ.
* X 공유 버튼, 링크 복사, 가능한 기기에서는 기본 공유 기능.
* 수정 제안 또는 신고 진입점.

원본의 비회원 투표 경로를 유지하면서 회원 투표도 지원하라. 회원은 사용자 기준 고유 제약을 적용하고, 비회원은 서명된 익명 식별자와 IP 기반 요청 제한을 함께 적용하라. 로그인 전후 동일 브라우저의 투표를 가능한 범위에서 연결해 단순 이중 집계를 방지하라.

비회원 투표는 완전한 1인 1표를 보장할 수 없다는 한계를 기록하라. 장기적인 원본 IP 저장을 피하고 신뢰할 수 있는 프록시 설정과 짧은 보관 기간을 고려하라.

대체 인증과 커뮤니티 게시글의 “좋아요”는 별도 행동과 집계로 구현하라.

9. 회원가입·로그인·내 활동

기획서에 있는 인증 방식을 우선 구현하되, 외부 OAuth나 메일 서비스 키가 없어도 검증 가능한 기본 가입·로그인 경로를 마련하라. 기본값은 이메일·비밀번호 기반 로컬 계정과 서버 세션이다.

* 회원가입, 로그인, 로그아웃.
* 이메일·닉네임 중복 검사와 입력 검증.
* 안전한 비밀번호 해시 저장.
* 로그인 상태 유지, 세션 만료, 로그아웃 시 세션 폐기.
* 가입 시 필요한 약관·개인정보 관련 안내와 선택적 소식 수신 동의의 분리.
* 프로필 조회·수정과 닉네임.
* 내가 쓴 글·댓글, 북마크, 대체 인증 내역.
* 계정 탈퇴와 데이터 처리 정책.
* 사용자 권한과 관리자 권한의 서버 측 검증.
* 잘못된 비밀번호, 존재하지 않는 계정, 반복 요청 등 실패 흐름.

이메일 확인과 비밀번호 재설정은 UI, 토큰 발급·만료·일회성 사용, 서버 로직까지 구현하라. 메일 공급자 키가 없으면 실제 발송만 개발용 로컬 어댑터로 대체해 내부 흐름을 테스트하고, 실제 수신함 도착·메일 링크 연동은 보류 항목으로 남겨라.

미인증 이메일을 인증 완료 상태로 처리하지 마라. 로컬 개발용 메일 뷰어나 토큰 확인 기능은 운영 환경에 노출되지 않게 하라.

소셜 로그인은 기획서의 제공자를 우선하고, 별도 지정이 없으면 Google과 Kakao를 기본 대상으로 구성하라. 다른 제공자를 넣는 경우 필요한 범위만 선택하라. 계정 연결 시 이메일 문자열만 같다는 이유로 계정을 자동 병합하지 마라.

소셜 로그인 키가 없으면 준비 상태를 정확히 표시하고 관련 기능만 비활성화하라. 서버 전체나 일반 회원가입이 실패하지 않게 하라.

운영용 관리자 계정과 비밀번호를 코드에 하드코딩하거나 공개 seed에 넣지 마라. 로컬 QA 계정과 관리자 생성 절차는 운영과 분리하라.

10. 커뮤니티·알림·운영 기능

단순 게시판 목업이 아니라 실제 사용 가능한 커뮤니티를 구현하라. 기획서에 더 구체적인 요구가 있다면 해당 요구도 포함하라.

기본 게시판은 제작 후기·작품 공유, 질문·도움 요청, 프롬프트 공유·개선, 자유 토론, 공지로 구성하라. 기획서에 명칭이 있으면 이를 따르라.

* 게시글 목록·상세·작성·수정·삭제.
* 제목, 본문, 카테고리, 태그, 관련 도구 연결.
* Markdown 등 실제 사용할 수 있는 본문 편집과 안전한 렌더링.
* 최신순·인기순, 검색, 필터, 페이지네이션.
* 댓글과 1단계 답글, 수정·삭제.
* 게시글 좋아요와 북마크, 중복 방지.
* 작성자 프로필과 활동 내역.
* 게시글·댓글 신고.
* 비로그인 열람과 로그인 후 쓰기·반응 등 권한 정책.
* 로그인 페이지를 거친 후 원래 하려던 페이지로 복귀.
* 작성자 본인만 수정·삭제할 수 있도록 서버에서 확인.
* 댓글·답글 등 기본 알림, 읽음 처리, 알림에서 대상 글로 이동.
* 삭제·숨김 처리된 콘텐츠와 알림·좋아요·댓글 간 일관성.

제작 후기에는 대상 도구, 사용한 코딩 에이전트, 적용한 프롬프트, 만든 기능, 어려웠던 점, 실제 대체 범위, 배포 URL 또는 저장소 URL 등을 작성할 수 있게 하라. 모든 필드를 필수로 만들어 글쓰기를 어렵게 하지 마라.

외부 링크나 파일은 입력 검증과 적절한 처리를 하라. 첨부 기능이 기획서에 있으면 구현하고, 외부 스토리지 키가 없을 때 로컬 테스트와 실제 업로드 검증을 분리하라. 임의의 외부 URL을 서버가 제한 없이 가져오도록 만들지 마라.

운영에 필요한 최소 관리자 화면도 구현하라.

* 사용자 조회와 필요한 제한 조치.
* 게시글·댓글 숨김 및 복구.
* 신고 조회와 처리 상태.
* 공지 작성·고정.
* 도구 등록 제안과 정보 수정 제안의 검토.
* 주요 조치의 감사 기록.
* 비관리자의 화면 접근과 API 호출 차단.

도구 등록·수정 제안의 접수와 검토 상태는 DB에 저장하고, 정식 카탈로그는 검증된 JSON 변경 후 배포하는 흐름을 명확히 하라. 채택되었지만 아직 배포하지 않은 제안을 “게시 완료”로 표시하지 마라. 기획서에서 실시간 카탈로그 편집을 요구한다면 JSON 원본과 동기화하는 일관된 게시 절차를 별도로 구현하라.

11. 대기자 명단·분석·검색 노출

원본의 대기자 명단 이메일 수집 기능을 유지하라. 공개 서비스 출시 후에는 출시 소식·업데이트 구독 등 맥락에 맞는 문구를 사용해도 된다.

* SQLite 저장.
* 이메일 검증과 정규화.
* honeypot과 요청 제한.
* 중복 구독 방지.
* 등록 성공·실패와 이미 등록된 경우의 처리.
* 회원가입과 독립적인 이용 경로.
* 수신 동의 기록과 철회 절차.
* 메일 발송 서비스가 없어도 등록 자체는 실제 동작.

분석은 first-party analytics만 사용하라. 페이지 조회, 검색, 프롬프트 복사, 대체 인증, 가입, 글쓰기 등 서비스 개선에 필요한 최소 이벤트를 대상으로 하고, 비밀번호·세션·이메일·게시글 본문·민감한 검색어 원문을 분석 이벤트에 실어 보내지 마라.

SEO는 원본 요구사항을 유지하라.

* 공개 콘텐츠와 핵심 메타데이터의 서버 렌더링.
* “Notion을 바이브코딩으로 대체할 수 있을까?” 같은 질문형 제목.
* 페이지별 title, description, canonical, Open Graph, 공유 메타데이터.
* WebSite + SearchAction, ItemList, FAQPage, BreadcrumbList, Organization JSON-LD.
* 구조화 데이터는 실제 화면의 공개 콘텐츠와 일치하도록 하고, 적용 가능한 페이지에만 사용.
* sitemap.xml과 robots.txt.
* 로그인·내 활동·관리자·비공개·삭제 콘텐츠의 검색 노출 방지.
* 검색·필터 URL의 중복 색인 정책.
* 없는 slug와 삭제된 페이지의 올바른 상태 코드.
* 빌드 시 satori + resvg로 도구별 OG 이미지를 생성하고 한글 폰트 렌더링 확인.
* 빌드 후 생성되는 커뮤니티 글의 OG 이미지는 별도 동적 생성·캐시 또는 정식 fallback 정책으로 처리.
* 도메인 변경 시 localhost나 이전 주소가 canonical·sitemap·공유 링크에 남지 않도록 설정.
* 구조화 데이터를 넣었다는 이유만으로 검색엔진의 특정 노출 형태를 보장하지 않음.

푸터에는 이 서비스를 만드는 데 사용한 실제 최종 재구축 프롬프트의 공개 페이지 또는 파일 링크를 넣어라. 원본 참고 프롬프트와 한국판 확장 프롬프트의 관계도 확인할 수 있게 하라.

12. 기능에 맞는 보안과 운영 처리

인증과 커뮤니티가 추가된 만큼 실제 기능에 필요한 보안을 구현하라.

* 서버 측 입력 검증과 권한 검사.
* 파라미터 바인딩 등 SQL injection 방지.
* 게시글·댓글·프로필·Markdown·URL 렌더링의 XSS 방지.
* 세션 쿠키의 HttpOnly, Secure, SameSite 설정과 환경별 동작.
* 상태 변경 요청의 CSRF 방어.
* 로그인·가입·투표·댓글·신고·대기자 등록 등의 요청 제한.
* 요청 크기와 입력 길이 제한.
* 인증 토큰·세션 값·환경변수 비밀값의 로그 노출 방지.
* 세션 생성·폐기·만료와 권한 변경 반영.
* 사용자별 데이터 접근 제한과 관리자 API 보호.
* 탈퇴·숨김·삭제에 따른 목록·검색·통계 처리.
* 404·500 및 외부 연동 실패 시 이해 가능한 안내.
* 필요한 운영 로그, 상태 확인, 백업·복원 절차.

이번 기능에 없는 결제나 과도한 기업용 권한 체계를 새로 만들지 마라. 약관·개인정보 문서의 실제 운영 주체 등 입력이 필요한 사항은 표시하고, 확인하지 않은 법적 검토를 마쳤다고 주장하지 마라.

13. 환경변수와 외부 연동의 구현·검증 분리

환경변수 항목은 다음 세 가지로 구분하라.

A. 외부 계정 없이 로컬에서 설정 가능한 필수값.
B. 운영 배포 시 필요한 설정값.
C. 외부 서비스 계정·비밀키가 필요한 선택적 연동값.

SITE_URL, DB 경로, 로컬 세션 보안값처럼 외부 계정 없이 준비할 수 있는 값은 안전한 로컬 설정을 만들어 QA를 진행하라. 직접 생성할 수 있는 로컬 설정까지 “환경변수 미등록”을 이유로 건너뛰지 마라.

OAuth, 실제 메일 발송, 외부 스토리지 등은 필요한 키가 없더라도 다음을 완성하라.

* UI와 서버 로직.
* 설정 검사와 기능별 활성화 정책.
* 어댑터 또는 연동 코드.
* 키가 없을 때의 정상적인 비활성·오류 처리.
* mock·stub·로컬 어댑터로 확인 가능한 계약 및 내부 흐름 테스트.
* 키 등록 후 실제 외부 서비스에서 재실행할 검증 시나리오.

mock 성공을 실제 외부 연동 성공으로 기록하지 마라. 운영 모드에서 개발용 인증 우회, 가짜 로그인, 가짜 메일 성공이 동작하지 않게 하라.

실제 코드에서 사용하는 이름과 일치하는 .env.example을 작성하고, 비밀값을 저장소에 넣지 마라. 선택적인 키가 누락되었다는 이유로 관련 없는 페이지나 서버 초기화가 실패하지 않게 하라.

환경변수 명세에는 각 항목별로 다음을 기록하라.

* 정확한 변수명.
* 사용 기능과 읽는 코드 위치.
* 로컬 필수·운영 필수·선택 구분.
* 서버 전용인지 공개 가능한 값인지.
* 발급 또는 설정 경로.
* 예시 형식과 callback·redirect URI.
* 로컬·운영 환경별 차이.
* 미설정 시 동작.
* 설정 후 재시작·재빌드 필요 여부.
* 값이 유효한지 확인할 방법.

보류한 테스트에는 각각 고유 ID를 부여하고, 기능명, 보류 이유, 필요한 변수·외부 준비 사항, 실행 명령, 브라우저 조작 순서, 기대 결과, 정리 방법을 남겨라.

14. 실제 서버와 브라우저 QA

모든 구현을 마친 후 실제 웹 서버를 실행하고, 브라우저를 열어 화면과 사용자 흐름을 검증하라. 코드를 읽거나 빌드가 성공했다는 사실만으로 QA를 끝내지 마라.

브라우저 도구와 Playwright 등 사용 가능한 수단으로 실제 사용자 조작을 수행하라. 자동화가 가능한 핵심 흐름은 재현 가능한 테스트로 남기고, 시각적 품질도 직접 확인하라.

최소 다음 범위를 검증하라.

* 홈페이지, 모든 주요 페이지, 없는 경로, 빈 상태, 오류 상태.
* 도구 검색, 한글·영문·별칭 검색, 카테고리, 필터, 정렬, 페이지 이동, URL 상태 복원.
* 전체 도구 데이터의 스키마·slug·필수 필드 검증과 상세 페이지 렌더링 확인.
* yes·kinda·no, 무료·유료·일회성·가격 미확인 도구의 대표 화면과 상호작용.
* 프롬프트 전문 표시, Claude Code·Codex·Cursor 각각의 실제 복사 결과.
* FAQ, 관련 도구, prior art, 외부 링크, 공유 URL.
* 비회원·회원 대체 인증, 중복 클릭, 로그인 전후 중복, 집계와 티커 변화.
* 통화별 합산, 가격 미확인·무료·일회성 항목의 집계 정책.
* 가입, 로그인, 로그아웃, 세션 유지·만료, 잘못된 입력, 중복 계정.
* 프로필 수정, 내 활동, 북마크, 탈퇴.
* 게시글·댓글·답글의 생성·조회·수정·삭제.
* 좋아요·북마크·신고·알림.
* 타인의 글 수정·삭제 시도와 API 직접 호출 거부.
* 비로그인 쓰기 제한과 로그인 후 복귀.
* 관리자 접근, 신고 처리, 콘텐츠 숨김·복구, 공지, 제안 검토.
* 대기자 이메일 등록, 중복, honeypot, 수신 철회.
* 새로고침·서버 재시작 후 데이터 유지.
* 다크·라이트 모드, reduced motion, 키보드 조작.
* 모바일 360~390px, 태블릿, 데스크톱에서 레이아웃과 주요 흐름.
* 긴 한글·영문 텍스트, 코드, 매우 큰 숫자, 데이터가 없는 상태.
* 메타데이터, canonical, sitemap, robots, JSON-LD, OG 이미지.
* 콘솔 오류, 실패한 네트워크 요청, 깨진 이미지, 가로 넘침, 폼 오류 안내.
* 선택적 환경변수가 없을 때의 기능별 처리.
* 인증·XSS·CSRF·요청 제한 등 구현한 보호 장치의 핵심 실패 시나리오.

외부 링크 공유는 조합된 URL과 이동 동작을 검증하되, 사용자의 실제 SNS에 게시하는 것까지 QA에 포함하지 마라.

외부 설정이 필요한 테스트만 보류하고, 나머지 기능은 실제로 수행하라. 설정된 연동을 테스트할 때도 테스트 계정·수신함 등 통제된 데이터를 사용하라.

문제를 찾으면 수정 → 필요한 재검증을 반복하라. 무관한 테스트를 끝없이 추가하지 말고, 요구사항과 발견한 위험을 검증하는 데 집중하라.

테스트 상태는 최소 다음처럼 구분하라.

* PASS: 실제 실행해 기대 결과를 확인.
* FAIL: 실행했으나 실패.
* BLOCKED_ENV: 필요한 외부 환경변수·계정이 없어 실제 연동 검증 보류.
* BLOCKED_ACCESS: 도구·네트워크·권한 등의 실행 제약.
* NOT_RUN: 아직 실행하지 않음.

기능별 구현 상태와 테스트 상태를 별도로 기록하라. “구현했지만 외부 연동 미검증”과 “구현 자체가 안 됨”을 섞지 마라.

QA 보고서에는 검증 날짜, 코드 커밋 또는 버전, 실행 환경, 명령, 대상 URL, 테스트 계정 유형, 기대 결과, 실제 결과, 증거 파일, 남은 문제를 남겨라. 스크린샷에는 비밀번호나 토큰을 노출하지 마라.

15. 배포·공개 저장소·라이선스

사용 가능한 배포 환경과 연결된 계정이 있으면 해당 환경의 절차에 따라 실제로 배포하라. 배포 후 URL에 접속해 핵심 흐름을 다시 확인하라.

배포할 수 없으면 로컬 production build와 production start까지 검증하고, 실행 가능한 미리보기와 배포 설정·절차를 준비하라. 이 경우 “배포 완료”라고 쓰지 말고 배포를 위해 필요한 설정만 구체적으로 남겨라.

* 실제 Node 서버 실행 방식과 포트·호스트 설정.
* DB의 영속 경로와 볼륨.
* 최초 마이그레이션·seed와 재배포 시 데이터 유지.
* 환경변수 등록과 OAuth callback 설정.
* HTTPS와 운영 세션 설정.
* OG 이미지·sitemap 생성과 도메인 반영.
* 상태 확인, 로그, 백업·복원, 이전 버전으로 되돌리는 방법.
* 로컬 및 배포 환경에서 테스트 데이터를 분리·정리하는 방법.

소스코드는 MIT 라이선스와 공개 GitHub 저장소를 목표로 준비하라. 원본 코드의 실제 라이선스를 먼저 확인하고, 재사용한 저작권 고지와 의존성 라이선스를 보존하라. 확인되지 않은 코드를 임의로 MIT로 재라이선스하지 마라.

공개 저장소 생성·push가 가능한 설정과 권한이 있으면 진행하라. 그렇지 않으면 커밋 가능한 상태의 프로젝트, 라이선스, README, .gitignore, 공개 전 제외 항목을 준비하고 정확한 후속 절차를 남겨라.

기존 비공개 저장소 자체를 임의로 공개 전환하거나 비밀키·실제 사용자 DB·테스트 계정 비밀번호를 공개하지 마라. 새 프로젝트를 공개할 때도 공개 대상 파일을 확인하라.

16. 최종 산출물과 완료 기준

설명만 남기지 말고 다음을 실제 프로젝트에 포함하라. 기존 문서 구조가 있으면 그 구조에 맞게 통합해도 되지만, 아래 정보가 빠지면 안 된다.

* 실행 가능한 전체 소스코드.
* 검증된 도구별 JSON 데이터 100개 이상과 출처.
* DB 스키마, 마이그레이션, 반복 실행 가능한 seed.
* .env.example과 환경변수 검사.
* 실제 기능을 검증하는 테스트와 실행 명령.
* README: 설치, 개발, 빌드, 실행, 테스트, 관리자 준비, 배포.
* 기획 검토·수정 내역과 최신 기획서.
* 구조·데이터 모델·권한·통계 정의 문서.
* 도구 정보·가격·환율·판정 근거와 확인일 문서.
* QA 보고서와 필요한 스크린샷·테스트 결과.
* 환경변수 명세와 외부 설정 후 테스트 명세.
* 배포·영속 저장·백업·복원 문서.
* 원본과 한국판 최종 제작 프롬프트의 공개 사본 및 푸터 링크.
* MIT 라이선스와 필요한 원본 저작권 고지.

다음 조건이 충족되어야 개발 완료로 판단하라.

1. 검토한 기획과 이 프롬프트의 요구사항이 구현 또는 명시적 검증 보류 항목에 추적 가능하게 연결되어 있다.
2. 환경변수 없이 검증 가능한 주요 기능은 실제 DB와 서버를 통해 작동한다.
3. 회원가입·로그인·커뮤니티·도구 디렉터리·대체 인증·티커가 목업이 아닌 실제 기능이다.
4. 의도한 영속 저장 구조에서 재시작 후 데이터가 유지된다.
5. 실제 브라우저 QA를 수행했고, 서비스 사용을 막는 오류를 수정했다.
6. 환경변수와 외부 권한 때문에 보류한 항목은 재현 가능한 테스트 명세가 있다.
7. 실제 배포 여부, 공개 저장소 여부, 구현 완료 여부, 검증 완료 여부를 정확하게 구분한다.
8. 중요한 FAIL·NOT_RUN을 숨긴 채 전체 완료라고 보고하지 않는다.

마지막 응답에는 다음을 간결하게 보고하라.

* 구현한 핵심 기능과 기획에서 수정한 주요 사항.
* 실제 접속 가능한 URL과 저장소 주소가 있다면 그 주소.
* 실행·테스트 방법.
* 수행한 QA와 결과 요약.
* 외부 설정 때문에 보류한 기능, 필요한 환경변수, 재테스트 문서 위치.
* 남아 있는 실제 오류나 제약.
* 주요 산출물 위치.

진행 가능한 구현·검증·배포 준비를 끝내기 전에 최종 응답을 제출하지 마라. 아래 원본 프롬프트까지 검토한 뒤 지금 바로 작업을 시작하라.

17. 참고: 원본의 첫 번째 원샷 제작 프롬프트 전문

아래는 참고용 원본이다. 위에서 명시한 회원가입·커뮤니티·한국화·범위 확장과 충돌하는 부분은 위의 확장 요구사항을 따른다. 충돌하지 않는 기존 요구사항은 모두 유지한다.

Build me a directory site called "Can I Vibecode It?" that answers, per paid SaaS app, whether you can replace it with one AI coding prompt. Requirements:

* Stack: Astro (server output, node adapter) + better-sqlite3. No client framework: vanilla JS for interactions. Dev-tool aesthetic: JetBrains Mono + Space Grotesk, CRT-black dark mode (default) and a paper light mode, phosphor green as the only loud color.
* Each app is one JSON file in data/apps/: slug, name, domain, category, priceMonthly, verdict (yes|kinda|no), whatYouLose[], priorArt[], prompt, notes.
* Homepage: hero search that live-filters, category chips with emoji, and "The Death List": apps ranked by "I replaced this" votes, each row: favicon, name, category, price, verdict badge (YES green / KINDA amber / NOT REALLY red), vote count.
* A loud "COLLECTIVE MRR DESTROYED: $X/mo" ticker (sum of price × votes) with odometer-rolling digits and a scrolling tape of app prices. It must look like a stock ticker, not text.
* App pages at /:slug: big verdict, the one-shot build prompt in a code block with per-agent copy buttons (Claude Code / Codex / Cursor, each prefixes agent-specific run instructions), honest "what you lose" list, prior-art links, 3 related apps, an "I replaced this" vote button (SQLite counter, IP rate-limited, no auth), a share-on-X button, and a 4-question FAQ.
* SEO: server-rendered everything, question-format titles, canonical URLs, JSON-LD (WebSite+SearchAction, ItemList, FAQPage, BreadcrumbList, Organization), sitemap.xml, robots.txt, per-page OG images generated at build time with satori + resvg.
* Waitlist email capture (SQLite, honeypot, dedupe) and a footer that links to this very rebuild prompt, because the site should practice what it preaches.
* Micro-animations everywhere, tastefully: odometer rolls, hover lifts, press scales, copy confirmations, reveal-on-scroll. Respect prefers-reduced-motion.

MIT license. Public repo. No accounts, no payments, no tracking beyond first-party analytics.