화면 정의서와 기능 정의서 차이 구분

앱이나 웹 기획 시 중심이 되는 문서는 화면 정의서와 기능 정의서라 할 수 있습니다. 이 두 문서는 요구 사항의 내용을 개발과 연결하며, 스토리보드 작성의 내용이 됩니다. 하지만 중요성에 비해 구분 없이 작업되거나, 심지어 작성 없이 바로 스토리보드로 넘어가는 일도 종종 있습니다.

 

 

화면 정의서와 기능 정의서 작성 이유

화면 정의서, 기능 정의서를 작성하는 이유는 문서의 이름에 이미 나와 있기는 합니다. 화면 정의서는 앱/웹 화면 개발을 위해, 기능 정의서는 앱/웹의 기능 개발을 위해 작성됩니다.

 

화면 개발과 기능 개발이라 같이 개발의 단어를 품고 있지만 화면 정의서는 디자인과 UI 등 디자인적 내용이 다수 포함되어 있는 반면, 기능 정의서는 대부분이 프로그래밍에 관한 내용으로 작성됩니다.

 

이 때문에 화면 정의서와 기능 정의서 없이 바로 스토리보드를 작성하는 경우 사용자 관점의 앱/웹 화면을 설명하는 문서로 흐르기 쉽습니다.

 

이 경우 코딩이 어려워질 수 있다는 문제의 소지가 있습니다. 물론 개발자(프로그래머)와 기획자가 스토리보드 내용을 가지고 잦은 대화와 토론을 통해 문제를 최소화할 수도 있습니다. 그러나 이 경우도 화면 중심 스토리보드를 작성하였다는 사실만으로도 기획자가 개발(코딩) 관련 지식이 부족하고, 프로그래머와 협업에 익숙하지 않기 않기 때문일 가능성이 크기 때문에 애초에 잦은 대화와 토론이 원활하지 않을 가능성이 매우 큽니다. 물론 반대의 경우인  기획자가 코딩에 대해서는 잘 알고 있으나 디자인과 UI에 대해서는 부족한 경우 앱/웹 개발에 투입된 디자이너와 협업이 어려울 수 있습니다. 

 

기획 경력이나 역량이 다소 부족하기에 화면 정의서와 기능 정의서를 구분하거나 작성하지 못할 수도 있습니다. 이 경우도 스토리보드의 내용은 어느 한쪽에 치우 칠 수 있게 됩니다.   

 

이렇게 치우친 스토리보드를 방지하고 앱/웹 개발에 적절한 스토리보드를 만들기 위해서 화면 정의서와 기능 정의서는 필요합니다.

 

프로젝트의 특성에 따라서는 기능 정의서, 화면 정의서 없이 바로 요구 사항에서 스토리보드 작업으로 진행할 수도 있습니다. 이때에는 요구 사항의 정리가 상당히 구체적이어야 합니다. 그러나 개발 규모가 크거나 다양한 기능, 많은 사용자 이용 페이지를 개발해야 하는 경우 화면 정의서, 기능 정의서가 없는 경우 양은 많으나 무언가 내용이 연결이 안 되고, 개발자의 질문이 많은 스토리보드가 될 가능성이 큽니다. 고객이나 의사 결정자가 산출물로 평가하는 스토리보드와 별개로 개발용 스토리보드로는 그 양에 비해 질적인 부분이 다소 떨어질 수 있는 위험이 있다는 것입니다.

 

 

화면 정의서와 기능 정의서 예

상품 상세 페이지를 정의하는 문서를 작성한다고 가정합니다. 이때 작성되는 화면 정의서와 기능 정의서의 예를 간단히 살펴보겠습니다.

 

상품의 상세 페이지는 메인 상품 이미자와 상품명, 혜택, 가격 등이 표시되고 구매와 장바구니, 찜으로 구성된다고 가정합니다. 그리고 그 아래에 상품에 대한 설명을 넣을 수 있는 공간이 제공됩니다. 설명은 이미지와 텍스트로 작성될 수 있습니다.

 

 

상품 상세 페이지 화면 정의서 예

화면 정의서는 이러한 화면 구조를 설명하고 각 컴포넌트와 배치에 대해 표시합니다. 만약 상품에 따라 반드시 표시해야 하는 개별적 요소가 존재한다면 이에 대한 표시도 합니다. 만약 상품 등록 후 화면까지 개발에 포함되어 있다면 상품이 등록되었을 때 사용자가 보게 되는 상품 상세 화면에 디자인 정의를 포함할 수도 있습니다.

 

상품 상세 페이지 화면 정의서의 내용은 계약에 의해 정의된 개발을 통해 사용자에게 보일 부분에 대한 내용이 정리되어야 합니다. 상품 페이지 생성 기능만 제공하고 이를 통해 상세 페이지를 만드는 것은 관리자의 역할이라 계약하는 경우와 사용자가 실제 이용하게 될 상품 상세 페이지 모두를 개발한다고 계약하는 경우 화면 정의의 내용이 달라지는 것입니다.

 

 

상품 상세 페이지 기능 정의서 예

기능 정의서의 경우는 메인 상품 이미자와 상품명, 혜택, 가격 등이 표시되고 구매와 장바구니, 찜 아래에 이어지는 상품 설명 내용의 구성이 그리 간단하지 않을 수 있습니다.   

 

상품 페이지는 간단히 상품명만 넣고 생성이 되는 독립적 생성 형태가 될 수도 있습니다. 하지만 카테고리 구분 후 하위로 생성되는 방식, 행사나 이벤트와 연결하는 방식 등으로 구성될 수 있습니다. 이런 상품 페이지 방식에 따라 데이터 관리와 앱/웹 화면에 노출되는 상품 상페 페이지의 위치가 달라질 수 있습니다.

 

상품 가격 개발의 경우도 기본 상품 가격, 할인 등록, 쿠폰 할인, 포인트 할인 등의 기능 적용 시 처리 방식에 대한 부분을 고려해야 합니다.

 

예를 들어 사용자가 여러 상품을 구매 후 일부 상품을 구매 취소했을 때 할인 또는 쿠폰, 포인트 처리에 따라 개발되어야 하는 범위나 난이도가 크게 달라질 수 있습니다.

 

이러한 부분은 단지 지정하여 입력하는 상품 판매 가격에 대한 내용이 아니라 앱/웹의 가격 정책 전반에 관한 사항의 기능 개발입니다.

 

또한 상품에 따라 옵션에 대한 부부이 있을 수 있습니다. 예를 들어 패션 상품의 경우 같은 옷이라도 사용자는 구매 시 자신의 사이즈의 옷을 골라야 할 수 있습니다.

 

또한 세트로  판매 등록되는 상품도 있을 수 있습니다. 이 경우 상품의 가격과 구성은 이 세트를 하나의 상품으로 등록하는 방식과 이미 등록된 각 상품을 불러와서 세트 상품으로 추가 생성하는 방식을 고려할 수도 있습니다. 전자는 앱/웹 화면에서는 세트 카테고리를 생성하여 노출될 수 있습니다. 후자의 경우는 독립된 세트 상품 카테고리 외에 각 상품 카테고리 하위에 세트가 생성되고 노출되는 방식과, 각 상품 페이지 하단에 세트 상품으로 노출되는 방식을 고려할 수 있습니다.

 

결제의 경우도 결제 버튼의 위치나 모양, 결제 클릭 시 넘어가는 화면의 구성과 내용이 화면 정의서 또는 화면 중심 스토리보드의 주된 내용이라면, 결제 클릭 시 서버에서 처리되어야 하는 내용과 화면이 넘어갈 때 처리되어야 하는 정보의 내용의 정의가 기능 정의 및 기능 설명 스토리보드의 내용입니다.

 

보통 결제는 PG사를 통해 이루어집니다. 만약 과거처럼 기존 PG사 결제 모듈 이외에 새로운 간편 결제가 추가되어야 하는 상황이 되었다면 이에 대한 정의도 표시해 놓아야 이후 유지/보수가 용이해집니다. 이러한 새로운 외부 모듈 적용에 대한 프로세스와 관련한 내용은 사용자 화면 이용 측면에서는 나타나는 내용은 아닙니다.

 

사용자는 결제 클릭 수 카드 결제 또는 간편 결제를 선택하고 나오는 화면에 대해 결제를 진행하면 됩니다. 그러나 이 화면은 앱/웹 화면일 수도 있고, 결제사의 화면일 수도 있습니다. 만약 결제사로 이동해서 처리되는 화면이라면 화면 정의서의 내용에는 결제사 화면 이동만 표시합니다. 개발되어야 할 화면이 아니기 때문입니다. 그러나 기능 정의서는 연동 API 처리 내용이 표시되어야 합니다. 물론 이 내용은 기획자가 단독으로 작성하는 것은 아닙니다.

 

기획자는 연동 부분을 처리하고 결제사 API 문서에 따른 내용을 표시하는 수준일 것입니다.. 실제 작업 내용은 개발자가 결제사 개발자와 협업을 통해 작성합니다. 그러나 스토리보드에는 이 내용이 표시되어 있어야 합니다. 그리고 기능 정의서에는 내용이 표시되어 있고 하위 설계 문서 번호 또한 지정되어 있어야 합니다. 그래야 스토리보드 만으로는 확인할 수 없는 기능 개발에 대한 상세 내용을 파악할 수 있게 됩니다.     

  

솔직히 이런 내용은 개발 프로젝트에서 개발자와 디자이너와 협업을 몇 번만 해 보아도 자연스럽게 알게 되는 내용이기는 합니다. 그러나 이를 어떻게 정리하고, 각 개발자(프로그래머와 디자이너, 퍼블리셔 등)와 어떻게 협업해 나갈지는 기획자의 역량과 노련함의 차이라 할 수 있을 것 같습니다.