Poli

국회 데이터는 법안, 의원, 정당, 처리 상태처럼 구조화된 정보가 많지만 사용자가 매번 검색하고 원문을 읽어 변화 여부를 확인해야 하면 지속적으로 따라가기 어렵습니다. 반대로 AI 요약만 앞세우면 어떤 원문을 근거로 했는지, 왜 내 관심사와 연결됐는지 확인하기 어려워집니다.

그래서 폴리는 공식 데이터 수집 → 정규화 → 후보 검색 → 관련성 판정 → 근거와 함께 노출 순서를 분리했습니다. AI는 원문을 대체하는 최종 판단자가 아니라, 많은 항목에서 사용자의 구독과 관련된 후보를 좁히고 읽기 쉽게 정리하는 계층으로 두었습니다.

AI 실패가 정보 단절로 이어지지 않게

요약 생성과 관련성 판정은 외부 모델 호출에 의존하므로 실패 가능성을 운영 상태로 다룹니다. 원문 식별자와 공식 출처를 별도로 보존하고, AI 결과가 없더라도 사용자가 원문으로 이동할 수 있는 구조를 우선했습니다.

사용자는 관심사뿐 아니라 법안, 정당, 정치인을 직접 구독할 수 있습니다. 이 관계를 단순 즐겨찾기가 아니라 피드 정렬, 새 활동 알림, 다이제스트 생성의 공통 입력으로 사용했습니다.

최근에는 정부·공공기관의 정책·혜택 데이터도 별도 수집해 개인 피드에 함께 섞는 흐름을 추가했습니다. 이 경우에는 생활 조건이 필요한 만큼 별도의 정책 프로필과 동의를 두고, 동의된 정보만 매칭에 사용하도록 경계를 분리했습니다.

초기 데이터가 쌓일수록 관심사별 후보 검색, 관련성 판정, 요약 생성, 알림 전송이 동시에 늘어났습니다. 수집과 AI 작업을 NestJS Worker로 분리하고 Redis/BullMQ 이벤트와 주기 점검을 함께 사용해 실시간성보다 누락 없는 전달을 우선했습니다.

관심사마다 최근 스캔과 판정 상태를 확인할 수 있게 만들고, 실패한 작업은 사용자 화면의 오류 문구로 끝내지 않고 운영 상태에서 다시 추적할 수 있도록 했습니다. 다이제스트도 생성 결과를 보관해 일회성 알림이 아니라 다시 조회할 수 있는 아카이브로 확장했습니다.

Poli에서 가장 큰 구현 범위는 피드 UI가 아니라 외부 공공데이터를 계속 가져오고, 의미 검색과 AI 판정을 운영 가능한 상태로 만들고, 같은 구독 정보를 여러 전달 채널에 재사용하는 일이었습니다.

프론트엔드·API·DB·배치·AI·푸시 알림·개인정보 동의까지 서로 다른 경계를 한 제품 흐름 안에서 연결하면서, AI 기능도 결국 데이터 모델과 운영 상태가 받쳐줘야 제품이 된다는 점을 확인했습니다.