PRD부터 시스템 설계까지: 한 장의 그림으로 연결되는 기획 여정
"사용자가 로그인하면 대시보드가 나와야 한다"라는 간단한 요구사항 하나에도 생각보다 많은 것들이 숨어있습니다. 어떤 사용자인지, 어떤 권한을 가졌는지, 무엇을 먼저 봐야 하는지, 시스템은 어떻게 이를 판단하고 처리할지까지 말이죠.
한 헬스케어 스타트업 프로젝트에서 "환자 정보 관리" 기능을 기획한다고 가정해봅시다. 처음에는 단순해 보였지만, 막상 세부사항을 파고들수록 복잡한 퍼즐처럼 여러 조각들이 얽혀있다는 것을 발견하게 될 것입니다.
의료진용 앱인지 환자용 앱인지, 개인정보 보호는 어떻게 할지, 응급상황에서는 어떤 정보를 우선 보여줄지, 시스템 장애 시에는 어떻게 대응할지까지. 이 모든 것들이 하나씩 정리되어야 비로소 개발팀이 실제로 만들 수 있는 명확한 그림이 나옵니다.
PRD: 모든 것의 시작점
**PRD(Product Requirements Document)**는 마치 건축물의 설계도면과 같습니다. 무엇을 만들 것인지, 왜 만들어야 하는지, 누가 사용할 것인지에 대한 근본적인 질문들에 답하는 문서죠.
일전 모바일 뱅킹 앱 프로젝트에서 PRD 작성 과정을 경험했습니다. 처음에는 "더 편리한 계좌이체 기능"이라는 모호한 요구사항으로 시작했지만, PRD를 통해 구체적인 모습을 잡아갔습니다. 누가(20-40대 직장인), 언제(업무시간 중 급한 송금), 어디서(사무실, 지하철, 카페), 왜(빠르고 안전한 송금), 어떻게(생체인증, 즐겨찾기 기능)까지 명확해졌습니다.
PRD에는 비즈니스 목표와 사용자 니즈가 어떻게 연결되는지가 담겨야 합니다. 단순히 기능 목록이 아니라, 그 기능이 존재해야 하는 이유와 가치가 설명되어야 하죠. 성공 지표도 구체적으로 정의합니다. "사용자 만족도 향상"이 아니라 "송금 완료율 95% 이상, 평균 송금 시간 30초 이내"처럼 측정 가능한 형태로 말입니다.
기능정의: 아이디어가 실체가 되는 순간
PRD에서 정의된 방향성을 바탕으로 구체적인 기능들을 정의하는 단계입니다. 이때 중요한 것은 기능 하나하나가 사용자의 실제 행동과 연결되어야 한다는 점입니다.
예를 들어 "즐겨찾기 기능"이라고 해도, 사용자가 어떤 상황에서 즐겨찾기를 등록하고, 언제 사용하며, 몇 개까지 등록할 수 있고, 중복 등록 시에는 어떻게 처리할지까지 정의되어야 합니다. 추상적인 개념이 사용자가 실제로 클릭하고 입력하는 구체적인 행동으로 바뀌는 순간이죠.
한 이커머스 플랫폼에서 "상품 추천" 기능을 정의할 때도 비슷한 과정을 거쳤습니다. 단순히 "사용자에게 상품을 추천한다"가 아니라, 언제(첫 방문시, 검색 후, 장바구니 담기 후), 어떤 기준으로(구매이력, 조회이력, 유사 사용자), 몇 개를(메인 4개, 상세페이지 8개), 어떤 형태로(카드형, 리스트형) 보여줄지까지 구체화했습니다.
기능정의서에는 각 기능의 우선순위와 의존관계도 명시되어야 합니다. A기능이 완성되어야 B기능을 개발할 수 있다면, 이런 순서와 제약사항들이 명확히 기록되어야 개발 일정과 리소스 배분이 가능해집니다.
요건정의: 디테일 속에 숨은 성공 요소
**요건정의(Requirements Definition)**는 정의된 기능들이 실제로 어떻게 작동해야 하는지 세밀하게 기술하는 단계입니다. 여기서 놓친 디테일 하나가 나중에 큰 문제가 되는 경우를 자주 봅니다.
보안 요건, 성능 요건, 호환성 요건 등 비기능적 요구사항들이 특히 중요합니다. "빠르게 작동해야 한다"가 아니라 "3초 이내 페이지 로딩, 1초 이내 검색 결과 표시"처럼 구체적인 기준이 필요하죠.
한 온라인 교육 플랫폼 프로젝트를 가정해봅시다. "동영상 재생" 기능 하나만 해도 수많은 요건들이 도출될 것입니다. 지원 해상도(720p, 1080p, 4K), 재생 속도 조절(0.5배~2배), 자막 지원, 구간 반복, 북마크, 진도율 추적, 네트워크 불안정 시 품질 자동 조절, 모바일 데이터 절약 모드 등이 모두 별도의 요건으로 정의되어야 할 것입니다.
예외 상황 처리도 요건정의의 핵심입니다. 정상적인 상황만 고려하면 80%까지는 순조롭게 진행되지만, 나머지 20%의 예외 상황들이 실제 사용자 경험을 좌우합니다. 네트워크 끊김, 서버 오류, 잘못된 입력값, 동시 접속자 폭증 등 다양한 상황에서 시스템이 어떻게 반응할지 미리 정의해야 합니다.
플로우: 사용자 여정의 구체적 지도
플로우(Flow) 설계는 사용자가 실제로 서비스를 이용하는 과정을 단계별로 그려보는 작업입니다. 이때 중요한 것은 해피패스(정상적인 경로)뿐만 아니라 다양한 분기점과 예외 상황도 함께 고려하는 것입니다.
일전 금융 서비스 앱에서 "대출 신청" 플로우를 설계했을 때, 처음에는 단순한 직선적 과정으로 생각했습니다. 하지만 실제로는 신용등급 확인, 소득 증빙, 담보 설정, 심사 대기, 추가 서류 요청, 조건 변경, 승인/거부 등 복잡한 분기들이 존재했습니다.
특히 사용자가 중도에 이탈했다가 다시 돌아오는 상황을 고려하는 것이 중요합니다. 대출 신청을 절반만 하고 며칠 후 다시 접속했을 때, 어디서부터 시작해야 하는지, 이전 정보는 얼마나 유지되는지, 만료된 정보는 어떻게 처리할지 등이 모두 플로우에 반영되어야 합니다.
모바일과 웹의 크로스플랫폼 플로우도 고려사항입니다. 모바일에서 시작한 작업을 웹에서 이어서 할 수 있는지, 동기화는 어떻게 되는지, 각 플랫폼의 특성(생체인증, 푸시알림 등)을 어떻게 활용할지도 플로우 설계에 영향을 줍니다.
IA: 정보의 논리적 구조
**IA(Information Architecture)**는 서비스 내의 모든 정보와 기능들을 논리적으로 구조화하는 작업입니다. 사용자가 원하는 정보를 빠르고 직관적으로 찾을 수 있도록 하는 것이 핵심이죠.
한 종합쇼핑몰 프로젝트에서 카테고리 구조를 설계할 때의 경험을 돌이켜보면, 단순히 상품을 분류하는 것 이상의 고민이 필요했습니다. 사용자가 "운동화"를 찾을 때, 브랜드별로 찾을지, 용도별로 찾을지, 가격대별로 찾을지에 따라 IA 구조가 달라집니다.
다면적 분류 체계가 필요한 경우가 많습니다. 같은 상품이라도 카테고리별, 브랜드별, 가격별, 인기순 등 여러 관점에서 접근할 수 있어야 하죠. 이때 중요한 것은 사용자가 혼란스러워하지 않도록 주 카테고리와 보조 카테고리를 명확히 구분하는 것입니다.
검색과 브라우징의 균형도 IA 설계의 중요한 포인트입니다. 명확한 목적이 있는 사용자는 검색을 선호하지만, 둘러보며 발견하고 싶은 사용자는 브라우징을 선호합니다. 두 니즈를 모두 만족시킬 수 있는 구조를 만드는 것이 과제입니다.
메뉴 깊이도 신중하게 결정해야 합니다. 너무 얕으면 한 페이지에 너무 많은 옵션이 나열되고, 너무 깊으면 사용자가 길을 잃기 쉽습니다. 일반적으로 3-4단계를 넘지 않는 것이 좋지만, 서비스 특성에 따라 조절이 필요합니다.
시스템 구조: 보이지 않는 기반
**시스템 구조(System Architecture)**는 사용자에게는 보이지 않지만 서비스의 안정성과 확장성을 결정하는 중요한 요소입니다. 기획자도 기본적인 시스템 구조를 이해해야 현실적인 기획이 가능합니다.
데이터베이스 설계에서는 데이터 간의 관계가 핵심입니다. 사용자 정보, 상품 정보, 주문 정보가 어떻게 연결되고, 각각 어떤 속성을 가져야 하는지 정의해야 합니다. 이때 놓치기 쉬운 것이 이력 데이터입니다. 현재 상태만이 아니라 변경 이력도 추적할 수 있어야 하는 경우가 많습니다.
API 설계는 프론트엔드와 백엔드, 그리고 외부 시스템과의 소통 방식을 정의합니다. 어떤 정보를 주고받을지, 어떤 형식으로 주고받을지, 오류 발생시 어떻게 처리할지 등이 명확해야 합니다.
보안 아키텍처도 초기부터 고려되어야 합니다. 개인정보는 어떻게 암호화할지, 인증과 권한은 어떻게 관리할지, 해킹 시도는 어떻게 탐지하고 차단할지 등이 시스템 설계에 반영되어야 합니다.
확장성과 성능도 중요한 고려사항입니다. 현재 예상 사용자 수의 10배가 몰려도 시스템이 버틸 수 있는지, 데이터가 현재의 100배로 늘어나도 검색 속도를 유지할 수 있는지 등을 미리 검토해야 합니다.
연결된 하나의 그림
이 모든 산출물들은 독립적인 것이 아니라 하나의 일관된 그림을 이루어야 합니다. PRD의 비즈니스 목표가 기능정의에서 구체적인 기능으로 구현되고, 요건정의에서 세밀하게 정의되며, 플로우에서 사용자 경험으로 연결되고, IA에서 논리적으로 구조화되며, 시스템 구조에서 기술적으로 실현되는 일련의 과정입니다.
각 단계에서 발견되는 이슈들은 이전 단계로 피드백되어 전체적인 완성도를 높입니다. 시스템 구조를 검토하다가 성능상 문제가 발견되면 기능정의나 플로우가 수정될 수 있고, 플로우를 그리다가 사용자 경험상 문제가 보이면 IA나 기능정의가 개선될 수 있습니다.
이런 반복적인 개선 과정을 거쳐야 비로소 개발팀이 실제로 구현할 수 있고, 사용자가 만족할 수 있으며, 비즈니스 목표를 달성할 수 있는 완성된 기획안이 탄생합니다. 문서 하나하나가 아니라 서로 연결된 하나의 큰 그림으로 바라보는 시각이 성공적인 서비스 기획의 출발점입니다.
Jay Kim 웹/앱 서비스기획 26년차
현대경제연구원 IT분야 전문 컨설턴트
프로필 http://bit.ly/3E1OGQB
프로젝트 문의: mailside@gmail.com (카카오톡, 지메일)