타입스크립트 제네릭, 실무에서 어떻게 써야 할까?
타입스크립트 제네릭(Generics)의 필요성을 강조하며, `any` 사용 시 타입 정보 손실과 런타임 에러 발생 가능성을 지적
제네릭 함수, 인터페이스, 타입 별칭의 기본 문법을 설명하고, 타입 추론(Type Inference)과 명시적 타입 지정의 차이점을 제시
`extends` 키워드를 사용한 타입 제약(Type Constraints)을 통해 제네릭의 유연성을 유지하면서 타입 안전성을 확보하는 방법 소개
API 응답 래퍼, 유틸 함수 등 실무에서 자주 사용되는 제네릭 패턴(Generic Patterns)을 예시로 제시하며, 코드 재사용성과 타입 안전성을 동시에 확보하는 방법 제시
제네릭(Generics) 도입의 핵심 이유: 타입 안전성 확보
타입스크립트에서 제네릭(Generics)을 사용하는 주된 이유는 타입 안전성(Type Safety)을 확보하고 코드 중복을 줄이기 위함이다. `any` 타입을 사용할 경우, 컴파일러(Compiler)가 타입 정보를 알 수 없어 런타임 에러(Runtime Error) 발생 위험이 높아진다.
제네릭은 함수, 인터페이스, 타입 별칭에서 타입 변수(Type Variable)를 사용하여, 다양한 타입에 유연하게 대응하면서도 컴파일 타임(Compile Time)에 타입 검사를 수행한다.
결과적으로, 제네릭은 코드의 재사용성을 높이고, 런타임 에러를 사전에 방지하여 유지보수성(Maintainability)을 향상시킨다.
제네릭 문법: 함수, 인터페이스, 타입 별칭
타입스크립트에서 제네릭(Generics)은 함수, 인터페이스, 타입 별칭 등 다양한 곳에서 활용된다. 제네릭 함수는 꺾쇠 괄호 `<>`를 사용하여 타입 매개변수를 선언하며, 호출 시점에 전달되는 값에 따라 타입이 결정된다.
타입 추론(Type Inference): 타입스크립트는 인자를 보고 타입을 추론하여, 개발자가 직접 타입을 명시하지 않아도 된다.
명시적 타입 지정: 타입 추론이 원하는 대로 동작하지 않을 경우, `<타입>` 형태로 직접 타입을 지정할 수 있다.
제네릭 인터페이스와 타입 별칭은 구조는 같지만 내부 데이터 타입만 달라지는 경우에 유용하며, 사용하는 위치에 따라 타입 인수를 직접 명시해야 하는 경우가 많다.
타입 제약(Type Constraints)을 통한 제네릭 활용
제네릭(Generics)은 기본적으로 어떤 타입이든 받을 수 있지만, `extends` 키워드를 사용하여 타입의 범위를 제한할 수 있다. 타입 제약은 특정 속성이나 메서드를 가진 타입만 허용하도록 하여, 제네릭의 유연성을 유지하면서도 타입 안전성을 확보한다.
`T extends { length: number }`: T는 반드시 `length` 속성을 가져야 한다는 제약 조건
컴파일 에러(Compile Error): 제약 조건을 만족하지 않는 타입이 들어오면 컴파일 단계에서 에러 발생
유틸리티 타입(Utility Types): 타입스크립트가 기본으로 제공하는 `Pick`, `Omit`, `Partial` 등은 제네릭과 타입 제약을 활용하여 만들어졌다.
실무 제네릭 패턴: API 응답, 유틸 함수
실무에서 제네릭(Generics)은 API 응답 래퍼(API Response Wrapper)와 유틸 함수(Utility Functions)를 만들 때 유용하게 사용된다. API 응답 구조가 일정한 형태를 따르는 경우, data 부분만 제네릭으로 열어두면, 하나의 인터페이스로 모든 API 응답을 커버할 수 있다.
API 응답 래퍼: `ApiResponse<T>` 형태로 data 부분의 타입을 제네릭으로 지정
유틸 함수: 배열이나 객체를 다루는 공통 유틸 함수에 제네릭을 적용하여 반환 타입까지 정확하게 추론
객체 필드 추출: `K extends keyof T`를 사용하여 존재하지 않는 키 접근 시 컴파일 에러 발생 및 반환 타입 자동 추론
결과적으로, 제네릭은 코드의 재사용성을 높이고, 타입 안전성을 확보하여 개발 생산성(Developer Productivity)을 향상시킨다.
