--- title: "앰플리튜드 Guides를 통해 푸시 팝업 매끄럽게 유도하기" description: "앰플리튜드 Guides & Surveys를 통해 하이브리드앱에 빠르게 팝업을 띄워 푸시 설정을 유도해보았습니다." date: 2026-08-30 tags: [ux, tooling] sections: [technical] draft: false --- > ⏱️째깍악어🐊 선생님 앱에서 **푸시 알림 대상자를 확보**하기 위해 DB와 앰플리튜드로 현황을 분석하고 [Amplitude Guides & Surveys](https://amplitude.com/ko-kr/guides-and-surveys)를 통해 **앱 배포 없이 팝업을 운영**해보았습니다. > 이 글에서는 의사결정 단계에서부터 맥락별 UX 라이팅, 이벤트·사용자 속성 및 트리거 구성까지 하나의 기능이 프로덕트에 담기기까지 전 단계에서 고민한 흔적들을 정리해 보았습니다. 데이터 기반으로 푸시 유도를 고민하시는 프로덕트 엔지니어분들께 도움이 되기를 바랍니다. ⏱️째깍악어🐊 선생님 앱에서 푸시 알림은 **주변 공고 추천, 채팅, 지원 결과 알림 등 서비스의 핵심 기능을 전달하는 통로**입니다. 다만 최근 DB와 앰플리튜드 로그를 확인해보니 **푸시 설정을 끄고 있는 선생님**이 생각보다 많더라구요. 푸시 허용한 사용자 수치가 점점 하향 곡선을 그리고 있는 상황이었는데요. 물론 근본적으로는 저희가 제공하는 푸시의 설득력이 약하기 때문이라고도 해석할 수 있겠지만(예: _지나치게 잦거나 원치 않는 주변 공고 추천으로 짜증난 사용자가 푸시를 끄는 상황_) 지속적으로 유입되는 CS를 확인하면 꼭 그렇지도 않은 상황처럼 보였습니다. > **CS 중** > 🗣️​ "공고를 너무 늦게 봐서 놓쳤어요." > 🗣️​ "부모님 채팅을 못 봐서 돌봄 장소가 바뀐지 몰랐어요." > 🗣️​ "...(지원 결과 확인 안해 노쇼)" 게다가 ⏱️째깍악어🐊는 단일 푸시 허용 방식이 아닌 **개별 푸시 항목에 대해서 허용 여부를 설정**할 수 있기 때문에 시스템 푸시는 허용한 채로 개별 푸시를 끄는 방식으로 서비스를 사용할 수도 있는 상황이었는데요. 아래처럼요. | 개별 푸시 항목을 켜고 끌 수 있는 상황 | | :---------------------------------------------------------------------------------------: | | ![개별 푸시 항목을 켜고 끌 수 있는 상황](/imgs/posts/2026-08-30/type-of-pushes.webp){360} | 그럼에도 대다수의 선생님들이 시스템 알림 설정조차도 끈 상태로 두고 있다는 것은 **우리의 푸시가 어떤 기능을 하는지, 또 어떻게 푸시를 켜야 하는지** 인지조차 하지 못한 상태라는 것을 방증하는 지표처럼 보였습니다. | 시스템 푸시를 허용한 선생님들의 비율: 대략 1/3이 시스템 알림을 꺼두고 계셨습니다. | | :-------------------------------------------------------------------------------: | | ![시스템 푸시 허용 선생님 비율](/imgs/posts/2026-08-30/system-push-allowed.webp) | 결과적으로 **핵심 이벤트의 푸시 수신에 대한 필요성과 이를 저지하는 문제 상황은 충분히 확인**된 바, 우리 플랫폼 그룹은 우선 선생님들의 푸시 허용률 상승을 목표로 여러 작업들을 수행해보기로 했습니다. 그 중에서 저는 **푸시 허용 팝업을 통해 선생님들의 시스템 알림과 서비스 푸시 허용을 동시에 유도**하는 작업에 착수해 보았습니다. ## 푸시 허용 실태를 조금 더 들여다 보니 작업 착수에 앞서 조금 더 데이터를 들여다 보았었는데요, **푸시 허용 관련해서 다소 특이한 양상**을 확인할 수 있었습니다. 바로 활동량이 많은 선생님들과 이제 막 활동을 시작하는 선생님들 사이에서 푸시 허용 비율 간극이 꽤나 컸다는 점이었는데요, 활동량이 많은 **슈퍼악어 선생님들은 푸시 알림을 허용(푸시 중 하나라도 허용)한 비율은 80%에 육박**한 반면, 이제 **막 활동을 시작한 선생님들은 약 30% 정도만이 푸시 알림을 허용**하고 계신 상황이었습니다. 다만 푸시 유형별로 쪼개보니 [공고 알림 동의] 푸시에서는 그 간극이 조금 좁혀져 있는 상황이긴 했는데요, 이는 우리의 추천 공고 알림이 선생님들에게 적절하지 않게 전달되고 있음을 시사하기도 해서 추후의 과제로 남겨둔 상황입니다. | 등급 | 교사 수 | 둘 다 미동의 | 공고 알림 동의 | | :--------------------: | ----------: | -----------: | -----------------: | | 악어알 (프로필 미완성) | 178,750 | 14,798 | 77,368 (43.3%) | | ... | ... | ... | ... | | 슈퍼악어 | 2,526 | 35 | 1,416 (56.1%) | | **합계** | **198,000** | **17,660** | **87,655 (44.3%)** | 다시 푸시 허용으로 돌아와서, 푸시 허용과 활동량에 대한 인과를 확인할 수는 없지만 최소한의 상관 관계는 확인된 바, 푸시 유인은 주로 **신규 사용자 층에서 발생**할 것으로 해석할 수 있었습니다. 다시 말하면 **아직 깊게 일하지 않았거나 알림 가치를 모르는 선생님들에게는 여전히 푸시 유인이 확실히 있는 상황인 것이죠.** 푸시 허용을 유도해서 우리의 매끄러운 공고 지원 프로세스를 경험할 수 있다면 **슈퍼 악어**로까지 우리 서비스에 깊게 인볼브하게 만들 수 있다(_물론 인과는 증명되지 않았습니다!_)는 생각에 서비스의 리텐션 측면에서도 푸시 유도는 그 의미가 있어 보였습니다. ### 유의미한 푸시 채널 그렇다면 알림을 켠 사용자에게 푸시 채널은 실제로 작동하고 있었을까요? 이는 **푸시 도달율(푸시를 실제로 클릭하여 앱 진입) 지표**를 통해 확인할 수 있었습니다. 실제로 **푸시를 통해 서비스에 진입한 사용자가 많다면(=도달율이 높다면), 푸시 채널 자체는 충분히 의미가 있다고 확언**할 수 있는 것이죠. 이를 위해 `utm`을 활용했습니다(미리 `utm_source`로 `push`를 심어뒀던 스스로를 칭찬했습니다 👏). `utm_source=push`, `utm_content=offer-recommendation`으로 필터링한 **추천 공고 푸시 클릭 후 Page Viewed** 추이를 보면, 일별 **1,000~2,300건** 수준의 유입이 꾸준히 발생하고 있었습니다. 주 1회 정도 눈에 띄는 피크도 보였는데요, 추천 공고 푸시가 단순히 발송만 되는 것이 아니라 **실제로 앱 진입으로 이어지고 있다**는 뜻이기도 했습니다. | 추천 공고 푸시 클릭 후 Page Viewed 일별 추이 | | :------------------------------------------------------------------------------------: | | ![추천 공고 푸시 유입 Page Viewed](/imgs/posts/2026-08-30/recommend-push-clicked.webp) | 이처럼 푸시는 우리의 핵심 기능을 보여주는, 실제로 유의미한 통로​임이 확인되었음에도 아직 일부 선생님들에게는 이러한 푸시의 가치를 충분히 경험되지 못하는 상황이었는데요. 결국 남은 문제는 **어떤 사용자에게, 언제, 어떻게 푸시 설정을 안내할 것인가**​에 대한 문제였습니다. 앱(웹)을 다시 배포하지 않고도 이 문제를 빠르게 검증하고 운영할 수 있는 방법으로 저는 **Amplitude Guides**를 선택했습니다. 👉 [앰플리튜드 Guides 확인하기](https://amplitude.com/ko-kr/guides-and-surveys) ## Guides를 통해 빠르게 띄운 팝업 시스템 OS 알림을 허용하면 사용자들은 무엇을 얻을 수 있을까요? 앞서 말했듯이 ⏱️째깍악어🐊 선생님 앱에서의 푸시 알림은 **주변 공고 추천, 채팅, 지원 결과 알림** 등 실시간 결과가 핵심인 다양한 기능들을 지원하고 있습니다. 이러한 **사용자 니즈가 명확하게 수면 위로 떠오르는 시점에 유도 팝업을 띄운다**면 그 효과가 분명할 것이라는 생각에 서로 다른 두 가지 맥락에서 두 가지 팝업을 설정했습니다. ### 두 가지 맥락, 두 가지 팝업 (1): 홈 진입 홈은 서비스 사용자라면 무조건 방문하게 되는, 탐색과 발견의 공간입니다. 사용자는 아직 특정 행동을 완료하지 않은 상태이고 **놓칠 수 있는 혜택·맞춤 공고**라는 프레임 자체가 이 맥락과 자연스럽게 연결됩니다. 때문에 파괴력이 강한 홈 화면에 팝업을 배치함으로써 최대한 많은 사용자가 푸시 허용에 대한 이득을 자연스럽게 인지할 수 있도록 했습니다. | 홈 진입 시 노출되는 팝업 | | :-----------------------------------------------------------: | | ![홈 진입 팝업](/imgs/posts/2026-08-30/home-dialog.webp){400} | **잠재적인 손해 상황을 암시**하는 "놓치지 마세요" 문구와 함께 하단의 서브 문구로 **잠재적인 이득 상황을 동시에 제시**함으로써 **사용자의 손실 회피 심리와 보상 욕구를 자극**하는 전략을 취했습니다. 이때 **팝업에서는 기존의 푸시 설정 스위치 디자인과 유사한 디자인을 미리 노출**함으로써 사용자가 길을 잃지 않고 이후 플로우에서 유사한 스위치로 시선이 옮겨갈 수 있도록 했습니다. 다만 강력한 힘은 강력한 부작용을 초래하는 법, **홈에서의 팝업은 사용자를 피로하게 만들 가능성**이 높기 때문에 적확한 노출 조건이 필요했습니다. 1. **시스템 OS 푸시를 허용하지 않은 사용자를 대상**으로만 팝업을 띄웠습니다. 해당 사용자는 앱이 실행되는 시점 플러터 브릿지를 통해 네이티브에서 판단, 앰플리튜드에 전달되므로 식별이 가능합니다. 2. **동일한 사용자에게 하루 최대 1회**만 팝업이 띄워지게끔 설정했으며, 팝업과 마주한 사용자가 **_닫기_ 버튼을 클릭하면 3일 동안은 팝업이 띄워지지 않도록** 빈도를 조정해 두었습니다. 놀랍게도 앰플리튜드에서는 이러한 기능들을 간편하게 제공하고 있어 약간의 코드 수정만으로도 목적을 쉽게 달성할 수 있는 상황이었습니다! (감사해요 앰플리튜드 👏) -- ### 두 가지 맥락, 두 가지 팝업 (2): 공고 지원 완료 홈 진입 팝업과는 달리 지원 완료 팝업은 공고 지원이라는 **행동이 막 끝난 직후**, 아직 시스템 알림이 꺼져 있는 사용자에게 노출됩니다. 모두 시스템 알림이 꺼져 있는 사용자이지만 이 지점에서의 사용자는 **홈 진입 시점의 사용자와는 조금 다른 상황**에 처해져 있습니다. 때문에 UX 라이팅을 조금 다르게 가져가 보았습니다. | 공고 지원 완료 후 노출되는 팝업 | | :-------------------------------------------------------------------: | | ![지원 완료 팝업](/imgs/posts/2026-08-30/post-apply-dialog.webp){400} | 우선 해당 지점의 사용자는 이미 **공고 지원**이라는 핵심 동작을 진행했습니다. 공고 지원이라는 행위는 기본적으로 **스트레스를 유발**하기 마련입니다. 공고를 탐색하고 자기 소개를 작성하는 과정을 통과하며 사용자는 에너지를 많이 소모하기 때문입니다. 더구나 공고 지원 직후는 **결과가 아직 나오지 않은 불확실한 상태**입니다. 탈락이나 대기처럼 **불확실성 자체가 불안감을 야기**할 수 있는 순간이기도 하죠. | 공고 지원 과정에서 사용자가 통과하는 정보 입력 상황 | | :---------------------------------------------------------------------: | | ![공고 지원 플로우](/imgs/posts/2026-08-30/offer-apply-sample.gif){360} | 이때 "놓치면 손해"라는 **손실 회피 프레임을 사용하는 것은 오히려 압박과 불안을 증폭**시킬 가능성이 있습니다. 그래서 지원 완료 팝업에서는 손실 회피를 의도적으로 배제하고, 사용자에게 **통제감**을 부여하는 방향으로 라이팅을 풀어내 보았습니다: _알려드릴까요_ 같은 질문형 구조를 사용해서 선택권 자체를 사용자에게 넘겼고, _지원 결과를 바로 받아보세요_ 라는 문장으로 정보에 대한 수신을 사용자가 능동적으로 선택할 수 있음을 전달했습니다. 정리하면 두 팝업 모두 **알림을 켜달라**는 동일한 목표를 가지고 있지만 팝업이 노출되는 지점과 해당 지점에서의 사용자 특성에 따라 UX 라이팅을 다르게 가져감으로써 팝업의 효과를 극대화시켜 본 것입니다. 맥락에 따라 다른 설득 프레임을 사용한 것이죠. ## 측정 가능하게 만든 이벤트와 사용자 속성 Guides 팝업을 운영하려면 **트리거 조건과 결과 측정**이 모두 가능해야 합니다. 이를 위해 이벤트 로그와 사용자 속성을 심어 지속적으로 측정이 가능하도록 해두었습니다. ### 이벤트 로그 | 이벤트 | 의미 | 파라미터 | | :------------------------------: | :--------------------------------------: | :-----------------------------------------------------------: | | `system_notification_permission` | 앱 진입 시 최초 1회, 알림 허용 여부 확인 | `isGranted`: true/false | | `set_notification` | 푸시 알림 설정 변경 시 | `notification_type`: chat/offer/system, `enabled`: true/false | `system_notification_permission`은 앱 진입 시 최초 1회 판단되어 앰플리튜드에 이벤트 형태로 전달됩니다. 물론 사용자 속성을 통해 푸시 허용 사용자를 발라낼 수도 있지만 퍼널 등을 활용하기에는 능동적으로 이벤트 자체를 수신 하는 것이 유리하여 추가한 것입니다. `set_notification`은 알림 설정 페이지(하단 이미지 참고)에서 스위치를 통해 ON/OFF가 변경될 때 유형과 상태를 포착합니다. 시스템 푸시를 허용하지 않은 사용자에 한하여서는 아래와 같은 안내 섹션을 별도로 띄워 기기의 알림 설정 페이지로 사용자를 이동시키며 전후의 푸시 상태를 측정해 이벤트를 쏘아냅니다. | 알림 설정 페이지 | | :----------------------------------------------------------------------------: | | ![알림 설정 페이지](/imgs/posts/2026-08-30/screen-push-notification.webp){280} | ### 사용자 속성 | 속성 | 의미 | 값 | | :---------------------------: | :-----------------------: | :--------: | | `system_notification_allowed` | 시스템(OS) 알림 허용 여부 | true/false | 기존에 추적하고 있던 채팅과 공고 푸시 허용 여부에 더해 시스템 알림 허용이라는 신규 사용자 속성을 추가했습니다. 다만 시스템 알림 허용 여부는 네이티브단에서 비동기적으로 포착이 가능한 속성이기에 **앰플리튜드를 처음으로 로드(`amplitude.identify`)하는 시점에서는 이 값이 누락될 가능성**이 있습니다. 때문에 별도의 플러그인으로 처리하여 **최초 로드 이후 사용자 상태를 업데이트**하는 방식으로 구현하였습니다. ```ts function AmplitudeNotificationPermissionPlugin({ children, }: PropsWithChildren) { const sendNotificationPermission = (isGranted: boolean) => { if (!isApp()) return; /* * Tracker 인터페이스를 통해 사용자 속성 업데이트 처리합니다. * 이 지점은 사용자 속성이 특정된 이후의 시점입니다. */ Tracker.update("system_notification_allowed", isGranted); }; useEffect(() => { const handleVisibilityChange = async () => { // 해당 플러그인을 심어둔 지점에서 시스템 푸시 여부를 포착합니다. const result = await FlutterBridge.callHandler< "handleCheckNotificationPermission", BridgeResponse<{ isGranted: boolean; }> >("handleCheckNotificationPermission", {}); sendNotificationPermission(result?.data?.isGranted ?? false); }; /* *** */ }, []); } ``` ## 결과 지속적으로 추적하기 우리의 궁극적인 목적인 시스템 알림 허용자 증대라는 목적을 추적하기 위해 차트를 만들고, 앰플리튜드 대시보드 형태로 추적하는 방향을 선택했습니다. 알림 허용 부산물로 채팅/공고 알림 허용자 수도 증가할 것임을 기대하면서 관련 지표에 대해서도 측정할 수 있도록 해두었습니다. | 앰플리튜드 대시보드 | | :-----------------------------------------------------------------------------: | | ![앰플리튜드 대시보드](/imgs/posts/2026-08-30/amplitude-dashboards-sample.webp) | 1. **시스템 알림 허용**: `system_notification_allowed = true` 사용자 수(비율) 증가 - 교차 검증을 위해 `system_notification_permission` 유니크 이벤트 수도 동시에 추적 2. **채팅/공고 알림 허용**: `set_notification` where `notification_type: chat/offer` & `enabled: true` 유니크 이벤트 수, `chat_allowed`·`recommend_allowed` 변화 추가적으로 Guides에서 기본적으로 제공하는 [인사이트] 기능을 이용하여 두 팝업이 얼마나 노출되었고, 사용자에게 얼마만큼의 반응을 이끌어 냈는지 지속적으로 확인하였습니다. | 홈 진입 팝업 추이 | | :-----------------------------------------------------------------------------: | | ![앰플리튜드 대시보드](/imgs/posts/2026-08-30/amplitude-home-guide-sample.webp) | | 공고 지원 완료 팝업 추이 | | :------------------------------------------------------------------------------: | | ![앰플리튜드 대시보드](/imgs/posts/2026-08-30/amplitude-apply-guide-sample.webp) | 해당 데이터를 기반으로 지속적으로 추이를 확인했고, 푸시 허용 팝업 관련 인사이트를 정리해 팀에 공유드렸습니다. 3명 중 1명이 시스템 알림을 허용해 놓은 최초 시점에 반해 **푸시 유도 팝업 시행 이후 절반 정도의 사용자가 시스템 알림을 허용**, 사용자 알림 허용 분포가 조금씩 변경되는 ✨**꽤나 긍정적인 결과**✨를 낳고 있습니다. 다만 추천 공고 푸시를 비허용하는 사용자가 꾸준히 증가하고 있어, 후속 작업으로 사용자 맞춤 추천 공고 로직을 변경하는 작업에 착수하려 합니다. | 푸시 허용 관련 7일 추이 | | :----------------------------------------------------------------: | | ![앰플리튜드 대시보드](/imgs/posts/2026-08-30/guide-result-7.webp) | | 푸시 허용 관련 7+일 추이 | | :-----------------------------------------------------------------: | | ![앰플리튜드 대시보드](/imgs/posts/2026-08-30/guide-result-7+.webp) | ## 마무리하며 이번 작업을 돌아보면 **초기 인사이트 → 분석 → Guides 운영 -> 결과 측정 -> 후속 작업 결정**이라는 흐름이 꽤 매끄럽게 이어졌다고 느낍니다. 여러 지점에서 이미지 생성 에이전트, 앰플리튜드 같은 툴들을 잘 활용했기 때문인 것 같습니다. 개인적으로 가장 인상 깊었던 지점은 **같은 목표(알림 허용)라도 맥락별로 UX 라이팅을 달리한 지점**이었습니다. 처음 메시지를 기획-디자인 팀에 공유드렸을 때 부정적인 의견도 있었는데요, 홈에서는 손실 회피가 자연스럽지만 공고 지원 직후에는 오히려 통제감을 주는 것이 맞다는 제 판단을 기반으로 설득했죠. 그리고 **맥락을 나눈 가설과 사용자 반응이 같은 방향**이었기에 더 값지게 느껴집니다(물론 라이팅에 따라 다른 A/B 테스트를 진행한 것은 아닙니다만 두 맥락에서 사용자 반응성에 차이가 있다는 것이 이를 방증한다고 보고 있습니다). | UX 라이팅 전략을 팀에 소개시켜 드렸습니다 | | :-------------------------------------------------------------------------------------: | | ![지원 완료 시점의 UX 라이팅 전략 소개](/imgs/posts/2026-08-30/offer-apply-reason.webp) | 이벤트와 사용자 속성을 먼저 정비해 둔 덕분에 Guides뿐 아니라 향후 다른 채널의 실험에도 같은 데이터를 재사용할 수 있을 것 같습니다. 조직이 개편되면서 조금 더 빠른 속도로 협업하며 기능을 개발할 수 있었는데요, **좋은 서비스는 혼자 만드는 것이 아니라**는 점을 또다시 확인하는 작업이었습니다 ☺️. 긴 글 읽어주셔서 감사합니다.