React Native 0.87, Strict TypeScript API 기본값 전환이 가지는 의미
타입 정의와 실제 코드 사이 불일치를 줄이는 방향으로 바뀐 릴리스
React Native로 개발하다 보면 타입 정의와 실제 런타임 동작이 미묘하게 어긋나는 경험을 한 번쯤 하게 된다. 손으로 관리되는 타입 선언 파일과 실제 네이티브 코드가 각각 다른 속도로 바뀌다 보니, 분명 타입 상으로는 문제없는 코드인데 실행하면 예상과 다르게 동작하는 상황이 생기곤 한다. 이런 어긋남을 줄이기 위한 변화가 최근 React Native 릴리스에 반영됐다.
React Native 0.87에서 달라진 것
Strict TypeScript API가 기본값이 됐다
React Native 공식 블로그에 따르면, 0.80 버전부터 미리보기 형태로 제공되던 Strict TypeScript API가 0.87부터 모든 프로젝트의 기본 자바스크립트 API로 채택됐다. 가장 큰 변화는 타입 정의를 손으로 관리하던 방식에서 벗어나, React Native 소스 코드에서 타입을 직접 생성하는 방식으로 바뀌었다는 점이다. 이로써 타입 선언과 실제 코드 사이에 오랫동안 존재하던 불일치 문제가 근본적으로 줄어들 것으로 안내되고 있다.
Metro와 iOS 빌드 체계도 함께 업데이트됐다
번들러인 Metro도 0.87로 함께 올라갔는데, 소스맵 생성 속도가 2배 빨라지고 메모리 사용량은 절반으로 줄었다고 소개된다. TypeScript와 ECMAScript 모듈 형식의 설정 파일이 정식으로 지원되기 시작했고, 패키지 자체 해석 등 리졸버 개선으로 최신 패키지 구조에 대한 지원도 나아졌다. iOS 쪽에서는 CocoaPods를 대체할 수 있는 Swift Package Manager(SwiftPM) 지원이 실험적으로 추가됐는데, 기본 경로인 CocoaPods를 대체하는 것이 아니라 선택적으로 함께 쓸 수 있는 형태로 도입됐다.
기존 프로젝트를 업그레이드할 때 점검할 것
타입 오류가 새로 드러날 수 있다는 점 감안하기
타입이 소스 코드에서 직접 생성되는 방식으로 바뀌면서, 그동안 느슨한 수동 타입 정의 덕분에 통과하던 코드에서 새로운 타입 오류가 드러날 수 있다. 업그레이드 직후 타입 체크를 전체 프로젝트에 한 번 돌려보고, 오류가 발생한 지점을 우선순위를 정해 하나씩 정리하는 순서로 접근하는 편이 수월하다.
Metro 설정 파일 형식 재검토
TypeScript·ESM 설정 파일이 정식 지원되기 시작한 만큼, 기존에 CommonJS 형식으로 작성해둔 Metro 설정을 그대로 유지할지, 새로운 형식으로 옮길지 판단해볼 만하다. 다만 팀 전체 빌드 스크립트와의 호환성을 먼저 확인한 뒤에 전환하는 것이 안전하다.
SwiftPM 도입은 신중하게
SwiftPM 지원은 아직 실험적 단계이고 CocoaPods가 여전히 기본 경로로 유지되므로, 당장 전체 iOS 의존성 관리 방식을 SwiftPM으로 옮길 필요는 없다. 새 라이브러리를 도입할 때 SwiftPM 배포판이 더 잘 갖춰진 경우에 한해 부분적으로 시도해보는 정도로 접근하는 편이 무난하다.
업그레이드 시 흔히 놓치는 점
타입 생성 방식이 바뀌었다는 이유만으로 서드파티 라이브러리의 타입 정의까지 자동으로 함께 맞춰지는 것은 아니다. React Native 코어의 타입은 소스에서 생성되더라도, 프로젝트에서 쓰는 외부 라이브러리가 아직 예전 방식의 타입 정의를 쓰고 있다면 그 부분에서 여전히 불일치가 남아 있을 수 있다. 업그레이드 후에는 자주 쓰는 주요 라이브러리들의 타입 호환성도 함께 확인해두는 편이 좋다.
또한 Metro 성능 개선을 기대하고 업그레이드했는데 체감 효과가 크지 않다면, 프로젝트 규모가 작아 기존에도 소스맵 생성이 병목이 아니었을 가능성을 먼저 살펴봐야 한다. 대규모 프로젝트일수록 이번 업데이트의 체감 효과가 클 것으로 예상되므로, 프로젝트 규모에 따라 기대치를 다르게 잡는 편이 현실적이다.
정리
React Native 0.87의 핵심은 타입 정의를 소스 코드와 직접 연결해 오랜 불일치 문제를 줄인 것이다. 다만 업그레이드 과정에서 새로운 타입 오류가 드러날 수 있으므로, 전체 타입 체크를 먼저 돌려보고 우선순위를 정해 정리하는 순서로 접근하는 것이 안전하다. Metro 설정 형식이나 SwiftPM 도입처럼 선택적인 변화는 팀 상황에 맞춰 서두르지 않고 검토해도 충분하다.
핵심 요약
- React Native 0.87부터 Strict TypeScript API가 모든 프로젝트의 기본값으로 채택됐다.
- 타입이 소스 코드에서 직접 생성되면서 기존 수동 타입 정의와의 불일치 문제가 줄어든다.
- Metro 0.87은 소스맵 생성 속도와 메모리 사용량이 개선됐고 TS·ESM 설정 파일을 정식 지원한다.
- SwiftPM 지원은 아직 실험적 단계이며 CocoaPods가 여전히 기본 경로로 유지된다.
초보자가 자주 실수하는 포인트
- 업그레이드 직후 전체 타입 체크를 돌려보지 않고 일부 화면만 확인한 뒤 문제없다고 판단하는 경우
- React Native 코어 타입이 바뀌었다고 해서 서드파티 라이브러리 타입까지 자동으로 맞춰졌다고 오해하는 경우
- SwiftPM이 실험적 지원 단계인데도 전체 iOS 의존성을 급하게 옮기려는 경우
체크리스트
- 업그레이드 후 전체 프로젝트에 타입 체크를 돌려 새로 드러난 오류를 확인했는가
- 자주 쓰는 주요 서드파티 라이브러리의 타입 호환성을 점검했는가
- Metro 설정 파일 형식 전환이 팀 빌드 스크립트와 호환되는지 확인했는가
- SwiftPM 도입 범위를 실험적 수준으로 한정했는가
자주 묻는 질문
Strict TypeScript API로 바뀌면 기존 코드가 당장 깨지나요?
즉시 깨지지는 않지만, 그동안 느슨한 수동 타입 정의 덕분에 통과하던 부분에서 새로운 타입 오류가 드러날 수 있으므로 업그레이드 후 전체 타입 체크를 먼저 돌려보는 것이 안전하다.
CocoaPods를 SwiftPM으로 지금 바로 바꿔야 하나요?
그럴 필요는 없다. SwiftPM 지원은 아직 실험적 단계이고 CocoaPods가 기본 경로로 계속 유지되므로, 필요한 경우에 한해 부분적으로 시도해보는 정도가 무난하다.
이 글은 초보자 기준으로 이해하기 쉽게 정리되었으며, 내용은 운영 과정에서 순차적으로 보완될 수 있습니다.