Previous
Next
TypeScript 실전 글 모음 | 시리즈 목차·학습 경로

TypeScript 실전 글 모음 | 시리즈 목차·학습 경로

· 16분 읽기 · 수정 초급 가이드
TypeScript 실전 글 모음 | 시리즈 목차·학습 경로

이 글의 핵심

TypeScript의 백엔드·ORM 맥락과 함께 TypeORM vs Prisma 중심 목차·학습 경로를 안내합니다. JavaScript 글과의 구분도 짚습니다.

들어가며

이 페이지는 pkglog에 흩어진 TypeScript 시리즈·ORM 글을 한곳에 모아 둔 허브일 뿐이야. “완벽한 커리큘럼”이나 “정답 루트” 같은 건 없다고 보면 돼. 그냥 내가 읽을 때·팀이 물어볼 때 링크 던지기 좋게 모아 둔 거고, 아래엔 내가 실제로 밟았던 순서랑 틀렸던 것들이 적혀 있어. 공식 가이드라고 생각하지 마.

any 쓰지 마. 제발.
나도 처음엔 빨강 줄 없애려고 any 찍고 다녔다. 팀에선 아무도 뭐라 안 하고, PR도 통과했어. 그런데 몇 달 뒤에 그 any 밑에 숨은 건 전부 “런타임에 터지는 버그”였다. unknown + narrowing(시리즈 02 말)이 귀찮으면 그만큼만 귀찮고, any는 나중에 이자 붙는다. 정 안 되겠으면 eslint-disable 한 줄이어도 “여기 냄새 난다”는 흔적을 남기는 쪽이 낫다고 본다.

JavaScript랑은 이렇게 나눠 읽는 게 편해: 문법·엔진·async·모듈은 JavaScript 완전 가이드 쪽, 타입·tsconfig·제네릭·ORM 계층은 이 페이지에 링크된 typescript-series-* 쪽. 겹치는 것처럼 보여도 실제로는 역할이 다르다.

저는 이 순서로 배웠어요

아래는 “권장 로드맵” 표로 정리한 게 아니라, 내가 당시에 덜 고통스럽다고 느꼈던 순서야. 팀·프로젝트에 맞게 뒤섞어도 된다.

먼저 01 입문에서 tsc가 돌아가게 만들고, “컴파일할 때 vs 실행할 때” 감을 잡았다. 그다음 02 고급 타입—여기 Union이랑 narrowing이 뒤에 다 깔려 있다. 02를 가볍게 넘기면 04~08에서 계속 꼬인다. 03 Interface는 API·도메인 객체 “모양” 잡는 데 쓰면 된다.

그다음 04 Generics랑 05 Utility Types를 연달아 봤다. DTO를 한 줄 한 줄 복붙하다가 Partial / Pick 쓰는 날, 삶의 질이 확 달라진다. 06 Decorators는 Nest/ORM 안 쓰면 우선순위 낮아도 되고, “문법이 뭔지”만 봐 둬도 된다. 07 고급 패턴은 라이브러리 타입 짤 때 빛난다. 08 REST API는 Express 한 바퀴 돌리면 “타입이 끊기는 지점”이 어디인지 눈에 보인다.

DB 붙이면 TypeORM vs Prisma로 팀이 말이 많아질 때 기준을 잡을 수 있고, Prisma만 팔자면 Prisma 완벽 가이드를 깊게 보면 된다. 런타임 검증은 Zod이랑 같이 쓰는 케이스가 많다. 최신 TS 기능은 TypeScript 5 완벽 가이드를 곁에 두면 돼.

TypeScript 배우면서 했던 뻘짓들

  • strict 꺼놓고 “나중에 켤게” — 안 켠다. “나중”은 퇴사할 때쯤 온다. 처음부터 켜고, 끄고 싶으면 파일/폴더 단위로 이유를 적어라.
  • as로 찍어서 퉁침 — as unknown as X는 그날 PR은 녹는데, 다음 달엔 “왜 undefined지?”가 된다.
  • API 응답에 타입만 믿기 — 컴파일러는 fetch 뒤에 뭐가 올지 모른다. JSON.parse도 마찬가지. 밖에서 들어온 값은 Zod나 최소한 런타임 체크.
  • enum에 애정 과다 — 팀에 따라 쓰는 건 괜찮은데, 나는 Union 리터럴 + as const 쪽이 추적하기 편했음. (의견이야, 팀 룰 따르면 끝.)
  • 데코레이터부터 배우려고 함 — 06이 나쁜 건 아닌데, 02·04가 먼저. 안 그럼 “이게 왜 있지?”만 남는다.

시리즈 본편 — 그냥 링크만

ORM·DB 쪽 (시리즈 밖)

Drizzle·Kysely 쓰는 팀이면 Drizzle ORM 같은 쪽이 따로 있다. “ORM 비교” 글이 TypeORM/Prisma에 초점이 있다고 해서, 타입이 스키마랑 같이 가야 한다는 이야기만 가져가면 된다.

도구는 이렇게만 알아도 돼 (장표 없이)

  • tsconfig는 01·08 예제에 나온 걸 팀 템플릿 출발점으로 써도 된다. strict: true 기본, 예외는 문서.
  • paths 쓰면 test 러너·CI에서도 똑같이 풀리게 맞춰. 안 그럼 “로컬만 된다” 병이 난다.
  • ESLint는 @typescript-eslint 붙이고, 포맷은 Prettier나 Biome 중 하나로. 둘 다 켜놓고싸움은 자제.
  • 테스트는 Vitest/Jest + TS 설정 맞추고 끝. E2E는 Cypress·[Playwright](/en/blog/playwright-component-testing-guide/ 쪽.

React·Next·Astro 쓰면 각자가 강요하는 tsconfig·경로가 있으니, “우리 팀은 Express API”냐 “우리 팀은 Next”냐에 맞는 글을 골라 보면 된다. Next.js App Router, Astro 이런 거.

JavaScript → TypeScript

런타임에만 터지는 버그, 다 겪었을 거다. TypeScript 쓰면 소스 트리 안에서는 일관성이 좋아지고, 리팩터할 때 “어디가 깨질지”가 먼저 보인다. 다만 “컴파일 통과 = 프로덕션 안전”은 아님. HTTP·DB·JSON에서 온 값은 언어가 모른다. 그래서 02의 narrowing이랑 Zod 를 같은 프로젝트에 두는 그림이 생긴다. 이건 패러다임이고, 반박해도 괜찮고 내가 실무에서 본 케이스는 대부분 이쪽이었음.

FAQ (완전 반말)

Q. 글 많은데 어디부터 봄?
A. 아예 처음이면 01→02→03. JS는 익숙한데 TS만 궁금하면 04·05 먼저 봐도 됨. 01은 설치·옵션만 훑을 수도 있고.

Q. 이 시리즈만으로 백엔드 실무 되냐?
A. 08까지로 “API 한 바퀴 + 타입 안 끊기게”는 감 잡힘. DB·마이그레이션·운영은 ORM/Prisma 글을 이어서 봐야 현실에 가깝다.

Q. Prisma만 쓸 건데 TypeORM 비교 읽어야 하냐?
A. 꼭 다 읽을 필요는 없다. Prisma 쪽 절만 골라 읽어도 되고, 레거시 TypeORM이 남아 있으면 비교 글이 가끔 도움 됨.

Q. 데코레이터 꼭 배워야 하냐?
A. Nest/일부 ORM 안 쓰면 우선순위 낮다. 06은 필요해질 때 몰아서 봐도 됨.

Q. 타입 에러 너무 많이 뜨는데?
A. strict 한꺼번에 다 못 쓰겠으면 폴더 단위로 켜고, any 말고 unknown + 02 패턴. 그리고 “에러 수”를 PR 목표로 잡지 말고, 경계(API·DB)부터 좁혀.

Q. enum이랑 Union 뭐 씀?
A. 팀 룰 따르면 끝. 나는 Union + as const 편이었음. 숫자 enum 역매핑 이슈는 한번쯤 찾아보면 이유 감이 온다.

Q. TS5·최신 문법은?
A. TypeScript 5 가이드랑 05·07이랑 같이 보면 덜 멘붕 난다.

Q. 영어 글(-en)도 있냐?
A. 있을 수 있음. 이 인덱스는 한국어 시리즈용으로 잡고, 용어 맞출 때 보조로 쓰면 됨.

같이 보면 좋은 글

배포할 땐 git add → git commit → git push 하고, 프로젝트에 맞는 npm run deploy 흐름 쓰면 됨. 이 페이지 갱신할 때 “새 글이 seriesId: 'typescript'면 여기에 링크 추가” 정도만 기억해 두라고… 근데 그것도 팀이 편한 방식으로 해도 돼. 나는 그냥 여기 써 둔 거야.