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

우아한 테크러닝 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