빠른 설정

{
  "compilerOptions": {
    "strict": true
  }
}

strict 설정

strict 설정에서 먼저 자주 보는 축은 아래와 같습니다.

• "strict": true
• strictNullChecks
• noImplicitAny
• exactOptionalPropertyTypes 같은 세부 strict 옵션
• narrowing으로 없음 가능성 처리

1) 프로젝트 기본선은 strict: true

strict는 여러 안전장치를 한 번에 켜 주는 대표 설정입니다. 프로젝트가 커질수록 이 옵션은 선택이 아니라 품질 기준선에 가까워집니다.

2) strictNullChecks는 "없을 수 있는 값"을 정직하게 드러낸다

이 옵션이 꺼져 있으면 null과 undefined가 너무 쉽게 섞여 들어갑니다. 켜 두면 실제로 없을 수 있는 값이 타입에 반영돼, 런타임에서야 터질 문제를 더 일찍 볼 수 있습니다.

const users = [{ name: "Ada" }];
const found = users.find((user) => user.name === "Grace");

strict 모드에서는 found가 undefined일 수 있다는 사실을 무시할 수 없습니다.

if (found) {
  console.log(found.name.toUpperCase());
}

3) strict 오류는 모델링과 narrowing으로 줄이는 편이 맞다

strict 도입 초기에 오류가 많이 나오면 as any로 덮고 싶어지기 쉽습니다. 하지만 그렇게 하면 strict를 켠 이유가 사라집니다.

function upper(value: string | undefined) {
  return value ? value.toUpperCase() : "";
}

즉 불편하더라도 타입 모델을 더 정확히 만들고, 분기해서 좁히는 쪽이 장기적으로 훨씬 낫습니다.

4) noImplicitAny는 코드가 모르는 부분을 숨기지 못하게 만든다

이 옵션은 "정말 타입을 모르는가, 아니면 그냥 적지 않은 것인가"를 구분하게 만듭니다. 팀 전체의 타입 품질을 올릴 때 체감이 큰 축입니다.

5) 세부 strict 옵션은 문제 유형에 따라 추가로 읽는다

프로젝트에 따라 exactOptionalPropertyTypes, noUncheckedIndexedAccess 같은 세부 옵션까지 보는 경우가 있습니다. 이들은 "있을 수도 있음"과 "인덱스 접근 결과가 빠질 수도 있음" 같은 경계를 더 날카롭게 드러냅니다.

6) strict 도입은 번거로움보다 유지보수 비용 절감으로 봐야 한다

초기엔 에러가 늘어난 것처럼 보여도, 실제로는 잠재 버그와 암묵적 가정을 더 빨리 드러내는 과정입니다. 그래서 strict는 생산성 저하 옵션이 아니라 장기 비용 절감 옵션에 가깝습니다.

언제 더 엄격히 볼까

체크포인트

• 프로젝트 기본 검사 강도다: strict: true
• null/undefined 구분이 필요하다: strictNullChecks
• 암시적 any를 막는다: noImplicitAny
• 빠짐 가능성을 더 엄격히 본다: 세부 strict 옵션 검토
• 오류를 줄인다: 모델링 + narrowing 우선
• as any를 쓰고 싶다: 우회 전 이유 재검토

주의할 점

// ❌ strict를 우회해 버림
const found = users.find((user) => user.name === target) as any;
console.log(found.name.toUpperCase());

// ✅ 없음 가능성을 타입대로 처리
const found = users.find((user) => user.name === target);
if (found) {
  console.log(found.name.toUpperCase());
}

// ❌ non-null assertion으로 습관적으로 덮음
const unsafe = users.find((user) => user.name === target)!;
console.log(unsafe.name);