"죄송해요, User 스키마에서 name 필드가 빠지게 됐어요."
백엔드 개발자의 이 한마디에 식은땀부터 흐른다면? fetch 호출마다 as User[]로 타입을 단언하고, API 스펙 변경 때마다
온 동네를 뒤져야 하는 고통.
제네릭을 활용한 Type-Safe API 레이어 설계로, 스펙 변경에도 끄떡없는 견고한 구조를 만드는 방법을 공유합니다.
더 이상 런타임 에러에 떨지 않고, 컴파일 타임에 버그를 잡아내는 쾌감을 느껴보세요.
👉 글 보러가기: https://blog.sangwook.dev/posts/typescript-project-api-design
🔗 관련 시리즈 (전체 보기)
- 당신의 Type, 어디까지 연결되어 있나요? (https://blog.sangwook.dev/posts/typescript-project-design)
- Type 설계의 시작: 견고한 서버 API Type 설계하기
(https://blog.sangwook.dev/posts/typescript-project-api-design) - Type 설계의 시작: 견고한 서버 API Type 설계하기 With Di
(https://blog.sangwook.dev/posts/typescript-project-api-di-design) - "원래 있던 기능이니 금방 하시죠?" 당하지 않는 Service Layer 설계 전략
(https://blog.sangwook.dev/posts/typescript-project-service-design) - "원래 있던 기능이니 금방 하시죠?" 당하지 않는 Service Layer 설계 전략 With Di
(https://blog.sangwook.dev/posts/typescript-project-service-di-design) - "같은 로직 또 복사했어요?" Domain 모델로 책임 분리하기
(https://blog.sangwook.dev/posts/typescript-project-domain-design)
11개의 댓글
2025년 6월 24일
제네릭을 활용해서 타입 안전성을 지원한 덕분에 테스트 코드까지 흔들림 없이 작성되는 게 인상 깊었어요.
진짜 좋은 구조는 테스트가 쉬워야 한다는 말에 실감이 났습니다. 감사합니다
1개의 답글
2025년 6월 28일
타입스크립트 완전 딥다이브 하는 중입니다 기존 문제 점 코드 같이 보여주시니까 더 이해가 잘 되었던 것 같아요 ㅠㅠ 많이 배우고 갑니다 감사해요!
1개의 답글
좋은 글 잘 읽었습니다 🙏 제네릭을 저렇게 활용해서 타입안정성을 지원할 수 있군요!!
HTTP 클라이언트를 보면 보통 클래스 기반으로 설계하던데, 함수형 방식을 선호하지 않는 이유가 어떤것일까요? 또, 제네릭에 기본값으로 any를 사용하는 건 불가피한 선택인지 궁금합니다.
사이드 프로젝트에서 tRPC를 사용해봤는데, 백엔드와 프론트 간 타입 안정성을 해결해줘서 DX가 정말 좋았던 경험이 있어요ㅎㅎ 공유 감사합니다~