책에 포함된 노트혼자 만드는 AI 로봇: 개인 개발자를 위한 현실적인 로봇 제작 로드맵

22. 로봇 PRD 만들기

2026-04-25Views 112약 11분생성형 AI 활용

22. 로봇 PRD 만들기

로봇 PRD 만들기

아이디어를 명세로 바꾸는 순간, 로봇은 비로소 만들어진다

지난 장에서 우리는 문제를 고르고, 사용자를 정하고, 로봇이 해야 할 작업을 잘게 나누는 법을 살펴봤습니다. 거기까지가 "무엇을 왜 만들까"의 단계였다면, 이제는 "그래서 정확히 어떻게 만들까"로 넘어갈 차례입니다.

이때 필요한 것이 PRD입니다. PRD는 Product Requirements Document, 즉 제품 요구사항 문서입니다. 이름은 조금 딱딱하지만 뜻은 간단합니다. 이 로봇이 누구를 위해, 어떤 환경에서, 무엇을, 어느 수준까지, 어떤 비용과 위험 안에서 만들 것인지 적어 두는 문서입니다. 잘 쓴 PRD는 팀을 위한 문서이기도 하지만, 개인 개발자에게는 더 중요합니다. 미래의 내가 과거의 나와 싸우지 않게 해 주기 때문입니다.

개인 프로젝트가 흔히 무너지는 이유는 기술이 부족해서만이 아닙니다. 어제는 이동 로봇이었는데 오늘은 로봇팔이 붙고, 내일은 LLM 음성 비서가 되면서 목표가 계속 흔들리기 때문입니다. PRD는 이 흔들림을 줄여 줍니다. 무엇을 만들지뿐 아니라 무엇을 이번 버전에서는 만들지 않을지도 분명히 적어 두기 때문입니다. AI 제품 문서에서는 특히 이런 경계선이 중요하다고 자주 강조됩니다.¹²

왜 로봇 PRD는 더 꼼꼼해야 할까

앱은 잘못 만들면 불편합니다. 로봇은 잘못 만들면 부딪히고, 넘어지고, 멈추고, 충전이 바닥나고, 심하면 물건을 망가뜨립니다. 그래서 로봇 PRD는 일반적인 소프트웨어 PRD보다 더 넓어야 합니다. 화면과 기능만 적는 것으로는 부족합니다. 몸체, 센서, 모터, 전원, 배터리, 통신, 안전, 유지보수까지 들어가야 합니다.

여기에 AI가 들어가면 더 까다로워집니다. 보통 소프트웨어는 입력이 같으면 출력도 거의 같습니다. 하지만 AI 모델은 확률적으로 동작합니다. 즉, "대체로 잘 맞는다"와 "언제 틀릴 수 있다"를 함께 문서화해야 합니다. 그래서 AI PRD 템플릿들은 기능 설명만이 아니라 모델 성능 목표, 데이터 요구사항, 실패 모드, 사람의 개입 방식, 법적·윤리적 주의사항까지 함께 적도록 권합니다.³⁴⁵

로봇 PRD는 한마디로 이런 문서입니다.

기능 문서 + 하드웨어 명세 + AI 운영 규칙 + 안전 설계 + 유지 계획

멋진 이름보다 중요한 것은, 이 문서를 보고 나면 "이제 부품을 사고 코드를 짜도 되겠다"는 확신이 생겨야 한다는 점입니다.

로봇 PRD의 뼈대는 이렇게 잡는다

처음부터 거대한 문서를 쓰려고 하면 손이 멈춥니다. 그래서 로봇 PRD는 다음 순서로 잡는 것이 좋습니다.

한 줄 요약을 씁니다. 이 로봇이 무엇을 하는지 한 문장으로 적습니다.
문제와 사용자를 씁니다. 누구의 어떤 불편을 줄이는지 적습니다.
운영 환경을 씁니다. 어디서 움직이고, 어떤 방해를 받는지 적습니다.
핵심 시나리오를 씁니다. 사용자가 어떻게 시작하고, 로봇이 어떤 순서로 행동하는지 적습니다.
범위 안과 범위 밖을 나눕니다. 이번 버전에 꼭 들어갈 것과 일부러 빼는 것을 적습니다.²
하드웨어 구성을 적습니다. 몸체, 구동부, 센서, 컴퓨팅 보드, 통신, 전원 구조를 씁니다.
소프트웨어와 AI 구성을 적습니다. 어떤 모델을 어디서 돌리고, 어떤 기준으로 판단하는지 적습니다.³⁵
안전 요구사항과 실패 케이스를 적습니다. 잘될 때가 아니라 잘 안될 때 어떻게 할지를 먼저 씁니다.⁴⁵
비용, 배터리 시간, 유지보수를 적습니다. 만들 수 있는 프로젝트와 오래 굴러가는 프로젝트는 다르기 때문입니다.
성공 기준을 숫자로 적습니다. 어느 정도면 이번 버전이 성공인지 정합니다.

이 순서가 좋은 이유는 단순합니다. 문제를 정의한 뒤에야 하드웨어가 결정되고, 하드웨어가 정해져야 배터리와 비용이 계산되며, 그다음에야 안전과 유지 계획이 현실적으로 써지기 때문입니다.

좋은 PRD 문장은 기술 이름보다 행동이 먼저 나온다

PRD를 쓸 때 흔한 실수는 기능 이름을 잔뜩 쓰는 것입니다.

"객체 인식 지원" "음성 인터페이스 제공" "자율주행 기능 탑재"

이 문장들은 있어 보이지만, 실제로 개발할 때는 별로 도움이 되지 않습니다. 로봇 PRD에서는 기능 이름보다 행동 단위 문장이 훨씬 낫습니다.

예를 들어 이렇게 바꿔 써 보세요.

사용자가 "순찰 시작"을 말하면 로봇은 충전 위치에서 출발해 지정된 두 지점을 방문한다.
로봇은 각 지점에서 카메라 이미지를 촬영하고, 지정된 물체가 있는지 판단한다.
판단 신뢰도가 낮으면 결과를 확정하지 않고 사진과 함께 사용자 확인을 요청한다.

이렇게 쓰면 센서가 왜 필요한지, AI 모델이 어디에 들어가는지, 실패했을 때 어떤 예외가 생기는지가 자연스럽게 따라옵니다.

좋은 PRD는 보통 "무엇을 넣을까?"보다 "로봇이 실제로 무엇을 하게 될까?"를 더 자세히 씁니다.

범위 밖을 먼저 적으면 프로젝트가 산으로 가지 않는다

개인 개발자는 욕심이 많습니다. 사실 그건 좋은 일입니다. 문제는 그 욕심이 한 버전에 다 들어가려 할 때 생깁니다.

그래서 PRD에서 아주 중요한 부분이 Out of Scope, 즉 이번 버전에서 하지 않을 일입니다. 이 항목은 소극적인 선언이 아니라 프로젝트 생존 장치입니다.²

예를 들어 책상 안전 점검 로봇을 만든다면, 이번 버전의 범위 밖은 이렇게 적을 수 있습니다.

책상 위 물건을 집어서 옮기는 기능은 넣지 않는다.
완전 자유 대화형 챗봇은 넣지 않는다.
방 전체를 돌아다니는 이동 기능은 넣지 않는다.
클라우드 없이는 동작할 수 없는 구조는 피한다.

이렇게 써 두면 개발 중간에 "여기까지 왔는데 로봇팔도 달아 볼까?"라는 유혹이 와도 문서가 브레이크를 걸어 줍니다. 좋은 PRD는 열정을 꺾는 문서가 아니라, 열정이 새지 않게 하는 문서입니다.

하드웨어 구성은 부품 쇼핑 목록이 아니라 역할 설계도다

로봇 PRD에서 하드웨어 구성은 단순한 부품 나열로 끝나면 안 됩니다. 중요한 것은 왜 이 부품이 필요한지입니다.

예를 들어 "카메라 1개"라고만 적으면 부족합니다. 대신 이렇게 적는 편이 좋습니다.

전방 카메라 1개: 물체 인식과 사용자 확인용 이미지 캡처
IMU 1개: 자세 변화 감지와 충돌 직후 이상 상태 판단 보조
거리 센서 2개: 근거리 장애물 감지와 정지 조건 판단
SBC 1개: 비전 처리, 상위 제어, 네트워크 통신
MCU 1개: 모터 제어와 긴급 정지 같은 저수준 제어

이 문장들에는 역할이 들어 있습니다. 역할이 들어가면 대체 부품을 찾기도 쉬워집니다. 카메라 모델이 바뀌어도 "전방 이미지 캡처용"이라는 역할은 그대로니까요.

소프트웨어 구조도 함께 적어 두면 좋습니다. 만약 시스템을 ROS 2 기반으로 짠다면, 어떤 노드를 둘지까지 적을 수 있습니다. 로봇 개발에서는 ROS 2가 여전히 가장 널리 쓰이는 오픈소스 기반 중 하나이고, 새로 시작한다면 LTS 배포판 선택도 PRD에 적어 두는 편이 좋습니다.⁶ Jetson 기반의 카메라 처리 비중이 높다면 Isaac ROS 같은 GPU 가속 패키지 사용 여부도 미리 결정해 두면 나중에 구조가 덜 흔들립니다.⁷

센서와 AI 모델은 항상 짝으로 적는다

로봇 프로젝트에서 센서만 적어 놓고 모델을 안 적는 경우가 많습니다. 반대로 모델 이름만 적고 입력 데이터 구조를 안 적는 경우도 많습니다. 둘 다 위험합니다.

카메라는 그냥 카메라가 아닙니다. 무엇을 보기 위한 카메라여야 합니다. 모델도 그냥 "YOLO 사용"이 아닙니다. 무엇을 언제 얼마나 빨리 구분해야 하는 모델이어야 합니다.

그래서 PRD에는 최소한 다음 다섯 가지를 적는 편이 좋습니다.

입력은 무엇인가
출력은 무엇인가
성능 목표는 무엇인가
지연 시간 한도는 얼마인가
확신이 낮을 때 대체 행동은 무엇인가

예를 들어 이렇게 쓸 수 있습니다.

"전방 카메라 이미지를 입력으로 받아 사람, 컵, 책, 문 손잡이 네 클래스를 감지한다. 목표 정확도는 테스트 환경 기준 90퍼센트 이상, 추론 지연 시간은 300ms 이하로 한다. 신뢰도 0.6 미만이면 자동 행동을 실행하지 않고 사용자에게 화면을 보여 준다."

이 정도만 적어도 개발 방향이 훨씬 또렷해집니다. AI/ML PRD에서는 이런 식으로 기능 요구사항과 모델 요구사항을 분리해서 적는 습관이 중요하다고 강조합니다.⁴⁵

안전 요구사항은 "정상 동작"보다 "이상 동작"을 먼저 쓴다

로봇은 잘 움직일 때보다, 이상할 때 어떻게 멈추는지가 더 중요합니다. 그래서 PRD의 안전 항목은 뒤에 슬쩍 붙이는 부록이 아니라 중심부에 있어야 합니다.

로봇 PRD의 안전 요구사항은 보통 세 층으로 나누어 적으면 좋습니다.

첫째는 물리 안전입니다. 속도 제한, 힘 제한, 충돌 시 정지, 낙하 방지, 손 끼임 방지 같은 항목이 들어갑니다.

둘째는 시스템 안전입니다. 센서가 끊기면 어떻게 할지, CPU가 과열되면 어떻게 할지, 배터리 전압이 떨어지면 어떻게 할지 같은 항목입니다.

셋째는 AI 안전입니다. 모델이 자신 없어할 때 자동 실행을 중단할지, 사람 검출이 애매할 때 접근을 금지할지, 음성 명령을 잘못 들으면 재확인을 요구할지 같은 항목입니다.⁵

예를 들면 이런 문장이 PRD에 들어갈 수 있습니다.

장애물 거리 20cm 이내에서는 자동 전진 금지
카메라 입력 2초 이상 손실 시 모터 정지
배터리 잔량 15퍼센트 이하에서는 복귀 모드만 허용
음성 명령 인식 확신도가 낮으면 "다시 말씀해 주세요"로 응답하고 실행하지 않음
사람 손이 로봇팔 작업 구역에 들어오면 즉시 정지

이런 문장들은 재미는 덜하지만, 실제 로봇 품질을 결정하는 문장들입니다.

실패 케이스를 써 두면 디버깅 시간이 절반으로 줄어든다

PRD를 쓸 때 꼭 넣어야 하는 또 하나는 실패 케이스입니다. 실패 케이스는 "뭘 잘못했을 때 혼나는 목록"이 아니라, 예상 가능한 실패를 미리 설계에 포함시키는 장치입니다.

로봇에서 자주 만나는 실패는 대개 비슷합니다.

카메라가 안 잡힌다.
와이파이가 끊긴다.
라이다 데이터가 튄다.
바퀴가 헛돈다.
조명이 바뀌어 인식률이 떨어진다.
배터리가 생각보다 빨리 닳는다.
모델이 애매한 물체를 확신 있게 틀린다.

이런 실패를 PRD에 적을 때는 세 줄 구조로 쓰면 좋습니다.

실패 조건 → 감지 방법 → 대응 방식

예를 들어,

"전방 카메라 프레임 수신이 2초 이상 중단되면 카메라 오류로 판단하고, 모터를 정지한 뒤 모바일 알림을 보낸다."

또는,

"지정 물체 인식 신뢰도가 0.6 미만이면 판단 보류로 기록하고, 자동 집기 대신 사진 확인 요청으로 대체한다."

이렇게 써 두면 개발자가 바뀌어도, 시간이 지나도, 로봇이 이상하게 행동할 때 어디서부터 봐야 할지 기준이 생깁니다.

비용은 부품값만 적으면 안 된다

처음 로봇을 만들 때는 보드와 센서 가격만 더해 보고 "생각보다 싸네?"라고 느끼기 쉽습니다. 하지만 실제 총비용은 늘 그보다 큽니다. PRD에는 최소한 세 가지 비용을 나눠 적는 것이 좋습니다.

시제품 비용: 보드, 센서, 모터, 프레임, 배터리, 충전기, 케이블, 나사, 공구
운영 비용: API 사용료, 클라우드 서버, 교체 부품, 소모품
실패 비용: 추가 구매, 파손, 잘못 산 부품, 테스트용 예비품

개인 프로젝트에서는 특히 세 번째가 큽니다. 한 번에 정답 조합을 사는 일은 거의 없기 때문입니다. 그래서 PRD 예산에는 보통 예상 부품비의 20~30퍼센트 정도 여유분을 따로 잡아 두는 편이 안전합니다.

또 하나 중요한 것은, 로봇은 움직이는 순간 유지비가 생긴다는 점입니다. 바퀴 타이어, 기어박스, 서보, 배터리는 모두 닳습니다. PRD에 유지보수 주기를 적는 이유가 바로 여기 있습니다.

배터리 시간은 감으로 쓰면 안 된다

로봇 PRD에서 배터리 시간은 자주 희망사항으로 적힙니다.

"한 번 충전하면 오래 갔으면 좋겠다."

이 문장은 소원이지 요구사항이 아닙니다. 요구사항은 숫자여야 합니다.

가장 쉬운 계산은 이렇습니다.

배터리 에너지(Wh) = 전압(V) × 용량(Ah)

그리고

예상 구동 시간(h) = 배터리 에너지(Wh) ÷ 평균 소비전력(W)

예를 들어 11.1V, 5Ah 배터리라면 약 55Wh입니다. 평균 소비전력이 20W인 로봇이라면 이론상 약 2.7시간이지만, 실제로는 전압 변환 손실, 순간 피크 전류, 안전 여유를 고려해야 하므로 이보다 짧게 잡아야 합니다. 실전에서는 보통 계산값보다 여유 있게 보는 편이 좋습니다.

배터리 종류 선택도 PRD에 적어 두는 것이 좋습니다. 모바일 로봇에서는 Li-Ion, Li-Poly, NiMH가 자주 쓰이고, 납축전지는 무게 대비 에너지 밀도와 반복 충방전 특성 때문에 이동 로봇에는 대체로 덜 적합하다는 설명이 많이 쓰입니다.¹⁰ 소형 Jetson 프로젝트에서는 보드 자체는 5V 입력으로 전원 공급을 받더라도, 실제 로봇 전체는 18650 셀 기반 팩과 DC/DC 전원 구조를 쓰는 경우가 많습니다.⁸⁹

다만 여기서 가장 중요한 것은 성능보다 안전입니다. 리튬 계열 배터리는 편리하지만, 충전기 호환성, 셀 혼용 금지, 보호 회로, 열 관리, 보관 수칙을 무시하면 위험할 수 있습니다. 키트 문서들조차 이 점을 매우 강하게 경고합니다.⁹

즉, PRD에는 단순히 "배터리 사용"이라고 쓰지 말고 이렇게 적는 편이 좋습니다.

목표 연속 동작 시간: 90분 이상
충전 방식: 전용 충전기 사용
저전압 보호: 15퍼센트 이하 자동 복귀
배터리 팩 구조: 3S Li-Ion, 보호회로 포함
교체 주기: 300회 충방전 또는 성능 80퍼센트 미만 시 점검

이렇게 쓰면 전원 문제가 감이 아니라 설계가 됩니다.

유지보수 항목을 적는 순간, 장난감에서 제품으로 넘어간다

많은 사람이 PRD를 기능 문서라고 생각합니다. 하지만 좋은 로봇 PRD는 유지 문서의 시작점이기도 합니다.

유지보수 항목에는 거창한 것이 필요하지 않습니다. 대신 아주 현실적이어야 합니다.

예를 들어 다음과 같은 내용이 들어갈 수 있습니다.

카메라 렌즈 청소 주기
바퀴 마모 점검 주기
서보 유격 확인 주기
배터리 건강도 점검 주기
로그 저장 기간
모델 재학습 또는 재평가 주기
펌웨어 업데이트 방식
원격 접속 복구 절차

이 항목이 중요한 이유는 간단합니다. 로봇은 첫 주보다 넷째 주에 더 많은 문제가 생기기 때문입니다. 책상 위에서 잘 되던 카메라가 먼지 때문에 흐려지고, 처음엔 조용하던 기어가 느슨해지고, 배터리가 조금씩 약해집니다. PRD에 유지보수를 적어 두면, 로봇의 수명이 기능 추가 속도보다 길어집니다.

실전 예시: 책상 안전 점검 로봇 PRD

이제 지난 장의 아이디어를 실제 명세로 바꿔 보겠습니다. 완벽한 문서라기보다, 개인 개발자가 바로 개발을 시작할 수 있는 수준의 예시라고 보면 됩니다.

제품 개요

제품명: DeskGuard Mini
한 줄 설명: 퇴근 전에 책상 위 위험 물건 상태를 30초 안에 점검하고, 이상이 있으면 음성과 메시지로 알려 주는 고정형 소형 로봇

문제와 사용자

주 사용자는 혼자 전자 작업을 하는 메이커 또는 하드웨어 개발자입니다. 이 사용자는 퇴근 직전 인두 전원, 배터리 충전기 상태, 특정 공구 위치를 자주 확인해야 하지만 반복 작업이라 자주 깜빡합니다.

현재 해결 방식은 사람이 눈으로 직접 확인하는 것입니다. 문제는 피곤한 날일수록 이 확인이 가장 잘 빠진다는 점입니다.

운영 환경

책상 크기는 약 120cm × 60cm입니다. 실내 고정 조명 환경이며, 로봇은 책상 한쪽에 고정 설치됩니다. 이동 기능은 없고, 2축 팬-틸트로 시야를 바꿉니다. 인터넷이 끊겨도 최소한 로컬 경고음은 동작해야 합니다.

핵심 시나리오

사용자가 퇴근 버튼을 누르거나 음성으로 "퇴근 점검 시작"이라고 말합니다. 로봇은 카메라 각도를 순서대로 바꿔 세 구역을 촬영합니다. 각 이미지에서 인두 전원 상태, 충전기 LED 상태, 지정 물체 존재 여부를 판단합니다. 위험이 감지되면 경고음을 울리고, 모바일 메시지로 사진과 함께 알립니다. 확신이 낮으면 "확인이 필요합니다"라는 문구와 함께 사진만 전송합니다.

범위 안

책상 위 3개 구역 순차 스캔
전원 LED 상태 판별
지정 물체 존재 여부 확인
음성 시작 명령 3개 이하 지원
모바일 알림 전송
로컬 경고음 출력

범위 밖

물건을 집어 옮기는 기능
방 전체를 돌아다니는 이동 기능
자유 대화형 챗봇 기능
클라우드가 없으면 전혀 동작하지 않는 구조
사용자별 맞춤 대화 성격 설정

하드웨어 구성

SBC 1대: 라즈베리파이 5급 또는 동급 보드, 상위 로직과 네트워크 담당
MCU 1대: 서보 제어와 부저 제어 담당
1080p 카메라 1대: 상태 인식용
2축 팬-틸트 서보 1세트: 시야 전환용
마이크 1개: 짧은 음성 명령 인식용
스피커 또는 부저 1개: 경고 알림용
외부 전원 어댑터 기본, 선택형 배터리 팩 지원

소프트웨어와 AI 구성

상태 인식 1: LED 켜짐/꺼짐 분류 모델 또는 규칙 기반 비전
상태 인식 2: 지정 물체 존재 감지용 경량 객체 인식 모델
음성 인식: 제한된 명령어 세트만 지원
로컬 우선 동작, 네트워크 가능 시 메시지 전송
로그 저장: 최근 200회 점검 기록 보관

성능 목표

30초 안에 전체 점검 완료
지정된 3개 대상 상태 판별 정확도 95퍼센트 이상
알림 전송 지연 5초 이하
확신도 낮음 판정 비율 월 평균 10퍼센트 이하
네트워크 장애 시 로컬 경고 기능 100퍼센트 유지

안전 요구사항

팬-틸트 속도 제한으로 손 끼임 방지
카메라 프레임 수신 실패 시 스캔 중단
점검 결과가 애매할 때 자동 안전 판정 금지
선택형 배터리 사용 시 보호회로 포함 팩만 허용
과열 감지 시 음성 기능 중단 후 경고만 유지

실패 케이스와 대응

카메라 연결 실패: 즉시 점검 중단, 앱 알림, 수동 확인 요청
네트워크 끊김: 로컬 경고음만 출력, 재연결 후 결과 업로드
모델 확신도 부족: 위험 확정 대신 사진 검토 요청
조명 부족: 조명 부족 경고 후 재시도 1회
배터리 잔량 부족: 점검 시작 거부 또는 어댑터 연결 요청

비용 목표

시제품 총비용은 25만~40만 원 사이를 목표로 합니다. 여기에 예비 케이블, 여분 서보, 마운트 재출력 비용까지 포함해 30퍼센트의 완충 예산을 추가합니다.

전원과 배터리

기본 운영은 어댑터 전원입니다. 이동형 버전을 대비해 선택형 배터리 팩 구조를 열어 둡니다. 목표 배터리 동작 시간은 2시간 이상이지만, 1차 버전에서는 배터리보다 안정적인 유선 운영을 우선합니다. 작은 개발 보드 기반 프로젝트에서도 전원 입력 조건과 배터리 팩 구성이 프로젝트마다 꽤 다르므로, PRD에서 이 부분을 먼저 잠가 두는 것이 좋습니다.⁸⁹

유지보수

주 1회 카메라 렌즈 청소
월 1회 서보 유격 점검
월 1회 점검 실패 로그 검토
분기 1회 모델 성능 재측정
배터리 버전 사용 시 충방전 기록 관리

이 정도만 적어도 프로젝트가 훨씬 현실적으로 바뀝니다. 이제는 "AI 책상 로봇"이 아니라, 어떤 부품으로 어떤 순서로 어떤 실패를 감수하며 만들 제품인지 보이기 시작합니다.

소프트웨어 스택도 PRD에서 미리 잠가 두자

개인 개발자는 자주 이런 함정에 빠집니다. 하드웨어를 조립한 뒤에야 "아, 이건 ROS 2로 짜야 하나?"를 고민합니다. 하지만 그 질문은 PRD 단계에서 하는 편이 훨씬 낫습니다.

예를 들어 프로젝트가 단일 보드, 단일 카메라, 단순 제어라면 파이썬 스크립트와 작은 서비스 구조만으로도 충분할 수 있습니다. 반면 카메라, 라이다, 모터 제어, 원격 명령, 로그 수집, 지도화가 함께 들어가면 ROS 2가 편해집니다. 지금 시점에서는 ROS 2 LTS 배포판을 기준으로 시작하는 것이 무난하고, Jetson에서 카메라 처리와 인지 파이프라인 비중이 큰 경우 Isaac ROS를 고려하면 성능 최적화 여지가 큽니다.⁶⁷

즉, PRD의 소프트웨어 섹션에는 최소한 이런 질문에 답이 있어야 합니다.

단일 프로세스 구조인가, 노드 기반 구조인가
온디바이스 추론인가, 클라우드 추론인가
로그는 로컬에 남길 것인가, 서버로 보낼 것인가
원격 업데이트가 필요한가
오프라인에서도 핵심 기능이 살아야 하는가

이 다섯 가지가 안 정해지면, 코드는 결국 "일단 돌아가게만 만든 파일"들로 늘어나기 쉽습니다.

PRD는 한 번 쓰고 끝나는 문서가 아니다

잘 만든 PRD도 처음부터 완벽하지는 않습니다. 오히려 처음 버전은 틀릴 가능성이 높습니다. 중요한 것은 빨리 틀리고, 문서를 고치고, 다시 확인하는 것입니다. AI 제품 문서가 살아 있는 문서라고 불리는 이유도 여기에 있습니다.¹

예를 들어 처음에는 "객체 인식 정확도 95퍼센트"를 목표로 잡았는데, 실제 책상 조명 변화 때문에 80퍼센트도 어려울 수 있습니다. 그러면 문서를 고쳐야 합니다. 조명을 고정하는 쪽으로 환경 요구사항을 강화할지, 모델을 바꿀지, 사용자가 마지막 확인을 하도록 시나리오를 바꿀지 결정해야 합니다.

즉, PRD는 계획서이면서 동시에 학습 기록입니다. 개발하면서 바뀐 사실을 반영하지 않는 PRD는 멋진 문서일 수는 있어도, 좋은 문서는 아닙니다.