아침마다 조달 사이트에 들어가 신규 공고를 훑는 영업 담당자, 원자재 시세와 환율을 확인해 단가표를 갱신하는 구매 담당자, 자사 상품 리뷰와 커뮤니티 반응을 살피는 마케팅 담당자. 회사마다 '매일 어딘가에 들어가서 확인하는 일'이 하나쯤 있습니다. 이런 모니터링성 업무는 건별 판단은 사람이 해야 하지만, 확인하러 가는 일 자체는 시스템이 대신할 수 있습니다. 이 글은 모니터링 업무 자동화의 공통 구조와, 자동화 범위를 어디서 끊어야 하는지, 흔한 실패 두 가지를 어떻게 막는지 정리했습니다.
대상은 달라도 구조는 같다
- 수집. 공고 사이트, 시세 API, 리뷰 채널처럼 정해진 소스를 주기적으로 확인해 새 항목을 가져온다
- 정규화. 소스마다 다른 형식을 하나의 구조(제목·날짜·금액·본문·원문 링크)로 통일한다
- 필터·요약. 정해진 조건으로 후보를 거르고, 남은 것에만 요약을 붙인다
- 알림. 걸러진 결과를 담당자가 이미 쓰는 채널(메일, 메신저)로 보낸다
입찰 공고 선별이든 시세 확인이든 리뷰 모니터링이든 이 네 단계 구조는 동일합니다. 달라지는 것은 단계별 난이도입니다. 공고는 필터 조건 설계가, 시세는 소스 신뢰도가, 리뷰는 요약 품질이 관건이 됩니다. 구조가 같다는 것은, 하나를 제대로 만들면 다음 대상으로 확장하기 쉽다는 뜻이기도 합니다.
어디까지 자동화하고, 어디부터 사람이 판단하나
수집과 정규화는 전부 자동화하는 것이 맞습니다. 사이트를 순회하며 새 글이 올라왔는지 확인하는 일에는 판단이 들어 있지 않기 때문입니다. 필터는 절반입니다. '공고명에 특정 키워드 포함', '추정가 얼마 이상' 같은 명시적 조건은 규칙으로 처리하고, '우리가 수행할 수 있는 과업인가' 같은 판단성 분류는 LLM이 1차로 분류하되 판단 근거를 함께 보여주는 방식이 안전합니다. 그리고 이 공고에 입찰할지, 지금 원자재를 계약할지, 이 리뷰에 어떻게 대응할지 같은 최종 결정은 사람의 몫으로 남겨야 합니다.
시스템의 역할은 결정이 아니라 후보 축소라는 것이 설계 원칙입니다. 하루 300건을 10건으로 줄여주면 성공이고, 그 10건 중 무엇을 잡을지는 담당자가 정합니다. 이 선을 넘어 시스템이 결정까지 하게 만들면, 놓친 한 건의 책임을 두고 시스템 전체가 불신받게 됩니다.
흔한 실패 1 · 과알림
모니터링 자동화가 버려지는 가장 흔한 경로는 오작동이 아니라 과알림입니다. 놓치는 것이 무서워 필터를 느슨하게 잡으면 하루 수십 건의 알림이 오고, 2주쯤 지나면 담당자는 알림을 열어보지 않게 됩니다. 아무도 안 보는 알림을 보내는 모니터링 시스템은 없는 것과 같습니다.
방지책은 세 가지입니다. 첫째, 알림을 등급으로 나눕니다. 조건에 정확히 맞는 건만 즉시 알림으로 보내고, 나머지는 하루 한 번 다이제스트로 묶습니다. 둘째, 도입 첫 몇 주를 조정 기간으로 계획합니다. 담당자가 '이건 필요 없었다'고 표시한 기록을 필터 조건에 반영하는 루프를 처음부터 설계에 넣습니다. 셋째, 알림 건수 자체를 지표로 봅니다. 하루 알림이 담당자가 소화할 수 있는 수준을 넘으면 필터를 조여야 한다는 신호입니다.
흔한 실패 2 · 요약을 믿을 수 있는가
LLM 요약은 편리하지만, 마감일·자격 요건·금액처럼 틀리면 안 되는 값이 요약문 안에서 잘못 옮겨지면 피해가 큽니다. 요약만 읽고 입찰 준비를 시작했는데 원문의 마감일이 달랐다면, 그 시스템은 그날로 신뢰를 잃습니다.
방지책의 핵심은 요약과 추출을 분리하는 것입니다. 마감일, 금액, 자격 요건 같은 핵심 필드는 문장으로 요약하지 않고 원문에서 그대로 추출해 별도 항목으로 표시합니다. 요약문의 역할은 '무슨 내용인지 빠르게 파악하는 것'으로 한정하고, 모든 알림에 원문 링크를 붙여 결정 전에는 원문을 확인하는 동선을 만듭니다. 추출에 실패한 필드는 빈칸이나 추정값으로 채우지 않고 '확인 필요'로 표시합니다.
수집 단계에서 미리 확인할 것
- 공식 API나 RSS가 있는가. 화면을 긁어오는 방식보다 훨씬 안정적이다. 공공 조달처럼 공식 API가 제공되는 소스는 API를 쓴다
- 이용약관과 수집 정책. 소스별로 자동 수집의 허용 범위가 다르다. 약관·계약상 문제가 없는지 시작 전에 확인한다
- 소스 구조가 바뀌면 어떻게 되는가. 수집 실패를 조용히 넘기지 않고, '오늘 이 소스에서 0건' 같은 이상 신호를 담당자에게 알리는 감시 장치를 함께 만든다
요약 · 단계별 자동화 범위와 사람의 역할
| 단계 | 자동화 범위 | 사람의 역할 |
|---|---|---|
| 수집·정규화 | 전부 자동화 | 소스 추가·제외 결정 |
| 필터 | 명시적 조건은 규칙, 판단성 분류는 LLM + 근거 표시 | 분류 기준 조정, 오분류 피드백 |
| 요약 | 핵심 필드는 원문 추출, 본문은 요약 + 원문 링크 | 결정 전 원문 확인 |
| 알림 | 등급별 발송 (즉시 / 일일 다이제스트) | 최종 판단 (입찰·구매·대응) |
하루 30분씩 확인하는 업무라면 한 달이면 대략 열 시간입니다. 하지만 시간보다 중요한 것은 '담당자가 자리를 비우면 그날은 아무도 안 본다'는 구조적 공백입니다. 모니터링은 사람이 매일 꾸준히 하기 가장 어려운 종류의 일이고, 시스템이 가장 잘하는 종류의 일입니다. 지금 매일 확인하는 소스 목록과 '남길 것과 버릴 것'의 기준을 말로 적을 수 있다면, 자동화 가능성은 짧은 검증으로 판단할 수 있습니다. Plan AI는 2주 파일럿(PoC)으로 실제 소스를 수집해 필터 정확도부터 확인한 뒤에 본 구축을 제안합니다. 자동화하고 싶은 업무를 남겨주시면 1영업일 내 검토 회신드립니다.