Tangly가 Expo, Next.js, Vercel, Supabase를 쓰는 이유

Tangly는 모바일 앱 하나만 만드는 프로젝트가 아니다. 피부 분석을 하는 앱, 운영자가 콘텐츠를 바꾸는 관리자, 광고주가 지표를 확인하는 포털, 그리고 기술 기록을 남기는 블로그가 함께 움직인다.

그래서 기술 선택의 기준은 유행보다 속도와 연결성이었다. 혼자 또는 작은 팀이 빠르게 만들 수 있고, 모바일과 웹이 같은 데이터와 API를 바라볼 수 있으며, 배포와 운영이 너무 무겁지 않아야 했다.

모바일은 Expo를 중심으로 만들었다. Tangly에는 카메라, 이미지 선택, 이미지 처리, 푸시 알림, 라우팅, 폰트, 햅틱처럼 앱에서 자주 필요한 기능이 많다. Expo는 이런 기능들을 한 번에 다루기 좋게 묶어준다.

특히 초기 제품에서는 iOS와 Android를 따로 깊게 파고들기보다, 같은 React Native 코드로 화면과 흐름을 빠르게 검증하는 것이 중요했다. 피부 분석, 리포트, 루틴, 샵 같은 기능을 계속 바꾸는 단계에서는 개발 속도가 큰 장점이었다.

Expo Router를 쓰면 모바일 앱의 화면 구조를 파일 기반으로 관리할 수 있다. 웹에서 Next.js를 쓰는 감각과도 비슷해서, 모바일과 웹을 오가며 작업할 때 머릿속 구조가 덜 흔들린다.

웹은 Next.js로 만들었다. 관리자 콘솔, 광고주 포털, 블로그, API 라우트를 한 프로젝트 안에서 다룰 수 있기 때문이다. Tangly처럼 운영 화면과 서버 API가 계속 함께 늘어나는 프로젝트에는 이 구조가 잘 맞았다.

관리자는 배너, 이벤트, 미션, 세일 알림, 광고를 다루고, 모바일 앱은 그 데이터를 API로 읽어간다. Next.js의 App Router와 Route Handler를 쓰면 화면과 API를 같은 코드베이스에서 같이 진화시킬 수 있다.

블로그도 같은 웹 앱 안에 두었다. 별도 CMS를 먼저 붙이기보다, 지금은 우리가 만든 기능을 코드 가까이에 기록하는 편이 더 빠르고 안전했다.

Vercel은 Next.js 배포 흐름이 단순하다. GitHub에 푸시하면 빌드와 배포가 이어지고, 도메인과 SSL도 프로젝트 설정 안에서 관리할 수 있다.

이번에 tangly.kr을 연결하면서 nacho, ad, blog 같은 서브도메인을 나눴다. 같은 앱을 쓰되, 접속한 host에 따라 관리자, 광고주 포털, 블로그로 보내는 방식이다. 작은 팀 입장에서는 프로젝트를 여러 개로 쪼개기 전에 이렇게 시작하는 편이 운영 부담이 낮다.

배포가 쉬우면 제품을 더 자주 다듬을 수 있다. Tangly처럼 관리자 화면과 모바일 API를 계속 수정하는 프로젝트에서는 배포 파이프라인이 가벼운 것이 큰 이점이다.

Supabase는 데이터베이스, 인증, 스토리지 역할을 함께 맡는다. Tangly에는 사용자, 리포트, 배너, 이벤트, 광고, 푸시 토큰, 이미지 같은 데이터가 많고, 이 데이터들이 서로 연결된다.

Postgres 기반이라 SQL로 구조를 명확히 남길 수 있는 점도 좋았다. 광고 시스템처럼 advertisers, ad_banners, ad_impressions, ad_clicks가 연결되는 구조는 SQL 파일로 남겨두면 나중에 다시 이해하기 쉽다.

이미지 업로드도 여러 기능에서 반복된다. 분석 사진, 프로필 사진, 이벤트 이미지, 배너 이미지를 다뤄야 해서, 데이터와 스토리지가 가까이 있는 구조가 개발 속도에 도움이 됐다.

제품이 실제로 배포되면 로컬에서 보이지 않던 문제가 생긴다. 웹에는 Sentry 설정을 붙여 배포 후 문제를 확인할 수 있게 했다.

초기에는 완벽한 관찰 시스템보다 에러가 어디서 나는지 놓치지 않는 것이 중요하다. 특히 관리자와 API는 문제가 생기면 운영이 바로 막히기 때문에, 배포 후 확인 장치가 필요했다.

지금 스택의 가장 큰 장점은 한 사람이 전체 흐름을 이해하기 쉽다는 점이다. 모바일은 Expo, 웹과 API는 Next.js, 배포는 Vercel, 데이터는 Supabase로 역할이 나뉘어 있다.

물론 나중에 사용자가 늘면 더 깊게 고민해야 할 부분도 생긴다. 성능, 비용, 권한 분리, 데이터 보존 정책, 이미지 최적화, 배포 환경 분리는 계속 점검해야 한다.

하지만 초기 Tangly에는 빠르게 만들고, 운영자가 직접 바꾸고, 앱과 웹이 같은 제품 방향으로 움직일 수 있는 구조가 더 중요했다. 그래서 이 조합은 지금 단계의 Tangly에 꽤 잘 맞는다.