'THE RED: 김민태의 React와 Redux로 구현하는 아키텍쳐와 리스크관리' 후기 - 강의내용요약

최근 OAuth, OpenID Connect 등을 조금 커스텀하게 구축하며 프론트엔드의 환경, Redirect, Cookie, Security 등과 관련된 사항을 살펴보게 되었습니다.

 

작업을 진행하며 좀 더 프론트엔드의 구조와 기능을 공부할 필요성을 느꼈는데요.

 

큰 관점의 서비스 이해는 물론, 백엔드 개발에도 도움이 될 수 있을 것 같았습니다. 일반적인 프론트엔드 기술강의(React, JSP?, Angular, Android 등)은 겉핧기로 만들어 본 적은 있었지만, 전반적인 실무의 경험에 대한 학습이 필요하다 생각되었습니다.

 

이 글에서는 그러한 목적을 위해 사비로 수강하게 된 패스트캠퍼스 강의내용을 요약해보려 합니다:

 

1. 프론트엔드 개발자가 갖춰야할 역량

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

3. React & Redux 이해하기

 

---

프론트엔드 개발자가 갖춰야할 역량

Web Front End란?

web: 개방형이라고 하지만 모두 벤더 디펜던시가 있다. 이러한 공룡들의 방향성을 이해하면 기술의 방향성을 알 수 있음.

front: 사람이 사용하는 것의 앞에 있음. 시각적 요소가 많고 그렇기에 주관적인 부분도 많음. 개발자가 기술만 알고 있다고 해서 뛰어나다고 평가받지 않을 수 있으며 UX와 같은 부분들도 많이 고려됨. 빠른 변화.

end: 프로세스적 관점에서 기획 -> 디자인 -> 백엔드 -> 프론트와 같은 사이클의 끝에 있음. 릴리즈 일자를 선정하나 계획이 변경되고 앞선 부분에서 기간이 조정될 때에 프론트가 많은 부담을 받게됨. 

 

과거, 현재, 미래의 Front End

1992: http의 탄생과 같이 웹이 시작됨.

2007: 아이폰의 탄생, 모바일 생태계로 중심이 이동함 (1년 뒤, 앱스토어를 선보임).

2008: 구글 크롬이 출시되며 V8 엔진을 선보임. 웹이 발전해야 하는데 가장 병목은 브라우저의 JavaScript 실행 부분이었음 (V8 엔진). 

2009: JavaScript를 일반 시스템에서 실행하기 위해서 빠른 V8 엔진을 사용한 node JS를 만듬 (지금의 프론트엔드 환경을 만들었다고 평가할 수 있음).

2010: node 패키지 매니저인 npm의 등장 (08 ~ 10의 변화가 이후의 FE 10년의 환경의 기반이 됨). Angular과 knockout JS의 탄생 (이전의 WebApp은 jquery로 만들던 시절이었으며, Angular가 나오며 라이브러리 단계에서 프레임워크로 발전시킴, 보다 큰 앱을 단단하고 아키텍쳐를 가지고 설계될 수 있도록 하였음, knockout JS는 데이터 흐름을 라이브러리나 프레임워크 단계로 내릴 수 있는 설계를 제시함 - Two-Way Binding).

2012: TypeScript 출시. 

2013: React 출시. Angular가 Two-Way binding의 장점과 동시에 단점이 부각되었으며 React는 대비적으로 One-way binding의 장점을 살림 (Virtual DOM 등과 같이). 

~2020: React, VueJS가 주류로 사용됨. 안정화되기도 하고 지루한 시기. 

최근: deno가 가져올 변화 (TypeScript가 더 잘 적용될 수 있는 부분 등). 

 

 

 

 

Front End 개발자 유형

- System에 대한 지식이 있는/없는 개발자

- Graphics에 대한 관심이 있는/없는 개발자

- UX에 관심이 있는/없는 개발자

 

Front End 개발자의 학습 전략

- 모두 알아야하는 지식: Network, memory, performance

- 필요한 상황이 생기면 알고 싶지만 쉽게 배울 수 없는 지식: Graphics, Math

- 필요하다면 쉽게 배울 수 있는 지식: JS, React, TS

 

다수가 중요하다고 생각하는 것을 이루기 위한 전략

- share, teaching, feedback

- balance

 

 

 

안정적인 프로덕트를 위한 아키텍쳐와 리스트 관리

프로덕트의 개발 환경

프로덕트의 문제는 어디서 발생하는가?

- scale

- 기업은 제한된 리소스 상태 (스타트업은 시니어, 실패비용 등에서 조금 다를 수 있으나)

 

어느 리소스가 부족한가?

- 인적자원

- 역량 한계 인정과 드러내기에서 적절한 리소스 판단이 수행될 수 있음

 

어떤 것이 리스크인가?

- 리소스를 넘는 프로덕트 

- MVP에 집중하기 (서비스 관점, 기술 관점)

- 초기 클린코드에 집착보다는 동작하는 코드에 집중

 

웹 개발을 설계하는 방식

Mobile first하의 Browser와 App(native, webview)

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

- 웹의 철학과 특징을 고려하기

- 기술이 서비스 성공의 촉매 역할이 될 수 있다.

- 모든 것이 공유될 수 있는 자원이 될 수 있다.

- 외부 서비스 연동 정보를 정리하여 관리하기

 

디자인과 디테일한 UX/UI

- 어설픈 UX는 좋은 이미지를 만들 수 없다

- 발빠른 테스트와 릴리즈를 위한 아키텍처를 처음부터 고려하기

-  UX의 견고함과 기능이 경합을 벌이면 견고함을 선택하기

 

최신기술을 사용하기

- 레거시 없는 서비스라는 장점

- 낮은 브라우저 버젼 버리기

 

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

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

- 로그 분석 인프라를 마련하고 지속적으로 발전시키기

 

 

웹뷰 개발을 설계하는 방식

현대의 서비스는 보통 앱을 중심으로 서비스를 운영함.

앱은 안드로이드와 IOS 양강체제로 2개의 환경이 제공하는 것을 통해 개발하는 것이 native app. Native app 형태로만 개발하기에는 많은 비용이 들었기에 웹기술을 활용한 하이브리드 형태가 많이 시도되고 발전되어 왔음. 대외적으로 어떤 기술을 썼는지는 대외비인 경우도 많아 알기 어려움. 

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

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

- 네이티브 컨테이너 + 단일 웹뷰: 앱스토어 규약 위반 가능성, 네이티브 기능을 탑재해야함 (푸시, 카메라, 네이티브 인증(페이스 타임, 지문 익식 등))

- 네이티브 + 멀티 웹뷰: 대부분의 모든 서비스가 사용하는 방법. 웹뷰간 데이터 교환 방법을 초기부터 고안해야 함. 앱에 저장소를 만들고 웹뷰에게 인터페이스를 제공하는 형태. 

- 네이티브 + RN: 변화가 많은 지면은 RN으로 개발, 그외의 지면은 네이티브 개발.

네이티브 부분에 있어서 역량있는 개발자가 한 명 정도는 있어야 발생하는 깊은 문제를 해결할 수 있는 경우가 많음. 

 

 

웹뷰 기반의 앱 설계 시 참고할 사항들

네비게이션 룰을 확립하라

- 앱은 웹과 달리 고유한 URL이 없기에, 사용자가 어떤 상황에서든 direct로 접근할 수 있는 deep link를 '모든 화면에' 만들어 두는 것이 좋다.

- deep link를 설계하는 방식은 여러가지가 있지만, (웹의 스펙과 동일한) 유니버셜 링크를 기본 구조를 가져가는 것도 좋다.

 

공개용 웹뷰와 내부용 웹뷰를 분리하라

보안을 고려하라

개발환경을 구축하라

런타임 오류를 수집하라

- 디바이스의 환경은 매우 다양하다 (특히, 안드로이드)

캐싱을 적극적으로 활용하라

웹뷰의 라이프사이클을 인지할 수 있는 인터페이스를 설계하라

프리젠테이션 컴포넌트를 독립적으로 운영하라

접근성을 언제나 고려하라

 

 

React & Redux

- https://github.com/kadensungbincho/Online_Lectures/tree/master/fastcampus/the_red_react_and_redux