PRD 중심으로 AI 에이전트와 제품 개발하기

1년 전, ‘생성형 AI의 시대에 PM이라는 직군/역할은 사라지는 것이 아닌가’ 하는 우려가 팽배했습니다. 그때 당시 PM은 사라지지 않는다는 얘기를 열심히 설명하고 다녔던 기억이 생생합니다.

하지만 이제 AI는 더욱 발전해, 아래 포스팅처럼 PRD만 정확하게 써 내려갈 수 있다면 제품을 개발할 수 있는 시대에 도착해 버렸습니다. (참고로 포스팅을 남긴 분은 현재 빅테크 기업에서 AI 에이전트로 제품을 개발하는 것을 업으로 하는 분인데, 개발 과정에서 여러 차례 재설계와 재개발로 인한 고통을 받고 있다 하시더군요.)

물론 “생성형 AI 시대에 PRD도 AI에 맡기면 되는 게 아니냐?”라는 질문이 나올 수도 있고, 또 여러 사람이 실제 PRD를 작성하는 프롬프팅을 공개하고 있기도 합니다.

하지만 저는 PRD 작성을 AI에게 맡기지는 않습니다. 물론 어느 파트의 유즈 케이스(Use Case)나 예외 케이스(Exceptional Case)를 잡을 때는 사용하고 있지만, 본론을 작성하는 데에는 AI를 필요로 하지 않습니다. 제게는 이 ‘필요로 하지 않는다’는 것이 AI의 쓸모를 말할 가장 정확한 표현입니다. 왜 그렇게 표현할 수 있을까요?

이번 글에서는 AI 시대에 PRD를 작성한다는 것은 어떤 의미인가, 그리고 그렇게 작성한 PRD를 중심으로 AI 에이전트를 활용해 개발하며 겪은 일을 말해 보겠습니다.

PRD는 무엇인가? 설계도인가? 

PRD를 작성한다는 것은 한 마디로 ‘내가 무엇을 만들지 잘 알고 있다’는 의미입니다. 내가 무엇을 만들지 잘 알고 있기에 그것을 사용자 시나리오로 작성할 수 있다는 것, 그리고 사용자가 시나리오에서 행위해야 하는 일들을 유즈 케이스로 기술할 수 있다는 의미입니다. 참고로 이는 모든 것을 아주 구체적으로, 매우 디테일하고 정확하게 알고 있다는 것을 포함하지는 않습니다.

PRD에는 어떤 내용이 들어가야 할까요? PRD 또는 제품 스펙(Product Spec) 등으로 검색해 보면 다양한 목차를 만날 수 있습니다. 그리고 그 목차들 모두 정답 카테고리에 포함되어 있습니다. 그런 내용 모두 다 알면 좋겠지요.

하지만 지금 PM으로 일하는 여러분이 회사에서 디자인팀 혹은 개발팀과 함께하는 과정은 어떠한가요? 모두가 그런 내용을 다 알고 있나요? 지금은 그런 세세한 것들을 몰라도 개발할 수 있는데, PRD 중심 개발은 그런 것까지 다 알아야 한다면 훨씬 더 어렵고 험난한 방법론이 아닐까요? 굳이 지금도 AI로 힘들고 불안한 내가 이런 험난한 방법론을 시도해야만 할까요?

저는 PRD 중심 개발 방법론을 꾸준히 강의하며 코칭해오고 있습니다. 아직은 제 강의 실력이나 유명세가 보잘것없다 보니 아주 많은 케이스를 만들고 있지는 않습니다만, 그래도 꾸준히 한두 개 스타트업에 방법론을 강의하고 코칭하며 적용해 보고 있습니다.

마침, 지금 코칭을 진행하고 있는 스타트업에서 기초 강의에 대한 피드백이 굉장히 좋아 많이 들떠있기도 한데요. 물론 이런 피드백은 기본적으로 칭찬일 수밖에 없으므로, 미사여구는 배제하고 주로 어떤 항목과 어떤 내용에서 반응이 나오는지 살펴보세요. 어쩌면 여러분의 회사나 팀에 도움이 될 수도 있을 것입니다.

돌아가 PRD 중심으로 개발하든, PRD 없이 개발 요건을 담은 AC 문서를 기반으로 하든, 혹은 화면정의서나 피그마에 작성한 스크린플로우를 가지고 제품 개발을 하든, 제가 PRD 중심 개발에서 강조하는 핵심은 모두 동일합니다. 다음 한 문장으로 정리해 볼 수 있습니다. (편의상 이 문장을 ‘가치 정의 문장’이라고 칭하겠습니다)

가치 정의 문장: “누가” “왜” 우리 제품을 “어떻게” 사용해 “어떤 가치”를 가져갈 것인가 

이것이 우리가 회사에서 제품을 개발하고 산출하고 배포하고 운영하는 이유이자 목적입니다.

그러면 다시, 여러분은 회사에서 AC 문서나 디자인 문서, 스크린플로우를 바탕으로 개발팀과 디자인팀에 리뷰하고 제품을 개발한다고 했을 때, 저 규정한 가치대로 잘 개발해 나가고 있나요? 제가 경험한 바에 따르면 그런 개발 방식에서는 그렇게 아름다운 답변이 나올 일이 없었습니다. 그런 압축된 문서(예를 들어, 화면정의서)들은 가치 정의 문장에서 요구하는 것들을 제대로 전달해 내지 못하기 때문입니다. 그리고 그것이 제가 PRD 중심 개발을 강조하는 이유이기도 합니다.

기업에서 제품을 개발해 온 과정

아니라고요? 많은 기업에서 제품을 개발해 온 과정을 한번 복기해 보겠습니다.

어떤 계기로 아이디어 생성(Idea Generation)이 일어납니다. 곧 초안 버전 상태에서라도 비즈니스 구조 설계(Business Structuring)를 해나갈 것입니다. 그다음 제품팀, 혹은 개발팀을 대상으로 이게 무엇인지 설명하고 전달하겠죠. 화이트보드나 A4 이면지에 자신 있게 북북 그어나가는 선들을 보고 있노라면 당장에라도 제품이 튀어나올 것만 같습니다. 이어 다양한 형태의 구두(verbal) 커뮤니케이션이 따라옵니다. 이런 설명을 듣다 보면 모두가 이미 모든 것을 알고 있으며 그 형태는 동일한 상태로 공유하고 있다고 착각하게 됩니다. 이제 “개발을 시작해 보자!”라는 선언이 나오죠. 그다음, 우리는 무엇을 하고 있을까요?

지금 이 상황을 규정해 봅시다. 발화자(Idea owner)의 머릿속은 온통 아름다운 에덴동산으로, 장엄한 유니콘이 뛰어놀고 있습니다. 그리고 그 설명을 청취한 제품팀 멤버들 모두의 머릿속에는 평행우주처럼 각자의 에덴동산과 유니콘이 태어날지도 모릅니다. 분명히 아름답고 참 좋은데, 설명을 할 수 없는 그런 느낌이랄까요. 확실한 것 한 가지는 어느 우주를 선택하더라도 그리 충분한 형상화가 일어나지 않았다는 것입니다. 심지어 발화자의 우주에서도 형상화가 충분하지 않다는 것은 확실합니다.

그럼에도 불구하고 우리 모두는 각자 이 제품을 “알고” 있습니다. 그리고 그것을 모두 “공유”해 “동기화(Sync)”되어 있다고 생각합니다. 그리고 여기부터 보통 스크린을 그려나가기 시작합니다. 우리 모두는 개발자(Maker)로서의 자아도 가지고 있지만, 동시에 소비자로서의 자아도 가지고 있습니다. 그러니 스크린이 어떤 자아를 기반으로 작성되는지, 그 스크린을 보고 해석하는 사람들은 어떤 종류의 자아로 이를 해석하고 있는지 자신할 수 없습니다. 그렇게 모두 같은 것을 “공유”하고 있다는 믿음 아래 각자 다른 것을 “상상하면서 만들기 시작”합니다.

제가 강조하는 PRD는 여러 목차를 보유하고 있습니다만, 그중에서 핵심 요체가 되는 것들은 퍼소나(Persona), 그리고 메인 시나리오(Main Scenario) 이렇게 두 가지입니다. 그 외에 기본이 되는 것으로 배경(Background), 맥락(Context) 등을 추가할 수 있고, 심화 과정으로 들어가면서는 유즈 케이스(Use Case)를 채워 넣습니다. 이러한 구성으로 PRD를 정리해 나갈 때야 앞서 규정한 가치 정의를 가장 정확하게 수행할 수 있다고 저는 생각합니다.

글의 주제로 돌아가겠습니다. 이처럼 사람 동료에게도 제대로 전달하지 못하는 가치 정의를 과연 AI 에이전트에게 제대로 전달할 수 있을까요? 어쩌면 AI 에이전트는 사람 동료보다도 당신을 훨씬 더 잘 이해하고 개발해 줄지도 모릅니다. 최소한 당신을 비난하지는 않을 테니까요. 하지만 과연 그렇게 만들어진 제품이 정말 원했던 무언가, 그 가치를 정확하게 구현하고 실현한 제품일까요?

PRD 중심으로 AI 에이전트와 개발하는 과정

올해 초, 아름답지 않은 이유로 제가 설계하고 목표했던 제품을 드롭하게 되었습니다. 아쉬움이 남아 이 제품을 ‘PRD 중심으로 AI 에이전트와 개발하기’의 소재로 사용해 보기로 했습니다.

우선 내가 무엇을, 왜, 개발하고 싶어하는지 더욱 명확하게 정리하고, 또 그중 가장 핵심이 무엇인지 선별해 PRD를 작성하기 시작합니다. 이 첫 단계에서 제가 강조하는 두 가지가 있습니다.

a. 반드시 문서로, 텍스트로 작성할 것. 어설프게 그림을 그리지 말 것

b. 모든 문장은 서술형으로 작성할 것. 권장하는 문장 구조는 사용자는 OOO를 할 수 있다. (User be able to have an option)

많은 분이 텍스트로 문서를 작성하는 것을 매우 어려워합니다. 아닐 것 같지만, 사실입니다. 누군가는 스티브 잡스가 아이콘 하나 띄워 두고 삼십 분씩 발표하는 것을 대단한 능력이라고 생각할 수도 있을 텐데, 비슷한 것을 많이 해본 분이라면 알겠지만, 말로 하는 것이 세상에서 제일 쉽습니다. 이유는 단순합니다. 내가 상상한 것을 말로만 전달하면 에덴동산도 유니콘도 마음껏 만들 수 있는데, 글로 써 보고 나면 머릿속에 있던 에덴동산도, 유니콘도 온데간데 없어지기 때문입니다.

남은 것은 (제가 가장 좋아하는 비유입니다만) ‘2주 전에 써놓은 연애편지처럼’ 촌스럽고 초라하며 볼품없는, 게다가 말도 안 되고 내용도 개발괴발인 글 덩어리일 뿐입니다. 그래서 많은 분이 제품에 대한 이야기를 말로만 하려고 합니다. (저는 신뢰하지 않지만, 바이브 코딩(Vibe Coding)이 이런 분들에게 희망이 될까요?)

텍스트 문서와 서술형 문장, 두 가지를 강조한 것은 이 때문입니다. 텍스트 기반 문서는 그 허황되고 말도 안 되는 에덴동산을 제거하기 위함이고, 서술형 문장은 그 연애편지를 조금 덜 촌스럽고, 더 구조화된 상태로 만들기 위함입니다. 같은 이유로 노션에 개조식 To-Do 리스트를 작성하는 방식은 매우 매우 반대합니다. To-Do는 To-Do로만 사용해 주세요.

AI 에이전트에 제품 개발 요청하기

PRD를 갖추었다면 이제 우리는 프론트엔드(Front-End)를 개발할 수 있습니다. 사용자의 메인 시나리오부터 하나씩 하나씩 상상하는 대로 넣어가면 됩니다.

저는 AI 코딩 도구로 러버블(Lovable)을 이용하고 있습니다. 꽤나 말귀를 잘 알아들어 유용하게 쓰고 있습니다. 대신 고집이 대단해 또 어떤 것은 결코 양보해 주지 않더군요. 그래도 시나리오를 넣은 다음 유즈 케이스를 하나씩 추가하는 데에는 아주 안성맞춤입니다.

아래 두 가지 프롬프트 예시가 있습니다. 전자는 일단 아무렇게나 에덴동산을 만들고 싶은 경우이고, 후자는 그래도 에덴동산에 언덕과 골짜기가 몇개인지 구체적으로 그려본 경우라고 비유할 수 있겠네요.

이제 에덴동산을 보다 구체적으로 조정하는 일이 남았습니다.

우리는 시장을 모른다

PRD를 전부 쓰고 한 번에 넣어, 바로 완제품을 만들어 달라고 하면 안 될까요? 네, 안 됩니다.

AI 에이전트의 성능이나 요금제 때문만은 아닙니다. 앞선 문단에서 말했듯, 사실 제품을 만드는 본인도 스스로 개발할 것이 무엇인지는 정확하게 잘 모릅니다. 그리고 그것이 정상입니다. 지금 단계에서 알 수 있는 것은 ‘누가, 왜, 어떻게 제품을 사용해 무슨 가치를 획득해 갈 것이다’라는 사실뿐이니까요.

애자일을 설명할 때 항상 강조하는 문장은, “우리는 시장을 모른다”입니다. 저는 이 말이 애자일 철학의 가장 근원적인 질문을 만들어 낸다고 생각합니다. 우리가 만들어 갈 제품을 우리는 사실 잘 모릅니다. 그저 조금 더 형상화된 문장, 시각화(Visualized)된 상상을 가지고 있을 뿐입니다. 그렇게 시나리오와 사용자 케이스를 하나씩 넣어가며 그때마다 조금 더 정확하게 알아가고는 합니다. 그렇게 하나의 시나리오를 알고 규정할 수 있게 되면, 여러 유즈 케이스를 규정할 수 있으며, 인접한 다른 시나리오를 형상화할 수 있습니다.

이 프로젝트를 제가 혼자 진행한 것은 아닙니다. 채널 개발 쪽은 제가 정한 정책과 PRD를 바탕으로 다른 분이 맡았고, 그는 커서 AI(Cursor AI)를 이용했습니다. 그렇게 둘이서 1주일에 하루 2~3시간을 들여 공동 작업을 했고, 1주일에 반나절 정도는 각자 개인 작업을 진행하며, 4주 동안 개발을 마쳤습니다. 이 글을 쓰는 지금 그 제품은 Email for Weeks라는 이름으로 크롬 익스텐션 스토어에 올라가 있으며, 업데이트 대기 중인 상태입니다.

QA와 QC

제품 개발의 마지막 단계는 QA입니다. 회사에 QA 팀이 있다면 이들은 수백 줄로 이루어진 TC 시트를 가지고 있을 것입니다. 그리고 주기적으로 전체 테스트(Full Test)를 하면서 TC 시트에 새로운 줄을 추가해 나가고 있을 것입니다.

PRD 중심 개발의 QA는 그와는 좀 다릅니다. TC로 모든 경우를 검증하는 것이 QA(Quality Assurance)라면 PRD 중심에서는 QC(Quality Control)를 한다고 설명해 보고 싶습니다.

여기서는 PRD에서 작성한 시나리오대로, 그리고 유즈 케이스(UseCase)대로 우리 제품이 제대로 작동해 주는지 테스트합니다. 이 방식의 장점은 메인 시나리오에 대해 확실한 점검을 할 수 있다는 것이고, 단점은 생각하지 못한 예외 케이스를 필터링하지 못할 위험성이 상대적으로 높다는 점입니다.

그럼에도 제가 이 방식을 선호하는 이유는 반드시 가치를 지켜내야 하는 메인 시나리오와 의도치 않게 발생하는 예외 케이스를 명확하게 구분해 낼 수 있기 때문입니다. 그래서 예외 케이스를 보정하기 위해 메인 시나리오의 가치가 훼손되는 것을 막을 수 있게 됩니다. 모든 앱 기동에 대해 MECE로 테스트를 하기 시작하면 무한정으로 펼쳐져 가는 사용자 행동 시나리오를 만나게 될 수도 있습니다. 또, 그런 것들을 정리하다 보면 메인 시나리오의 가치가 훼손되는 상황을 만나기도 합니다.

제가 삼성페이를 개발할 때의 일화입니다. 어떤 예외 케이스를 발견했는데, 그 케이스를 적절하게 수용하려면 메인 시나리오를 손대야만 할 상황에 도착했습니다. 예외 케이스를 EP(Entry Point)에서부터 막아버리려는 저와 삼성 모바일의 UX 정책상 그렇게 해서는 안 된다는 UX 담당자의 의견이 대립했습니다. 당시 저는 그 예외 케이스에 들어갈 사용자가 많아 봐야 1%도 안 될 거라고 짐작했습니다.

이에 대한 UX 담당자의 답변은 무엇이었을까요? “과장님, 갤럭시 사용자의 1%가 몇 명인 줄 아십니까?”
(그립네요. 박 책임님, 이 글을 혹시 보면 연락 한 번 주세요)

그때 어떤 결정이 이뤄졌는지는 사실 잘 기억나지 않습니다. 그저 당시 QC 과정에서는 PM과 UX 사이 이런 치열한 대립이 수도 없이 많았고 제 승률은 3할 정도 수준이었다고만 기억합니다. 그러나 이런 과정 덕분에 삼성페이는 “삼성스럽지 않게” 잘 나온 제품이라 자부하고 있습니다. 또, 이런 과정에도 불구하고 삼성페이의 버전 출시는 일정 지연이 거의 없는 상태로 배포해 내기도 했습니다.

PRD는 언제 완성되는 것인가? 

PRD 중심으로 개발하자고 강의할 때, 가장 많이 듣는 질문 또는 컴플레인은 “PRD를 쓰느라 너무 많은 시간을 허비해야 한다”는 것입니다.

디자인 문서나 화면정의서, AC 문서 등은 1차로 완성한 다음 개발팀과 리뷰를 진행합니다. 하지만, PRD라는 문서를 쓰는 데는 AC 문서보다 훨씬 더 많은 시간이 들어갈 테고, 그만큼 제품 개발이 더 지연된다는 불만입니다. 이런 불만이 나오면 저는 제가 강의를 잘 해내지 못했다는 사실을 깨닫게 됩니다.

PRD는 100점짜리 문서를 쓰는 작업이 아니라고 아무리 설명해도 이미 가지고 있는 인식을 뛰어 넘기는 정말 쉽지 않습니다. 그럼 PRD를 리뷰하려면 어느 정도 완성도가 있어야 할까요? ‘100점 만점에 30점’이라고 저는 설명합니다. 70점이 아닌, 30점입니다.

그 정도면 가치 정의 수준을 완성하고 퍼소나(Persona)와 메인 시나리오(Main Scenario) 정도만 쓰여 있습니다. 얼추 배경(Background)과 맥락(Context) 정도를 추가해도 충분합니다. 때로 조금 더 해서 중요한 유즈 케이스(UseCase)를 작성하고 사용자 여정(User Journey) 또는 사용자 흐름(User flow)이라고 부르는 일방향(One way) 흐름도까지 쓰고 나면 40~50점은 됩니다. 이 정도를 작성하는 데에는 PM의 고민이 충분하거나 혹은 경영진이나 전략 부서와 작성한 MRD(Market Requirement Document)가 있다면 반나절, 길어도 하루 정도면 충분한 작업입니다.

그러면 이 PRD는 언제 100점에 도달할까요? 답은 ‘제품이 배포될 때’입니다. 그 잠깐의 시점을 지나고 나면, PRD의 점수는 다시 70점으로 돌아와 다음 배포를 기다리는 상태가 되어 있겠죠. 제가 AI 에이전트와 개발한 제품의 PRD도 이런 과정으로 쓰였고, 제품을 배포하기 직전까지도 100점에 다다르지 못했습니다. 그러나 일단 배포를 했으니 다시 70점이 되었고, 그렇게 배포한 제품을 기반으로 유즈 케이스(UseCase)를 다시 정렬하고, 후속으로 배포할 기능에 대한 시나리오를 추가해야겠죠. 채널 쪽 동작의 로직도 좀 더 수정할 필요가 있어 보입니다.

이 제품을 개발하는 과정에서 나온 다양한 케이스도 논의를 거쳐 일부는 수용했지만, 또 대부분은 EP(Entry Point)에서 막아버렸습니다. 제가 설정한 퍼소나(Persona)는 꽤나 분명하고 정형화된 형상을 가지고 있기 때문에, 일어날 것 같지 않은 상황들에 대해서는 제품 개발을 하지 않기로 했습니다. 이 과정 모두 PRD 기반 QC를 하면서 확인했습니다.

마치며

제품을 설계하고 PRD를 쓰며, 또 배포하는 과정은 도파민이 터지는 정말 즐거운 일입니다. 저는 연차 많은 시니어 PM이지만, 이번 제품을 만드는 과정에서 또 한 번 스스로 성장했다고 여기고 있습니다. PM은 제품을 배포하는 행위를 통해서만 성장하는 것이니까요.

그리고 저는 이러한 성장 과정을 전파하고 있습니다. 누군가 저를 가리켜 “어디에서나 PRD를 외치는 사람”이라고 지칭할 정도로요. 그렇게 많은 스타트업들이 PRD 중심 개발을 꼭 시도해 보기를 바랍니다. 제품을 더 정확하게, 원하는 대로 배포할 방법이자, 동시에 PM이 성장해 나가는 과정이 될 것이라고 믿기 때문입니다.

이 글에서 예를 든 사건들 외에도 수많은 상황을 누군가는 마주하고 또 경험하고 있을 것이고, 이렇게 해주었으면 저렇게 할 수 있다면 하는 많은 방법론들을 생각해 낼 수 있을 것입니다. 이 글을 읽는 독자분들 중에 이런 사항을 경험하시고 공감하는 분이 계신다면 댓글로 생각을 남겨주세요.

제품 개발 과정(Agile Product Development Process, APDP)에 대해, 특히 PRD에 대해 궁금한 분들을 위해 커피챗 신청 창구를 만들었습니다. 링크를 참고해 주세요. 이러한 과정에 관심 있는 스타트업도 좋습니다. 댓글 또는 이메일이나 링크드인으로 연락 주셔도 됩니다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.