[TIL-230727] 프로덕트 설계 4일차

출처

[새싹X러닝스푼즈] 유니콘 기업 현직자에게 배우는 IT 서비스 기획자 취업 캠프

프로덕트 설계 강의 (김승현 강사님)

 

 

공부한 내용

기획자에게도 개발에 대한 이해가 중요하다.

 

  웹 서비스 이해  

 Front-end vs Back-end 

프론트엔드 - 유저에게 보여지는 화면 구현

백엔드 - 유저가 모르는 화면 구현

풀스텍 - 프론트 + 백엔드

 

*로컬앱: 알람, 메모 앱 - 통신이 끊겨있는 상태에서도 작동 가능

 

Client -  네트워크에서 정보를 요청하는 쪽

Server - 정보를 제공하는 쪽, 다양한 서버가 존재(이미지, 비디오,웹,,)

 

 

Web Front-end

웹은 보통 브라우저를 통해 실행, 웹을 제공하는 곳은 웹 서버

 

- HTML: 뼈대

- CSS: 디자인

- JavaScript: 동작

- 순서: html을 통해 기본적인 element 적용 > css를 이용해 element들에 디자인 적용 > javascript 적용

 

 

Back-end

서비스에 필요한 모든 데이터를 저장하고 다루는 공간

 

AWS Auto Scaling - 트래픽이 일시적으로 증가할 경우, 클라우드가 자동으로 스케일링을 해줌. AWS가 제공. 

 

 

API

- 규칙들의 집합

- 앱의 경우 버전이 달라지면 문제가 생길 수 있기 때문에 따로 구분을 해둠

 

- Open API: 모두에게 공개

- Closed API: 제한적 공개

 

*카카오 로그인 로직

 

Mobile App - iOS vs Android

연령대별 점유율이 매우 다름

예) 택시 기사용 앱의 경우 iOS는 제공 안함

 

iOS: Objective-C, Swift로 개발

Android: java, Kotlin으로 개발

 

*Flutter, React-native - 모두 커버할 수 있는 언어 

- 초기 창업자 입장에는 각각 만드는 것보다는 이런 언어들을 이용하여 빨리 개발하는 것이 나음

- 단점은 양 OS를 하나의 언어로 만든 것이다보니 각 OS에 최적화되지는 못함

- 큰 규모의 서비스에는 제한이 있음

 

iOS: 앱 심사가 꼼꼼함 -> 각각의 앱 완성도 높음 -> 유료 앱 결제 전략

Android: 무료 앱 제공 -> 인앱 광고/결제 유도 전략

 

 

웹뷰

- 자주 변경되어야하는 콘텐츠로 구성

- 앱개발자가 코드로 만든 화면이 아님

- 웹 페이지임 -> 웹이라고 못 느끼게끔 특정 url의 웹을 불러와서 실행하게끔 웹코드가 박혀 있음

- 이 화면을 바꾸려면 url을 새로 배포하면 됨 

 

 

Native App

- 모바일 OS에 최적화된 SDK를 이용해 개발한 앱(Kotlin, Swift)

- 장점: 성능과 실행 속도가 가장 높고 안정적, 앱스토어를 통해 쉽게 검색하고 다운로드하여 간편하게 사용

- 단점: 인력, 시간, 비용이 비교적 크게 소모 / 수정이나 업데이트 시 승인이 필요하므로 배포 및 적용 속도가 느림

 

Web App

- 앱의 형태를 가지지만 실제 내용은 웹에서 구현

- 모바일 웹과 네이티브 앱을 결합한 형태로 모바일 웹과 동일하게 html로 개발하지만,

모든 ui와 ux를 앱과 유사하게 제작해서 모바일로 url 접속 시 앱처럼 작동

- 장점: 업데이트 시 별도의 심사 필요 없음

- 단점: 스마트폰 고유 기능을 사용할 수 없음(카메라, 녹음, GPS, 푸시 알림 등) / URL을 통해 접속해야 하고 인터넷 속도의 영향을 받음

 

Hybrid App

- 네이티브 앱의 구조를 가지고 있으나, 일부 기능들을 웹으로 구현해 개발

- 네이티브 앱에 웹 화면을 띄워 웹앱을 실행시키는 것으로 네이티브 앱과 웹 앱의 혼종

- 최근은 거의 모든 앱이 하이브리드 앱의 형태를 띔

- 장점: 다양한 개발이 가능, 적재적소에 네이티브 API와 웹 API를 배치해 각각의 장점을 극대화할 수 있음

- 단점: 기획자 입장에서는 이게 웹에서 발생한 문제인지, 앱에서 발생한 문제인지 판단하기 어려움(얽혀있음)

 

어떤 기준으로 선정?

- 초기: WebApp으로 제작 -> 테스트하는 것을 권고

 

 

앱 스토어 배포

- Apple: 상대적으로 심사 과정이 까다로움

- Google: 심사 과정이 적음

 

*tip: 배포 주기를 정하는 것이 좋음(스크럼, 3주에 한 번 정도)

배포 주기가 없으면 - 윗단은 asap을 원하고, 아랫단에서는 일정이 있음

정해진 일정이 있으면 좋음, 주기가 반드시 필요함!

 

Apple App Store 대표적인 거절 사유

- Apple ID 로그인: 필수

- 스크린샷: 아이폰으로 연상되지 않는 스마트폰 모양의 그림을 첨부해서는 안됨, 해상도가 낮은 이미지 첨부해서는 안됨

- 푸시 알림: 필수면 안됨, 거절/건너뛰기 버튼 필요

- 인앱 결제: 디지털 컨텐츠 구매 시 수수료가 나감 

예) 유튜브 프리미엄, 네이버 쿠키

- 리워드: 친구 초대/리뷰 작성 시 보상을 지급하는 리워드 금지

- 테스트/베타 등의 문구: 앱 내 콘텐츠/파일명 등에 '테스트, 베타' 등의 문구가 있는 경우 등록 거절

 

앱 업데이트

- 강제(필수) 업데이트

- 권장(선택) 업데이트

 

유저가 많은 서비스의 경우 강제 업데이트를 하면 문제가 생길 수 있음

-> 오래된 핸드폰의 경우 버전이 호환되지 않을 수 있음 -> 크래쉬

-> 좋지 않은 사용자 경험을 제공할 수 있음

-> 거의 하지 않음(1년에 1-2번), 굉장히 오래된 버전에서만 실행

 

앱 업데이트 안내

- 발생 가능한 문제에 대한 안내: 공급자적 마인드를 버리기

- 업데이트에 대한 구체적 안내

- 업데이트를 하지 않아도 핵심 기능은 계속 사용할 수 있도록 허용

- 앞으로 추가될 기능에 대한 안내 및 알림

 

릴리즈 노트 작성

- 앱 스토어: 버전 기록

- 플레이 스토어: 새로운 기능

-> 유저에게 업데이트 소식을 전하고, 친밀한 메시지를 전달할 수 있음

-> 보통 기획자가 관리 / 마케팅 팀에서 전달

 

- 동일한 메시지를 반복 노출하기보다는 사용자에게 친근한 메시지를 전달하는 것이 좋음

- 업데이트 기능에 대한 구체적 정보를 제공하는 것이 좋음

- 사용자의 맥락에서 업데이트 내용에 대한 친근한 안내

 

 

 

  QA(Quality Assurance)  

개발 후 운영 서버에 배포하기 전에 기획에 맞게 개발되었는지 검증하는 행위

 

*보통은 happy case만 test하지만, error case도 test해야 함

 

 

체크 포인트

- 기능성: 기획자가 의도한 기능들이 올바르게 작동하는지 검증

- 심미성: 오탈자가 있는지, 표시되는 이미지에 문제가 없는지 검증

- 호환성: 디바이스/OS/버전/브라우저 등에 따라 동일한 형태로 구현되는지 검증

 

 

테스트

- 정적 테스트: 개발자들이 모여 코드 리뷰 수행(개발 팀)

- 동적 테스트: 실제로 수행하며 오류를 찾음(QA 팀)

QA팀에서 테스트 시나리오를 짜면, 각각 단말기로 수행

 

- 화이트 박스 테스트: 내부 로직을 아는 상태에서 테스트, 개발자 관점

- 블랙 박스 테스트: 내부 로직을 모르는 상태에서 테스트, QA팀 관점

 

- 단위 테스트: 특정 함수만 동작

- 통합 테스트: 여러 함수를 엮어서 동작

- UI 테스트: 통합 + UI 입혀서 동작

 

 

테스트 자동화

반복되는 테스트를 자동화, 단위~통합 일부 테스트를 자동화시킴

 

 

테스트 주도 개발(TDD: Test-Driven Development)

: 실패 케이스를 계속 생각하면서 코드를 작성

현업에서는 시간이 부족해 잘 수행하지는 못함

 

 

UI 테스트 자동화

- Selenium Webdriver

웹 테스트에 최적화

QA 자동화뿐만 아니라 업무 자동화까지 가능해짐

- Appium

 

 

QA 진행 팁

1. 테스트 환경 세팅

2. 시나리오별 계정 세팅

3. 시나리오 한계를 극복하기 위한 랜덤 QA

4. 의존성 요소를 고려한 누적 QA

 

 

딥 링크

특정 주소 혹은 값을 입력하면 앱이 실행되거나 앱 내 특정 화면으로 이동시키는 기능

 

- URI 스킴: 앱에 URI 스킴 값을 등록하여 딥링크 사용

- 앱 링크: 도메인 주소를 이용한 딥링크 사용(안드로이드)

- 유니버셜 링크: 도메인 주소를 이용한 딥링크 사용(iOS)

 

URI 스킴

한계: 스킴 값의 중복 문제 발생

 

앱 링크, 유니버셜 링크

URI 스킴의 한계 극복

 

지연된 딥 링크

- 앱이 설치되어 있지 않은 경우, 앱 설치 후 실행한 이용자가 앱의 첫 화면이 아닌, 지정된 특정 앱 페이지로 이동되는 기능

- 광고를 통해 특정 상품페이지로 랜딩시켜야 하는 커머스 등의 앱 서비스에서는 지연된 딥링크 적용 여부 확인 필요

 

 

 

  다국어 대응  

다국어 관리

- 다국어 언어셋은 고유 key값에 언어 코드를 대응한 값을 데이터베이스에 저장하여 관리

- 다국어 대응이 필요한 문구를 사전에 확인한 후 번역을 진행하여 배포 전에 적용될 수 있도록 확인

- 원활한 번역을 위해 서비스 화면이 포함된 이미지 등을 첨부하여 번역 진행

 

문자의 압축률

- 어떤 문장을 표현할 때 몇 글자의 문자가 필요한가

- 한국어는 압축률이 매우 뛰어난 언어

- 영어는 중간 정도의 압축률이기에 이를 기준으로 잡아 레이아웃 설계

 

주요 언어별 고려사항

- 영어: 언어 코드가 en이라고 하더라도, 다양한 국가 코드가 존재

- 중국어: zh-CN(간체), zh-TW(번체), 띄어쓰기 없음

- 일본어: 띄어쓰기 없음

- 스페인어: es-419(남미), es-ES(스페인), 문장의 앞에 역물음표, 역느낌표 존재

- 아랍어: R to L, 아랍어 문구 입력/수정/복사 시 L to R 강제 변환 주의

 

GDPR(General Data Protection Regulation)

- EU 개인정보보호 법령

 

다국어 대응을 고려한 UI 디자인 참고

- 길어질 문장에 대비해 넉넉한 텍스트 공간 마련

- 이미지에 텍스트 삽입 피하기 -> CSS로 이미지 위에 텍스트 올리기

- UI 요소로 문장 완성 피하기

- 메타포(비유) 조심하기

 

중국 시장의 특성

- 폐쇄적

- 안드로이드 점유율 80% 이상

- 다양한 앱 스토어 존재 -> 상위 5개 앱 스토어의 시장 점유율 70% 상당

 

 

  계정  

주요 관련 법령

- 개인정보 보호법

- 정보통신망 이용촉진 및 정보보호에 관한 법률

- 위치정보의 보호 및 이용 등에 관한 법률

 

약관

- 약관 개정 고지 의무

- 안내 채널: 서비스 내 공지사항/배너 등, 이메일

 

개인정보 처리방침 + 개인정보 제 3자 제공

- 개인정보 이용내역 통지

 

회원가입/로그인

- 비밀번호 규칙 수립

: KISA도 새로운 디지털 아이덴티티 가이드라인 정책 준용하여 비밀번호 가이드라인 수정

KISA(한국인터넷진흥원)_패스워드 선택 및 이용 안내서

 

Passwordless 로그인

- 소셜 로그인

- PIN 번호/생체 인증 수단 등록

- 폰번호/이메일 통한 인증번호 입력

- QR 로그인

 

인증

필요한 경우에만 사용, 자주 남발하면 안됨

 

휴면

 

탈퇴

 

 

 

  슈퍼 앱 전략  

하나의 앱 안에서 별도의 다른 앱을 설치하지 않아도 수많은 서비스를 이용할 수 있는 앱

예) 토스 - 토스, 토스증권, 토스뱅크 모두 법인이 다른 회사이지만 한 앱에서 제공

 

한국에서는 아직 부족, 중국에서 최초 등장한 전략

카피캣이 당연시되는 중국에서 다른 경쟁사(카피캣)들이 따라오지 못하도록 디지털 '해자'를 판다

자신들만의 것을 계속 추가하는 전략

 

중국의 WeChat

- 앱 위의 미니 앱이 100만개 이상

- 이 앱 자체가 하나의 OS 개념이 되어버림

- DAU가 2억 명

 

GRAB

- 택시, 자전거 등 모든 교통수단

- 음식, 식재료, 물품 배송, 결제

- 소액 대출, 자동차 보험

- 행사장 입장이나 줄을 대신 서주는 그랩 드라이버 등..

 

네이버 지도, 카카오 모빌리티, ,,

 

 

모두 하나의 앱으로 만들어 버리면 난이도가 기하급수적으로 올라감

복잡도가 엄청나게 높아짐 -> 계정, 빌링, 약관, 데이터 분석, 법무 등

안정적인 서비스 제공을 고려한 개발 및 테스트 일정 산정 필요

 

 

Mobility

MaaS(Mobility As A Service)

- 사람의 이동 관점에서 모빌리티와 관련된 모든 기획

- 기차/버스 등 대중교통을 비롯해 택시/공유 차량 등 다양한 모빌리티 서비스를 하나로 통합하는 흐름

- 이용자에게 목적지까지 가는 가장 효율적인 방법을 알려줄 뿐만 아니라 이동수단에 대한 요금 결제 및 예약 등 모빌리티와 관련된 모든 서비스를 하나의 플랫폼에서 제공

 

- UAM(Urban Air Mobility, 도심항공교통)

 

LaaS(Logistics As A Service)

- 물류의 이동 관점에서 바라보는 것

- 식품 배달, 화물을 중개하는 플랫폼 서비스

 

- 근거리 로봇 배송 -> 음식점 서빙 로봇 상용화 단계

- 화물차 군집주행

 

TaaS(Trasnportation As A Service)

- MaaS + LaaS

- 수송 전반을 서비스 관점에서 바라본 것

- 자율주행차, 전기차 등 미래차뿐만 아니라 도로 인프라/충전 인프라 등도 포함

 

 

 

 

느낀 점

기획자가 고려해야 할, 알아야 할 요소들이 너무 많다

개발+규제+디자인+알파.. 

개발은 익숙한 분야인데, 기획자 관점에서 보니 좀 색다르다

모빌리티 시장이 생각보다 흥미로운 분야인 것 같다

 

 

 

 

참고

REST-API 활용한 카카오 소셜 로그인 구현(feat. React, SpringBoot)