[05일차 스터디] 앱과 웹의 서비스 구조 / 폭포수 방법론 (패스트 캠프 '서비스 기획서 완성')

 

06. 온라인 서비스의 구조의 이해 

 

어떤 식으로 형성이 되어 있는지 

IT 나 개발을 해본 사람의 경우 쉽게 느껴질 수 있다. ㅎㅎ

 

 

온라인 서비스 구조 

(웹기준)

 

출처: 강의자료 02-41

 

• 이용자 

- PC / 모바일 / IoT (스마트 스피커, TV)

네트워크를 통해 개발된 것은 비슷한 형태 

 

 

• 네트워크 - 와이파이, LTE 등

 

네트워크 상 어딘가에 있는 서비스를 디바이스에 불러온다. 

 

호출을 하게 되면 

• 웹 서버 / DNS 서버 

DNS Server (Domain Nam System)

: 도메인 이름(예: www.amazon.com)을 머신이 읽을 수 있는 IP 주소(예: 192.0.2.44)로 변환 

 

※ 참고

aws.amazon.com/ko/route53/what-is-dns/

DNS란 무엇입니까? – DNS 소개 - AWS

 

• 웹 화면 

- 실제로는 코딩으로 이루어져 있다. 

 

• DB 서버 

 

기획자의 관점으로 본다면, 

기획을 하는 부분은 온라인 서비스라는 것은 데이터의 입력과 출력을 만들어주는 것이고 

기획할 때 데이터에 대한 부분을 염두해 두어야 한다. 

 

 

기획 템플릿 

 

함수?

어떤 X 값을 넣으면 수식을 통해 Y 가 되어서 나온다. 

=> 기획은 화면상에 룰을 만들어 주는 것이다. 

 

템플릿 

: 각 페이지 단위로 룰을 정해놓은 것 

 

EX

네이버 같은 웹에 화면에 이미지 배너가 등장한다. 

이게 나오는 것은 누군가가 세팅을 해놓은 것인데, 몇시부터 몇시까지 이 화면을 노출하게 해주세요 라고 

룰을 정하게 된다. 

=> 화면의 구성요소 하나하나 정의 보단, 어떤한 룰을 가지고 어떠한 컨텐츠를 노출시켜주세요 라고, 

사용자에 따라 이러한 데이터를 보게 해주세요 라고 룰을 정하는것, 

이를 템플릿이라고 하고 기획자가 화면 구성을 정의를 한다. 

 

만약, 

룰 정의 없이 하면 하드코딩을 해야한다. 

대부분 룰에 의해 움직이는 템플릿이다! 

룰에 대해 생각하는 것이 중요하다. 

 

 

서비스 레벨과 화면 레벨의 구분 

 

화면 레벨을 프로덕트 라고 하기도 한다. 

 

EX. 이커머스 

1. 판매 상품 Admin 등록 

(이를 위해 필요한 화면 단위 )

2. 상품 전시 

3. 주문하기 

 

 

※ 화면 템플릿 예시 

 

혼자서 템플릿 찾아보는 방식 (강사님이 분석하는 방식)

 

주소를 보면, 도메인이 뉴스를 치고 나온 url

파일의 위치를 호출하게 되는데, ? 하고 일렬 번호가 나와 있다. 

템플릿은 하나이고 어떠한 데이터를 불러오느냐에 따라 노출되는 데이터가 다른 것이다. 

어떤 DB를 불러올 것인지! 

 

네이버 블로그 주소와 브런치 주소 

각 아이디 별로 화면의 템플릿을 가져다가 이 데이터를 뿌려주는구낭~ 이라고 알아볼 수 있다. 

 

화면 템플릿은 몇개고 어디까지 템플릿인지 확인해볼 수 있다 

 

 

정리 

입력과 출력 과정에서 템플릿, 어떠한 룰을 구축하는지 중요하고 이를 기획하는 것이다. 

 

 

07. 앱, 웹 또는 서비스 구조에 대한 이해 -1, -2 

 

대표적으로 온라인 서비스는 앱과 웹이 있고 

실질적으로 모바일 폰에서 이용되는 서비스가 가장 쉽게 접할 수 있다. 

 

 

앱과 웹의 차이 

사용적인 특징  

 

구분	PC 웹	모바일 웹	네이티브 앱
기본 인터렉션 도구	마우스  (키보드도 있지만 안쓰는 경우도 있다. ) 일부 웹에서 지문을 사용하는 경우도 있다.	손가락 터치	손가락 터치  (앱으로 사용할 때 인터렉션 도구를 훨씬 더 많이 많이 사용한다.) 다양한 센서 - 자이로스코프 센서, GPS, 홍채 인식 등
인터렉션의 종류	마우스에서 할 수 있는 것이 다이다.  클릭, 커서, 휠 사용하는 인터렉션,	제스쳐  - 탭, 더블탭, 프레스, 스와이프, 드래그, 로테이트  - 그러나 웹에서는 마니 사용하지 않다. 보통 탭, 더블탭, 핀치 이정도만	제스쳐  - 탭, 더블탭, 프레스, 스와이프, 드래그, 로테이트  부드럽게 다양한 인터렉션이 있다.
데이터 로딩 단위  - 화면을 불러올 때, 시점이 필요한다.	페이지가 이동될 때 데이터를 불러온다.  AJAX 를 통해서 탭을 누를 때 특정한 액션을 취할때 부분적으로만 데이터를 불러온다.  - 한 페이지가 유기적으로 연결되어있는 형태라고 볼 수 있다.	PC 웹과 동일하다.	모듈 단위 로딩  보이는 영역이 쪼개져 있다.  하나의 화면에 여러가지의 구성요로 데이터를 불러온다.
화면 구성 형태	고객은 F자의 형태로 고객의 시선이 간다.	모바일의 경우는 I 자의 형태로 시선이 많이 간다.  컨텐츠 분할 로딩을 할 수 있다.

 

 

웹 

 

• 반응형 웹 

화면의 가로 크기에 따라 계속 다른 UI 형태로 보여주는 퍼블리싱 형태 

 - 개발 산출물은 줄어들지만 기획은 다 해야한다. 

 

• 적응형 웹 

모든 가로크기에 대응하려다 보니깐 중간의 애매한 사이즈에 놓였을 때 깨져보일 수 있다. 

기준 이상 이하로만 나누어서 2~3단계로만 기획을 해놓는 방식 

 

• Landscape, Portrait  

가로, 세로로 돌렸을 때 

 

 

APP

 

• 웹앱 

그냥 웹인데 브라우저가 앱이다. 

이를 제외하면 아래 종류이다.

 

 

• 하이브리드 앱 

앱안에브라우저를 넣을 수 있는데 웹뷰 라고 한다. 

- 장점 

 > 변경사항을 데이터 서버에만 올리면 된다. 그러면 변경된 서비스를 제공할 수 있다. 

 / 앱을 업데이트를 해야한다. 

 그래서 일부 변경이 찾은 페이지는 웹으로 만드는 경우가 있다. 

 > 앱에서 쓸 수 있는 플러그인들 

  API 까지 다 쓸 수 있다.

웹 서비스를 그래도 가지고 와서 앱의 장점도 쓸수 있다. 

 

• 네이티브 앱 

인터렉션 부분에서 많이 사용할 수 있기 때문에 많이 사용된다. 

 

개발 방식과 언어가 다르다. 

서비스에 따라서 기획, 개발 방식을 고려해야한다. 

ex. 은행같은 경우는 보안이 중요하기 때문에 앱으로 진행되는 경우가 많다.

 

 

 

| 프로젝트에서의 기획자의 순서와 역할 

 

01. 프로젝트와 산출물 (폭포수)

 

산출물도 있어야 하고 커뮤니케이션 역량도 있어야하고

프로젝트 전체에 대한 이해도 있어야한다. 

 

프로젝트 방법론 

- 폭포수 (워터풀)

- 애자일 방법론 

 

커뮤니케이션 해야하는 협업 대상자들은 누구인지 

이후에 산출물, 작성법 등 강의 진행할 것이다. 

 

실제 업무와 밀접한 내용을 다루게 된다. 

 

 

프로젝트 방법론 

: 프로젝트를 어떻게, 어떤 순서로 나갈 것인지 

 

 

폭포수 방법론 

1950년대 만들어진 개념 / 전통적인 

건설에서 영향을 받아서 

 

소프트웨어 개발 하는데 표준 방법 

 

출처: 강의자료 03-02

 

폭포수가 백은 없듯이 

단게별로 넘어가지는 방법론 

 

아이디어 > 기획: 스케치, 와이어 프레인 > 구체화 >  코딩 > 개발 테스트 / 서비스 피드백 

 > [현대 폭포수는] 기획으로 다시 빽 해서 수정 단계 진행 

 

 

핵심!

업무자가 흘러가면서 기획 - 디자인 - 개발자 - QA 테스트 - 오픈  

일정관리에 용이한 부분이 있다. 

 

 

장점 

- 단계가 명확하다. 

 진척률이 몇프로인지 확인할 수 있다. 

- 책임 소재 명확하다. 

- 앞에서 기획하고 나면 요구사항을 가지고 진행되기 때문에 인력의 산출물이 명확해진다. 

 Push 를 잘하는 경우 일정을 잘 맞출 수 있다. 

 국내는 외주 기반이 많아서 Push를 잘해서 폭포수 쓴느 경우가 많다. 

- 산출물 문서가 명확하다. 

 따라서 관리가 용이하다. 

- 외부 인력과 작업하기 할때 용이하다. 

 

단점 

- 앞 단계에서 기획이 잘못 되면 다음 단계는 중간에 되돌리면 설계부터 다 틀어야한다. 

 프로젝트가 산으로 가면 중간에 파악할 수 있는 시점이 없다. 

- 앞단계 문서에 명시되지 않으면 누락될 수 있다. 

 기획자에게 오는 부담이 커진다. 문서 요구사항에서 다 파악하고 정의를 해줘야한다. 

- 테스트 전까지 산출물 형태를 알 수가 없다. 

 

 

기획자의 산출물 

(인하우스 기준/ 운영되고 있는 서비스 기준 )

출처: 패스트캠퍼스 강의자료 03-04 / 빨간색=산출물

 

• 아이데이션 

- UX

- 무엇을 개선할지 의논 

 

 

• 기획안 작성 

- RFP(Request for proposal) (외주경우)

 = 제안 요청서 

 : 발주자가 특정 과제의 수행에 필요한 요구사항을 체계적으로 정리하여 제시함으로써 제안자가 제안서를 작성하는데 도움을 주기 위한 문서

요구사항 - 위키백과, 우리 모두의 백과사전

- 사용자, 데이터 조사 

 행동데이터, 결제 비율 등 

- 전체 프로세스 분석 

 서비스가 들어갈려면 기존 시스템 흐름을 파악해야한다. 

- 정책서 

 룰 / 데이터, 법적으로 

- 서비스 전략 기획

 고객한테 사용자에게 어떻게 보여줄 것인지 

어떤 UI, 내용, 흐름으로 갈 것인지 정의 

- 요구사항 정의서 

 개발자와 협의하는 내용 부분 

- IA 

 과거는 페이지 구조 정리로 이용했다면 

 최그는 화면 갯수를 세는 용도로 사용한다. 

- 스토리보드 => 폭포수의 핵심 산출물 

 화면설게서는 기획의 모든 내용을 다 담고 있어야 하고 

개발자가 봤을 때 템플릿, 화면이 가지고 있는 모든 룰, 규칙, 케이스 등을 다 담고 있는 문서이다.

끝까지 챙겨야하는 SB 이다. 

 

• 협업 

구현가능한 스펙으로 정리 및 개선 

- 디자인 

 > UI 정리 

 > 프로토타입 만들 수도 있고 

- 프론트 엔드 개발 (퍼블리싱 개발 ) 

- 백엔드 개발  

 

• 테스트 

- 테스트 케이스 

 종류 > 단위테스트 (기능) / 통합 테스트  시나리오 베이스 서비스 전체 흐름 

베타 테스트 : 게임의 경우 많이 진행 

 

• 오픈 

- 교육, 메뉴얼 작성 (운영 가이드) 

 

 

기획자의 역할이 변화되는 포인트 

1. 창의적인 부분 

2. 현식적인 => 스토리보드 

3. 제대로 원하는 것을 만들어 낼 수 있도록 리뷰, 회의, 설득 

 => 수용하는 과정 / 커뮤니케이션 

4. 테스트를 통해 퀄리티를 챙기는 과정 

 

 

폭포수 관련 QA 

 

Q) 폭포수를 배우는 것은 촌스럽다?

A) 애자일 방법론은 긴 시간동안 폭포수 방법론의 단점을 보완하기 위해 나온 것. 

 애자일을 이해하기 위해 필수적인 요소 

 

Q) 느리다?

A) Push 를 잘하는 기업에서는 오히려 더 빠를 수 있다. 

 출시 기간이 명확하게 중요하면 폭포수를 통해서 맞추는 것이 좋을 수 있고, 

 높은 완성도가 더 중요하면 애자일이 더 좋을 수 있다. 

 즉, 단기간에 동일한 산출물을 만든다고 하면 폭포수가 더 빠를 수 있다. 

 

프로젝트 성격에 따라서 픽! 

그리고 부분적으로 나누어 사용하는 경우도 있다. 

 

 

전통적인 프로젝트 방식이며 

아직 많이 사용된다. 

 

 

 

-----

패스트 캠퍼스 

'서비스 기획서 완성 온라인 완주반' 

스터디 내용 정리