반응형

 

모바일 서비스를 위한 앱 개발 과정

 

네이티브 앱

  • 하나의 운영체제에서만 동작.
  • 모든 운영체제에서 동작하게 하려면 각 운영체제에 맞는 언어로 각각 개발해야만 함.
  • 그래서 모든 사용자를 고려하면 개발 리소스 2배 이상 늘어남
  • 사용자가 직접 다운로드해야 하기 때문에 실시간 업데이트가 쉽지 않음.
  • + 각 운영체제에서 제공하는 강력한 기능을 활용 가능
  • + 높은 사양의 그래픽을 구현할 수 있고 빠른 속도!
  • 초기 스마트폰 시장 때도, 지금도, 가장 대중적인 모바일 개발 형식.
  • + 사용자 기기에 저장된 사진, 카메라, 캘린더, 주소록에 접근 권한을 가질 수 있다 (가장 큰 장점)
  • ⬆️ 이러한 특징으로 고성능 게임이나 카메라, GPS 등 센서를 활용한 앱 제작에 많이 활용

모바일 웹앱

  • 사파리나 크롬 같은 인터넷 브라우저에 실행되는 웹사이트.
  • 유저가 스토어에서 앱을 다운로드 하지 않아도 브라우저에 접속하면 연결되기 때문에 실시간으로 업데이트 가능
  • 애플의 앱스토어나 구글의 플레이 스토어 같은 플랫폼을 거치지 않기 때문에 유지 보수에 유리
  • HTML5 같은 표준 웹 언어로 만들어 개발 기간도 네이티브 앱에 비해 빠른 편
HTML5 (Hyper Text Markup Language)
웹 표준 기관인 W3C가 만든 웹 언어 규격. 웹 문서 작성에 반드시 필요한 마크업 언어.
  • (-) 웹앱은 웹 기반 → 모바일 기기에 최적화되어 있지 않기 때문에 네이티브 앱에 비해 속도 SLOW 성능도 떨어짐.
요즘은 비용이 드는 네이티브 앱 개발을  웹앱으로 유저 확보 후에 하는 서비스가 많음. 접근성이 (스토어에서 새로운 앱 설치 보다는) 검색으로 접속하는 것이 접근성이 더 높기 때문.

 

하이브리드 앱

  • 네이티브 앱과 웹앱의 장점을 모두 가짐.
  • 겉은 네이티브 앱, 실제는 웹 기반.
  • 콘텐츠는 HTML 방식으로 제작.
  • 최종 앱 배포에 필요한 *패키징 처리는 안드로이드, iOS에서 개발. 
  • 앱스토어나 구글 플레이 스토어 같은 플랫폼에서만 다운로드 가능
  • 앱 안에서 웹페이지를 불러오는 방식 → 한 번 설치하면 네이티브 앱의 번거로운 업데이트 문제 해결.
  • (-) 사용자의 네트워크 환경에 따라 속도가 일정하지 않음
  • 하나의 앱으로 다양한 웹 환경에 대응할 수 있어서 '대형 쇼핑몰'이나 '포털 사이트'가 하이브리드 앱을 선호. 
*패키징 : 최종 앱 배포를 위해 기능별로 실행 파일을 묶어 만든 설치 파일. 예를 들어 안드로이드 패키지 파일의 확장자는 .aab, .apk다.

 

와이어프레임 & 프로토타입 이해

웹/앱 서비스의 기능과 디자인을 검증하고 개선하기 위한 단계.
실무에서 혼동하지만 와이어프레임과 프로토타입은 정확히 구별해야함.

 

와이어프레임

와이어프레임 : '선wire로 틀frame을 잡는다.'는 뜻.
건축 설계 도면 처럼 이미지만으로 웹/앱의 구조와 용도를 파악하는 것이 목표
  • 기능과 구조 등을 '대략적으로' 이해할 수 있으면' 된다.
  • 화면 간 흐름을 쉽게 파악할 수 있도록 각 페이지를 따로 설계하는 것이 원칙 (한 장에 모든 내용이 있으면 이해하기 어려움)
  • 와이어프레임은 협업을 위한 공유 문서의 일종 → 누가 봐도 이해할 수 있어야 함
  • 내용, 구조, 흐름, 기능 included
  • 실무에서는 손그림이나 PPT를 이용한 가벼운 형식 선호 (와이어프레임 제작에 들이는 비용과 시간을 최소화 하기 때문)
  • 서비스 출시 전에도, 기존 서비스 보완 시에도 유용

 

프로토타입

  • 와이어프레임 → 설계도면 , 프로토타입 → 실제와 비슷하게 입체적으로 구현한 모형
  • 구현 단계에 따라 피델리티 레벨을 나눌 수 있음. (Fidelity : 성실도, 충실도) 얼마나 충실하게 구현했나.
  • 구현 수준에 따라 Low fidelity, High fidelity로 구분됨.
  • 로우 피델리티는 간단한 인터렉션을 테스트 할 수 있는 정도 화려한 모션이나 세세한 기능 보다는 페이지와 페이지의 상관관계, 이를 통해 페이지 간 어색한 흐름을 잡아내는 것이 목표
  • 하이 피델리티는 실제 출시할 서비스와 거의 유사할 정도로 대부분 기능을 구현한 수준. 
  • 하이 피델리티 프로토타입 제작 이유 : 개발 비용 낮추고 높은 수준의 피드백을 얻기 위함. 이 때 부터는 제대로 된 사용성 평가를 할 수 있음. 참여자가 프로토 타입으로 주어진 과제를 수행하는 과정을 지켜보는 형태로 평가가 진행됨. 제작자는 참여하는 사람이 의도와는 다르게 제품을 이용하는 모습을 보며 객관성을 확보함. 사용할 때 느끼는 어려움, 답답한 부분들을 관찰함. 이 단계에서 문제 발생 시ㅣ, 빠르게 프로토타입만 수정해 다시 테스트 가능. 그러나 복잡한 하이 피델러티 프로토타입 수정은 개발보다 비용이 더 많이 발생할 수 있기에 팀의 상황, 자원 파악 뒤 진행해야 함.

 

프로토타입 제작 툴

프로토타입 툴 없었을 대는 UI 디자인에 안맞는 포토샵 등의 프로그램을 써야 했다. 리사이징에 제한이 있는 비트맵 기반의 포토샵...ㅠㅠ 하지만 벡터 기반의 툴(스케치, 피그마 등)들이 나타나서 1 배율로 작업할 수 있게 됨.

 

효과적인 유저 스토리 작성법

  • 와이어 프레임 제작이 끝나고, 이를 개발자에게 효과적으로 전달할 방법 → '유저 스토리' 설명 방식
  • 유저 스토리란 개발에서 '요구 사항'이라고 부르는 시스템의 기능 설명을 '사용자 관점에서 이야기하는 것'
  • 서비스의 다양한 Tasks → 각각 유저 스토리로 작성하면 개발자와 완성도 높은 커뮤니케이션을 할 수 있음.

유저스토리 틀

[사용자는] [태스크]를 수행할 수 있다.

지금부터 인스타그램 하이라이트에 사진을 추가하는 예시를 통해 유저 스토리 작성법을 자세히 알아보자.

<인스타그램 하이라이트 업로드 과정>
1. 인스타 앱 열기
2. 하단 탭의 프로필 사진을 눌러 프로필로 이동
3. 프로필 바이오 아래 '새로 만들기'를 선택
4. 게시해 둔 스토리 중에서 하나 선택
5. 표지 추가하고, 하이라이트 이름 쓰기
6. '만들기' 클릭

이 과정을 유저 스토리의 기본 틀로 만들면 다음과 같다.

[사용자]는 [인스타 하이라이트에 사진 업로드]를 수행할 수 있다.

As a (사용자), I want to (     ), So that (      ).
사용자는, 인스타그램에 하이라이트를 업로드 하고 싶다, 그렇게 해서 일상을 기록하고 싶다.
[인수 조건]을 유저 스토리에 추가하면 디자이너가 원하는 기능을 더 확실하게 전달 할 수 있음
Acceptance Criteria (인수 조건)

Where [인스타 프로필 페이지에 진입한 상태에서]
When [ 프로필 하단 "+" 버튼을 확인 후 클릭하면]
Then [사진 선택 후 하이라이트를 추가할 수 있다]
or [사진을 복수 선택하고 싶을 때]
And [하이라이트에 있는 기존 사진에서 1개 이상 선택할 수 있다.]
반응형

+ Recent posts