Silent Push — 본질, 백그라운드 작업 및 전달 구성

Silent Push란 무엇인가 — 본질 및 목적

Silent Push는 사용자에게 시각적 알림 없이 기기에 데이터를 전달하는 iOS 메커니즘입니다. 배너를 표시하고, 소리를 재생하고, 알림 센터에 나타나는 표준 푸시와 달리, silent push는 백그라운드에서 앱을 “깨우고” 처리를 위해 데이터를 전달합니다. 사용자는 이러한 알림의 전달을 결코 알지 못합니다. 결과는 다음에 앱을 열 때 업데이트된 콘텐츠입니다.

일반 푸시 알림과의 차이점

핵심 차이점은 JSON 페이로드에 있습니다. silent push에는 content-available: 1 플래그가 포함되고 alert, sound 또는 badge가 포함되지 않습니다. 표준 알림은 alert가 있으면 content-available에 관계없이 항상 사용자에게 표시됩니다. Silent push는 content-available: 1 및 alert 없이만 작동합니다. alert를 추가하면 백그라운드 전달 플래그가 있어도 시스템이 알림을 표시합니다.

Silent Push 사용 시기

무음 알림은 사용자가 앱을 열 때 데이터가 최신 상태여야 하지만 사용자가 방해받지 않아야 하는 시나리오에 필수적입니다. 예시: 백그라운드에서 뉴스 피드 업데이트, 구독 동기화, 오프라인 액세스를 위한 새 콘텐츠 다운로드, 위젯 업데이트, 캐시 무효화. Silent Push는 예상되는 사용자 작업 전에 앱을 “워밍업”하는 데에도 사용됩니다.

무음 알림 전달 방식

Silent Push 전달은 일반 알림과 크게 다르며 전력 최적화 규칙을 따릅니다. iOS 시스템은 APNS에서 푸시 요청을 수신하고, 이것이 silent push(content-available: 1)임을 확인하고, 배터리 수준, 절전 모드, 이전 silent push 빈도, 앱 활동 및 현재 CPU 부하와 같은 여러 요인에 따라 전달 여부를 결정합니다.

Power Nap 및 백그라운드 모드의 역할

Apple M 칩 및 iOS 15+가 탑재된 기기에서 silent push는 주기적으로 기기를 깨워 백그라운드 작업을 수행하는 Power Nap 메커니즘과 통합됩니다. Power Nap은 여러 silent push를 하나의 활동 기간으로 통합하여 전체 전력 소비를 줄입니다. 개발자는 Power Nap을 직접 제어할 수 없습니다. 시스템은 사용자 행동 및 앱 사용 기록에 따라 자동으로 결정을 내립니다.

30초 처리 시간

시스템이 silent push를 전달하면 앱은 AppDelegate에서 application(_:didReceiveRemoteNotification:fetchCompletionHandler:) 호출을 받습니다. 개발자는 30초 이내에 completion handler를 호출하고 올바른 결과(UIBackgroundFetchResult)를 전달해야 합니다. 처리가 제 시간에 완료되지 않으면 시스템이 이 앱에 대한 silent push 빈도를 제한하거나 전달을 완전히 중단할 수 있습니다.

// AppDelegate에서 Silent Push 처리
func application(
    _ application: UIApplication,
    didReceiveRemoteNotification userInfo: [AnyHashable: Any],
    fetchCompletionHandler completionHandler:
    @escaping (UIBackgroundFetchResult) -> Void
) {
    guard let type = userInfo["sync-type"] as? String
    else {
        completionHandler(.failed)
        return
    }

    if type == "news-feed" {
        NewsFeedSyncService().sync { success in
            completionHandler(success ? .newData : .failed)
        }
    } else if type == "cache-invalidate" {
        CacheManager.shared.invalidateAll()
        completionHandler(.newData)
    } else {
        completionHandler(.noData)
    }
}

전달 간격

Apple은 silent push 간의 정확한 간격을 공개하지 않지만, 테스트 및 문서에 따르면 기기당 시간당 2–3개의 무음 알림을 초과하여 보내지 않는 것이 좋습니다. 더 자주 보내면 시스템이 silent push를 무시하기 시작하고 데이터 전달이 중단됩니다. 더 빈번한 동기화가 필요한 경우 백그라운드 구성이 있는 URLSession 또는 VoIP push 사용을 고려하십시오.

Silent Push 사용 사례

Silent Push는 사용자의 적극적인 참여 없이 데이터를 최신 상태로 유지해야 하는 광범위한 작업에 사용됩니다. 실제 iOS 애플리케이션에서 이 메커니즘의 가장 효과적인 사용 사례를 살펴보겠습니다.

오프라인 액세스를 위한 콘텐츠 업데이트

뉴스 앱, 리더 및 여행 애플리케이션은 백그라운드에서 새 콘텐츠를 다운로드하기 위해 Silent Push를 사용합니다. 사용자가 앱을 열면 데이터가 이미 로드되어 있으며 인터넷 연결 없이도 사용할 수 있습니다. 이 접근 방식은 사용자 경험을 극적으로 향상시킵니다. 빈 로딩 화면이 사라지고 콘텐츠가 즉시 표시됩니다. 새 기사가 나타나면 서버가 silent push를 보내고 앱이 오프라인 읽기를 위해 백그라운드에서 다운로드합니다.

위젯 상태 동기화

iOS WidgetKit은 일정에 따라 위젯을 업데이트하지만, 서버 측 데이터 변경 후 즉시 업데이트하려면 Silent Push가 사용됩니다. 백그라운드의 앱이 silent push를 처리하고, 위젯용 로컬 데이터 저장소를 업데이트하고, WidgetCenter를 통해 타임라인을 강제로 새로 고칩니다. 사용자는 앱을 열지 않고도 위젯에서 최신 정보(환율, 일기 예보, 배송 상태)를 확인합니다.

캐시 무효화 및 오래된 데이터 정리

서버가 중요한 데이터(예: 가격 책정 규칙, 프리미엄 사용자에게 제공되는 기능)를 업데이트하면 Silent Push가 로컬 캐시를 즉시 무효화할 수 있습니다. 다음에 열 때 앱은 오래된 캐시를 사용하는 대신 서버에서 새 데이터를 로드합니다. 이는 특히 유료 콘텐츠 또는 구독이 있는 앱에 중요합니다.

표시 알림 없이 배지 업데이트

일부 시나리오에서는 알림을 표시하지 않고 앱 아이콘의 배지를 업데이트해야 합니다. 페이로드에 배지 필드가 있는 Silent Push를 사용하면 배너로 사용자를 방해하지 않고 원하는 카운터 값을 설정할 수 있습니다. 예를 들어, 채팅 앱은 사용자가 이미 앱에 있는 경우 각 새 메시지를 알림으로 표시하지 않고 읽지 않은 메시지 수로 배지를 업데이트할 수 있습니다.

Silent Push 구성: 페이로드 및 기능

Silent Push가 올바르게 작동하려면 Xcode 프로젝트, 서버의 JSON 페이로드 및 앱의 처리 코드의 세 가지 수준에서 구성이 필요합니다. 각 수준은 중요합니다. 단계를 건너뛰면 알림이 일반으로 전달되거나 전혀 전달되지 않습니다.

Xcode에서 기능 구성

Xcode에서 Push Notifications 기능과 Remote notifications 확인란이 선택된 Background Modes를 활성화해야 합니다. Push Notifications는 APNS용 인증서를 생성하고, Background Modes의 Remote notifications는 silent push를 수신할 때 시스템이 앱을 깨울 수 있도록 합니다. Remote notifications가 없으면 silent push가 전달되지만 앱이 백그라운드에서 활성화되지 않고 데이터가 처리되지 않습니다.

JSON 페이로드 구조

Silent Push 페이로드에는 content-available: 1이 있는 aps 키가 포함되어야 하며 alert, sound 또는 badge가 포함되어서는 안 됩니다. 사용자 정의 필드는 aps와 동일한 수준에서 전달되며 처리할 데이터(작업 유형, 개체 식별자, 메타데이터)를 포함합니다. content-available이 없는 페이로드는 일반 알림으로 처리됩니다. alert가 있으면 content-available이 있어도 일반 알림으로 처리됩니다.

{
    "aps": {
        "content-available": 1
    },
    "sync-type": "news-feed",
    "last-article-id": "article_8521",
    "priority": "high"
}

클라이언트 측 처리

silent push를 수신하면 iOS는 앱이 표시되기 전에 application(_:didReceiveRemoteNotification:fetchCompletionHandler:)을 호출합니다. 이 메서드에서 userInfo를 분석하고, 필요한 작업(네트워크 요청, Core Data 쓰기, 캐시 업데이트)을 수행하고, 30초 이내에 올바른 결과로 completionHandler를 호출해야 합니다. completionHandler를 호출하지 않으면 시스템에서 오류로 간주하고 향후 silent push 빈도에 영향을 미칩니다.

제한 사항 및 모범 사례

Silent Push는 중요한 작업을 위한 안정적인 데이터 전달 채널이 아닙니다. 최적화 메커니즘이지 보장된 동기화가 아닙니다. 개발자는 제한 사항을 이해하고 silent push가 있거나 없을 때 모두 앱이 올바르게 작동하도록 시스템을 설계해야 합니다.

전달 제한 사항

iOS는 모든 silent push의 전달을 보장하지 않습니다. 배터리가 부족한 경우(20% 미만), 저전력 모드, 빈번한 이전 silent push 후 또는 앱이 오랫동안 사용되지 않은 경우 시스템이 전달을 지연하거나 취소할 수 있습니다. Apple의 평균 전달 통계에 따르면 약 70–80%의 silent push가 5분 이내에 전달되고 나머지는 지연되거나 손실될 수 있습니다.

Apple의 Silent Push 권장 사항

Apple은 효과적인 silent push 사용을 위해 몇 가지 규칙을 따를 것을 권장합니다. 기기당 시간당 2–3개 이상의 silent push를 보내지 마십시오. 제한을 초과하면 차단됩니다. 컴팩트 페이로드를 사용하십시오. 최소 페이로드 크기는 처리를 가속화하고 네트워크 부하를 줄입니다. 항상 가능한 한 빨리 completionHandler를 호출하십시오. 처리 시간이 길수록 시스템이 향후 silent push를 제한할 가능성이 높아집니다.

Silent Push 대안

보장된 전달이나 더 많은 처리 시간이 필요한 시나리오의 경우 대안을 고려하십시오. VoIP push(PushKit)는 전달을 보장하고 더 많은 시간을 제공하지만 VoIP 애플리케이션만을 대상으로 합니다. Background fetch(UIApplication background fetch)는 시스템에서 일정에 따라 시작되지만 서버에서 시작할 수 없습니다. WebSocket은 지속적인 연결을 유지하지만 배터리를 더 많이 소모하며 모든 유형의 앱에 적합하지 않습니다.

모니터링 및 디버깅

Silent Push를 디버깅하려면 Mac에서 Console.app을 사용하고 앱 이름으로 필터링하십시오. 시스템은 각 silent push를 “background task” 레이블로 기록하고 처리가 성공했는지 여부를 나타냅니다. 기기에서는 설정 → 개발자 → Background Modes Logging을 통해 확인하십시오. 서버 측 추적은 APNS Feedback Service를 통해 수행되어 전달되지 않은 알림을 식별합니다.