본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
250812(화) 43일차
개념과 구조 - 런타임 & 컴파일 타임
타입스크립트의 구조적 한계 – 런타임 검증은 별개
타입스크립트는 정적 타입 언어로서 개발자가 작성한 코드의 컴파일 타임 안전성을 확보해주는 강력한 도구지만 강의에서는 명확하게 강조했다: 타입스크립트는 런타임을 통제하지 못한다.
즉 타입스크립트는 우리가 작성한 코드의 흐름 안에서는 타입 안정성을 제공하지만 외부로부터 들어오는 데이터 (예: API 응답, 사용자 입력, JSON 파일 등)에는 무력할 수 있다
type User = {
id: number;
name: string;
};
function printUserName(user: User) {
console.log(user.name);
}
이 함수에 아래와 같은 외부 데이터를 넣는다면?
const userFromAPI = JSON.parse('{"id":"not-a-number","name":null}');
printUserName(userFromAPI);
타입스크립트 입장에서는 userFromAPI가 User 타입이라고 주장만 하면 아무 문제 없이 통과하지만
실제 실행 시에는 user.name이 null이기 때문에 에러가 발생한다
타입스크립트가 이걸 막아줄 수 없다는 것
방어적 프로그래밍의 중요성
강의에서는 런타임 안전을 확보하기 위해 다음과 같은 전략들을 강조했다
명시적인 런타임 타입 체크
if (typeof user.name === 'string') {
console.log(user.name);
} else {
console.warn('Invalid user name');
}
zod, io-ts 같은 타입 검증 라이브러리 활용
- API 응답 등 외부 데이터는 무조건 스키마 기반으로 검증
- 런타임에서 타입 검증을 통과한 데이터만 타입을 주장하기
unknown 타입 적극 활용
- 외부에서 오는 데이터는 any가 아닌 unknown으로 받아 명시적 처리 유도
함수 진입점에서 validate + narrow 하기
- 받기 전에는 절대 신뢰하지 마라는 철학을 코드에 녹여야 한다
이번 강의는 타입스크립트를 사용하는 프론트엔드 개발자에게 단순한 문법 이상의 경각심을 심어주는 유익한 내용이었다
타입스크립트가 다 지켜줄 것이라는 환상을 깨고 실전에서는 얼마나 방어적인 코딩이 필요한지를 실감할 수 있는 계기가 되었다