Unplan

프로젝트 개요

Unplan은 사용자의 컨디션과 생활 패턴을 바탕으로 그날의 일정을 유연하게 관리하도록 돕는 스마트 스케줄러 모바일 앱입니다. 계획을 빈틈없이 채우는 대신 오늘의 상태에 맞춰 할 일을 조정하고 하루를 이어갈 수 있는 경험을 만들었습니다.

React Native와 Expo 기반으로 iOS와 Android를 함께 지원하며, 소셜 로그인부터 온보딩, 일정 관리까지 하나의 모바일 흐름으로 연결하는 팀 프로젝트입니다.

문제 정의

모바일 스케줄러는 일정 데이터만 보여주는 것으로 끝나지 않습니다. 로그인 세션, 온보딩 완료 여부, 사용자의 생활 패턴, 화면 전환 중 유지해야 하는 상태를 함께 다뤄야 합니다. 네이티브 SDK와 백엔드 API가 동시에 연결되므로 플랫폼별 설정 차이와 인증 실패 경로도 고려해야 했습니다.

기능이 빠르게 늘어나는 상황에서도 화면마다 요청 로직과 상태 관리 방식이 달라지지 않도록, 프로젝트 초기에 공통 UI와 API 연동 기준을 먼저 세우는 것이 중요했습니다.

담당 역할

모바일 프론트엔드 개발을 맡아 프로젝트 초기 구조와 컨벤션을 정리하고, 디자인 토큰과 공통 UI 컴포넌트, 로그인·온보딩 화면을 구현했습니다. 이후 카카오·구글 소셜 로그인과 OpenAPI 기반 API 클라이언트, EAS 기반 미리보기 배포 흐름을 연결했습니다.

구현 코드뿐 아니라 PR 템플릿과 개발 문서를 함께 관리해 팀원이 같은 구조와 검토 기준으로 작업할 수 있도록 했습니다.

주요 구현

• Expo Router 권장 구조에 맞춰 라우트, 화면, 상태 모듈의 책임 분리
• 색상·간격·타이포그래피 디자인 토큰과 Typography, Tag 등 공통 UI 구현
• 생활 패턴을 입력하는 온보딩 플로우와 공통 입력 컴포넌트 구현
• 카카오톡 설치 여부에 따른 카카오 계정 로그인 fallback 처리
• Google Sign-In의 ID Token과 카카오 Access Token을 백엔드 로그인 API에 연결
• Orval과 Axios를 이용해 OpenAPI 기반 요청 함수와 타입 생성
• TanStack Query와 Zustand로 서버 상태와 앱 전역 클라이언트 상태 분리
• EAS Build·EAS Update와 GitHub Actions를 연결해 iOS·Android 미리보기 배포 자동화

소셜 로그인 검증 환경

소셜 로그인은 앱, OAuth 제공자, 백엔드가 함께 동작하기 때문에 실패 원인을 한쪽 코드만 보고 판단하기 어려웠습니다. 네이티브 앱에서 받은 토큰이 올바른지, 백엔드 교환 과정에서 어떤 응답이 오는지 분리해 확인할 수 있도록 social-token-console을 별도 저장소로 관리했습니다.

이를 통해 앱 화면 구현과 인증 API 검증을 분리하고, 카카오와 구글 인증 흐름을 연결할 때 문제 범위를 더 빠르게 좁힐 수 있도록 했습니다.

기술적 판단

서버에서 받은 데이터는 TanStack Query가 관리하고, 인증 세션처럼 여러 화면에서 즉시 공유해야 하는 앱 상태는 Zustand가 관리하도록 책임을 나눴습니다. 토큰은 일반 스토리지에 평문으로 저장하지 않고 expo-secure-store를 사용해 네이티브 보안 저장소에 보관했습니다.

API 요청 함수와 타입은 Orval로 생성하되, 인증과 화면 상태까지 생성 코드에 맡기지는 않았습니다. Axios 공통 클라이언트가 요청 설정을 담당하고, 화면에서는 팀이 작성한 훅을 통해 서버 상태를 사용하도록 구성했습니다. 생성 코드와 앱 정책을 분리해 API 명세가 바뀌어도 화면 코드에 미치는 범위를 줄이고자 했습니다.

배포에서는 JavaScript 변경과 네이티브 의존성 변경을 구분했습니다. JavaScript 변경은 EAS Update로 빠르게 확인하고, 네이티브 변경이 포함되면 플랫폼별 Preview Build를 실행하도록 CI 흐름을 나눴습니다.

결과 및 회고

프로젝트 초기의 디자인 토큰과 공통 컴포넌트부터 소셜 로그인, API 생성, 미리보기 배포까지 모바일 앱 개발의 기반을 단계적으로 구축했습니다. 특히 카카오와 구글 로그인을 실제 네이티브 빌드와 백엔드 API까지 연결하면서 웹과 다른 모바일 인증 환경을 경험했습니다.

공통 구조와 문서를 먼저 정리한 덕분에 이후 기능을 추가할 때 화면마다 새로운 방식을 만들지 않고 같은 기준을 재사용할 수 있었습니다. 이 과정에서 구조는 문서만으로 완성되는 것이 아니라, 실제 기능을 연결하고 리뷰 피드백을 반영하며 계속 검증해야 한다는 점을 배웠습니다.