TnT

트레이너와 트레이니를 연결하다

PT 효과가 미미하거나, 꾸준히 PT를 지속하기 어려웠나요? 트레이너와 트레이니 사이의 체계적인 소통과 효율적인 PT 운영을 직접 경험하세요 :)

💪🏻 트레이너는 체계적인 회원 관리를, 트레이니는 효율적인 기록을!
🏋 TnT와 함께 트레이너와 트레이니의 케미를 터트려보세요!

---

TnT iOS Testing Lab

이 저장소는 TnT 본 프로젝트에서 분기해 만든 iOS 실험장 입니다. 새 제품 기능을 보여주는 레포라기보다, 실제 앱 코드 위에서 구조 리팩토링, 테스트 보강, 네트워크 정책 정리, 로컬 캐싱 성능 개선을 실험하고 정리한 작업 공간입니다. 본래 TnT 프로젝트에서 분리된 분기점 커밋은 163684bc입니다.

Testing Lab 작업 내용

TnT 앱은 Trainer와 Trainee 플로우가 분리돼 있고, 네트워크 응답·세션 상태·입력 검증·이미지 로딩이 여러 화면에 걸쳐 있습니다. Testing Lab에서는 실제 앱 흐름을 유지한 채 테스트/개선 가능한 지점을 늘렸습니다.

---
title: Testing Lab 작업 흐름
---
flowchart LR
  Start[기존 TnT iOS] --> Domain[Domain 규칙 분리]
  Domain --> Data[Data / Network 책임 정리]
  Data --> Tests[모듈별 테스트 보강]
  Tests --> Cache[도메인 snapshot cache]
  Cache --> Image[이미지 cache pipeline]
  Image --> Portfolio[성능 개선 근거 정리]

Loading

작업의 중심은 화면 규칙의 Domain 이동, 서버 응답 구조와 앱 도메인 모델 분리, 반복 진입 화면의 네트워크 요청 감소입니다.

1. Domain 규칙을 화면 밖으로 이동

온보딩과 기록 화면에 있던 입력 검증을 Domain UseCase와 policy로 옮겼습니다. 화면은 사용자 입력과 상태 표시를 맡고, 규칙 판단은 Domain 테스트에서 확인할 수 있게 했습니다.

트레이니 연결 입력, 이름/주의사항/PT 목적 입력, PT 수업 초안, 식단 기록 초안, 세션 확인 결과와 앱 시작 라우팅 정책을 이 범위에서 다뤘습니다.

이 작업으로 reducer 안의 조건 분기를 줄이고, 규칙 변경이 생겼을 때 Domain 테스트를 먼저 볼 수 있게 했습니다.

2. Data와 Domain 책임 분리

서버 응답 DTO, request payload, mapper 책임을 Data 레이어로 옮겼습니다. Domain에는 앱 내부에서 쓰는 Entity와 Repository protocol만 남기고, 서버 JSON 구조는 Data에서 다루도록 정리했습니다.

---
title: Data와 Domain 책임 분리
---
flowchart TB
  subgraph Domain[Domain]
    Entity[Entity]
    UseCase[UseCase]
    Contract[Repository protocol]
  end

  subgraph Data[Data]
    DTO[Response DTO]
    Payload[Request payload]
    Repo[Repository impl]
    Network[Network service]
  end

  UseCase --> Contract
  Contract --> Repo
  Repo --> DTO
  Repo --> Payload
  Repo --> Network

Loading

3. 네트워크 정책을 테스트로 고정

URLSession 기반 네트워크 서비스에서 실패 응답과 세션 상태가 화면마다 다르게 보이지 않도록 정책을 분리했습니다. 성공 요청보다 실패 경로를 더 중요하게 봤습니다.

인증 토큰 로딩 실패, 세션 만료 feedback, 진행 표시 feedback, 응답 오류 fallback, multipart 요청, 빈 응답 mutation ack를 이 범위에서 확인했습니다.

NetworkServicePolicyTests, AuthTokenInterceptorTests, ResponseValidatorInterceptorTests 같은 테스트가 이 정책을 고정합니다.

4. 로컬 캐싱 성능 개선

캐싱은 API 응답을 그대로 저장하는 방식이 아니라, 사용자가 같은 화면으로 다시 돌아왔을 때 다시 받을 필요가 없는 데이터를 줄이는 방향으로 잡았습니다.

도메인 데이터는 Data 레이어의 snapshot cache로 다루고, 이미지는 Presentation의 image pipeline으로 분리했습니다.

---
title: 도메인 cache와 이미지 cache 분리
---
flowchart LR
  Screen[화면 재진입] --> Repo[Repository]
  Repo --> Fresh{fresh cache?}
  Fresh -->|hit| Snapshot[Domain snapshot]
  Fresh -->|miss| API[Network API]
  API --> Snapshot

  Screen --> ImageView[CachedRemoteImage]
  ImageView --> Memory[Memory cache]
  ImageView --> Disk[Disk cache]
  ImageView --> Remote[Remote image]

Loading

도메인 모델 캐시는 세션 namespace와 요청 파라미터를 key에 포함합니다. 수정 성공 뒤에는 관련 캐시를 지워, 수정 후 이전 snapshot이 다시 보이지 않게 했습니다.

이미지 캐시는 URL hash key, memory/disk cache, in-flight coalescing, disk TTL/capacity/LRU cleanup을 따로 둡니다.

성능 개선 결과

수치는 request count 기준입니다. byte 전송량, 화면 표시 시간, FPS는 별도로 측정하지 않았습니다.

사용자 플로우	변경 전 warm 재진입	변경 후 warm 재진입	의미
Trainer 홈 재진입	전체 서버 라우트 7회	전체 서버 라우트 1회	남은 1회는 앱 진입 시 필요한 GET /check-session
Trainer 홈 콘텐츠 재조회	도메인 API 4회 + 이미지 요청 2회	캐시 대상 요청 0회	수업/회원 콘텐츠와 반복 이미지를 local cache hit로 처리
Trainee 홈/식단 확인	홈 API 2회, 식단 상세 API 1회 + 이미지 요청 1회	각 warm flow 요청 0회	날짜별 홈 정보와 식단 상세를 다시 받을 필요를 줄임
MyPage/Profile	/members 1회	/members 0회	내정보 데이터를 local cache hit로 처리

캐시는 빠르게 보여주고 서버 부하를 줄이는 것만으로 충분하지 않습니다. 캐시 적용 작업 이후 fresh TTL, stale fallback, mutation invalidation, session namespace, capacity/LRU 기준까지 함께 정리했습니다.

테스트 범위

모듈	테스트 예시
Domain	SessionBootstrapPolicyTests, TraineeValidationUseCaseTests, DietRecordDraftValidatorTests
Data	NetworkServicePolicyTests, AuthTokenInterceptorTests, ResponseValidatorInterceptorTests, TraineeRepositoryCacheTests, TrainerRepositoryCacheTests, UserRepositoryCacheTests
Presentation	TrainerHomeFeatureTests, CachedRemoteImageTests

기술 환경과 코드 구조

• iOS 17.0, Xcode 16.0.1, Tuist 4.37.0
• SwiftUI / TCA / Clean Architecture
• FirebaseMessaging / Kakao iOS SDK / FSCalendar
• TnT/Projects: TnTApp, Presentation, Domain, Data, DIContainer, DesignSystem