PRD·TRD 꼭 작성해야 할까?

바이브 코딩을 시작할 때 제일 궁금한게, SNS에 있는 후일담입니다. 몇 마디 던졌더니 만들어줬다며 올려놓은거 보면 결과물이 장난 없던데;; 진짜 그렇게 되는건지 궁금합니다.

이런 거 하나 만들어줘.

그런거 못하는 입장에서 글을 쓰려니 좀 쫄리는데, 제 방법 잠깐 조금 소개 할께요.

프로젝트를 시작할 때는 잠깐만 그 마음을 참아보면 좋겠습니다. 코드가 나오기 전에 먼저 정해둘 것이 있어요. 무엇을 만들고, 왜 만들고, 어디까지 만들 것인가. 사실 이건 개발과 상관 없이 오롯이 나의 생각, 의도에 대한 질문입니다. 처음 이 질문에 대한 답을 잘 정해 놓으면 여러모로 도움이 됩니다. Agent에게도 도움이 되지만 저 스스로에게도 도움이 됩니다. ‘아, 맞다 내가 그걸 만드려고 했었지!’ 하는 순간이 와요ㅋㅋㅋ

저는 이걸 README, PRD, TRD에 나눠서 적어두고 시작합니다. AX Notes 앱을 만들 때도 그렇게 했고요. 그런데 문서부터 채우려고 하면 막막할 수 있습니다. 그 앞에 먼저 생각해볼 것이 있거든요. 누가 이걸 필요로 하는지, 지금은 어떻게 해결하고 있는지요.

저는 특히 초반에 프로젝트의 정체성을 정하는 데 힘을 많이 씁니다. 시장 조사도 시키고, 제 생각에 반대하는 의견과 비판도 강하게 요구합니다. 무엇을 만드는지 흐릿한 상태에서 기능부터 붙이면, 나중에는 저도 이게 뭐 하는 제품인지 설명하기 어려워질 수 있으니까요.

처음에는 넓게 묻고, 점점 좁혀가기

저는 시장 조사나 기획을 시작할 때 처음부터 질문을 촘촘하게 쓰는 편은 아닙니다. 일단 폭넓은 답변이 나올 만한 질문을 던집니다. 아직 제가 뭘 모르는지도 잘 모르니까요.

사람들이 읽은 글을 저장하고 다시 활용하는 방식에는 어떤 것들이 있을까? 어떤 사람들이 어떤 상황에서 불편을 겪는지도 넓게 살펴봐줘.

처음부터 “북마크와 메모 기능이 있는 앱의 경쟁사를 찾아줘”라고 하면, 이미 앱의 형태와 기능을 어느 정도 정한 채 시작하게 됩니다. 저는 그 전에 다른 가능성도 보고 싶은 거예요. 문제를 해결하는 방법이 꼭 새 앱일 필요는 없으니까요. 다른 분야에서도 종종 사용하는데, 일부러 폭넓게 물어봅니다.

넓게 질문하고 → 답변에서 갈림길을 찾고 → 비교하고 → 이번에 풀 문제를 정하는 방식입니다. 처음부터 완성된 기획을 한 번에 받아내려고 하기보다, 대화를 하면서 제가 원하는 것과 아직 모르는 것을 구체화하는 거죠.

그리고 대화 중간에 지금까지 선택한 방향과 선택 이유, 보류한 대안, 아직 확인하지 못한 가설을 요약해둡니다. 대화가 길어졌다는 이유만으로 결정까지 끝난 것은 아니고, 이게 또 길어지면 다시 보기 힘들더라구요. 그래서 문서화해놓는 다거나 issue로 등록해놔요.

시장 조사도 뚝딱

대충 윤곽이 정해졌을 때, AI가 진짜 잘하는게 시장 조사입니다. 솔직히 해봐서 아는데, 경쟁 제품 다 찾아보고 비교하는거 정말 빡세고, 품이 많이 가는 일입니다. 이게 시키기도 좋은게, 제품은 기본적으로 인터넷에 홍보가 되어 있어서 경쟁 제품 장단점에 대한 정보를 AI가 찾기도 수월합니다.

경쟁 제품은 같은 종류의 앱만 있는 게 아니고, 같은 플랫폼만 고집할 필요가 없죠. 이런것도 너무 좋은게, iOS 앱까지 느므 잘 분석해 줍니다.😎

여기서 주의할 것은 조사 보고서가 그럴듯하다고 수요까지 확인된 것은 아니라는 점입니다. AI가 경쟁 제품 몇 개를 찾고 “차별화 가능성이 높습니다”라고 써줘도, 그게 누군가 쓰겠다는 뜻은 아니더라구요. 기본적으로 AI는 아부쟁이라서ㅋㅋㅋ

누구를 위한 것인가: 대상 사용자와 페르소나

그다음에는 첫 사용자를 좁혀봅니다. “생산성을 높이고 싶은 모든 사람”이라고 하면 거의 모든 기능을 넣을 이유가 생깁니다. 시작할 때는 조금 더 구체적인 사람이 필요해요.

페르소나라고 하면 이름, 나이, 직업부터 채우게 되는데, 저는 어떤 상황에서 무엇을 하려다가 막히는 사람인지가 더 중요하다고 생각합니다. 페르소나 설정하고 문서화하는 것도 만만치 않은 작업인데, AI가 아주 잘해줍니다. 예전에는 글쎄 페르소나 설정할 때 실제 인물 인터뷰까지 했대요! 어머나! 그 시절에 알바비 받고 인터뷰한 1인

방향이 잡히면, 이번에는 강하게 반대해달라고 한다

넓게 묻고 좁혀가는 동안 제가 마음에 드는 답만 따라갈 수도 있습니다. 그래서 방향이 조금 잡히면 일부러 반대 의견을 요구합니다. “좋은 아이디어네요” 다음에 기능 목록이 나오는 것으로 기획을 끝내고 싶지는 않거든요.

저는 이 단계에서 꽤 강하게 비판해달라고 합니다. 이 제품이 왜 필요 없는지, 기존 제품을 두고 누가 굳이 옮겨올지, 제가 시장 조사에서 유리한 근거만 골라보고 있지는 않은지요. 다만 강한 비판은 말투가 센 비판보다 핵심 가정을 정확히 찌르는 비판이면 좋겠습니다.

지금까지 정리한 제품 구상을 가장 설득력 있게 반박해줘.
내가 이 제품을 만들고 싶어 한다는 이유로 결론을 좋게 맞추지 마.

- 누구의 어떤 문제가 충분히 중요하지 않을 수 있는가?
- 기존 도구를 계속 쓰는 편이 나은 이유는 무엇인가?
- 사용자가 새로 배우고, 데이터를 옮기고, 비용을 낼 이유가 있는가?
- 시장 조사에서 빠진 대안이나 결론과 충돌하는 근거는 무엇인가?
- 이 구상이 성립하려면 반드시 참이어야 하는 가정은 무엇인가?

각 비판에 근거와 불확실성을 적어줘. 근거가 없으면 가설로 표시해줘.
제품 방향을 무너뜨리는 문제와 나중에 고칠 수 있는 문제를 구분해줘.
중요한 비판부터 실제로 확인할 방법과 방향을 바꿀 조건을 제안해줘.

AI에게 반대하라고 했다는 이유만으로 그 답이 맞는 것은 아닙니다. 칭찬도 비판도 근거를 확인해야 해요. 제가 바라는 건 모든 아이디어를 기각하는 심사위원이 아니라, 제가 놓친 질문을 꺼내주는 상대입니다.

솔직히 이 과정은 매번하지는 않는데, 간단하게 반대의견이라도 꼭 물어는 봅니다. 근데, 이 AI 녀석은 금방 태새전환합니다. 그래서 그냥 ‘그렇구나~ 그랬구나~’ 하고 넋놓고 있으면 완전 산으로 갈 수 있어요. 가장 중요한 생각의 중심은 내가 꽉 붙들고 있어야해요. 솔직히 여기까지가 젤 힘들어요. 정말 힘든 일이고, 피곤할때는 잘 안되서 많이 할 수도 없고, 2~3일은 머릿속에 넣어두고 조금씩 계속 대화하면서 정리하는 편입니다.

README: 그래서 이게 뭐 하는 건데?

프로젝트를 한두 문장으로 설명할 수 있어야 합니다. 누구를 위한 것이고, 어떤 문제를 해결하는지요. 저는 AI 시대 이전부터 README 첫 한 줄, 첫 문장을 굉장히 중요하게 생각했는데, 변함 없이 가장 신경써서 작성합니다.😉

AX Notes 앱이라면 이렇게 시작할 수 있겠습니다.

AX Notes의 글을 읽고, 글에 연결된 생각을 남기는 개인용 읽기 앱이다. 다시 읽고 싶은 글과 내 메모를 쉽게 찾을 수 있게 한다.

이 문장이 있으면 기능을 추가할 때 돌아와서 물어볼 수 있어요. 이게 읽기와 메모에 도움이 되나? 지금 만드는 앱에 필요한가?

그리고 저한테는 내가 왜 이걸 만들고 싶은가도 중요합니다. 직접 쓸 것인지, 돈을 벌고 싶은 것인지, 새로운 개발 방식을 시험해보고 싶은 것인지. 목적이 다르면 시간을 쓸 곳도 달라지거든요. 개발 과정을 실험하는 게 목적이라면, 이용자가 많지 않아도 얻어갈 게 있습니다.

처음 README에는 거창한 내용이 필요하지 않습니다. 프로젝트 소개, 만들려는 이유, 첫 버전의 범위 정도면 출발할 수 있어요. 실행 방법이나 설치 방법은 실제로 돌아가는 것이 생겼을 때 맞춰서 채우면 됩니다.

PRD, TRD - 어렵게 생각하기 없기

PRD는 Product Requirements Document, 제품 요구사항 문서입니다. 무엇을 만들고 사용자가 어떤 경험을 하게 할지 적습니다.

여기서 중요한 것은 기능 이름을 많이 쓰는 게 아니에요. 요구사항을 행동과 결과로 적어두면 더 좋아요.

- 사용자는 글을 북마크하고 해제할 수 있다.
- 북마크를 해제해도 그 글에 작성한 메모는 남는다.

이 정도로 적으면 만들 때도 도움이 되고, 나중에 눌러보면서 확인하기도 쉬워집니다. “검색 구현 완료”라는 보고를 받았을 때 내가 뭘 확인해야 하는지도 알 수 있고요.

여기까지 정하면 일단 멈출 수 있는 지점이 생깁니다.

TRD는 Technical Requirements Document, 기술 요구사항 문서입니다. PRD에 적은 동작을 어떤 기술과 구조로 구현할지 정리합니다.

어떤 언어와 프레임워크를 쓸지, 데이터는 어디에 저장할지, 외부 시스템과 어떻게 연결할지, 어떻게 테스트하고 배포할지 같은 내용이 들어갑니다.

당연히 PRD, TRD 손으로 안씁니다. 하지만 리뷰는 꼭 해야해요. TRD는 모르는 내용이 많이 있을 수도 있는데, 간단하게 설명이라도 듣고 이해는 해야해요. 예를 들어, 백엔드 서버를 serverless api로 구성한다고 했을때, 비용 상항에 대한 대책이 어떻게 되는지 등이 기술 스택에 따라 달라질 수 있거든요.

공부한다 생각하고 쭈욱 읽어보고 모르는 부분 설명을 꼭 들으세요. 이거 모르는 거는, 차사면서 가솔린인지 디젤인지 신경 안쓰겠다는 거랑 같아요.

이 글에서 나눈 역할을 정리하면 이렇습니다. 프로젝트마다 문서 구성은 조금씩 달라도 됩니다.

README에는 개인용이라고 해놓고 PRD에는 팀 초대가 들어가 있거나, PRD에는 동기화가 없는데 TRD에는 사용자별 클라우드 저장소가 있다면 한 번 확인해야겠죠. 제가 중간에 생각을 바꾼 것일 수도 있고, AI가 제안하면서 범위를 넓힌 것일 수도 있습니다.

AI에게 문서 초안을 맡기는 것은 좋습니다. 다만 모르는 부분까지 알아서 확정하게 두면 안 됩니다. 아직 정하지 않은 것은 미정으로 남기고, 선택지를 달라고 하면 됩니다. 빈칸이 있는 문서가 그럴듯한 추측으로 채운 문서보다 다음 결정을 하기에는 낫습니다.

작은 프로젝트라면 한 파일에 세 영역을 나눠 적어도 충분합니다. 처음부터 문서 세 개를 빽빽하게 채우느라 힘을 다 쓸 필요는 없어요. 중요한 것은 파일 개수보다 내가 결정한 내용이 남아 있는가입니다. 코드는 안봐도 이 3개 문서는 꼭 봐야합니다!