Scarab Diagnostic Suite 현장 테스트 #015: React Compiler의 Non-Null Assertion 경계 문제

이번 현장 테스트는 React를 대상으로 진행되었습니다.

해당 이슈는 React #33054였습니다:

https://github.com/facebook/react/issues/33054

공개된 PR(Pull Request)은 여기 있습니다:

https://github.com/facebook/react/pull/36709

보고된 문제는 React Compiler와 TypeScript의 non-null assertion (non-null 단언)과 관련이 있었습니다.

유용한 진단 경계(diagnostic boundary)는 다음과 같았습니다:

TypeScript non-null assertion → 컴파일러의 의존성/효과 추적 (dependency/effect tracking) → 생성된 React 동작

이것이 중요한 이유는 React Compiler가 단순히 구문(syntax)을 변환하는 것이 아니기 때문입니다.

React Compiler는 어떤 값이 중요한지, 의존성이 어디에 존재하는지, 그리고 컴파일을 통해 반응형 범위(reactive scopes)가 어떻게 보존되어야 하는지에 대한 결정을 내립니다.

눈에 보이는 증상은 객체에 대한 non-null assertion이 컴파일 후에 올바르게 동작하지 않는 JavaScript를 생성할 수 있다는 것이었습니다.

더 깊은 문제는 컴파일러가 HIR(High-level Intermediate Representation) 및 코드 생성(codegen) 과정을 통해 non-null 표현식을 보존했지만, non-null assertion이 여전히 의존성 및 효과 정보를 담고 있는 값으로서 올바르게 취급되지 않았다는 점입니다.

쉬운 말로 설명하자면:

구문은 보존되었지만, 해당 값의 반응형 의미(reactive meaning)에 대한 컴파일러의 이해가 어긋난 것입니다.

이는 컴파일러의 진실 경계(truth-boundary) 실패입니다.

로컬/공개 수정 사항은 의도적으로 좁은 범위를 가집니다.

React Compiler를 재설계하지 않습니다.

TypeScript 처리 방식을 광범위하게 다시 작성하지도 않습니다.

이 수정은 이를 이해해야 하는 컴파일러 경로를 통해 non-null assertion 의존성을 전달하는 데 집중합니다.

패치는 컴파일러 HIR 방문자(visitors), 의존성/효과 처리(dependency/effect handling), 반응형 범위 가지치기(reactive scope pruning), 코드 생성(codegen) 경로, 그리고 관련 컴파일러 픽스처 스냅샷(compiler fixture snapshots)을 업데이트합니다.

목표는 간단합니다:

Non-null assertion은 그것이 감싸고 있는 표현식의 의존성 보유 또는 효과 보유 특성을 지워버려서는 안 됩니다.

만약 콜백 내부의 속성 읽기(property read)가 해당 표현식에 의존한다면, 컴파일러는 해당 읽기를 잘못된 단계에 속한 것처럼 취급하는 대신 그 관계를 보존해야 합니다.

PR(Pull Request)에 나열된 검증 항목에는 포매팅 (formatting), 린팅 (linting), Flow, 컴파일러 스냅샷 빌드 (compiler snapshot build), 그리고 non-null assertion (non-null assertion) 주변의 타겟팅된 컴파일러 스냅샷 테스트가 포함됩니다.

현장 테스트 (Field Test) #015

• 프로젝트: React
• 이슈 유형: React Compiler / TypeScript non-null assertion 동작
• 경계 (Boundary): TypeScript assertion 구문 vs 컴파일러 의존성/효과 추적 (dependency/effect tracking)
• 결과: 컴파일러 피스처 (fixtures) 및 스냅샷을 포함한 공개 PR 오픈
• 상태: PR 오픈됨; Meta CLA 서명 완료; 리뷰 필요

이 현장 테스트가 중요한 이유는 Scarab를 핵심 컴파일러 의미론 (compiler semantics) 영역으로 이동시키기 때문입니다.

이는 앱 동작, 런타임 리소스, 또는 인프라 캐시 경로와는 다른 종류의 경계입니다.

컴파일러는 코드의 형태 (shape)를 보존할 수는 있지만, 그 코드가 담고 있던 의미 (meaning)를 잃어버릴 수도 있습니다.

그것이 컴파일러 버그를 미묘하게 만드는 요소입니다.

출력 결과는 구조적으로 그럴싸해 보일 수 있지만, 컴파일러의 내부 모델이 중요했던 관계를 보존하는 것을 중단했을 수 있습니다.

이 경우, 중요한 질문은 단순히 다음과 같은 것이 아니었습니다:

non-null assertion이 컴파일 과정에서 살아남았는가?

더 나은 질문은 다음과 같았습니다:

의존성 (dependency)과 효과 (effect)의 의미가 그것과 함께 살아남았는가?

이것이 바로 Scarab가 드러내기 위해 구축된 종류의 경계입니다.

단순히 코드가 변하는 지점이 아니라,

의미가 보존되지 않는 지점 말입니다.