Swifty Healthy: 아키텍처 설계와 기술 선정의 여정

이 문서는 app-swifty-healthy 프로젝트가 왜 시작되었고, 어떤 구조로 설계되었으며, 왜 하필 이 기술들을 사용했는지에 대한 상세한 기록입니다. 단순한 기술 나열이 아닌, **"왜(Why)"**에 초점을 맞추어 작성되었습니다.

---

1. 개발 동기 (Motivation)

"건강 관리는 왜 귀찮을까?"

현대인에게 건강 관리는 필수지만, 식단과 운동을 매번 수기로 기록하는 것은 매우 번거로운 일입니다.

• 문제점: 기존 앱들은 사용자가 직접 칼로리를 검색하고 입력해야 하는 수고로움이 있었습니다.
• 해결책: "사진 한 장으로 끝내는 기록". 사용자가 식단이나 운동 완료 화면을 캡처해서 올리면, AI가 이를 분석해 자동으로 데이터를 입력해주는 서비스를 기획하게 되었습니다.

이 아이디어를 실현하기 위해 멀티모달(Multimodal) AI 능력이 필수적이었고, 이를 모바일 앱으로 구현하여 접근성을 높이고자 했습니다.

---

2. 시스템 아키텍처 (System Architecture)

초기에는 클라이언트 중심의 구조였으나, 보안과 확장성을 위해 Client-Server 구조로 진화했습니다.

• Frontend: 사용자 인터랙션과 데이터 시각화 담당.
• Backend: AI 분석 요청 중계, 데이터 영속성 관리, 인증 처리 담당.
• Infra: 완전 관리형(Serverless) 서비스를 사용하여 운영 비용 최소화.

---

3. Frontend 기술 스택 및 선정 이유

Framework: React Native with GraniteJS

• 선정 이유:
  • Cross-Platform: iOS와 Android를 하나의 코드베이스로 대응.
  • GraniteJS: React Native 프로젝트의 구조를 잡아주는 프레임워크입니다. Next.js처럼 **파일 기반 라우팅(File-based Routing)**을 제공하여, 복잡한 네비게이션 설정을 직관적인 폴더 구조로 해결할 수 있어 도입했습니다.

UI Library: Toss Design System (TDS) for React Native

• 선정 이유:
  • 완성도 높은 디자인: 토스 앱 특유의 깔끔하고 직관적인 UI 컴포넌트를 즉시 사용할 수 있습니다.
  • 생산성: 버튼, 리스트, 토스트 메시지 등 기본 컴포넌트를 처음부터 만들 필요 없이 비즈니스 로직 구현에 집중할 수 있었습니다.

State Management: Zustand

• 선정 이유: "Simple, Fast, Scalable"
• 대안 비교:
  • vs Redux: Redux는 강력하지만 보일러플레이트(Action, Reducer, Selector 등)가 너무 많아 초기 설정과 유지보수 피로도가 높습니다.
  • vs Context API: 렌더링 최적화가 어렵고, 상태가 복잡해지면 Provider 지옥(Wrapper Hell)에 빠지기 쉽습니다.
  • Zustand의 이점: Hook 기반으로 사용이 매우 간편하며, 불필요한 리렌더링을 방지하는 Selector 패턴을 기본 지원합니다. 전역 상태를 마치 로컬 변수처럼 직관적으로 다룰 수 있어 도입했습니다.

Server State: TanStack Query (React Query)

• 선정 이유:
  • 상태 분리: 클라이언트 상태(UI)와 서버 상태(DB 데이터)를 명확히 분리하기 위함입니다.
  • 자동화된 기능: 캐싱(Caching), 중복 요청 제거(Deduplication), 백그라운드 업데이트(Refetch on window focus) 등 서버 데이터를 다룰 때 필요한 복잡한 기능을 설정 한 줄로 해결해줍니다.

Linting & Formatting: Biome

• 선정 이유:
  • 속도: Rust로 작성되어 기존의 ESLint + Prettier 조합보다 압도적으로 빠릅니다.
  • 통합성: 린터와 포매터가 하나로 합쳐져 있어 설정 충돌 걱정이 없고 관리가 간편합니다.

---

4. Backend 기술 스택 및 선정 이유

⚡ Framework: FastAPI

• 선정 이유:
  • 비동기(Async) 네이티브: Python의 asyncio를 기본 지원하여, AI API 호출이나 DB 조회 같은 I/O 바운드 작업에서 높은 성능을 냅니다.
  • 생산성: Pydantic 모델을 통한 자동 데이터 검증과 Swagger UI 자동 생성 기능은 개발 속도를 획기적으로 높여줍니다.
  • AI 생태계: Python 기반이므로 Google Gemini SDK 등 AI 라이브러리와의 통합이 가장 매끄럽습니다.

Database Driver: AsyncPG

• 선정 이유:
  • 성능: Python 진영에서 가장 빠른 PostgreSQL 드라이버입니다. psycopg2보다 벤치마크 상 훨씬 높은 처리량을 보여줍니다.
  • 비동기 지원: FastAPI의 비동기 특성을 100% 활용하기 위해, DB 연결도 Non-blocking으로 처리해야 했습니다.

AI Model: Google Gemini API

• 선정 이유:
  • 멀티모달 성능: 이미지와 텍스트를 동시에 이해하는 능력이 탁월합니다. 식단 사진을 보고 "이건 500칼로리짜리 김치찌개입니다"라고 분석해내는 정확도가 높았습니다.
  • 비용 효율성: GPT-4 Vision 등 경쟁 모델 대비 가격 경쟁력이 우수하거나, 무료 티어(Free Tier) 활용이 용이했습니다.

---

5. Infrastructure 선정 이유

Compute: Google Cloud Run

• 선정 이유:
  • Serverless: 서버를 직접 관리할 필요가 없습니다.
  • Scale to Zero: 트래픽이 없을 때는 인스턴스를 꺼두어 비용이 0원입니다. 사이드 프로젝트나 초기 스타트업에 최적화된 모델입니다.

Database: Google Cloud SQL

• 선정 이유:
  • 완전 관리형: 백업, 패치, 복제 등을 구글이 알아서 관리해줍니다.
  • 보안: Cloud Run과 동일한 VPC 내에서 Unix Socket으로 연결하여, Public IP를 노출하지 않고 안전하게 통신할 수 있습니다.