앱 MVP Android 대화 버블: 사용자 허용·대화 요건·일반 알림 폴백을 나누는 5가지 기준
앱 MVP Android 대화 버블: 사용자 허용·대화 요건·일반 알림 폴백을 나누는 5가지 기준
Android 앱 MVP에 대화 버블을 넣을 때 핵심은 ‘작은 채팅창을 띄운다’가 아닙니다. 이 기능이 실제 사람 사이의 진행 중인 대화에 맞는지, 사용자가 버블을 허용했는지, 대화 알림과 바로가기가 연결됐는지, 버블이 되지 않을 때 일반 알림에서도 같은 업무가 가능한지를 각각 확인해야 합니다. 버블이 한 번 화면에 보였다고 해서 모든 기기·모든 대화에서 기능이 완료된 것은 아닙니다.
Android Developers는 버블을 사용자가 다른 앱 위에서 대화를 보고 참여할 수 있게 하는 알림 기능으로 설명합니다(C001). 사용자는 앱의 모든 버블을 막거나, 선택한 대화만 허용하거나, 앱이 보낸 버블 메타데이터를 모두 허용하도록 설정할 수 있습니다(C001).
따라서 MVP의 첫 결정은 ‘어떤 사용자 과업을 대화로 볼 것인가’와 ‘버블을 선택하지 않은 사용자가 무엇을 하는가’입니다. 이 글은 특정 기능이 응답률이나 재방문을 높인다고 주장하지 않습니다. 출시 전에 기능 범위와 QA 증거를 분리하는 기준을 다룹니다.
먼저 구분할 것: 대화 기능, 일반 알림, 버블 표시는 같은 상태가 아닙니다
Android의 대화 영역은 사람 사이의 실시간 대화용입니다. 공식 문서는 SMS, 텍스트 채팅, 전화처럼 빠른 상호작용을 기대하는 흐름을 예로 들고, 이메일이나 사람 사이 대화와 무관한 활동에는 그 기대가 없다고 설명합니다(C002). 단순 공지, 배치 완료, 상품 추천을 ‘대화’로 포장해 버블로 보내는 판단은 피하는 편이 좋습니다.
버블은 알림 API에 추가 메타데이터를 붙여 만드는 표시 방식입니다(C001). 반면 일반 알림은 버블이 꺼져 있거나 요건을 만족하지 않을 때도 사용자가 내용을 보고 앱으로 이동할 수 있는 기본 경로입니다. ‘알림 발송 성공’, ‘대화 영역에 분류됨’, ‘버블로 확장됨’, ‘사용자가 답장을 읽고 처리함’을 하나의 성공 신호로 합치지 마세요.
구분 | MVP에서 확인할 질문 | 완료로 단정하면 안 되는 것 |
|---|---|---|
대화 정의 | 실제 사람 사이의 빠른 상호작용인가 | 메시지 형태의 모든 이벤트 |
알림 | 버블이 꺼져도 내용을 보고 이동할 수 있는가 | 서버가 푸시 요청을 보낸 사실 |
버블 | 사용자가 허용했고 기기 요건을 충족하는가 | 개발 기기에서 한 번 표시된 화면 |
대화 목적지 | 특정 대화로 바로 열리는가 | 앱 홈이 열리는 동작 |
처리 확인 | 읽기·답장·후속 행동을 관찰했는가 | 버블 아이콘이 존재하는 상태 |
기준 1: 먼저 ‘버블로 해도 되는 대화’를 한 가지 사용자 과업으로 좁힙니다
버블은 다른 앱 위에 떠서 화면 공간을 사용합니다. Android Developers도 진행 중인 커뮤니케이션처럼 중요하거나 사용자가 명시적으로 요청한 경우에만 사용하라고 안내하며, 사용자가 버블을 끄면 같은 알림이 일반 알림으로 동작해야 한다고 설명합니다(C001). 그래서 MVP에서는 상담원과 고객의 진행 중인 1:1 메시지, 예약 변경을 논의하는 채팅처럼 상대·문맥·다음 행동이 분명한 한 흐름을 먼저 고르는 편이 낫습니다.
각 버블에 무엇을 표시할지도 정하세요. 새 메시지 요약, 상대 표시명, 마지막 메시지 시각, ‘대화 열기’의 목적지는 개인정보 최소화 원칙과 함께 검토할 항목입니다. 잠금 화면과 always-on display에서는 버블이 일반 알림처럼 보인다는 점도 고려해야 합니다(C001). 잠금 화면에서 보여도 되는 텍스트와 앱 안에서만 보여야 하는 상세 내용을 같은 범위로 취급하면 안 됩니다.
이 기준을 기록할 때는 “채팅 기능 출시” 대신 다음처럼 적을 수 있습니다. ‘이번 버전은 이미 대화가 시작된 사람 간 1:1 메시지에만 버블 후보를 만든다. 공지·자동 리마인더·마케팅 알림은 일반 알림으로 남긴다. 사용자가 버블을 막은 경우에도 해당 메시지를 일반 알림에서 열 수 있어야 한다.’ 이는 사용량 성과 약속이 아니라 범위를 재검토할 수 있는 제품 기록입니다.
기준 2: 대화 알림·long-lived 바로가기·버블 메타데이터를 따로 검수합니다
Android 11 이상을 대상으로 하는 앱에서 대화 알림으로 분류되려면 MessagingStyle을 쓰고, 유효한 long-lived 동적 또는 캐시된 공유 바로가기와 연결하며, 사용자가 대화 영역에서 내리지 않은 상태여야 합니다(C002). 버블 문서도 Android 11 이상에서는 버블 메타데이터나 알림이 공유 바로가기를 참조해야 한다고 안내합니다(C001).
즉, 메시지 내용만 바꾸거나 PendingIntent만 연결했다고 대화·버블 요건이 자동으로 충족되는 것은 아닙니다.
실무에서는 대화 ID와 바로가기 ID를 같은 대화 단위로 추적하는지 확인하세요. Android Developers는 들어오고 나가는 같은 대화의 메시지가 같은 바로가기 ID를 써야 하며, 바로가기가 그 대화 화면으로 직접 열려야 한다고 권장합니다(C002). 닉네임이나 마지막 메시지 텍스트를 식별자로 쓰면 변경·중복·재가입 상황에서 무엇이 같은 대화인지 불명확해질 수 있습니다.
버블을 펼친 화면은 선택한 Activity에서 만듭니다. 이 Activity는 resizeable이고 embedded가 가능해야 하며, 그렇지 않으면 시스템이 알림으로 표시한다고 공식 문서가 설명합니다(C001).
대화가 여러 개일 수 있다면 각 대화의 화면 인스턴스가 분리되는지도 점검 대상입니다. Android 10 이하에서 여러 버블을 지원하는 조건과 Android 11 이상의 기본 동작은 다를 수 있으므로, 지원 최소 버전과 target SDK를 함께 기록하세요.
우리 앱 MVP의 대화 알림·바로가기·QA 기준 점검하기
기준 3: 사용자 설정은 앱의 요청과 별개로 읽고, 일반 알림 폴백을 준비합니다
사용자는 앱 전체의 버블을 차단하거나, 선택한 대화만 버블로 허용하거나, 모두 허용할 수 있습니다(C001). 또한 대화 알림은 사용자가 알림 채널 설정에서 대화 영역에서 제외할 수 있습니다(C002). 앱이 BubbleMetadata를 포함해 알림을 보냈다는 사실과 사용자가 실제로 버블을 볼 수 있다는 사실은 다른 관찰입니다.
일반 알림 폴백은 실패 화면이 아니라 기본 경험입니다. 버블이 막힌 경우에도 알림을 탭하면 해당 대화로 이동하고, 읽지 않은 상태·답장·오류 안내가 같은 사용자 문맥에서 이어져야 합니다. 버블 문서는 사용자가 버블을 껐을 때 버블 알림이 일반 알림으로 나타난다고 설명합니다(C001). 따라서 QA 표에는 버블 허용·선택 허용·전체 차단·알림 자체 차단을 분리해 넣으세요.
알림 채널도 별도 경계입니다. Android 8.0(API 26) 이상에서는 모든 알림이 채널에 속해야 하며, 채널을 만든 뒤에는 중요도 등 알림 동작을 앱이 바꿀 수 없고 사용자가 최종 제어합니다(C003). 버블 문제가 생겼을 때 새 빌드에서 채널 중요도를 바꾸면 해결된다고 가정하지 말고, 채널 ID·현재 사용자 설정·대화별 설정·앱의 폴백 화면을 함께 확인해야 합니다.
기준 4: 버블 화면의 생명주기와 ‘읽음’ 처리를 분리해 설계합니다
버블을 펼치면 해당 콘텐츠 Activity는 일반 프로세스 생명주기를 거칩니다. 버블을 접거나 닫으면 Activity가 파괴되고, 다른 포그라운드 구성요소가 없으면 프로세스가 캐시된 뒤 종료될 수 있습니다(C001). 그래서 화면이 접혔다고 대화가 종료됐다고 보거나, 버블이 다시 열렸다고 입력 중 상태가 자동 복원된다고 단정하면 안 됩니다.
MVP에는 최소한 대화 식별자, 마지막으로 확인한 메시지, 임시 입력값을 어떤 저장 범위에서 다룰지 정해야 합니다. 전송 완료·네트워크 재시도·상대가 대화를 삭제한 경우도 별도 상태입니다. 이 글의 범위는 특정 저장 기술을 지시하지 않습니다. 다만 버블 Activity가 파괴되는 조건을 고려하지 않은 임시 상태는 실제 기기에서 잃을 수 있으므로, 복귀 결과를 관찰해야 한다는 점을 남깁니다.
읽음 상태도 버블 아이콘의 존재와 다릅니다. Android Developers는 접힌 버블에 새 메시지가 오면 배지가 표시되고, 사용자가 관련 앱에서 메시지를 열면 BubbleMetadata를 업데이트해 알림을 숨기고 OnlyAlertOnce로 반복 소리·진동을 막는 방법을 안내합니다(C001).
팀은 ‘알림을 표시했다’, ‘사용자가 대화 화면을 열었다’, ‘해당 메시지를 읽음으로 처리했다’, ‘새 메시지의 배지를 갱신했다’를 이벤트 이름과 관찰 로그에서 구분하는 편이 좋습니다.
관련 글 앱 MVP Android 알림 권한: 요청 시점·선택·채널을 나누는 기준은 권한 요청과 채널 설계의 경계를 다룹니다. 이번 글은 사람 사이 대화만 버블로 연결할 때의 사용자 허용·바로가기·표시 폴백에 초점을 둡니다.
기준 5: 표시 확인이 아니라 대화별 복귀 경로를 실제 기기에서 검수합니다
버블 문서에 따르면 Android 11 이상에서는 대화 요건을 만족하지 않는 알림이 버블 대신 일반 알림으로 나타날 수 있습니다(C001). 대화 문서는 알림을 길게 눌러 대화 관련 메뉴가 보이는지 확인하면 바로가기 통합을 검증할 수 있다고 안내합니다(C002). 개발자 화면에서 아이콘을 띄우는 테스트만으로는 사용자 설정·대화별 목적지·일반 알림 폴백을 충분히 확인할 수 없습니다.
출시 전에는 실제 지원 기기와 계정 두 개를 사용해 대화 단위로 다음 흐름을 남겨 보세요.
사용자 A와 B가 같은 대화 ID로 메시지를 주고받고, A의 알림이 올바른 대화로 연결되는지 확인합니다.
A가 버블을 허용한 경우와 막은 경우에 각각 해당 대화로 이동하는지 확인합니다.
버블을 펼친 뒤 접기·닫기·다시 열기를 수행하고, 읽음 상태와 입력·복귀 정책이 의도한 대로인지 확인합니다.
대화가 삭제되거나 상대 권한이 바뀐 경우에 오래된 바로가기·버블이 어떤 안내를 보이는지 확인합니다.
알림 채널과 대화별 설정을 바꾼 뒤, 앱이 사용자의 선택을 덮어쓰지 않고 적절한 설정 화면 또는 폴백을 제공하는지 확인합니다.
이 기록은 버블이 모든 사용자에게 노출된다는 증거도, 메시지 기능의 성과 증거도 아닙니다. 어느 대화·어느 기기·어느 설정에서 무엇을 실제로 관찰했는지 남기는 QA 근거입니다. 다음 기능 확장에서는 이 기록을 바탕으로 대화 범위를 넓힐지, 일반 알림만 유지할지를 결정할 수 있습니다.
출시 전 대화 버블의 사용자 설정과 폴백 흐름 정리하기
자주 묻는 질문
모든 푸시 알림을 버블로 보내도 되나요?
권장되지 않습니다. Android Developers는 버블을 진행 중인 커뮤니케이션처럼 중요하거나 사용자가 명시적으로 요청한 경우에 쓰라고 안내합니다. 이메일이나 사람 사이 대화와 무관한 활동은 대화 기능의 기대와 다를 수 있으므로, 먼저 실제 대화 과업인지 정하세요.
BubbleMetadata를 넣으면 Android 11 이상에서 항상 버블로 보이나요?
그렇게 단정할 수 없습니다. Android 11 이상을 대상으로 하는 경우 대화·바로가기 요건이 필요하고, 사용자는 앱 전체 또는 특정 대화의 버블을 막을 수 있습니다. 요건이나 설정이 맞지 않으면 일반 알림 폴백에서도 해당 대화로 이동할 수 있어야 합니다.
버블 화면을 닫으면 입력 중이던 내용도 계속 남나요?
자동으로 보장되지 않습니다. 버블을 접거나 닫을 때 콘텐츠 Activity가 파괴될 수 있으므로, 임시 입력과 읽음 상태를 어떤 범위에서 보존할지 정하고 실제 기기에서 닫기·재열기 결과를 확인해야 합니다.
알림 채널의 중요도를 새 앱 버전에서 바꾸면 사용자의 설정도 바뀌나요?
아닙니다. Android는 채널을 만든 뒤 중요도 같은 알림 동작을 앱이 바꿀 수 없고 사용자가 최종 제어한다고 안내합니다. 현재 채널·대화별 설정과 폴백 화면을 함께 확인하세요.
공식 출처
Android Developers: Use notification bubbles for conversations — 2026-09-23 직접 확인
Android Developers: People and conversations — 2026-09-23 직접 확인
Android Developers: Create and manage notification channels — 2026-09-23 직접 확인
발행일: 2026-09-23 · 작성: 유인어스 정책자금·정부지원사업 인사이트