1. 상황

엄마 그림을 올리는 갤러리 웹사이트(Next.js)를 만들어 둔 상태였는데, 제작이 보류돼 있었다. 이유는 하나였다. 엄마는 거의 핸드폰만 쓰는데, 모바일에서 웹사이트로 들어가 관리하는 걸 어려워했다. 외부에서 찾아오기 쉽게 하려고 웹으로 만들었는데, 정작 그림을 올리는 사람이 웹을 쓰기 힘든 상황이었다.

그래서 AI(Claude)에게 이렇게 물었다. 엄마의 사이트 관리는 앱으로 하고, 외부 유입은 웹으로 받고, 앱을 통해 들어오는 길도 열어 두고 싶은데 어떻게 하면 되냐고.

2. AI가 처음 내놓은 구조

첫 제안은 데이터를 Firebase(Auth, Firestore, Storage)에 두고, 관리는 엄마 전용 앱, 노출은 지금의 웹으로 나누는 구조였다.

[엄마 폰: 관리 앱] ──쓰기──▶ Firebase ◀──읽기── [웹사이트] ◀── 외부 방문자

앱은 두 가지 모드로 만들자는 제안도 같이 나왔다.

• 앱 첫 화면은 누구나 보는 공개 갤러리(작가 소개, 작품 목록, 작품 상세)
• 엄마 계정으로 로그인하면 작품 올리기, 수정, 삭제 메뉴가 열림
• 웹 링크를 눌렀을 때 앱이 있으면 앱에서, 없으면 웹에서 열리는 딥링크(Android는 App Links)

Flutter Web으로 웹까지 한 코드로 만드는 방법도 후보로 나왔다. 하지만 검색 노출(SEO)과 첫 로딩이 약해서, 외부 유입이 목적이면 기존 Next.js 웹을 유지하는 쪽이 낫다는 설명이었다. 여기까지는 "관리는 앱, 노출은 웹, 데이터는 한 곳"이라는 큰 틀이 잡힌 단계다.

3. 되물어서 바뀐 첫 번째: Flutter에서 Jetpack Compose로

AI는 관리 앱을 Flutter로 추천했다. 나는 이렇게 되물었다. "그럼 프로젝트 자체가 공유를 안하는데 플루터로 할 이유가 있어?"

AI의 답은 이랬다. 웹과 앱이 코드를 공유하지 않으면 Flutter를 고를 기술적 이유는 없고, 남는 이유는 내가 이미 Flutter/Dart로 앱을 여러 개 출시해 봤다는 익숙함 하나뿐이라고 했다. 그러면서 Expo(React Native)와 PWA/Capacitor도 같이 비교했다.

• Expo: 타입과 Firebase 로직 일부는 공유할 수 있지만 UI는 어차피 따로 만들어야 해서, 모노레포까지 구성하는 건 이 규모에는 과함
• PWA/Capacitor: 새로 배울 게 가장 적지만 결국 웹뷰라서 앱만큼 매끄럽지 않음

여기서 내가 한 줄을 더했다. "난 컴포즈가 더 익숙해". AI가 세운 기준("익숙한 도구가 가장 빠르다")이 그대로 Compose를 가리키게 됐다. 단점은 iPhone에서는 앱을 쓸 수 없다는 점인데, 방문자는 웹이 항상 열려 있으니 앱은 "Android 사용자를 위한 추가 경로"로 두면 된다고 정리됐다.

[확인 필요: 엄마 폰이 Android인지 — AI가 두 번 물었는데 이 대화에서는 답이 확인되지 않음]

4. 되물어서 바뀐 두 번째: Firestore에서 집 서버 DB로

데이터 저장소도 처음엔 Firebase로 가는 흐름이었다. 그때 나는 집에 서버가 있는데 거기에 DB를 두고 쓰면 되지 않냐고 물었다.

AI는 Firestore가 필수는 아니라고 인정하고, 실제로 갈리는 건 두 가지라고 짚었다.

• 가동 시간: 정전, 공유기 재부팅, 인터넷 장애, DDNS 갱신 지연이 생기면 웹과 앱이 같이 멈춘다
• 이미지 트래픽: 무거운 건 DB가 아니라 이미지이고, 가정용 인터넷은 업로드 속도가 느릴 수 있다

Firestore의 장점은 서버 운영과 백업 부담이 없고 앱 오프라인 캐시가 기본이라는 점, 단점은 구글 서비스에 묶이고 쿼리가 제한적이라는 점이었다.

이어서 Next.js를 웹으로 쓰면서 백엔드 기능도 어느 정도 같이 할 수 있지 않냐고 물었다. 가능하다는 답이 왔다. Next.js의 Route Handlers(app/api/.../route.ts)로 REST API를 만들면 웹이 쓰는 데이터와 앱이 쓰는 데이터를 같은 서버에서 내줄 수 있어서, 갤러리용 NestJS 서버를 따로 둘 필요가 없다는 것이다.

그리고 "일단 집에서 하고 추후 외부 고려"로 정했다. 스택은 Next.js + Docker + PostgreSQL + Prisma로 갔다. SQLite가 아니라 PostgreSQL인 이유로 AI가 든 건, SQLite는 파일 DB라서 나중에 웹만 외부로 옮기면 접근할 방법이 마땅치 않다는 점이었다.

나중에 옮길 때를 위한 원칙도 두 가지 정했다.

• DB 접근은 lib 서비스 레이어로만 하고, 화면과 API는 DB를 직접 건드리지 않는다
• 앱이 쓰는 API 경로는 처음부터 /api/v1/...처럼 버전을 붙인다. 한번 배포한 앱은 사용자가 업데이트하기 전까지 옛 API를 계속 부르기 때문이다

[보강: 내가 Firestore 대신 집 서버 DB를 최종 선택한 이유 — 직접 쓴 한두 문장]

5. 화면 구조와 앱 요구사항

• 메인 화면은 이전 사이트처럼 전체 화면 슬라이더로 연출만 맡기고, 실제 그림 감상은 별도 "작품" 코너(/artworks)에서 하기로 했다.
• 앱은 방문자용과 엄마용 관리 기능을 한 앱에 합치고, 네이티브 Android(Kotlin)로 만든다. 엄마가 쓰는 앱이라 사용감이 좋아야 하고, 자동 로그인이 되어야 한다는 게 요구사항이었다.
• 웹은 PC용과 모바일용을 따로 만들지 않고 반응형 하나로 간다. 옛 코드에서 모바일에서 깨질 곳으로는 네비게이션(메뉴 5개가 한 줄이라 햄버거 메뉴 필요), 최상위 h-screen을 min-h-screen으로, 슬라이더의 100vh를 100dvh로, 작가 소개의 <br /> 제거와 break-keep 적용이 짚였다.

정리

• 웹은 유입(검색, 공유), 관리는 앱, 데이터는 한 곳으로 역할을 나누니 "엄마가 쓰기 힘든 웹" 문제가 풀렸다
• 웹과 코드를 공유하지 않으면 크로스 플랫폼을 고를 이유가 약하다. 결국 익숙한 도구가 기준이 됐다
• Firestore는 필수가 아니었다. 가동 시간과 이미지 트래픽을 감수하면 집 서버 DB로도 된다
• 나중에 옮길 가능성이 있으면 DB 접근을 서비스 레이어로 모으고 API에 버전을 붙여 둔다

다음 글 예고

다시 꺼낸 옛 코드를 로컬에서 처음 돌리다 npm install부터 막힌 이야기를 쓴다.