FCM(Firebase Cloud Messaging)

->^_^<- 2025. 9. 18. 17:52

FCM(Firebase Cloud Messaging)은 ?

구글이 제공하는 푸시 알림 서비스입니다. 모바일 앱(안드로이드·iOS), 웹 브라우저, 서버 간 메시지 전송에 널리 사용돼요.

---

📘 FCM Push 개요

풀네임: Firebase Cloud Messaging

역할: 서버에서 앱/브라우저로 실시간 알림(푸시 메시지)을 전달

지원 플랫폼: Android, iOS, Web

비용: 무료 (트래픽 제한은 있지만 대부분 서비스에 충분)

---

⚙️ 동작 방식

[ App 서버 ]   →   [ FCM 서버 ]   →   [ 사용자 기기 (앱) ]

1. 앱 등록

앱이 Firebase 프로젝트에 등록되고 FCM SDK가 앱에 탑재됨.

앱 실행 시 FCM에서 토큰(token) 발급 → 기기를 식별하는 ID.

2. 토큰 전달

앱은 이 토큰을 자신의 백엔드 서버에 전달.

3. 푸시 요청

백엔드 서버가 FCM 서버에 메시지를 전송 (토큰, 메시지 내용 포함).

4. 푸시 전달

FCM 서버가 해당 토큰을 가진 기기로 메시지를 푸시.

앱이 백그라운드/종료 상태일 경우에도 OS 푸시 채널(안드로이드/애플 푸시 서비스) 통해 전달됨.

---

📩 메시지 유형

1. 알림 메시지(Notification message)

OS 푸시 채널을 통해 직접 표시됨.

앱이 꺼져 있어도 시스템이 자동으로 알림 표시.

2. 데이터 메시지(Data message)

앱 코드에서 직접 처리해야 함.

유연하게 커스텀 가능 (예: 특정 이벤트 처리, 앱 내부 데이터 업데이트).

👉 실제 서비스에서는 알림+데이터 혼합 메시지도 많이 씀.

---

🔑 주요 특징

멀티 플랫폼 지원: 하나의 API로 Android, iOS, Web에 모두 알림 가능.

주제 구독(Topic Messaging):

예: news 토픽을 구독한 사용자 전체에 동시에 푸시 전송.

그룹 메시징(Device Group): 여러 디바이스를 하나의 사용자 계정에 묶어서 푸시 가능.

조건부 전송(Condition Messaging): 특정 조건(topicA && topicB) 충족 시 발송.

---

🛠️ 개발 시 자주 쓰는 요소

FCM 토큰: 단말 식별용, 앱 재설치/재로그인 시 갱신 필요.

FCM 서버 키(Server key / API key): 서버가 FCM에 메시지 전송 시 사용.

REST API or Firebase Admin SDK: 서버에서 푸시를 전송하는 방법.

예시 (HTTP v1 API):

POST https://fcm.googleapis.com/v1/projects/myproject/messages:send
{
  "message": {
    "token": "DEVICE_FCM_TOKEN",
    "notification": {
      "title": "새 소식!",
      "body": "오늘 업데이트된 콘텐츠를 확인하세요."
    },
    "data": {
      "key1": "value1",
      "key2": "value2"
    }
  }
}

---

✅ 요약

FCM Push = Firebase 기반 무료 푸시 알림 서비스.

서버 → FCM → 기기(앱/브라우저) 구조.

메시지 유형: 알림(Notification) / 데이터(Data) / 혼합.

기능: 주제 구독, 그룹 메시징, 조건부 전송 등.

---

FCM(구글) / APNs(애플) 푸시 API 서버 접속 정보(허용목록) + 인증·프로토콜 요구사항 + 프록시 설정 시 주의사항 및 예제

---

1) 허용(Allowlist) 호스트 · 포트 (최소)

프록시/방화벽에서 아래 대상에 대해 outbound(아웃바운드) TLS(443) 허용을 권장합니다.

Google FCM (HTTP v1)

호스트(주요 엔드포인트)

fcm.googleapis.com

OAuth 토큰 발급/관리용: oauth2.googleapis.com (또는 www.googleapis.com의 토큰 엔드포인트)

포트: TCP 443 (HTTPS)

API 경로 예시:

https://fcm.googleapis.com/v1/projects/{PROJECT_ID}/messages:send (메시지 전송).

Apple APNs

호스트

Production: api.push.apple.com

Development (sandbox): api.sandbox.push.apple.com

포트: TCP 443 (HTTPS, HTTP/2 over TLS)

프로토콜: HTTP/2 + TLS 1.2 이상 필수. 요청은 HTTP/2 POST로 전송.

> 참고: Google/Apple 쪽에는 추가적으로 인증·토큰 발급을 위한 엔드포인트(예: Google의 토큰 엔드포인트)로의 접근도 필요합니다. OAuth 토큰을 발급받는 서버 주소(oauth2.googleapis.com 등)를 차단하면 FCM 호출이 실패합니다.

---

2) 인증·요구사항 요약 (푸시 서버가 꼭 준비해야 할 것)

FCM (Google)

인증 방식: HTTP v1은 Google OAuth 2.0 액세스 토큰(서비스 계정 기반, 짧은 수명 토큰)을 사용. 서비스 계정 JSON으로 토큰을 발급받아 Authorization: Bearer <ACCESS_TOKEN> 헤더로 호출. (Application Default Credentials 권장)

엔드포인트: https://fcm.googleapis.com/v1/projects/{PROJECT_ID}/messages:send.

주의: 레거시 https://fcm.googleapis.com/fcm/send는 더이상 권장/지원되지 않음(마이그레이션 필요).

APNs (Apple)

인증 방식: 두 가지

JWT 기반 provider token (.p8 키 + Key ID + Team ID) — 권장. 서버가 JWT를 발급해 Authorization: bearer <jwt>로 요청.

(구식) TLS certificate 기반(예전 방식) — 현재는 토큰 방식 권장/보편화.

요구 프로토콜: HTTP/2 + TLS(1.2+), POST 요청, apns-topic(앱 번들 id) 등 헤더 필요.

---

3) 프록시(Proxy) 적용 시 실무 권장/주의사항

A. 프록시 방식 선택

TLS 터널링(HTTP CONNECT) 방식 권장

내부서버 → 프록시 (CONNECT) → 원격 FCM/APNs 서버로 TLS 세션을 직접 수립.

이 방식은 프록시가 TLS를 복호화하지 않고 터널링만 하기 때문에 Apple/Google의 TLS/HTTP2 요구사항을 깨뜨리지 않음(안정권).

투명 프록시 / SSL Inspection 적용 시 주의

SSL 가로채기(중간자 복호화)를 하면 APNs의 HTTP/2/TLS 연결이 깨질 수 있고(인증/검증 실패) 정상 동작을 보장하지 못합니다. APNs는 엄격한 TLS 요구가 있고, 중간자 인증서를 신뢰하지 않으면 연결 실패 가능성이 큽니다. (따라서 APNs/FCM에 대해서는 TLS 패스스루(검사 제외) 를 권장).

B. 프록시 기능·제약

APNs (HTTP/2)

APNs는 HTTP/2를 요구하므로 프록시가 HTTP/2 터널링을 지원하거나, 최소한 CONNECT로 TLS 터널을 열어준 뒤 클라이언트가 HTTP/2로 통신하도록 해야 합니다. 일부 구형 프록시는 HTTP/2 프록시링을 지원하지 않아 문제를 일으킬 수 있습니다.

FCM (HTTPS)

일반 HTTPS(HTTP/1.1 or HTTP/2)로 통신하므로 대부분의 프록시에서 터널링으로 정상 동작. 다만 OAuth 토큰 발급(google oauth 엔드포인트)도 동일하게 허용돼야 합니다.

C. 권장 프록시 설정(예시)

방화벽: 직접 tcp/443을 차단하고 오직 프록시(또는 프록시 IP)를 통한 443 통신만 허용.

프록시: CONNECT 메서드 허용 + 대상 호스트(예: fcm.googleapis.com, oauth2.googleapis.com, api.push.apple.com, api.sandbox.push.apple.com)와 포트 443 허용.

SSL 검사(복호화)는 APNs/FCM 대상에 대해 비활성화(예외) — TLS 패스스루.

---

4) 실제 서버(애플리케이션)에서의 프록시 설정 예제

1) 리눅스 환경(환경변수 방식)

Node / curl / 대부분의 HTTP 클라이언트가 HTTP_PROXY / HTTPS_PROXY 환경변수를 사용합니다.

export HTTPS_PROXY="http://proxy.example.local:3128"
export HTTP_PROXY="http://proxy.example.local:3128"

Google SDK(애플리케이션 기본 자격증명 사용)도 환경변수를 통해 프록시를 인식합니다(라이브러리에 따라 다름).

2) curl 예제 (FCM 토큰발급 → 메시지 전송)

# (예) OAuth 토큰 발급 (서비스 계정 JWT 교환) - 토큰 엔드포인트로 요청
curl -x http://proxy.example.local:3128 \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=<JWT>" \
  https://oauth2.googleapis.com/token

# FCM send
curl -x http://proxy.example.local:3128 \
  -H "Authorization: Bearer <ACCESS_TOKEN>" \
  -H "Content-Type: application/json; UTF-8" \
  -d '{ "message": { ... } }' \
  "https://fcm.googleapis.com/v1/projects/PROJECT_ID/messages:send"

3) APNs (Node 예시) — 주의: HTTP/2 + TLS 터널 필요

APNs용 라이브러리(예: node-apn, http2 클라이언트)를 쓸 때는 프록시를 통해 TLS 터널을 만드는 tunnel 같은 모듈을 사용해야 할 수 있습니다.

또는 운영환경에서 프록시를 통한 TLS 터널링(CONNECT) 을 허용하고, 클라이언트는 평상시처럼 api.push.apple.com:443에 HTTP/2로 연결하면 됩니다.

APNs는 JWT 토큰(.p8)으로 인증하므로, 토큰 생성 로직은 서버에서 처리(비공개 키 보관)해야 합니다.

---

5) 보안·운영 체크리스트 (권장)

1. 허용목록(Allowlist): fcm.googleapis.com, oauth2.googleapis.com, api.push.apple.com, api.sandbox.push.apple.com → TCP/443 허용.

2. 프록시 방식: TLS 터널링(CONNECT) 사용 권장 — SSL Inspection 금지/예외 처리.

3. 인증 자료 보관:

FCM: 서비스 계정 JSON(비밀) 안전 보관 / 자동 만료 토큰 사용.

APNs: .p8 키 + Key ID + Team ID 안전 보관, JWT 발급 주기(최대 1시간 추천).

4. 테스트: Sandbox (api.sandbox.push.apple.com)과 Production (api.push.apple.com) 모두 프록시 통과 테스트.

5. 로깅·모니터링: 프록시/방화벽 로그로 outbound 실패(권한/인증/연결 실패) 모니터링.

---

6) 추가 권장 사항 · 흔한 문제

레거시 FCM 사용 금지: 레거시 엔드포인트는 종료되었으니 HTTP v1으로 마이그레이션 필요.

프록시 성능 이슈: 대량 푸시(대규모 알림 트래픽)는 프록시 병목을 유발할 수 있으니 프록시 용량·커넥션 제한을 사전 검토하세요.

APNs 토큰 만료/갱신: APNs Provider token은 만료 관리(토큰 생성 시 유효기간)를 신경써야 합니다.