바이브 코딩용 소크라테스식 AI 컨설턴트 설계 정리

핵심 요약

이 문서는 경력 개발자·테크 리드를 위한 "AI 설계 파트너"를 정의하는 메타 프롬프트이다.

목표는 질문–결정–문서화까지 한 번에 수행하여, 바로 개발 가능한 7종 문서를 자동 생성하는 것이다.

AI는 정보 수집기가 아니라, 가정·리스크·충돌을 드러내고 설계를 고정하는 역할을 수행한다.

역할과 목표: AI 설계 파트너의 정의

이 시스템에서 AI는 초급 개발자 코치가 아니라, 이미 실전 경험이 있는 개발자와 함께 일하는 설계 파트너로 설정된다.

대상은 주로 경력 개발자, 테크 리드, 프로덕트 엔지니어로, 이들이 실제 프로젝트에서 "바이브 코딩"을 효율적으로 쓰도록 돕는 것이 목적이다.

태도는 친절한 조언자보다는 명료하고 직설적인 동료에 가깝고, 특히 비판적 사고와 소크라테스식 질문을 통해 사용자의 생각 속 전제와 구멍을 집요하게 드러내도록 설계되어 있다.

이 AI가 수행해야 할 핵심 임무는 네 가지로 요약된다. 첫째, 숨겨진 가정을 끄집어내고 반증 가능한 형태의 가설로 바꾸는 것. 둘째, 제품 요구(PRD)를 기술 요구(TRD)로 변환 가능한 구체 결정으로 정제하는 것. 셋째, MVP와 마일스톤 중심의 실행 계획을 만드는 것. 넷째, 이 모든 대화를 바탕으로 AI 코딩 파트너가 바로 개발을 시작할 수 있는 7가지 구조화 문서를 자동 생성하는 것이다.

두 가지 운영 모드: 인터뷰 vs 산출물

이 시스템은 작업 단계에 따라 두 가지 모드로 분리된다.

첫 번째는 설계 인터뷰/리뷰 모드로, 여기서는 기술 용어 사용을 허용하고 아키텍처, 스택, 운영, 보안 등 핵심 결정을 가능한 초기에 확정하는 데 집중한다. 질문은 한 번에 하나가 아니라 여러 개를 묶어 던지는 배치 질문 방식이 기본이며, 애매하게 답변된 항목에 대해서는 다시 단일 질문 모드로 파고들어 명확한 결정을 이끌어낸다.

두 번째는 산출물 모드로, 인터뷰 결과를 기반으로 7개의 문서를 실제로 작성하는 단계이다. PRD는 비기술자도 읽을 수 있게 하되 개발자가 싫어할 만한 애매함을 제거하고, TRD·DB 설계·태스크 정의·코딩 컨벤션은 개발 문서로서 바로 사용 가능한 수준으로 작성된다. 기술 스택 선택에서는 AI가 임의로 정하지 않고, 별도의 스택 결정 프로토콜을 통해 옵션과 근거를 제시하고 최종 선택은 사용자 또는 명시된 가정으로 남기도록 한다.

대화 전략: "정보 수집"이 아닌 "결정 완료"

이 시스템의 핵심 철학은 "결정이 곧 문서의 연료"라는 생각이다.

대화의 목적은 최대한 많은 정보를 듣는 것이 아니라, 실제로 필요한 결정을 끝까지 밀어붙여 확정하는 데 있다. "감"이나 "취향" 수준에 머무르는 항목은 문서에서 리스크 또는 가정으로 명시하거나, 추가 논의를 통해 구체적 결정으로 승격시켜야 한다.

AI는 사용자의 답변을 받는 즉시 갭과 충돌을 탐지하도록 설계된다. 예를 들어 "리텐션이 중요하다"고 말하면서 실제 지표는 가입자 수만 잡는 상황, 로컬 저장을 원하면서 동시에 멀티 디바이스 동기화를 요구하는 상황, 빠른 MVP를 원하면서 지나치게 복잡한 보안 요구를 붙이는 상황 등의 모순을 빠르게 집어낸다.

모호한 선택지에 대해서는 단순히 "A vs B 중 무엇이 좋냐"고 묻는 것이 아니라, 각각의 트레이드오프와 언제/왜 더 나은지까지 비교해준다. 예를 들어 "Next.js 모놀리식"과 "FE/BFF 분리"를 기능과 팀 상황, 확장성 요구에 따라 어떤 조건에서 선택할지 설명하며 결정을 도와주는 식이다.

진행 규칙과 "미정" 처리 방식

대화는 라운드 단위로 진행되며, 각 라운드는 R1, R2처럼 번호를 붙여 관리한다.

각 라운드에서는 6~10개의 질문을 한 번에 던져 속도 있게 정보를 모으되, 애매한 답변은 다시 좁혀 들어가서 하나씩 확정하는 방식으로 진행한다. 중요한 결정을 내릴 때마다 Decision Log에 일정한 형식으로 기록하여, 나중에 문서에서 근거와 맥락을 추적할 수 있도록 만든다.

전문가와의 대화에서는 "모른다"보다 "아직 정하지 않았다"는 상황이 훨씬 많다고 전제하고, "미정"으로 남은 항목은 그대로 두지 않고 그 결정을 어떤 방식으로 내릴지까지 정의한다. 지금 바로 결정할 것인지, 아니면 실험·POC를 통해 검증한 뒤 결정할 것인지 선택하게 하고, 필요하다면 가정으로 명시하고 검증 플랜까지 붙인다. 보류 항목이 과도하게 늘어나면 MVP 범위를 줄이거나 아키텍처를 단순화하는 선택까지 권고하도록 되어 있다.

SSOT와 Decision Log: 일관성을 강제하는 장치

이 시스템은 여러 문서를 생성하면서도 전체 프로젝트의 "단일 진실 원천"을 유지하기 위해 식별자 체계를 강하게 적용한다.

큰 사용자 가치 단위는 EPIC, 구체적인 기능은 FEAT, 개별 요구사항은 REQ, 비기능 요구는 NFR, 리스크는 RISK라는 접두어와 번호를 붙인다. 이 식별자는 PRD의 사용자 스토리, 사용자 플로우 다이어그램, 데이터베이스 ERD 주석, 태스크 정의, 테스트/인수 기준 등 모든 문서에 동일하게 사용된다.

또한, Decision Log는 {ID, 항목, 선택, 근거, 영향, 대안, 보류안} 형식을 고정하여, "왜 이런 스택을 골랐는가?", "왜 이 범위로 MVP를 자른 것인가?"와 같은 질문에 언제든 근거를 되짚을 수 있게 한다. 이는 나중에 스택 변경, 확장, 리팩토링 시에도 중요한 참고 자료가 된다.

MVP 캡슐: 모든 문서 상단에 고정되는 요약 블록

프로젝트의 MVP가 확정되면, 이를 12줄짜리 요약 블록으로 정리해 모든 문서 최상단에 공통으로 삽입한다.

이 블록에는 목표, 타깃 사용자, 핵심 가치 제안, 가장 중요한 EPIC과 FEAT, 노스스타 지표와 주요 입력 지표, 이번 릴리스에서 의도적으로 다루지 않을 Non-goals, 최우선 비기능 요구, 데이터 민감도와 규정, 가장 큰 리스크와 그에 대한 완화/실험, 그리고 향후 7일의 구체적 액션까지 포함된다.

이렇게 하면 PRD를 보든, TRD를 보든, DB 설계를 보든, 모두 같은 한 페이지짜리 공통 컨텍스트 위에서 논의가 이루어지므로, 팀 내 커뮤니케이션 비용이 크게 줄어든다. 또한 Non-goals를 명시함으로써 "이번 MVP에서 하지 않는 것"을 선명하게 해, 스콥 크리프를 방지하는 효과도 있다.

스택 결정과 7개 문서 패키지

기술 스택은 AI가 마음대로 정하는 것이 아니라, 옵션과 조건을 명시적으로 제시하는 방식으로 다룬다.

권장 스택(Option A)은 현재 팀의 제약과 요구에 가장 잘 맞는 안으로, 근거를 최소 세 가지 이상 명시한다. 대안 스택(Option B, C)은 어떤 상황이나 트리거 조건에서 더 나은 선택이 되는지, 락인·비용·운영 난이도 측면에서 어떤 차이가 있는지를 함께 설명한다. 최종 선택은 사용자가 내리거나, 일단 임시 가정으로 채택한 뒤 특정 시점이나 지표에서 재검토하도록 계획을 붙인다.

모든 라운드가 끝나면 AI는 대화 내용과 필요 시 제공되는 참고 자료("젬스")를 기반으로 7개의 문서를 한 번에 완성한다. 이 문서들은 제품 요구(PRD), 기술 요구(TRD), 사용자 플로우 다이어그램, 데이터베이스 설계, 디자인 시스템 최소본, 개발 태스크 목록, 코딩 컨벤션 및 AI 협업 가이드로 구성된다. 각 문서는 앞서 언급한 MVP 캡슐과 SSOT 식별자, Decision Log를 일관되게 반영해, 바로 개발에 착수할 수 있는 수준의 패키지를 형성한다.

라운드별 질문 구조: R1~R4의 핵심 내용

대화는 기본적으로 네 개의 주요 라운드로 구성된다.

R1에서는 제품과 스콥, 지표를 다룬다. 프로젝트의 이름과 한 줄 설명, 배경, 주요 사용자 시나리오, MVP에서 반드시 포함해야 할 것과 의도적으로 제외할 항목, 노스스타 지표와 입력 지표, 레퍼런스와 피하고 싶은 방향, 출시 목표일과 기간·예산·인력 제약을 한꺼번에 묻는다.

R2에서는 도메인 모델과 데이터, 권한을 파고든다. 핵심 엔티티와 관계, 개인정보 민감도와 보관/삭제 정책, 권한 모델(RBAC/ABAC 등), 감사 요구, 멀티테넌시 여부와 테넌트 모델, 데이터 일관성 수준(트랜잭션 vs 이벤트 중심)을 묻고 정리한다.

R3에서는 아키텍처와 비기능, 운영을 논의한다. 예상 트래픽과 성능 목표(p95, RPS, 동시성), 가용성과 재해복구 목표, 관측성과 알림, 배포 전략과 롤백 방안, 보안 요구, 외부 시스템 연동(API, SSO, 결제, 지도, AI 등)의 존재 여부를 정리한다.

R4에서는 기술 스택과 개발 프로세스, AI 협업 방식을 다룬다. 선호/금지 스택, 레포 구조, 코딩 컨벤션과 테스트 기준, AI가 맡을 작업 범위, PR 리뷰 규칙과 브랜치 전략, 릴리스 정책, 보안·컴플라이언스 체크리스트 등을 여기에서 확정한다.

인사이트

이 설계는 "AI에게 물어보면 답을 준다" 수준을 넘어서, AI를 팀의 설계 리더·비판적 동료로 활용하려는 시도다.

실무에서 바로 활용하려면, 이 구조를 그대로 따라가기보다 팀의 현실과 문화에 맞게 축소·커스터마이즈하는 것이 좋다. 예를 들어 작은 사이드 프로젝트라면 R1과 R2만 먼저 돌리고, R3·R4의 일부 항목은 "미정+가정+검증 계획"으로 남겨 두는 식으로 단계적으로 적용할 수 있다.

또한, 이 프롬프트의 핵심 가치는 "결정 기록"에 있다. 의사결정 이유와 대안을 구조화해두면, 나중에 문제가 생겨도 "누가 왜 이렇게 정했는지"를 빠르게 되짚을 수 있고, 팀원이 바뀌어도 맥락 전파가 훨씬 쉬워진다. 실제 프로젝트에 적용해보고, 부족하거나 과한 부분을 조금씩 잘라내고 추가하면서 자신만의 "팀 전용 AI 설계 파트너" 템플릿으로 발전시키면 활용도가 크게 올라간다.

출처 및 참고 : 바이브코딩 전문가 요구사항 발굴 & 7문서 자동생성 소크라테스 프롬프트(개발자용) | VibeLabs