중국 환경에서 앱 푸시 안정적으로 발송하기

들어가며

안녕하세요, 백엔드 개발자 이찬희입니다. 중국 사용자분들로부터 “푸시가 안 와요”, “VPN을 켜야만 접속돼요” 같은 피드백이 꾸준히 들어왔습니다. Android/iOS 모두 FCM 기반으로 운영하던 저희에게 중국의 네트워크 환경은 큰 장벽이었습니다. 저희는 VPN 없이도 앱의 모든 기능이 원활히 동작하는 환경을 만들고자 했습니다. 그 첫 단계로 중국 푸시 서비스를 개편했고, 이 글에서는 왜 AWS IoT Core와 Custom Lambda Authorizer 조합을 선택했는지 기록합니다.

중국 환경에서 MQTT 선택 이유

중국에서는 VPN 없이 Google 계열 서비스에 접근하기 어렵습니다. 이 때문에 기존 FCM 기반 푸시 구조로는 메시지 전달이 지연되거나 아예 실패하는 경우가 많았습니다. 다른 지역이라면 보통은 FCM을 사용합니다. OS 차원에서 최적화되어 있고, 서버 운영 부담이 거의 없기 때문에 굳이 다른 프로토콜을 선택할 이유가 적습니다.

하지만 저희가 원하는 건 중국 사용자도 아무런 설정을 신경 쓰지 않고 평범하게 앱을 쓸 수 있는 경험이었습니다. 이를 위해서는 다음 조건을 만족해야 했습니다.

• 네트워크 품질이 불안정한 환경에서도 연결을 오래 유지할 수 있는 프로토콜
• 데이터 사용량이 적고, 모바일 환경에 최적화된 통신 방식

여러 옵션을 검토한 결과, MQTT가 가장 적합했습니다. MQTT는 경량 프로토콜로서 연결 유지를 위한 오버헤드가 작고, QoS(Quality of Service) 옵션을 통해 메시지 전달 보장 수준을 조정할 수 있습니다. 모바일 네트워크에서 배터리와 데이터 소모를 최소화하면서도 실시간성 있는 통신을 유지할 수 있다는 장점도 있습니다.

여기에 AWS IoT Core를 더하면, 수십만~수백만 개의 장치 연결을 안정적으로 관리하고 보안·인증·확장성 문제를 AWS에 위임할 수 있습니다. 덕분에 저희는 인프라 운영 부담을 줄이고, 서비스 로직과 사용자 경험 개선에 집중할 수 있게 되었습니다.

인증·권한 구조 설계

클라이언트는 로그인 이후 wss://<iot-endpoint>/mqtt 로 연결을 시도합니다. 이때 AWS IoT Core가 Custom Lambda Authorizer 를 호출하여 토큰을 검증합니다. 토큰이 유효하면 그 사용자/디바이스에만 유효한 정책을 만들어 반환합니다.

출처: AWS IoT Core 개발자 안내서 - 사용자 지정 인증 워크플로 이해

MQTT 토픽 설계는 서비스 목적에 따라 다양하게 구성할 수 있지만, 푸시 서비스에서는 디바이스 단위로 권한을 완전히 격리했습니다. 그렇기 때문에 특정 기기의 토픽이 탈취되어도 다른 기기에는 영향을 주지 않습니다. 인증 과정은 Lambda Custom Authorizer를 통해 처리하며, 인증이 완료되면 해당 연결에 대해 임시 권한을 발급합니다. 이때 권한 유지 시간과 정책 재검증 간격을 적절히 설정하면, 불필요하게 자주 자격 증명을 재발급하지 않아도 되고, Authorizer 호출 빈도 역시 줄어들어 운영 비용과 지연을 함께 낮출 수 있습니다.

디바이스는 자기 토픽만 구독·수신하도록 최소 권한을 부여합니다. 아래는 인증이 완료되면 발급되는 Policy의 예시입니다.

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": ["iot:Connect"], "Resource": ["*"] },
    {
      "Effect": "Allow",
      "Action": ["iot:Subscribe"],
      "Resource": ["arn:aws:iot:<region>:<account>:topicfilter/${topic}"]
    },
    {
      "Effect": "Allow",
      "Action": ["iot:Receive"],
      "Resource": ["arn:aws:iot:<region>:<account>:topic/${topic}"]
    }
  ]
}

Custom Authorizer 선택 배경

MQTT 브로커 연결 시 인증 방식은 다양합니다. 저희도 Custom Authorizer, Cognito, 인증서(X.509) 방식을 모두 검토했습니다. 그중 Custom Authorizer를 선택한 이유는 저희가 통제할 수 있는 범위가 가장 넓었기 때문입니다. 단순한 인증 로직뿐 아니라 권한의 유효 시간, 정책 재검증 주기까지 직접 제어할 수 있었죠. 이 옵션들을 적절히 설정하면 스파이크 트래픽 상황에서도 부하를 완화할 수 있고, 필요 시 Lambda의 Provisioned Concurrency까지 활용해 안정성을 높일 수 있습니다.

Cognito는 AWS가 관리하는 신원 토큰과 STS 자격 증명을 통해 표준화된 SigV4 인증을 제공합니다. 토큰 수명과 회전도 AWS가 관리해주기 때문에 장기 운영 관점에서 매력적입니다. 하지만 Cognito API의 기본 rate limit이 상대적으로 낮은 것이 부담이었습니다. AWS에 요청하면 상향은 가능하지만, 계속 한도를 신경 써야 한다는 운영 리스크가 존재했습니다.

인증서 방식은 디바이스 정체성 보장 측면에서 강력하고, 전통적인 IoT 기기에는 최적화돼 있습니다. 그러나 모바일 앱 환경에서는 프라이빗 키 보관·회수가 가장 큰 고민입니다. 키체인·키스토어를 사용하더라도 루팅·탈옥·에뮬레이터 환경에서 유출 위험을 완전히 제거하기 어렵고, 한 번 유출되면 대규모 폐기·재발급이 필요합니다. 또한 소비자용 앱 특성상 한 디바이스에서 사용자가 자주 바뀌는데, 그때마다 인증서와 사용자 매핑을 반복 갱신해야 하는 구조는 매끄럽지 않았습니다.

정리하면, 당시 저희의 우선순위는 넓은 권한 제어, 연결 순간의 정책 동적 생성, 빠른 회수/차단이었고, 이 세 가지를 가장 단순하게 만족시킨 게 Custom Authorizer였습니다. 다만 Cognito는 장기적으로 표준화·운영 자동화 측면에서 매력적이라, 내부 로드맵에 “Cognito Identity Pool 기반 접속 실험”을 계속 올려두고 있습니다.

마치며

이번 작업을 통해 “중국에서도 온전하게 동작하는 프롬 서비스”에 한 걸음 더 다가섰다고 생각합니다. AWS IoT Core + Custom Authorizer 조합은 네트워크 제약이 심한 환경에서도 안정적인 연결을 가능하게 해줬습니다. 실제로 중국에서 테스트를 진행해 보기도 했는데, (중국에서도 프롬 쓰게 해주세요. -2편 ) 이 링크에서 확인이 가능합니다. 푸시 서비스는 그 시작일 뿐이며, 앞으로도 남은 과제를 하나씩 해결해 나갈 계획입니다.