처음에는 좀 단순하게 React Native로 왔으니까 화면도 다 RN으로 짜야 하는 게 아닌지... 생각했다.
근데 실제로 붙이기 시작하니까 바로 현실이 보였다.
핵심 UX(앱 느낌이 중요한 구간)랑, 운영하는 화면(자주 바뀌는 페이지)을 같은 속도로 RN로 다 밀어붙이는 건 생각보다 빡세다.
처음에 착각했던 포인트
내 머릿속 공식은 이랬다.
- 앱 = 무조건 네이티브 화면
- 웹뷰 = 임시방편
근데 하다 보니 반대였다.
WebView는 대충 때우는 기술이 아니라, 어디를 빠르게 바꾸고, 어디를 네이티브 품질로 가져갈지 나누는 전략에 더 가까웠다.
비유하자면
- RN: 집의 뼈대랑 문, 창문 같은 구조
- WebView: 벽지/포스터/배치처럼 자주 바뀌는 영역
뼈대는 신중하게 만들고, 바뀔 것들은 갈아끼우기 쉽게 두는 게 맞다는 걸 이제 좀 이해했다.
다행히 Next.js도 쓰고 있어서 좋았던 점
이미 Next.js에 익숙하니까, 운영성 화면을 WebView로 붙이려고할 때 진입장벽이 낮았다.
RN 프로젝트인데 Next.js도 같이 돈다는 점이 처음엔 좀 낯설었는데, 막상 해보니 역할 분리가 되면서 오히려 머리가 맑아졌다.
- RN은 앱 네비게이션/디바이스 경험 담당
- Next.js는 콘텐츠/운영 화면 담당
이렇게 나누니까 각자 잘하는 걸 하게 되는 느낌!
RN 스택이랑 Web 라우터가 같이 있는 게 헷갈렸던 부분
RN도 이동이 있고, 웹도 이동이 있으면 누가 진짜 라우터지?
이해한 바로는 2층 구조다.
1. RN 스택: 앱 화면 단위 이동 (예: Home -> WebContent)
2. Web 라우터(Next App Router): WebView 안에서 페이지 이동 (예: `/faq`, `/notices`)
즉 RN은 웹뷰라는 방으로 들어가는 문이고, 방 안에서 어디로 갈지는 웹 라우터가 정하는 구조.
이래서 둘이 충돌이 아니라 공존이 되는구나 싶었다.
실제로 부딪힌 포인트 (근데 구조를 이해하니 해결됨)
WebView에서 서버 연결 안 됨이 떴을 때, 처음엔 RN 코드 문제인 줄 알았다.
근데 원인은 단순했다. WebView는 URL을 여는 거라, Next dev 서버가 안 떠 있으면 당연히 실패한다.
RN Fast Refresh와 Web 서버 실행 상태는 별개다.
이걸 구분하고 나니까 디버깅이 훨씬 쉬워졌다.
지금 기준으로 잡은 감각
모든 걸 RN로 당장 완성하려고 하지 말고, 핵심 경험 먼저 Native로 올리고, 운영성 화면은 WebView로 빠르게 돌리는 게 MVP에 더 맞는 듯하다.
현재 소규모 개발 인원에서는 완벽한 단일 스택보다 변경 비용이 낮은 구조가 더 중요한 순간이 진짜 많다.
RN + Next.js 조합이 생각보다 자연스럽고, 다행히 Next.js도 쓴다 ㅎㅎ가 실제로 생산성 이점으로 이어지는 걸 체감했다.
앞으로는 어떤 화면을 RN으로 끌어올릴지, 어떤 화면은 Web로 남겨둘지 데이터 보면서 조금씩 조정해볼 생각이다.
아직 배우는 중이지만, 적어도 지금은 하이브리드가 타협이라는 느낌은 아니다.
오히려 초기 속도와 품질을 같이 챙기려는 설계에 더 가까운 것 같다.
'프로젝트' 카테고리의 다른 글
| RN) Xcode 아이폰 연결 방법 ~ USB 신뢰부터 최신 빌드 설치까지 (1) | 2026.08.24 |
|---|---|
| RN) Next.js 하던 내가 RN 처음 붙잡고 느낀 점 및 초보자 에뮬레이터 실행 (0) | 2026.05.25 |
| RN(React Native) 시작 전 마음의 준비: RN이 뭔데? (0) | 2026.05.17 |