김민태의 React와 Redux로 구현하는 아키텍처와 리스크관리(2)
패스트캠퍼스 The Red
2. 안정적인 프로덕트를 위한 아키텍처 설계와 리스크 관리
3) 웹뷰 개발을 설계하는 방식
현대의 서비스들 - 앱 서비스
앱 위주의 서비스에서 어떤 것을 고려해야하는가
앱을 만들기 위한 기술은 다양하게 존재함
구글 Android vs 애플 iOS
생각해볼 점 : 순수한 네이티브 앱이란 존재하는가?
모바일앱 초창기
네이티브 앱 구현 비용 높음
하지만 대부분 대외비이기 때문에 실제로 어떤 기술로 구현되었는지는 회사마다 다름
네이티브 앱 패키징 아키텍처
But 모든 화면을 다 앱으로 만드는 것은 어렵다
규약, 심사, 출시일정, 구현비용 이슈
많이 고려되는 방식 -웹뷰웹앱
🔎 네이티브 컨테이너 + 단일 웹뷰
🔎 네이티브 + 멀티 웹뷰
ex) 상품, 주문 페이지 - 일반 사용자 입장에서는 분간이 어려울 정도로 잘 구현
🔎 네이티브 + RN
- 사용성, 퍼포먼스 이슈 없이 민첩한 사용 경험
- 스타트업에서 많이 고려하는 방법
- 웹 프론트엔드 개발이어도 역량있는 네이티브 개발자가 적어도 1명은 필요하다 (crush 방지)
- React Native와 혼용하여 개발
- 다만 RN은 아예 아키텍처가 다르므로 하이브리드로 구현하더라도 프로젝트 구조가 나중에 변경되어 발생하는 cost 방지를 위해 구성을 애초에 RN으로 시작하고 이후 앱과 관련된 공통화면을 구현하는 방식으로 접근해야 개발 효율을 높일 수 있다
ex) 인스타그램 (RN가 담당하는 view가 대부분)
⭐️ 앱 패키징 아키텍처와 무관한 고려사항
네비게이션 룰을 확립하라
- 특정 화면의 직접 랜딩을 위한 앱 스킴 디자인
네비게이션 룰,딥링크 스펙설계의 중요성- 앱 배포되면 아예 그 버전이 스토어에 박제됨 (업데이트 하기 전)
- 강제 업데이트하게 하는 결정 시 비즈니스 입장에서는 버릴 수 없는 사용자
- 버전과 관련된 피처, 확장성 고려한 유연한 대처
공개용 웹뷰와 내부용 웹뷰를 분리하라
- 이벤트 페이지 URL - 브라우저 다이렉트 노출
- 보안을 고려하라
- API 연동 토큰 및 앱 메타 정보 등 서버가 필요로 하는 정보를 어떻게 관리할지 고려
- 노출되면 안되는 정보를 초기부터 분리
- 서버를 나누고 잠재적인 보안 이슈 해결
- 다만 2개의 서버 운영 비용 발생하는 부분은 있음
개발 환경을 구축하라
- 웹뷰와 데스크탑 브라우저는 다르다.
- 같은 기기 내 웹뷰, 브라우저 등도 차이점이 존재한다.
- 시뮬레이터와 실제 디바이스에서 작동하는 것도 차이가 존재한다.
- 각각에 대해 개발자가 경험할 수 있는 환경을 미리 준비하고
개발자 간 쉽게 방법을 공유할 수 있도록 문서화하고 변경사항을 업데이트한다.
런타임 오류를 수집하라
- 실제 디바이스 환경이 브라우저보다 다양함 (안드로이드 제조사별 다양)
- 사용자 리포트 : 고객이 겪는 다양한 오류
- 개발팀 입장에서는 도대체 뭐가 오류인지 모를 수도 있는 상황
- 런타임 오류를 추적할 수 있는 방안 ex) Sentry
- 참고자료
Sentry로 우아하게 프론트엔드 에러 추적하기
자바스크립트 센트리는 어떻게 동작할까?
캐싱을 적극적으로 활용하라
- 캐싱 : 네트워크를 통해 서버로부터 불러온 데이터
- 네트워크가 안될 때에 화면이 안 나온다면
- 캐싱된 데이터와 서버 패치 데이터의 자연스러운 전환을 고려한 UX를 설계하라
- 참고자료
사용자 경험과 성능 개선 방법 in 카카오웹툰
웹뷰의 라이프사이클을 인지할 수 있는 인터페이스를 설계하라
- 네이티브 앱이 웹뷰를 로드 시킬 때 첫번째 로드 후 다른 네이티브 화면에 가려져서 안 보이는 경우
ex) 탭바 : 사용자가 다시 화면에 들어올 때 페치된 화면- 네이티브 앱만 인지할 수 있는 화면
- 웹앱에서 인터페이스 재사용 (업데이트 할 필요 x)
모바일웹에서의 접근성 고려하라
- 사용자가 점차 늘어났을 때
4) 신규 개발 관점에서의 리스크 관리
제품을 처음 개발하게 되면 발생하는 다양한 리스크
커뮤니케이션
Soft Skill (소프트 스킬)
추상적인 기준 - 좋다? 나쁘다? (상대적인 개념)
커뮤니케이션, 무엇이 문제인가
그래서 어떻게 하란 것인가
프로젝트 사전 - 일관된 용어, 컨텍스트 맥락, 합의된 사항 공유 (초기부터)
프로토타입 - 동작하는 시제품
동작하는 제품만이 오해를 막을 수 있는 거의 유일한 방법
각자가 생각했던 것과 실제 구현된 것의 정보 차이를 줄이기
감정 쌓임 - 제품 퀄리티 영향
브레인 스토밍 단계에서부터 서로 의견 공유 필요성
POC : Proof-of-Concept
참고자료
ex) 회원가입 - 이 동선은 효율적인가?
동선을 확인하기 위해 프로토타입을 만드는 것
데이터를 서빙받는 상황 - 딜레이 - 동선 - UX
동적인 데이터 : 프론트엔드를 시각적, 정적으로만 한정하지 말 것
Mocking API
선제적인 모델링
라이브 데이터를 모사할 수 있다
ex) 상품 전시 목록 : 현실적으로 보여야 하는 데이터
데이터 스트럭처를 미리 시뮬레이션
💬 신사업이나 스타트업 분야라면 신규 개발, 웹뷰, 웹앱에 대한 이해는 필수인 것 같다. 사전 지식이나 이해도가 없으면 커뮤니케이션 시 혼선이 크다. 금일 강연을 들으니 과거에 힘들었던 이유는 사실.. 태도의 문제가 아니라 지식이나 정보의 문제였음을 느낀다. 알면 더 잘 소통할 수 있었겠지.. 나의 무지함을 반성하고 성찰하기!
