Front-end Engineer

장현석

우아한 테크러닝 3기 React & TypeScript 정리
1회차
강의 목표
수많은 주니어들이 스스로 잘 하고 있는지 고민과 의문에 도움을 주고자 한다.
네트워킹에 대한 욕심이 커 보인다 (코드리뷰, 사수, 피드백)
코드 품질 아키텍처 적정기술
동작은 하지만 설계가 옳은 것인지
김민태님 소개
90년대부터 개발한 아재 개발자
저수준을 바닥부터 구현했던 시절
도구와 학습의 관계
이제는 도구를 잘 사용하는 시대가 왔다
TypesScript, React 등등…
어떤 도구를 쓰더라도 원천을 이해하는 것이 가장 잘 사용하는 것이다.
만든 사람의 의도 혹은 솔루션
이러한 흐름을 놓치게 된다면 불편함에 놓이게 된다.
도구는 도구일뿐 사용하는 관점을 발견할 수도 있는 것
언어를 배울 때 경력과 실력에 상관없이 가벼운 학습 후 막힐 때는 구글링에 의존하는 개발자가 많은 것 같다
최근에는 조금 길더라도 읽기 쉽고 명시적인 코드를 선호하는 흐름
React & TypeScript
Type Alias
타입에 별명을 통해 의미를 부여할 수 있다
컴파일과 런타임 구분을 잘하자
타입스크립트를 쓰면 런타임까지 보장된다고 생각하지만 그렇지 않다
Babel
React의 JSX를 트랜스파일링하는 역할을 한다
CRA
과거에는 웹팩부터 모든 설정을 직접 했었으나 미리 만들어진 템플릿을 사용할 수 있어진다
자신들만의 설정을 강요한다
개인적으로 프로덕션 앱을 만들때는 권장하지 않는 편이다
Eject는 너무 방대하기때문에 추천하기 어렵다
JSX
결국 React의 createElement문을 더 편리하게 사용할 수 있는 것 뿐이다.
React.StrictMode
React 개발을 하면서 생기는 문제 상황을 알려준다.
Redux
과거에는 이것만 사용할때가 있었다
굉장히 간단하지만 그 간단함 때문에 어려워하는 측면이 있다
단순한 기능만 제공하는데도 복잡한 걸 하려니 굉장히 어려워지는 것
불필요한 행동이 많다
MobX
Redux와 비교 대상이라고 보기 어려우며 대체품도 아니다
프로덕션 환경에서도 많이 활용되고 있는 상황이다
유연성이 주는 장점과 단점을 가지고 있다
Q & A
회사에서 앵귤러를 사용하다 보니 초조하다
앵귤러가 가진 철학과 방향도 충분히 좋다
개발자라면 앵귤러만 했어도 상황에 따라 리액트를 습득해서 잘하면 된다
Context API 사용해도 되지 않는가
너무 많은 의존성이 생기면 당연히 좋지 않다. 페이스북 개발팀에서도 안내하고 있는 사항
아직 주니어인데 앞으로 어떻게 공부해서 성장해야 할지 모르겠어요
주니어가 시니어보다 유리한 점은 시간이 많고 여유가 있다 초조해하지 말고 여유를 가지며 의도적으로 훈련하자
2회차
JavaScript
Function of JavaScript
함수는 값이며 모든 값은 대입될 수 있다.
함수를 인자로 받아 해당 함수를 반환하는 함수를 1급 함수라고 한다.
Closure
내부의 값을 캡처해놓는다
값을 보호할 때 사용한다
모듈 패턴이라고도 불리운다
새로운 형태에 현혹되지 말자 (어려운 개념)
심호흡을 하며 하나하나 분해해보는 용기를 가자
새로운 개념을 만드는 경우는 드물다
비동기 & 동기
사람의 생각은 동기인데 코드의 동작 방식은 비동기라 어렵다
똑똑한 사람들이 어려울 때는 안 어렵게 만드는 방법을 찾아보다
Callback Function
비동기 코드를 동기 코드처럼 동작하도록 만들어본다.
중첩 CallBack 지옥을 가질 수 있다.
Promise
내부의 스코프를 resolve를 통해 받아보는 것이 Closure와 같다
then 을 가진 인스턴스를 생성할 수 있다
Async & Await
async를 선언한 함수
await를 then처럼 사용할 수 있다
Q & A
우형에 들어갈 수 있는 방법은 어떻게 되나요
6개월마다 지원 가능합니다 도전!
나이는 보지 않습니다
FE 코테는 어떻게 준비할까요
다들 준비해 줍니다 편하신 대로 하세요
FE가 UI도 해야할까요? (CSS 해야하는지)
앙꼬 없는 찐빵입니다
세미콜론 안 쓰는 이유는?
귀찮은 일은 기계를 시킵시다
프론트 자격사항은 다양하다 백엔드는 어느정도까지 준비해야할지 팁이 필요합니다
기승전 스프링과 그 외에 CS와 몇몇 구현체를 학습하는 게 중요하니 기본에 충실하는 걸 잊지 말아야 합니다
브라우저에 대한 공부
크로미움과 V8 소스를 까봐야 한다
자신의 수준을 먼저 알아야 한다
주화입마에 빠지지 않은 전략이 필요하다
프론트 개발자에게 CS 역량은 얼마나 중요할까요
결국 다 필요합니다
꾸준히 합시다
사이드프로젝트를 만들어서 볼륨을 키워보고 단계마다 전략학습을 해봅시다
클로저가 있는데 커링을 사용할 필요가 있을까요
인자를 나누는 것
어차피 거기서 거기다. 클로저에 대한 이해가 부족해 보인다.
Redux
Flux 아키텍처 이후로 완전한 주류가 되었다.
VDom 알고리즘과 상호작용하기 좋은 구조다.
컴포넌트에서 상태를 바꾸지 못하도록 한다.
3회차
새로운 것을 습득할 때는 항상 공부할 것이 많이 보인다.
남들의 코드를 배우고 새로운 것을 읽히면 넓이만 추구하게 된다
이름만 잘 지어도 중간은 간다
JS의 객체는 원시 값보다 다루기 쉬운 구조다
WHY without 10년차 개발자 < WHY with 10년차 개발자 
WHY를 탐구하고 기본을 탄탄하게 다지자 => 몸값으로 증명
공식 문서를 자주 보자
React 기본 개념
React는 단일 Virtual DOM을 가진다.
DOM
HTML 요소를 JavaScript로 다룬다.
Virtual DOM
DOM을 JavaScript로 더욱 쉽게 다룬다.
React.createElement()
Virtual DOM을 만든다
ReactDOM.render()
Virtual DOM => Real DOM
React는 DOM에 의미를 부여할 수 있는 장점을 가진다.
React 컴포넌트에 무언가 넘기는 방법은 Children & Props뿐
React가 해주는 것과 트랜스파일러가 해주는 것을 구분해야 한다.
런타임 시점에서 일어나는 일과 컴파일 타임에 일어나는 일을 인지해야 한다.
성능에 문제가 없다면 일관성을 지키는 것이 굉장히 중요
React API
Class Component
완전한 객체 구조
라이프사이클 통제 가능
Function Component
과거에는 컴포넌트가 호출될 때마다 상태가 생성되어 상태를 유지할 수 없었다.
라이프 사이클 및 상태를 가질 수 없다
기본적으로 계속 재 호출하는 형태로 구현되어 있다.
Hook API
메커니즘을 이해하는 게 좋다
전역 배열로 관리되며 생성되는 순서에 맞춰 key로 부여 후 인덱싱
내부 코드를 모두 이해할 수는 없지만 컨셉적인 측면을 이해해야 도움이 된다
최상위가 아닌 부분에서 호출 => 전역 배열에 문제 발생 => 원치 않는 값 반환 가능
4회차
개발자의 소통
의사소통시 프로토콜이 어긋나는 경우가 특히 많다
쏟아내는 방식의 일방적인 소통은 좋지 않다
높고 낮은 이해의 수준보다 상대방과의 수준을 맞추는 것이 중요
상대방이 이해할 수 있는 레이어 파악이 중요
Generator
코루틴의 구현체
function*, yield 키워드 사용
Generator, Promise, Async & Await는 밀접한 관련이 있다
단순화된 일반화된 것들은 여러 방향으로 사용할 수 있어 어렵다
Redux-saga에서 사용됨
아키텍처
굉장히 거대한 것처럼 느끼지만 실제로는 작은 코드에서부터 시작
작은 코드에서부터 어떻게 아키텍처를 잡아갈지가 더 중요
거대해지기 전에 미리 쪼개자
Garbage Collector
엔진이 어떤 알고리즘으로 알아서 진행
Garbage
정리되지 않은 메모리
유효하지 않은 메모리 주소
Mark
객체의 참조를 찾는 과정
Sweep
Mark 되어있지 않은 객체들을 제거
Hook API
useEffect
렌더링 이후 내부 함수 호출
제어 불가능한 요소들을 주로 다룬다
실제 메모리에 관련된 것들을 해제해주지는 않는다.
Hook 자체는 Closure가 아니다.
하지만 Hook을 사용할 때 당연히 Closure 캡처
5회차
Redux
예측 가능한 상태 컨테이너로 상태 변화를 예측하기 쉽게 도와준다.
멱등성
수 회의 연산을 적용해도 같은 결과를 보이는 성질
Redux 로직을 실행할 때마다 결과가 다를 수 있는 경우가 존재 (비동기)
커링
함수 지연 호출 가능
인자와 인자 사이에 대해 개입 가능한 기법
Redux는 동기적 처리 흐름을 가진다
비동기 작업 처리를 위해 미들웨어 이용
미들웨어
Redux에서는 커링을 이용한다.
데이터가 처리 흐름 과정 중간을 거친다.
연결된 파이프 순서를 따르기 때문에 항상 같은 처리 흐름을 따른다.
Redux Saga
Side Effect event 관리
동작 메커니즘
Action => 비동기 처리 => Middleware => Dispatch
디자인 패턴
Observer
객체의 상태가 변화를 구독
의존성과 결합도가 높다
모든 객체 상태를 구독받아야 한다.
동기 방식
Pub-Sub
낮은 결합도
비동기 방식
몽기 페칭
실행 중인 코드의 일부분을 런타임 상태에서 바꾸는 기법
함수도 값이기 때문에 다른 객체의 메서드를 가져와 자신의 것처럼 사용
메서드를 선언 시점이 아닌 사용 시점에 확장하는 것
공식문서
처음에는 무조건 봐야 한다.
1회 완독했다고 해서 이해된 것이 아니다.
대략 1/3 이해한 정도
수많은 맥락과 배경지식을 전제로 하는 암묵적인 개념 파악 필요
6회차
훈련 방법
엔진을 만드는 사람과 개발을 하는 사람 모두 알아야 하는 정보
어떠한 목표로 무엇을 배우고 있는지 항상 레이어 화해서 불필요한 학습시간을 최대한 줄이는 것이 좋다.
Webpack
전부 Node에서 실행
프로젝트의 구조를 분석하고 모듈 & 리소스들을 묶고 패킹하는 모듈 번들러
Loader (컨버팅)
미들웨어와 같은 역할
Plugin (후처리)
loader보다 더 복잡하고 많은 일을 처리할 수 있음
보통 loader가 모두 실행된 후 실행
컴파일
사람이 읽는 코드를 기계어 코드로 변환
트랜스파일
사람이 읽는 코드를 사람이 읽을 수 있는 코드로 변환
7회차
Promise
일종의 상태 머신이자 도구, 그리고 인터페이스
then 체이닝을 통해 작업을 연결할 수 있다
리액트를 사용하는 이유
개발하는 재미
사용하는 개발자들이 많음
높은 자유도와 취사선택
컴포넌트 구조
상태에 의존적인 컴포넌트와 그렇지 않은 컴포넌트 분리
비즈니스 로직
상태를 변경 시 상태에 대한 출처와 선택을 포함하는 코드들로 단지 props로 내려받는 것과 전혀 다름
Atomic Design Pattern
너무 조립적이다
유연성이 떨어진다
조직의 상황에 맞게 해야 한다.
구분의 기준
외부와의 관계를 어떻게 가지는지
외부와의 흐름을 어떻게 가지는지
컨테이너
데이터를 전달하는 역할로 로직을 포함
여러 하위 컴포넌트들을 결합
하나의 페이지를 구성
페이지와 1:1 or 1:N 구성 가능
UI 혹은 스타일 상태를 가지지 않는다
일반 컴포넌트
순수하게 역할에 맞는 렌더링 
웬만하면 로직 없는 곳
코드 스플리팅
초기 로딩 최적화를 위함
화면을 뿌리는 단위
SSR
서버의 부하 고려
트래픽 및 인스턴스 고려
백오피스 구조
스케일은 크지만 복잡도는 낮은 케이스
폴더 구조
폴더 구조 자체가 디펜던시이다
바깥쪽에서는 네이밍으로만 소통하도록 해보자
Maybe Component
Conditional Rendering 이용시 삼항연산자의 떨어지는 가독성 최소화
TypeScript
컴파일 타임에서의 검사이지 런타임에서 타입 검사를 하지는 않는다.
Type Alias vs Interface
기능적으로는 굉장히 유사
개인적으로는 props => Interface / 그 외의 내부 데이터는 Type Alias
Interface
외부에 노출시켜주는 느낌으로 사용
Type Alias
상태를 규격화
Generic
여러 타입에 유연하게 대응
Q & A
개발자는 많지만 쓸만한 개발자는 없다
과한 패턴에 대한 집착은 유연성을 잃게 만든다
Redux는 MVC에 적합
MobX는 MVVM에 적합
포트폴리오는 주로 코드만 확인한다
이력서의 경력기술서로 실력을 검증할 수 없다.
구조에 대한 고민
상태에 대한 고민
마크업을 잘할 수 있다고 말할 수 있는 조건
시멘틱에 대한 이해
2D화면에서 Geometry의 이해
나누는 것은 관심사의 분리로 생각하는 것이 좋다
새로운 기술을 공부하는 방법
공식 문서 정독이 기본
이해하지 못한 것과 이해한 것들을 확인하는 과정이 필요
8회차
Router
URL과 Component를 매칭시켜준다.
Hash Router는 잘 사용되지 않는다.
MobX
Observable, Observer 등의 용어가 학습을 매우 힘들게 한다.
Primitive 타입의 변경은 알 수 없다.
Singleton 패턴을 자주 사용
autorun
상태가 바뀌면 내부의 함수 호출
Action
논리적인 작업 단계
Flow
비동기 작업
MobX vs Redux
Redux
개인적으로 선호한다
MobX
실수하기 쉬운 환경을 제공한다
쉽지만 블랙박스 같은 느낌이 있다
무언가 분석할 때는 가장 만만한 녀석들부터 분석한다
테스트
성공하는 테스트
반드시 성공해야 한다.
실패하는 테스트
반드시 실패해야 한다.
규모가 커질수록 복잡도가 늘어진다면 의존성 문제다
마무리
원래 오프라인 30명 정도를 선발하려했 으나 코로나 때문에 500명가량을 선발했다고 한다.
(애매한 중니어 경력이라 운이 좋게도 참석할 수 있었다)
김민태님의 강의는 언제나 견문을 넓히는 좋은 조언을 들을 수 있어 좋다.
기술적인 이해나 접근보다는 내가 했던 고민과 앞으로 할 수 있는 고민에 대해 또 다른 시각으로 바라볼 수 있는 계기가 되어 매우 값진 시간이었고
코로나가 나아진다면 오프라인에서 또 다시 좋은 기회가 있기를 바란다.
관련 링크
https://gist.github.com/ibare/1ed63de0c09c94a7ac79713d57b80f8d
https://gist.github.com/ibare/c736f63fba835c172e60aa98a996dada
https://gist.github.com/ibare/c7020756170aa7ed3d1cc84f86972409
https://gist.github.com/ibare/0eb8597551070bf1ebf8e797439913a3

우아한 테크러닝 3기 React & TypeScript 후기

댓글