Firebase Performance: 개요, 메트릭 및 추적 방법

Firebase Performance Monitoring이란

Firebase Performance Monitoring은 모바일 앱 성능 메트릭을 수집, 집계 및 시각화하는 SDK 및 클라우드 플랫폼입니다. SDK는 앱에 내장되어 Activity 수명 주기(Android) 또는 ViewController(iOS), URLSession(iOS) 또는 OkHttp(Android)를 통한 네트워크 요청, 시스템 호출 등 주요 지점을 자동으로 계측합니다. 수집된 데이터는 Firebase 서버로 전송되어 앱 버전, 기기, 국가 및 기타 속성별로 집계됩니다.

Performance SDK 아키텍처는 최소 오버헤드 원칙을 기반으로 합니다. 계측은 측정된 작업 실행 시간에 1~2% 이상 추가되지 않습니다. 데이터는 비동기적으로 수집되고 전송 전에 기기에서 버퍼링되어 UI 스레드 성능에 미치는 영향을 제거합니다. 데이터는 일정에 따라(기본적으로 30분마다) 또는 버퍼가 100KB에 도달하면 전송됩니다.

Firebase Performance와 Android Studio 프로파일러(CPU Profiler) 또는 Xcode Instruments의 주요 차이점은 프로덕션 모니터링입니다. Firebase Performance는 개발자 기기뿐만 아니라 실제 사용자 기기에서 데이터를 수집합니다. 이를 통해 특정 모델, OS 버전 또는 특정 지역에서만 발생하는 문제——통제된 환경에서 재현할 수 없는 문제——를 감지할 수 있습니다.

코드 변경 없이 SDK가 데이터를 수집하는 방법

자동 계측은 Firebase Performance의 주요 기능입니다. Android의 경우 SDK가 자동으로 ActivityLifecycleCallbacks을 등록하고 onCreate와 onResume 사이의 시간(화면 렌더링 시간)을 측정합니다. iOS의 경우 viewDidLoad 및 viewDidAppear 메서드를 스위즐합니다. 네트워크 요청은 OkHttpInterceptor(Android) 또는 NSURLProtocol(iOS) 수준에서 가로채집니다. 개발자는 표준 메트릭에 대해 start/stop 호출을 추가할 필요가 없습니다.

Performance SDK 활성화 및 비활성화는 Google Services 플러그인(Android) 또는 Info.plist(iOS)를 통해 관리됩니다. 디버깅을 위해 Performance SDK의 상세 로깅을 활성화하여 수집 및 전송되는 메트릭을 확인할 수 있습니다. 프로덕션에서는 불필요한 정보로 로그가 복잡해지는 것을 방지하기 위해 로깅을 경고 수준으로 유지하는 것이 좋습니다. Flutter 또는 React Native 프로젝트의 경우 자동 계측이 제한될 수 있습니다. 자세한 내용은 코드 예제 섹션을 참조하세요.

무료 한도 및 가격

Firebase Performance는 무료 Spark 요금제에서 트레이스 수 또는 데이터 양에 제한 없이 사용할 수 있습니다. 유료 Blaze 요금제에서도 Performance Monitoring에 대한 요금이 부과되지 않습니다——두 요금제 모두 완전히 무료인 몇 안 되는 Firebase 서비스 중 하나입니다. 제한 사항은 단 하나입니다. 데이터 저장 기간은 30일(Spark) 및 최대 365일(Blaze)입니다. 장기 분석을 위해 BigQuery 내보내기를 통해 데이터를 내보내세요.

무료이기 때문에 Firebase Performance는 프로토타입에서 수백만 사용자의 엔터프라이즈 애플리케이션에 이르기까지 모든 프로젝트에 이상적인 선택입니다. 유일한 비용은 Performance SDK의 발신 트래픽이지만, 앱의 다른 네트워크 작업에 비해 무시할 수 있는 수준입니다(기기당 월 1MB 미만). BigQuery 내보내기는 스토리지 및 쿼리에 대해 요금이 부과되지만 Performance SDK 자체는 무료입니다.

자동 메트릭: 코드 없이 측정되는 항목

Firebase Performance는 코드 한 줄 없이 다섯 가지 범주의 메트릭을 자동 수집합니다: 앱 시작 시간, 느린 HTTP 요청, 화면 렌더링 속도, 메모리 사용량(Android만 해당), 프레임 속도(Android만 해당). 이러한 메트릭은 SDK 연결 및 첫 사용자 세션 직후 Firebase 콘솔에서 사용할 수 있습니다.

앱 시작 시간——프로세스 시작부터 UI가 완전히 상호 작용할 준비가 될 때까지의 시간입니다. 콜드 스타트(앱이 처음부터 시작)와 웜 스타트(앱이 백그라운드 상태에서 재개)로 나뉩니다. 콜드 스타트에는 DEX 파일 로드, 정적 필드 초기화, Application.onCreate 및 Activity.onCreate 호출이 포함됩니다. Firebase는 자동으로 시작 유형을 분류하고 각 유형의 시간 분포를 표시합니다.

화면 렌더링 시간——화면 로딩 시작(Android의 경우 onCreate, iOS의 경우 viewDidLoad)부터 화면이 상호 작용할 준비가 되는 순간(onResume, viewDidAppear)까지의 시간입니다. Firebase는 각 화면(클래스 이름 또는 사용자 정의 화면 이름 기준)별로 데이터를 집계하여 어떤 화면 로딩에 가장 오래 걸리는지 식별할 수 있습니다. Android의 경우 드롭된 프레임——화면 렌더링 중 건너뛴 프레임 수(jank)——도 측정됩니다.

네트워크 요청(HTTP/HTTPS)

Performance SDK는 URLSession, OkHttp 또는 URLConnection을 통해 앱에서 전송된 모든 HTTP/HTTPS 요청을 자동으로 가로채고 측정합니다. 각 요청에 대해 URL(보안을 위해 쿼리 매개변수를 제외한 경로), HTTP 메서드, 응답 코드, 응답 크기(바이트), 요청 지속 시간 및 연결 속도(WiFi, 셀룰러)가 기록됩니다. 데이터는 Firebase 콘솔의 네트워크 요청 대시보드에 집계됩니다.

느린 요청——지속 시간이 설정된 임계값을 초과하는 요청입니다. 기본 느린 요청 임계값은 4000ms입니다. 이 메트릭은 백엔드 문제를 식별하는 데 중요합니다. 백엔드 업데이트 후 느린 요청 수가 1%에서 15%로 증가하면 즉시 서버 로그를 분석해야 하는 신호입니다. 사용자는 응답을 5초 이상 기다리지 않습니다——Firebase 데이터에 따르면 요청에 3초 이상 걸리면 53%의 사용자가 앱을 종료합니다.

자동 계측의 제한 사항

iOS 제한 사항: iOS에서 Performance SDK는 드롭된 프레임을 측정할 수 없습니다(비공개 API). iOS에서 jank를 측정하려면 MetricKit 또는 CADisplayLink를 사용하세요. 또한 iOS에서 SDK는 URLSession을 사용하지 않는 타사 HTTP 클라이언트(예: SwiftNIO)를 통해 실행된 요청을 가로채지 않습니다. 이러한 경우 HTTP 속성이 있는 사용자 정의 트레이스를 사용하세요.

Android 제한 사항: Android에서 자동 메모리 측정은 Android 8.0+(API 26+) 기기에서만 사용할 수 있습니다. 이전 버전의 경우 Debug.getMemoryInfo()를 통해 얻은 데이터로 사용자 정의 트레이스를 사용하세요. 또한 SDK는 WebSocket 연결을 가로채지 않습니다——별도의 트레이스가 필요합니다. 이러한 제한에도 불구하고 자동 메트릭은 성능 모니터링 요구 사항의 80%를 충족합니다.

사용자 정의 트레이스 및 HTTP 속성

사용자 정의 트레이스는 개발자가 특정 시나리오(뉴스 피드 로딩, 이미지 처리, 데이터 동기화, 복잡한 데이터베이스 쿼리 실행)의 성능을 측정하기 위해 수동으로 생성하는 명명된 시간 간격입니다. 사용자 정의 트레이스는 자동 메트릭을 보완하며 개발자가 성능에 중요하다고 생각하는 코드 부분을 정확히 측정할 수 있게 해줍니다.

각 트레이스에는 이름(최대 100자)이 있으며 최대 5개의 사용자 정의 메트릭(트레이스 내에 기록되는 숫자 값)을 포함할 수 있습니다. 예를 들어 “image_processing” 트레이스에서 “original_file_size” 및 “processed_file_size”와 같은 메트릭을 측정할 수 있습니다. 메트릭은 Firebase 콘솔에 분포(최소, 최대, 평균, 백분위수)로 표시되어 지속 시간뿐만 아니라 작업 특성도 분석할 수 있습니다.

HTTP 속성——SDK에 의해 자동으로 가로채지지 않은 네트워크 요청(WebSocket 또는 타사 라이브러리를 통해)을 위한 특별한 유형의 사용자 정의 트레이스입니다. HTTP 속성에는 URL, HTTP 메서드, 응답 코드 및 응답 크기가 포함됩니다. Firebase는 이를 자동 수집된 요청과 함께 네트워크 요청 섹션에 표시하여 네트워크 상호 작용의 통합된 그림을 제공합니다.

사용자 정의 트레이스를 사용해야 하는 경우

사용자 정의 트레이스는 로컬 데이터베이스(Room, CoreData)의 데이터 로딩 시간, 복잡한 계산(암호화, 압축) 지속 시간, 애니메이션 및 전환 성능, 타사 SDK(지도, 결제, 분석) 응답 시간을 측정하는 데 필수적입니다. 이러한 각 시나리오에 대해 트레이스를 만들고 측정할 코드를 start/stop으로 감싼 후 후속 세분화를 위한 속성을 추가하세요.

사용자 정의 트레이스를 남용하지 마십시오. 각 트레이스는 배터리 및 트래픽 오버헤드를 추가합니다. 프로덕션 버전에서는 10~15개 이상의 활성 트레이스를 두지 않는 것이 좋습니다. 디버깅을 위해 더 많은 트레이스를 추가할 수 있지만 릴리스 전에 Remote Config(performance_tracing_enabled 플래그 사용)를 통해 과도한 트레이스를 비활성화하세요. 이를 통해 전체 사용자에게 영향을 주지 않고 선택된 사용자나 세션에 대해서만 상세 추적을 활성화할 수 있습니다.

세분화를 위한 트레이스 속성

사용자 정의 속성은 Firebase 콘솔에서 추후 필터링을 위해 트레이스에 추가할 수 있는 키-값 쌍입니다. 예를 들어 “feed_load” 트레이스에 “feed_type”(main, explore, following) 및 “cache_status”(cold, warm)와 같은 속성을 추가할 수 있습니다. 콘솔에서 트레이스 데이터를 이러한 속성으로 필터링하여 어떤 피드 유형이 가장 느리게 로드되는지 확인할 수 있습니다.

제한 사항: 각 트레이스는 최대 5개의 사용자 정의 속성을 가질 수 있습니다. 속성 값은 최대 100자의 문자열입니다. 속성은 트레이스 시작 전에 설정해야 하며, 시작 후 속성 변경은 무시됩니다. 이 제한은 성능과 관련이 있습니다——시작 후 속성을 고정하려면 추가 동기화가 필요합니다.

성능 임계값 및 알림

임계값은 메트릭에 대한 구성 가능한 경계값으로, 초과 시 Firebase Performance가 경고를 생성합니다. 임계값은 Firebase 콘솔(Performance > Thresholds)에서 각 자동 메트릭(앱 시작 시간(콜드/웜), 화면 렌더링 시간, 느린 HTTP 요청, HTTP 응답 시간)에 대해 설정할 수 있습니다. 모든 앱 버전에 대한 전역 임계값 또는 특정 버전에 대한 고유 임계값을 설정할 수 있습니다.

알림은 임계값이 초과될 때 Firebase가 전송하는 자동 알림입니다. 알림은 이메일, Slack 웹훅, PagerDuty 또는 Cloud Functions(사용자 정의 처리용)를 통해 구성할 수 있습니다. 각 알림에는 메트릭 이름, 현재 값, 임계값, 앱 버전, 세그먼트(기기, 국가)가 포함됩니다. 알림을 통해 사용자가 알아차리기 전에 성능 저하에 대응할 수 있습니다.

권장 임계값(업계 표준, Google I/O 2025 기준): 콜드 스타트——2초 미만, 웜 스타트——1초 미만, 화면 렌더링——500ms 미만, HTTP 요청 지속 시간——3000ms 미만(95백분위수), 느린 요청 비율——5% 미만. 경쟁이 치열한 앱(소셜, 전자상거래)의 경우 대상 임계값을 더 엄격하게 설정할 수 있습니다: 콜드 스타트 1.5초 미만, HTTP 1000ms 미만.

Firebase 콘솔에서 임계값 설정

Firebase 콘솔에서 Performance 섹션으로 이동하여 Thresholds 탭을 엽니다. 각 메트릭에 대해 원하는 임계값과 초과의 영향을 받아야 하는 사용자 비율을 설정합니다. 예: “10% 이상의 사용자에 대해 2초를 초과하는 경우 콜드 스타트를 느린 것으로 간주”. Firebase는 현재 메트릭 값과 초과 기록을 표시하여 현실적인 임계값 선택을 지원합니다.

중요: 임계값은 데이터 수집에 영향을 미치지 않으며 알림 생성만 제어합니다. 임계값이 너무 낮은 경우(예: 50%의 기기가 3초에 시작하는데 콜드 스타트 1초), 알림이 계속 수신되어 개발자가 무시하는 “소음”이 됩니다. 현재 성능을 기준으로 임계값을 설정하고 앱 최적화에 따라 점진적으로 강화하세요.

Firebase 콘솔의 성능 대시보드

성능 대시보드는 주요 메트릭을 앱 버전, 기기, 국가, 연결 유형 및 OS 버전별로 분류한 시계열로 표시합니다. 각 메트릭에 대해 평균, 중앙값, 95백분위수, 99백분위수를 사용할 수 있습니다. 95백분위수는 이상값을 무시하고 약한 기기에서 앱 성능을 나타내므로 성능 평가에 가장 유용한 메트릭입니다.

대시보드는 버전 비교를 지원합니다. 메트릭을 시각적으로 비교하기 위해 두 개의 앱 버전(현재 및 이전)을 선택합니다. 업데이트 후 95백분위수 시작 시간이 2.1초에서 3.4초로 증가했다면——회귀가 명백하며 속도 저하를 유발한 커밋을 찾아야 합니다. Firebase Performance는 GitHub, GitLab 및 Bitbucket과 통합되어 메트릭 변경 사항을 특정 커밋에 연결할 수 있습니다.

Performance Monitoring 코드 예제

Kotlin을 사용한 Android 앱에서 Firebase Performance Monitoring 통합 예제를 살펴보겠습니다. 코드는 뉴스 피드 로딩을 측정하는 사용자 정의 트레이스 생성, 자동으로 가로채지지 않는 요청에 대한 HTTP 속성 추가, Trace를 사용한 이미지 처리 시간 측정을 보여줍니다. 모든 예제는 Remote Config를 통해 추적을 비활성화하는 기능을 고려합니다.

사용 전에 Firebase BOM을 통해 종속성을 추가하세요: implementation("com.google.firebase:firebase-perf"). 자동 계측을 위한 추가 설정은 필요하지 않습니다——종속성 추가 후 SDK가 자동으로 표준 작업을 가로챕니다.

피드 로딩을 위한 사용자 정의 트레이스

첫 번째 예제는 서버에서 뉴스 피드의 로딩 시간 측정입니다. 트레이스는 네트워크에서 데이터를 가져와 JSON을 파싱하는 비동기 fetchFeed 작업을 감쌉니다. 트레이스에 데이터 소스(캐시 또는 네트워크) 및 수신된 게시물 수와 같은 사용자 정의 속성이 추가되었습니다. 이를 통해 데이터를 세분화하고 어떤 조건에서 피드가 가장 느리게 로드되는지 이해할 수 있습니다.

suspend fun loadFeedWithTrace(source: String) {
    val trace = Firebase.performance
        .newTrace("feed_load")
    trace.putAttribute("source", source)

    try {
        trace.start()
        val feed = fetchFeed()
        trace.putMetric(
            "items_count",
            feed.size.toLong()
        )
    } finally {
        trace.stop()
    }
}

loadFeedWithTrace 함수는 트레이스 속성으로 사용되는 source 매개변수(“cache” 또는 “network”)를 받습니다. 비동기 작업이 완료되면 finally 블록에서 트레이스가 중지되어 예외 발생 시에도 중지를 보장합니다. items_count 메트릭은 게시물 수가 로딩 시간에 미치는 영향을 분석할 수 있게 해줍니다. Firebase 콘솔에서 source 속성별로 트레이스를 필터링하면 네트워크 로딩이 캐시보다 3배 느리다는 것을 확인할 수 있습니다.

비표준 요청에 대한 HTTP 속성

두 번째 예제는 WebSocket을 통해 실행된 요청(자동으로 가로채지지 않음)에 대한 HTTP 속성입니다. HttpMetric 클래스를 사용하여 URL 요청, 메서드, 응답 코드 및 크기를 수동으로 등록할 수 있습니다. Firebase는 이 요청을 자동으로 가로채진 요청과 함께 네트워크 요청 섹션에 표시합니다.

suspend fun sendWithHttpMetric() {
    val metric = Firebase.performance
        .newHttpMetric(
            "https://api.example.com/data",
            FirebasePerformance.HttpMethod.POST
        )
    metric.start()

    try {
        val response = webSocketSend()
        metric.setHttpResponseCode(response.code)
        metric.setRequestPayloadSize(1024)
        metric.setResponsePayloadSize(
            response.body.length.toLong()
        )
    } finally {
        metric.stop()
    }
}

예제에서 sendWithHttpMetric은 newHttpMetric을 사용하여 비표준 HTTP 호출을 등록합니다. SDK가 자동으로 가로채지 않으므로 개발자가 URL, 메서드, 응답 코드 및 크기를 수동으로 설정합니다. 보안 및 집계를 위해 URL을 쿼리 매개변수 없이 설정하는 것이 중요합니다——즉 /data?token=abc가 아닌 /data입니다. Firebase는 자동으로 동일한 URL 패턴을 그룹화합니다.

이미지 처리 시간 측정

세 번째 예제는 사용자 정의 트레이스를 사용한 이미지 처리(압축, 크기 조정)의 시간 측정을 보여줍니다. 이 경우 트레이스는 동기 작업을 감싸지만 프로덕션에서는 UI 스레드를 차단하지 않도록 코루틴 또는 RxJava를 사용하세요.

fun compressImage(bitmap: Bitmap): ByteArray {
    val trace = Firebase.performance
        .newTrace("image_compression")
    trace.putAttribute(
        "format", "JPEG"
    )
    trace.start()

    val stream = ByteArrayOutputStream()
    bitmap.compress(
        Bitmap.CompressFormat.JPEG, 80, stream
    )
    val result = stream.toByteArray()
    trace.putMetric(
        "output_size_kb",
        result.size / 1024.toLong()
    )
    trace.stop()
    return result
}

compressImage 함수는 80% 품질의 JPEG 이미지 압축 시간을 측정합니다. format 속성을 통해 향후 JPEG와 WebP 압축 시간을 비교할 수 있습니다. output_size_kb 메트릭은 압축 효율성을 보여줍니다. Firebase 콘솔에서 분포를 확인할 수 있습니다: 약한 기기(저가형 Android)에서는 압축 시간이 플래그십보다 4배 더 오래 걸리며, 이는 서버에 이미지를 업로드할 때 지연의 원인이 될 수 있습니다.

데이터 기반 성능 개선 방법

Firebase Performance는 데이터를 제공하지만 기성 솔루션을 제공하지는 않습니다. 메트릭 분석에는 각 메트릭의 성능 저하 일반적인 원인을 이해해야 합니다. 주요 저하 패턴과 Performance Monitoring 데이터를 사용한 진단 방법을 살펴보겠습니다. 접근 방식: 메트릭에서 이상 징후 찾기 → 일반적인 원인 확인 → 최적화 적용 → 일주일 후 결과 확인.

느린 콜드 스타트(2초 초과): 원인——Application.onCreate에서의 무거운 SDK 초기화(분석, 충돌 리포트, 지도 SDK), 대용량 리소스 로드(글꼴, 테마), 시작 시 메인 스레드에서의 동기 작업. 해결책: 지연 SDK 초기화, 지연 리소스 로딩, 초기화 중 플레이스홀더 표시를 위한 SplashScreen API(Android 12+) 사용. Firebase Performance는 어떤 앱 버전이 느려지기 시작했는지 표시합니다——추가되거나 업데이트된 종속성을 확인하세요.

느린 화면 렌더링(500ms 초과): 원인——복잡한 View 계층 구조(중첩된 ConstraintLayout, 여러 Fragment), UI 스레드에서의 데이터 로딩(네트워크 또는 디스크), 무거운 그리기 작업(큰 이미지, 사용자 정의 View). 해결책: 레이아웃 계층 구조 최적화(Android Studio의 Layout Inspector), 데이터를 백그라운드 스레드로 오프로드, Glide 또는 Coil을 통한 이미지 캐싱. Firebase에서 화면 렌더링 필터를 사용하여 가장 느린 화면을 찾아 먼저 최적화하세요.

네트워크 요청 최적화

느린 HTTP 요청(3초 초과): 원인——느린 서버, 큰 페이로드, 캐싱 부족, 최적이 아닌 프로토콜(HTTP/2 대신 HTTP/1.1), DNS 확인. 해결책: 서버 측 확인(가동 시간, 지연 시간), 응답 크기 감소(페이지네이션, GraphQL, JSON 대신 protobuf), HTTP 헤더(Cache-Control)를 통한 캐싱 활성화, OkHttp Interceptor를 사용하여 타임아웃 및 재시도 로직 추가.

Firebase Performance는 요청의 시간 분포를 표시합니다: DNS 확인, TCP 핸드셰이크, TLS 핸드셰이크, 요청 전송, 응답 수신. 시간의 대부분이 DNS에 소비되는 경우——DNS 사전 로딩(OkHttp DNS-over-HTTPS)을 사용하세요. TLS인 경우——세션 재개 및 암호 제품군 튜닝을 사용하세요. 응답 수신인 경우——응답 크기와 사용자 네트워크 속도를 확인하세요. Firebase 데이터를 통해 단순히 “요청이 느리다\u201d고 말하는 대신 프로토콜 수준에서 문제를 파악할 수 있습니다.

추적 비활성화를 위한 Remote Config 통합

프로덕션에서는 Remote Config 플래그 performance_tracing_enabled를 추가하여 사용자 정의 트레이스를 원격으로 비활성화할 것을 권장합니다. 클라이언트의 Firebase Performance SDK가 너무 많은 데이터를 생성하거나 성능에 영향을 미치는 경우(약한 기기에서) 모든 사용자에 대한 트레이스를 비활성화하고 최소 오버헤드가 있는 자동 메트릭만 남길 수 있습니다.

로직 예: 앱 시작 시 Remote Config 매개변수 performance_tracing_enabled를 확인합니다. false인 경우——Firebase.performance.newTrace()에 대한 모든 호출이 데이터를 수집하지 않는 스텁 객체를 반환합니다. 이는 트레이스 생성 전에 플래그를 확인하는 래퍼 클래스를 통해 구현됩니다. 이 접근 방식을 통해 전체 사용자에게 영향을 주지 않고 특정 사용자(베타 테스터, 개발자)에 대해 상세 추적을 활성화할 수 있습니다.