교육/원티드 프리온보딩 챌린지

[원티드 프리온보딩 챌린지 2월] Week 2-1 Safety Application for TypeScript - 강의 후기

알파카털파카 2023. 2. 14. 15:54

Week 2-1 Safety Application for TypeScript

Type Guard

 

 

강의를 들으면서 내가 프로젝트를 진행할 때 사용하던 것들이 이런 명칭을 가지고 있구나 하는 것을 깨닫기도 했다. 나도 모르게 익혀서 사용하는 것일 수도 있지만, 제대로 된 이해 없이 무작정 코드를 치고 있던 것은 아닌가 되돌아보게 되었다. 이번 강의는 용어들이 어려워서 지금까지 3번 진행된 TS 강의 중 가장 난이도가 높게 느껴졌다. 과제 또한 이번에 다 못하더라도 언젠가 꼭 해봐야겠다.

 

 


 

 

1. 동적 타입과 정적 타입

타입 체커가 컴파일 타임에 수행되는지, 런타임에 수행되는지 여부

 

자바스크립트는 인터프리터를 기반으로 한 동적 언어이다.

타입스크립트는 컴파일 언어이다. 컴파일은 ts파일을 js파일로 변환하는 것이다. 컴파일 된 이후 실제로 코드가 돌아가는 것이 런타임이다. 

 

퀴즈

다음 두 가지 퀴즈를 풀고 답을 적어보라고 하셨다. 이 내용은 마지막 시간에 다루기로 했다.

Quiz 1. tsserver가 왜 있는가?

Quiz 2. 컴파일러는 무엇을 할까?

 

 

 

 

2. 건전성

다음 문장을 여러번 읽어보자.

건전함의 반대인 불건전함(Unsoundness)은 런타임에 문제를 유발할 수 있지만 타입스크립트는 일부 불건전한 동작을 허용한다.

 

불건전한 동작에 대해 허용한 것은 다음과 같다. 

  • any
  • as 타입단언
  • Non-null assertion operator

 

⚠️ 자소서에 '안정성을 위해 타입을 유용하게 사용합니다' 라고 해놓고 기업과제에서 이런 식으로 제출하면 안 된다. 

타입 단언은 사용자가 타입을 가장 잘 알고 있다는 것을 명시하는 방법이다. 비유해서 말하자면 타입스크립트에게 가스라이팅 하는 것이라 보면 된다. 옵셔널 체이닝의 경우 타입 가스라이팅이다.

Non-null assertion operator의 경우에는 HTML DOM을 다룰 때는 어쩔 수 없다. ref를 사용하면 컴파일 전까지는 어떤 DOM을 가리키는지 알 수 없기 때문이다. 그렇다고 해도 ?를 많이 사용하고, !는 쓰면 안 된다. 공중 화장실을 예시로 들자면, ?는 사람이 있는지 체크하는 것이고, !는 확인 없이 문을 확 열어버리는 것과 같다. 

라이브러리에서 타입스크립트와 친하지 않다고 공식적으로 써있을 때 불건전한 동작을 쓰는 것은 괜찮지만, 그 외는 최대한 줄이는 것이 좋다. 나중에 문제가 생길 수 있기 때문이다. 빌드타임에 터지거나, tsserver에서 안 터졌지만 컴파일에 터지거나 할 수 있다.

 

건전성 

컴파일 타임에 알기 어려운 특정 타입을 안전하게 허용하는 것을 의미함

  • 즉 컴파일러가 런타임 시점 값의 타입을 보장할 수 있다는 개념
  • 모든 JavaScript 코드를 지원하기 위함
  • 건전한 언어는 데이터가 타입이 말하는 것과 일치하는지 확인하기 위해 때때로 런타임 검사를 사용
  • 타입스크립트는 변환된 코드가 런타임에 영향을 미치지 않는 것을 목표로 한다.

 

라이브러리

타입과 친하지 않은 라이브러리 중에는 리덕스 사가가 있다. 리덕스 사가는 타입호환이 잘 되지 않는다.

https://github.com/redux-saga/redux-saga

리덕스 사가의 깃허브 이슈에서 타입스크립트를 검색하면 여러 건이 나온다. 타입과 친하지 않아서 타입 단언으로 범벅이 된다고 한다. 그래도 지금은 타입이 어느정도 추가되어있는 것을 볼 수 있다.

https://github.com/redux-saga/redux-saga/blob/main/packages/types/types/ts3.6/index.d.ts

redux-saga README
redux-saga

 

타입스크립트 공식 사이트 하단의 code sample에서도 soundness를 찾아볼 수 있다. 타입스크립트에서도 건전성(soundness)를 주요한 개념으로 다루고 있다.

https://www.typescriptlang.org/

타입스크립트 공식 홈페이지

 

 

 

 

3. 타입 가드

타입 가드는 타입스크립트 학습에서 가장 중요한 것 중 하나이다.

in 연산자는 JS 문법이지만 TS도 사용 가능하다. 데이터 타입이 기본형일 경우 typeof 연산자, 객체일 경우 in 연산자를 사용할 수 있다. in 연산자를 사용하면 타입을 강제하지 않아도 된다.

is 문법은 TS 문법이다. typeof, instanceof는 JS 문법이고, TS 관점에서 쓰고싶으면 in, is 연산자를 사용하자.

 

타입스크립트를 사용하는 방법

⭐️ TS를 사용할 때 3가지 방법으로 사용할 수 있다.

  • 런타임 - 타입가드(더 있을수도)
    • 리액트에서 하는 방법 : ref, prop types(런타입 체킹), mobx (MST - 런타입 체킹)
  • IDE - 타입체커(ts server)
  • 컴파일 - tsc → (로더) js와 d.ts로 분리
    • 바벨, esbuild, ts 등 

TS는 왜 런타임에 타입이 결정되도록 허술하게 허용할까? 이는 불건전성 때문이다.

 

과제

타입스크립트 공부 방법으로 추천해주신 사이트를 10단계까지 풀어보는 것이 이번의 과제이다. 최대한 많이 풀고 해설을 달아보라고 하셨다.

https://typescript-exercises.github.io/

런타임을 위한 문제이며 에러를 없애면 통과한다. 최소 9-10단계까지는 풀어야 타입스크립트를 사용한다고 말하고 다녀도 된다고 하셨다.

 

 

 

 

4. Q&A

이번 시간에도 좋은 얘기들이 많이 나왔다. 그 중 몇 가지만 추려서 적어본다.

 

이력서

자신감 있게 성과를 적되, 허세부리지 말자

 

신입이라는 내용을 드러낼 필요가 없다. 진행 중, 공부 중, 수정 중 등의 단어는 회사 측에서 안 그래도 내키지 않는 신입 채용을 더욱 내키지 않게 만들 뿐이다. 그렇다고 허세부리지도 말자. 풀스택, '스타트업에 미쳐있는' 등의 단어를 사용하며 거부감드는 허세를 부리지 말자. 스킬트리에 별점 매기는 방식도 지양하자. 

배운 점, 학습한 점, 회고 등의 방어기제 대신에 성과로 바꿔서 적도록 하자. 프로젝트의 오류나 치명적인 내용을 적어놓으면 대놓고 단점, 약점을 드러내는 것이다. 어떤 것을 공부해서 적용해봤다는 내용도 필요 없다. 성과로 보이는걸 적어야 한다. 기능 정도만 적고 면접 질문에 답변을 잘 하면 된다. 어려운 점을 적고 싶다면, 에러를 해결했다는 식으로 어려움을 해결한 쪽으로 풀어내는 것이 좋다. 결과가 있어야 한다.

포트폴리오는 깃허브로 설명이 가능하다. 유명 부트캠프 저장소를 모두 참고하자. 어차피 모두 Public 접근이 가능하다. 우아한테크코스, 우아한테크캠프, 네이버 부스트캠프 등을 참고하면 좋다.

 

번아웃 극복 

번아웃을 극복하지 못하더라도 회복 탄력성을 이용하면 된다.
대신에 번아웃이 온 상황의 내가 앞으로의 내 자신이면 안 된다.

 

번아웃이 올 수도 있고, 극복하지 못할 수도 있다. 오래 쉬어본다든지 하는 극복방법이 모두에게 적용되는 것도 아니다. 그래도 괜찮지만, 번아웃이 왔다고 하더라도 그 상태로 고착화된 모습이 나의 미래이면 안 된다.

 

채용시장

채용시장이 어렵다는 얘기를 해주셨다. 네이버조차도 채용이 클로즈되어 프론트엔드 개발자를 뽑고 있지 않았다. 유독 프론트엔드 부트캠프가 많고 공급이 많아져서 취업이 어려운 상태라고 한다. 이는 3-5년차 주니어 개발자도 마찬가지였다. 애초에 열린 채용 자리조차 별로 없었다. 공부하면서 개발자로서의 첫 취업을 준비하는 입장에서는 막막한 얘기였다. 기회가 올 때 잡을 수 있도록 평소에 준비를 잘 해두는 것이 최선이지 않을까 생각한다.