PRD와 WRD를 이용해 AI 에이전트 잘 활용하기

현우

Apr 13, 20269d ago

왜 이 방식이 사용되고 있을까?

AI 코딩 도구가 처음 나왔을 때, 대부분의 사용법은 단순했다. 프롬프트로 함수 하나를 만들고, 수정하고, 반복하는 식이었다. 그런데 GPT-4 급의 모델이 대화 컨텍스트를 길게 유지하면서 더 복잡한 작업을 하게 되자, 기존 방식의 한계가 드러났다.

AI에게 프로젝트 전체를 설명하려면 대화 초반부터 엄청난 토큰을 소모하게 된다. 매 세션마다 같은 배경을 반복 설명해야 하고, 맥락이 흐릿한 상태에서 생성된 코드는 전체 구조와 맞지 않는 경우가 많다.

그 대안으로 나온 것이 문서를 먼저 작성하고, 그 문서를 AI의 참고 자료로 삼는 방식이다. 소프트웨어 개발에서 PM이 작성하던 PRD의 개념을 AI 개발 워크플로우에 끌어들인 것이다. WRD는 그보다 한 단계 더 내려가서, 실제로 어떤 기능들을 만들 것인지를 정리한 문서다.

PRD와 WRD는 무엇이고, 어떻게 다를까?

PRD(Product Requirements Document) — 제품이 왜 존재하는지를 정의한다

PRD(Product Requirements Document)는 제품의 목적, 사용자, 핵심 요구사항을 담은 문서다. "무엇을 만들 것인가"를 추상적인 수준에서 정의한다.

# PRD 예시 — 채용공고 알림 서비스

## 제품 목표
구직자가 원하는 기업의 채용공고를 놓치지 않도록
실시간으로 알림을 제공하는 서비스

## 대상 사용자
- 이직을 준비 중인 개발자
- 특정 기업/포지션을 주시하는 구직자

## 핵심 요구사항
- 사용자가 관심 기업과 직무를 등록할 수 있어야 한다
- 새로운 채용공고가 올라오면 24시간 이내에 알림이 발송되어야 한다
- 웹/앱 모두에서 접근 가능해야 한다

## 범위 밖
- 이력서 작성 기능
- 채용공고 지원 기능

PRD의 핵심은 프로덕션의 요구사항 범위(scope)를 명확히 하는 것을 의미하며, 무엇을 만들지만큼 무엇을 만들지 않는지를 적는 것이 중요하다. AI가 이 문서를 읽으면 프로젝트의 전체 맥락을 단번에 파악할 수 있다.

WRD — 구체적으로 어떤 기능을 만들지 정의한다

WRD(Work Requirement Document)는 PRD에서 정의한 요구사항을 바탕으로, 실제 구현할 기능들을 세부적으로 정리한 문서다. "어떻게 만들 것인가"를 기능 단위로 쪼갠다.

# WRD 예시 — 채용공고 알림 서비스

## 기능 목록

### 1. 관심 기업 등록
- 기업명 검색 자동완성 (최소 2글자 입력 시 동작)
- 최대 10개 기업 등록 가능
- 등록/삭제 API 필요

### 2. 알림 발송
- 신규 채용공고 감지 시 푸시 알림 발송
- 발송 주기: 매일 오전 9시 배치 처리
- 중복 알림 방지: 동일 공고 알림은 7일에 1회

### 3. 공고 목록 화면
- 무한 스크롤 방식
- 필터: 직무, 경력, 지역
- 정렬: 최신순, 마감순

## 기술 스택
- Frontend: Next.js, TypeScript, Tanstack-Query
- Backend: Node.js (API), Python (크롤러)
- DB: PostgreSQL

WRD는 개발자 관점에서 작성된다. AI가 이 문서를 읽으면 각 기능의 경계와 기술적 제약을 이해하고, 불필요한 추측 없이 구현에 집중할 수 있다.

플로우 방식에서 실제로 어떤 일이 일어날까?

AI가 문서를 어떻게 처리하는지 이해하면, 왜 이 방식이 효율적인지 더 명확하게 보인다.

[전통적인 AI 개발 방식]

사용자 ──→ "로그인 기능 만들어줘"
AI    ──→ (맥락 없이 일반적인 로그인 구현)
사용자 ──→ "아 근데 JWT 써야 해, 리프레시 토큰도 필요해"
AI    ──→ (수정)
사용자 ──→ "기존 DB 스키마랑 맞춰줘"
AI    ──→ (또 수정)
        ↑ 매번 맥락 재설명, 토큰 누적 소모


[플로우 방식]

PRD 작성 ─→ WRD 작성
              ↓
    AI에게 PRD + WRD 전달 (단 1회)
              ↓
    AI: 전체 맥락 파악 완료
              ↓
    "로그인 기능 구현해줘" ─→ JWT, 리프레시 토큰, DB 스키마까지
                              문서 기반으로 한 번에 구현

AI의 컨텍스트 창은 유한하다. 대화가 길어질수록 초반 내용이 밀려나고 맥락이 손실된다. PRD와 WRD는 대화보다 정보 밀도가 높다. 같은 내용을 대화체로 설명했을 때보다 구조화된 문서로 전달했을 때 훨씬 적은 토큰으로 동일한 맥락을 제공할 수 있다.

새로운 세션을 시작할 때도 마찬가지다. "지난번에 말했던 것처럼..."으로 시작하는 대신, 문서를 첨부하면 AI가 즉시 프로젝트 전체를 이해한 상태에서 작업을 시작한다.

PRD vs WRD — 역할과 작성 시점 비교

항목	PRD	WRD
목적	제품의 목표와 범위 정의	구현할 기능 목록 정의
추상화 수준	높음 (비즈니스 관점)	낮음 (개발자 관점)
작성 시점	프로젝트 착수 시	PRD 완성 후
주요 독자	팀 전체, 이해관계자	개발자, AI
업데이트 빈도	드물다	기능 추가/변경 시
AI 활용 방식	전체 맥락 제공	기능별 구현 지시

PRD가 먼저고 WRD를 추후에 작성하는 것이 순서이며, PRD 없이 WRD를 쓰면 기능 목록은 있는데 왜 그 기능이 필요한지 근거가 없어진다. 반대로 WRD 없이 PRD만 있으면 AI는 "어떤 기능을 만들어야 하는지"를 매번 다시 물어보거나 스스로 추론하게 된다.

실제로 어떻게 작성하면 좋을까?

PRD 작성 흐름

PRD를 처음 작성할 때 막막하면, AI에게 요구사항을 구어체로 설명하고 PRD 형태로 정리해달라고 요청하는 방법이 있다. 초안이 나오면 내가 직접 다듬는 방식이다. 멘토님은 이것을 계속 깎아나간다라고 말해주셨다.

프롬프트 예시:
"다음 내용을 PRD 형식으로 정리해줘.
 제품 목표, 대상 사용자, 핵심 요구사항, 범위 밖 항목으로 나눠서.

 [요구사항 설명]
 채용공고를 크롤링해서 사용자가 관심 있는 기업에 새 공고가 뜨면
 알림을 보내는 서비스를 만들려고 해..."

중요한 건 PRD를 AI가 대신 완성해주는 게 아니라, 내가 검토하고 결정하는 과정이 반드시 있어야 한다는 점이다. AI가 요구사항을 오해해서 잘못된 범위로 정리할 수도 있기 때문이다.

WRD 작성 흐름

PRD가 완성되면, 기능 목록을 뽑는 작업을 AI와 함께 진행하면 효율적이다.

프롬프트 예시:
"첨부한 PRD를 바탕으로 WRD를 작성해줘.
 각 요구사항을 구체적인 기능 단위로 쪼개고,
 각 기능에 필요한 세부 동작과 기술 제약을 포함해줘."

WRD는 기능이 추가될수록 계속 업데이트된다. 새 기능을 AI에게 구현 요청하기 전에 WRD에 해당 기능을 먼저 추가하는 습관이 중요하다. AI가 WRD 기준으로 코드를 생성하기 때문에, 문서와 코드베이스가 일치하는 상태를 유지하는 것이 전체 흐름의 핵심이다.

문서 길이는 얼마가 적당할까?

문서가 길면 오히려 AI가 전체를 처리하는 데 더 많은 토큰을 쓰고, 핵심이 희석될 수 있다.

권장 분량 기준:

PRD  ─→ A4 1~2페이지 (500~1000 토큰 내외)
WRD  ─→ 기능 10개 이내 권장, 각 기능당 3~5줄
         (전체 1000~2000 토큰 내외)

초과 시 조치:
- 기능이 너무 많으면 WRD를 도메인별로 분리
  예: WRD-auth.md, WRD-notification.md
- PRD는 최대한 간결하게 유지하고
  상세 내용은 WRD로 위임

AI에게 문서를 전달하는 방식

세션 시작 시점에 두 문서를 함께 첨부하는 게 기본이다.

[세션 시작 시 프롬프트 구조]

시스템 컨텍스트:
  - PRD 전문
  - WRD 전문
  - 현재 폴더 구조 (선택)

작업 요청:
  "WRD의 [기능 이름] 항목을 구현해줘.
   기술 스택은 PRD에 명시된 것을 따라줘."

문서를 매번 붙여넣는 게 번거롭다면, Claude Code나 Cursor 같은 도구에서 .context 파일이나 CLAUDE.md에 문서 경로를 지정해두는 방법도 있다. AI가 세션 시작 시 자동으로 문서를 읽게 된다.

이 방식이 모든 프로젝트에 맞을까?

그렇다면 WRD와 PRD, 이 두 문서를 이미 존재하는 프로젝트에 적용하는 것이 맞을지,

아니면 어떠한 속성을 가진 신규 프로젝트에 적용을 하는 것이 좋을지 궁금해졌다.

상황	플로우 방식 적합성
사이드 프로젝트 (기능 5개 이상)	적합
팀 프로젝트 (AI 협업 포함)	매우 적합
빠른 PoC/프로토타입	불필요할 수 있음
단순 함수 1~2개 생성	오버엔지니어링
장기 운영 서비스	적합 (문서 관리 비용 고려)

규모가 작은 작업이라면 문서 작성 자체가 더 많은 시간을 쓰는 경우도 있다. 플로우 방식은 프로젝트의 범위가 어느 정도 있고, 세션을 여러 번 나눠서 진행하는 상황에서 효과가 크다.

PRD와 WRD를 먼저 작성하는 것은 결국 AI가 아니라 내가 설계 주도권을 갖는 방식이다. AI에게 맡기더라도 반드시 내가 검증하고 판단하는 과정들은 필수적이다. AI에게 맥락을 설명하는 비용을 줄이고, 매번 다른 결과물이 나오는 불확실성을 줄이는 구조적인 접근이다.

신규로 진행하는 사이드 프로젝트의 경우 지금까지 요구사항을 한 페이지짜리 PRD로 먼저 정리해보는 것을 프로젝트의 출발점으로 잡고 있다. 어쩌면 모르는 사람에게 프로젝트를 설명해주는 것은 당연한 일인데, 이제는 AI를 단순 어시스턴트라기 보다는 하나의 동료라고 인식하는 것이 맞을지도 모르겠다.

悠悠

Subscribe to '悠悠自適'

Subscribe to my site to be the first to receive notifications and emails about the latest updates, including new posts.
Join Slashpage and subscribe to '悠悠自適'!