알림비서 NotiFilter — 알림을 지우는 앱이 아니라, 안전하게 맡기는 시스템

스마트폰 알림은 하루 종일 작은 결정을 요구합니다 — 지금 볼지, 나중에 볼지, 지워도 될지, 답장해야 할지. NotiFilter는 그 알림 노동을 줄이되, “알림을 없앴다”·“읽었다”·“답장했다”를 절대 같은 뜻으로 뭉개지 않는 local-first 개인 알림 비서입니다. Android는 알림의 원천, Windows PC는 분석·검토·감사, AI는 조언자 — 되돌리기 어려운 액션은 사람이 정한 확정 규칙과 승인을 통과해야만 실행됩니다. 이 글은 SL.AIMS 업무포탈의 알림비서로도 연결되는 이 프로젝트의 배경과 설계 철학을 정리한 기록입니다. 회사의 다른 개인 업무 시스템과 같은 계열입니다.

대표 이미지: 알림을 자동으로 없애는 장면이 아니라, Android와 Windows 사이에서 안전하게 검토되는 알림 흐름을 표현했습니다.

NotiFilter는 처음부터 단순한 알림 청소기로 기획된 프로젝트가 아니었습니다. 내가 풀고 싶었던 문제는 “알림이 너무 많다”보다 조금 더 까다로웠습니다. 중요한 업무 메시지·금융 알림·일정·배송·답장해야 하는 메신저 알림은 놓치면 안 되지만, 그렇다고 아무 자동화나 붙이면 원본 앱의 상태가 망가질 수 있습니다.

이 프로젝트의 핵심 질문

알림 노동은 줄이되, 내가 실제로 읽었는지 · 알림만 없앴는지 · 답장을 보냈는지 같은 의미는 절대 섞지 않을 수 있을까?

그래서 NotiFilter의 목표는 “AI가 알아서 다 처리하는 앱”이 아니라, 사용자가 안심할 수 있는 범위 안에서 알림을 분류하고, 요약하고, 검토하고, 필요한 액션을 준비해 주는 local-first 개인 알림 비서가 되었습니다.

프로젝트를 시작한 배경

스마트폰 알림은 편리하지만, 실제 생활에서는 계속해서 작은 결정을 요구합니다. 이건 지금 봐야 하는 알림인지, 나중에 봐도 되는지, 아예 지워도 되는지, 혹시 답장해야 하는 메시지인지 매번 판단해야 합니다. 문제는 그 판단 비용이 하루 종일 누적된다는 점입니다.

특히 업무용 메신저와 금융·일정·배송·인증 코드가 섞이면 “불필요한 알림”과 “놓치면 안 되는 알림”이 같은 공간에 쌓입니다. 기존 알림 정리 방식은 대체로 빠르게 지우는 데 초점이 맞춰져 있지만, 내가 원한 것은 지우기 전에 의미를 보존하는 시스템이었습니다.

그래서 NotiFilter는 Android 알림을 수집하되, 무리하게 원본 앱 내부 데이터베이스를 긁지 않고, 좌표 기반 화면 자동화나 AccessibilityService 기반 자동화를 MVP 핵심 경로로 삼지 않는 방향을 택했습니다. 안전하고 검증 가능한 알림 표면에서 출발하자는 결정이었습니다.

최종 목표: 안전한 알림 관제실

NotiFilter의 최종 모습은 “내 알림을 대신 판단하는 비서”보다는 **“내가 알림을 놓치지 않도록 도와주는 관제실”**에 가깝습니다. Android는 실제 알림 생명주기와 실행 가능한 알림 액션의 원천이 되고, Windows PC는 분석·검토·규칙·감사·장기 보관을 담당합니다.

AI는 여기서 조언자입니다. 요약·우선순위 후보·답장 초안·마감일 추출을 도와줄 수는 있지만, 중요한 액션을 최종 승인하는 주체는 deterministic policy gate입니다. 쉽게 말하면 “사람이 정한 확정 규칙”을 통과해야 한다는 뜻입니다. 이 원칙은 회사의 모든 업무를 승인 흐름과 연동하고, 에이전트가 할 수 있는 일과 없는 일을 먼저 긋는 설계 기조와 같습니다.

알림을 없앴다는 사실이, 그 메시지를 읽었다는 뜻이 되어서는 안 된다.

이 문장이 NotiFilter의 제품 철학을 가장 잘 요약합니다. 알림 제거, 원본 앱 읽음 처리, NotiFilter 안에서 본 상태, 답장 상태는 서로 독립된 의미입니다.

절대 섞으면 안 되는 네 가지 상태

이 독립성을 지키기 위해, NotiFilter는 하나로 뭉뚱그리기 쉬운 “봤다/처리했다”를 네 개의 상태로 쪼개서 따로 추적합니다.

상태	무엇을 기록하나	화면의 표기(예시)
notification_state	Android 시스템 알림이 지금 존재하는지, 사라졌는지, 알 수 없는지	알림창에 있음
app_read_state	원본 앱이 공식적으로 읽음 처리를 받아들였는지 (알림 제거와 다름)	앱 읽음: 확인 불가
user_view_state	사용자가 NotiFilter 안에서 목록을 봤는지, 상세를 열었는지, 미뤘는지	아직 안 봄
reply_state	답장 초안이 생성됐는지, 사용자가 승인했는지, 실제 전송 결과가 확인됐는지	답장 없음

네 상태는 이름만 다른 게 아니라 바뀌는 시점과 주체가 전부 다릅니다. 알림창에서 알림이 사라져도(notification_state) 그 앱에서 읽음 처리가 됐다는 보장은 없고(app_read_state), 내가 목록에서 스쳐 봤다고 해서(user_view_state) 답장을 보낸 것도 아닙니다(reply_state). 이 넷을 한 칸으로 합치는 순간 “다 처리한 줄 알았는데 실은 놓친” 사고가 생깁니다.

실제 화면: SL.AIMS 업무포탈의 알림비서

NotiFilter는 별도의 데모 화면만 있는 프로젝트가 아니라, SL.AIMS 업무포탈 안의 알림비서 업무 메뉴로도 연결됩니다. 받은편지함을 실행 가능한 일로 바꾸는 메일 관리 시스템과 나란히, 알림을 안전하게 맡아 두는 자리입니다.

이 글의 화면 데이터에 관하여

아래 화면의 개인 이름·알림 본문·발신자·계정·기기 식별 정보는 블로그 공개를 위해 모두 마스킹했습니다. 실제 알림 내용·계정과 무관합니다.

실제 알림비서 화면. 우측 "상태를 분리해서 추적" 패널이 위 네 가지 상태(알림창에 있음 · 앱 읽음: 확인 불가 · 아직 안 봄 · 답장 없음)를 그대로 보여줍니다. AI 판단은 85% 신뢰로 "답장 후보"를 제안하지만, 실제 실행은 하단의 사람 승인 버튼과 Android 결과를 거쳐야 확정됩니다.

화면 우측 아래 “바로 처리” 영역이 policy gate의 실체입니다. 읽음 처리는 원본 앱이 제공하는 공식 읽음 액션을 실행하고, 완료되면 목록에서 빠집니다. 알림 없애기는 휴대폰 알림창의 알림만 제거하도록 Android에 요청합니다 — 읽음과는 다른 동작입니다. 두 버튼이 따로 있는 이유가 바로 네 상태를 섞지 않기 위해서입니다.

어떻게 만들어졌나

구조는 Android와 Windows PC의 역할을 분리하는 데서 시작했습니다. Android 앱은 알림 접근 권한, NotificationListenerService, 로컬 저장소, 오프라인 outbox, 안전한 명령 실행을 담당합니다. Windows 쪽은 Tauri와 React로 만든 command center, Python FastAPI sidecar, SQLite 기반 저장소를 씁니다.

계약(contract)은 JSON Schema를 중심에 두었습니다. Android·Python·TypeScript가 같은 의미를 바라보게 하기 위한 선택입니다. 스키마와 valid/invalid 예시를 먼저 정의해 두면, 플랫폼이 늘어나도 payload의 의미가 흔들리지 않습니다.

그림 1 — 알림 원천(Android) → PC sidecar(Core API) → 검토 지휘소(Desktop)의 3층 구조. 세 층은 하나의 JSON Schema 계약 위에서 같은 의미를 공유합니다.

구성요소	역할
Android — 알림 원천	알림 이벤트 수집, 로컬 저장, WorkManager outbox, 액션 실행 직전 active notification 재조회
Core API — PC sidecar	FastAPI, SQLite WAL, command lifecycle, audit log, AI provider adapter
Desktop — 검토 지휘소	React/Tauri UI로 알림 검토, 규칙 편집, 연결 상태 확인
Contracts — 의미 고정	JSON Schema와 valid/invalid 예시로 세 층의 payload 의미를 일치

안전을 위해 지키는 원칙

알림 자동화의 실패는 대부분 “너무 많이 해주려다” 생깁니다. NotiFilter는 기능을 늘리기 전에, 하지 않을 일을 먼저 정했습니다. 이 경계가 있어야 사용자가 시스템을 안심하고 켜둘 수 있기 때문입니다.

NotiFilter가 하는 일	NotiFilter가 하지 않는 일
알림을 수집해 분류하고, 요약·우선순위 후보를 제안	사용자 승인 없이 알림을 지우거나 답장을 전송
답장 초안과 마감일 추출을 준비해 사용자 검토에 올림	원본 앱 내부 데이터베이스를 직접 접근
모든 액션을 audit log로 남겨 나중에 확인 가능	좌표 기반 화면 자동화나 접근성 서비스 남용
이름·계정·기기 식별 정보 같은 민감정보를 마스킹	알림 원문을 외부 서버로 무단 전송

민감정보를 로컬에서 다루고 함부로 밖으로 보내지 않는다는 원칙은, 명함관리 CardSync에서 “타인의 개인정보를 외부 서버로 보내지 않는다”는 결정과 같은 뿌리입니다.

AI가 아무리 좋은 제안을 해도, 알림 제거나 답장 전송처럼 되돌리기 어려운 액션은 반드시 사람이 정한 확정 규칙과 사용자 승인을 통과해야 합니다. AI는 조언자이고, 최종 결정권은 항상 사용자에게 있습니다.

맺으며

NotiFilter가 증명하고 싶은 것은 “AI가 알림을 다 처리해 준다”가 아닙니다. 알림 노동은 줄이면서도, 읽음·삭제·검토·답장이라는 서로 다른 의미를 끝까지 지켜주는 시스템이 가능하다는 것입니다.

좋은 알림 비서의 기준은 기능 목록이 아니라, 안심하고 켜둘 수 있는가이다.

이 기준을 지키는 알림 비서라면, 사용자는 알림을 확인하는 시간이 아니라 알림이 가리키는 진짜 일에 시간을 쓸 수 있게 됩니다. NotiFilter가 향하는 방향입니다.