모바일 개발에서 Time-to-Interactive: 정의, 지표 및 측정

Time-to-Interactive란

Time-to-Interactive는 페이지 또는 애플리케이션이 사용자의 완전한 상호작용을 위해 준비된 순간을 포착하는 성능 지표입니다. 웹 컨텍스트에서 TTI는 탐색 시작부터 세 가지 조건이 충족될 때까지의 시간으로 정의됩니다: 페이지가 유용한 콘텐츠를 표시했음(First Contentful Paint), 메인 스레드가 최소 5초 동안 유휴 상태였음, 모든 이벤트 리스너가 등록되었음. 모바일 애플리케이션에서 TTI는 Activity 시작부터 UI 초기화가 완료될 때까지의 시간으로, 모든 상태가 로드되고 애니메이션이 구성되며 사용자가 지연 없이 모든 버튼을 탭할 수 있습니다.

이 지표는 첫 번째 상호작용이 중요한 애플리케이션(로그인 화면, 검색, 결제)에 특히 중요합니다. TTI가 5초를 초과하면 사용자는 앱이 “멈춤” 상태라고 인식하고 앱을 닫을 수 있습니다. Google(Web Vitals Report, 2025)에 따르면 TTI가 3.8초 미만인 페이지는 TTI가 7초를 초과하는 페이지보다 24% 더 많은 전환율을 보입니다. 그 차이는 500ms에서도 느껴집니다. Amazon의 연구에 따르면 100ms 지연마다 1%의 매출 손실이 발생합니다.

TTI 계산 방법

TTI 계산 알고리즘은 W3C 사양에 정의되어 있으며 Lighthouse에 구현되어 있습니다. 계산은 First Contentful Paint(FCP)부터 시작됩니다. 이는 브라우저가 콘텐츠의 첫 번째 픽셀을 렌더링하는 순간입니다. 그런 다음 알고리즘은 “정적 창”을 찾습니다. 이는 메인 스레드에서 50ms를 초과하는 작업이 없는 5초 기간입니다. TTI는 이 창 이전의 마지막 작업으로 설정됩니다. 15초 이내에 정적 창이 발견되지 않으면 TTI는 마지막 긴 작업의 시간으로 설정됩니다. 이 알고리즘은 TTI가 렌더링 순간뿐만 아니라 상호작용에 대한 실제 준비 상태를 반영하도록 보장합니다.

모바일 애플리케이션(Android/iOS)에는 W3C 사양의 정확한 동등물이 없지만 개념은 동일합니다. TTI는 onResume(시작)과 모든 비동기 작업이 완료된 첫 번째 프레임의 콜백에서 타임스탬프를 캡처하여 측정할 수 있습니다. Firebase Performance를 사용하면 사용자의 대화형 세션 시작 및 종료와 함께 사용자 지정 추적을 설정할 수 있습니다. 예를 들어, Application.onCreate에서 startTrace(“TTI”)를 호출하고 모든 SDK가 초기화되고 첫 번째 프레임이 렌더링된 후 stopTrace()를 호출합니다.

TTI 사용자 지정 추적 예시

Kotlin 코드는 Firebase Performance를 사용한 TTI 측정을 보여줍니다. 추적은 Application.onCreate에서 시작되고 첫 번째 reportFullyDrawn 후에 중지됩니다.

class App : Application() {

    private var ttiTrace: Trace? = null

    override fun onCreate() {
        super.onCreate()
        ttiTrace = Firebase.performance
            .newTrace("tti")
        ttiTrace?.start()
    }

    fun stopTtiTrace() {
        ttiTrace?.stop()
        ttiTrace = null
    }
}

TTI, FCP, LCP 및 FID: 차이점

Core Web Vitals 생태계에는 여러 지표가 있으며, TTI는 종종 First Contentful Paint(FCP) 및 Largest Contentful Paint(LCP)와 혼동됩니다. FCP는 상호작용을 보장하지 않는 콘텐츠의 첫 번째 픽셀이 렌더링되는 시간입니다. LCP는 가장 큰 콘텐츠 요소(이미지, 텍스트 블록)의 렌더링 시간입니다. 그러나 TTI는 렌더링이 아닌 상호작용에 대한 준비 상태를 측정합니다. 그 차이는 중요합니다. FCP는 1.2초일 수 있지만 메인 스레드가 JS 번들 로딩으로 차단되면 TTI는 8초에 도달할 수 있습니다.

First Input Delay(FID)는 사용자의 첫 번째 작업과 브라우저가 이벤트 처리를 시작하는 순간 사이의 지연을 측정합니다. FID는 “상호작용의 품질”인 반면 TTI는 “상호작용까지의 시간”입니다. TTI가 인터페이스가 응답할 때까지의 시간(초)을 나타내는 경우 FID는 응답 정도를 나타냅니다. 메인 스레드가 차단되면 TTI가 높아지고 FID가 모든 상호작용을 지연시키므로 좋은 TTI는 좋은 FID 없이는 불가능합니다. 모바일 애플리케이션에서 FID의 동등물은 Touch Latency(터치 지연 시간)로, 화면 터치와 UI 응답 사이의 지연입니다.

모바일 애플리케이션에서 TTI

네이티브 모바일 애플리케이션에서 TTI의 개념은 웹처럼 표준화되어 있지 않지만 그 중요성은 줄어들지 않습니다. Android에서 TTI는 앱 아이콘을 탭한 순간부터 UI가 완전히 대화형이 될 때까지의 시간입니다: RecyclerView 스크롤, 버튼 탭 반응, 애니메이션 원활한 실행. Android에서 TTI를 측정하려면 reportFullyDrawn(API 29+)과 FrameMetricsAggregator의 조합을 사용합니다. reportFullyDrawn은 개발자가 UI가 준비되었다고 판단할 때 앱이 수행하는 호출입니다. 시스템은 이 순간을 캡처하여 Android Vitals 보고서에 포함합니다.

iOS에서 TTI의 동등물은 Time to First Frame 및 Time to Responsive입니다. MetricKit는 실행 파일 로드, 프레임워크 초기화, 첫 번째 프레임 렌더링과 같은 단계로 구분된 시작 시간 데이터를 수집합니다. Apple은 Time to First Frame이 400ms를 초과하지 않고 완전한 상호작용이 2초 이내에 달성될 것을 권장합니다. 앱이 플레이스홀더 화면을 표시한 다음 콘텐츠를 로드하는 경우 TTI는 첫 번째 프레임이 아닌 실제 콘텐츠가 상호작용할 준비가 된 순간부터 계산됩니다.

FrameMetrics를 통한 Android TTI 측정

Kotlin 코드는 FrameMetricsAggregator를 사용하여 첫 번째 대화형 프레임을 추적합니다. 사용자가 시작한 첫 번째 프레임이 완료되면 콜백이 실행됩니다.

class TtiTracker(private val activity: Activity) {

    private val metrics = FrameMetricsAggregator()
    private var startTime = 0L

    fun onStart() {
        startTime = System.nanoTime()
        metrics.add(activity.window)
    }

    fun onFirstFrame() {
        val ttiMs = (System.nanoTime() - startTime) / 1_000_000
        Log.d("TTI", "Time to Interactive: $ttiMs ms")
        metrics.reset()
    }
}

TTI 최적화 방법

TTI 최적화에는 세 가지 방향이 있습니다: 메인 스레드 작업 부하 감소, 중요하지 않은 구성 요소의 지연 로드, 점진적 렌더링. 첫 번째 방향은 동기 작업 최소화입니다: SharedPreferences를 DataStore로 대체, SDK 초기화를 백그라운드 스레드로 이동, Dagger/Hilt 모듈 지연 로드. 두 번째는 지연 로드입니다: 시작 시 표시되지 않는 화면(바텀 시트, 대화상자, 탭)은 첫 번째 프레임 후에 초기화되어야 합니다. 세 번째는 점진적 렌더링입니다: 먼저 스켈레톤 화면을 표시한 다음 콘텐츠를 부분적으로 로드합니다.

Android에서 효과적인 방법은 순위가 지정된 이니셜라이저와 함께 App Startup 라이브러리를 사용하는 것입니다. 예를 들어 Firebase Analytics 이니셜라이저를 선택 사항으로 만들고 시작 후 2초 지연시킬 수 있습니다. iOS에서 동등물은 lazy 플래그가 있는 Initialization Dependencies입니다. 웹의 경우 주요 방법은 코드 분할, 트리 쉐이킹, 중요 리소스에 대한 사전 로드/사전 연결, 논블로킹 JS를 위한 defer입니다. Google Lighthouse는 구체적인 권장 사항을 제공합니다: “Eliminate render-blocking resources” 및 “Defer offscreen images”는 TTI에 직접 영향을 미칩니다.

React Native 코드 분할

React Native에서 React.lazy 및 Suspense를 사용한 번들 분할 예시. HeavyScreen 구성 요소는 사용자가 해당 화면으로 이동할 때만 로드되어 초기 화면 TTI를 줄입니다.

import React, { lazy, Suspense } from 'react';

const HeavyScreen = lazy(() =>
    import('./screens/HeavyScreen')
);

const App = () => (
    <Suspense fallback={<Loading />}>
        <HeavyScreen />
    </Suspense>
);

TTI 측정 도구

TTI 측정에는 여러 도구가 있으며 플랫폼과 분석 깊이에 따라 다릅니다. 웹에서 기본 도구는 Chrome DevTools의 Lighthouse입니다. Lighthouse는 감사를 실행하고 TTI를 밀리초 단위로 출력하며 개선을 위한 구체적인 권장 사항을 제공합니다. 지속적인 모니터링을 위해 PageSpeed Insights(Google)를 사용합니다. 실제 사용자의 Chrome User Experience Report(CrUX) 데이터를 수집합니다. 네이티브 앱에서 TTI는 Android Vitals(Google Play Console) 및 MetricKit(Apple)을 통해 측정됩니다.

프로덕션 모니터링을 위한 인기 도구로는 Firebase Performance Monitoring(사용자 지정 추적), Datadog RUM(실제 사용자 모니터링), Sentry Performance가 있습니다. 이러한 도구는 TTI를 표시할 뿐만 아니라 TTI와 전환, 이탈, 세션 시간과 같은 비즈니스 지표 간의 상관 관계를 추적할 수 있습니다. 권장 임계값: < 3.8초 — 좋음, 3.8~7초 — 개선 필요, > 7초 — 심각. 네이티브 앱의 경우 임계값이 더 엄격합니다: < 2초 — 좋음, 2~5초 — 보통, > 5초 — 심각. 모바일 앱 사용자는 지연에 대한 내성이 낮기 때문입니다.

Lighthouse CI 설정

CI/CD 파이프라인에서 자동 TTI 확인을 위한 Lighthouse CI 설정 예시. 3.8초 임계값을 초과하면 빌드에 경고가 표시됩니다.

// lighthouserc.js
module.exports = {
    ci: {
        assert: {
            assertions: {
                'interactive': ['warn', {
                    maxNumericValue: 3800
                }],
                'first-contentful-paint': ['error', {
                    maxNumericValue: 1800
                }]
            }
        },
        collect: {
            startServerCommand: 'npm start',
            url: ['http://localhost:3000'],
            numberOfRuns: 3
        }
    }
};