1. 도출된 SRS 검토 및 보강 : 정말로 “내가 구현할 + 운영할 수 있는” MVP 범위로 적절한가?

꼭 직접 해 보세요!

• 검토 기준

  • 개발 난이도 (MVP 단계 적절성)
  • 기술 스택 (복잡성 및 오픈소스 여부)
  • 운영 소요 비용 (클라우드 컴퓨팅 서비스 기반 예비 산정)

  + 기타 개인 프로젝트별 기준 - PoC(Proof of Concept) 차원에서 아래 내용 고려 필요

  *+ 현 단계에서 증명해야 하는 요소

  • 현 단계에서 증명할 수 없는 요소
  • 현 단계에서 무시하고 Dummy 작업으로 대체할 수 있는 요소*

• 작업 예제

  # 기존 기술스택 내용이 있는 경우
  현재 "SRS 상 암묵적으로 전제된 기술 스택(안)" 으로 아래와 같이 정리해 줬는데,
  

  <출력된 기술 스택 관련 서술 내용>

  내가 의도하는 기술 스택은 아래와 같아.
  

  [Assumptions & Constraints]

  (시스템 내부 - 단일 통합 프레임워크) C-TEC-001: 모든 서비스는 Next.js (App Router) 기반의 단일 풀스택 프레임워크로 구현한다. (프론트엔드와 백엔드를 별도 분리하지 않는다.) C-TEC-002: 서버 측 로직(DB 접근, API 호출 등)은 Next.js의 Server Actions 또는 Route Handlers를 사용하여 별도의 백엔드 서버 없이 구현한다. C-TEC-003: 데이터베이스는 Prisma + 로컬 SQLite를 사용하여 로컬 개발환경을 구성하고 배포 시 Supabase(PostgreSQL)를 사용하여 인프라 설정 복잡도를 최소화한다. C-TEC-003: 데이터베이스는 Prisma + 로컬 Supabase CLI 사용하여 로컬 개발환경을 구성하고 배포 시 Supabase(PostgreSQL)를 사용하여 인프라 설정 복잡도를 최소화한다. C-TEC-004: UI 및 스타일링은 Tailwind CSS와 shadcn/ui를 사용하여 AI가 일관된 디자인 코드를 생성하도록 강제한다.

  (시스템 외부 - 연결 및 AI 통합) C-TEC-005: LLM 오케스트레이션은 별도의 Python 서버 없이 Vercel AI SDK를 사용하여 Next.js 내부에서 직접 구현한다. C-TEC-006: LLM 호출은 Google Gemini API를 기본으로 사용하며, 환경 변수 설정만으로 모델 교체가 가능하도록 SDK의 표준 인터페이스를 준수한다. C-TEC-007: 배포 및 인프라 관리는 Vercel 플랫폼으로 단일화하며, CI/CD 설정 없이 Git Push만으로 배포를 자동화한다.

  
  **{기존 SRS 문서}**를 MVP 관점에서 내가 원하는 스택에 부합하도록 변경하고 싶어.
  그렇게 변경하였을 때, 구현 시 기능적 커버리지가 충분한지도 검토해줘.
  파일 수정하기 전에 일단 채팅 응답으로 알려줘.
  

  → MVP 기능의 핵심 사용자 경험 (가치 전달) 이 훼손되지 않는지 검토

  위 분석 내용을 전면 적용하여 작업하기 위한 plan 문서를 plans 경로에 작성해줘.
  해당 plan 문서에는 이러한 변경을 적용했을 때, MVP 기능의 핵심 사용자 경험 (가치 전달) 이 훼손되지 않는지 검토결과도 포함해줘.
  

  위 기술스택 변경 사항에 따라 파일 수정해줘.
  

  ---

  엄밀한 “난이도” 검토 + “구현 계획 효율성” 검토

  현재 {**SRS_V0_1_[모델명].md}** 의 내용이 
  
  1) **{입문자 | 초급자 | 중급자 | 고급자}** 수준의 SW 개발에 대한 배경지식을 갖추고 있는
  2) **{N년차 OOO 직무 종사자}** 를 위한
  3) **{완전 바이브코딩 기반의 MVP 개발 작업 | 엔지니어링 지식을 투입하며 AI 생성 결과물을 개선할 수 있는 MVP 개발 작업}**에 적절한지
  ***+) (Optional) 추가 개인적 SW 개발 배경지식 수준에 대한 상세한 묘사***
  
  개발 난이도 및 구현 가능성 관점에서 검토해줘. 파일 수정하지 말고 채팅 응답으로 알려줘.
  

  아래와 같은 "시스템 및 비용 효율성 관점"에 따라 더 조정할 것이 없는지도 통합적으로 검토해줘.
  
  1) 개발 속도 (MVP 단계의 과도한 시간 소요를 피함)
  2) 외부 연동 목표와 기술 스택 (복잡성 및 오픈소스 여부에 따른 적절성과 리스크)
  3) 운영 소요 비용 (클라우드 컴퓨팅 서비스 기반 비용 산정)
  
  검토 결과는 **"MVP-개발목표-적절성-종합-검토(난이도/가능성/효율성)-보고서.md"** 파일로 작성해줘.
  

  그렇다면 현재까지 제시한 내용을 모두 반영하여 **{기존 SRS 문서}**를 기반으로, 
  새 파일 **{SRS_V0_9.md}** 를 작성해줘.
  

  • Gemini 웹 기반 프롬프팅 예제

    그렇다면 현재까지 제시한 내용을 모두 반영하여 기존 SRS 문서를 기반으로, 
    
    1) 개인적으로 구현 가능한 개발 난이도 조정
    2) 목표로 하는 인프라 제약(완전 무료)과 비기능 요구사항(SLA, 동시 접속자 수) 사이에 심각한 기술적 모순을 해소
    
    수정본을 도출하기 위한 계획서를 작성해줘.
    

    위 내용은 나에게 주는 사람으로서의 작업 계획인데, 내가 원하는 것은 AI 작업용 계획서야.
    SRS 문서의 어떤 부분을 어떻게 수정해야 하는지 AI에 직접 명령하기 위한 작업 plan 문서를 작성해줘.
    

  **{SRS_v0_1_Opus.md}** 와 비교하여 **{SRS_v0_3.md}** 에서 변경된 부분을
  다음 세가지 관점으로 검토하여 명확하게 각각의 항목에 대한 표로 정리해서 보고해줘.
  
  1) 기술 스택의 명확성
  2) MVP 목표 및 가치전달 조정 내용
  3) 기타 차이점
  
  마크다운 파일로 작성해줘.
  

  https://github.com/wild-mental/SRS-from-PRD-HealthProdInfo

  → 여기까지 진행 후 금요일 수업 시작!

  ---

  *- 이후 본인이 학습 및 확인하고자 하는 기술 키워드 내용에 따라 후속 프롬프팅합니다 -*
  

2. SRS 최종본을 토대로 TASK 추출하기

📝 TASK란? TASK의 형태는?

• SW 개발 Task 에 대한 간결한 템플릿 (구조 파악용)
• 풀버전 템플릿 (향후 GitHub 프로젝트 관리에 맞춤)

📘 SRS → AI 에이전트용 개발 Task 추출의 핵심 원리 3가지

1. 눈에 보이는 기능보다, '데이터 흐름 관리와 데이터 보관 체계'부터 만들게 하기

• 사람 기획자는 보통 '화면'과 '기능'을 먼저 생각합니다. 하지만 AI에게 화면부터 만들라고 하면 데이터를 어디에 저장할지 몰라 제멋대로 창고를 만듭니다.
• 원칙: 기획서를 읽을 때 가장 먼저 "이 기능은 어떤 데이터를 저장해야 하지?"를 고민하고, '데이터 창고(DB) 만들기' 작업을 최우선으로 뽑아내야 합니다.

2. 큰 요구사항은 여러개로 쪼개서 하나의 지시서에는 딱 하나의 목적만 담기 (조회 vs 쓰기)

• "회원가입하고 마이페이지 보여줘"라는 지시는 AI에게 너무 복잡합니다.
• 원칙: 기능 요구사항을 읽을 때, 그 기능이 '데이터를 단순히 꺼내서 보여주는 것(조회)'인지, 아니면 '데이터를 새로 저장하고 수정하는 것(쓰기)'인지 엄격하게 나누어 별도의 작업으로 쪼개야 합니다.

3. 사람이 확인해주기 전에 스스로 확인할 수 있는 1차 검토 리스트를 생성하기 (자동 채점표 제공 → TDD 테스트 주도 개발 적용)

• AI는 코드를 다 짜고 나서 "저 잘했나요?"라고 사람에게 물어보며 멈춰있지 않습니다.
• 원칙: 기획서에 적힌 '완료 조건(예: 비밀번호 틀리면 에러 날 것)'을 바탕으로, "AI가 스스로 정답을 맞혔는지 채점할 수 있는 테스트 코드 만들기" 작업을 반드시 포함해야 합니다.
• 핵심원칙 3가지 프롬프트용 버전