PRD (제품 요구사항 문서)

만들기 전에 합의할 내용을 남긴다

‘문의 관리 앱을 만들어줘’라는 요청만으로는 누가 어떤 문의를 관리하고 언제 처리가 끝나는지 알기 어렵습니다. PRD는 이런 제품·기능의 요구사항을 공유하는 문서입니다.

Atlassian의 PRD 안내는 제품의 목적과 기능, 사용자 요구를 정리하는 역할을 설명합니다. 문서의 이름이나 양식보다 팀이 같은 요구를 보고 있는지가 중요합니다.

작은 기능의 PRD 예시

다음은 설명을 위한 가상의 문의 목록 기능입니다.

빈칸을 AI가 알아서 채운 뒤 합의된 요구로 취급하지 않습니다. 모르는 조건을 질문으로 남기면 구현할 범위와 확인할 범위를 나눌 수 있습니다.

업무 쪼개기와 구현 계획을 연결한다

업무 쪼개기는 원래 업무에서 무엇을 입력받아 어떻게 처리하는지 살펴봅니다. PRD는 그중 제품으로 만들 부분의 요구사항을 정리합니다. 구현 계획은 어떤 구조와 순서로 만들지 다룹니다.

기술 선택을 너무 일찍 고정하면 사용자의 문제가 아니라 선택한 도구에 맞춰 요구를 바꾸기 쉽습니다. 다만 이미 정해진 시스템이나 접근 제한은 실제 제약이므로 명시해야 합니다.

가상 화면과 실제 동작의 완료 기준을 나눈다

BOAZ의 리더 교육 교안은 PRD를 바탕으로 가상 데이터를 사용한 작은 데모를 만들고, 이후 직접 입력과 저장을 붙이는 순서를 다룹니다. 이때 데모에서 확인한 것과 실제 운영에서 확인할 것은 다릅니다.

화면의 버튼이 보이는지, 입력한 데이터가 데이터베이스에 저장되는지, 다른 사용자의 데이터가 섞이지 않는지를 각각 확인합니다. 외부 정보를 사용한다면 API의 응답 실패와 접근 조건도 요구사항에 반영합니다.

AI의 기능 제안을 범위와 대조한다

AI는 간단한 문의 목록에 통계·알림·관리자 화면을 덧붙일 수 있습니다. 유용한 제안일 수 있지만 이번 과제의 완료 조건과는 별개입니다.

이번에 만들 기능과 나중에 검토할 기능을 구분하고, 실제 필요한 기능 하나를 끝까지 확인합니다. 불분명한 요구는 설명이나 작은 화면으로 확인한 뒤 문서를 갱신합니다. 바이브 코딩에서도 이런 합의가 다음 수정을 판단할 기준이 됩니다.

PRD도 결과를 보고 고친다

문서를 처음에 완성한 뒤 고정하기보다, 실행과 사용자 확인에서 바뀐 판단을 남깁니다. 기능을 뺐다면 이유를, 완료 기준이 바뀌었다면 적용 범위를 기록합니다.

검증 Loop는 문서에 적힌 요구와 실제 결과를 대조합니다. 문서가 최신이어도 구현이 따라오지 않았을 수 있고, 구현을 고쳤어도 문서가 오래됐을 수 있습니다. 두 상태를 함께 확인해야 다음 작업이 같은 기준에서 시작됩니다.