dsgnmstr; Design Monster

[태그:] 요구사항도출

  • 아이디어를 현실로: 페르소나부터 UI 컨셉션까지, 놓치면 안 될 요구사항 도출 5단계 (정보처리기사 합격 비법)

    아이디어를 현실로: 페르소나부터 UI 컨셉션까지, 놓치면 안 될 요구사항 도출 5단계 (정보처리기사 합격 비법)

    모든 성공적인 제품 개발의 중심에는 ‘명확한 요구사항’이 있습니다. 하지만 아이디어의 불꽃이 사용자가 사랑하는 제품으로 현실화되는 과정은 결코 순탄치 않습니다. 수많은 프로젝트가 길을 잃는 가장 결정적인 이유는 바로 사용자의 필요(Needs)를 구체적이고, 측정 가능하며, 모두가 동의하는 요구사항(Requirements)으로 변환하는 데 실패하기 때문입니다. ‘사용하기 편하게 만들어 주세요’나 ‘직관적인 디자인을 원해요’와 같은 모호한 바람은 개발자에게 아무런 방향도 제시해주지 못하며, 끝없는 수정과 팀원 간의 갈등을 낳는 씨앗이 됩니다.

    이 글에서는 추상적인 아이디어를 만질 수 있는 현실로 바꾸는 체계적인 여정, 즉 ‘사용자 요구사항 도출’의 핵심 5단계를 깊이 있게 탐구합니다. 이는 정보처리기사 시험에서도 매우 중요하게 다루어지는 핵심 개념입니다. 우리는 사용자의 목소리를 대변하는 ‘페르소나’를 시작으로, 그들의 이야기에 생명을 불어넣는 ‘정황 시나리오’, UI의 뼈대를 세우는 ‘콘셉트 모델’, 모든 요구사항을 체계적으로 관리하는 ‘요구사항 매트릭스’, 그리고 마침내 아이디어를 눈앞에 펼쳐 보이는 ‘UI 컨셉션’에 이르기까지, 각 단계가 어떻게 유기적으로 연결되어 견고한 제품의 토대를 만들어가는지 구체적인 예시와 함께 살펴볼 것입니다. 이 과정을 통해 여러분은 단순한 아이디어를 성공적인 제품으로 이끄는 구체적인 설계도를 그리는 법을 배우게 될 것입니다.

    목차

    1. 페르소나: 요구사항의 목소리를 담다
    2. 정황 시나리오: 사용자의 이야기에 생명 불어넣기
    3. 콘셉트 모델: UI의 청사진 그리기
    4. 요구사항 매트릭스: 복잡함을 명쾌하게 관리하다
    5. UI 컨셉션: 아이디어를 눈앞에 펼치다
    6. 마무리: 체계적인 요구사항 도출의 힘

    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-01Should진행 중디자인 검토 필요
    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) 접근이 필수적입니다.

    둘째, 프로젝트의 규모와 특성에 맞게 각 산출물의 상세 수준을 조절해야 합니다. 작은 규모의 프로젝트에서 너무 상세하고 무거운 문서를 만드는 것은 오히려 효율성을 떨어뜨릴 수 있습니다. 중요한 것은 문서의 형식이 아니라, ‘팀원 모두가 요구사항에 대해 동일한 이해를 갖는 것’이라는 본질을 잊지 말아야 합니다. 마지막으로, 이 모든 과정에 기획자뿐만 아니라 디자이너와 개발자가 초기부터 함께 참여하는 것이 매우 중요합니다. 다양한 관점이 조기에 반영될수록, 기술적으로 실현 가능하고 사용자에게 더 나은 가치를 제공하는 요구사항을 도출할 수 있을 것입니다.

  • 성공적인 제품의 첫 단추: 요구사항 분석, 8가지 핵심 기술 완전 정복

    성공적인 제품의 첫 단추: 요구사항 분석, 8가지 핵심 기술 완전 정복

    모든 성공적인 제품과 실패한 프로젝트 사이에는 눈에 보이지 않지만 결정적인 차이를 만드는 과정이 존재합니다. 바로 ‘요구사항 분석’입니다. 아무리 뛰어난 개발자와 디자이너가 있어도, 무엇을 만들어야 하는지에 대한 정의가 잘못되었다면 그 결과물은 사용자의 외면을 받거나 프로젝트의 방향을 송두리째 흔들게 됩니다. 요구사항 분석은 단순히 고객의 말을 받아 적는 행위가 아닙니다. 이는 숨겨진 니즈를 발견하고, 흩어진 의견을 하나로 모으며, 복잡한 아이디어를 명확한 청사진으로 바꾸는 종합 예술에 가깝습니다. 이 과정의 성패는 프로젝트의 운명을 결정하는 첫 단추이며, 이를 능숙하게 수행하기 위해서는 8가지 핵심적인 기술, 즉 청취, 인터뷰/질문, 분석, 중재, 관찰, 작성, 조직, 모델 작성 기술을 자유자재로 활용할 수 있어야 합니다. 이 기술들은 프로덕트 오너(PO), 분석가, 기획자에게는 가장 강력한 무기와도 같습니다.

    모든 것의 시작, ‘청취’ 기술

    요구사항 분석의 가장 기본적이면서도 강력한 기술은 바로 ‘청취(Listening)’입니다. 많은 사람들이 듣는 것(Hearing)과 청취하는 것(Listening)을 혼동하지만, 이 둘은 근본적으로 다릅니다. 수동적으로 소리가 귀에 들어오는 것이 듣는 것이라면, 청취는 상대방의 말뿐만 아니라 그 이면에 담긴 의도, 감정, 그리고 말하지 않는 맥락까지 이해하려는 적극적인 정신 활동입니다. 고객이나 이해관계자는 자신이 무엇을 원하는지 명확하게 표현하지 못하는 경우가 많습니다. 그들의 말 속에는 수많은 가정, 편견, 그리고 생략된 정보가 포함되어 있습니다. 뛰어난 분석가는 단순히 표면적인 단어에 집중하는 대신, 말의 톤, 속도, 사용되는 비유, 주저하는 지점 등을 통해 숨겨진 의미를 파악합니다. 이것이 바로 ‘적극적 경청(Active Listening)’입니다. 상대의 말을 요약하여 되묻거나, 감정을 읽어주며 공감을 표현하는 등의 기술을 통해 더 깊은 신뢰 관계를 형성하고, 이를 바탕으로 진정한 요구사항의 핵심에 다가갈 수 있습니다. 모든 위대한 분석은 위대한 청취에서 시작됩니다.

    숨겨진 맥락을 파헤치는 ‘인터뷰와 질문’ 기술

    청취가 수용적인 기술이라면, ‘인터뷰와 질문(Interviewing/Questioning)’은 숨겨진 정보를 능동적으로 탐색하고 이끌어내는 기술입니다. 좋은 질문은 막연한 아이디어에 형태를 부여하고, 암묵적인 가정을 수면 위로 드러내며, 대화의 방향을 올바른 길로 인도합니다. 질문 기술은 크게 두 가지로 나뉩니다. ‘폐쇄형 질문(Closed-ended Question)’은 ‘예/아니오’ 또는 단답형으로 답할 수 있는 질문으로, 사실 관계를 확인하거나 논점을 명확히 할 때 유용합니다. 반면 ‘개방형 질문(Open-ended Question)’은 상대방이 자신의 생각과 경험을 자유롭게 이야기하도록 유도하는 질문으로, “만약 ~라면 어떨 것 같으세요?”, “그 문제에 대해 좀 더 자세히 설명해주실 수 있나요?”와 같은 형태를 띱니다. 이를 통해 우리는 예상치 못했던 통찰이나 근본적인 문제의 원인을 발견할 수 있습니다. 특히 문제의 근원을 파고드는 ‘5 Whys’ 기법처럼, 하나의 현상에 대해 “왜?”라는 질문을 연달아 던짐으로써 피상적인 해결책이 아닌 근본적인 원인을 찾아내는 것이 중요합니다. 인터뷰는 단순히 답을 얻는 과정이 아니라, 질문을 통해 함께 답을 만들어가는 과정입니다.

    말하지 않는 진실을 읽는 ‘관찰’ 기술

    사용자는 종종 자신이 무엇을 하는지, 왜 그렇게 하는지 제대로 설명하지 못합니다. 때로는 자신이 말하는 것과 전혀 다르게 행동하기도 합니다. 이러한 말과 행동의 불일치 속에서 진정한 요구사항의 실마리를 찾아내는 기술이 바로 ‘관찰(Observation)’입니다. 관찰은 사용자가 실제 업무를 수행하거나 제품을 사용하는 환경에 직접 찾아가 그들의 행동, 환경, 상호작용을 있는 그대로 지켜보는 것을 의미합니다. 이를 ‘상황적 조사(Contextual Inquiry)’라고도 부릅니다. 예를 들어, 새로운 재고 관리 시스템을 개발한다고 가정해봅시다. 관리자와의 인터뷰에서는 ‘빠르고 정확한 입력’이 중요하다고 말할 수 있습니다. 하지만 실제 창고를 관찰해보면, 관리자는 무거운 물건을 옮기느라 양손이 자유롭지 못하고, 장갑을 낀 채로 키보드를 조작하며, 수시로 다른 동료와 소통하며 업무를 처리하는 모습을 발견할 수 있습니다. 이러한 관찰을 통해 ‘한 손으로 조작 가능한 인터페이스’, ‘음성 인식 입력 기능’, ‘협업을 위한 실시간 공유 기능’과 같은, 인터뷰만으로는 결코 얻을 수 없었던 핵심적인 요구사항을 도출할 수 있습니다. 관찰은 사용자의 입이 아닌 몸이 말해주는 진실을 듣는 가장 확실한 방법입니다.

    흩어진 정보를 꿰뚫는 ‘분석’ 기술

    청취, 인터뷰, 관찰을 통해 수집된 방대한 양의 정성적, 정량적 데이터는 그 자체로는 단순한 정보의 나열에 불과합니다. 이 혼란스러운 데이터 속에서 의미 있는 패턴을 찾아내고, 우선순위를 정하며, 논리적인 구조를 만들어내는 과정이 바로 ‘분석(Analysis)’ 기술입니다. 분석은 원석을 보석으로 가공하는 과정과 같습니다. 수집된 요구사항들을 검토하며 서로 충돌하는 내용은 없는지, 논리적으로 모순되는 부분은 없는지 확인해야 합니다. 또한, 모든 요구사항이 동일한 가치를 갖지 않기 때문에 우선순위를 정하는 것이 필수적입니다. 이때 MoSCoW 기법(Must-have, Should-have, Could-have, Won’t-have)이나 카노 모델(Kano Model)과 같은 프레임워크를 활용하여 어떤 기능을 반드시 포함해야 하고, 어떤 기능이 부가적인 가치를 제공하는지, 어떤 기능이 사용자의 만족도에 큰 영향을 미치는지 등을 체계적으로 평가할 수 있습니다. 분석 기술은 단순히 정보를 분류하는 것을 넘어, 데이터에 기반한 의사결정을 통해 한정된 자원으로 최대의 가치를 창출할 수 있는 길을 찾는 핵심적인 과정입니다.

    충돌을 기회로 바꾸는 ‘중재’ 기술

    하나의 프로젝트에는 다양한 이해관계자(Stakeholder)가 존재하며, 그들의 요구사항은 종종 서로 충돌합니다. 영업팀은 더 많은 기능을 원하고, 개발팀은 안정성과 기술 부채 감소를 우선하며, 경영진은 빠른 출시와 비용 절감을 압박합니다. 이러한 상충하는 요구사항들을 조율하고 모두가 동의할 수 있는 합의점을 찾아내는 기술이 바로 ‘중재(Facilitation/Mediation)’입니다. 중재자는 어느 한쪽의 편을 드는 것이 아니라, 객관적인 입장에서 각자의 입장을 충분히 듣고 그들의 근본적인 목표가 무엇인지 파악해야 합니다. 그리고 각 요구사항이 프로젝트 전체 목표에 어떤 영향을 미치는지 데이터와 논리를 바탕으로 설명하여 공통의 이해를 형성해야 합니다. 워크숍이나 회의를 효과적으로 진행하여 모든 참석자가 자유롭게 의견을 개진하고, 감정적인 대립이 아닌 건설적인 토론으로 이어지도록 이끄는 것이 중재자의 핵심 역할입니다. 성공적인 중재는 단순히 갈등을 봉합하는 것을 넘어, 다양한 관점의 충돌을 통해 더 창의적이고 견고한 해결책을 찾아내는 기회로 전환시킵니다.

    생각을 명확한 결과물로, ‘작성’ 기술

    요구사항 분석의 결과물은 명확하고 간결하며, 누가 읽어도 오해의 소지가 없는 문서로 기록되어야 합니다. 머릿속에 있는 훌륭한 아이디어도 제대로 ‘작성(Writing)’되지 않으면 아무런 의미를 갖지 못합니다. 요구사항 문서는 개발자, 디자이너, 테스터 등 프로젝트에 참여하는 모든 사람이 동일한 목표를 이해하고 각자의 역할을 수행할 수 있도록 안내하는 지도와 같습니다. 작성 기술의 핵심은 모호함을 제거하는 것입니다. ‘빠른 속도’, ‘사용자 친화적인 디자인’과 같은 추상적인 표현 대신, ‘페이지 로딩 시간 2초 이내’, ‘3번의 클릭 안에 주요 기능에 도달할 수 있어야 함’처럼 측정 가능하고 검증 가능한 형태로 구체화해야 합니다. 사용자 스토리(User Story) 형식으로 작성할 때는 ‘사용자로서(~As a user), 나는 ~을 원한다(~I want to), 왜냐하면 ~하기 때문이다(~so that)’의 구조를 따라 기능의 목적과 가치를 명확히 전달해야 합니다. 잘 작성된 요구사항 문서는 프로젝트 내내 발생하는 수많은 질문과 논쟁을 줄여주고, 모두가 같은 방향을 바라보며 나아갈 수 있게 하는 등대 역할을 합니다.

    혼돈에 질서를 부여하는 ‘조직’ 기술

    수십, 수백 개에 달하는 요구사항들을 단순히 나열만 해 둔다면 그 누구도 전체적인 그림을 파악할 수 없습니다. 혼란스러운 요구사항들에 체계와 구조를 부여하여 관리하고 추적할 수 있도록 만드는 것이 ‘조직(Organizing)’ 기술입니다. 조직화의 첫 단계는 요구사항들 간의 관계를 파악하고 계층 구조를 만드는 것입니다. 거시적인 비즈니스 요구사항에서 시작하여 사용자 요구사항, 기능 요구사항, 그리고 비기능 요구사항으로 세분화해 나가는 하향식 접근이 일반적입니다. 이렇게 구조화된 요구사항들은 제품 백로그(Product Backlog)와 같은 형태로 관리되며, 각 요구사항 항목(아이템)은 고유한 ID를 부여받아 개발, 디자인, 테스트, 배포 등 전체 개발 생명주기 동안 추적됩니다. 이를 ‘요구사항 추적성(Requirements Traceability)’이라고 하며, 특정 기능이 어떤 비즈니스 목표에서 비롯되었는지, 그리고 해당 기능이 제대로 구현되고 테스트되었는지를 역으로 추적할 수 있게 해줍니다. Jira, Confluence와 같은 도구를 활용하면 이러한 조직화 및 추적 과정을 효율적으로 관리할 수 있으며, 이는 프로젝트의 투명성과 관리 효율성을 극대화합니다.

    복잡함을 한눈에, ‘모델 작성’ 기술

    “백문이 불여일견(A picture is worth a thousand words)”이라는 말처럼, 복잡한 시스템의 구조나 동작 방식을 설명하는 데는 글보다 그림이 훨씬 효과적일 때가 많습니다. ‘모델 작성(Modeling)’ 기술은 요구사항과 시스템 설계를 시각적인 다이어그램이나 프로토타입으로 표현하여 이해관계자들이 시스템을 더 쉽고 직관적으로 이해할 수 있도록 돕는 기술입니다. UML(Unified Modeling Language)은 모델링의 표준 언어와도 같으며, 다양한 다이어그램을 제공합니다. 예를 들어, ‘유스케이스 다이어그램(Use Case Diagram)’은 사용자와 시스템 간의 상호작용을 전체적으로 보여주고, ‘액티비티 다이어그램(Activity Diagram)’은 특정 기능의 업무 흐름이나 프로세스를 순서대로 보여줍니다. ‘와이어프레임(Wireframe)’이나 ‘프로토타입(Prototype)’은 실제 화면의 구조와 동작을 미리 보여줌으로써, 텍스트로만 설명하기 어려운 사용자 인터페이스(UI)나 사용자 경험(UX)에 대한 구체적인 피드백을 초기에 받을 수 있게 해줍니다. 잘 만들어진 모델은 복잡한 시스템에 대한 공통된 이해의 기반을 마련하고, 잠재적인 설계 오류나 누락된 요구사항을 조기에 발견하게 해주는 강력한 소통 도구입니다.

    결론: 요구사항 분석은 기술이 아닌 예술이다

    지금까지 살펴본 청취, 인터뷰, 관찰, 분석, 중재, 작성, 조직, 모델링이라는 8가지 기술은 독립적으로 존재하는 것이 아니라, 하나의 목표를 위해 유기적으로 얽혀 작동하는 교향곡과 같습니다. 효과적인 청취는 깊이 있는 질문의 재료가 되고, 날카로운 질문과 관찰은 분석의 원천이 됩니다. 정확한 분석은 논리적인 작성과 조직화의 기반이 되며, 중재와 모델링은 이 모든 과정을 이해관계자들과 공유하고 합의를 이끌어내는 윤활유 역할을 합니다. 요구사항 분석은 정해진 공식대로만 수행하는 과학이라기보다는, 상황에 따라 적절한 기술을 조합하고 응용하는 예술에 가깝습니다. 이 기술들을 끊임없이 연마하고 체화하는 것은 성공적인 제품을 만들고자 하는 모든 프로덕트 오너와 분석가, 기획자가 해야 할 가장 중요하고 가치 있는 투자입니다. 결국, 제대로 된 첫 단추를 끼우는 것에서부터 위대한 제품의 여정은 시작되기 때문입니다.

  • “이게 아니었는데…” 프로젝트 실패를 막는 첫 단추: 요구사항 개발 프로세스 완벽 해부

    “이게 아니었는데…” 프로젝트 실패를 막는 첫 단추: 요구사항 개발 프로세스 완벽 해부

    안녕하세요! 사용자의 기대를 뛰어넘는 제품을 만들기 위해 오늘도 치열하게 고민하는 Product Owner(PO), 프로젝트 관리자(PM) 여러분, 그리고 정보처리기사 시험을 통해 소프트웨어 공학의 정수를 파고드는 미래의 전문가 여러분. 오늘은 모든 성공적인 프로젝트의 시작점이자, 실패를 막는 가장 강력한 방패인 ‘요구사항 개발 프로세스’에 대해 깊이 있게 이야기해 보고자 합니다.

    우리가 공들여 만든 제품이 시장에서 외면받거나, 프로젝트 막바지에 “우리가 원했던 건 이게 아니에요”라는 말을 듣게 되는 가장 큰 이유는 무엇일까요? 바로 ‘요구사항’이라는 첫 단추를 잘못 끼웠기 때문입니다. 사용자와 이해관계자의 머릿속에만 있던 막연한 기대를 명확하고 구체적인 ‘요구사항’으로 정의하고, 이를 모든 팀원이 동일하게 이해하도록 만드는 과정. 이것이 바로 요구사항 개발 프로세스의 핵심입니다. 이 글에서는 요구사항이 도출되고, 분석되며, 명세서를 통해 구체화되고, 최종적으로 확인되는 전 과정을 체계적으로 살펴봄으로써, 여러분의 프로젝트 성공 확률을 획기적으로 높일 수 있는 실질적인 인사이트를 제공해 드리겠습니다.

    목차

    1. 요구사항 개발 프로세스란? 왜 중요한가?
    2. 1단계: 요구사항 도출 (Elicitation) – 숨겨진 니즈를 찾아내는 탐사
    3. 2단계: 요구사항 분석 (Analysis) – 원석을 보석으로 다듬는 연마
    4. 3단계: 요구사항 명세 (Specification) – 모두의 언어로 기록하는 약속
    5. 4단계: 요구사항 확인 및 검증 (Validation & Verification) – 올바른 길을 가고 있는지 확인하는 나침반
    6. 성공적인 요구사항 관리를 위한 제언: 반복, 그리고 소통

    요구사항 개발 프로세스란? 왜 중요한가?

    요구사항 개발 프로세스는 소프트웨어가 해결해야 할 문제와 갖춰야 할 기능, 성능, 제약 조건 등을 체계적으로 정의하고 관리하는 일련의 활동을 의미합니다. 이는 단순히 ‘무엇을 만들 것인가’를 목록으로 만드는 것을 넘어, 이해관계자의 숨겨진 니즈를 발견하고(도출), 모순되거나 불분명한 요구들을 정제하며(분석), 누구나 이해할 수 있는 형태로 문서화하고(명세), 최종적으로 이 요구사항들이 올바른지 점검(확인)하는 전 과정을 포함합니다.

    이 과정이 중요한 이유는 명확합니다. 잘못 정의된 요구사항 위에 지어진 시스템은 사상누각과 같습니다. 개발 과정에서 끊임없는 재작업과 일정 지연을 유발하고, 프로젝트 비용을 눈덩이처럼 불어나게 합니다. 무엇보다, 최종 결과물이 사용자의 실제 문제를 해결해주지 못해 외면받게 됩니다. 특히 제품의 방향성을 결정하고 사용자 가치를 책임지는 Product Owner에게 이 프로세스에 대한 깊은 이해는 선택이 아닌 필수 역량입니다.

    1단계: 요구사항 도출 (Elicitation) – 숨겨진 니즈를 찾아내는 탐사

    요구사항 도출은 사용자를 포함한 다양한 이해관계자(고객, 경영진, 현업 담당자 등)로부터 요구사항을 수집하고 식별하는 과정입니다. 마치 고고학자가 유물을 발굴하듯, 이해관계자의 머릿속에 흩어져 있거나 암묵적으로만 존재하는 요구사항을 겉으로 끄집어내는 단계입니다. 많은 경우, 사용자 자신도 무엇을 원하는지 명확히 알지 못하기 때문에 이 단계는 매우 중요하고 또 어렵습니다.

    주요 도출 기법

    • 인터뷰 (Interview): 가장 전통적이고 직접적인 방법입니다. 이해관계자와의 일대일 또는 그룹 대화를 통해 심도 있는 정보를 얻을 수 있습니다. 개방형 질문을 통해 사용자의 숨겨진 ‘Pain Point’를 발견하는 것이 중요합니다.
    • 설문조사 (Surveys): 다수의 사람들에게서 정량적인 데이터를 빠르고 효율적으로 수집할 때 유용합니다.
    • 사용자 관찰 (Observation): 사용자가 실제 업무 환경에서 어떻게 행동하는지 직접 관찰하여, 인터뷰에서는 드러나지 않는 암묵적인 요구사항이나 비효율적인 프로세스를 발견할 수 있습니다. Product Owner나 사용자 조사 담당자에게 매우 효과적인 기법입니다.
    • 프로토타이핑 (Prototyping): 간단한 작동 모델이나 화면 설계를 만들어 사용자에게 직접 보여주고 피드백을 받는 방법입니다. 백 마디 말보다 한 번 보여주는 것이 효과적일 때가 많으며, 사용자가 자신의 요구사항을 구체화하도록 돕습니다.
    • JAD (Joint Application Development): 개발자, 사용자, 분석가 등 주요 이해관계자들이 한자리에 모여 집중적인 워크숍을 통해 요구사항을 정의하고 합의를 이끌어내는 협업 방식입니다.

    예를 들어, ‘온라인 강의 플랫폼’을 개발한다면, 수강생 그룹과는 인터뷰와 설문조사를 통해 학습 편의성에 대한 요구를, 강사 그룹과는 관찰과 JAD를 통해 콘텐츠 관리의 효율성에 대한 요구를 도출할 수 있습니다.

    2단계: 요구사항 분석 (Analysis) – 원석을 보석으로 다듬는 연마

    도출 단계를 통해 수집된 요구사항들은 정제되지 않은 원석과 같습니다. 중복되거나, 서로 충돌하거나, 불명확하고, 기술적으로 구현이 불가능한 내용들이 섞여 있습니다. 요구사항 분석은 이러한 원석들을 다듬어 의미 있는 보석으로 만드는 과정입니다.

    주요 분석 활동

    • 요구사항 분류: 수집된 요구사항을 기준에 따라 분류합니다. 가장 일반적인 분류는 시스템이 ‘무엇을’ 해야 하는지를 정의하는 기능적 요구사항(예: 수강생은 강의를 장바구니에 담을 수 있어야 한다)과, 시스템의 품질이나 제약 조건을 정의하는 비기능적 요구사항(예: 웹사이트는 3초 이내에 로딩되어야 한다, 모든 개인정보는 암호화되어야 한다)으로 나누는 것입니다.
    • 개념 모델링: 요구사항을 그림으로 표현하여 이해를 돕고 구조를 명확히 하는 활동입니다. UML(Unified Modeling Language)의 유스케이스 다이어그램(Use Case Diagram)을 통해 사용자와 시스템 간의 상호작용을 표현하거나, 데이터 흐름도(DFD)를 통해 시스템 내 데이터의 흐름을 분석하는 것이 대표적입니다.
    • 상충 요구사항 해결: 이해관계자 간의 요구사항이 서로 부딪힐 때 이를 중재하고 협상을 통해 우선순위를 정하는 과정입니다. 예를 들어, 경영진은 빠른 출시를 원하지만(Time to Market), 개발팀은 안정성을 위해 충분한 테스트 기간을 요구할 수 있습니다. 이때 Product Owner는 데이터와 비즈니스 목표를 기반으로 합리적인 의사결정을 내려야 합니다.

    분석 단계의 핵심은 ‘왜(Why)?’라는 질문을 던지는 것입니다. “사용자는 왜 이 기능을 원하는가?”, “이 요구사항이 해결하려는 근본적인 문제는 무엇인가?”를 파고들어 요구사항의 본질을 파악하고, 이를 바탕으로 시스템의 범위를 명확히 정의하고 우선순위를 설정해야 합니다.

    3단계: 요구사항 명세 (Specification) – 모두의 언어로 기록하는 약속

    분석을 통해 정제된 요구사항을 이제 모든 사람이 오해 없이 이해할 수 있도록 명확하고 체계적으로 문서화하는 단계가 바로 요구사항 명세입니다. 잘 작성된 요구사항 명세서(SRS, Software Requirements Specification)는 기획자, 개발자, 테스터, 디자이너 모두가 공유하는 ‘단일 진실 공급원(Single Source of Truth)’ 역할을 합니다.

    좋은 요구사항 명세의 조건

    • 명확성 (Unambiguous): 단 하나의 의미로만 해석되어야 합니다. “사용하기 쉬워야 한다”와 같은 모호한 표현 대신 “신규 사용자는 5분 이내의 튜토리얼만으로 핵심 기능을 사용할 수 있어야 한다”처럼 구체적으로 작성해야 합니다.
    • 완전성 (Complete): 시스템이 수행해야 할 모든 기능, 성능, 제약 조건이 누락 없이 포함되어야 합니다.
    • 일관성 (Consistent): 요구사항 간에 서로 모순되는 내용이 없어야 합니다.
    • 검증 가능성 (Verifiable): 요구사항이 충족되었는지 여부를 테스트나 분석을 통해 객관적으로 확인할 수 있어야 합니다.
    • 추적 가능성 (Traceable): 각 요구사항이 어떤 비즈니스 목표에서 비롯되었고, 어떤 설계 및 테스트 케이스와 연결되는지 추적이 가능해야 합니다.

    이전 글에서 다룬 소단위 명세서(Mini-Spec)는 바로 이 명세 단계에서 각 기능의 세부 처리 논리를 아주 상세하게 기술하는 강력한 도구입니다. 명세는 단순히 글을 쓰는 행위가 아니라, 복잡한 시스템의 논리를 설계하고 모두의 합의를 이끌어내는 과정 그 자체입니다.

    4단계: 요구사항 확인 및 검증 (Validation & Verification) – 올바른 길을 가고 있는지 확인하는 나침반

    요구사항 명세서가 완성되었다고 해서 끝이 아닙니다. 이 요구사항들이 정말로 사용자가 원하는 것이 맞는지, 그리고 우리가 제대로 이해하고 기록했는지를 최종적으로 점검해야 합니다. 이 과정을 ‘확인(Validation)’과 ‘검증(Verification)’이라고 부릅니다.

    • 확인 (Validation): “Are we building the right product?” (우리가 올바른 제품을 만들고 있는가?)
      • 이 요구사항이 사용자의 실제 필요와 비즈니스 목표를 제대로 반영하고 있는지를 확인하는 활동입니다. 즉, ‘고객의 관점’에서 요구사항의 타당성을 검토하는 것입니다.
      • 주요 기법: 요구사항 검토 회의(Requirements Review), 프로토타입 사용성 테스트, 사용자 승인 테스트(UAT) 등
    • 검증 (Verification): “Are we building the product right?” (우리가 제품을 올바르게 만들고 있는가?)
      • 요구사항 명세서 자체가 완전하고, 일관적이며, 명확하게 작성되었는지를 확인하는 활동입니다. 즉, ‘문서의 품질’을 검토하는 것입니다.
      • 주요 기법: 동료 검토(Peer Review), 워크스루(Walkthrough), 인스펙션(Inspection) 등

    예를 들어, 완성된 요구사항 명세서를 가지고 주요 이해관계자들과 함께 리뷰 회의를 진행하는 것은 검증(Verification) 활동입니다. 그리고 그 명세서를 기반으로 만든 프로토타입을 실제 사용자에게 보여주고 피드백을 받는 것은 확인(Validation) 활동입니다. 이 두 과정을 통해 우리는 개발에 착수하기 전에 오류를 조기에 발견하고 수정하여 막대한 비용과 시간 낭비를 막을 수 있습니다.

    성공적인 요구사항 관리를 위한 제언: 반복, 그리고 소통

    요구사항 개발 프로세스는 폭포수처럼 한 번에 끝나는 선형적인 과정이 아닙니다. 도출, 분석, 명세, 확인은 프로젝트 전반에 걸쳐 계속해서 반복되는 순환적(Iterative)이고 점진적인(Incremental) 활동입니다. 특히 변화가 잦은 애자일 환경에서는 짧은 주기로 이 사이클을 반복하며 요구사항을 지속적으로 구체화하고 발전시켜 나가야 합니다.

    결국 성공적인 요구사항 개발의 핵심은 ‘소통’입니다. 이해관계자와 끊임없이 대화하여 니즈를 파악하고(도출), 팀 내에서 치열하게 토론하여 최적의 해결책을 찾고(분석), 모두가 이해할 수 있는 언어로 약속을 만들고(명세), 그 약속이 올바른지 함께 점검하는(확인) 과정의 연속입니다. 이 험난하지만 중요한 여정을 성공적으로 이끄는 것이 바로 뛰어난 Product Owner와 PM의 역량일 것입니다.