ADR-T-002

모바일 앱은 React Native(Expo) 기반으로 개발한다

ADR ID: ADR-T-002
상태: Accepted
작성일: 2026-03-02
작성자: YSY
관련 ADR: ADR-T-001

1. 배경 (Context)

플랫폼은 모바일 중심 구조다.
초기 목표는 안드로이드 MVP 출시이며, 이후 iOS 확장 가능성을 열어둔다.

제약 조건:

1인 개발
빠른 MVP 필요
웹 확장 가능성 존재
UI/UX 품질이 경쟁력
위치/GPS 사용 빈도 높음
지도 SDK 연동 필요

기존 개발 경험은 .NET 중심이며, 모바일 네이티브(Android Kotlin, iOS Swift)는 숙련도가 낮다.

2. 결정 (Decision)

모바일 앱은 React Native + Expo 기반으로 개발한다.

초기 전략:

안드로이드 우선 출시
단일 코드베이스 유지
Expo 기반으로 빌드/배포 단순화
네이티브 모듈 커스터마이징은 최소화

3. 대안 (Alternatives Considered)

대안 A: Android 네이티브(Kotlin)

설명
안드로이드만 우선 개발

장점

퍼포먼스 최적
네이티브 제어 용이
위치/GPS/지도 안정성 높음

단점

iOS 별도 개발 필요
코드 이중화
장기적으로 유지 비용 증가

채택하지 않은 이유
장기 확장성과 1인 개발 리소스를 고려할 때 비효율적이다.

대안 B: Flutter

설명
Dart 기반 크로스플랫폼

장점

UI 일관성 우수
성능 안정적
네이티브와 유사한 렌더링

단점

생태계 적응 필요
기존 JS/웹 확장성과 연결성 낮음
러닝커브 존재

채택하지 않은 이유
웹 확장과 코드 공유 가능성을 고려했을 때 RN이 더 자연스럽다.

대안 C: React Native(Expo 제외, Bare Workflow)

설명
React Native CLI 기반

장점

네이티브 제어 자유도 높음

단점

빌드 환경 복잡
DevOps 부담 증가

채택하지 않은 이유
초기 단계에서 복잡도를 낮추기 위해 Expo를 우선 채택한다.

4. 결과 (Consequences)

긍정적 결과

단일 코드베이스 유지
안드로이드/iOS 확장 용이
웹과 개념 공유 가능
개발 속도 향상
Expo로 빌드/배포 단순화

부정적 결과

순수 네이티브 대비 퍼포먼스 한계 가능성
Expo 의존성 존재
복잡한 네이티브 기능 도입 시 제약

5. 영향 범위 (Impact)

기술

상태 관리(Zustand 등) JS 기반
API 통신 구조 통일
지도/위치 SDK는 RN 호환 라이브러리 선택 필요

플랫폼 간 UI 차이 최소화
네이티브 느낌 유지 위한 추가 작업 필요

운영

Expo 빌드 파이프라인 활용
앱스토어 배포 절차 표준화

6. 재검토 조건 (Revisit Conditions)

다음 조건 중 하나 이상 충족 시 재검토:

퍼포먼스 병목이 구조적으로 발생
네이티브 기능 의존성이 과도해질 경우
팀 규모 확대 후 네이티브 전문 인력 확보
플랫폼 확장 전략이 웹 중심으로 전환될 경우

Buy me a coffee

ADR-T-001 ADR-T-003