받은 편지함이 너무 많이 알고 있다: 프라이버시 중시자를 위한 파슬리

Source: Dev.to

이 글은 Gemma 4 챌린지: Build with Gemma 4에 대한 제출물입니다.
몇 주마다 또 다른 고객 데이터 유출 사건이나 SaaS 플랫폼 침해 이야기가 나오곤 합니다. 동시에 사람들은 “내 소포는 어디에 있나요?”라는 한 가지 질문에 답하기 위해 무작위 AI 제품에 Gmail 계정을 기꺼이 연결합니다.
Parsli는 로컬에서 작동하는 AI 비서로, 여러분의 인박스를 타인의 클라우드로 보내지 않고도 그 질문에 답합니다.
Gmail에 로컬로 연결해 배송 관련 이메일을 파싱하고, 추적 정보를 추출하며, 배송 이벤트를 분류하고, 마켓플레이스·운송업체·픽업 포인트·통관 알림·2009년식 이메일을 아직도 보내는 잡다한 상점들의 혼란스러운 데이터를 타임라인으로 정리합니다.

배송 이메일은 자세히 들여다보면 놀라울 정도로 사적인 데이터 집합입니다. 여러분이 어디서 쇼핑하는지, 어떤 약국을 이용하는지, 어떤 고가의 물건을 사는지, 언제 여행을 가는지, 때로는 집에 없을 때까지도 조용히 드러냅니다. 저는 “우리는 개인정보를 소중히 여깁니다”라는 페이지만 있는 또 다른 스타트업에 이 개인 행동 흐름을 넘겨주고 싶지 않았습니다.
Parsli는 아직 초기 프로토타입이지만, 저는 실제로 계속 작업할 계획입니다. 저는 여러 국가의 다양한 마켓플레이스를 통해 주문을 하고, 운송 추적은 운송업체·언어·알림 형식이 뒤섞여 금세 혼란스러워집니다. 처음엔 로컬 AI 워크플로우 실험으로 시작했지만, 점차 제가 직접 사용하고 싶어지는 무언가가 되었습니다. 다음 단계로는 SMS, 스크린샷, 음성 메시지를 입력 소스로 추가하려 합니다—배송 업데이트는 이메일뿐 아니라 여러 채널에 흩어져 있기 때문입니다.
또한 시스템을 또 다른 “블랙 박스” AI 에이전트가 아니라 관찰 가능한 형태로 만들고 싶었습니다. 배송 이벤트를 저장하는 것 외에도 Parsli는 규칙 매치, 모델 결정, 신뢰도 수준, 추출된 엔터티, 처리 시간, 토큰 사용량, 분류 논리 등을 지속합니다. 이메일 파싱은 행복한 경로 데모를 벗어나면 곧바로 엣지 케이스 지옥이 되므로, 전체 의사결정 과정을 남겨두면 디버깅이 크게 쉬워집니다.

https://github.com/olgazju/parsli

Parsli는 결정론적 추출 파이프라인 위에 추론 레이어로 Gemma 4를 사용합니다.

많은 배송 이메일은 LLM이 전혀 필요하지 않습니다. Amazon, UPS, 이스라엘 우편, 그리고 절반 이상의 인터넷 서비스가 같은 템플릿을 반복해서 보내기 때문에 HTML 정리, 추적 번호 추출, 인보이스 필터링, 명백한 배송 업데이트와 같은 작업은 결정론적 규칙과 언어 팩으로 처리됩니다. 모든 이메일에 모델 호출을 남발하면 속도가 느려지고 의미가 없습니다.
하지만 이메일이 표준 템플릿에서 벗어나기 시작하면—다국어 통관 통지, 본문에 숨겨진 추적 번호가 있는 픽업 포인트 알림, 모든 것을 다르게 포맷하는 마켓플레이스—결정론적 규칙만으로는 부족합니다. 바로 그때 Gemma가 배송 분류기이자 규칙 위에 얹힌 감사 레이어 역할을 합니다.
파이프라인은 먼저 구조화된 후보를 결정론적으로 추출하고, 모호한 경우에만 모델에 검증, 신뢰도 추정, 배송 상태 분류, “이게 실제로 의미가 맞는가”를 확인하도록 보냅니다. 결과가 저장되기 전에 말이죠.
저는 전체 의사결정 과정을 저장합니다: 어떤 규칙이 작동했는지, 모델 출력, 신뢰도 점수, 토큰 사용량, 처리 시간, 최종 답변이 규칙에서 나왔는지 모델에서 나왔는지. 실제 메일함에서 48개의 관련 이메일 중 55%는 규칙만으로 해결됐고 모델은 저렴한 감사 역할만 했으며, 38%는 모델이 규칙이 틀린 부분을 바로잡았고 나머지는 엣지 케이스로 나뉘었습니다. 규칙만으로는 약 60% 정도만 해결할 수 있었고, 모델만으로는 모든 것을 처리할 수 있지만 속도가 느리고 비효율적입니다. 두 가지를 결합하면 서로의 사각지대를 메울 수 있습니다.
로컬 추론을 위해 저는 M2 MacBook Pro에서 LM Studio를 헤드리스 모드로 실행해 google/gemma-4-e4b 모델을 사용했습니다. 이 모델 크기는 해당 작업량에 충분히 넘었습니다. HTML 잡동사니와 이메일 혼란을 없애면 배송 추적은 좁은 구조화 문제—무한히 시를 쓰는 것이 아니라 유한한 상태 집합에 분류하는 일—가 됩니다. E4B는 제가 필요로 하는 추론 품질을 제공하면서도 전용 GPU 서버 없이 로컬에서 충분히 빠르게 실행될 수 있었고, 이것이 바로 목표였습니다.