AI로 협업 검수 도구 만들기 - PRD작성 편(2)
유연한 협업을 위한 프로덕트 디자이너의 바이브 코딩 기록
문제 정의에 이어, 이번 편에서는 PRD 작성 과정에 대해 기록합니다. 기능을 어떻게 정의하고 우선순위를 결정했는지에 대한 내용이에요.
앞단에서 문제를 정의하고 필요한 기능을 나열한 후, 구체적으로 PRD를 작성했다. 잠깐 PRD 작성의 중요성에 대해 언급하고 넘어가자면 이렇다. 무엇을 만들 것인지 AI가 이해할 수 있는 형태로 번역하는 작업에 가깝다. AI는 내가 원하는 결과를 알아서 추론해주지 않는다. “이미지 가이드 검수 사이트를 만들어줘.”라는 문장만으로는 내 머릿속에 있는 맥락과 화면 흐름이 전달되지는 않는다.
결국 PRD 작성은 AI에게 맥락을 정리해서 전달하기 위한 작업이면서, 동시에 내가 만들 제품의 범위를 스스로 구체화하는 과정이기도 하다.
어떤 내용을 담아야 할까
PRD는 크게 세 가지 질문에 답하는 구조로 작성했다. 이 세 질문이 정리되면 기능의 우선순위나 범위가 좁혀지기 때문이다.
1️⃣ 누가 쓸 것인가
주요 사용자는 비디자이너로 구성된 운영팀이다. 이미지를 직접 제작하거나 외주를 맡기고 회사 어드민에서 이미지와 관련 내용을 업로드한다. 가이드는 존재하지만 실제 검수는 개인의 경험과 감각에 의존하는 경우가 많았다. 1편에서 정의한 문제를 바탕으로 페인포인트를 정리하면 다음과 같다.
배너 규격(이미지 사이즈 등)이 가이드와 다르게 업로드되는 경우 발생
다양한 디바이스(모바일 앱/웹)에서 배너가 어떻게 보이는지 미리 확인하기 어려움
현재 노션 가이드에는 증정품 영역에 대한 규칙이 별도로 명시되어 있지 않음
콘텐츠를 업로드하기 전에 가이드를 준수했는지 확인하고 싶지만 스스로 판단하기 어려움
실제 업무 시 가이드 위반 케이스가 다수 발생하며 수정과 재업로드 반복여기서 핵심은 “검수를 해야 하는데 제대로 판단했는지 확신하기 어렵다”라는 것이다. 즉 그들에게는 “판단을 가능하게 해주는 구조”가 필요했다.
2️⃣ 무엇을 검수해야 하는가
검수 항목은 다음과 같이 정리했다.
이미지 규격(사이즈, 용량, 포맷, 오브젝트의 위치)
텍스트 글자 수
중복 문구 입력 여부
뷰포트 별 말줄임 시뮬레이션
검수 항목을 나열하다 보니, 자동으로 처리할 수 있는 것과 사람이 직접 확인해야 하는 것을 어떻게 나눌지 다음 고민으로 이어졌다.
3️⃣ 어떻게 배포할 것인가
개발 환경 없이 HTML 단일 파일로 구현하고 GitHub Pages에 올려 관리하기로 했다. 빠르게 공유하고 실제 사용 피드백을 받는 것이 더 중요했기 때문이다. 별도 서버나 빌드 과정 없이 URL 하나로 바로 공유할 수 있고 수정 사항을 즉시 반영할 수 있다는 점에서 팀에 전달하기에도 적합한 방식이었다.
자동화의 경계 결정하기
PRD를 작성하며 기능을 고민할 때 가장 시간이 많이 걸린 부분이다. 처음에는 검수 항목 대부분이 수치 기반일 것이라 판단해 모두 자동화가 가능할 것이라고 생각했다. 그러나 검수 기준을 구체화하다 보니, 사람의 판단이 필요한 부분이 있었다.
이미지 사이즈, 용량, 포맷 등 숫자나 텍스트 비교로 판단할 수 있는 것들은 명확하게 자동으로 처리할 수 있는 항목이었지만 배경이 올바른 색상인지, 이미지 안에 텍스트가 삽입되어 있는지, 이미지의 여백은 시각적으로 안정적인지 등은 자동화가 아니라 판단의 영역에 가까웠다. 기술적으로 구현하는 것은 가능하겠지만, 난이도와 복잡도를 고려해 보았을 때 MVP에서는 제외하기로 했다.
그래서 수동 확인이 필요한 항목은 담당자가 직접 확인하며 기준에 부합한 지 체크하는 방식으로 제공하기로 결정했다. 100% 자동화는 아니지만 기준이 명시되는 것만으로도 판단의 부담은 줄어들 것이기 때문이다.
PRD 작성 과정에서 AI 활용하기
PRD 작성 자체에도 AI를 활용했다. 검수 항목을 분류할 때도 “이 항목은 자동 판정이 가능한가, 판단이 필요한가”를 기준으로 함께 점검하면서 내가 놓친 고려사항을 보완하고 완성한 후에는 그 내용을 그대로 Google AI Studio 프롬프트로 변환했다.
요구사항을 정리한 PRD 일부
Google AI Studio 프롬프트 일부AI와 대화하면서 가장 유용했던 점은 기존 노션 가이드를 실행 가능한 조건으로 번역하는 작업이었다. 실제 검수 도구로 구현하려면 기존 가이드를 수치와 조건으로 다시 정의해야 했다. 문장으로는 충분했지만, 시스템으로는 모호했기 때문이다. 예를 들어 “타이틀은 2줄 이내 권장”이라는 가이드는 그대로는 자동 판정이 불가능하다. 어느 뷰포트 기준인지, 말줄임은 언제 발생하는지 등을 명시해야 한다는 것을 AI와의 대화를 통해 구체화했다.
다음 글에서는 이 PRD를 실제 코드로 옮기면서 마주한 시행착오를 기록해보려 한다. UI 라이브러리를 선택하는 문제부터 생각보다 단순하지 않았던 스타일 결정 과정, 1차 결과물에 대한 내용을 정리해 볼 예정이다.
앞으로 이 시리즈에서 문제를 어떻게 정의하고, 어떤 과정으로 도구를 만들었는지 단계별로 기록할 예정입니다. 다음 편에서는 디자인 시스템을 명확화하고 프롬프트를 통해 구현한 결과물에 대해 다루려고 합니다.