트립팝 출시 후기 — AI 여행 플래너를 1인으로 4개 언어 동시 출시까지

결론부터: 두 번째 사이드 프로젝트, 출시까지 갔습니다

2026년 4월, 트립팝(Tripop)을 정식 출시했습니다. AI 여행 플래너인데, iOS·Android·웹 세 곳에서 동시에, 그리고 한국어·영어·일본어·중국어 4개 언어로 동시 런칭했습니다.

알고노트(Algonote)에 이은 두 번째 사이드 프로젝트입니다. 알고노트가 "내가 React를 진짜 다룰 수 있나"의 실험이었다면, 트립팝은 "AI와 오프라인을 어떻게 한 앱에 담을까"의 실험이었습니다.

왜 여행 앱이었나

알고노트를 출시하고 다음 사이드 프로젝트를 고민할 때, 제가 가장 자주 짜증을 내는 일이 무엇인지 곰곰이 생각했습니다.

여행 준비였습니다.

캘린더에는 일정이, 메모장에는 준비물이, 스프레드시트에는 예산이, 이메일에는 항공권 PDF가, 카톡방에는 호텔 예약이. 정작 공항에서 항공권을 보여줄 때는 이메일을 뒤져야 하고, 비행기 안에서 다음 일정을 보고 싶으면 와이파이가 없어서 못 봤습니다.

기존 여행 앱을 다 살펴봤지만 두 가지 문제는 누구도 정면으로 풀지 않고 있었습니다. AI를 여행 준비에 거의 안 쓰고 있고, 정작 여행지에선 인터넷이 가장 안 되는데 오프라인 동작이 안 됐습니다. 이 두 개를 풀면 된다고 생각했습니다.

알고노트와의 차이점

알고노트는 코딩 학습 사이트라 데이터 모델이 단순했습니다. 알고리즘 = 정적 콘텐츠, 사용자 = 진행도. 그게 끝이었습니다.

트립팝은 다릅니다. 여행 하나당 일정·이벤트·바우처·가계부·체크리스트·동행자 멤버 6개의 도메인이 서로 엮여 있고, 두 명 이상의 사용자가 동시에 편집할 수 있어야 합니다. 거기에 오프라인까지.

이 복잡도가 알고노트와 트립팝의 가장 큰 차이였습니다. 알고노트는 클라이언트가 비교적 얇았는데, 트립팝은 클라이언트 자체가 작은 분산 데이터베이스입니다.

기술 선택

모바일: React Native (Expo) + Zustand + MMKV

모바일이 메인이라 처음부터 RN을 썼습니다. 알고노트처럼 Capacitor로 웹앱을 감싸는 방식은 이번엔 안 맞았습니다. 카메라로 영수증 찍기, 푸시 알림, 위젯, 오프라인 저장 — 네이티브 표면적이 너무 컸습니다.

상태 관리는 Zustand에 MMKV(react-native-mmkv)로 영속화했습니다. AsyncStorage 대비 성능 차이가 체감되는 수준이지만, 무엇보다 MMKV는 앱 시작과 동시에 동기적으로 디스크에서 읽힌다는 점이 오프라인 우선 설계의 핵심이었습니다. 비동기 스토리지 hydration 대기로 빈 화면이 잠깐 보이는 일이 없습니다.

서버: Next.js + Supabase

알고노트는 Spring Boot + Kotlin이었는데, 트립팝은 Next.js + Supabase로 갔습니다. 이유는 두 가지. 첫째, 마케팅 페이지·블로그·웹앱·API를 한 코드베이스에 두고 싶었습니다. 둘째, 1인 운영이라 인프라 운영 부담을 최대한 줄이고 싶었습니다. Postgres + Auth + Storage가 한 패키지인 Supabase가 이 조합에 딱 맞았습니다.

AI: Google Gemini 2.5 Flash

이미지·PDF·텍스트를 모두 받는 melt-pot 모델이 필요했고, 가격 대비 성능에서 Gemini Flash가 가장 좋았습니다. PDF에서 항공편 18장을 한 번에 뽑아내는 것도, 영수증 사진에서 금액·통화·카테고리를 채우는 것도 같은 모델·같은 호출 모양으로 처리됩니다.

진짜 어려웠던 건 동기화

이번 프로젝트의 가장 큰 챌린지는 오프라인 우선 + 멀티 디바이스 동기화였습니다.

같은 여행을 모바일과 웹에서, 두 명의 동행자가, 비행기 안과 호텔에서 동시에 편집한다고 가정해 보세요. 누가 진실의 원천(source of truth)이 될지, 충돌이 났을 때 어떤 값을 살릴지는 단순한 문제가 아닙니다.

결국 단순하게 갔습니다. 모든 mutation을 3초 디바운스로 큐잉하고, push(로컬→서버) → pull(서버→로컬) 순서로 동기화하고, 서버를 진실의 원천으로 둡니다. 충돌이 나면 더보기 → 여행 동기화에서 수동 재시도. CRDT 같은 정교한 모델은 1인 개발 스코프에 안 맞다고 판단했고, 결과적으로 90%의 케이스를 단순한 last-write-wins로 잘 처리하고 있습니다.

오프라인 부분은 더 단순했습니다. 읽기는 항상 로컬 MMKV에서, 쓰기는 로컬 우선 + 서버 동기화 시도, 네트워크 없으면 큐에 쌓아두고 복구 시 자동 재시도. 이 구조 덕분에 비행기 모드에서도 일정 편집이 그대로 동작합니다.

4개 언어 동시 출시

알고노트는 한국어 + 영어였는데, 트립팝은 처음부터 한국어·영어·일본어·중국어 4개 언어로 만들었습니다. 일본·동남아·중국은 한국에서 가장 많이 가는 여행지인데, 영어만 지원하는 여행 앱은 일본인·중국인 사용자에게 거의 안 통합니다.

문제는 i18n을 처음부터 박아넣지 않으면 나중에 추가하는 비용이 5배쯤 든다는 것이었습니다. 그래서 첫 줄 코드부터 t('home.title') 같은 키를 썼고, 4개 언어 dict를 한 파일에 두고 빌드 타임에 검증했습니다. 마케팅 페이지·가이드 페이지·블로그도 같은 패턴.

지금 와서 보면 잘한 결정이었습니다. 출시 후 첫 일본어 사용자 피드백이 왔을 때, "이 한 줄 카피만 고치면 된다"는 자신감이 있었습니다.

출시 결정의 어려움

알고노트 때 배운 것이 그대로 여기서도 통했습니다. 출시 자체보다 출시를 결정하는 게 가장 어렵습니다.

"AI 갭 분석 더 정교하게 다듬고", "위젯도 만들고", "동기화 충돌 UI도 더 친절하게" — 이런 생각이 끝없이 듭니다. 하지만 핀테크 회사에서 11년간 배운 게 있다면, 사용자 한 명의 진짜 피드백 한 마디가 머릿속 가설 100개보다 가치 있다는 것입니다. 그래서 핵심 5개 기능 + 4개 언어로 끊고 출시했습니다.

App Store는 5번 리젝당했고, Play Store는 권한 정책 위반으로 한 번 막혔습니다. 둘 다 결국 통과시켰는데, 이런 마찰이 출시를 미루는 핑계가 되기 너무 쉬웠습니다. 그냥 한 번씩 더 시도하면 된다는 단순한 사실을 다시 배웠습니다.

다음 스텝

현재는 사용자 피드백을 기반으로 v1.4를 준비하고 있습니다. iOS 위젯, Apple Watch 일정 보기, 카드사 결제 연동, AI 여행 비교("하와이 vs 괌 4박 5일 어떤 게 맞나요?") 등이 후보입니다.

또 트립팝과 알고노트를 운영하면서 다음 사이드 프로젝트인 꿀주식(HoneyStock) 도 천천히 시작하고 있습니다. 이번에도 같은 패턴 — 명확한 도메인 문제, AI 활용, 1인 운영 가능한 스택.

마무리

AI와 함께 일하는 1인 개발은 속도가 아니라 결정의 질이 결과를 가른다는 것을 다시 한번 느꼈습니다. AI는 코드를 빠르게 써주지만, "어떤 코드를 쓸지"는 여전히 사람의 몫입니다. 11년 동안 시스템 설계를 하면서 쌓은 직관이 트립팝의 동기화 모델·오프라인 설계·i18n 전략에서 그대로 빛을 발했습니다.

트립팝은 tripop.app에서 받을 수 있습니다. App Store와 Google Play에서 "트립팝" 또는 "Tripop"으로 검색해도 나옵니다. 여행 좋아하시는 분들 한 번 써보시고 피드백 주세요.

사이드 프로젝트는 "언젠가"가 아니라 지금입니다.