# Expo vs 베어 React Native

Source: Dev.to

개요

Expo는 “관리 전용” 솔루션에서 필요할 때 베어 워크플로우로 이탈할 수 있는 전체 툴킷으로 진화했습니다. 아래는 2025‑2026년 현재 Expo와 베어 React Native의 비교입니다.

Expo

장점

• EAS Build – 로컬에서 Xcode나 Android Studio 없이 클라우드 빌드를 할 수 있습니다. 서명 및 프로비저닝이 자동으로 처리되어 CI 환경이나 네이티브 툴체인을 유지하고 싶지 않은 개발자에게 좋습니다.
• EAS Submit – CLI에서 직접 TestFlight 및 Google Play(내부 또는 프로덕션)으로 빌드를 푸시합니다. EAS Build와 원활히 연동되어 커밋‑투‑스토어 파이프라인을 구현할 수 있습니다.
• Expo SDK – 카메라, 지도, 알림, 업데이트 등 다양한 API를 일관된 JavaScript 인터페이스로 제공해, 작성하고 업그레이드해야 하는 네이티브 코드 양을 크게 줄여줍니다.
• Over‑the‑air updates – EAS Update를 사용하면 전체 스토어 릴리스 없이도 JavaScript(및 에셋) 변경을 배포할 수 있어 핫픽스나 A/B 테스트에 유용합니다.
• Documentation & DX – 잘 정리된 문서와 부드러운 CLI(npx expo start). Fast Refresh와 dev client 덕분에 반복 작업이 빠릅니다.
• Custom dev client – 네이티브 모듈을 추가하면서도 EAS Build와 대부분의 Expo 도구를 계속 사용할 수 있어, 네이티브 코드 사용이 차단되지 않습니다.

단점

• 네이티브 제어 – 매우 맞춤형 네이티브 동작이나 최신 네이티브 API는 패치, 포크, 혹은 config plugin이 필요할 수 있습니다. 보통은 해결 가능하지만 복잡도가 증가합니다.
• 번들 크기 및 추상화 – Expo가 런타임 오버헤드를 추가합니다. 대부분의 앱에서는 문제가 없지만, 매우 제한된 환경에서는 영향을 받을 수 있습니다.
• 학습 곡선 – 베어 React Native에 익숙한 팀은 EAS와 Expo 워크플로우를 새로 배워야 합니다.

Expo를 선택해야 할 때

• 네이티브 툴체인의 부담을 피하고 싶을 때, 특히 새로운 React Native 앱을 시작할 경우.
• 기본 SDK에 포함되지 않은 네이티브 모듈이 필요할 때 custom dev client를 사용합니다.
• 앱이 Expo가 지원하는 범위 내에 머무를 경우 managed workflow를 유지합니다.

Prebuild

prebuild는 Expo 설정을 기반으로 ios/ 및 android/ 폴더를 생성(또는 업데이트)합니다.

• 무엇을 하는가 – app.json / app.config.js와 설정 플러그인 목록을 읽은 뒤, 네이티브 Xcode 및 Android 프로젝트를 생성합니다. 플러그인은 권한, 네이티브 의존성, 혹은 커스텀 네이티브 코드(expo-camera, expo-notifications 등)를 추가할 수 있습니다.
• 언제 실행되는가 – EAS Build에서는 prebuild가 각 빌드 전에 자동으로 실행됩니다(네이티브 폴더를 커밋하고 해당 프로파일에서 건너뛰도록 설정하지 않은 경우). 로컬에서는 다음과 같이 실행할 수 있습니다:

npx expo prebuild          # 네이티브 프로젝트를 생성하거나 새로 고침
npx expo prebuild --clean  # 처음부터 다시 생성(플러그인이나 설정을 변경한 후에 유용)

• Managed vs. “bare‑ish” – Managed 워크플로에서는 일반적으로 ios/와 android/를 커밋하지 않으며, EAS Build가 매번 이를 재생성합니다. 커스텀 dev client나 “bare‑ish” 워크플로에서는 prebuild를 한 번 실행하고 네이티브 폴더를 커밋한 뒤 수동으로 편집할 수 있습니다. 이후에도 해당 폴더를 유지 관리하거나 prebuild를 다시 실행해 변경 사항을 재적용할 수 있습니다(재현성을 위해 가능한 한 설정 플러그인을 사용하는 것이 좋습니다).
• 왜 중요한가 – prebuild를 사용하면 네이티브 모듈을 추가하면서도 EAS Build와 Expo 도구를 계속 활용할 수 있어, “네이티브 코드 없음”과 “완전 수동 네이티브 프로젝트” 사이의 이분법적 선택을 피할 수 있습니다.

베어 React Native

장점

• 전체 제어 – 모든 네이티브 파일이 여러분에게 속합니다. 원하는 대로 수정하고, 라이브러리를 추가하며, 네이티브 프로젝트를 정확히 필요에 맞게 미세 조정할 수 있습니다.
• Expo 레이어 없음 – 런타임 용량이 약간 작아지고, Expo 런타임이나 설정 플러그인이 없습니다.
• 기존 프로젝트 – 많은 코드베이스가 베어 상태로 시작합니다. 베어 설정을 유지하는 것이 Expo로 마이그레이션하는 것보다 간단할 수 있습니다.

단점

• 빌드 및 서명 – Xcode/Android Studio, 인증서, 프로비저닝 프로파일, CI 등을 직접 관리해야 하며, 이는 시간과 좌절을 초래할 수 있습니다.
• 업데이트 – React Native와 네이티브 종속성을 업그레이드하는 것은 전적으로 여러분의 책임입니다. Expo는 이 작업의 대부분을 추상화합니다.
• 내장 OTA 없음 – CodePush와 같은 솔루션을 통합할 수 있지만, 네이티브 EAS Update에 해당하는 것이 없습니다.

베어를 선택해야 할 때

• 앱이 Expo에서 지원하지 않거나 대규모 패치를 필요로 하는 네이티브 동작을 요구할 때.
• 팀이 이미 안정적인 베어 워크플로우를 가지고 있고 이를 유지하고 싶을 때.
• 기존 베어 코드베이스와 맞추어야 할 때.

Expo와 Bare 중 선택

• 새 앱, 표준 요구 사항 – Expo(관리형 또는 커스텀 dev client)와 EAS Build + Submit을 사용하여 시작하세요. 차단 요소가 발생할 경우에만 bare로 전환합니다.
• 무거운 네이티브 요구 사항이나 기존 bare 코드베이스 – 편리함보다 제어가 더 중요할 때는 bare 워크플로우를 유지하거나 마이그레이션하세요.

2026 Outlook

Expo는 이제 프로덕션 준비가 되었으며 널리 채택되고 있습니다. “Expo는 네이티브 코드를 사용할 수 없다”는 오래된 인식은 구시대적입니다. 앱의 요구 사항과 팀의 네이티브 툴링에 대한 편안함에 맞는 접근 방식을 선택하세요, 기존 고정관념에 의존하지 말고.