소개
구상중인 앱서비스 개발을 위한 구체화를 위해 PRD, MRD 를 작성했습니다.
맥락을 충분히 반영하고 일관되도록 chatGPT Project 를 이용
각 단계마다 평가하고 평가를 반영해 다시 작성하는 방식으로 PRD를 고도화
MRD 를 위한 딥리서치 프롬프트 작성, 결과를 비교 통합
진행 방법
사용한 도구 :
PRD GPTs : Product Requirements Document (PRD) Writer
ChatGPT
DeepResearch(GPT, Grok, Perplexcity)
1. GPTs 를 이용한 PRD 작성
사용한 GPTs 는 단계적으로 대략 8개의 질문을 합니다. 질문에 대한 답변을 제가 직접하기 않고 ChatGpt 에게 하도록 했습니다. 그동안 서비스 관련 작업을 했던 "ChatGPT Project" 을 이용했습니다.
챗지피티의 프로젝트는 그 안에 파일이나 대화내용을 사용하기 때문입니다. 그동안 제가 한 작업에 근거해 PRD GPTS의 8가지 질문에 ChatGPT 가 한 답변을 정리해서 PRD Gpts 에 제공했어요.
2. PRD 평가(4o VS o3)를 반영해 PRD 업그레이드
PRD 작성히 여러 모델을 사용하고, 각 모델의 결과를 평가했습니다.
o3 : 단순 평가
4o VS o3 : PRD 에 대한 섹션별 목적에 근거해 평가
언제나 맥락이 중요해서인지 평가 기준을 주었을 때 결과가 더 좋았습니다.
1번에서 작성된 PRD를 두 모델에서 평가했습니다.
PRD 의 섹션명과 그 목적을 평가 기준으 로 제시한 경우
두 모델의 결과 비교 평가(o3)
평가결과로 개선된 PRD 작성
위는 개선 전 PRD에 대한 평가표, 아래는 평가 결과가 반영된 PRD 평가표입니다.
심층평가표, 액션 리스트 등의 결과물을 생각지 못한 부분이었습니다.
평가표를 보고 존재하지 않은 부분들 중에서 기술스택, 아키텍쳐 설계와 벤치마킹 리서치를 했습니다.
3. 기술스택, 아키텍쳐 o3 설계
사진 첨부를 위해 간단히 정리했습니다.
학습된 일반적인 정보를 활용하다 보니 제가 그것과 다른 방향으로 가고자 할때는 반영이 잘 안됩니다.
기능과 기술스택을 연결해서 살펴보니, 아래의 1, 2번이 전부인 서비스를 만들고 싶은데 "실시간 조회"가 들어가 있습니다. 그냥 '안들어간다' 보다는 현실적 한계나 단순 학습용 프로젝트라고 하면 과한 PRD 가 수정될 확률이 높습니다.
잠시 데이터를 어떻게 할지가 고민이어서 최근에 보고 있는 firebase 에 대해 물어봤습니다. 모두 사실인지는 공부를 해가며 봐야겠지만 매우 잘 말해주네요.
4. 벤치마킹, 경쟁앱 리서치를 위한 프롬프트 작성
딥리서치 또한 프롬프트에 따라 결과가 많이 달라집니다. 이전 맥락을 가진 챗창에서 딥리서치용 프롬프트를 작성했습니다.
o3 는 추론모델은 작업의 맥락만 유지되면 지가 알아서 잘 합니다. 그게 추론이기 때문입니다.
4o 와 달리 결과 형식까지 작성했습니다.
프롬프트 역시 두 모델에 근거해 작성하고 비교했습니다.
딥리서치 프롬프트 4o VS o3 비교
#1 : 4o 프롬프트 , #2 : o3 프롬프트
장단점을 요약하고 추천 활용시나리오도 제시합니다.
저는 o3 가 만든 #2 프롬프트를 사용했습니다.
chatGPT 의 조사 범위를 묻는 추가 질문에 대해서도 두 모델에게 동일하게 물었습니다. 답변이 상이했으며 o3의 답변으로 진행했습니다.
5. DeepResearch(GPT, Grok, Perplexcity) 결과
이미지는 ChatGPT 결과만 첨부했습니다.
프롬프트 단계에서 직접 경쟁상대와 간접 경쟁 상대를 어떻게 볼 것인지에 대한 논의가 있었습니다.
4o 와 o3 가 다르게 보고 있었습니다. 모두 구체화된 PRD 에 근거하도록 챗창을 유지했습니다.
이로서 대략적인 시장조사는 더 적합하게 할 수 있습니다.
GPT, Grok, Perplexcity 의 인사이트가 모두 달랐습니다. 수익모델에 대해서도 언급해 아이디어 확장과 검증에 매우 유용했습니다.
결과와 배운 점
ChatGPT 프로젝트 기반으로 서비스 아이디어 정리를 하고 결 과에 대한 비교 평가를 반영한 고도화 방식은 매우 유용했습니다.
PRD를 고도한 이후 누락된 항목에 요구하거나 관련 딥리서치 프롬프트를 작성할 경우 서비스의 내용이 더 충분히 포함된다고 생각합니다. 연역적인 접근은 언제나 효과가 좋았습니다.
