중국에서도 끊기지 않는 푸시, 이렇게 만들었습니다(안드로이드)

들어가며

안녕하세요. 노머스에서 프롬 안드로이드 앱 개발을 담당하고 있는 김민석입니다.
최근 프롬 앱에 중국 현지에서도 VPN 없이 원활하게 서비스를 이용할 수 있는 최적화 기능이 추가되었습니다. 👏

이번 글에서는 그중 안드로이드 팀에서 MQTT를 활용하여 안정적인 푸시(Push) 수신 서비스를 구축한 경험을 공유하고자 합니다.

이 글에서는 MQTT의 기본 개념 설명보다는, 저희 안드로이드 팀에서 어떤 방법으로 구현하고 문제를 해결했는지에 집중합니다. 저희 팀에서 MQTT를 선택한 배경이 궁금하시다면 아래 시리즈 글을 먼저 읽어보시는 것을 추천드립니다.

• 중국에서도 프롬 쓰게 해주세요. - 1편
• 중국에서도 프롬 쓰게 해주세요. - 2편
• 중국 환경에서 앱 푸시 안정적으로 발송하기

1. FCM의 한계

국내에서 서비스되는 대부분의 안드로이드 앱은 FCM(Firebase Cloud Messaging)을 통해 푸시 알림을 구현합니다. FCM은 앱이 포그라운드, 백그라운드, 심지어 프로세스가 종료된 상태에서도 푸시를 안정적으로 수신하게 해주는 강력한 도구입니다.

하지만 FCM은 Google Play Service 위에서 동작하기 때문에, 기기에 반드시 Google Play 스토어 앱이 설치되어 있어야 합니다. Firebase 공식 문서에서도 이 점을 명시하고 있습니다.

FCM 클라이언트는 Android 5.0 이상의 Google Play 스토어 앱이 설치된 기기 또는 Google API로 Android 5.0을 실행하는 에뮬레이터가 필요합니다. Google Play 스토어를 통해서만 Android 앱을 배포하도록 제한되지는 않습니다.

출처: https://firebase.google.com/docs/cloud-messaging/android/client?hl=ko

이러한 제약은 중국 환경에서 두 가지 큰 문제를 야기합니다.

1. Google Play 스토어의 부재: 화웨이(Harmony OS) 등 중국 내수용 기기에는 Google Play 스토어가 탑재되지 않은 경우가 많아 FCM을 원천적으로 사용할 수 없습니다.
2. 중국 방화벽(GFW): Play 스토어가 설치된 기기일지라도, 중국의 방화벽 정책으로 인해 FCM 서버와의 연결이 불안정하거나 차단됩니다. 따라서 푸시를 정상적으로 수신하려면 VPN 사용이 강제됩니다.

샤오미(Mi Push), 화웨이(Push Kit) 등 기기 제조사가 제공하는 자체 푸시 서비스를 활용하는 방법도 고려했지만, 도입을 위한 요건이 복잡하고 제약이 많아 현실적인 대안이 되기 어려웠습니다.

이러한 문제들을 해결하고 VPN 없이 안정적인 푸시 서비스를 제공하기 위해, 저희 팀은 MQTT를 활용한 자체 푸시 구현을 결정했습니다.

2. 어떤 MQTT 라이브러리를 선택했는가

프로젝트 초기 기술 검토 단계에서 서버는 AWS IoT Core 기반의 MQTT 브로커를, 인증 방식은 AWS Cognito를 사용하기로 결정했습니다.

이에 따라 안드로이드 팀에서는 Cognito 인증을 공식 지원하는 AWS IoT Core Device SDK Java V2를 우선 검토했습니다.

하지만 개발 과정에서 여러 문제로 인해 인증 방식이 Custom Authorizer로 변경되면서 웹소켓(wss) 프로토콜을 사용해야 했습니다. 이 과정에서 AWS IoT Core Device SDK가 안드로이드 환경의 SSL 인증서를 제대로 처리하지 못해 연결에 실패하는 문제를 겪었습니다. 제한된 시간 안에 공식 문서나 GitHub Issue에서 명확한 해결책을 찾기 어려웠고, 다른 라이브러리를 테스트하며 대안을 모색해야 했습니다.

여러 라이브러리를 검토한 결과, 최종적으로 hannesa2/paho.mqtt.android 오픈소스를 채택했습니다.

paho.mqtt.android 라이브러리는 두 종류가 있습니다.

• eclipse-paho: 이클립스 재단에서 개발한 MQTT 클라이언트 SDK입니다. 현재는 개발이 거의 중단된 상태입니다. (GitHub)
• hannesa2: eclipse-paho를 기반으로 최신 안드로이드 환경에 맞게 개선한 버전입니다. 지금도 활발하게 유지보수되고 있습니다. (GitHub)

3. paho.mqtt.android를 이용한 프롬 푸시 서비스 구현

이제 paho.mqtt.android 라이브러리를 사용하여 MQTT 연결부터 토픽 구독까지의 핵심 구현 과정을 살펴보겠습니다.

MqttClient 생성

가장 먼저 MQTT 브로커와 통신할 MqttAndroidClient 객체를 생성합니다.

class PahoMqttTransport(...) {
    private val callback = object : MqttCallbackExtended {
        override fun connectComplete(reconnect: Boolean, serverURI: String?) {
            // 연결 또는 재연결이 성공적으로 완료되었을 때 호출됩니다.
        }

        override fun connectionLost(cause: Throwable?) {
            // 연결 끊김 원인 로깅 등 예외를 처리합니다.
        }

        override fun messageArrived(topic: String?, message: MqttMessage?) {
            // 구독 중인 토픽으로 메시지가 도착했을 때 호출됩니다.
            scope.launch {
                _message.emit(message?.payload?.decodeToString())
            }
        }

        override fun deliveryComplete(token: IMqttDeliveryToken?) {
            // 메시지 발행(publish)이 완료되었을 때 호출됩니다. (푸시 수신만 구현할 경우 불필요)
        }
    }

    val mqttClient = MqttAndroidClient(
        context = context,     // Application Context
        serverURI = serverUri, // "wss://{your-domain}:443"
        clientId = clientId    // 클라이언트를 식별하기 위한 고유 ID (e.g., Device ID)
    ).apply {
        setCallback(callback)
    }
}

• serverURI: 웹소켓 기반으로 연결하므로 wss://{도메인}:443 형식을 사용합니다.
• clientId: MQTT 브로커가 각 클라이언트를 식별하기 위한 고유한 문자열입니다. 저희 팀은 기기의 Device ID를 사용합니다.

브로커 연결

다음으로, MqttConnectOptions를 설정하여 브로커에 연결을 시도합니다.

fun connect(password: String) {
    val options = MqttConnectOptions().apply {
        this.userName = clientId
        this.password = password.toCharArray()
        this.mqttVersion = MqttConnectOptions.MQTT_VERSION_3_1_1
        this.isAutomaticReconnect = true
        this.isCleanSession = false
    }

    mqttClient.connect(options)
}

• password: 브로커 연결에 필요한 인증 정보입니다. 프롬에서는 백엔드 서버에서 발급받은 토큰을 사용합니다.
• isAutomaticReconnect: 네트워크 문제 등으로 연결이 끊어졌을 때 자동으로 재연결을 시도할지 여부를 설정합니다.
• isCleanSession:
  • true로 설정하면 연결마다 새로운 세션을 생성합니다. 이 경우, 재연결될 때마다 구독했던 토픽을 다시 구독해야 합니다.
  • false로 설정하면 기존 세션을 유지하여, 재연결 시 이전 구독 정보가 자동으로 복원됩니다.

토픽 구독

연결이 완료되면, 푸시 메시지를 수신할 토픽(Topic)을 구독합니다.

fun subscribe(topic: String, qos: Int) {
    mqttClient.subscribe(topic = topic, qos = qos)
}

• 프롬에서는 푸시용으로 단일 토픽을 사용하지만, 여러 토픽을 배열로 전달하여 한 번에 구독할 수도 있습니다.
• 푸시의 QoS는 0 (At most once)으로 설정하여 사용합니다.

이렇게 MQTT 클라이언트의 기본적인 연결 및 구독 설정을 마쳤습니다. 하지만 사용자가 앱을 종료한 상태에서도 푸시를 받으려면 이 MQTT 연결을 백그라운드에서 계속 유지해 줄 컴포넌트가 필요합니다.

4. 안정적인 푸시 수신을 위한 Immortal Service

출처: Wikipedia - Immortan Joe, Mad Max

사용자가 앱을 종료한 후에도 MQTT 연결을 유지하여 푸시를 수신하기 위해, 저희는 소위 ‘죽지 않는 서비스(Immortal Service)‘를 구현했습니다.

물론 안드로이드의 강화된 백그라운드 제한 정책(Doze 모드, Foreground Service 실행 제한, 제조사별 배터리 최적화 등) 때문에 100% 완벽한 불멸의 서비스는 불가능합니다. 따라서 저희는 다음과 같은 전략들을 조합하여 서비스의 생존 가능성을 최대한 높였습니다.

1) Foreground Service 활용

서비스를 Foreground Service로 실행하면 일반 백그라운드 서비스보다 종료될 확률이 훨씬 낮아집니다. 또한 onStartCommand()에서 START_STICKY를 반환하도록 설정하면, 메모리 부족 등의 이유로 시스템에 의해 서비스가 강제 종료되더라도 시스템 자원이 확보되었을 때 자동으로 서비스를 재시작해 줍니다.

class FrommMqttMessagingService : Service() {
    // ...

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        // 사용자에게 알림을 표시하고 포그라운드 서비스 시작
        startForegroundService()

        // MQTT 연결 및 토픽 구독 로직 수행
        pahoMqttTransport.connect(password)
        pahoMqttTransport.subscribe(topic, qos)

        // 서비스 비정상 종료 시 시스템이 자동으로 재시작
        return START_STICKY
    }
}

2) 기기 부팅 시 서비스 자동 실행

BroadcastReceiver가 기기 부팅 완료(ACTION_BOOT_COMPLETED) 이벤트를 감지하면, 서비스가 실행되도록 구현합니다.

class BootCompletedReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == Intent.ACTION_BOOT_COMPLETED) {
            val serviceIntent = Intent(context, FrommMqttMessagingService::class.java)
            ContextCompat.startForegroundService(context, serviceIntent)
        }
    }
}

물론 실제 프롬 앱에서는 푸시뿐만 아니라 채팅 기능에도 MQTT를 활용하기에 더 정교한 구조로 설계되어 있습니다. 위 코드는 핵심 로직을 이해하기 위한 예시로 참고해 주시면 좋겠습니다.

최신 안드로이드 OS 대응의 어려움

안드로이드 OS의 백그라운드 정책은 계속해서 강화되고 있어 추가적인 대응이 필요합니다.

• Android 14: Foreground Service에 반드시 foregroundServiceType을 명시해야 합니다. 저희는 푸시 목적이므로 remoteMessaging 타입을 지정했습니다.
• Android 15: 부팅(BOOT_COMPLETED) 직후 백그라운드에서 Foreground Service를 실행하는 것에 제한사항이 추가되었습니다.

참고: Android 15 동작 변경사항 — 포그라운드 서비스

이러한 변경점에 대응하고 있지만, 일부 기기에서는 여전히 간헐적으로 서비스가 실행되지 않는 사례가 발생하고 있어 지속적인 모니터링과 개선이 필요한 상황입니다.

5. FCM과 MQTT 통합 관리: 어댑터 패턴으로 구조 개선하기

프롬 앱은 일반적인 환경에서는 FCM을, 중국 환경에서는 MQTT를 통해 푸시를 수신합니다. 두 경로는 푸시 알림을 노출할 때 사용하는 객체가 다릅니다. FCM은 RemoteMessage 를 사용하는 반면, MQTT는 JSONObject 를 사용합니다.

이처럼 서로 다른 형태의 데이터를 일관된 방식으로 처리하고, 향후 유지보수와 확장이 쉬운 구조를 만들기 위해 어댑터(Adapter) 패턴을 적용했습니다.

먼저 앱에서 다루는 모든 푸시 타입을 표준화된 PushMessage sealed interface로 정의했습니다.

sealed interface PushMessage {
    data class Chat(...) : PushMessage
    data class Promotion(...) : PushMessage
    data class Channel(...) : PushMessage
    // ... 기타 푸시 타입
}

그 다음, 어떤 데이터 소스든 이 표준 PushMessage 객체로 변환하는 역할을 할 PushMessageAdapter 인터페이스를 설계했습니다.

interface PushMessageAdapter {
    fun toPushMessage(): PushMessage
}

이제 각 데이터 소스에 맞는 어댑터 구현체를 만듭니다. FcmPushMessageAdapter는 FCM의 RemoteMessage를, MqttPushMessageAdapter는 MQTT의 JSONObject를 받아 각각 표준 PushMessage로 변환합니다.

// FCM 데이터를 표준 PushMessage로 변환하는 어댑터
class FcmPushMessageAdapter(private val message: RemoteMessage) : PushMessageAdapter {
    override fun toPushMessage(): PushMessage {
        // message.data의 "action" 값에 따라
        // PushMessage.Chat, PushMessage.Promotion 등으로 파싱하여 반환
        ...
    }
}

// MQTT 데이터를 표준 PushMessage로 변환하는 어댑터
class MqttPushMessageAdapter(private val message: JSONObject, ...) : PushMessageAdapter {
    override fun toPushMessage(): PushMessage {
        // message.optString("action") 값에 따라
        // PushMessage.Chat, PushMessage.Promotion 등으로 파싱하여 반환
        ...
    }
}

마지막으로, 실제 알림 처리를 담당하는 PushMessageDelegator가 이 구조를 활용합니다.

@Singleton
class PushMessageDelegator @Inject constructor(...) {
    suspend fun handlePushMessage(pushMessageAdapter: PushMessageAdapter) {
        when (val pushMessageType = pushMessageAdapter.toPushMessage()) {
            is PushMessage.Chat -> showChatNotification(...)
            is PushMessage.Channel -> showChannelNotification(...)
            is PushMessage.Promotion -> showPromotionNotification(...)
            // ...
        }
    }
}

각 푸시 수신 서비스는 자신의 출처에 맞는 어댑터를 생성하여 Delegator에 전달하기만 하면 됩니다.

FCM 메시지를 수신하는 FrommFirebaseMessagingService에서는 onMessageReceived가 호출되면, RemoteMessage를 FcmPushMessageAdapter로 감싸 PushMessageDelegator에 전달합니다.

@AndroidEntryPoint
class FrommFirebaseMessagingService : FirebaseMessagingService() {

    @Inject
    lateinit var pushMessageDelegator: PushMessageDelegator

    override fun onMessageReceived(message: RemoteMessage) {
        scope.launch {
            pushMessageDelegator.handlePushMessage(
                FcmPushMessageAdapter(...)
            )
        }
    }
}

마찬가지로, MQTT 메시지를 수신하는 FrommMqttMessagingService에서는 Mqtt 로부터 들어온 메시지를 전달받아 MqttPushMessageAdapter로 감싸고, 동일한 PushMessageDelegator에 전달합니다.

@AndroidEntryPoint
class FrommMqttMessagingService : Service() {

    @Inject
    lateinit var pushMessageDelegator: PushMessageDelegator
    
    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        scope.launch {
            pahoMqttTransport.message.collect { message ->
                pushMessageDelegator.handlePushMessage(
                    MqttPushMessageAdapter(...)
                )
            }
        }
        return START_STICKY
    }
}

이러한 구조를 통해 데이터 파싱 로직(Adapter)과 알림 처리 로직(Delegator)을 명확하게 분리할 수 있었습니다. 덕분에 다음과 같은 장점을 얻었습니다.

• 유지보수성 향상: 푸시 데이터의 형식이 변경되더라도 해당 어댑터만 수정하면 되므로 변경의 영향 범위가 최소화됩니다.
• 확장성 확보: 만약 미래에 화웨이 푸시(HMS) 등 새로운 푸시 서비스를 추가해야 한다면, 새로운 어댑터 클래스만 구현하면 됩니다. PushMessageDelegator의 코드는 전혀 수정할 필요가 없습니다.

마무리

입사 후 첫 스쿼드 업무로 참여했던 중국 대응 프로젝트가 드디어 성공적으로 마무리되었습니다. 기술 검토부터 아키텍처 설계, 그리고 실제 구현에 이르기까지 많은 고민과 노력이 필요했지만, 그만큼 기술적으로도 많이 성장할 수 있었던 소중한 경험이었습니다.

특히 배포 후 중국 사용자들로부터 “만들어줘서 고맙다”, “VPN 없이 사용할 수 있어 너무 좋다”와 같은 긍정적인 피드백을 받았을 때, 모든 노력을 보상받는 듯한 뿌듯함을 느꼈습니다.

이 글이 중국 환경에서 푸시 서비스를 구현하려는 다른 안드로이드 개발자분들께 작은 도움이 되기를 바랍니다.

긴 글 읽어주셔서 감사합니다!