사용자가 비활성화하지 않는 푸시 알림: 타이밍과 설계

사람들이 푸시 알림을 비활성화하는 이유

성가신 알림은 누군가가 하루종일 어깨를 톡톡 두드리는 것처럼 느껴지고, 당신이 자리를 떠나면 놀란 척합니다. 알림은 방해하고 주의를 요구하며, 종종 아무런 보상도 주지 않습니다. 며칠만 그런 경험을 하면 사람들은 가장 단순한 선택을 합니다: 당신을 조용히 합니다.

대부분의 옵트아웃은 직관적인 이유에서 일어납니다. 메시지가 너무 자주 오거나 관련성이 없거나 잘못된 시간(심야, 업무 중, 사용자가 이미 작업을 끝낸 직후)에 도착하기 때문입니다. 때로는 내용이 모호하거나 클릭베이트 같아 신뢰를 잃습니다. 그리고 첫 알림이 사용자가 앱의 가치를 이해하기 전에 도착하면 이렇게 들립니다: "당신은 나를 거의 모르는데 잠금화면에 접근하려고 하네요."

푸시 비활성화는 정신적 잡음을 줄이는 방법이기도 합니다. 많은 사람들이 이미 이메일, 소셜 앱, 단체 채팅에서 알림 피로를 느낍니다. 당신의 앱이 약간의 무작위한 알림을 추가하면 다른 것들과 함께 묶여 차단됩니다. 모바일에서는 그 결정이 가혹합니다: 한 번 꺼지면 많은 사용자가 다시 켜지 않습니다.

진짜 목표는 한 번 권한을 얻는 것이 아닙니다. 매 메시지가 그 자리를 얻을 때까지 권한을 수개월간 유지하는 것입니다.

좋은 알림은 정의하기 쉽습니다: 기대 가능한(expected), 유용한(useful), 시기적절한(timely) 것입니다. 기대 가능하다는 건 사용자가 왜 이 알림을 받았는지 추측할 수 있다는 뜻입니다. 유용하다는 건 사용자가 이미 신경 쓰고 있는 일을 돕는다는 뜻입니다. 시기적절하다는 건 시스템이 준비된 때가 아니라 실제로 도움이 될 때 도착한다는 뜻입니다.

옵트아웃을 유발하는 패턴은 예측 가능합니다: 첫 실행 시 명확한 이유 없이 권한을 요청하기, 개인적 가치가 없는 "그리워요" 메시지 보내기, 사용자가 두 번 무시한 뒤 동일한 리마인더를 반복하기, 일상 업데이트에 긴급성 단어를 붙이기, 마케팅 발송을 중요한 알림과 같은 채널로 섞어 보내기 등입니다.

푸시를 특권처럼 대하면 사용자는 혜택으로 여깁니다. 무료 광고 공간처럼 다루면 사용자는 스팸으로 취급합니다.

누가 옵트인할 의지가 있는가

사람들은 알림이 앱이 아니라 자신을 도울 것이라고 믿을 때 "허용"을 탭합니다. 사람들이 비활성화하지 않는 푸시 알림을 얻는 가장 쉬운 방법은 권한을 가치 교환으로 취급하는 것입니다: 구체적인 약속을 하고 꾸준히 지키세요.

권한을 묻기 전에 약속을 평이한 언어로 말하세요. "최신 상태 유지" 같은 모호한 문구는 피하세요. 대신 무엇이 도착할지, 왜 중요한지, 사용자가 무엇을 제어할 수 있는지 설명하세요. 좋은 사전 권한 화면은 세 가지에 답합니다: 무엇을 보낼지(주문 상태, 리마인더, 가격 인하, 보안 알림), 얼마나 자주 보낼지(그리고 "드물게"가 실제로 무엇을 의미하는지), 그리고 나중에 어떻게 변경할 수 있는지(환경설정, 음소거, 조용한 시간).

알림은 사용자가 이미 가진 목표와 일치할 때 옵트인이 늘어납니다. 사용자가 달성하려는 바를 기준으로 생각하세요, 당신이 홍보하고 싶은 것을 기준으로 생각하지 마세요.

사람들은 구체적인 가치에 대해 훨씬 더 옵트인합니다: 절약("가격 인하"), 리마인더("약속이 2시간 남음"), 업데이트("배송이 10분 내 도착"), 안전("새로운 로그인"), 또는 진행상황("주간 목표 달성").

초기에 기대치를 설정하세요. 덜 "영업적"처럼 느껴져도 괜찮습니다. 예를 들어 일주일에 다섯 번 메시지를 보낼 것이라면 그렇게 말하세요. 트리거 전용(배송 업데이트처럼)이라면 그 또한 명시하세요. 놀라움은 불신을 만들고, 불신은 옵트아웃으로 이어집니다.

시스템 권한 창이 나타나기 전에 작은 예시를 보여주세요. 한 줄짜리 현실적 예시는 한 단락의 문구보다 더 효과적일 수 있습니다:

"샘플 알림: 배송이 출발했습니다 - 도착 예정 3:10~3:40 PM"

이 한 줄은 사용자가 그 순간이 시간을 절약해 줄 것을 상상하게 도와주고, 스팸을 보낼 계획이 아니라는 신호를 줍니다.

자연스럽게 느껴지는 권한 타이밍

대부분의 사람들은 알림을 싫어하는 게 아닙니다. 너무 이르게 요청받는 것을 싫어합니다. 권한 타이밍은 사람들이 알림을 끄지 않는 것과 영원히 끄는 것의 차이를 자주 만듭니다.

간단한 규칙이 있습니다: 사용자가 관심을 증명한 행동 바로 다음에 요청하세요. 누군가가 항목을 저장하거나 주제를 팔로우하거나 예약을 하거나 운동을 마쳤다면 그들은 어떤 것이 중요한지 보여준 것입니다. 그 행동에 연결된 업데이트를 제공할 순간입니다.

신뢰할 수 있는 패턴은 시스템 권한 창 전에 소프트-요청(soft-ask) 화면을 두는 것입니다. 짧고 구체적으로 유지하세요: 무엇을 받을지, 얼마나 자주 받을지, 그리고 왜 도움이 되는지. 그런 다음 두 개의 명확한 버튼을 넣으세요: "Allow notifications"와 "Not now." 사용자가 "Allow"를 선택했을 때만 시스템 권한 창을 표시하세요. 이렇게 하면 놀람을 제거하고 기대치를 설정할 수 있습니다.

요청하기 좋은 순간은 보통 성과 직후입니다(주문 완료, 목표 달성), 팔로우/구독 직후, 저장/북마크 직후, 리마인더 설정 또는 추적 시작 직후, 기능을 켰을 때 등입니다.

나쁜 순간은 사용자가 바쁘거나 불안하거나 회의적인 때입니다. 첫 실행 시 권한을 묻는 것은 흔한 실수인데, 아직 신뢰가 없기 때문입니다. 가입(signup) 중에 묻는 것도 위험합니다. 사람들은 양식, 비밀번호, 인증을 처리하느라 바쁘기 때문입니다.

만약 사용자가 거부하면 처벌하지 말고 계속 팝업으로 괴롭히지 마세요. 우아하게 복구하세요. 앱을 정상적으로 계속 사용할 수 있음을 확인시키고, 이후에 해당 기능 근처의 설정에서 조용한 옵션을 노출하세요. 예: "저장한 항목이 변경되면 알림 받기"라는 토글을 보여, 선택이 실제 혜택에 연결되어 있다고 느끼게 하세요.

구체적 예: 리세일 앱에서 사용자가 "사이즈 8 부츠"에 대한 검색을 저장하면, "검색 저장"을 탭한 직후 화면에 "새 매물이 나타나면 알림 받을래요? 하루에 최대 1회 보냅니다."라고 표시하세요. 이 요청은 사용자가 방금 요청한 것에 연결되어 있기 때문에 정당하게 느껴집니다.

알림 환경설정 센터 설계하기

좋은 환경설정 센터는 안전 밸브입니다. 사용자가 시스템 수준에서 알림을 끄는 대신 스스로 조정할 수 있게 해 줍니다.

사람들이 빠르게 이해할 수 있는 세 가지 제어부터 시작하세요: 주제, 빈도, 조용한 시간. 주제는 그들이 실제로 관심 있는 것을 선택하게 합니다. 빈도는 많은 옵트아웃 뒤에 숨은 진짜 질문에 답합니다: "왜 이렇게 자주 메시지를 보내죠?" 조용한 시간은 비활성화로 가는 가장 빠른 경로를 막아줍니다: 잘못된 시간의 진동 하나가 원인이 됩니다.

포함할 제어 항목(및 라벨링 방법)

선택지를 작고 평이하게 유지하세요. 20개의 토글을 제공하면 사람들은 관리하지 않고 그냥 끕니다.

다음처럼 짧은 집합을 목표로 하세요: 주제 카테고리(주문, 리마인더, 보안, 제품 업데이트 등 사용자가 쓰는 단어로), 빈도 옵션(즉시, 일간 요약, 주간 요약), 조용한 시간(기기 시간 기준 창), 채널 선택(푸시 vs 이메일 vs 인앱 알림), 일시중지 옵션(24시간 또는 7일 스누즈).

기본값은 중요합니다. 도움이 되지만 공격적이지 않은 기본값을 선택하세요. 많은 제품에서 안전한 기본값은: 필수 알림 켜기(보안 또는 거래 상태), 마케팅성 업데이트 끄기, 가능하면 요약 빈도로 설정하는 것입니다. 모든 것이 기본으로 켜져 있다면 첫날부터 알림 피로를 만들고 있습니다.

어디에 배치할지

환경설정을 깊은 설정 메뉴에만 숨기지 마세요. 사람들이 관심 가질 때 자연스럽게 찾는 곳에 두세요.

핵심 행동 후에 작은 프롬프트를 제공하고 주제와 빈도 선택으로 바로 안내하세요. 예를 들어 주문을 한 직후에는 "주문 상태" 푸시만 켜게 하고 "프로모"는 끈 상태로 둘 수 있게 하세요.

또한 계정/설정 내부와 인앱 인박스 같은 알림이 표시되는 곳 근처에 쉽게 찾을 수 있게 하세요. 사용자가 짜증나면 10초 이내에 "일시중지"나 "덜 자주" 옵션을 찾을 수 있어야지 시스템 토글을 찾으러 가지 않게 하세요.

Koder.ai로 제품을 만드는 경우, 환경설정 센터를 각주가 아닌 우선 기능으로 취급하세요. 옵트인을 유지하는 것이 다시 얻는 것보다 비용이 적게 듭니다.

사용자가 신뢰하는 메시지 디자인

사람들은 메시지가 도움 되는 톡 한 번처럼 느껴질 때 알림을 켜둡니다. 최고의 푸시 알림은 왜 도착했는지, 사용자가 다음에 무엇을 할 수 있는지를 분명히 합니다.

사람처럼 쓰세요. 짧고 평이한 단어를 사용하고 중요한 정보를 먼저 배치하세요. "Your report is ready"는 "New update available"보다 낫습니다. 구체적 표현이 재치있는 표현보다 낫습니다.

한 메시지엔 한 목적만 가지세요. 뉴스, 프로모, 리마인더를 한 알림에 섞으면 광고처럼 보이고 사용자는 무시하도록 학습합니다. 더 할 말이 있으면 알림 수를 줄이고 앱 내부에서 처리하세요.

개인화는 얻어야 합니다. 사용자가 분명히 한 행동을 기반으로 하세요, 당신의 추측이 아니라.

예: 누군가가 어제 소스 코드를 내보냈다면, "Export finished. Your ZIP is ready"는 타당합니다. 모바일 앱을 만들라고 한 적 없는 사람에게 "Build a mobile app today?"를 보내면 무작위적이고 섬뜩하게 느껴집니다.

긴급성은 괜찮습니다. 압박은 안 됩니다. 진짜 긴급성은 드라마 없이 결과를 설명합니다:

• 좋은 예: "Payment failed. Update your card to avoid losing access tomorrow."
• 나쁜 예: "Last chance! Act now!"

타이밍은 사람들이 생각하는 것보다 더 중요합니다. 유용한 메시지도 잘못된 시간에 도착하면 성가심이 됩니다. 로컬 시간을 존중하고 일반적인 수면 시간은 피하세요. 업무 관련 제품이라면 정말 긴급한 경우가 아니면 일반적인 근무 시간 안에 머무르는 것이 좋습니다.

잘 작동하는 간단한 템플릿

일관된 구조는 사용자가 당신의 스타일을 신뢰하도록 돕습니다:

• 무슨 일이 일어났는가(짧은 문장 1개)
• 왜 중요한가(선택적, 짧은 문구)
• 무엇을 할지(하나의 명확한 액션)

Koder.ai 같은 제품을 위한 예: "Deployment failed. Check logs to retry." 직접적이고 사용자가 취한 행동과 일치하며 모든 것을 긴급한 것처럼 꾸미지 않습니다.

메시지가 구체적이고 기대에 맞고 시기적절하면 사용자는 알림을 소음이 아니라 제품의 일부로 경험합니다.

단계별: 알림 시스템 계획하기

푸시 알림을 사람들이 비활성화하지 않게 하려면 카피만큼 계획이 중요합니다. 작은 계획이 "유용하다고 느껴지는 것"을 아무렇게나 보내며 피로를 만드는 일을 막아줍니다.

1) 알림 목록 작성

보낼 수 있는 모든 푸시 메시지를 나열하세요. 명백한 것들(주문 업데이트, 리마인더)과 "나중에"일 수 있는 것들(요약, 프로모)을 포함하세요. 각 항목에 작업명(working name)을 붙여 명확하게 이야기할 수 있게 하세요.

각 알림마다: 무엇을 위한 것인지, 누가 도움을 받는지, 사용자가 보고 난 뒤 무엇을 해야 하는지 한 문장으로 적으세요. 한 문장으로 답할 수 없다면 그 알림은 보낼 가치가 없을 가능성이 큽니다.

2) 목적별로 메시지 묶기

목록을 몇 개의 사람 친화적 버킷으로 묶으세요. 많은 앱에서는 다음이 대부분의 필요를 커버합니다: 리마인더(사용자가 요청하거나 시작한 일), 업데이트(사용자가 기다리는 상태 변경), 프로모(세일, 업셀, 마케팅), 안전/계정(보안 알림, 정책 변경), 팁/교육(사용자가 분명히 원할 때만).

이 그룹은 환경설정 UX의 뼈대가 됩니다. 사용자는 25개의 토글을 원하지 않습니다. 3~6개의 명확한 선택을 원합니다.

3) 트리거와 한도 결정하기

각 메시지에 대해 무엇이 트리거인지와 어떤 한도를 둘지 정의하세요. 트리거는 "언제 관련있는가?"에 답하고 한도는 "스팸을 어떻게 피할 것인가?"에 답합니다.

실용적인 세트는: 하루 최대, 주 최대, 조용한 시간(예: 사용자 현지 시간의 야간 푸시 금지). 또한 여러 알림이 경쟁할 때 어떤 알림이 우선인지, 어떤 알림을 버릴지 결정하세요.

4) 템플릿 작성하고 사용자 친화적으로 이름 붙이기

각 알림에 대해 짧은 템플릿(제목, 본문, 탭 액션)을 만드세요. 내부 코드명이 아니라 사용자가 설명할 법한 이름을 붙이세요. "Delivery update"는 "SHIP_STATUS_CHANGED_V2"보다 낫습니다.

이 명명 습관은 옵트인 메시징과 설정을 만들 때, 그리고 지원팀이 사용자가 받은 것을 설명할 때 큰 도움이 됩니다.

5) 실제 시나리오로 QA하기

단일 메시지를 따로 떼어 검사하지 말고 실제 여정으로 계획을 테스트하세요. 신규 사용자(신뢰 낮음), 복귀 사용자(놀람을 덜 원함), 파워 유저(높은 볼륨, 제어 필요)를 시나리오에 포함하세요. 프로모를 끄고 안전 알림은 켜두는 경우, 30일 비활성 사용자 등도 포함하세요.

어떤 시나리오에서든 푸시가 폭발적으로 몰리거나 타이밍이 혼란스럽거나 과도한 가정을 하는 메시지가 있다면 권한을 묻기 전에 트리거를 수정하거나 한도를 더 엄격히 하세요.

옵트아웃을 유발하는 흔한 실수

대부분의 사람들은 알림 자체를 싫어하는 게 아닙니다. 놀람, 잡동사니, 회사 이익을 위해 보낸 것처럼 느껴지는 메시지를 싫어합니다. 옵트인을 일회성 승리로 여기지 않고 지속적인 관계로 다루지 않으면 신뢰를 잃는 가장 빠른 길입니다.

흔한 실수는 앱을 열자마자 권한을 묻는 것입니다. 아무 맥락 없이 요청하면 랜덤하게 느껴져 사용자는 거부하거나 나중에 후회합니다. 더 나은 규칙은 분명한 이득이 생기는 순간 첫 "예"를 얻는 것입니다.

또 다른 신뢰 파괴 요인은 발송량입니다. 많은 팀이 옵트인 직후 "활성화"를 위해 메시지를 폭발적으로 보냅니다. 그건 대개 알림 피로를 만들고 사용자는 모든 것을 끕니다. 초기 메시지를 꼭 보내야 한다면 적게, 구체적으로, 사용자가 이미 취한 행동에 연결되게 보내세요.

모호한 카피도 옵트아웃을 유발합니다. "Check this out"이나 "Don't miss this" 같은 문구는 사용자가 왜 중단당했는지 알기 위해 앱을 열게 만듭니다. 가치가 진짜라면 솔직하게 말하세요.

타이밍 실수도 치명적입니다. 시간대를 무시하면 회의, 저녁, 수면 중에 사람들을 깨웁니다. 한 번의 새벽 3시 알림으로 모든 알림이 꺼질 수 있습니다.

마지막으로 환경설정을 쉽게 만드세요. 유일한 선택지가 "모두" 아니면 "없음"이라면 사용자는 "없음"을 선택합니다. 또한 사용자는 설정을 찾기 귀찮으면 일시중지 옵션 없이 모든 것을 끕니다.

대부분의 옵트아웃 뒤에는 일관된 패턴이 있습니다: 권한 요청이 너무 이르고, 옵트인 후 24~72시간 내에 알림이 너무 많이 오고, 메시지가 요점을 숨기며, 잘못된 시간에 전송되고, 단순한 제어(일시중지, 조용한 시간, 주제 선택)가 없습니다.

예: 쇼핑 앱이 아침 7시에 3일 연속으로 "Big news!"를 보내고 프로모를 음소거할 방법이 없다면 사용자는 주문 업데이트 같은 유용한 알림까지 포함해 알림을 완전히 끕니다.

전송 전에 빠르게 확인할 항목

전송 버튼을 누르기 전에 30초만 멈추세요. 대부분의 옵트아웃은 예상치 못한, 불분명한, 또는 너무 잦은 메시지 이후에 발생합니다.

5초 관련성 테스트

한 가지 질문을 하세요: 사용자가 지금 이걸 예상하고 있을까?

배달이 출발했을 때의 배송 업데이트는 말이 됩니다. 누가 이미 그 아이템을 산 다음날 프로모를 받는 것은 아닙니다. 빠른 체크리스트를 사용하세요:

• 사용자가 방금 한 행동(또는 분명히 신경 쓰는 것)과 일치하는가?
• 첫 줄만 보고도 이해할 수 있는가?
• 사용자의 현지 시간대에 적절한 시간에 도착하며 조용한 시간을 피하는가?
• 이 유형의 메시지가 얼마나 자주 올 수 있는지 상한이 있는가?
• 마음에 들지 않으면 이 카테고리를 설정에서 끌 수 있는가?

그런 다음 낯선 사람처럼 메시지를 읽어보세요. 가치가 즉시 분명하지 않으면 첫 줄을 다시 쓰세요. 많은 맥락이 필요하면 그건 아마 푸시가 아닙니다.

피로를 막는 타이밍 및 제어 점검

두 가지가 조용히 피로를 만든다: 잘못된 타이밍과 탈출구 부재. 로컬 시간은 생각보다 중요합니다. 당신에게 오전 9시는 그들에게 새벽 2시일 수 있고, 한 번의 무례한 깨움이 채널을 잃게 할 수 있습니다.

빈도 상한은 다른 하나의 가드레일입니다. 카테고리별 상한(예: 주당 프로모 2회)을 정하고 마케팅이 흥분해도 지키세요. 규칙을 어기는 순간 사용자는 계속될 것이라 믿습니다.

마지막으로 환경설정 센터가 해당 카테고리를 포함하는지 확인하세요. 빠른 점검: 사용자가 불평하면 지원팀이 10초 이내에 정확히 어디서 바꿀지 말할 수 있나요? 아니라면 아직 그 메시지를 보낼 준비가 안 된 것입니다.

예: 누군가 항공권을 검색했다면 가격 인하 알림 한 건은 도움이 됩니다. 하루에 세 번 알림을 보내고 "가격 인하"를 음소거할 방법이 없으면 거래가 진짜여도 스팸처럼 느껴집니다.

현실적인 예: 성가시게 하지 않고 옵트인 얻기

식단 계획 앱을 상상해 보세요. 푸시 옵트인을 원하지만 첫인상이 나쁘면 빠른 비활성화로 이어진다는 걸 압니다.

첫 세션에서는 사용자에게 먼저 도움을 줍니다. 레시피를 검색하고 즐겨찾기를 저장하며 간단한 주간 계획을 만듭니다. 권한 팝업은 없습니다. 대신 작은 메모를 보여줍니다: "원하면 나중에 리마인더를 받을 수 있어요." 사용자는 시스템 대화 상자가 아닌 작업에 집중합니다.

앱이 요청할 권리를 얻는 순간은 분명한 행동에 연결됩니다. 사용자가 레시피 3개를 저장하면 부드러운 화면을 표시합니다(아직 OS 권한 팝업 아님): "요리할 시간에 리마인더를 받을래요? 어떤 걸 받길 원하는지 선택하세요." 사용자가 "예"를 탭하면 앱이 권한 요청을 트리거합니다. "나중에"를 탭하면 앱은 물러나고 정상 작동을 계속합니다.

다음 화면은 평이한 언어와 합리적 기본값을 가진 간단한 환경설정 센터입니다. 몇 가지 선택지만 제공합니다: 식사 리마인더(계획한 날에 하루 최대 1회), 새로운 레시피(주간 요약), 할인(원할 경우에만). 각 옵션은 빈도를 설명합니다. 예: "식사 리마인더: 계획한 날에 하루 최대 1회." "새 레시피: 주 1회." 할인은 기본적으로 꺼져 있습니다.

일주일 후 결과는 보통의 "실행 시 묻기" 방식과 다릅니다. 옵트인 비율은 전반적으로 낮을 수 있지만, 옵트인한 사용자는 더 만족합니다. 전송량은 적고 앱은 해당 유형의 메시지를 요청한 사람에게만 알립니다. 그 결과 비활성화와 전체 끄기 순간이 줄어듭니다.

이것이 사용자가 비활성화하지 않는 푸시 알림을 얻는 방법입니다: 권한 요청을 사용자가 이미 얻은 승리와 연결하고, 모든 메시지가 그들이 개인적으로 요청한 것처럼 느껴지게 하세요.

측정, 개선, 다음 단계 결정

알림을 제품 기능처럼 취급하세요: 결과를 측정하고 한 가지를 바꾸고 빠르게 학습하세요.

우선 신뢰를 얻고 있는지 아니면 태우고 있는지 알려주는 결과를 추적하세요. 단순 오픈에 그치지 마세요. 비용 측면도 봐야 합니다:

• 화면/순간/사용자 세그먼트별 옵트인 비율
• 특정 알림 후 및 시간 경과에 따른 비활성화 비율
• 오픈율(탭 후의 후속 행동 포함)
• 이탈 신호(언인스톨, 세션 감소, 이메일 구독 취소)
• 환경설정 편집(어떤 카테고리를 끄는지 vs 전체 끄기)

다음으로 최악의 원인을 검토하세요. 특정 카테고리, 시간대, 또는 반복 템플릿이 비활성화를 유발하는 패턴이 있는지 찾으세요. 모든 알림에 목적 태그(리마인더, 업데이트, 프로모, 보안)를 붙여 "어떤 메시지가 1,000전송당 가장 많은 옵트아웃을 일으키는가?"에 답할 수 있게 하세요. 먼저 그것들을 고치세요.

큰 재출시 대신 작은 테스트를 하세요. 한 번에 한 변수만 변경하세요: 요청 시점을 더 늦추기(명확한 성공 순간 후), 혜택을 구체적으로 바꾼 카피 테스트, 카테고리별 빈도 상한 설정, 필수-알려야하는 것과 선택적-알려야하는 것을 분리, 초기에는 켜진 카테고리 수를 줄이는 등.

환경설정을 눈에 보이게 하고 편집을 쉽게 유지하세요. 사용자가 한 종류의 메시지만 빠르게 음소거할 수 있다면 전체를 끌 가능성이 줄어듭니다. 실용적인 규칙: 어떤 알림이든 환경설정 센터에서 2번의 탭 이내에 편집 가능해야 합니다.

빠르게 움직이려면 권한 플로우와 환경설정 센터를 Koder.ai에서 구축하고 반복하면(koder.ai) 변경사항을 빠르게 배포하고 준비되면 소스 코드를 내보내 다음 단계로 나아갈 수 있습니다.