[패스트캠퍼스] 김민태의 React와 Redux로 구현하는 아키텍처와 리스크관리 (2-2)

productuidev·2022년 7월 18일
0

FE Study

목록 보기
43/67
post-thumbnail

김민태의 React와 Redux로 구현하는 아키텍처와 리스크관리(2)

패스트캠퍼스 The Red

2. 안정적인 프로덕트를 위한 아키텍처 설계와 리스크 관리

3) 웹뷰 개발을 설계하는 방식

현대의 서비스들 - 앱 서비스
앱 위주의 서비스에서 어떤 것을 고려해야하는가
앱을 만들기 위한 기술은 다양하게 존재함

구글 Android vs 애플 iOS
생각해볼 점 : 순수한 네이티브 앱이란 존재하는가?

모바일앱 초창기
네이티브 앱 구현 비용 높음
하지만 대부분 대외비이기 때문에 실제로 어떤 기술로 구현되었는지는 회사마다 다름

네이티브 앱 패키징 아키텍처

But 모든 화면을 다 앱으로 만드는 것은 어렵다
규약, 심사, 출시일정, 구현비용 이슈
많이 고려되는 방식 - 웹뷰 웹앱

🔎 네이티브 컨테이너 + 단일 웹뷰

riskmanagement01

🔎 네이티브 + 멀티 웹뷰

riskmanagement02

ex) 상품, 주문 페이지 - 일반 사용자 입장에서는 분간이 어려울 정도로 잘 구현

🔎 네이티브 + RN

riskmanagement03
  • 사용성, 퍼포먼스 이슈 없이 민첩한 사용 경험
  • 스타트업에서 많이 고려하는 방법
  • 웹 프론트엔드 개발이어도 역량있는 네이티브 개발자가 적어도 1명은 필요하다 (crush 방지)
  • React Native와 혼용하여 개발
  • 다만 RN은 아예 아키텍처가 다르므로 하이브리드로 구현하더라도 프로젝트 구조가 나중에 변경되어 발생하는 cost 방지를 위해 구성을 애초에 RN으로 시작하고 이후 앱과 관련된 공통화면을 구현하는 방식으로 접근해야 개발 효율을 높일 수 있다
    ex) 인스타그램 (RN가 담당하는 view가 대부분)

⭐️ 앱 패키징 아키텍처와 무관한 고려사항

  1. 네비게이션 룰을 확립하라
  • 특정 화면의 직접 랜딩을 위한 앱 스킴 디자인
  • 네비게이션 룰, 딥링크 스펙 설계의 중요성
  • 앱 배포되면 아예 그 버전이 스토어에 박제됨 (업데이트 하기 전)
  • 강제 업데이트하게 하는 결정 시 비즈니스 입장에서는 버릴 수 없는 사용자
  • 버전과 관련된 피처, 확장성 고려한 유연한 대처
  1. 공개용 웹뷰와 내부용 웹뷰를 분리하라
  • 이벤트 페이지 URL - 브라우저 다이렉트 노출
  • 보안을 고려하라
  • API 연동 토큰 및 앱 메타 정보 등 서버가 필요로 하는 정보를 어떻게 관리할지 고려
  • 노출되면 안되는 정보를 초기부터 분리
  • 서버를 나누고 잠재적인 보안 이슈 해결
  • 다만 2개의 서버 운영 비용 발생하는 부분은 있음
  1. 개발 환경을 구축하라
  • 웹뷰와 데스크탑 브라우저는 다르다.
  • 같은 기기 내 웹뷰, 브라우저 등도 차이점이 존재한다.
  • 시뮬레이터와 실제 디바이스에서 작동하는 것도 차이가 존재한다.
  • 각각에 대해 개발자가 경험할 수 있는 환경을 미리 준비하고
    개발자 간 쉽게 방법을 공유할 수 있도록 문서화하고 변경사항을 업데이트한다.
  1. 런타임 오류를 수집하라
  1. 캐싱을 적극적으로 활용하라
  • 캐싱 : 네트워크를 통해 서버로부터 불러온 데이터
  • 네트워크가 안될 때에 화면이 안 나온다면
  • 캐싱된 데이터와 서버 패치 데이터의 자연스러운 전환을 고려한 UX를 설계하라
  • 참고자료
    사용자 경험과 성능 개선 방법 in 카카오웹툰
  1. 웹뷰의 라이프사이클을 인지할 수 있는 인터페이스를 설계하라
  • 네이티브 앱이 웹뷰를 로드 시킬 때 첫번째 로드 후 다른 네이티브 화면에 가려져서 안 보이는 경우
    ex) 탭바 : 사용자가 다시 화면에 들어올 때 페치된 화면
  • 네이티브 앱만 인지할 수 있는 화면
  • 웹앱에서 인터페이스 재사용 (업데이트 할 필요 x)
  1. 모바일웹에서의 접근성 고려하라
  • 사용자가 점차 늘어났을 때

4) 신규 개발 관점에서의 리스크 관리

제품을 처음 개발하게 되면 발생하는 다양한 리스크

커뮤니케이션
Soft Skill (소프트 스킬)
추상적인 기준 - 좋다? 나쁘다? (상대적인 개념)
riskmanagement04

커뮤니케이션, 무엇이 문제인가
riskmanagement05 riskmanagement06
그래서 어떻게 하란 것인가
riskmanagement07

프로젝트 사전 - 일관된 용어, 컨텍스트 맥락, 합의된 사항 공유 (초기부터)

riskmanagement08

프로토타입 - 동작하는 시제품
동작하는 제품만이 오해를 막을 수 있는 거의 유일한 방법
각자가 생각했던 것과 실제 구현된 것의 정보 차이를 줄이기
감정 쌓임 - 제품 퀄리티 영향
브레인 스토밍 단계에서부터 서로 의견 공유 필요성

riskmanagement09

POC : Proof-of-Concept

참고자료

riskmanagement10

ex) 회원가입 - 이 동선은 효율적인가?
동선을 확인하기 위해 프로토타입을 만드는 것

riskmanagement11

데이터를 서빙받는 상황 - 딜레이 - 동선 - UX
동적인 데이터 : 프론트엔드를 시각적, 정적으로만 한정하지 말 것

riskmanagement12 riskmanagement13

Mocking API
선제적인 모델링
라이브 데이터를 모사할 수 있다
ex) 상품 전시 목록 : 현실적으로 보여야 하는 데이터
데이터 스트럭처를 미리 시뮬레이션


💬 신사업이나 스타트업 분야라면 신규 개발, 웹뷰, 웹앱에 대한 이해는 필수인 것 같다. 사전 지식이나 이해도가 없으면 커뮤니케이션 시 혼선이 크다. 금일 강연을 들으니 과거에 힘들었던 이유는 사실.. 태도의 문제가 아니라 지식이나 정보의 문제였음을 느낀다. 알면 더 잘 소통할 수 있었겠지.. 나의 무지함을 반성하고 성찰하기!

profile
필요한 내용을 공부하고 저장합니다.

0개의 댓글