Figma Make로 Product Discovery 더 잘하기
Figma Make 실전 활용 후기를 공유합니다. 프롬프트 기반 프로토타이핑으로 아이디어를 기존의 10분의 1 비용으로 만들고, 고객 인터뷰의 질을 높여 프로덕트 디스커버리의 퀄리티도 높인 과정을 공유합니다.

지난 5월에 Figma의 Config 2025 컨퍼런스를 통해 Figma Make 기능이 발표되었습니다. 간단하게 설명하면 Cursor처럼 프롬프트를 통해 동작하는 제품의 프론트엔드를 만들어주는 기능이라고 생각하면 됩니다. 주로 프로토타입을 만드는 것에 포커스를 두고 있습니다. (실제 Figma의 홈페이지에도 그렇게 나와있고요. 😄)

처음 업데이트가 되고 난 이후에 바로 이 기능을 써보지는 못 했는데요. 최근에 의식적으로 업무 영역을 확장하려고 여러 시도를 하던 중에 본격적으로 이 기능을 써봤습니다.

Figma Make 활용 사례
이 기능을 엄청 많이 사용한 것은 아니지만, 제가 주로 사용했던 것은 다음과 같습니다.
- 한 분기 정도 후에 진행할 제품 과제의 프로토타입 제작
- 아쉬운 기능을 개선한 버전의 프로토타입 제작
- 팀에서 중요한 과제로 인식하진 않지만, 개인적으로는 필요하다고 생각한 과제의 프로토타입 제작
저의 주 활용 사례를 추상화 해보면 이런 느낌이더라고요.
- 굉장히 명확하게 해결할 문제가 존재하고, user journey가 굉장히 짧아서 프로토타입만으로도 엔지니어들에게 설명하기 어렵지 않은 기능
- 아직 구체적인 스펙을 확정하지 못 했고, 어떤 가치 제안이 가장 중요한지에 대한 감을 잡아가는 과정인 기능
결국 Product Designer의 시간과 에너지를 쓰기에는 애매하면서 시각적인 요소 없이는 좋은 커뮤니케이션과 논의가 어려운 과업들에 Figma Make를 활용했습니다.
Figma Make의 장점
어쨌든 가장 큰 장점은 PO/PM이 스스로 구현하려는 가치 제안을 굉장히 쉽고 빠르게 동작하는 제품으로 만들 수 있다는 점입니다. 예를 들어서 과거에 이런 프로토타입을 만든다고 생각해보면 이런 단계를 밟습니다.
- PO/PM이 프로토타입을 위한 PRD를 작성한다. (아주 러프하게라도)
- PRD를 PD에게 공유하고, PD는 이를 소화한다.
- PD가 프로토타입을 만들기 전에 서로 질문과 답변을 주고 받는다.
- PD가 시안을 만든다.
- 적절한 UX를 고민하고, user journey를 고민한다.
- 각각의 요소들의 배치를 고민하고, 동작을 고민한다.
- 시안을 두고 PO/PM과 PD가 함께 논의하면서 시안을 고친다.
- PD는 좀 더 그럴싸한 시안을 만들기 위해서 더미 데이터를 고민하고 집어넣는다.
- PD가 Figma 상에서 동작하는 제품처럼 보이기 위해 프로토타입 기능을 활용해서 제공한다.
이런 식으로 되었는데요. 이 과정이 거의 다 사라지게 됩니다. 물론 적절한 UX를 고민하고 user journey를 고민하는 일은 필요하죠. 하지만 이것마저도 PO/PM이 AI를 활용해서 적절한 UX나 플로우를 정리하면 더 쉽게 만들 수 있습니다.
저의 실제 사용 방식
저는 이런 방식으로 해봤습니다.
- 고객 문제와 솔루션 등을 정의하는 Product Pager 생성용 프롬프트에 "입력 정보"를 두고 먼저 Product Pager를 생성합니다. Pager는 Persona, Problem, Context, Solution concept 등을 정리해줍니다.
- Pager 생성 과정에서 나온 Persona, Problem, Context, Solution Concept와 기존 제품 맥락(정책이나 정보들)을 담은 정보를 얹어서 User Story & AC 추출 프롬프트에 넣어서 User Story와 AC를 뽑아냅니다.
- 다시 US/AC를 가지고 이를 Cursor나 Figma Make에 집어넣기 위해 필요한 프롬프트를 생성합니다. 이 프롬프트도 귀찮을 때는 그냥 AI한테 맡깁니다.
- 이 프롬프트들을 Figma Make에 순차적으로 입력합니다. 절대 한 번에 다 입력하지 않습니다. 순차적인 처리나 CoT 때문에 그런 것은 아니고요. 중간중간에 구현되는 과정을 보면서 뒤의 User Story나 AC를 고칠 수도 있기 때문입니다. 😄
- 프롬프트를 다 넣어준 상태에서 나온 프로토타입을 깎아내고, 더미 데이터들을 설정하고 더 종작하는 제품처럼 보이게 만들기 위해 좀 더 가공을 해줍니다.(인터랙션 같은 것들)
Product Pager 생성용 프롬프트 일부
[프롬프트 시작]
당신은 고도로 훈련된 **'프로덕트 전략 AI'**입니다. 당신의 고유한 능력은, 인간 Product Manager가 제공한 최소한의 단편적인 정보들을 바탕으로, 정교한 추론 및 창작 과정을 거쳐 최종 결과물인 **'완벽한 Product Pager'**를 한 번에 완성하는 것입니다.
[당신의 내부 작업 프로세스]
당신은 다음 3단계의 작업을 내부적으로, 순차적으로 수행해야 합니다.
- [1단계: 페르소나 합성 및 서사 구축]
[2. 페르소나 및 VoC]
정보를 분석하여, 시장을 대표하는 하나의 가상 페르소나 프로필을 정의하고, 그의 감정과 상황이 생생하게 느껴지는 **'페르소나의 세계'**와 **'마음의 소리'**를 내부적으로 생성합니다.[9. 페르소나 간 대화 시나리오]
가 있다면, 이를 바탕으로 생생한 대화문을 함께 구축합니다. 이때는 당신의 '드라마 작가' 페르소나를 활용하세요.
- [2단계: 핵심 논리 분석 및 구조화]
[3. 문제 분석]
,[4. 솔루션 가설 및 개요]
,[6. 로직 및 가설]
에 입력된 정보를 종합적으로 분석합니다.- 특히
Logic & Validation
섹션을 생성하기 위해, '전략의 씨앗'들을 바탕으로 내부적인 소크라테스식 문답을 수행하여 논리적 연결고리를 완성합니다.
- [3단계: Product Pager 최종 완성]
- 위 분석을 바탕으로, 아래 **[Product Pager 최종 목차 (v2.0)]**에 맞춰 Pager를 완성합니다.
- 각 섹션은 아래 **[각 항목별 특별 지시]**에 따라 작성되어야 합니다.
- 최종 결과물은 오직 아래 목차로 구성된 Product Pager여야만 합니다. 중간 과정은 표시하지 마세요.
Product Discovery 활용
이런 식으로 만들어진 프로토타입은 주로 고객 인터뷰 장면에서 활용합니다. 며칠 전에도 고객과 인터뷰를 하면서 아예 프로토타입을 보여줬고, 고객에게 가치 제안이 무엇인지 설명했는데요. 인터뷰의 질이 더 높아졌다는 생각이 들었습니다. 여러 이유는 있지만 고객 입장에서는 다음과 같이 느꼈던 것 같아요.
- 기존의 Figma 프로토타입에서는 어색하게 느껴지던 인터랙션들이 굉장히 자연스러워졌음
- 기존에는 더미 데이터를 생성하는 작업이 부담스러워서 고객 맞춤형으로 설정하지 못했던 각종 데이터 설정을 고객에게 맞춰줄 수 있음(이건 B2B에서만 느끼는 장점일 수도)
이렇게 되니까 고객도 이 솔루션이 어떻게 돌아갈지를 생각할 수 있습니다. 특히 제가 구두로 설명할 때는 고객도 제 설명을 이해한 후에 본인의 멘탈 모델 하에서 상상한 솔루션으로 대화를 하기 마련인데요. 그 과정에서 생기는 미스매치들을 거의 다 없앤 상태에서 대화를 하니까 Discovery 과정이 굉장히 좋아진다는 것을 느꼈습니다.
아쉬운 점
그럼에도 좋은 프롬프트를 작성해야 한다는 부담은 여전히 있습니다. 특히 Figma Make는 한 번의 프롬프트에도 거의 대부분의 코드를 새로 쓰는 느낌인데 그렇다보니 뒤로 갈수록(즉, 설계한 프로토타입의 코드가 500줄을 넘어갈수록) 프롬프트 하나하나를 잘 설계해서 던져야 합니다. 안 그러면 프롬프트에 따라 구현하는 시간이 5분 이상 소요될 때도 있더라고요
PRD를 잘 설계하는게 여전히 중요합니다. 제 머릿 속에 어느 정도 솔루션이 어떻게 구동될 것이라고 상상을 해뒀던 기능은 어렵지 않았는데, 그렇지 않았던 기능들의 프로토타입을 만들 때 PRD 없이 들어갔다가 1시간 정도 삽질을 하기도 했습니다. 이건 바이브코딩에서도 적용되는 것이니 다들 잘 이해할 것으로 생각합니다.
정리
저는 Figma Make가 PO/PM이 아예 동작하는 제품까지를 만들어 내는 기능이라고는 생각하진 않습니다. Figma도 명시적으로 이 기능은 프로토타입을 만들기 위한 것이라고 했고요. 😄 하지만 프로토타입의 퀄리티, 제작 비용을 엄청나게 절약해준다는 명확한 장점을 가지고 있습니다.
하지만 바이브코딩과 마찬가지로 본인이 원하는 점을 명확하게 설명해야 하고(물론 의식적으로 뭉뚱그려서 적을 때도 있음) PRD나 User Story, AC를 잘 써야 한다는 점은 여전히 필요한 일입니다. 프로토타입 하나를 위해서 이렇게 투자를 하는게 아깝다고 느낄 수 있습니다. 저는 원래부터 팀원들이 다 PO/PM의 일을 할 수 있도록 Pager 생성 프롬프트나 User story, AC 생성 프롬프트를 만들어둬서 좀 더 수월하다고 느꼈는데요. (다음에 이 프롬프트를 공유 드릴게요) 저처럼 어느 정도 효율화를 해두지 않은 분이라면 부담스러울 수 있습니다.
도구의 진화가 사람의 변화를 강제하는 시대를 살고 있다고 느끼는데요. 너무 익숙한 방식으로만 일하시지 말고, 새로운 방식도 이리저리 시도해보시기 바랍니다.