TnT iOS — 다시 보는 화면을 다시 기다리지 않게

TnT는 트레이너의 회원·수업 관리와 트레이니의 운동·식단 기록을 연결하는 PT 관리 앱입니다. 이 저장소는 기존 TnT iOS를 포크해, 같은 화면을 다시 열 때마다 반복되던 API·이미지 요청과 대기 시간을 줄인 개선 프로젝트입니다.

분기 시점에는 테스트 메서드가 없었습니다. 제품 규칙과 실패 상태를 302개의 회귀 테스트로 먼저 고정하고, 사용자나 기록이 바뀌었을 때 잘못된 값을 재사용하지 않도록 도메인·이미지 캐시를 각각 설계했습니다. 다섯 재진입 플로우에서 대상 반복 요청을 모두 제거했고, 동일한 Profile 실행 파일로 진행한 100회의 유효 실기기 A/B에서 내부 완료 시점 p50이 74.9~97.5% 줄었습니다.

원본 프로젝트의 기획과 UI, Trainer·Trainee 플로우는 유지했습니다. 이후의 레이어 리팩토링과 테스트, 캐시 파이프라인, 실기기 측정은 직접 진행했습니다.

Diet Before/After · 실기기 측정 결과

개선 결과

Diet는 캘린더, 날짜별 식단, 상세 기록과 이미지를 차례로 다시 사용하는 플로우입니다. 캐시 적용 후에는 세 도메인 데이터와 상세 이미지를 원격 요청 없이 다시 사용했습니다.

사용자	다시 들어간 화면	대상 원본 요청	적용 전 → 적용 후 p50
Trainer	Home · 수업 목록	API 1회 → 0회	687.4 → 172.5ms · 74.9% 감소
Trainer	Home · 회원 프로필	이미지 6회 → 0회	1,937.9 → 183.4ms · 90.5% 감소
Trainee	Home · 식단 카드	이미지 3회 → 0회	1,490.0 → 171.2ms · 88.5% 감소
Trainee	Diet · 캘린더에서 식단 상세	API 3회·이미지 1회 → 모두 0회	1,092.6 → 212.6ms · 80.5% 감소
공통	MyPage · 내 정보	API 1회·이미지 1회 → 모두 0회	1,133.3 → 28.2ms · 97.5% 감소

캐시 설계

캐시 적중률보다 “지금 이 값을 다시 보여줘도 되는지”를 먼저 정했습니다. 빠르더라도 다른 사용자의 정보나 수정 전 기록(캐시)이 보이면 유저 경험은 더 나빠지기 때문입니다.

상황	적용한 기준
로그아웃·계정 전환	이전 사용자의 캐시를 비우고 세션별 데이터를 분리
식단·프로필 변경	관련 도메인 스냅샷을 무효화
TTL 만료	서버 요청이 실패했을 때만 오래된 스냅샷을 제한적으로 사용
이미지 URL 변경	늦게 끝난 이전 요청이 현재 화면을 덮지 못하게 차단
동일 URL 동시 요청	진행 중인 요청 하나를 공유
저장 공간	메모리·디스크 캐시의 크기와 수명을 제한하고 LRU로 정리

도메인 데이터와 이미지는 하나의 저장 구조로 묶지 않았습니다. 도메인 캐시는 세션과 기록 변경이 수명을 결정하고, 이미지 캐시는 URL과 디코딩 비용, 메모리 사용량을 중심으로 관리해야 했습니다.

캐시 저장 방식

캐시에 DTO나 화면 상태를 그대로 저장하지 않았습니다. Data에 도메인 친화적인 스냅샷을 저장하게 해 서버 응답 형식과 화면 생명주기에서 캐시 형식을 분리했습니다.

기록이 바뀐 뒤에는 개별 key를 찾아 지우는 대신 관련 세션 namespace를 비웠습니다. 다음 요청 비용은 감수하더라도 파생 조회 관계를 빠뜨려 수정 전 데이터를 보여주는 쪽이 더 위험하다고 판단했습니다.

동일한 작은 스냅샷 60개를 순차 저장·조회하는 디스크 기반 벤치마크 테스트에서 JSON은 초기화·저장·조회가, CoreData는 일괄 정리와 저장 공간이 유리했습니다. 어느 한쪽의 전면적인 성능 우위는 확인되지 않았고, 현재 접근 패턴에서는 CoreData의 추가 복잡도를 감수할 근거도 부족했습니다. 본 프로젝트 범위에서는 CoreData 유지보수 비용에 비해 확연한 CoreData 사용의 이득이 없어 JSON을 기본 저장 방식으로 유지했습니다.

리팩토링과 테스트

기존 프로젝트는 레이어별 모듈로 나뉘어 있었지만, 입력 검증과 세션 판단이 TCA Reducer에 남아 있었고 Domain이 네트워크 DTO와 Mapper를 알고 있었습니다. 네트워크와 Keychain 같은 외부 의존성도 실패 상황을 재현하기 어려운 형태였습니다.

기존 동작을 테스트로 고정 → 책임 분리 → 실패 상태 재현 → 캐시 적용 → 실제 화면 A/B

기존 구조	리팩토링 후
Reducer가 입력 검증, 기록 초안, 세션 시작 조건까지 판단	Domain validator와 policy가 제품 규칙을 판단
Domain이 DTO와 Mapper를 소유	DTO, 요청 payload, 매핑 책임을 Data로 이동
외부 의존성의 실패 결과를 만들기 어려움	네트워크·Keychain·푸시 저장 경로를 주입 가능한 인터페이스로 분리
실패 뒤에도 성공 상태로 넘어갈 수 있음	실패 시 기존 화면 상태를 유지하도록 테스트로 고정

현재 302개의 제품 회귀 테스트가 입력 규칙, 세션, 네트워크 실패, 캐시 생명주기와 화면 상태 전환을 검증합니다. 기존 동작과 실패 상태를 테스트 코드로 먼저 재현한 다음 안전하게 리팩토링을 진행했습니다.

성능 측정

같은 Profile 실행 파일에서 cache-bypass(캐시 X)와 cache-enabled(캐시 O)를 실행 시점에 선택하고, 같은 화면을 번갈아 실행했습니다.

Trainer Home 30회, Trainee Home 30회, Diet 20회, MyPage 20회로 총 100회의 유효 실행을 수집했습니다. 대상 요청 수와 내부 완료 시점, 이미지 메모리, Release 측정 코드 제외, 기존 기능이 다시 깨지지 않는지를 함께 확인했습니다. 다섯 플로우의 지연 시간은 모두 개선됨으로 판정됐고, 이미지 경로는 20개 측정 묶음·120회 재진입에서 메모리 가드레일을 통과했습니다.

측정값은 사용자 동작 시작부터 내부 종료 marker까지 걸린 시간입니다. 표본 수와 판정 기준은 PortfolioPerformanceV2에 정리했습니다.

코드 살펴보기

구현

1. Domain / Data: 화면에서 분리한 제품 규칙과 네트워크 책임
2. DomainCacheEngine.swift: 세션 namespace, TTL, 스냅샷 저장과 정리
3. CachedRemoteImage.swift: URL identity, generation guard, 메모리·디스크·원격 로딩
4. TNT_PERFORMANCE_VARIANTS: 동일 실행 파일의 runtime A/B

대표 테스트

확인할 내용	대표 테스트
세션 시작과 식단 입력 규칙	SessionBootstrapPolicyTests · DietRecordDraftValidatorTests
도메인 캐시의 fresh·stale·cleanup	DomainCacheEngineTests
repository 캐시 hit과 변경 후 무효화	TrainerRepositoryCacheTests · TraineeRepositoryCacheTests
이미지 URL identity와 generation guard	CachedRemoteImageTests
실제 화면 측정 조건	ScreenUseCasePerformanceMeasurementTests

성능 근거

• PortfolioPresentationV1: Diet Before/After 영상과 이미지
• PortfolioPerformanceV2: 다섯 플로우의 표본 수, p50, 판정과 요청 수
• 163684bc: 원본 TnT iOS의 프로젝트 기준점

원본 trace와 개발 서버 로그는 공개하지 않았습니다. 공개 가능한 측정 결과와 검증 범위는 PortfolioPerformanceV2에서 확인할 수 있습니다.

---

Tech · iOS 17 · SwiftUI · The Composable Architecture · Clean Architecture · Tuist 4.188.0

Measured on · Profile · iPhone 13 Pro · iOS 26.5.2