모든 성공적인 제품 개발의 중심에는 ‘명확한 요구사항’이 있습니다. 하지만 아이디어의 불꽃이 사용자가 사랑하는 제품으로 현실화되는 과정은 결코 순탄치 않습니다. 수많은 프로젝트가 길을 잃는 가장 결정적인 이유는 바로 사용자의 필요(Needs)를 구체적이고, 측정 가능하며, 모두가 동의하는 요구사항(Requirements)으로 변환하는 데 실패하기 때문입니다. ‘사용하기 편하게 만들어 주세요’나 ‘직관적인 디자인을 원해요’와 같은 모호한 바람은 개발자에게 아무런 방향도 제시해주지 못하며, 끝없는 수정과 팀원 간의 갈등을 낳는 씨앗이 됩니다.
이 글에서는 추상적인 아이디어를 만질 수 있는 현실로 바꾸는 체계적인 여정, 즉 ‘사용자 요구사항 도출’의 핵심 5단계를 깊이 있게 탐구합니다. 이는 정보처리기사 시험에서도 매우 중요하게 다루어지는 핵심 개념입니다. 우리는 사용자의 목소리를 대변하는 ‘페르소나’를 시작으로, 그들의 이야기에 생명을 불어넣는 ‘정황 시나리오’, UI의 뼈대를 세우는 ‘콘셉트 모델’, 모든 요구사항을 체계적으로 관리하는 ‘요구사항 매트릭스’, 그리고 마침내 아이디어를 눈앞에 펼쳐 보이는 ‘UI 컨셉션’에 이르기까지, 각 단계가 어떻게 유기적으로 연결되어 견고한 제품의 토대를 만들어가는지 구체적인 예시와 함께 살펴볼 것입니다. 이 과정을 통해 여러분은 단순한 아이디어를 성공적인 제품으로 이끄는 구체적인 설계도를 그리는 법을 배우게 될 것입니다.
목차
- 페르소나: 요구사항의 목소리를 담다
- 정황 시나리오: 사용자의 이야기에 생명 불어넣기
- 콘셉트 모델: UI의 청사진 그리기
- 요구사항 매트릭스: 복잡함을 명쾌하게 관리하다
- UI 컨셉션: 아이디어를 눈앞에 펼치다
- 마무리: 체계적인 요구사항 도출의 힘
1. 페르소나: 요구사항의 목소리를 담다
요구사항의 목소리를 담다
사용자 요구사항 도출의 여정은 ‘누구를 위해 만드는가?’라는 근본적인 질문에서 시작합니다. 페르소나는 바로 이 질문에 대한 구체적인 대답입니다. 이전 글에서 다루었듯이, 페르소나는 실제 사용자 리서치 데이터를 기반으로 만들어진 가상의 인물로, 우리 팀이 만들어갈 제품의 핵심 사용자 그룹을 대표합니다. 요구사항 도출 과정에서 페르소나는 단순히 참고 자료에 그치지 않고, 모든 요구사항의 ‘출처’이자 ‘목소리’ 그 자체가 됩니다.
우리는 더 이상 “사용자는 이런 기능이 필요할 거야”라고 막연하게 추측하는 대신, “페르소나 ‘김지현’씨는 퇴근길에 30분 안에 저녁을 준비해야 하니, 조리 시간으로 레시피를 필터링하는 기능이 반드시 필요해”라고 구체적으로 이야기할 수 있게 됩니다. 이처럼 페르소나는 팀의 모든 논의를 사용자의 실제 목표와 고충에 고정시키는 닻의 역할을 합니다. 모든 요구사항은 페르소나의 목표를 달성하거나, 그들의 문제를 해결하는 방향으로 귀결되어야 하며, 이를 통해 제품이 나아갈 방향의 일관성을 유지할 수 있습니다.
왜 페르소나로 시작하는가?
페르소나로 요구사항 도출을 시작하는 것은 건물을 짓기 전에 누가 살 집인지를 명확히 하는 것과 같습니다. 거주할 사람의 라이프스타일, 가족 구성원, 선호도를 알아야 그에 맞는 구조와 설계를 할 수 있듯, 페르소나의 목표와 행동 패턴을 먼저 정의해야 그들에게 정말로 필요한 기능과 경험을 설계할 수 있습니다. 페르소나는 팀원들이 각자 머릿속에 그리던 불분명한 ‘사용자상’을 하나로 통일시켜, 모두가 같은 사용자를 상상하며 제품을 만들게 합니다.
이는 개발 과정에서 발생할 수 있는 수많은 주관적인 의견 대립을 막아주는 효과적인 장치입니다. 기능의 우선순위를 정할 때, 디자인의 방향성을 결정할 때, “이 결정이 과연 우리 페르소나에게 도움이 되는가?”라는 질문은 가장 명확하고 객관적인 판단 기준이 되어 줍니다. 결국, 잘 만들어진 페르소나는 프로젝트 전체를 관통하는 사용자 중심적인 시각을 확보하는 첫 단추이자 가장 중요한 초석입니다.
요구사항 도출의 출발점
페르소나의 목표(Goals)와 좌절점(Frustrations)은 요구사항의 원석이 됩니다. 페르소나의 목표는 우리 제품이 반드시 만족시켜야 할 ‘기능적 요구사항’의 단서가 되고, 좌절점은 우리가 해결해야 할 ‘사용성 문제’나 ‘비기능적 요구사항’의 힌트가 됩니다. 이제 이 페르소나라는 주인공을 무대 위에 올려, 그들이 우리 제품을 만나는 구체적인 이야기를 그려볼 차례입니다. 그것이 바로 다음 단계인 ‘정황 시나리오’입니다.
2. 정황 시나리오: 사용자의 이야기에 생명 불어넣기
정황 시나리오란 무엇인가?
정황 시나리오(Contextual Scenario)는 페르소나가 특정 목표를 달성하기 위해 미래에 만들어질 우리 제품이나 서비스를 사용하는 과정을 구체적인 이야기 형식으로 풀어쓴 것입니다. 여기서 가장 중요한 단어는 바로 ‘정황(Context)’입니다. 이는 단순히 ‘사용자가 A 버튼을 누르고 B 화면으로 이동한다’와 같은 기능의 나열이 아니라, 사용자가 ‘언제, 어디서, 어떤 상황에서, 왜’ 그 행동을 하는지에 대한 배경과 맥락을 생생하게 묘사하는 것을 의미합니다.
예를 들어, 페르소나 ‘김지현’씨가 밀키트 앱을 사용하는 시나리오는 “조용한 집에서 여유롭게 메뉴를 고른다”가 아닐 수 있습니다. “퇴근 시간 만원 지하철 안에서, 한 손으로는 손잡이를 잡고 다른 한 손으로 스마트폰을 보며 급하게 저녁 메뉴를 주문한다”와 같은 구체적인 정황을 담아야 합니다. 시나리오는 이처럼 페르소나의 삶 속으로 제품을 가져와, 실제 사용 환경에서 발생할 수 있는 다양한 변수와 제약 조건을 미리 탐색하게 해주는 강력한 스토리텔링 도구입니다.
시나리오가 요구사항을 구체화하는 방법
잘 쓰인 정황 시나리오는 수많은 요구사항을 자연스럽게 드러내 줍니다. 앞서 예로 든 ‘만원 지하철’ 시나리오를 통해 우리는 다음과 같은 구체적인 요구사항들을 도출할 수 있습니다.
- 흔들리는 환경에서도 쉽게 누를 수 있도록 터치 영역이 큰 버튼이 필요하다. (사용성 요구사항)
- 한 손 조작이 용이하도록 주요 기능은 화면 하단에 배치해야 한다. (UI 구조 요구사항)
- 지하철이 터널에 들어가 통신이 끊겨도 주문 과정이 중단되지 않도록 임시 저장 기능이 필요하다. (비기능적 요구사항)
- 메뉴를 오래 고민할 시간이 없으므로, ‘최근 주문 메뉴’나 ‘인기 메뉴’를 바로 주문할 수 있는 빠른 주문 기능이 필요하다. (기능적 요구사항)
이처럼 시나리오는 추상적인 페르소나의 목표를 실제 사용 맥락 속에서 구체적인 기능과 인터페이스에 대한 요구사항으로 번역해주는 다리 역할을 합니다.
좋은 시나리오의 조건
효과적인 정황 시나리오는 몇 가지 특징을 가집니다. 첫째, 페르소나의 관점에서 1인칭 또는 3인칭 관찰자 시점으로 서술되어야 합니다. 둘째, 시스템의 기능이 아닌, 사용자의 목표 달성 과정에 초점을 맞춰야 합니다. 셋째, 이상적인 성공 사례뿐만 아니라, 사용자가 겪을 수 있는 문제 상황이나 예외 케이스를 포함하면 더 풍부한 요구사항을 도출할 수 있습니다. 시나리오는 개발팀과 디자이너에게 ‘무엇을 만들어야 하는가’를 넘어, ‘우리가 만드는 것이 사용자의 삶에 어떤 의미를 갖는가’를 일깨워주는 중요한 소통의 도구가 됩니다.
3. 콘셉트 모델: UI의 청사진 그리기
콘셉트 모델이란?
정황 시나리오를 통해 사용자의 이야기와 필요한 기능들을 구체화했다면, 이제 이것들을 담아낼 그릇의 구조를 설계할 차례입니다. 콘셉트 모델(Conceptual Model)은 제품이나 서비스가 사용자에게 제공할 주요 개념(Concept)들과 그들 간의 관계를 정의한 일종의 시스템 구조도 또는 UI의 청사진입니다. 이는 눈에 보이는 화면 디자인을 시작하기 전에, 정보와 기능의 전체적인 뼈대, 즉 정보 구조(Information Architecture)를 잡는 과정입니다.
예를 들어, 밀키트 앱의 콘셉트 모델은 ‘레시피’, ‘식재료’, ‘마이페이지’, ‘장바구니’, ‘주문’과 같은 핵심적인 개념(객체)들로 구성됩니다. 그리고 이 개념들이 서로 어떻게 연결되는지를 정의합니다. 가령, ‘사용자는 여러 레시피를 장바구니에 담을 수 있다’, ‘하나의 레시피는 여러 식재료 정보로 구성된다’, ‘주문 내역은 마이페이지에서 확인할 수 있다’와 같은 관계를 명확히 하는 것입니다. 이 과정은 사용자에게 일관성 있고 예측 가능한 경험을 제공하는 논리적인 UI 구조의 기반이 됩니다.
콘셉트 모델의 구성 요소
콘셉트 모델은 보통 다이어그램 형태로 시각화되며, 다음과 같은 요소들을 포함합니다.
- 객체(Objects): 사용자가 인식하고 상호작용하는 주요 정보 단위입니다. (예: 레시피, 리뷰, 회원 정보)
- 속성(Attributes): 각 객체가 가지는 세부 정보입니다. (예: 레시피 객체는 ‘조리 시간’, ‘난이도’, ‘가격’ 등의 속성을 가집니다.)
- 행동(Actions): 사용자가 객체를 대상으로 수행할 수 있는 동작입니다. (예: 레시피를 ‘검색하다’, ‘찜하다’, ‘주문하다’)
- 관계(Relationships): 객체들 사이의 관계를 정의합니다. (예: 하나의 회원은 여러 개의 리뷰를 작성할 수 있다.)
이러한 모델을 만드는 데에는 사용자가 생각하는 정보의 그룹핑 방식을 파악하는 ‘카드 소팅(Card Sorting)’과 같은 리서치 기법이 함께 활용되기도 합니다.
시나리오에서 콘셉트 모델로
콘셉트 모델은 시나리오로부터 자연스럽게 도출됩니다. 정황 시나리오에 등장하는 주요 명사들은 콘셉트 모델의 ‘객체’가 될 확률이 높고, 동사들은 ‘행동’이 될 가능성이 큽니다. 예를 들어, “김지현 씨가 앱에서 추천 레시피를 보고, 마음에 드는 것을 장바구니에 담아 주문을 완료했다”는 문장에서 ‘레시피’, ‘장바구니’, ‘주문’은 핵심 객체가 되고, ‘보다’, ‘담다’, ‘주문하다’는 사용자의 주요 행동이 됩니다. 이처럼 시나리오 속 사용자 이야기를 분석하여 핵심 개념과 관계를 추출해 구조화하는 과정이 바로 콘셉트 모델링이며, 이는 복잡한 시스템을 논리적이고 체계적으로 설계하는 데 필수적입니다.
4. 요구사항 매트릭스: 복잡함을 명쾌하게 관리하다
요구사항 매트릭스란?
페르소나, 시나리오, 콘셉트 모델을 통해 도출된 수많은 요구사항들을 체계적으로 관리하지 않으면, 누락되거나 중복되거나 혹은 우선순위가 뒤섞이는 등 혼란이 발생하기 쉽습니다. 요구사항 매트릭스(Requirements Matrix)는 이러한 혼란을 막기 위해, 도출된 모든 요구사항을 표(Matrix) 형태로 정리하여 추적하고 관리하는 문서 또는 도구입니다. 이는 프로젝트에 관련된 모든 이해관계자들이 요구사항에 대해 동일한 정보를 공유하고, 진행 상황을 명확하게 파악할 수 있게 해주는 중앙 통제실과 같은 역할을 합니다.
각 요구사항은 고유한 ID를 부여받고, 요구사항의 상세 내용, 출처(어떤 페르소나의 어떤 시나리오에서 나왔는지), 우선순위, 현재 개발 상태(진행 중, 완료, 보류 등), 담당자 등의 정보를 포함합니다. 이 매트릭스를 통해 우리는 프로젝트의 전체 범위를 한눈에 파악할 수 있으며, 각 요구사항이 비즈니스 목표나 사용자 목표와 어떻게 연결되는지 추적할 수 있습니다(요구사항 추적성).
왜 매트릭스가 필요한가?
프로젝트가 복잡해질수록 요구사항의 수는 기하급수적으로 늘어납니다. 이때 매트릭스가 없다면, “그 기능은 원래 만들기로 했었나요?”와 같은 소모적인 논쟁이 반복될 수 있습니다. 요구사항 매트릭스는 모든 요구사항을 명문화하여 이러한 혼선을 방지하고, 프로젝트의 투명성을 높입니다.
특히, 한정된 자원과 시간 속에서 무엇을 먼저 개발할지 결정해야 할 때, 매트릭스는 매우 중요한 역할을 합니다. MoSCoW 기법(Must-have, Should-have, Could-have, Won’t-have) 등을 활용하여 각 요구사항의 우선순위를 명확히 표시해 두면, 핵심 기능 개발에 집중하고 부가적인 기능 때문에 일정이 지연되는 것을 막을 수 있습니다. 이는 특히 프로덕트 오너(PO)가 제품 백로그를 관리하고, 개발팀과 효율적으로 소통하는 데 필수적인 도구입니다.
요구사항 매트릭스 예시
요구사항 매트릭스는 보통 엑셀이나 지라(Jira)와 같은 프로젝트 관리 도구를 사용하여 만들어지며, 기본적인 형태는 다음과 같습니다.
| ID | 요구사항 설명 | 출처 | 우선순위 | 상태 | 비고 |
|---|---|---|---|---|---|
| REQ-001 | 사용자는 조리 시간(예: 30분 이내)으로 레시피를 필터링할 수 있어야 한다. | 페르소나 ‘김지현’, 시나리오 ‘퇴근길 주문’ | Must | 완료 | |
| REQ-002 | 사용자는 알레르기 유발 식재료를 제외하고 레시피를 검색할 수 있어야 한다. | FGI-01 | Should | 진행 중 | 디자인 검토 필요 |
| REQ-003 | 사용자는 과거에 주문했던 메뉴를 재주문할 수 있어야 한다. | 페르소나 ‘김지현’, 시나리오 ‘퇴근길 주문’ | Must | 대기 | |
| REQ-004 | 레시피에 대한 동영상 가이드를 제공한다. | 경쟁사 분석 | Could | 보류 | MVP 이후 고려 |
5. UI 컨셉션: 아이디어를 눈앞에 펼치다
UI 컨셉션이란?
지금까지의 단계가 주로 텍스트와 다이어그램을 통해 요구사항을 정의하고 구조화하는 ‘추상적인’ 과정이었다면, UI 컨셉션(UI Conception)은 마침내 그 아이디어들을 눈에 보이는 ‘구체적인’ 형태로 시각화하는 단계입니다. 즉, 도출된 요구사항들과 콘셉트 모델을 바탕으로 UI의 전반적인 방향과 스타일, 레이아웃, 그리고 핵심적인 인터랙션에 대한 아이디어를 구체화하고 시각적으로 표현하는 모든 활동을 의미합니다.
이 단계에서는 최종 디자인처럼 모든 세부사항을 완벽하게 다듬기보다는, 다양한 아이디어를 빠르게 탐색하고 검토하는 데 중점을 둡니다. 손으로 그린 간단한 스케치, 화면의 구조와 레이아웃에 집중하는 와이어프레임, 전반적인 디자인 톤앤매너를 보여주는 무드보드(Moodboard) 등이 이 단계의 주요 산출물입니다. UI 컨셉션은 추상적인 요구사항 목록을 팀원들과 이해관계자들이 실제로 보고 만질 수 있는 형태로 바꾸어, 조기에 구체적인 피드백을 주고받을 수 있게 합니다.
주요 기법: 와이어프레임과 프로토타입
UI 컨셉션 단계에서 가장 널리 사용되는 두 가지 기법은 와이어프레임과 프로토타입입니다.
- 와이어프레임(Wireframe): 색상, 이미지, 타이포그래피 등 시각적 요소를 의도적으로 배제하고, 오직 화면의 구조, 콘텐츠의 배치, 기능 요소들의 관계에만 집중하여 그리는 저충실도(Low-fidelity) 설계도입니다. UI의 뼈대를 만드는 작업으로, 빠르고 쉽게 만들고 수정할 수 있어 초기 아이디어 검토에 매우 효과적입니다.
- 프로토타입(Prototype): 실제 제품과 유사하게 사용자와 상호작용(Interaction)이 가능하도록 만든 동적인 모델입니다. 단순한 클릭으로 화면 전환을 보여주는 수준부터 실제와 거의 흡사한 고충실도(High-fidelity) 수준까지 다양합니다. 사용성 테스트를 통해 사용 흐름(Flow)의 문제점을 발견하고 개선하는 데 결정적인 역할을 합니다.
요구사항을 시각 언어로 번역하기
UI 컨셉션은 이전 단계의 결과물들을 시각 언어로 충실하게 번역하는 과정입니다. 콘셉트 모델은 와이어프레임에서 어떤 정보 덩어리(객체)들이 한 화면에 나타나야 하는지에 대한 가이드가 됩니다. 요구사항 매트릭스에 있는 ‘REQ-001: 조리 시간 필터링 기능’은 와이어프레임에서 필터 아이콘과 시간 선택 옵션이라는 구체적인 UI 요소로 표현됩니다. 정황 시나리오에서 묘사된 ‘한 손 조작’이라는 맥락은, 주요 버튼들을 화면 하단에 배치하는 레이아웃 결정으로 이어집니다. 이처럼 UI 컨셉션은 모든 추상적인 요구사항들이 구체적인 형태와 생명을 얻는 창의적인 과정이자, 논리적인 구현의 과정입니다.
6. 마무리: 체계적인 요구사항 도출의 힘
아이디어에서 제품까지의 체계적인 여정
지금까지 우리는 하나의 아이디어가 사용자가 만나는 제품으로 탄생하기까지 거쳐야 하는 체계적인 요구사항 도출 여정을 함께 걸어왔습니다. 이 여정은 서로 긴밀하게 연결된 하나의 흐름입니다. 우리는 먼저 사용자의 목소리를 대변할 주인공, ‘페르소나’를 만났습니다. 그리고 그 주인공이 우리 제품과 함께하는 생생한 이야기, ‘정황 시나리오’를 들었습니다. 그 이야기 속에서 핵심 개념을 추출하여 시스템의 뼈대인 ‘콘셉트 모델’을 세웠고, 발견된 모든 요구사항들을 빠짐없이 기록하고 관리하기 위해 ‘요구사항 매트릭스’라는 꼼꼼한 지도를 만들었습니다. 마지막으로, 이 모든 설계도를 바탕으로 아이디어의 첫 모습인 ‘UI 컨셉션’을 눈앞에 그려냈습니다.
이 5단계의 과정은 단순히 문서를 만드는 절차가 아닙니다. 이것은 불확실성을 줄이고, 팀의 소통 비용을 낮추며, 사용자가 진정으로 원하는 것을 만들 확률을 극대화하는 가장 검증된 전략입니다. 각 단계는 이전 단계의 결과물을 입력받아 다음 단계의 결과물을 만들어내는 논리적인 체인과 같아서, 이 과정을 충실히 따를 때 비로소 견고하고 사용자 중심적인 제품의 토대를 마련할 수 있습니다.
적용 시 주의사항
이러한 방법론들을 실제 프로젝트에 적용할 때는 몇 가지 유연한 사고가 필요합니다. 첫째, 이 과정은 폭포수처럼 한 방향으로만 흐르지 않습니다. UI 컨셉션 단계에서 프로토타입을 만들어보니 시나리오가 비현실적이었다는 사실을 깨닫고 다시 앞으로 돌아가 수정하는 등, 필요에 따라 앞 단계를 다시 검토하고 개선하는 반복적인(Iterative) 접근이 필수적입니다.
둘째, 프로젝트의 규모와 특성에 맞게 각 산출물의 상세 수준을 조절해야 합니다. 작은 규모의 프로젝트에서 너무 상세하고 무거운 문서를 만드는 것은 오히려 효율성을 떨어뜨릴 수 있습니다. 중요한 것은 문서의 형식이 아니라, ‘팀원 모두가 요구사항에 대해 동일한 이해를 갖는 것’이라는 본질을 잊지 말아야 합니다. 마지막으로, 이 모든 과정에 기획자뿐만 아니라 디자이너와 개발자가 초기부터 함께 참여하는 것이 매우 중요합니다. 다양한 관점이 조기에 반영될수록, 기술적으로 실현 가능하고 사용자에게 더 나은 가치를 제공하는 요구사항을 도출할 수 있을 것입니다.