가상의 온라인 대출 비교 서비스 개발 기획 연습

앞서서 진행하였던 서비스 기획에 따라 진행될 앱 개발 관련 기획 사항을 연습해 보는 시간을 가지려고 합니다. 먼저 앞서 진행한 온라인 대출 비교 서비스 기획을 통해 도출된 어떤 서비스를, 어떤 사용자 그룹에게 제공한다는 것에 맞추어 앱 개발을 작업합니다. 이를 간단한 가정하에 연습해 보겠습니다.

 

 

어떤 앱을 개발할 것인가?

이 질문에 대한 구체적인 내용을 요구사항이라고 합니다. 때로는 요구사항 내용으로 개발할 앱을 특정하기가 어려울 때도 있습니다. 때문에 단순히 요구사항을 전달받는 것이 아닌 추가로 개발에 필요한 사항과 정의를 파악하는 상세화/구체화 작업이 진행됩니다.

 

요구사항은 앱 개발의 성격 상 구체적이어야 하고, 확정적이어야 합니다. 이렇지 않을 경우 앱 개발을 위해 투입되는 인력의 수와 능력이 달라질 수도 있고, 개발 기간이 늘어나게 될 수도 있습니다. 이런 변화는 결과적인 앱 개발을 실패로 이끌게 됩니다. 

 

그러므로 어떤 앱을 개발할 것인지에 대한 정의인 요구사항정리는 앱 개발의 시작으로 중요성을 가집니다. 

 

 

앱 기능 정의 

앞서 서비스 기획을 통해 진행할 대출 비교 서비스 관련 정책, 구조, 기능을 정리했습니다. 여기서 진행된 구조와 기능은 앱을 목표로 한 게 아니라 온라인 서비스를 목표로 한 것입니다. 그러므로 앱 개발에 정확히 들어맞지 않을 수도 있습니다. 하지만 어떤 앱 기능을 구현해야 하는지는 명확히 알려줄 수는 있습니다.

 

일반적으로 앱 기능 정의는 요구 사항의 내용을 토대로 정리합니다. 앞서 서비스 기획 시 작업된 정책, 기능, 구조는 요구사항에서 이미 반영되어 있을 것입니다. 

 

기능 정의는 정해진 방법이나 양식이 있는 것은 아닙니다. 그러나 기본이 되는 것으로 기능 유형과 기능명, 기능번호 그리고 기능에 대한 구체적 설명은 기본적으로 포함되어 있어야 합니다. 여기에 개발을 어떻게 관리/진행시켜 나갈지에 따라 기능 정의서 항목을 추가할 수 있습니다.

 

그리고 반드시 요구사항의 기능 관련 내용이 모두 포함되어 있어야 합니다.

 

온라인 대출 비교 서비스 가상 개발 기능정의서 연습표

 

예시된 위의 표는 가상으로 만들어 본 것입니다. 위의 표처럼 꼭 작업해야 하는 것도 아니고 또 정답인 정리 방식이 있는 것도 아닙니다. 앱 개발 프로젝트 형태나 개발 진행 및 관리 방식에 따라 기능 정의서는 조금씩 다르게 정리할 수 있습니다. 프로젝트 오너인 기업에 따라 관리하는 문서 양식이 따로 있을 수도 있습니다.

 

그러나 약속된 개발 작업 범위와 기간 하에서 원활한 작업을 원하고, 개발 완료 이후 유지/보수와 기능 업그레이드 작업을 위해서는 잘 정리된 기능 정의서가 반드시 필요합니다.    

 

정리하면 어떤 앱을 어떻게 개발할지에 따라, 프로젝트 오너 기업에 따라 기획 문서의 디테일은 달라집니다. 결국 기능정의서는 개발 프로젝트 계약 사항과 요구사항 정리에 따라 문서 내용이 달라지게 되는 것이라 할 수 있습니다.

 

    

IA와 화면 정의

앱 개발 요구 사항과 개발해야 할 기능이 정리되었다면, 사용자가 이용할 앱 화면의 구성을 정리합니다. 이때 사용자 화면과 관리 화면은 구분하여 작업됩니다. 

 

흔히 대출 비교 앱은 사용자 화면을 의미함으로 관리자인 admin 화면과 다릅니다. 그러나 이 둘은 거울의 양면과 같은 것이므로 사용자 앱 없는 관리자, 관리자 없는 사용자 앱은 존재할 수 없습니다.

 

결국 이 두 화면에 대한 내용은 요구사항과 기능 정의에 포함되어야 한다는 것을 의미합니다.

 

이렇게 사용자 또는 관리자 화면의 구성과 내용을 정리한 문서가 IA와 화면정의서입니다. 보통 크게 복잡하지 않은 앱의 경우 화면정의서 없이 IA와 기능정의서를 토대로 작업될 수 있습니다. 그러나 조금 복잡한 앱의 경우 화면정의서를 통해 개발된 화면의 수와 내용을 정리합니다. 때로는 와이어프레임 작업을 통해 화면의 구조와 톤 앤 매너를 규정할 수 있습니다.

 

온라인 대출 비교 서비스 가상 개발 화면정의서 연습표

 

화면 정의서의 왼쪽의 depth는 메뉴 구조를 의미합니다. 즉 화면 정의서는 실제 앱 또는 관리자의 화면 구조와 내용을 정리한 문서라 할 수 있습니다. 이점에서 스토리보드와 강하게 연결됩니다. 어떻게 보면 화면정의서를 시각적 문서로 만든 것이 스토리보드이고, 이를 디자인한 것이 앱 화면 디자인 파일인 것이라 할 수도 있는 것입니다.

 

 

스토리보드

일반적으로 이용의 흐름에 따라 정리한 문서를 스토리보드라 합니다. 사용자가 이용인 경우, 관리자가 이용자인 경우 사용자 스토리보드, 관리자 스토리보드로 구분될 수 있는 것입니다.

 

이러한 스토리보드는 작성 시점이 이용을 따라가므로 화면 설계의 형식을 취합니다. 그래서 잘못하면 어떤 기능을 어떻게 개발하고, 어떤 조건에서 다른 작동 방식을 취하는지 스토리보드에 나타나지 않을 수 있습니다. 단지 화면을 보여주는 형식의 문서가 될 수 있는 것입니다. 이런 경우 디자인은 가능하지만 화면 개발은 어려울 수 있습니다.

 

그리고 화면의 작동은 서버 사이드 개발, 데이터와도 연결되어야 가능합니다. 이 때문에 스토리보드가 개발 문서로 의미가 있기 위해서는 화면에 대한 설명뿐 아니라 기능 작동에 대한 설명도 포함되어 있어야 합니다. 

 

그러므로 스토리보드는 기능정의서와 화면정의서를 바탕으로 작업되어야 하는 것입니다.

 

가장 기본적인 앱 스토리보드의 구성은 회원 가입과 로그인/아웃, 메인, 대출 비교 서비스, 이벤트/안내, 마이페이지, 고객 센터 등으로 구분하여 이용 흐름을 정리하는 것입니다.    

   

스토리보드 작성 양식도 프로젝트에 따라 달라질 수 있습니다. 그러나 반드시 현재 보고 있는 스토리보드의 화면이 어느 위치이고 어떤 화면인지를 알 수 있어야 합니다. 그래서 스토리보드는 맨 위해 화면번호와 경로를 꼭 표시합니다.

 

이번 글에서는 대출 비교 앱 개발에 대한 사례를 통해 전반적인 개발 기획 작업에 대해 알아보았습니다. 다음에는 몇 가지 개발 가정을 통해 각 개발 문서가 어떻게 작성되는지 좀 더 집중적으로 살펴보도록 하겠습니다.