Expo vs React Native CLI, 2026년 어떤 방식으로 크로스플랫폼을 시작해야할까?

😀 개요

안녕하세요 😀

새 React Native 프로젝트를 만들려고 터미널을 열었을 때, 첫 명령어부터 멈칫한 적 없으신가요?

• npx create-expo-app 으로 Expo로 시작할까
• 아니면 npx @react-native-community/cli init 으로 순정으로 시작할까

검색을 해보면 정보가 서로 엇갈립니다. 한쪽에서는 "Expo가 편하다"고 하고, 다른 쪽에서는 "Expo는 나중에 eject 해야 하고 네이티브 모듈을 못 붙인다"고 합니다.

그런데 이 두 번째 이야기들은 대부분 몇 년 전 기준입니다. 그사이 Expo의 구조가 크게 바뀌었고, 정작 React Native 공식 문서는 지금 새 앱에 프레임워크(Expo) 사용을 권장하고 있습니다.

그래서 오래된 기억으로 순정 CLI를 골랐다가, 정작 필요했던 건 Expo였던 경우도 많습니다. 반대로 특수한 요건이 있는데 무작정 Expo로 시작해 고생하는 경우도 있고요.

🎯 이 글에서 챙겨 갈 것

이 글을 다 읽으면 아래 세 가지가 정리됩니다.

• 2026년 기준으로 Expo와 순정 CLI가 실제로 뭐가 다른지
• 내 프로젝트 조건에 맞춰 어느 쪽으로 시작할지 판단하는 기준표
• Expo가 맞는 경우 / 순정 CLI가 맞는 경우 / 성급히 정하지 말아야 하는 경우

즉, "남들이 Expo 쓰니까"가 아니라 내 상황에서 무엇이 맞는지 스스로 판단하는 기준을 챙겨 가는 것이 목표입니다. 어느 한쪽이 무조건 정답이라고 단정하지는 않습니다.

🧭 이 글의 근거를 먼저 밝히면

본론에 들어가기 전에 이 글의 성격부터 짚어 두겠습니다.

이 글은 같은 앱을 Expo와 순정 CLI로 각각 만들어 오래 운영해 본 경험담이 아니라, React Native와 Expo 공식 문서를 근거로 정리한 결정 가이드입니다.

버전, 명령어, 요금, 정책은 모두 확인일(2026년 7월 17일) 기준입니다. 특히 EAS 요금처럼 자주 바뀌는 값은 결정하기 전에 공식 페이지에서 다시 확인하시는 편이 안전합니다. 문서 기준 정보의 출처와 확인일은 글 맨 아래 참고 자료에 모아 뒀습니다.

🗺️ 2026년의 지형: 3년 전 정보가 왜 안 맞을까

세부 비교로 들어가기 전에, 지금 상황부터 정리하겠습니다. Expo에 대한 오해 대부분은 여기서 풀립니다.

첫째, 공식 문서가 프레임워크(Expo)를 권장합니다. React Native 공식 "Get Started" 문서에는 이렇게 적혀 있습니다. "새 앱을 만든다면 프레임워크 사용을 권장한다(if you're building a new app with React Native, we recommend using a Framework)." 그리고 현재 권장되는 커뮤니티 프레임워크로 Expo를 지목합니다. 여기서 프레임워크는, 쉽게 말하면 앱에 꼭 필요한 공통 기능들을 미리 갖춰 둔 도구 모음입니다.

그림 1. React Native 공식 "Get Started" 문서(좌상단 버전 0.86 기준). 프레임워크(Expo) 사용을 권장하는 설명, npx create-expo-app@latest 시작 명령, 그리고 EAS가 "선택(optional)"이라는 안내가 함께 담겨 있습니다. 출처: reactnative.dev/docs/environment-setup, 확인일 2026-07-17.

둘째, "managed / bare workflow"와 "eject"는 옛 용어입니다. 예전에는 Expo가 "쉬운 대신 제약이 있는 managed"와 "제약이 없는 bare"로 나뉘었고, 제약을 벗어나려면 eject를 했습니다. 지금은 이 구분이 사라졌고, 모든 Expo 프로젝트가 CNG(Continuous Native Generation) 라는 한 가지 방식을 씁니다. CNG는 쉽게 말하면, android·ios 같은 네이티브 폴더를 저장소에 계속 들고 있지 않고 설정을 바탕으로 필요할 때 자동 생성하는 방식입니다.

셋째, 앱을 켜는 방식이 두 갈래입니다. Expo에서 개발 중 앱을 켜는 방식은 Expo Go와 development build(개발 빌드) 두 가지입니다. Expo Go는 미리 만들어진 앱이라 Expo SDK에 포함된 네이티브 기능만 쓸 수 있습니다. 반면 development build는 내 프로젝트를 직접 빌드한 앱이라, 여기서는 어떤 네이티브 코드나 서드파티 네이티브 모듈도 넣을 수 있습니다. "Expo는 네이티브를 못 쓴다"는 말은 사실 Expo Go에만 해당하는 이야기입니다.

넷째, New Architecture는 이제 양쪽 다 기본이자 사실상 유일합니다. React Native는 0.76부터 New Architecture가 기본값이 됐고, 0.82부터는 레거시로 끌 수 없는 유일한 아키텍처가 됐습니다. Expo도 SDK 55부터 항상 New Architecture로만 동작합니다. 즉 "Expo면 내부 구조가 다르다"는 것도 옛말이고, 이 부분에서 둘 사이에 차이는 없습니다.

Expo의 실행 방식(Expo Go·development build·CNG)이 한 번에 안 잡힌다면, 아래 개요도로 관계를 먼저 보고 넘어가면 좋습니다.

그림 2. 2026년 Expo의 실행·네이티브 모델. Expo Go(SDK 기능만)·development build(임의 네이티브 가능)·CNG/prebuild(네이티브 폴더 자동 생성)의 관계를 한 장으로 정리했습니다.

⚖️ 기준별 차이

그럼 실제 선택은 어디서 갈릴까요? 두 방식을 판단 축별로 정리하면 이렇습니다. 참고로 순정 방식의 시작 도구는 이제 react-native init이 아니라 커뮤니티 CLI(@react-native-community/cli) 입니다. 예전 react-native init 명령은 코어에서 빠져 커뮤니티 CLI로 옮겨졌을 뿐, 계속 지원됩니다.

판단 축	Expo (공식 권장 기본)	순정 RN / 커뮤니티 CLI
시작 명령	npx create-expo-app@latest	npx @react-native-community/cli@latest init
android/ios 폴더	기본은 두지 않고 필요할 때 생성(CNG/prebuild)	처음부터 저장소에 두고 직접 관리
커스텀 네이티브 코드	development build면 제한 없음(Expo Go만 제한)	제한 없음
빌드·서명·스토어 제출	EAS로 클라우드 처리(선택) 또는 로컬 빌드	직접 구성(Xcode·Gradle·CI)
OTA 업데이트	EAS Update 등으로 바로 배포	직접 구성
RN 버전 업그레이드	프레임워크가 상당 부분 정리	직접 처리(공수 부담 큼)
기존 네이티브 앱에 끼워넣기	브라운필드=alpha(일부 도구 미지원)	성숙, 자유로움
필요한 팀 역량	낮음~중간	iOS/Android 네이티브 빌드 경험 필요

여기서 EAS(Expo Application Services)는, 쉽게 말하면 Expo가 제공하는 클라우드 서비스 묶음입니다. 앱을 클라우드에서 빌드·서명하는 EAS Build, 스토어에 올려 주는 EAS Submit, JS·에셋 수정 사항을 사용자에게 바로 밀어 넣는 EAS Update로 이뤄져 있습니다.

중요한 점은 EAS가 필수가 아니라는 것입니다. 공식 문서도 로컬이나 자체 CI에서 빌드할 수 있다고 안내합니다. 그래서 "Expo를 쓰면 유료 서비스에 강제로 묶인다"는 것도 정확한 이야기는 아닙니다. (요금은 뒤에서 따로 짚겠습니다.)

🧯 자주 오해하는 3가지

판단 축을 봤으니, 결정을 흐리는 대표적인 오해 세 가지를 짧게 짚고 가겠습니다.

① "Expo는 네이티브 모듈을 못 쓴다"

앞서 본 것처럼 이건 Expo Go에만 해당합니다. development build에서는 공식 문서 표현대로 "다른 네이티브 앱과 똑같이 네이티브 코드나 설정을 바꿀 수" 있고, 서드파티 네이티브 라이브러리도 그대로 붙습니다.

② "나중에 막히면 eject 해야 한다"

eject라는 개념 자체가 사라졌습니다(앞의 CNG). 네이티브가 필요하면 npx expo prebuild로 폴더를 생성해 그대로 손보고, config plugin으로 네이티브 설정을 코드로 반영하면 됩니다. 정말 Expo 도구에서 완전히 벗어나고 싶어도, Expo CLI는 커뮤니티 CLI의 "드롭인 대체(drop-in replacement)"라 기존 React Native 앱이면 전환이 매끄럽습니다.

그림 3. Expo 공식 "Continuous Native Generation(CNG)" 문서. npx expo prebuild가 android·ios 폴더를 생성한다는 설명과, 생성된 폴더를 손으로 고치면 --clean 시 덮어써질 수 있으니 config plugin을 쓰라는 안내, 그리고 이 방식이 "완전히 선택(fully optional)"이라는 문장이 보입니다. 

③ "Expo 쓰면 유료(EAS)에 묶인다"

EAS는 선택입니다. 다만 주의할 점은 따로 있습니다. 네이티브 폴더를 손으로 수정해 두면 npx expo prebuild --clean을 실행할 때 그 수정이 덮어써질 수 있습니다. 그래서 android/ios 폴더를 상시 손으로 관리해야 하는 프로젝트라면, 이 동작 방식이 오히려 걸림돌이 될 수 있습니다. 이건 요금 문제가 아니라 관리 방식의 문제입니다.

🤔 그래서, 뭘 골라야 할까

이제 상황별로 정리하겠습니다. 정답은 프로젝트 성격에 따라 다릅니다. 아래 흐름을 먼저 보면 감이 잡힙니다.

 

Expo로 시작하는 편이 좋은 경우

• 완전히 새로 만드는 앱이고, 특별한 네이티브 요건이 아직 없다.
• 빌드·서명·스토어 제출·OTA 업데이트 같은 공통 인프라를 직접 만들 여력이 없다.
• 팀에 iOS/Android 네이티브 빌드를 전담할 인력이 넉넉하지 않다.
• 빠르게 시작해서 실제 화면부터 만들어 보고 싶다.

순정 CLI(bare)를 검토해야 하는 경우

• 이미 있는 네이티브 앱에 React Native 화면을 끼워 넣는다(브라운필드). 이 경우 Expo 도구 지원은 아직 alpha 단계라 일부 기능이 안 됩니다.
• android·ios 폴더를 처음부터 저장소에 두고 빌드 툴체인을 손으로 완전히 통제해야 하는 특수 요건이 있다.
• 꼭 써야 하는 핵심 라이브러리가 아직 prebuild나 config plugin을 지원하지 않는다.
• 조직 정책상 EAS 같은 외부 클라우드 서비스를 쓸 수 없고, 그에 준하는 대안도 스스로 감당하기 어렵다.

지금 성급히 정하지 말아야 하는 경우

• "언젠가 막힐까 봐"라는 막연한 불안만으로 순정 CLI를 고르는 상황. 그 걱정 대부분은 development build로 해결됩니다. 실제로 막는 라이브러리나 요건을 확인한 뒤 결정해도 늦지 않습니다.

한 가지 덧붙이면, 이미 만들어 둔 React Native CLI 프로젝트를 Expo 도구로 옮기는 것과, RN이 아닌 순수 네이티브 앱에 끼워 넣는 브라운필드는 다른 이야기입니다. 앞쪽은 공식 문서가 "모든 Expo 도구가 어떤 React Native 앱에서도 잘 동작한다"고 할 만큼 성숙했고, 뒤쪽이 alpha입니다. 이 둘을 섞어서 판단하면 결정이 어려워집니다.

✅ 시작 전 결정 체크리스트

여기까지를 한 장으로 정리하면 아래와 같습니다. 그대로 복사해 프로젝트 이슈나 노션에 붙여 쓰셔도 됩니다.

[내 프로젝트 성격]
- [ ] 완전히 새 앱인가, 기존 네이티브 앱에 RN을 끼워 넣나(브라운필드)?
- [ ] 팀에 iOS/Android 네이티브 빌드를 직접 다룰 인력이 있나?
- [ ] android/ios 폴더를 손으로 상시 관리해야 하는 특수 요건이 있나?

[라이브러리]
- [ ] 꼭 필요한 네이티브 라이브러리 목록 작성
- [ ] 각 라이브러리의 New Architecture 지원 확인 (reactnative.directory)
- [ ] config plugin / prebuild 지원 여부 확인
- [ ] npx expo-doctor 로 의존성 호환 교차 점검

[빌드·배포]
- [ ] 클라우드 빌드(EAS)를 쓸 수 있나, 아니면 자체 CI만 가능한가?
- [ ] OTA 업데이트·스토어 제출을 직접 구성할 여력이 있나?

[결론]
- [ ] 위에 특수 요건이 없다 → Expo(create-expo-app)로 시작
- [ ] 브라운필드 / 완전한 네이티브 통제 / 미지원 라이브러리 → 순정 CLI 검토

시작 명령은 각각 이렇습니다. 복사해서 바로 써 보실 수 있습니다.

# Expo로 새 프로젝트 시작 (공식 권장 기본)
npx create-expo-app@latest

# 순정(bare) React Native로 시작 (커뮤니티 CLI)
npx @react-native-community/cli@latest init AwesomeProject

# Expo에서 네이티브 포함 development build를 로컬로 만들어 실행
npx expo run:ios      # 또는 npx expo run:android

# 내가 쓰는 라이브러리들이 New Architecture와 호환되는지 점검 (Expo 프로젝트)
npx expo-doctor

참고: 예전에 전역으로 설치한 react-native-cli가 남아 있으면 충돌이 날 수 있습니다. 공식 문서도 아래로 정리할 것을 권장합니다.

npm uninstall -g react-native-cli @react-native-community/cli

💸 EAS 요금은 어느 정도일까

EAS를 쓸 생각이라면 비용이 궁금하실 텐데요. 확인일 기준으로 정리하면 이렇습니다.

• 무료 티어: 한 달에 안드로이드·iOS 각각 빌드 15회, 낮은 우선순위 대기열, EAS Update는 월 활성 사용자 1,000명까지.
• 유료 플랜: Starter가 월 19달러, Production이 월 199달러 선에서 시작합니다.

다만 이 숫자는 자주 바뀝니다. 빌드 횟수, 크레딧, 사용자 한도, 초과 요금은 결정 직전에 반드시 공식 가격 페이지(expo.dev/pricing)에서 다시 확인하세요. 여기 적은 값은 어디까지나 확인일 시점의 참고치입니다.

🫡 마무리

정리하면, 2026년 현재 기본값은 Expo이고, 순정 CLI는 특수한 요건이 있을 때 고르는 선택지입니다.

핵심은 "예전에 Expo가 별로였다"는 기억이 아니라, 지금의 공식 문서 기준으로 판단하는 것입니다. 오래된 글의 eject·managed/bare 이야기에 끌려다니지 말고, 위 체크리스트로 내 프로젝트의 실제 요건부터 확인해 보시길 권합니다.

Expo든 순정 CLI든 결국 같은 New Architecture 위에서 돌아갑니다. 이 New Architecture가 왜 이제 양쪽 모두의 기본이자 유일한 구조가 됐는지 궁금하시면, 그 배경을 정리한 「React Native 0.82부터 레거시 아키텍처를 못 쓰는 이유」 글을 함께 보시면 흐름이 이어집니다.

다음 글에서는 Expo development build에 서드파티 네이티브 모듈을 직접 붙이는 과정을, 작은 예제 하나로 처음부터 따라가 보겠습니다.

읽어 주셔서 감사합니다 🙇

---

참고 자료

• React Native 공식 문서: Get Started (환경 설정·프레임워크 권장)
• React Native 공식 블로그: Use a framework to build React Native apps (2024-06-25)
• React Native 공식 문서: Get Started Without a Framework (커뮤니티 CLI)
• Expo 공식 문서: Continuous Native Generation (CNG)
• Expo 공식 문서: Add custom native code (Expo Go vs development build)
• Expo 공식 문서: EAS 개요 · Expo 요금
• Expo 공식 문서: New Architecture 가이드
• React Native Directory (라이브러리별 New Arch 지원 확인)