TS에 대한 고민과 주관 (feat.원티드 챌린지)

(어떠한 코멘트던 환영입니다!)

 

 

🫐 경험을 통한 공부

---

몇 달 전 타입스크립트 공부하며  JS프로젝트를 TS로 리펙터링을 했었다. 리팩터링 할 당시 인풋과 아웃풋을 강제할 수 있다! 는 점은 경험했지만 대다수의 기업이 채택한 기술이라기엔 스스로가 설득될만한 효과는 아니었다.

(지금 돌이켜보면 타입을 도입해 에러만 잠재우기 급급하였고, 수정하지 않아야 할 부분까지 수정하는 잘못을 범했다는 것을 깨달았다. 타입을 설계로 해석하는 관점이 당시에는 없었기 때문이다.)

TS에 왜 그렇게 열광하는지 직접 경험하고 싶다는 생각 하에 원티드 1,2월 챌린지에 참여하게 되었고, 함께 타입스크립트 서적을 함께 공부하며 많은 ‘놀람’ 모먼트를 경험했다. 그 경험과 그 과정에서 했던 고민들을 공유하는 포스팅을 작성해보려 한다.

 

 

🫐 도구들 이해하는 새로운 접근: 설득의 과정을 보라!

---

2차 원티드 프리온보딩 챌린지와 함께 러닝 타입스크립트 책을 읽으며 도구를 이해하는 새로운 시각을 갖게 되었다.

TS개발자들은 JS개발자를 다음 3가지 특성 때문에 ‘TS를 사용해야 합니다!’라고 설득한다.

• 신뢰할 수 있는 결과(A Result you can Trust)
  TS 파일을 컴파일하면 타입이 저장된 파일 (d.ts)과 JS 문법으로 컴파일된 파일(JS) 두 개가 생성된다. 또한 타입 오류가 포함된 index.ts 파일을 컴파일했을 때 이상 없이 index.js가 생성된다. 컴파일된 JS 파일만으로도 타입스크립트는 자바스크립트 작동 방식을 전혀 변경시키지 않는다. 이는 기존 자바스크립트 개발자들을 Typescript로 쉽게 넘어오게 설득하기 위한 방법이라 보인다.
  
  
• 스케일링해도 안전함(Safety at Scale)
  자바 || C++와 같은 정적 타입 언어는 충돌할 수 있다고 판단되면 코드 실행 자체를 거부한다. 하지만 JS는 충돌 가능성을 먼저 확인하지 않고 실행부터 한다. 이 맥락에서 TS를 사용하면 코드를 실행하기 전 편집기 차원에서 예상 가능한 오류를 미리 알려주어 컴파일 이전 단계에서 오류를 잡아낼 수 있다. 한두 달 전 기존 JS 프로젝트를 TS로 리팩터링 하기로 마음먹었었고, 그 과정에서 느낀 이점과 동일했다. 불과 몇 달 전 JS로 작성된 코드를 정적 분석 없이 이해하는데 소요되는 시간이 꽤나 올렸기에 고생을 했다. 설계를 보고 쉽게 코드를 이해할 수 있다.
  
  
• 자바스크립트 혹은 그 이상 (JavaScript and More)
  내부적으로 VSCode도 TS로 개발된 만큼, VSCode는 TS와 같이 사용 가능한 훌륭한 편집기이다. 자동완성, 내장 타입 체커 등

TS를 사용하면서 사용했던 기능이 위 설득을 위해 만들어졌다는 이해를 했고, TS가 기존 JS 개발자들을 설득하기 위해 굉장한 공을 들인 도구라는 생각이 들었다.

 

 

🫐 정말 TS의 자유도와 통제권은 Trade-off일까?

---

자바스크립트는 빠르고 유연하다. 타입스크립트를 사용하면서 이 유연성이 구조와 타입에 얽매이는 것 같다는 느낌을 받았다. 저번 달까지만 해도 TS라는 도구는 자유도를 빼앗은 대신 우리에게 통제권을 넘겨준 언어라는 생각이 들었지만, 지금은 생각이 조금 바뀌었다.

• TS는 어떠한 디자인 패턴이나 아키텍처를 따르던, 그 구조를 처음부터 만들어 나갈 수 있다.
• 어떤 코드를 변경할 때, 그 변경된 코드와 변경된 코드로 인해 변경이 되어야 할 코드가 명시적으로 분리해 주기에 코드 변경에 자유도를 준다.

오히려 우리에게 원하는 결과를 안정적으로 도출할 수 있게 해 주고, 안전한 결과를 얻을 수 있다는 확신을 준다. 따라서 TS는 자유를 제한하는 언어가 아니라, 제한을 통해 자유를 주는 언어 (혹은 도구)라고 재정의 하고 싶다!

 

 

🫐 그래서 타입스크립트가 뭔데?

---

JS -> TS 리팩터링 프로젝트 당시에는 다들 말하는 “타입 안정성”이라는 효과가 크게 와닿지 않았다.

이번 챌린지를 통해 타입스크립트를 “설계” 관점에서 보며 “타입 안정성”이라는 효과가 와닿았던 것 같다.

자바스크립트로 일반 함수를 만들 때를 생각해 보면, 함수가 받아오는 인풋과 아웃풋은 함수를 생성하는 당시 개발자의 사고에 따라 유연하게 변경할 수 있다. 즉, 개발자에게 큰 자유도를 주는 언어이다.

이때 타입스크립트로 동일한 함수를 만드는 과정을 “설계” 관점에서 바라본다면, 개발자가 받아올 인풋과 아웃풋의 생김새를 미리 설계한 후 → 그 설계에 맞추어 함수를 만들게 된다. 즉, 타입스크립트는 개발자에게 설계에 맞는 개발을 강제하는 통제권을 부여하는 도구, 그 통제권으로 자유를 주는 도구로 해석할 수 있다고 생각한다.

 

 

🫐 Interface와 Type alias의 본질적인 고민

---

유사한 효과를 내는 각 방식을 언제 사용해야 할지를 각각이 선언되는 방식의 차이에 대입해 고민해 보았다.

타입과 인터페이스가 선언되는 방식에 차이가 있다. Interface는 객체를 사용하고, Type alias는 타입을 변수처럼 할당한다.

type Name = __
interface Name {}

내가 정의하는 객체는 세상의 복잡성을 간단히 표현하는 방식이다. Interface를 객체의 관점에서 바라본다면, 다음의 객체의 특성이 필요한 시점, 그때가 바로 Interface를 사용해야 할 시점이라고 생각한다.

• 상속이 가능한 [상속]
• 여러 형태로 재구성이 가능한 [다형성]
• 본질적인 공통적 특성만 보아 캡슐로 만든 [추상화]
• 복잡성을 단순화한 [캡슐화] - DRY (Don’t repeat yourself! 무의미한 반복은 금기시)

 

반면에, Type alias는 “모든” 변수, 객체, 함수, 클래스에 할당이 가능하다.

클래스 특성이 필요한 시점, 구조적인 설계도를 작성하는 측면에서는, Interface를, 그 외 변수처럼 사용되어야 하는 경우에는 Type alias를 사용하는 게 좋을 것 같다. (물론 현업에서 정해진 합의가 있다면 따르는 걸로 ^,^)

 

 

(아래에는 원티드 프리온보딩 챌린지 과정 진행했던 과제를 정리해 보았습니다.)

🫐 Day 1

---

TS 등장 전, 자바스크립트 함수의 매개변수, 반환값, 구성 요소를 설명하는 표준화된 내용을 위해서 주석을 달기 위해 사용하는 JSDoc을 채택했다고 들었다.

첫 번째 과제로, 요구 사항에 맞추어 To Do 리스트를 선언부만 구현하며, JSDoc의 typedef / property / optional property 태그를 사용해 함수를 구현하기 전 타입에 대한 힌트를 적는 연습을 하였다.

• 과제 링크

GitHub - Yeonny0723/wanted-pre-onboarding-challenge-fe-2

• 느낀 점
  • '타입 안정성'의 효과를 '설계'의 관점에서 느낄 수 있었다.
  • 하지만, 설명만 할 뿐, 잘못된 코드를 막을 수는 없었고,
  • 리팩토링 과정에서 더 이상 유효하지 않아 진 설명을 추적하고 변경해주어야 하는 부분이 비효율 적이었다. 
  • 또한 복잡한 객체를 설명하기 어렵고, 그 관계를 설명하기 위해서 독립적인 다수의 주석이 필요했다. 

 

 

🫐 Day 2

---

JSDoc의 함수 설명서에 따라 타입을 설계하는 연습을 하였다.

• 과제 링크

GitHub - Yeonny0723/wanted-pre-onboarding-challenge-fe-2

• 느낀 점

타입 정의와 관련된 주요 문법을 살펴보면서 타입스크립트에 타입 지정에 다양한 문법이 있다는 것을 알았고, 익숙해질 수 있도록 여러 예시를 살펴보고 연습해 볼 필요가 있다고 느꼈다.

 

 

🫐 Day 3

---

타입을 설계한 대로 구현하는 연습을 하였다.

• 과제 링크

GitHub - Yeonny0723/wanted-pre-onboarding-challenge-fe-2

 

• 느낀 점

TS를 구조적인 측면, 집합론적인 측면에서 새롭게 이해해 보는 관점을 얻었다.

 

A. TS의 구조적 관점 (덕 타이핑, 구조적 타이핑)

타입스크립트 개발자들은 명시적 타이핑을 통한 엄격한 타입 체크가 아닌 (집합을 인정하는) 구조적 타이핑을 통한 타입 체크를 선택했다. 왜일까? 아마 기존 JS 개발자들이 받아들이기에는 좀 더 유연한 타입 체킹이 필요했기 때문이라고 생각했지 않았을까 싶다.

하지만 이 타입스크립트의 타입 체킹 시스템이 개발자에게 편리함을 줄 때도 있지만, 개발자가 예상하지 못한 곳 (런타임)에서 버그를 일으킬 수도 있다.

type Human = {
		name: string
}

type Animal = {
		name: string
}

function getName(obj: Animal){ // Animal을 넣던 Human을 넣던 구조가 동일하기에 문제 없음.
	return obj.name
}

그렇기 때문에 이 TS의 타입 체킹 시스템을 잘 이해해 컴파일러의 타입 체킹 결과를 예측하며 코드를 작성해야겠다는 생각이 들었다.

 

B. TS의 집합론적인 관점

이 관점에서 타입은 하나의 집합이다.

• 모든 타입은 집합일 뿐이지만 타입 간에도 계층이 존재하고, 
• 타입 간의 관계는 특정 관계로 선언되었는지 여부가 아닌 포함된 속성에 의해 결정한다.
• 서브 타입(하위 타입)은 슈퍼 타입(상위 타입)에 할당할 수 있다.

type Human = {
		name: string
}

type Animal = {
		name: string
}

type HumanAnima = Human extends Animal ? true : false // true. Human이 더 범용적이기에 얘가 더 상위 타입이다.

 

 

🫐 Day 4.

---

Typescript-exercises 문제를 1-9번까지 풀며 요구사항을 구현하기 위해 어떤 타입 에러가 발생하였고, 어떻게 해결할 수 있는지 기록하는 과제였다.

• 과제 링크 (원본 문제는 파일 커밋 history에 있습니다)

Union 타입, 타입 가드, Type Predicate (타입 명제), Partial & Omit과 같은 Util 타입을 연습하고 적용했다.

GitHub - Yeonny0723/wanted-pre-onboarding-challenge-fe-2

(! 문제 풀이에 대한 설명은 추후 포스팅에서 다룰 예정!)

 

 

 

 

 

 

 

앞으로 할 일:

논리에 기반한 일가견: https://techblog.woowahan.com/9804/

관심사 분리: https://www.youtube.com/watch?v=KEDUqA9JeIo&t=1212s

버전 업데이트에서 꼭 읽어야 할 사항: Breaking Changes (이전 버전과 호환되지 않는 부분)

Discussion ⇒ Issue ⇒ PR ⇒ Code Review ⇒ Merge → SEMVer ⇒ Release 흐름을 지키며 개발

꾸준히 가설을 세우고 → 수립하고 → 검증하고 → 실현하는 과정의 반복

RealWorld 만들기 연습: https://github.com/pocojang/nuxt-realworld

라이브러리 분석: https://github.com/axios/axios

Type hierarchy: https://www.zhenghao.io/posts/type-hierarchy-tree

 

 

참고자료: https://typescript-kr.github.io/pages/tutorials/ts-for-the-new-programmer.html

https://velog.io/@bbaa3218/TypeScript-독학-7-이펙티브-타입스크립트