플러터 앱을 리액트 네이티브로 옮긴 사례

왜 옮기게 되는가

플러터든 리액트 네이티브든 둘 다 좋은 도구입니다. 그럼에도 옮기는 이유는 대개 기술 자체보다 운영 연속성에 있습니다. 함께 유지보수할 개발 인력을 구하기 쉬운 쪽, 이미 쓰는 웹·서버 스택과 코드를 공유하기 좋은 쪽, 필요한 라이브러리·SDK 생태계가 맞는 쪽으로 정리하려는 경우가 많습니다.

(사례) 클라이밍 루트 앱을 RN으로 옮긴 배경

자사에서 운영하는 클라이밍 루트·개념도 앱(RouteFinding)을 플러터에서 리액트 네이티브로 이전한 적이 있습니다. 앱 자체는 잘 돌아갔지만, 다른 자사 앱과 유지보수 스택을 통일해 한 사람이 여러 앱을 이어서 관리할 수 있게 하려는 것이 이유였습니다. "지금 멀쩡한데 왜 옮기냐"는 질문에 답이 분명했기에 진행했습니다.

이전 전에 판단한 기준

• 옮길 이유가 분명한가 — 단순 취향이 아니라 운영상 이득이 있는가
• 재사용할 자산 — 서버·API·데이터 구조는 그대로 쓸 수 있는가
• 기능 규모 — 화면·연동이 많을수록 단계적 이전이 필수
• 중단 없이 갈 수 있는가 — 서비스 운영을 멈추지 않고 옮길 계획

이전 과정: 무엇부터 옮겼나

1. 데이터·API 정리 — 서버와 데이터 구조는 유지하고, 앱만 새 프레임워크로
2. 화면 흐름 도식화 — 기존 앱의 화면·이동 경로를 먼저 그려 설계 자료로
3. 핵심 기능부터 — 지도/개념도 표시 같은 핵심 화면을 먼저 이전해 검증
4. 주변 기능 이관 — 부가 화면과 설정을 이어서 옮김
5. 스토어 재배포 — 기존 앱을 대체하는 형태로 정식 배포

겪은 문제와 해결

프레임워크가 바뀌면 같은 기능도 구현 방식이 다릅니다. 지도·이미지 위에 요소를 겹쳐 그리는 부분이나 플랫폼별(iOS·안드로이드) 세부 동작에서 차이가 생겨, 화면별로 실제 기기에서 확인하며 맞춰갔습니다. 핵심은 한 번에 전부 바꾸지 않고 기능 단위로 옮겨 검증한 것이었습니다. 이렇게 하면 문제가 생겨도 범위가 좁아 원인을 빨리 찾습니다.

옮기고 나서 달라진 점

가장 큰 소득은 유지보수 연속성이었습니다. 스택을 통일하니 다른 자사 앱과 코드·경험을 공유해 한 사람이 여러 앱을 이어 관리하기 쉬워졌습니다. 반대로 말하면, 이런 운영상 이유가 없다면 굳이 옮길 필요는 없습니다. 프레임워크 이전은 목적이 분명할 때 가치가 있습니다(관련: 플러터 앱을 리액트 네이티브로 이전).

자주 묻는 질문