K-맛집 탐색 서비스를 피그마 프로토타입으로 검증하기

이전 글에서는 디자인의 코드화를 수월하게 만들어주는 Figma MCP를 소개해 드렸습니다.

Figma MCP가 핸드오프 단계에 도움이 되는 툴이라면, 피그마 메이크(Figma Make)는 기획 단계에서 서비스 흐름을 빠르게 만들고 검증하는 데 강점이 있는 도구입니다. 단순히 화면을 빠르게 그리는 수준을 넘어, 입력–처리–출력까지 포함한 End-to-End 흐름을 짧은 시간 안에 재현해볼 수 있습니다.

이번 글에서는 피그마 프로토타입이 프로덕트 기획에 어떻게 도움이 되는지 좀더 자세하게 소개하기 위해 실제 프로토타입 제작 사례를 공유해보려 합니다.(고객 동의 하에 실제 프로젝트의 부분을 변형한 사례입니다.)

검증할 사용자 시나리오

이번 프로토타입은 외국인이 영어로 K-맛집 키워드를 검색하고, 번역된 블로그 후기를 탐색하는 시나리오를 가정했습니다. 언어 장벽 없이 탐색이 이어지려면, 최소한 아래 단계가 한 번 끊김 없이 연결되어야 했습니다.

1. 영문 키워드 입력 받아 한글 번역
2. 번역한 한글 키워드로 로컬 검색 요청
3. 로컬 검색 결과 영문 번역
4. 로컬 검색 결과를 지도에 표시
5. 장소 클릭 시 관련 블로그 자동 검색
6. 블로그 내용 영문 번역
7. 블로그 메타 정보 추출 및 표시

기술/데이터 의존성 체크리스트

이 시나리오는 피그마 내부 기능만으로는 구현하기 어렵습니다. 번역–로컬검색–지도–콘텐츠 수집까지 외부 연동이 필요한 지점을 목록으로 정리했습니다.

구분	서비스	역할
번역 API	Google Translate	영어 ↔ 한국어 양방향 번역
지역 검색 API	카카오 로컬	키워드 기반 장소 탐색
지도 API	Google Maps	위치 시각화 및 인터랙션
블로그 검색 API	네이버 블로그	네이버 블로그 결과 추출
스크래핑 라이브러리	open-graph-scraper	대표 이미지, 제목, 설명 수집
데이터베이스	Supabase	검색 결과 저장 및 관리

체크리스트만 봐도 알 수 있듯, 단순 프로토타입이 아니라 데이터 처리와 연동 안정성까지 포함한 검증이 필요했습니다.

핵심 플로우를 피그마 프로토타입으로 재현하기

위 시나리오를 실제로 성립시키기 위해, 핵심 플로우를 3개의 연결 구간(검색→결과→탐색)으로 나눠 프로토타입에서 어떻게 재현했는지 보여드리겠습니다.

1. 영어 키워드를 로컬 검색으로 연결하기

첫 번째 검증 포인트는 영어 입력이 로컬 검색으로 ‘끊김 없이’ 변환되는지였습니다. 번역 결과가 검색 품질에 직접 영향을 주는 구간으로, 이 단계에서 실패하면 이후 흐름(지도/콘텐츠)은 전부 무의미해집니다. 그래서 입력 언어 처리(번역) → 로컬 검색 결과 품질을 먼저 확인했습니다.

검증 포인트 1 — 영어 입력이 번역을 거쳐 로컬 검색 결과로 ‘끊김 없이’ 연결되는지 확인

2. 로컬 검색 결과를 블로그 검색으로 연결하기

두 번째 검증 포인트는 ‘장소 정보’를 단순 표시하는 데서 끝나지 않고, 사용자가 다음 행동을 할 수 있도록 관련 후기 콘텐츠로 자연스럽게 이어지게 만드는 것이었습니다. 로컬 검색과 블로그 검색은 별개의 로직이므로, 로컬 검색 결과로 블로그를 검색했을 때 유의미한 결과로 연결될 수 있는지 확인해야했습니다.

검증 포인트 2 — 장소 선택 이후, 관련 후기 콘텐츠가 자동으로 연결되고 번역/요약까지 이어지는지 확인

3. 로컬 검색 결과를 지도에서 탐색 가능하게 만들기

세 번째 검증 포인트는 결과를 ‘보여주는 것’이 아니라 지도에서 편리하게 탐색 가능한 상태(목록↔지도 인터랙션)로 만드는 것이었습니다. 지도를 탐색하는 경험이 자연스럽게 이어지려면 어떠한 세부 인터랙션 요소가 필요한지 확인하고 개선해나갔습니다.

검증 포인트 3 — 목록↔지도가 함께 동작하며 탐색하는 UI(마커/포커스 동기화)

4. 지역명 자동완성으로 탐색 진입장벽 낮추기

핵심 플로우가 성립하더라도, 첫 입력에서 막히면 탐색이 시작되지 않습니다. 따라서 검색 실패를 줄이는 장치로 지역명 자동완성을 추가했습니다. 이부분은 프로토타입을 발전시키는 과정에서 나온 새로운 아이디어였습니다. 구현된 모습을 확인하면 새로운 아이디어가 나오고 이 아이디어를 다시 빠르게 적용해볼 수 있었습니다.

검증 포인트 4 — 첫 입력에서 막히지 않도록 지역명 자동완성으로 탐색 진입장벽을 낮추기

실제로 작동하는 피그마 프로토타입은 아래 링크에서 확인할 수 있습니다. (비용 이슈로 번역 기능은 제외되었습니다)

피그마 메이크 프로토타입 확인하기

빠른 제작보다 중요한 것: 반복 수정으로 완성도 올리기

프로토타입 제작기간은 얼마나 될까요? 놀랍게도 단 하루 였습니다. 다만 이 시점이는 “돌려볼 수 있는 상태” 정도 였으며 아이디어를 추가하고 오류를 다듬는 데는 하루-이틀이 더 소요되었습니다.

이 구간에서 저희가 했던 일은 기능을 더 얹는 것이 아니라, 흐름을 깨뜨리는 지점을 하나씩 찾아 검증 가능한 상태로 안정화하는 일이었습니다.

• 연동 리스크 정리 → 우선순위 조정: 번역/로컬검색/지도/블로그 검색/스크래핑 중 어디가 실패해도 사용자가 멈추는지 먼저 확인하고, 가장 치명적인 구간부터 손봤습니다.
• 상태(State) 정리: 로딩 중 / 결과 없음 / 실패 / 재시도 같은 상태를 분리하지 않으면, 화면은 있어도 사용자는 다음 행동을 못 하게 됩니다.
• 데이터 흐름 점검: 번역 결과가 검색 품질에 영향을 주거나, 선택한 장소 정보가 콘텐츠 패널로 제대로 전달되지 않는 등 “연결”에서 자주 문제가 발생했습니다.

반복 수정의 결과 — End-to-End 흐름을 ‘검증 가능한 상태’로 안정화하며 198번째 버전까지 개선

구체적으로는 아래 같은 문제들을 반복적으로 마주쳤습니다.

문제 유형	내용
CORS/권한 이슈	아예 호출이 막히는 문제
로딩/동기화 문제	데이터가 늦게 오거나 순서가 바뀌면서 발생
인터랙션 완성도 문제	클릭했는데 패널이 갱신되지 않거나, 목록/지도 포커스가 어긋남
실패 UX 문제	실패했을 때 사용자에게 무엇을 보여주고 어떤 선택지를 줄지

물론 이 단계에서는 로그를 보고 원인을 추적하는 과정이 필요했고, 어느 정도 개발 지식도 요구되었습니다. 그럼에도 이 반복 수정이 실무적으로 의미 있었던 이유는 명확했습니다. 와이어프레임이나 정적 프로토타입에서는 잘 드러나지 않는 문제들(로딩 중 데이터 처리, 검색어 처리 방식, 포커스/스크롤 이동, API 응답 지연, 실패 시 UI 상태)을 기획 단계에서 실제 동작으로 먼저 확인할 수 있었기 때문입니다.

프로토타입이 만든 변화 : 논의 단위가 화면에서 동작으로

피그마 프로토타입은 회의의 질문을 바꿉니다. “이 버튼을 누르면 어떻게 되나요?”에서 “실제 사용자라면 여기서 포기하지 않을까요?”로 논의가 이동합니다. 클라이언트/내부 이해관계자와의 합의는 ‘동작’을 기준으로 할수록 빨라집니다. 이번 프로토타입이 협업 방식에 어떤 변화를 만들었는지 정리해보면 아래와 같습니다.

• 리스크를 앞당겨 발견: 개발 착수 전에 데이터 흐름/예외 케이스를 확인해, 요구사항을 더 정확히 고칠 수 있었습니다.
• 논의의 단위를 화면이 아니라 ‘동작’으로 전환: “이 화면은 이런 느낌”이 아니라 “이 입력에서 이 응답이 오면 UI는 이렇게 변한다” 수준으로 합의가 빨라졌습니다.
• 명세의 품질 향상: API 연동, 로딩/실패 상태, 번역 품질 같은 요소가 PRD(기획 명세서)/스토리의 구체 항목으로 정리되며 누락이 줄었습니다.
• 의사결정 속도 개선: 팀 내에서 빠르게 ‘될 것/안 될 것’을 판별해 우선순위를 정하기 쉬웠습니다.

정리하면, 피그마 프로토타입은 ‘완성된 제품’이 아니라 기획 단계의 불확실성을 줄이는 검증 도구로서 특히 강점이 있습니다. 이 방식이 특히 유효한 상황은, 문서로는 합의가 어렵고 데이터/상태/예외가 많은 사용자 흐름을 빠르게 확인해야 할 때였습니다.

UX 기획이나 프로토타입 제작에 관심이 있다면 스무타트에 문의해주세요.