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

최현호·2022년 8월 3일
패스트캠퍼스
0

FastCampus

목록 보기
2/2
post-thumbnail

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

1. 문제는 어디서 발생하는가?

협업과 제품을 만들어나가는 과정에서

1.1 프로덕트의 문제

  • Scale 이 커져가는 과정에서 주로 발생한다.(즉, 서비스의 규모가 어느정도 될 때)
  • 기업은 리소스가 제한적이며, 시간이 부족하다.

이는 스타트업와 일반기업 또한 크게 다르지 않다. 제한된 리소스와 부족한 시간은 둘다 같다.
그나마 차이점은, 스타트업은 시니어 엔지니어가 없는 경우가 주로 있고 실패 비용이 크게 다가오기도 한다.


1.2 제한된 리소스란

  • 인적 자원의 부족
  • 부족한 시간

이를 해결하기 위해서는 역랑 한계를 인정 하고 드러내야 한다.


1.3 리스크를 줄이기 위한 노력

  1. 필요없는 기능 최대한 배제 -> MVP 에 집중
  2. 클린 코드에 집착 X -> 동작하는 코드가 가장 가치있는 시기가 있다.

1.4 MVP 란

“Minimum Viable Product”, 즉 최소 기능 제품의 줄임말. 최소한의 기능을 가진 제품이라는 뜻이다.

참고 : https://www.itworld.co.kr/t/61023/%EA%B0%9C%EB%B0%9C%EC%9E%90/212179


1.4.1 서비스 관점의 MVP

  1. 개발자가 판단한 MVP가 정답인지 의심하라.
  2. 직관이 통하는 세계가 존재함을 인정하라. 직관은 과학이 아님을 인정하라.
  3. 개발자의 역할은 직관의 실패 리스크를 최소화하며 피봇할 수 있게 지원하는 것이다.

1.4.2 기술 관점의 MVP

  1. 어떤 기술이 적정기술인가?
  2. 최대한 포기하라, 포기할 것과 포기하지 못하는 것을 분류하고 검토하라.
  3. 기술보다 중요한건 속도다. 언제나 서비스의 생존이 최우선이다.

2. 웹을 설계하는 방식

2.1 환경(mobile이든, pc이든)에 무관한 고려사항

  • 웹의 철학과 특징을 고려하기
  • 기술이 서비스 성공의 촉매 역할이 될 수 있다.
  • 모든 것이 공유될 수 있는 자원이 될 수 있다.
  • 외부 서비스 연동 정보를 정리하여 관리하기

2.2 디자인과 디테일한 UX/UI

  • 신규 서비스의 어설퍼 보이는 UX는 좋은 이미지를 만들 수 없고, 가치가 하락한다.
  • 발빠른 테스트와 릴리즈를 위한 아키텍처를 처음부터 고려하기
  • UX의 견고함과 기능이 경합을 벌이면 견고함을 선택하기

2.3 최신기술을 사용하기

  • 레거시 없는 서비스라는 장점
  • 낮은 브라우저 버전에 목매이지 않기

    레거시는 낡은 기술이나 방법론, 컴퓨터 시스템, 소프트웨어를 말합니다.


 

2.4 사용자 로그를 수집하고 분석하기

  • 로그는 필수, 초기부터 로그를 수집하는 것이 좋음

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

현대의 서비스는 대게 앱을 중심으로 서비스를 운영한다.
앱은 안드로이드와 IOS 양강체제 -> 2개의 환경이 제공하는 것을 통해 개발하는 것이 native app
하지만, Native app 형태로만 개발하기에는 많은 비용이 필요하기에 웹 기술을 활용한 하이브리드 형태가 많이 시도되고 발전되어 왔다.

대부분의 앱은 네이티브 앱 아키텍처에 기반한 웹 기술을 섞어서 사용하고 있다.
그 중 하나가 웹 뷰


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

  1. 네이티브 컨테이너 + 단일 웹뷰
  • 앱스토어 규약 위반 가능성, 네이티브 기능을 탑재해야 함
  • 모바일 웹 채널을 운영하고 있고 빠르게 앱을 출시하기를 원할 경우 유용
    ex) 푸시, 카메라, 네이티브 인증(페이스 타임, 지문 인식 등)
  1. 네이티브 + 멀티 웹뷰
  • 웹 뷰간 데이터 교환 방법을 초기부터 고안해야 함
  • 앱에 저장소를 만들고 웹 뷰에게 인터페이스를 제공
  1. 네이티브 + RN
  • 변화가 많은 지면은 RN 으로 개발, 그 외의 지면은 네이티브 개발
  • 웹뷰 개발 시 존재할 수 있는 사용성 관련 이슈를 방지
  • 역량 있는 네이티브 개발자 필요

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

  1. 네이게이션 룰을 확립
  • 웹 페이지는 각각의 URL이 존재하지만 네이티브에서는 그렇지 않다.
  • 깊이가 깊은 화면에 직접 접근할 수 있는 방법을 초기에 설계해야 함(Deep Link)

    사용자가 어떤 상황에서도 direct 로 접근 할 수 있는 deep link 를 모든 화면에 설계 하는 것이 좋다.


  1. 공개용 웹뷰와 내부용 웹뷰를 분리
  • URL이 노출될 경우 보안상 문제가 생길 위험이 있는지 고려하여 웹뷰를 분리

  1. 보안을 고려
  • API 연동 토큰 및 앱 메타 정보 등 서버가 필요로하는 정보를 어떻게 관리할 것 인가

  1. 개발환경을 구축
  • 웹뷰 vs 브라우저, 시뮬레이터 vs 실기기의 차이점이 존재함을 인지
  • 개발 단계에서 개발자가 경험할 수 있는 환경을 미리 준비
  • 개발자간 쉽게 방법을 공유할 수 있도록 문서화하고 변경사항을 업데이트

  1. 런타임 오류를 수집
  • 특정 기기에서 발생하는 오류일 경우 개발자가 발견하기 어려움
  • 고객 입장에서 개발팀이 원하는 수준의 리포팅을 하는 것은 현실적으로 불가능

  1. 캐싱을 적극적으로 활용
  • 모바일 특성상 네트워크 상태가 불안정한 경우에도 동일한 사용자 경험을 제공
  • 프리젠테이션 컴포넌트는 독립적으로 운영
  • 아키텍처를 변경해야 할 여지가 있으므로 충분한 가치가 있는 작업인지 신중히 고려
  • 웹뷰의 생명주기를 알 수 있는 인터페이스 설계
    ex) 웹뷰가 캐싱된 데이터로 렌더할지 데이터 페칭이 필요한지 여부를 네이티브에서 제공

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

4.1 리스크 종류

4.1.1 커뮤니케이션

무엇이 문제인가 ?

  • 회의는 커뮤니케이션의 종료가 아닌 시작이다.
  • 문서를 보고 이해했다는 피드백은 진짜 이해한 것이 아니다.
  • 기획자, 디자이너, 테스트, 개발자는 생각하는 방식이 다르며 이는 자연스러운 것이다.

일반적인 개발 진행

브레인스토밍 -> 기획 -> 디자인 & 백엔드 개발 -> 프론트앤드 개발 -> QA -> 릴리즈

즉, 같은 문제에 대한 다른 이해는 자연스럽다는 것을 이해하는 것이 문제 해결의 시작이다.
그러나 이해한다고 해서 모든 문제가 해결되는 것은 아니다.


4.1.2 해결책

1. 프로젝트 사전을 만들고 지속적으로 운영하며 공유

프로젝트 사전?
1. 압축된 용어는 의미를 포괄
-> 전문적인 일을 할수록 압축된 용어로 커뮤니케이션 비용을 줄인다.
2. 합의를 이루어 용어와 의미의 관계를 1:1 로 만든 사전을 만들어 운영
-> 사전에 당연해 보이는 용어조차 생략해선 안되며 모든 용어가 존재해야 한다.


2. 프로토타입을 만들어라 ( 작동 시켜라)

  • 정적인 것은 상상력을 자극한다. -> 즉, 다양한 해석을 낳는다.
  • 제품 개발 전반의 과정 중 70% 를 정적인 결과물을 기반으로 커뮤니케이션 된다.
  • 수 많은 프로토타입 개발 도구가 있다. ( 적극적으로 활용 하자 )

동작하는 제품만이 오해를 막을 수 있는 유일한 방법이다.


프로토타입에 대한 오해

  1. 프로토타입은 POC 가 아니다.

    POC ?
    새로운 프로젝트가 실제로 실현 가능성이 있는가, 효과와 효용, 기술적인 관점에서부터 검증을 하는 과정을 의미
    출처: https://engineer-mole.tistory.com/35 [매일 꾸준히, 더 깊이:티스토리]

  • 프로토타입에 사용한 코드를 프로덕션 코드로 가지고 가지 말아야 한다,
    -> 프로토타입에 코드가 사용될 필요는 없다.
    -> 중요한 것은 동작하는 결과물이다.

  1. 디자인이 나온 후 프로토타입을 만든다.
  • 프로토타입은 가능하다면 모든 단계 만들어야 한다.
  • 이상적이라면 프로토타입의 결과가 기획서, 디자인 이어야 한다.
    -> 디자인이 나왔다면 이미 프로토타입을 개발할 타이밍은 지나갔다.

  1. 프로토타입은 정적인 데이터로 만든다.
  • 프로토타입의 가장 빛나는 가치는 올바른 사용자 흐름 확인이다.
  • 화면을 정적인 데이터로 채우지 마라
  • 웹앱의 데이터는 네트워크를 통해 전달되며 네이트워크는 언제나 예외의 잔치다.
  • 서버 데이터를 이용하고 레이턴시를 프로토타입에 반영하라.

레이턴시란?
'잠복' 혹인 '대기시간' 이라는 사전적 의미를 가진다.
IT 에서는 컴퓨터가 원하는 결과물을 만들어 내기까지 발생하는 지연시간의 총합이라고 볼 수 있다.


  1. 프로토타입은 기획과 디자인을 위한 것이다.
  • 데이터는 구조(스펙)를 가진다.
  • 구조는 UI 를 구성하는 핵심 요소이다.
  • 백엔드 개발자에게 영감을 주어라

3. 네트워크를 묘사해라

웹앱은 네트워크 어플리케이션이다.

  • 화면과 하면 사이, 데이터와 데이터 사이에 비동기 상황이 존재한다.
  • 비동기 상황 처리의 단단함은 서비스의 품질에 직결된다.

5. 유지, 개선 관점에서의 리스크 관리

5.1 Legacy

레거시 시스템 은 낡은 기술이나 방법론, 컴퓨터 시스템, 소프트웨어 등을 말한다.
이는 현대까지도 남아 쓰이는 기술을 부르는 말일 수도 있지만, 더 이상 쓰이지 않더라도 현대의 기술에 영향을 주는 경우도 포함한다.
출처 : 위키백과

5.2 Legacy 를 대하는 자세

존중

  • 모든 코드는 릴리즈 되는 순간 레거시 코드다.
    -> 서비스를 생존시킨 레거시 코드는 존중받아 마땅하다.

비난 받아 마땅한 코드는 없다. 그러나 개선하기 힘든 코드는 있다.


5.3 개선하기 어려운 코드를 개선하기 위한 전략

시각화를 하자 -> 시각화 되지 않은 문제는 불만일 뿐이다.


5.4 레거시 코드 분석 실패의 이유

  1. 기술 난이도가 높은 코드
    -> 역량 한계를 인정하고 공개한 후 함께 해결책을 찾아라

  2. 잘못된 구조로 규모가 커진 코드
    -> 엔지니어의 역할은 깨끗한 코드를 깨끗하게 유지하는 것이 아니다.
    -> 개발자의 역할은 제품을 만드는 것이다.
    -> 좋은 코드는 좋은 제품을 만들기 위한 요소 중 하나일 뿐, 필수 조건은 아니다.

6. 소프트웨어의 생명주기

6.1 제품의 수명은 몇년일까

프론트엔드는 1년 이상 쓰이는 코드는 많지 않다.


6.2 안정적인 프로덕트를 위한 코드 구조와 관리

6.2.1 유형

-> 뒤섞이면 문제가 발생한다.

  • HTML
  • CSS
  • Code/Logic/Rule
  • Domain/Data/State
  • Effect

6.2.2 변형 주기

  • Design/Visual/Struct
  • Config
    -> 분리가 안 되어 있으면 서버가 바뀔 때마다 코드가 새로 배포되어야 한다.
  • Assets/Information
    -> 약관 같은 것들도 Information에 포함이 된다.

6.2.3 오너십

  • Library
  • Framework
  • Service

6.2.4 위치

  • Internal
  • External

참고

profile
최현호
현재 블로그 : https://choi-hyunho.com/
이전 포스트

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

0개의 댓글