프롤로그
왜 문서 대신 프로토타입인가
기획 패러다임의 전환점
소프트웨어 기획 현장에서 수백 페이지 PPT와 워드 문서가 더미처럼 쌓여있는 광경은 익숙하다. 기능 명세서, 화면 설계서, 플로우 차트, 요구사항 정의서. 이런 문서들은 프로젝트가 시작될 때마다 생산되고, 수정되고, 버전이 올라간다. 그런데 개발이 시작되면 이 문서들은 현실과 점점 멀어진다. 개발 과정에서 발생하는 변경사항을 문서에 반영하는 일은 뒷전이 되고, 문서와 실제 구현 사이의 간극은 메울 수 없는 수준이 된다.
이런 비효율의 근본 원인은 문서는 정적이고, 소프트웨어는 동적이라는 것에 있다. 아무리 상세한 화면 설계서도 실제 인터랙션을 완벽하게 표현할 수 없다. 버튼을 클릭했을 때의 반응, 데이터가 로딩될 때의 상태, 에러가 발생했을 때의 처리. 이 모든 것을 텍스트와 이미지로 설명하려면 방대한 분량이 필요하고, 그마저도 해석의 여지를 남긴다.
프로토타입 중심 기획은 이 문제에 대한 해답이 될 수 있다. 실제로 클릭할 수 있고, 화면 전환을 확인할 수 있으며, 상태 변화를 눈으로 볼 수 있는 프로토타입은 그 자체로 살아있는 명세서다. 중요한 점은 프로토타입이 커뮤니케이션 도구라는 것이다. 개발자, 디자이너, 경영진, 고객 모두가 같은 것을 보고 같은 이해를 가질 수 있다.
도구의 진화가 만든 기회
과거에는 프로토타입 제작이 전문 영역이었다. HTML/CSS 코딩 능력이 필요했고, 인터랙션을 구현하려면 JavaScript까지 다뤄야 했다. 기획자가 직접 프로토타입을 만드는 것은 현실적으로 불가능했다. 지금은 다르다.
Figma는 디자인 도구를 넘어 협업 플랫폼으로 진화했다. 실시간으로 여러 사람이 동시에 작업할 수 있고, 댓글과 버전 관리가 내장되어 있다. Community는 수천 개의 템플릿과 컴포넌트가 공유되고 있어, 제로베이스에서 시작할 필요가 없다. - Figma에도 Preview가 있지만, 수많은 페이지에서 일일이 연결시켜줘야 한다. 개인적으로 연결선들이 오히려 더 혼란을 준다. -
v0는 Vercel이 만든 AI 기반 UI 생성 도구로, 자연어 프롬프트만으로 React 컴포넌트를 생성한다. "장바구니 페이지를 만들어줘"라고 입력하면 실제 동작하는 코드가 나온다. 이를 다시 수정하고 조합해서 원하는 화면을 만들 수 있다. - v0가 아닌 Replit, Lovable, bolt를 사용해도 된다. 이 연재에서는 v0로 진행하지만, 어떤 AI 도구를 사용하든 형식은 같다. -
GPT는 요구사항 분석부터 정보구조 설계까지 기획의 전 과정을 지원한다. 비즈니스 목표를 입력하면 유스케이스를 도출하고, 경쟁사 레퍼런스를 분석하며, 데이터 모델을 설계한다. 인간 기획자의 역할은 GPT가 생성한 결과물을 검증하고 선택하는 것으로 변화한다. - Perplexity를 사용하면 더 정확한 검색과 분석이 가능하다. -
이 세 도구의 조합은 기획 방법론 자체를 바꾼다. GPT로 구조를 잡고, v0로 화면을 생성하고, Figma로 정제하고 문서화한다. 이 과정은 순차적이지 않고 반복적이다. 프로토타입을 만들면서 요구사항이 명확해지고, 화면을 보면서 정보구조가 개선된다.
진행 방식: 설계하며 설명한다
이 연재의 컨셉은 "설계하며 설명한다"다. 기존 방식은 먼저 문서로 설명하고, 나중에 설계했다. 수십 페이지 기능 명세를 작성한 후 화면을 그렸다. 새로운 방식은 이와는 반대다. 화면을 먼저 만들고, 그 안에 설명을 넣는다.
Figma Community에서 적절한 디자인 템플릿을 선택한다. 웹사이트의 모든 페이지가 포함된 템플릿이 이상적이다. 선택한 페이지를 v0에 불러와 프롬프트로 기능을 추가하거나 빼고, 위치를 옮기고, 새로운 페이지를 추가한다. 물론, Figma Community가 아닌 v0에서 바로 페이지를 만들 수도 있다. v0에서 페이지를 처음부터 만들려면 명확한 설명과 요구사항이 필요하다. 일단 Figma에서 적절한 화면을 가져온 후 v0에서 바로 코드화하는 것이 처음 시작에 효율적이다.
v0에서는 각 기능에 대한 설명을 직접 넣을 수 없기에, v0에서 만든 화면을 Figma로 다시 가져온다. Figma에서 NOTE 컴포넌트나 Text 컴포넌트를 활용해 각 요소에 대한 기능 설명, 상태 정의, 데이터 속성, 이벤트 처리를 문서화한다. 색상 규칙으로 중요도를 구분하고, 텍스트로 상세 내용을 기록한다.
이렇게 진행하면 문서화와 프로토타입이 동시에 만들어진다. 기획자는 화면을 직접 보면서 설계할 수 있고, 개발자는 구현해야 할 내용을 명확하게 파악할 수 있다. 설계와 설명이 하나의 산출물에 통합되는 효율적인 방법이다.
쇼핑몰 사례로 보는 실무 적용
쇼핑몰을 예시로 전체 과정을 진행한다. 쇼핑몰을 선택한 이유는 전체를 다룰 수 있기 때문이다. 첫째, 대부분의 사람이 쇼핑몰을 사용해 본 경험이 있어 도메인 이해가 쉽다. 둘째, FO(Front Office)와 BO(Back Office)라는 명확한 구분이 있어 다양한 사용자 관점을 다룰 수 있다. 셋째, 상품 관리, 주문 처리, 결제 프로세스 등 복잡한 비즈니스 로직을 포함한다.
FO는 고객이 직접 사용하는 영역이다. 홈페이지에서 시작해 상품을 탐색하고, 장바구니에 담고, 결제를 완료하는 전체 구매 여정이 포함된다. 각 단계마다 고려해야 할 상태가 있다. 로그인/비로그인, 재고 있음/없음, 쿠폰 적용/미적용. 이런 상태들을 프로토타입으로 표현하면 누락 없이 전체 시나리오를 검증할 수 있다.
BO는 쇼핑몰 운영자가 사용하는 관리 시스템이다. 상품 등록부터 주문 처리, 고객 관리, 프로모션 설정까지 다양한 기능이 필요하다. BO 설계의 핵심은 효율성이다. 운영자가 반복적으로 수행하는 작업을 최소한의 클릭으로 처리할 수 있어야 한다. 대시보드에서 주요 지표를 한눈에 확인하고, 문제가 발생하면 즉시 해당 화면으로 이동할 수 있어야 한다.
실제 쇼핑몰 프로젝트에서는 도메인 객체 정의부터 시작한다. 상품, 카테고리, 고객, 장바구니, 주문, 쿠폰 등 핵심 객체와 속성을 정의한다. 이를 바탕으로 정보구조를 설계하고, 사이트맵을 작성한다. FO와 BO 각각에 대해 3개씩 초안을 만들고 최적안을 선택한다.
산출물과 활용 방법
이 연재의 방법론을 따르면 네 가지 핵심 산출물이 만들어진다.
첫째, 프로토타입 링크다. v0에서 제작한 프로토타입은 URL로 공유된다. 이해관계자는 별도 프로그램 설치 없이 브라우저에서 바로 확인할 수 있다. 프로토타입 모드에서는 실제 서비스처럼 화면을 전환하며 전체 플로우를 체험할 수 있다.
둘째, 시나리오 카드다. 주요 사용자 시나리오를 카드 형태로 정리한 것으로, Given-When-Then 형식(Gherkin 라이트)을 따른다. "고객이 로그인한 상태에서(Given) 장바구니 버튼을 클릭하면(When) 장바구니 페이지로 이동한다(Then)". 이런 카드는 개발팀의 테스트 케이스로 직접 활용된다.
셋째, 결정 로그다. 기획 과정에서 내린 모든 결정을 기록한다. "왜 원스텝 체크아웃 대신 멀티스텝을 선택했는가", "필터를 왼쪽에 배치한 이유는 무엇인가". 이런 기록은 향후 비슷한 결정을 내릴 때 참고자료가 되고, 신규 팀원이 프로젝트 콘텍스트를 이해하는 데 도움이 된다. Figma 프레임 안에 직접 남겨 버전 관리와 함께 보관된다.
넷째, 요약 PDF다. 경영진 보고나 외부 공유를 위한 간략한 문서다. 핵심 화면 캡처, 주요 기능 리스트, 일정 계획이 포함된다. 프로토타입을 볼 시간이 없는 의사결정자를 위한 요약본이다.
단계별 로드맵
이 연재에서 제시하는 로드맵은 이전 기획 방식과 크게 다르지 않다. 초기 요구사항 분석은 거의 같고, 바로 PPT나 Figma로 화면 설계서를 작성했던 부분이 v0를 활용한 프로토타입으로 진행되는 것만 다르다.
첫 번째 단계는 요구사항을 정리한다. 비즈니스 목표, 제약사항, 경쟁 레퍼런스를 한 장으로 정리하고, GPT를 활용해 갭 분석과 핵심 질문을 도출한다. 운영, CS, 마케팅, 보안 담당자별 인터뷰 스크립트도 GPT가 생성한다.
두 번째는 구조를 설계한다. 유스케이스와 수용 기준(AC)을 정의하고, MoSCoW(Must-Have(반드시), Should-Have(해야 할), Could-Have(할 수 있으면), Won't-Have(안 할) 네 가지로 분류하는 기법)와 RICE 매트릭스(Reach(도달 범위), Impact(영향), Confidence(신뢰도), Effort(노력) 네 가지 요소를 점수화하여 우선순위 기법)로 우선순위를 정한다. 정보구조(IA) 초안을 2,3개 만들고 최적안을 선택한다. 용어와 라벨 가이드를 작성하고, 텍스트 플로우 다이어그램으로 주요 프로세스를 정리한다.
세 번째는 FO 핵심 화면을 제작한다. Figma Community에서 적합한 템플릿을 선택하고, v0로 5개 핵심 페이지(홈, 리스트, 상세, 장바구니, 결제)를 생성한다. 생성된 화면을 Figma로 가져와 컴포넌트로 기능을 30% 수준까지 문서화한다.
네 번째는 BO 핵심 화면을 제작한다. 대시보드, 상품 관리, 주문 관리, 고객 관리, 설정 화면을 같은 방식으로 제작한다. FO와 달리 BO는 효율성에 중점을 두고, 테이블과 폼 중심으로 설계한다. 역시 Figma로 30% 문서화를 진행한다.
다섯 번째는 완성도를 높인다. 와이어프레임을 하이파이 디자인으로 승격시키고, 4가지 상태(기본, 호버, 액티브, 디스에이블드)를 정의한다. 반응형 브레이크포인트를 설정하고, 접근성 요소를 점검한다. 시나리오 테스트를 진행하고, 리뷰 피드백을 반영한다. 마지막으로 전체 산출물을 패키징 한다.
기획, 그 가능성과 한계
기획에서 프로토타입이 구현되었다고 Front 개발자가 필요 없어진다는 의미는 아니다. 오히려 개발팀과 더 나은 커뮤니케이션을 위한 방법이다. 프로토타입은 개발팀이 구현해야 할 것을 명확하게 보여준다. 애매한 해석의 여지가 줄어들고, 구현 과정에서 발생하는 질문도 감소할 수 있다.
프로토타입은 실제 서비스가 아니다. 데이터베이스 연동, 서버 통신, 복잡한 비즈니스 로직은 구현되지 않는다. 성능 이슈나 보안 문제는 개발 단계에서 발견된다. 프로토타입은 "무엇을" 만들 것인지 보여주지만, "어떻게" 만들 것인지는 여전히 개발팀의 영역이다.
프로토타입 중심 기획의 가치는 분명하다. 빠른 검증, 명확한 커뮤니케이션, 즉각적인 피드백. 이것만으로도 프로젝트 성공 확률은 크게 높아질 수 있다. 문서 더미 속에서 길을 잃는 대신, 실제 화면을 보며 함께 만들어가는 것이 다음 시대 기획의 모습일 것이다.
