AI Native 개발을 위한 PRD는 뭘까?

나의 정리

• 좋은 PRD와 Figma가 AI Agent와 Workflow에 엄청난 영향을 끼침
• 결국 PRD든 AI Agent든 개발자 혼자힘의 개발이든 중요한건 정책 ⇒ 정책 이전에 우리가 해결해야 하는 문제에 대한 정의 ⇒ 당연히 해야할 것들을 다시 챙기는 기분
• 이번에 새로운 프로젝트에 AI Native 플로우를 자체적으로 학습해서 적용하면서 다양한 경험의 핵심은 AI는 이미 고급 개발자 수준으로 개발할 수 있는 능력을 가지고 있다. 이미 완성도 높은 Product를 구축하는 방법을 알고 있다. 하지만 AI를 잘 사용하지 못하면 정말 낮은 수준의 결과물이 나온다.
• AI가 요구하는 정보를 우리는 모두 전달해줘야 한다. 그 과정을 학습하면서 느끼는 점은 AI에게 전달해줘야 하는 정보들이 신입사원이나 배경지식이 없는 동료에게 전달해줘야 하는 정보와 같다. 그리고 전달해줘야 하는 정보들을 문서화하는 작업이 필요하다. 부족한 정보들을 알아내고 규칙을 만들어줘야 한다.
• 완성도 높은 개발을 하기 위해 AI에게 전달해야 하는 정보는 '우리가 Product/Project를 잘 만들어 나가기 위한 정보' 이다. AI는 우리에게 '좋은 개발이 하고싶다며? 근데 왜 충분한 정보를 안줘? 왜 그런 고민을 안했어? 왜 그런 컨벤션을 정하지 않았어?' 라고 질문하고 있는 기분이 든다.
• AI Native를 잘 사용하는 조직은 이미 탄탄한 기획, 문서화, 제품을 향한 깊은 고민을 하고있던 조직일 것 같다. 그런 환경에 있지 못하더라도 나부터 하나씩 시스템과 구조를 만들어나가는 노력이 필요할 것 같다.

왜 AI Native 개발에는 다른 PRD가 필요한가?

기존 PRD의 문제점

• 암묵적 지식 의존: "사용자 친화적으로", "직관적으로" 같은 모호한 표현
• 컨텍스트 누락: 개발자 간 구두 전달에 의존하는 정보들
• 예외 케이스 생략: "보통은 이렇게 되겠지" 하는 가정들
• 불완전한 요구사항: 발견되는 대로 추가하는 방식

AI 협업의 특징

• 명시적 정보만 활용: 문서에 없는 것은 추측하거나 일반적인 패턴으로 대체
• 완전한 컨텍스트 필요: 부분적 정보로는 잘못된 구현 가능성 높음
• 일관성 중시: 모순된 정보가 있으면 혼란 발생
• 구조화된 데이터 선호: 자유 형식보다 정형화된 포맷에서 더 정확한 이해

---

AI 친화적 PRD 작성 핵심 원칙

1. 명확성 (Clarity)

구체적 수치와 기준 제시

❌ "빠르게 로딩되어야 함"
✅ "초기 로딩 1초 이내, 추가 데이터 로딩 500ms 이내"

❌ "사용자 친화적인 인터페이스"  
✅ "터치 타겟 최소 44px, 주요 기능 3클릭 이내 접근"

왜 필요한가: AI는 "빠르게"가 1초인지 10초인지 판단할 수 없음. 구체적 기준이 있어야 정확한 구현 가능.

2. 완전성 (Completeness)

모든 시나리오 포함

• 정상 플로우 + 예외 케이스
• 성공 상황 + 실패 상황
• 로그인 상태 + 비로그인 상태
• 네트워크 연결 + 연결 끊김

데이터 구조 명시

입력: 사용자ID, 검색어(최대 100자), 필터 옵션
출력: 게시물 목록(20개), 다음 페이지 토큰, 총 개수
에러: 네트워크 오류, 서버 오류, 권한 오류

왜 필요한가: AI는 명시되지 않은 케이스를 임의로 처리하거나 누락할 수 있음. 모든 경우의 수를 미리 정의해야 일관된 동작 보장.

3. 구조화 (Structure)

계층적 정보 구성

1. 비즈니스 목표 (왜 만드는가)
2. 사용자 시나리오 (누가 언제 어떻게)  
3. 기능 명세 (무엇을 어떻게)
4. 기술 요구사항 (어떤 제약사항)
5. 품질 기준 (어느 정도까지)

템플릿 사용

• 매번 동일한 구조로 작성
• 필수 항목 체크리스트
• 섹션별 작성 가이드라인

왜 필요한가: AI는 일관된 패턴을 학습하여 더 정확하게 이해. 구조가 바뀔 때마다 이해도가 떨어짐.

4. 맥락 제공 (Context)

프로젝트 배경 설명

서비스: 소셜 미디어 플랫폼
사용자: 18-35세 모바일 사용자  
기술 스택: React, TypeScript, AWS
기존 시스템: 현재 페이지네이션 방식에서 무한스크롤로 전환

제약사항과 전제조건

기술적 제약: 기존 API 구조 유지, IE 지원 불필요
비즈니스 제약: 개발 기간 4주, 추가 서버 비용 최소화  
사용자 제약: 3G 환경 지원, 접근성 AA 등급 준수

왜 필요한가: 맥락 없이는 기술적으로 최선이지만 프로젝트에 맞지 않는 솔루션을 제안할 수 있음.

---

실무에서 바로 적용할 수 있는 PRD 템플릿

필수 섹션 구조

# [기능명] PRD

## 📋 프로젝트 정보
- 목적: [한 줄 요약]
- 담당자: [PM, 개발리드, 디자이너]  
- 일정: [시작일 - 완료일]
- 우선순위: [P0/P1/P2]

## 🎯 비즈니스 목표
- 해결할 문제: [구체적인 문제 정의]
- 성공 지표: [측정 가능한 KPI]
- 제약사항: [기술/비즈니스/일정 제약]

## 👤 사용자 시나리오  
- 주요 플로우: [단계별 사용자 행동]
- 예외 상황: [에러/실패 케이스]
- 다양한 상태: [로그인/비로그인, 권한별]

## ⚙️ 기능 명세
- 입력 데이터: [형식, 제약사항]
- 출력 결과: [화면 구성, 데이터 형태]
- 비즈니스 룰: [처리 로직, 검증 규칙]

## 🔧 기술 요구사항
- 성능: [응답시간, 처리량, 메모리]
- 호환성: [브라우저, 디바이스, 접근성]
- 보안: [인증, 데이터 보호]

## ✅ 완료 기준
- 기능 테스트: [테스트 시나리오]
- 성능 기준: [벤치마크 수치]  
- 사용성: [사용자 테스트 결과]

각 섹션별 작성 팁

비즈니스 목표 작성 시

• 정량적 지표 포함: "전환율 5% 향상", "로딩시간 50% 단축"
• 측정 방법 명시: "GA 이벤트로 추적", "성능 모니터링 도구 활용"
• 기간 설정: "출시 후 4주 내", "분기별 평가"

사용자 시나리오 작성 시

• 단계별 구체화: "버튼 클릭 → API 호출 → 결과 표시 → 다음 액션"
• 감정과 기대치 포함: "사용자는 즉시 결과를 보길 기대"
• 분기점 명시: "성공 시 A화면, 실패 시 B화면"

기능 명세 작성 시

• 데이터 형태 정의: "JSON 배열, 최대 20개 아이템"
• 검증 규칙: "필수 필드 확인, 길이 제한, 형식 검사"
• 에러 처리: "타임아웃 10초, 3회 재시도, 실패 시 캐시 데이터 사용"

---