피드로 돌아가기
Strict Mode — Strict Null Check
Dev.toDev.to
Frontend

Runtime Crash를 Compile Error로 전환하는 Strict Null Check 설계

Strict Mode — Strict Null Check

Nghề không nhiều chẳng sắc2026년 6월 29일5intermediate

Context

JavaScript의 동적 타입 특성으로 인해 발생하는 'Cannot read properties of undefined' 런타임 에러가 서비스 안정성을 저해하는 핵심 병목으로 작용. 기존 비엄격 모드에서는 null과 undefined가 모든 타입에 암묵적으로 허용되어 데이터 부재 상황에 대한 사전 검증이 불가능한 구조적 한계 존재.

Technical Solution

  • strictNullChecks 활성화를 통한 null/undefined의 독립적 타입 분리 및 명시적 선언 강제
  • Optional Chaining(?.) 도입을 통한 깊은 계층 구조의 데이터 접근 시 런타임 예외 방지 및 safe-navigation 구현
  • Nullish Coalescing(??) 적용으로 0, '', false와 같은 falsy 값의 유효성을 보존하며 기본값 할당
  • Type Narrowing 기법을 활용하여 런타임 접근 전 컴파일 단계에서 값의 존재 여부를 논리적으로 검증
  • Non-null Assertion(!) 사용을 최소화하여 컴파일러를 기만하는 잠재적 런타임 리스크 제거

1. 프로젝트 초기 단계부터 strictNullChecks 활성화 및 팀 내 강제

2. 기본값 할당 시 0이나 빈 문자열이 유효 값인지 판단하여 || 대신 ?? 사용 검토

3. 코드베이스 내 ! (non-null assertion) 및 as (type assertion) 개수를 리스크 지표로 관리

4. 외부 API 응답 데이터 경계 지점에서 any 타입을 제거하고 명시적 Optional 타입 정의

원문 읽기