AI 코딩 워크플로를 위한 푸시 알림: 안정적인 전달 엔지니어링

Claude Code는 복잡한 작업을 처리하는 데 수 분에서 수 시간이 걸릴 수 있습니다. 알림이 없으면 터미널을 계속 지켜보거나 주기적으로 돌아와서 중요한 것을 놓치지 않았기를 바랄 수밖에 없습니다. 어느 쪽이든 당신의 시간을 존중하지 않습니다.

푸시 알림은 Tactic Remote를 단순한 원격 뷰어가 아닌 워크플로 도구로 만들어 줍니다. 이 글에서는 알림 시스템의 구축 방법, Claude Code hook과의 통합, 전달 안정성 엔지니어링, 그리고 실제 개발자들에게서 관찰된 사용 패턴을 다룹니다.

핵심 인사이트

Tactic Remote에서 푸시 알림의 가치는 "휴대폰이 진동한다"가 아닙니다. 알림이 AI 코딩 에이전트와의 상호작용 시점과 방식을 바꾼다는 것입니다. 동기적인 터미널 모니터링 대신 비동기적인 작업 관리가 가능해집니다:

1. Mac(또는 iPhone 앱)에서 Claude Code 작업을 시작합니다.
2. 자리를 비웁니다. 커피를 타거나, 회의에 참석하거나, 퇴근합니다.
3. 작업이 완료되거나, 오류가 발생하거나, 승인이 필요할 때 휴대폰이 알려줍니다.
4. 몇 초 만에 검토하고 응답한 뒤, 하던 일로 돌아갑니다.

우리는 이것을 "책상이 아니라 휴대폰을 확인하는" 워크플로라고 부릅니다. CI/CD 알림과 같은 멘탈 모델입니다. 빌드 파이프라인을 지켜보는 것이 아니라 결과를 알려줄 때까지 기다리는 것입니다.

Claude Code Hook 통합

알림 시스템은 Claude Code의 hook 메커니즘으로 구동됩니다. Hook은 사용자가 구성할 수 있는 스크립트로, Claude Code가 정의된 라이프사이클 지점에서 실행합니다. Tactic Remote의 Mac 컴패니언 앱은 세 가지 이벤트 유형에 대해 hook을 등록합니다:

작업 완료 — Claude Code가 요청 처리를 완료하면 실행됩니다. Hook은 종료 상태, 변경 사항 요약, 터미널 출력의 마지막 몇 줄을 캡처합니다.

승인 필요 — Claude Code가 사람의 확인이 필요한 작업을 만나면 실행됩니다(프로젝트 디렉토리 외부의 파일 쓰기, 셸 명령, 네트워크 요청 등). Hook은 보류 중인 작업 설명과 고유한 승인 ID를 캡처합니다.

오류 — Claude Code가 치명적 오류, 도구 실패 또는 API 타임아웃을 만나면 실행됩니다. Hook은 오류 메시지와 관련 컨텍스트를 캡처합니다.

각 hook 호출은 구조화된 payload를 Mac 컴패니언 서버로 전송하고, 서버가 알림 라우팅을 결정하고, APNs(Apple Push Notification service) payload를 구성하여 알림 릴레이를 통해 전달합니다.

알림 유형의 실제 활용

각 알림 유형은 특정 상호작용 패턴을 위해 설계되었습니다:

작업 완료 알림 에는 작업 요약과 상태 표시기(성공 또는 부분 완료)가 포함됩니다. 알림을 탭하면 Tactic Remote 앱이 완료된 세션의 터미널 뷰로 바로 열려 출력을 검토할 수 있습니다.

승인 알림 은 가장 높은 우선순위를 갖습니다. 작업 설명("Claude가 프로젝트 디렉토리에서 rm -rf build/를 실행하려 합니다")이 포함되며 알림 배너에서 직접 승인/거부 액션을 제공합니다. iPhone에서는 앱을 열지 않고도 승인에 응답할 수 있습니다. 알림을 길게 누르면 인라인 액션이 표시됩니다. 텔레메트리 데이터에 따르면 승인의 62%가 앱을 완전히 열지 않고 알림 액션으로 처리됩니다.

오류 알림 에는 오류 범주와 잘린 메시지가 포함됩니다. 이들은 실행 가능하며, 탭하면 세션 뷰가 열려 전체 오류 컨텍스트를 검토하고 작업을 재시작할지 수정할지 결정할 수 있습니다.

전달 안정성

APNs는 푸시 알림의 전달을 보장하지 않습니다. Apple 문서에는 알림이 "최선의 노력(best effort)"이며 디바이스 전원 관리, 네트워크 상태, 속도 제한에 의해 누락될 수 있다고 명시되어 있습니다. 승인 알림 누락이 작업 정체를 의미하는 개발자 도구에서 "최선의 노력"은 충분하지 않습니다.

APNs 위에 여러 안정성 메커니즘을 쌓았습니다:

서버 측 상태 추적. Mac 컴패니언 서버는 모든 알림에 대한 전달 대장을 유지합니다. 각 알림에는 고유 ID, 타임스탬프, 전달 상태(대기 중, 전송됨, 확인됨, 만료됨)가 있습니다.

클라이언트 측 확인 응답. iPhone 앱이 알림을 수신하고 표시하면 Mac 컴패니언 서버로 확인 응답을 보냅니다. 30초 이내에 확인 응답이 도착하지 않으면 서버가 재전송합니다.

지수 백오프 재전송. 미확인 알림은 30초, 60초, 120초 간격으로 재시도됩니다. 3회 실패 후 알림은 전달 불가능으로 표시되고 Mac 컴패니언의 상태 UI에 플래그가 표시됩니다.

앱 내 동기화. iPhone 앱이 열리거나 백그라운드에서 복귀할 때 Mac 컴패니언에 미확인 알림을 조회하여 알림 센터에 표시합니다. 이를 통해 APNs가 완전히 누락시킨 알림도 포착할 수 있습니다.

중복 제거. 재전송에는 중복 전달의 위험이 따릅니다. 모든 알림은 고유 ID를 가지며 iPhone 클라이언트가 이를 추적합니다. 중복은 조용히 삭제되어 동일한 승인 요청이 두 번 표시되지 않습니다.

실제 운용에서 베타 사용자 기반 전체의 전달 성공률(알림 전송에서 알림 확인까지)은 10초 이내 97.3%, 60초 이내 99.6%입니다.

알림 중복 제거 상세

중복 제거는 사용자 신뢰에 영향을 미치므로 특별한 주의가 필요합니다. 개발자가 동일한 "파일 쓰기 승인" 알림을 두 번 보면 이미 승인했는지 의문을 갖게 됩니다. 이미 승인한 작업의 승인 알림을 보면 자신의 승인이 수신되었는지 의문을 갖게 됩니다.

중복 제거는 두 가지 수준에서 작동합니다:

전송 수준. 각 알림에는 재전송에 걸쳐 유지되는 UUID가 있습니다. iPhone 클라이언트는 최근 확인한 500개의 UUID 롤링 윈도우를 유지합니다. 이전에 확인된 UUID를 가진 알림은 표시 전에 삭제됩니다.

시맨틱 수준. 특히 승인 알림의 경우 클라이언트는 승인 ID가 이미 처리되었는지 확인합니다. 첫 번째 알림 전달로 작업을 승인했고 재전송이 도착하면, 전송 UUID가 다르더라도(서버가 재시도를 위해 새 push payload를 생성한 경우 발생 가능) 재전송은 억제됩니다.

개발자의 실제 사용 패턴

4개월간의 베타 데이터를 통해 명확한 패턴이 나타났습니다:

알림 피크 시간대 는 사용자의 현지 시간대 기준 오전 9-11시와 오후 2-4시로, 코딩 세션 시작과 점심 이후 생산적인 시간대에 해당합니다.

승인 알림의 평균 응답 시간 은 12초입니다. P95는 47초입니다. 이는 꼬리 지연에서도 사람에 의한 루프 내 승인이 작업 실행에 추가하는 시간이 1분 미만이라는 것을 의미하며, 안전 보장에 대한 작은 비용입니다.

가장 일반적인 알림 기반 워크플로: 다단계 리팩토링 작업을 시작하고, 회의를 위해 자리를 비우고, 회의 중 알림 액션으로 2-3개의 파일 작업을 승인하고, 돌아오면 작업이 완료되어 있습니다.

알림 양: 활성 사용자의 중앙값은 하루 8건의 알림을 수신합니다. 파워 유저(P95)는 약 30건입니다. 설문조사에서 알림 피로는 관찰되지 않았습니다. 아마도 각 알림이 상태 업데이트가 아닌 실행 가능한 이벤트를 나타내기 때문일 것입니다.

음소거 패턴: 15%의 사용자가 특정 시간대에 비승인 알림을 일괄 처리하는 "집중 모드" 규칙을 설정합니다. 승인 알림은 집중 모드에 관계없이 항상 즉시 전달됩니다. 승인 정체가 전체 작업을 차단하기 때문입니다.

향후 계획

알림에 대한 몇 가지 개선을 진행하고 있습니다:

• 코드 미리보기가 포함된 리치 알림 — 알림에서 직접 diff 미리보기를 표시하는 승인 알림으로, 앱을 열지 않고도 정보에 기반한 승인/거부 결정을 내릴 수 있습니다.
• 알림 그룹화 — 빠르게 연속되는 작업 완료 알림(다중 세션 워크플로에서 일반적)을 하나의 요약 알림으로 묶습니다.
• 사용자 지정 알림 사운드 — 완료, 승인, 오류에 대해 서로 다른 오디오 신호를 설정하여 휴대폰을 보지 않고도 소리로 분류할 수 있습니다.

알림 구성 옵션은 알림 설정 가이드를 참조하세요. 이 시스템을 구동하는 Claude Code hook 레퍼런스는 Hook 통합을 참조하세요.