3 day 2024.05.15.
17. 중간점검: 고객 경험을 만드는 PM 전략 (3)
8. 개발 플랫폼 특징 및 플랫폼 출시 기준
1) 개발 플랫폼 종류
- Mobile Apps는 Native App / Hybrid App / Web (Natve 껍데기를 가지고 안에 컨텐츠&웹 형태로 구현)
1-1) Web v.s. App 특징
| Web (PC/Mobile) | Android / iOS Native Application |
| 기준 해상도 정의 (예. 1024*768) |
표준/독립된 OS 설정 (안드로이드, iOS) |
| 브라우저 호완성 강함 (IE9, Chrome, Firefox 등) |
브라우저 호환성 약함 (Safari, Chrome) |
| 마우스/키보드 인터페이스 | 터치 인터페이스 |
| 넓은 영역 | 제한된 영역 |
| 정보 우선순위에 대한 배치 | 정보 우선순위에 대한 노출 순서 (제한된 화면으로 처음 보여줄 컨텐츠 중시) |
| 웹 접근성 준수 | Native App의 경우, App 접근 권한 정의 & 앱접근성 준수 (스마트폰 앱 접근 권한 안내서) |
| 웹표준 준수 (HTML5, CSS, JavaScript) |
앱표준 GuideLine (앱스토어, 구글) |
① 네이티브 앱(Native App)
· 정의 및 특징:
· 안드로이드 앱은 Google Play Store, iOS 앱은 App Store에서 다운로드 가능. 각 OS에서만 실행.
· Single Platform + Full Capability(모든 UI/기능 사용 가능) + 기기 기본 기능(카메라, 마이크, GPS 등)의 빠른 구현.
· 장점:
· 다양한 네이티브 기능과 UI 이용, 뛰어난 퍼포먼스 제공.
· 빠르고 안정적이며 반응이 빠른 환경.
· 단점:
· 특정 OS에서만 다운로드 및 실행 가능.
· 수정사항 발생 시, 앱을 업데이트 및 배포해야 함.
· 특정 플랫폼 언어 제약 존재.
· 유용한 경우:
· 필수 플랫폼 기능 필요 시.
· 앱 기능이 많고 복잡하며, 높은 성능이 요구될 때.
② 하이브리드 앱(Hybrid App)
· 정의 및 특징:
· 네이티브 앱과 웹 앱의 결합. 네이티브 앱 껍데기에 웹뷰를 띄워 웹 앱 실행.
· 각 마켓에서 다운로드 후 설치. 내용은 웹 기반으로 구성.
· Multiple Platform + Full Capability(기기 제공 기능 구현)
· 장점:
· 네이티브 API와 브라우저 API 이용, 다양한 개발 가능.
· 스마트폰 제어 가능(카메라, 마이크, 지문 인식 등).
· 크로스 플랫폼 대응 용이, 유지보수 간편.
· iOS와 Android에서 동일한 컨텐츠 제공.
· 단점:
· 복잡한 네비게이션에서 동선 문제 발생 가능.
· 네이티브 기능 접근을 위해 네이티브 개발 지식 필요.
· 유용한 경우:
· 다중 플랫폼 지원이 필요할 때.
· 많은 사용자가 다양한 채널을 통해 동시 접속해 일관된 서비스를 제공해야 할 때.
콘텐츠가 빈번하게 변경될 경우.
③ 모바일 웹
- 정의: 브라우저에 URL만 입력하면 어떤 디바이스에서나, 어디서든 동일한 콘텐츠를 볼 수 있는 방식입니다.
- 특징:
· 장점:
· 어떤 플랫폼에서든 동일한 컨텐츠 제공
· 개발 시간과 비용 절약
· 빠른 컨텐츠 업데이트 가능(앱과 달리 배포-검토-승인 과정 필요 없음)
· 단점:
- 유용할 때:
· 다중 플랫폼 지원이 필요한 경우
· 다양한 채널을 통해 많은 사용자들이 동시에 접속하여 동일한 서비스를 제공해야 할 때
· 콘텐츠가 자주 변경되는 경우, 앱보다 모바일 웹을 먼저 런칭하는 것이 유용
2) 웹(Web) 종류
① 반응형 웹(Responsive Web)
- 정의: 하나의 소스 코드로 모든 스크린에 최적화된 웹 사이트를 구축할 수 있는 방법.
- 특징: 브라우저의 가로 넓이에 반응하여 구성 요소가 변하고, 다양한 기기 해상도에 맞춰 화면 레이아웃이 자동으로 변경됨.
- 장점: 디바이스 해상도에 유연하게 반응하여 어떤 기기에서도 동일한 콘텐츠를 볼 수 있어 일관성을 확보.
- 단점: 서로 다른 기기 넓이에 맞춘 CSS 추가 코딩 필요로 초기 작업 시간이 오래 걸리나 장기적인 면에서는 효율적.
② 적응형 웹(Adaptive Web)
- 정의: 데스크탑과 모바일 버전의 사이트를 각각 제작하여 운영하는 방법.
- 특징: 주소 앞에 'm'을 붙이면 모바일 웹 페이지로 접속.
- 단점: 웹페이지를 수정할 경우, 각각 HTML과 CSS를 두 번 수정해야 해서 작업이 중복되고 비효율적이며 버그 발생 확률이 높음.
3) 개발 플랫폼 정의: 플랫폼 결정 전 고려 사항
- 서비스의 목적: 어떤 서비스를 제공하려는지 명확히 할 것.
- OS에서 제공하는 기능 활용: 서비스가 기기의 기능을 많이 사용하는지, 저장 공간을 많이 차지하는지 등을 고려.
- 콘텐츠 변경 주기: 컨텐츠 변경이 빈번한 경우 (예: 쇼핑몰, 면세점) Hybrid App이 추천됨.
3) 플랫폼 출시 기준
3-1) 플랫폼 출시 기준 결정 방법 (Native App의 경우)
- 기준 결정 시 고려 사항: 안드로이드와 iOS 중 어느 플랫폼을 먼저 출시할지 결정하는 방법.
- 예) 안드로이드 / iOS 동시 출시는 불가능할 경우, 어느 플랫폼은 먼저 open할지 고민?
3-1-1) HOW TO 1.
- 객관적인 데이터 기반으로 선정해야 하므로, [Statecounter] 웹사이트 들어가서
[Edit Chart]에서 Operating, Region, Chart Type, Period 기준 체크
- 국내 Mobile OS 시장 점유율 확인 → 앞도적으로 안드로이드
: (결과) Android 73.64% iOS 23%
- 일본 마켓쉐어를 검토했을 때, 일본 OS 시장 점유율 확인
: (결과) Android 33.8% iOS 63% → 앞도적으로 아이폰!
- 미국 스마트폴 OS 비율
: (결과) Android 58.8%% iOS 40.3% → 비슷할 경우, 연령/관심사 등 Segment 하여 타겟 명확하게 할 것
3-1-2) HOW TO 2.
a. 네이버 데이터를 통한 기기/성별/연령/기간대별 핸드폰 클릭량 추이 검색.
b. 연령대별 선호: 20,30대는 아이폰, 40대는 안드로이드.
3-2) 플랫폼 출시 순서 결정 시 고려사항
a. 내부 리소스 (디자인, 개발, QA) 고려: 동시 출시 준비 시, 일정 간격을 두는 것 권장.
b. 출시 국가의 OS 시장 점유율 고려.
c. 타겟 유저가 선호하는 OS 우선 출시.
9. 개발자와 협업하기
Q. 기획자도 개발 언어를 배워야 할까요?
A. 개발하는데 개발 환경을 먼저 익숙하게 익히는 부분이 중요 2) 개발자가 쓰는 단어 익히기
(이미 개발자도 프론드개발자/안드로이드개발자/iOS개발자/백엔드개발자 다양한 상황)
1) PM에게 요구되는 역량
- 고객에 대한 깊은 이해
- 비즈니스에 대한 깊은 이해
- 개발 환경 기술에 대한 깊은 이해
- 시장과 산업에 대한 깊은 이해
- 데이터에 대한 깊은 이해
2) 개발자와 협업하기 (개발 ∝ 건설/시공과 접목)
- 시공 팀의 용어와 환경을 이해하고 소통하는 인테리어 사장님
3) 프로그래밍 언어
- 컴퓨터의 언어
- 컴퓨터와 인간의 소통 방법
- 소통 체계
4) 운영체제 - 각 운영체제의 언어 상이
- Microsoft - Windows: C#, Visual Basic, C++, JavaScript
- Apple - Mac OS / iOS: Objective-C, Swift
- Google - Android: JAVA, Kotlin
- 운영체제의 역할
5) 서버와 클라이언트의 관계
- 클라이언트의 요청(Request)과 서버의 응답(Response) 관계
- 통신 체계 및 규칙의 중요성
- API를 통한 정보 교환 과정
1. 클라이언트 사이트 접속 시 - 서버는 웹사이트 제공
2. 클라이언트 로그인 시(ID/PW 입력) - 서버는 요청한 체계에 맞춰 응답하여 세션 생성 및 유지
클라이언트의 특정 자료 요청 시 - 서버는 세션 저장소에서 해당 정보를 찾아 응답
6) 쿠키(Cookie)
- 쿠키란?
- 사용자가 브라우저 또는 PC를 사용하며 남긴 정보의 흔적(부스러기)
- 앱이나 웹사이트 방문 시, 사용자에 대한 정보를 저장하는 주된 방법
- 쿠키는 최대 4KB의 용량을 가진 매우 작은 양의 데이터를 저장
- 쿠키에 사용자의 정보를 담아 서버로 보내면, 서버는 쿠키를 읽어 사용자가 누구인지 파악
- 쿠키의 용도
- 사용자가 검색한 것을 기억하거나 페이지 간 이동 시 로그인 상태를 유지하는 데 사용됩니다.
- 쇼핑 카트 항목, 자주 찾는 검색 키워드 등을 저장합니다.
- 예를 들어, 11번가에서 내가 본 상품을 리스트업하여 우측 하단에 보여주는 기능 등이 있습니다.
- 사이트 방문 시 "아이디와 비밀번호를 저장하시겠습니까?"와 같은 메시지가 나타나며, 재방문 시 ID/PW가 자동으로 입력된 상태를 유지할 수 있습니다.
- 쿠키의 단점
- 보안에 취약할 수 있습니다.
- 쿠키 종류
- 세션 쿠키
- 영구적 쿠키
7) 세션(Session)
- 세션의 정의
- 서버와 클라이언트 간의 지속적인 연결 상태를 유지하는 기술입니다.
- 일정 시간 동안 같은 사용자의 브라우저로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 일정하게 유지시킵니다.
- 사용자가 웹 브라우저를 웹 서버에 접속한 시점부터 웹 브라우저를 종료함으로써 연결을 끝내는 시점까지를 의미합니다.
- 세션의 목적
- 하드디스크에 정보가 남는 것과 같은 취약점을 보완합니다.
- 사용자와 서버 간의 지속적인 상태 유지를 가능하게 합니다.
- 세션의 단점
- 사용자의 접속량이 많을 경우, 서버에 과부하가 발생할 수 있습니다.
- 세션의 예시
- 금융권 화면에서 보이는 "자동 로그아웃 남은 시간 21초"
- 리크루팅 화면에서 데이터 작성 중 "로그인 세션 남은 시간 2분 20초"와 같이 일정 시간 동안만 데이터를 임시 저장할 수 있는 기능 제공
- 세션 종료 조건
- 사용자 브라우저가 종료될 경우 세션 종료
- 사용자가 일정 시간(약 30분) 동안 움직임이 없을 경우 세션 종료
· 사용가 브라우저는 종료할 경우, [세션 종료]
· 사용자가 일정시간(약 30분) 동안 움직임이 없을 경우, [세션 종료]
- 세션 관리
- 쿠키와 다르게 세션은 서버에서 관리됩니다.
- 서버에서 클라이언트를 구분하기 위해 '세션 ID'를 부여하며, 브라우저를 종료할 때까지 인증 상태를 유지합니다.
- 세션의 작동 과정
- 클라이언트가 서버에 요청합니다.
- 클라이언트가 서버에 접속 시, 서버는 '세션 ID'를 발급합니다.
- 클라이언트는 '세션 ID'를 쿠키를 사용하여 저장합니다. 서버에 요청 시, 이 쿠키의 세션 ID를 서버에 전달해서 사용합니다.
- 서버는 클라이언트의 요청을 처리하여 응답합니다.
8) 캐시(Cache)
- 캐시의 의미
- 데이터의 값을 미리 복사하여 저장하는 것을 의미합니다.
- 고정적으로 사용되는 이미지, HTML, JavaScript 등을 미리 하드웨어에 저장하여, 차후 웹사이트 접속 시 빠르게 데이터를 가져옵니다.
- 캐시의 목적
- 웹 사이트에 처음 접속할 때보다 다시 접속했을 때 로딩 시간을 단축시키기 위함입니다.
- 서버로부터 데이터에 접근하는 시간이 오래 걸리거나 값을 다시 계산하는 시간이 오래 걸릴 경우 사용됩니다.
- 캐시의 사용 예시
- 크롬 웹 브라우저에서 [설정] - [인터넷 사용 기록 삭제] 클릭 시, "캐시된 이미지 및 파일"을 삭제하여 저장용량을 확보하며, 이로 인해 일부 사이트는 다음 방문 때 속도가 느려질 수 있습니다.
- 브라우저가 저장하는 자산은 주로 '정적인 자산'입니다. 이는 웹 페이지에 방문할 때마다 변하지 않는 것들을 말하며, 이미지(로고, 사진, 백그라운드), HTML, CSS, JavaScript 등이 해당됩니다.
- 캐시의 장점
- 웹 사이트의 로딩 시간을 단축시켜 사용자 경험을 향상시킵니다.
- 서버의 부하를 감소시켜 더 효율적인 데이터 처리가 가능해집니다.
- 캐시 관리 방법
- 사용자는 브라우저 설정을 통해 캐시된 데이터를 관리할 수 있습니다. 예를 들어, 인터넷 사용 기록을 삭제하는 기능을 통해 캐시된 이미지 및 파일을 정리할 수 있습니다.
- 개발자는 캐시 정책을 설정하여 정적 자산의 캐싱 방법을 조절할 수 있습니다. 이는 브라우저가 언제 캐시를 업데이트해야 하는지 결정하는 데 도움이 됩니다.
9) 토큰 (token) 기반 인증 시스템
- 개념
- 쿠키(Cookie)와 세션(Session)의 단점을 보완하기 위해 '토큰'을 사용하는 인증 방식.
- 주요 특징
- 클라이언트의 정보를 저장하지 않기 때문에 서버의 과부하가 발생하지 않음.
- 사용자의 인증 정보를 서버 또는 세션에 유지할 필요가 없음.
- 사용자가 로그인 상태인지 여부에 대해 서버가 관리할 필요가 없음.
- 쿠키를 전달하지 않기 때문에 쿠키 사용으로 인한 취약점을 해결할 수 있음.
- 인증 과정
- 인증 요청: 사용자가 로그인을 시도하면 서버는 사용자의 인증 정보를 확인.
- 토큰 발급: 인증이 성공하면 서버는 사용자에게 토큰을 발급.
- 토큰 저장: 클라이언트는 받은 토큰을 저장해두었다가 서버에 요청을 할 때마다 토큰을 함께 전송.
- 토큰 검증: 서버는 요청과 함께 받은 토큰을 검증하고, 토큰이 유효하면 요청한 응답을 함.
- 인증 유지: 토큰은 인증 정보와 함께 클라이언트에 저장되어, 사용자가 서버에 요청할 때마다 재인증 없이 서비스를 이용할 수 있게 해줌.
- 예시
- '오늘의 집' 로그인 시 카카오/네이버/페이스북 등의 간편 로그인을 통해 인증 후, 서비스는 사용자에게 토큰을 발급. 사용자는 이 토큰을 이용하여 서비스에 접근.
- 장점
- 보안성이 높음: 클라이언트와 서버 사이에 인증 정보를 직접 전송하지 않으므로 보안성이 높음.
- 확장성이 좋음: 서버의 부하를 줄이고, 다양한 플랫폼(웹, 모바일 등)과 서비스에서 쉽게 구현 가능.
- 유연성: 다양한 인증 방식(소셜 로그인 등)과의 통합이 용이함.
10) 웹 접근성 vs. 앱 접근 권한의 차이
① 웹 접근성
: (장애인차별금지법) 신체장애, 지체, 시각, 청각, 인지 or 신경학적 장애 등 어떤 장애를 갖고 있는 사람이라도 차별하지 않고 누구나 콘텐츠를 이용할 수 있도록 기술적으로 제공해야 한다.
- 예) '한국 웹 접근성 평가센터'의 test를 통해 인증마크 부여
- 예) '네이버' Accessibility Guide를 통해, 장애인차별금지법 개정 후 전자정보를 장애 환경에 상관없이 동등한 수준으로 제공 → 웹 접근성 지침(KWCAG)을 발표하여 모든 웹 사이트가 '웹 접근성 준수 권고'
1-1) 웹 접근성 준수 가이드
1. 인식의 용이성
- 목적: 사용자가 콘텐츠를 쉽게 인식할 수 있어야 함.
- 구체적 방법:
2. 운용의 용이성
- 목적: 사용자 인터페이스 구성 요소는 조작 가능하고 네비게이션할 수 있어야 함.
- 구체적 방법:
3. 이해의 용이성
- 목적: 장애의 유무에 관계없이 모든 사용자가 콘텐츠를 이해할 수 있게 구성되어야 함.
- 구체적 방법:
4. 견고성
- 목적: 웹 콘텐츠는 미래의 기술에도 접근할 수 있도록 견고하게 만들어져야 함.
- 구체적 방법:
1-2) 웹/앱 접근 권한 (Accessibility Permission)
- 정의: 스마트폰 앱 서비스 제공자가 사용자의 스마트폰 내 저장된 정보나 설치된 기능에 접근하여, 해당 정보를 읽고, 수정하거나 기능을 실행할 수 있는 권한.
1. 필수 권한
- 설명: 앱에서 제공하는 서비스를 위해 반드시 필요한 스마트폰 내의 특정 데이터나 기능에 접근해야 하는 경우.
- 예시: 위치 정보 - 위치 기반 서비스 제공을 위해 필요.
2. 선택 권한
- 설명: 앱 실행에 필수적이진 않지만, 특정 기능이나 정보 활용을 위해 필요할 수 있으며, 사용자가 허용을 선택할 수 있는 권한.
- 예시:
예시
- T map 앱 사용을 위한 접근 권한 요청:
참고
- 앱 접근 권한 개인 정보보호 안내서: 사용자 권한 관리 및 개인 정보 보호를 위한 안내서. 사용자는 이를 통해 어떤 정보가 공유되고, 어떻게 관리되는지 이해할 수 있음.
11) 개발자와 협업하기 (개발자를 위한 환경 구성 + 어떻게 커뮤니케이션을 해야 하는지?)
1. 개발 환경과 언어 이해하기
- 목표: 개발 언어와 환경에 대한 기본적인 이해
- 실천 방법: 모르는 개발 언어나 환경이 있다면, 검색을 통해 기초 지식 습득 또는 직접 개발자에게 문의
2. 확장성, 속도, 안정성에 대한 논의
- 목표: 개발팀과 프로젝트의 기술적 측면에서 중요한 요소들에 대해 함께 논의
- 실천 방법: 상충되는 요구사항이나 목표에 대해 조율하며 최적의 해결책 모색
3. 개발 트렌드 학습 지속
- 목표: 최신 디자인 및 개발 트렌드에 대한 지속적인 학습과 인지
- 실천 방법: 장점과 단점을 포함하여 최신 트렌드에 대한 지식 업데이트 유지
4. 공유와 소통 강화
- 목표: 프로젝트 초기 단계부터 계획, 디자인, 개발 팀 간의 긴밀한 협력과 소통
- 실천 방법: 스프린트 방식을 활용하여 프로젝트 의도, 문제 파악 및 개선 사항에 대한 지속적인 논의와 공유
5. 업무 완료 시점 설정
- 목표: 업무의 완료 시점에 대한 명확한 설정 및 문제가 발생할 가능성에 대한 사전 대응
- 실천 방법: 개발자와의 협의를 통해 목표 날짜 설정, 상위 사업 전략에 따른 사전 설계 시 발생할 수 있는 문제에 대한 사전 검토 및 일정 확인 필요