화면 설계가 작동되는 앱 기획이 되기 위한 조건

앱(스마트폰 앱, 웹 사이트 등) 개발 시 화면 설계가 진행됩니다. 그런데 때로는 화면설계로는 화면 개발과 서버 개발을 진행하지 못하는 일이 발생하기도 합니다. 분명 보기에는 완벽한 것 같은 화면설계서가 개발로 이어지지 못하는 것은 작동되는 앱을 위한 조건을 담고 있지 못하기 때문입니다.

 

 

 

화면 설계를 하는 이유와 앱 개발 요소와 관계

 

모든 앱(스마트폰 앱, 웹 사이트 같은 애플리케이션)의 화면 설계는 기본적으로 작동을 기준으로 해야 합니다. 아무리 월등한 앱 UI라도 작동하지 않으면 의미가 없습니다. 사용자가 이용할 수 없기 때문입니다.

 

그렇기 때문에 간단히 앱 화면 설계의 위치와 앱 개발의 니즈를 구성하는 요소들과의 관계를 정리해 보면 아래 그림과 같습니다. 화면 설계를 하는 이유를 사용자의 이용 즉, 작동이 된다는 것을 기본으로 하는 입장의 그림입니다. 여기에는 앞선 UI나 디자인 등은 감안하지 않은 도식입니다. 일단 이러한 UI나 디자인은 작동을 가정하에 의미를 가지기 때문입니다.

 

앱 작동의 기본 모형

   

 

위 그림을 통해 보면 화면 설계를 하는 이유는 앱 사용자가 이용하게 만들기 위해서입니다. 더 편리하고 트렌디한 UI가 필요한 것은 앱을 이용하는 사용자가 그 앱을 더 익숙하고 편리하게 쓸 수 있기 때문입니다.

 

그러므로 앱(여기서 앱은 웹도 포한한 개념입니다) 화면 설계는 사용자 지향적으로 작업됩니다.

 

이렇게 2000년 인터넷 벤처 열풍 이후 20년 넘게 진행된 앱 화면 설계 작업은 어느 정도 공정 표준화 및 방법론이 구축될 수 있게 되었습니다.

 

바로 이 지점에서 점점 문제가 생기게 되었습니다.

 

초기 앱 화면 설계를 진행했던 기획자는 당연히 전체 앱 시스템에서 화면을 설계하였습니다. 그러나 화면 설계 공정 표준화와 방법론이 체계화된 이후 기획자는 화면이 전체 앱 개발 공정에서의 한 부분이 아니라, 그냥 앱 화면 설계만 반복 작업하게 된 것입니다.

 

개발 시스템이 분업화되고 표준화되고 시간이 일정 이상 흐르게 되면 발생하는 문제가 앱 개발 분야에도 나타나기 시작한 것입니다.

 

  

 

앱 개발에서 화면 설계의 위치

 

앱 화면 설계만 독립적으로 때어 놓고 작업하다 보면 이상한 일이 발생합니다. 지금 개발되고 있는 앱 시스템과 연동되어 작동되는 앱 화면이 아닌 연관성이 없는 화면이 설계되는 것입니다.

 

분명 지금 진행되고 있는 앱 개발 프로젝트에 투입된 화면 설계 작업인데, 앱 개발 단위 공정과 연결되지 않는 설계가 진행되는 것입니다. 심한 경우 다른 개발 작업에 대한 배타성까지 보이는 화면이 설계되고 있는 경우도 생기게 됩니다.

 

여기서 문제는 화면이 개발될 수 없다는 것이 아닙니다. 서버와 연동하여 작동하는 앱 화면이 설계되지 않는다는 점입니다.

 

 

 

조회 화면의 예 

.

만약 사용자가 구매한 상품을 조회한다고 가정합니다. 

 

이 케이스에서 사용자가 만족할 만한 조회가 이루어지기 위해서는 몇 가지 조건이 필요합니다. 이는 조회 UI 컴포넌트 구성과는 다른 것입니다.

 

그냥 상품 조회를 하면 너무 많은 상품이 나올 것입니다. 그래서 많은 앱/웹 서비스들이 기본적으로 카테고리 선택 항목을 제공합니다. 조회에는 앱 카테고리를 선택할 수 있는 선택 메뉴를 제공합니다. 문제는 이 선택 카테고리 메뉴에 나타나야 할 데이터일 것입니다.

 

이 화면에서 선택 가능한 상품 카테고리는 서버에서 받아와야 합니다.

 

이러한 이유로 화면 설계에 사용자 이용의 의미를 가지려면, 작동되려면 기본적으로 서버에서의 해당 UI와 연동되는 데이터에 대해 정의되어야 합니다.

 

앱이 작동되기 위해 반드시 필요한 이 정의는 누가 해야 할까요?

    

개발자는 기획자가 해야 한다고 생각할 것입니다. 그런데 기획자는 화면 설계자입니다. 그러면 기획자는 개발자가 해야 한다고 생각할 것입니다.

 

이 상태는 앱 시스템에서 필요한 프로세스 설계 담당자가 빠져 있는 것이 되고, 결국 앱 개발 진행 시 계속 문제로 등장하게 됩니다.

 

    

 

화면 설계 앱 기획의 조건 - 작동을 위한 프로젝트 관리 기준

 

일반적으로 어떤 개발 프로젝트가 진행되면 개발을 구성하는 기술적 요소와 이를 담당할 인력 구성을 매칭합니다.

 

앱 개발을 구성하는 기술 요소는 시스템 설계를 통해 도출합니다. 이 설계를 통해 담당 인력이 다시 도출되고 이를 정리한 것을 프로젝트 R&R이라 합니다. 

 

문제는 사용자가 이용할 앱과 가까운 거리의 기술은 비교적 쉽게 규정할 수 있지만, 좀 떨어져 있는 것은 규정하기 다소 어려운 점이 있습니다.

 

그래서 이런 사용자가 이용할 앱의 모습을 개발하는 가까운 거리의 기술은 비교적 쉽게 복제/모방할 수 있지만, 좀 떨어져 있는 설계 같은 요소는 쉽게 복제/모방할 수 없는 것입니다.

 

바로 쉽게 복제/모방할 수 없다는 지점이 개발 프로젝트의 구멍이 생기게 되는 것입니다.

 

 

 

UI 작동을 위한 설계 조건

 

바로 앞서 화면 UI에서 불러오는 데이터를 어떻게 지정할 것인가에 대한 부분입니다.   

 

사용자가 개발된 앱을 이용하기 위해서는 편리한 UI도 적용되어 있어야 하지만, 그 UI가 작동되어야 합니다. 그리고 편리한 기능적 요소도 포함되어 있어야 합니다.

 

이를 위해서는 앱 시스템에서 어떻게 상품이 등록/관리되는지 정의되어야 합니다. 이러한 요소는 앱 정책과 전략과 연결되어 있는 요소입니다.

 

• 앱 정책과 전략과 연결 UI 설계 조건

 

상품 등록 시 카테고리를 세분화하여 입력하면 좋지만, 상품이 거의 없는 카테고리가 많이 존재한다면 앱을 이용하는 사용자 입장에서 편리성이 감소될 것입니다. 심지어 오히려 불편해질 수도 있습니다.

 

그렇다면 카테고리는 현재 앱의 운영 상품 상태에 따라 달라질 수 있음으로 의미합니다. 또 1년 후 카테고리와 지금 카테고리가 달라질 수 있음을 의미합니다.

 

이를 기획자는 다양한 설계 기법 중에 적절한 방법을 선택하여 작업하게 됩니다. 

 

일단 대 카테고리, 중 카테고리, 소 카테고리를 미리 계획하고 설계할 수 있습니다. 이는 기본적으로 앱 성장 전략과 방향에 대한 계획이 있어야 합니다.

 

아니면 개발 시 특정 상품의 카테고리를 플렉시블(유연하게) 변경할 수 있도록 적용할 수도 있습니다. 이는 데이터나 개발 전략과 방향에 대한 계획이 있어야 합니다.

 

이러한 설계가 없는 앱의 경우 당장 지금 개발된 앱의 경우 운영에 문제가 없을 수 있습니다. 그러나 이후 버전 2의 앱이 개발될 경우 지금 개발되어 운영된 앱의 데이터와 연동이 되지 않게 될 수도 있습니다.

(이 상황은 실제 제가 개발 프로젝트에서 경험한 것입니다)

 

다른 하나는 개발 환경과 관련 있는 UI 종속성에 대한 설계입니다.

 

• 앱 비즈니스 구현 개발 방식과 연결  UI 설계 조건 (UI 종속)  

 

만약 앱 개발이 상품의 등록과 관리(판매, 배송, 재고 등)의 편의성을 위해 특정 설루션 기반으로 진행된다고 가정합니다.

 

이 설루션이 제공하는 UI 제약 요소는 화면 설계에 많은 부분에 영향을 미치게 됩니다. 이런 상황으로 어쩔 수 없이 화면 설계는 해당 설루션 기반으로 진행됩니다.

 

이때 설계는 앱 작동 속도를 위해 해당 설루션의 모든 요소를 체크/확인하여 작동되는 것이 아닌 필요한 요소만 체크하여 작동돼야 하는 것을 정의해야 할 수 있습니다.

 

보통 이 또한 개발 설루션과 앱 비즈니스 정책을 분석하여 정의합니다. 이러한 과정을 도식화한 것을 프로세스 설계라고 부르기도 합니다.

 

이외에도 화면 설계를 위해 미리 정의되어야 하는 여러 기획(분석/설계) 요소가 존재할 수 있습니다. 이러한 것은 각각의 프로젝트 상황에 따라 기획하면 됩니다.

 

문제는 이러한 분석/설계의 경우 화면 설계 공정을 표준화하기 불가능하다는 점입니다. 

 

그래서 표준 화면 설계 공정에 의한 앱 개발이 복잡하거나, 다른 시스템과 다른 개발 요소가 있다면 작동되는 화면 개발에 실패하는 일이 종종 발생하게 되는 것입니다.