예약 세션을 하나 돌려두고 자리를 비웠는데, 돌아와 보니 폰에 알림이 하나도 안 와 있었습니다. 세션 기록을 열어보니 몇 시간 동안 조건을 확인하긴 했는데 전부 정상이라 보고할 게 없었던 것뿐이었습니다. 처음엔 "알림이 안 가는 게 버그 아닌가" 싶었는데, 알고 보니 그게 의도된 동작이었습니다.
어떤 작업이었나
특정 조건을 주기적으로 확인하고, 문제가 생기면 그때만 알려달라고 맡긴 백그라운드 세션이었습니다. 처음엔 매번 확인 결과를 전부 알림으로 받고 싶었는데, 실제로 그렇게 설정하니 "이상 없음"이라는 알림이 하루에도 여러 번 쌓였습니다. 며칠 지나니 알림을 열어보지도 않고 넘기게 됐고, 정작 진짜 문제가 생긴 날에도 그냥 또 하나 쌓인 알림인 줄 알고 늦게 확인했습니다.
AI를 어떻게 활용했나
Claude Code에는 PushNotification이라는 도구가 따로 있습니다. 세션이 알아서 아무 때나 호출하는 게 아니라, "사람이 지금 이 자리에 없을 가능성이 높고, 돌아왔을 때 알아야 할 만한 일이 생겼을 때"로 호출 기준이 좁게 잡혀 있었습니다. 프롬프트를 이렇게 바꿔봤습니다.
"정해진 조건을 확인해. 이상이 없으면 그냥 조용히 종료하고,
조건을 벗어난 경우에만 PushNotification으로 무슨 일이 있었는지 알려줘."
이렇게 맡기고 나니 세션이 스스로 판단해서, 똑같은 "정상입니다" 결과에는 알림을 보내지 않고 세션 기록에만 남겼습니다. 알림 자체도 형식이 정해져 있었습니다. 본문 첫 문장이 폰 배너에 그대로 뜨는 구조라서, 가장 중요한 한 문장을 맨 앞에 놓아야 했습니다. 전체 문장은 길어도 상관없는데(이메일 본문으로 풀리는 구조), 배너에는 첫 문장만 노출되기 때문에 뒤에 설명을 붙이는 습관을 버려야 했습니다.
<routine_summary>
지난 1시간 동안 같은 에러가 3번 반복됨. 마지막 발생 14:32. 배포 #38291 이후 시작된 것으로 보임.
</routine_summary>
처음에 걸렸던 부분
터미널을 보면서 세션을 직접 돌리고 있는데도 같은 방식으로 알림을 보내보라고 시킨 적이 있었습니다. 호출은 됐는데 결과가 "not sent"로 돌아왔습니다. 실패한 줄 알고 재시도했는데 똑같았습니다. 나중에 알고 보니, 사용자가 지금 화면을 보고 있는 상태로 판단되면 알림을 중복으로 보지 않고 그냥 건너뛰는 구조였습니다. 화면으로 이미 결과가 보이는데 폰에까지 똑같은 내용을 또 띄우는 게 의미가 없다는 뜻이었습니다. 그러니 "not sent"가 떴다고 설정을 의심할 필요는 없었고, 오히려 그게 정상적으로 중복을 걸러낸 결과였습니다.
반대로 처음에 "모든 결과를 알려줘"라고 시켰을 때는 당연한 결과였지만 알림 피로가 바로 쌓였습니다. "이상 없으면 조용히 끝내라"는 조건을 프롬프트에 직접 넣어줘야, 정말 확인이 필요한 순간에만 알림이 왔습니다.
결과와 얻은 팁
- 백그라운드로 도는 반복 작업에는 "정상일 때는 알리지 말 것"이라는 조건을 프롬프트에 명시하는 편이 낫습니다. 기본값이 "뭐든 생기면 보고"에 가깝기 때문에, 조용히 넘어가야 할 기준을 직접 정해줘야 알림이 쌓이지 않습니다.
- 알림 문구는 첫 문장이 폰 배너라는 걸 염두에 두고 써야 했습니다. 결론부터 한 문장으로 쓰고, 그 다음에 근거나 추정 원인을 붙이는 순서가 실제로 더 쓸모 있었습니다.
- 터미널을 보고 있는 중에 같은 알림이 "not sent"로 돌아오는 건 실패가 아니라 중복 방지입니다. 폰으로 못 받았다고 바로 재전송을 시도하기보다, 지금 세션을 누가 보고 있는 상태인지부터 확인하는 게 맞는 순서였습니다.