들어가며
"일부 유저한테 인앱팝업이 안 떠요."
QA에서 올라온 이 한 줄짜리 리포트가, 결국 서드파티 SDK의 버그를 발견하고 리포트하는 데까지 이어질 줄은 몰랐습니다.
Playio에서는 인앱 메시징 서비스로 Notifly를 사용하고 있습니다.
캠페인 기반으로 특정 조건의 유저에게 팝업을 띄워주는 기능인데, 일부 유저에게만 팝업이 전혀 작동하지 않는 현상이 발생했습니다.
분명 같은 앱, 같은 버전인데 왜 이 유저만 안 되는 걸까?
문제 상황 — session_start가 찍히지 않는 유저
Notifly SDK는 앱이 시작될 때 `session_start`라는 이벤트를 로깅합니다.
이 이벤트가 정상적으로 기록되어야 SDK의 초기화가 완료된 것으로 간주되고, 이후 인앱팝업 캠페인이 정상 발송됩니다.
그런데 Notifly 대시보드에서 특정 유저의 로그를 확인해 보니, `session_start` 이벤트 자체가 찍히지 않고 있었습니다.
- `session_start` 로그 미발생
- 유저 ID가 `null`로 처리되는 케이스 존재
- 인앱팝업뿐 아니라 푸시 알림도 간헐적으로 미작동
초기화가 안 되니 당연히 캠페인 발송도 안 되는 상황이었습니다. 여기서 "왜 초기화가 안 되는가?"를 파고들기 시작했습니다.
원인 추적 — Application.onCreate()의 함정
Notifly SDK의 연동 가이드를 보면, `Application` 클래스의 `onCreate()`에 초기화 코드를 추가하도록 안내하고 있습니다.
저희도 그 가이드대로 `BaseApplication.onCreate()`에 Notifly 초기화 코드를 넣어두었습니다.
여기까지는 전혀 문제가 없어 보입니다. 대부분의 SDK가 이런 방식으로 초기화하니까요.
그런데 여기에 Android 프로세스 생명주기가 겹치면 이야기가 달라집니다.
Application.onCreate()는 "앱 실행 시"가 아니라 "프로세스 생성 시"에 호출된다
`Application.onCreate()`는 앱을 열 때마다 호출되는 게 아닙니다. 앱의 프로세스가 생성될 때 딱 한 번 호출됩니다.
보통은 이 둘이 같은 시점이라 차이를 느끼기 어렵지만, Foreground Service가 있으면 달라집니다.
Foreground Service가 프로세스를 살려둔다
저희 앱에는 게임 플레이 시간을 트래킹하는 Foreground Service가 있습니다.
유저가 다른 게임을 플레이하는 동안 백그라운드에서 서비스가 돌아가는 구조입니다.
문제는 이런 시나리오에서 발생합니다:
1. 유저가 앱을 실행 → 프로세스 생성 → Application.onCreate() 호출 → Notifly 초기화
2. Foreground Service가 프로세스를 유지
3. 유저가 최근 앱 목록에서 Playio를 스와이프하여 종료. 하지만 Foreground Service가 살아있으므로 프로세스는 죽지 않음
4. 유저가 다시 Playio를 실행 → 프로세스가 이미 살아있으므로 Application.onCreate()가 호출되지 않음
5. Notifly 초기화 누락 → session_start 미발생 → 인앱팝업 미작동
유저 입장에서는 분명 앱을 껐다가 다시 켠 건데, 내부적으로는 프로세스가 한 번도 죽지 않았기 때문에 `onCreate()`가 다시 호출되지 않는 것입니다.
결국 Foreground Service를 자주 사용하는 유저일수록 이 문제에 노출될 확률이 높았습니다.
Notifly에 리포트
원인을 정리한 후 내용을 Notifly 측에 리포트를 보냈습니다.
`session_start` 미발생 현상 재현 조건 (Foreground Service 동작 중 앱 재진입)
`Application.onCreate()`가 프로세스 재생성 없이는 호출되지 않는 점
Foreground Service가 프로세스를 유지하여 `onCreate()` 재호출이 누락되는 구조적 원인
Notifly 측에서도 문제를 확인했고, 초기화 로직이 팝업 관련 refresh, fetch 이외에도 여러 부분을 포함하고 있어 단순히 특정 인터페이스를 호출하는 식으로 우회하기는 어렵다는 점에서 SDK 레벨의 수정이 필요하다는 데 합의했습니다.
그리고 최근 수정된 버전이 나왔다는 소식을 전달받았습니다.
돌아보며
이 경험에서 몇 가지 배운 점이 있습니다.
서드파티 SDK도 "믿되 검증하라"
SDK를 도입하면 내부 구현을 블랙박스로 취급하기 쉽습니다.
하지만 문제가 생겼을 때 "SDK 문제인 것 같은데 우리가 할 수 있는 게 없다"로 끝내면 유저한테는 아무 의미가 없습니다.
SDK의 동작을 추적하고, 의심 가는 부분을 검증하는 과정이 결국 문제 해결로 이어졌습니다.
Application.onCreate()는 "앱 실행"이 아니라 "프로세스 생성"이다
대부분의 경우 이 차이가 문제가 되지 않지만, Foreground Service처럼 프로세스를 유지시키는 컴포넌트가 있다면 이야기가 달라집니다.
`Application.onCreate()`에만 의존하는 초기화 로직은, 프로세스가 살아있는 한 다시 호출되지 않습니다.
SDK를 만드는 입장에서도, 사용하는 입장에서도 이 점을 반드시 고려해야 합니다.
정확한 원인 분석이 빠른 해결로 이어진다
"팝업이 안 떠요"라고만 리포트했다면, 아마 훨씬 오래 걸렸을 겁니다.
Foreground Service와 프로세스 생명주기의 관계, `Application.onCreate()` 미호출 조건까지 정리해서 전달하니 Notifly 측에서도 빠르게 문제를 특정하고 수정할 수 있었습니다.
서드파티 라이브러리를 쓰다 보면 "이건 우리 코드가 아니니까"라고 선을 긋기 쉽습니다. 하지만 결국 유저가 경험하는 건 우리 앱이고, 문제의 원인이 어디에 있든 추적하고 해결하는 게 개발자의 역할이라고 생각합니다.
비슷한 상황을 겪고 계신 분들께 조금이나마 도움이 되었으면 합니다.
ⓒ 굿햄 2026. daryeou@gmail.com all rights reserved.
댓글