CLAWPOD ENGINEERING
브라우저 푸시가 안 올 때: 계정 설정과 기기 권한을 나눠 확인하기
ClawPod Cloud의 앱 내 알림과 브라우저 푸시를 구분하고, 수신 실패를 확인할 순서와 팀에 남길 기록을 정리합니다.
사무실에서는 보이던 알림이 집에서 쓰는 노트북에서는 보이지 않을 수 있습니다. 이 글은 ClawPod Cloud를 여러 기기에서 쓰는 실무자가 알림 수신 문제를 구분하고 팀에 확인 결과를 남기도록 돕습니다. 본인 계정으로 Portal에 접근할 수 있어야 하며, 설정 변경은 해당 기기의 사용자가 직접 결정합니다. 앱 내 알림은 제품 안에서 확인하는 알림이고, 브라우저 푸시는 브라우저의 알림 권한을 사용하는 별도 전달 방식입니다.
“켜짐”과 “수신 확인”을 따로 기록하세요
- 앱 내 알림 선호와 브라우저 푸시 선호를 구분합니다. 하나를 켰다는 사실만으로 다른 쪽도 준비됐다고 보지 않습니다.
- 푸시는 현재 브라우저와 사이트의 권한에 의존합니다. 실제로 사용할 기기마다 확인하세요.
- 알림이 없다는 이유만으로 원래 요청이나 작업이 없다고 판단하지 마세요. 중요한 내용은 연결된 원본 기록에서 확인합니다.
아래 경로는 공식 Guide가 설명하는 ClawPod Cloud Portal 기준입니다. Agent 실행 환경을 다루는 Agent Control UI의 설정 경로가 아닙니다. 현재 로그인 화면을 직접 확인한 안내는 아니므로 배포 환경의 메뉴와 다르면 관리자에게 확인하세요. 이 글은 푸시 전달을 보장하거나 모든 브라우저의 지원 여부를 판정하는 안내가 아닙니다.
먼저 본인 계정의 전달 선호를 확인합니다
Guide에는 두 진입 경로가 있습니다. 왼쪽 아래 계정 이름에서 설정 → 알림을 열거나, 상단 알림 → 모든 알림 보기를 엽니다. 개인 설정은 상단 관리자 메뉴와 별도입니다. 여기서 바꾸는 것은 본인 계정의 전달 선호이며, 다른 사용자의 설정이나 Agent 실행 정책을 바꾸지 않습니다.
Guide의 순서는 앱 내 알림을 켜거나 끄고, 지원되는 브라우저에서 푸시 알림을 켠 뒤 브라우저 권한 요청을 승인하는 것입니다. 자동으로 권한이 생긴다고 기대하지 마세요. 사용자가 푸시를 원할 때 직접 켜고, 브라우저가 제시하는 요청을 읽고 결정해야 합니다.
일반 웹 알림의 조건도 구분해 알아 두면 좋습니다. MDN은 권한 요청을 버튼 클릭 같은 사용자 동작에 응답해 해야 한다고 설명하고, Chrome과 Firefox에서는 보안 컨텍스트(HTTPS)가 필요하다고 설명합니다. 이는 브라우저 API의 조건이지 ClawPod Cloud의 전체 지원 목록이나 실제 전달 성공을 입증하는 자료는 아닙니다. Agent에게 “알림을 켜 줘”라고 말한 것만으로 브라우저의 사용자 허용을 대신했다고 보지 마세요.
브라우저와 기기가 바뀌면 다시 확인합니다
Guide는 푸시가 브라우저와 현재 origin의 권한에 의존한다고 설명합니다. 여기서는 접속한 Portal 사이트의 권한을 확인하세요. 다른 브라우저나 기기에서는 별도로 허용해야 합니다. 사무실 PC에서 허용한 사실을 집 노트북의 수신 증거로 쓰면 안 됩니다.
브라우저 권한을 거절했거나 환경이 지원하지 않으면 푸시 토글을 켤 수 없다는 것이 Guide의 설명입니다. 문제가 있으면 운영체제의 알림 차단과 브라우저의 사이트 권한을 함께 확인하세요. 거절 상태라면 같은 요청을 반복하기보다 해당 브라우저의 사이트 권한을 먼저 살펴봅니다. 권한을 바꿀지 여부는 기기의 사용자와 조직 정책에 따라 결정합니다.
| 증상 | 먼저 확인할 항목 | 이 확인만으로 알 수 없는 것 |
|---|---|---|
| 특정 기기에서만 보이지 않음 | 그 기기의 브라우저·사이트 권한과 운영체제 알림 차단 | 원래 이벤트가 발생했는지, 실제로 푸시가 전송됐는지 |
| 푸시 토글을 켤 수 없음 | 브라우저 권한 거절 여부와 환경 지원 여부 | 다른 브라우저에서도 동일한지 |
| 동료에게만 특정 유형이 보임 | 각자의 역할과 실제 표시되는 유형 | 모든 사용자에게 같은 유형이 제공되는지 |
| 설정 화면 자체를 찾지 못함 | 역할, 현재 조직, 상단 모드와 허용된 메뉴 | URL을 추측하거나 권한을 넓혀도 되는지 |
이 표는 진단을 시작할 순서입니다. “알림이 오지 않는다”의 원인을 무조건 브라우저 권한으로 단정하는 표가 아닙니다. 권한이 허용되어 있어도 실제 수신은 따로 확인해야 합니다.
예시: 집 노트북의 수신 상태를 팀에 인계하기
다음은 가상 예시입니다. 기기와 관찰 결과는 설명을 위한 표본이며 실제 시험 결과나 제품이 자동으로 만드는 보고서가 아닙니다. Room은 사용자와 Agent가 대화하는 공간입니다. 이 예시에서는 사용자가 직접 확인한 상태를 Agent에게 정리해 달라고 요청합니다.
독자의 요청
집 노트북에서는 알림이 보이지 않습니다. 제가 확인한 내용은 사무실 PC에서는 오늘 메시지 알림을 봤고, 집 노트북의 같은 Portal 사이트 권한은 차단 상태라는 것입니다. 집에서는 원래 Room의 메시지는 확인했습니다. 이 관찰을 표로 정리하고 다음 확인을 알려 주세요. 설정·권한을 바꾸거나 시험 알림을 보내지 마세요. 확인하지 않은 수신 성공을 완료로 적지 마세요.
채워진 결과 표본 — 가상 예시
| 대상 | 사용자가 제공한 관찰 | 판단과 다음 행동 |
|---|---|---|
| 사무실 PC | 오늘 메시지 알림을 봄 | 그때의 관찰만 기록. 집 노트북의 상태를 대신하지 않음 |
| 집 노트북 | 같은 Portal 사이트의 알림 권한이 차단됨 | 사용자가 브라우저 사이트 권한과 운영체제 차단을 확인. 변경 여부는 사용자 결정 |
| 원본 Room | 메시지 내용을 직접 확인함 | 해당 메시지 확인은 끝났지만, 집 노트북의 푸시 수신은 미확인 |
| 실행 범위 | 설정 변경·시험 발송 없음 | 수신 성공으로 종료하지 않고 다음 확인을 남김 |
성공 확인은 두 가지로 나눕니다. 먼저 표가 제공한 관찰과 일치하고, Agent가 설정 변경이나 수신 성공을 지어내지 않았는지 확인합니다. 다음으로 실제 푸시 준비 상태를 확인하려면 사용자가 승인한 변경 후, 허용된 메시지 상황에서 해당 기기의 알림과 원본 Room 메시지를 각각 확인해야 합니다. 이 절차는 팀의 검증 제안이지 제품에 전용 시험 발송 버튼이 있다는 뜻이 아닙니다. 관찰 시점·기기·브라우저·사이트와 실제 결과를 기록하세요.
실패 시 다음 행동도 같은 기록에 붙입니다. 권한이 허용되어 있는데도 보이지 않으면 “권한 허용, 수신 미확인”으로 남기고 운영체제 차단, 표시된 알림 유형과 원본 메시지를 확인합니다. 그래도 해결되지 않으면 그 관찰을 관리자에게 전달하세요. 시험을 반복 발송하거나 권한을 확대하지 말고, 해결 전에는 합의한 담당자가 원본 Room을 직접 확인하도록 인계합니다. 다른 알림 유형도 모두 전달된다고 일반화하지 않습니다.
역할별 유형과 대체 확인 경로를 함께 봅니다
Guide에 따르면 관리자 역할에는 메시지, Agent 오류·생명주기, 보안, 시스템, Skill, 사용량 같은 추가 유형이 표시될 수 있습니다. 테넌트 관리자는 멤버 관련 유형을 볼 수 있고, 일반 멤버에게는 메시지 알림만 표시될 수 있습니다. 화면에 표시되는 유형만 본인에게 켜거나 끌 수 있으므로, 동료의 화면을 그대로 따라 하라고 안내하지 마세요.
중요한 Agent 오류나 보안 알림을 끄기 전에는 대체 감시 경로를 확인하라는 것이 Guide의 주의사항입니다. 팀에서는 “누가 어떤 원본 기록을 언제 확인하는가”를 정하세요. 특정 대시보드가 모든 알림을 똑같이 대신한다고 가정하지 않습니다. 이 선호를 끄는 것은 Agent, 작업, webhook의 원본 이벤트·실행 기록을 삭제하는 동작이 아닙니다.
메뉴가 보이지 않으면 역할, 현재 조직, 상단 모드와 허용된 메뉴를 확인한 뒤 테넌트 관리자에게 문의합니다. 메뉴가 없다는 이유로 URL을 추측하거나 권한을 확대하지 마세요.
읽음, 알림 삭제, 원본 확인은 다른 행동입니다
Guide는 전체 알림 목록에서 유형·심각도 필터를 사용하고, 항목이 연결하는 대상을 확인한 다음 개별 또는 전체 읽음 처리를 선택하도록 설명합니다. 중요한 운영 알림은 읽음 처리 전에 연결된 Room이나 이벤트, 작업의 원본 기록을 확인하세요.
전체 알림 목록에는 삭제 버튼이 없고, 상단 알림 버튼으로 여는 패널에는 항목별 알림 삭제가 있습니다. 읽음 처리는 연결된 Room, 작업, Agent, webhook의 원본 데이터를 바꾸지 않습니다. “읽음으로 표시했다”, “알림을 삭제했다”, “원래 메시지 내용을 확인했다”를 인계 기록에서 서로 바꿔 쓰지 마세요.
탭을 모두 닫았거나 브라우저를 종료했을 때의 수신, 전달 지연과 재시도 보장은 이 글에서 확인하지 않았습니다. 중요한 업무의 유일한 감시 수단으로 푸시를 가정하지 마세요. 오늘은 실제 사용할 기기 하나를 골라 전달 선호, 브라우저 권한, 실제 수신 결과를 별도 항목으로 기록하는 것부터 시작하세요.
