제품 리콜 알림 서비스 만들기: 공고 스크래핑부터 영향받는 배치 매칭까지

제품 리콜 데이터는 이미 공개되어 있는데, 왜 소비자와 판매자는 자신에게 해당하는 리콜을 여전히 놓칠까요? 공고는 "무슨 일이 일어났는가"에 답하지만, 알림 서비스는 "이 공고가 내가 가진 제품에 해당하는가, 지금 무엇을 해야 하는가"에 답해야 하기 때문입니다. 그 사이에는 제품 식별, 배치 매칭, 근거 등급 분류, 지속적인 개정 반영, 안정적인 전달이 놓여 있습니다.

r/newproducts의 리콜 알림 제품 소개 글은 사진으로 구매한 물품을 저장해 두고 관련 리콜이 나오면 사용자에게 알리는 방식을 제안합니다. 이 게시물은 가설 단계의 사용자 과제를 보여 줄 뿐이며, 인식 정확도, 즉시성, 지불 의향을 입증하지 않습니다. 정말 연구할 가치가 있는 것은 "내가 가진 물건"을 규제 기관이 발표한 리콜 범위와 어떻게 안정적으로 연결하느냐입니다.

어려운 것은 공고 스크래핑이 아니라 해당 여부 판정입니다

리콜 제목에는 보통 브랜드, 품목, 제품 시리즈가 들어가지만, 제품이 실제로 영향을 받는지 결정하는 조건은 모델명, 제조일, 배치, 일련번호, UPC, 포장 규격, 판매 지역, 판매 기간 속에 숨어 있을 수 있습니다. 제품명만으로 전체 텍스트 매칭을 하면 비슷하지만 영향받지 않는 물품까지 사용자에게 보내게 되고, 조건을 지나치게 엄격하게 잡으면 필드가 불완전한 레코드를 놓칠 수 있습니다.

CPSC의 리콜 API는 공개 리콜 정보를 기계가 읽을 수 있는 JSON 또는 XML 형식으로 제공하며, 제목, 설명, 제품명으로 조회할 수 있습니다. 안정적인 수집의 진입점은 되지만, API로 조회할 수 있다고 해서 모든 레코드에 통일된 제품 식별자가 있는 것은 아닙니다. 제품은 "필드 누락"과 "수동 확인 필요"를 정상적인 상태로 다룰 수 있어야 합니다.

첫 버전에서 사진으로 모든 것을 자동 판정하겠다고 약속해서는 안 됩니다. 더 현실적인 약속은 이렇습니다. 사용자가 제공할 수 있는 식별자를 저장하고, 새 공고가 나오거나 기존 공고가 개정되면 매칭을 실행하고, 신뢰도가 높은 일치 건은 즉시 알리고, 의심 일치 건은 사용자에게 모델명이나 배치를 확인하도록 요청하고, 판정할 수 없을 때는 무엇이 부족한지 분명히 밝히는 것입니다.

서로 다른 규제 소스를 하나의 범용 필드 테이블로 뭉개지 마세요

소비재, 식품, 의약품, 자동차, 그리고 국가나 지역별 리콜 레코드는 서로 다른 소스와 법적 맥락에서 나옵니다. openFDA의 식품 API 엔드포인트는 집행(enforcement) 같은 데이터셋을 따로 구분하고, 식품 집행 보고서 조회 예시는 날짜 범위와 분류별 필터링을 보여 줍니다. 이들은 식품 집행 보고서 검색을 지원하지만, 모든 제품 리콜을 아우르는 통합 실시간 API로 재구성해서는 안 됩니다.

내부 데이터 계층은 공통 틀을 쓰되 원래 소스의 형태를 보존할 수 있습니다. 공통 필드는 검색과 전달에, 소스 필드는 검증에 사용합니다:

• 통합 식별자, 소스 기관, 소스 레코드 ID, 공고 날짜, 마지막 확인 시각.
• 제품명, 브랜드, 모델명, 코드, 배치, 판매 지역, 판매 기간. 값이 없으면 비워 둡니다.
• 위험 설명, 조치 방법, 소비자 문의 채널, 원본 공고 링크.
• 현재 상태, 이전 버전, 필드 변경 내역, 수집 실패 상태.
• 표준화 과정에서 핵심 한정 조건이 지워지지 않도록 보관하는 원본 레코드 또는 추적 가능한 스냅샷.

공통 틀이 있다고 해서 서로 다른 소스가 같은 정밀도를 갖도록 강제하지는 않습니다. 자연어 설명만 있는 레코드는 자연어로 표시된 채로 두어야 하며, 데이터베이스를 깔끔하게 유지하려고 존재하지 않는 SKU를 추론해서는 안 됩니다.

매칭 결과는 확정, 의심, 근거 없음으로 분류해야 합니다

리콜 알림 시스템에는 설명 가능한 단계별 매칭 기준이 필요합니다. 가장 강력한 근거는 보통 정확한 식별자 조합입니다. 예를 들어 UPC와 배치가 동시에 일치하거나, 모델명과 일련번호 범위가 동시에 일치하는 경우입니다. 그다음은 모델명과 판매 기간은 일치하지만 배치 정보가 없는 경우일 수 있습니다. 브랜드가 비슷하고 이름이 모호하게 일치하는 정도라면 "제품이 리콜되었습니다"가 아니라 확인 대기 단서로만 다뤄야 합니다.

매칭 결과는 세 가지 범주로 설계할 수 있습니다:

1. 확정 일치: 레코드의 핵심 식별자가 사용자 등록 정보와 일치하며, 검증용 원본 공고도 함께 첨부합니다.
2. 의심 일치: 일부 조건은 일치하지만 배치, 날짜, 지역 정보가 없습니다. 알림에서 누락된 식별자를 어디서 찾을 수 있는지 바로 알려 줍니다.
3. 판정 불가: 소스에 구조화된 필드가 충분하지 않거나 사진 인식 결과가 불안정합니다. 결론을 내리지 않고 계속 관찰합니다.

"일치 없음"이 "안전"을 뜻하지는 않습니다. 다루는 소스, 현재 데이터, 보유한 식별자 범위 안에서 일치하는 근거를 찾지 못했다는 뜻일 뿐입니다. 보수적으로 보이는 표현이지만, 사용자가 추가 확인을 잘못 멈출지 여부를 직접 좌우합니다.

이미지 인식은 최종 판정이 아니라 사용자가 라벨을 옮겨 적도록 돕는 데 적합합니다. OCR로 모델명과 바코드 후보를 제시한 뒤 사용자가 확인하게 할 수 있습니다. 저화질 사진, 포장 변경, 비슷한 글자는 모두 오류를 일으킬 수 있습니다. 제품은 매번 이전 사진으로 다시 추측하지 말고 사용자가 확인한 필드를 저장해야 합니다.

리콜 레코드는 개정되므로 알림에도 버전이 있어야 합니다

CPSC 리콜 페이지는 조치 정보가 바뀔 수 있다고 명시합니다. 조치 방법, 업체 연락 상태, 적용 범위가 업데이트된 뒤에도 이전 알림이 유일한 답으로 남아 있어서는 안 됩니다. 따라서 수집 계층은 같은 공고를 매일 새 리콜로 취급하지 말고, 최초 발견, 내용 개정, 일시적인 소스 접근 불가를 구분해야 합니다.

리콜 레코드에 적합한 이벤트 키는 일반적으로 소스 기관과 소스 레코드 ID로 구성됩니다. 확인할 때마다 내용 요약과 중요 필드의 차이를 저장합니다. 범위가 확대되면 관련 제품 전체를 다시 매칭해야 하고, 레이아웃만 수정된 경우에는 사용자를 방해할 필요가 없으며, 조치 방법이 바뀌면 이전에 알림을 받은 사람들에게 정정 알림을 보내야 합니다. 알림 자체에도 어느 버전을 기준으로 생성되었는지 기록해야 합니다.

소스 페이지에 일시적으로 장애가 생기면 화면에 "새 리콜 없음"이 아니라 "이번 확인을 완료하지 못함"을 표시해야 합니다. 사이트의 API 오류 및 자가 복구 가이드는 타임아웃, 요청 속도 제한, 권한, 데이터 소스 오류를 왜 따로 처리해야 하는지 설명합니다. 리콜 시나리오에 적용하면 특히 커버리지 중단을 안전한 상태로 위장해서는 안 됩니다.

사용자는 요약만이 아니라 다음에 할 일을 원합니다

효과적인 알림은 가장 중요한 행동을 맨 앞에 둡니다. 사용 중지, 배치 확인, 판매자 문의, 환불 요청, 수리, 추가 정보 대기 등입니다. 행동 지침은 현재 공식 공고에서 가져와야 하며, 모델이 임의로 조치 방법을 덧붙이게 해서는 안 됩니다. 위험도가 높은 경우에는 요약 바로 뒤에 원본 출처와 공식 문의 창구를 배치해야 합니다.

알림 발송 주기도 심각도와 매칭 신뢰도에 따라 달라야 합니다. 확정 일치인 고위험 레코드는 즉시 보낼 수 있고, 신뢰도가 낮은 의심 일치는 확인 대기열에 넣었다가 사용자가 식별자를 보완한 뒤 업데이트하는 편이 낫습니다. 일일 요약은 일반적인 관찰에 적합하지만, 메시지 수를 줄이려고 명백히 관련된 안전 알림을 늦춰서는 안 됩니다.

판매자용 제품에는 내부 작업도 필요합니다. 관련 상품 판매 중지, 재고 위치 파악, 주문 조회, 영향받는 고객 연락, 처리 결과 기록 등입니다. 수집은 작업을 촉발할 뿐이며, 주문, 창고, 고객 신원에 대한 판매자의 권한 관리를 대신할 수 없습니다. 결과를 워크플로에 통합할 때는 사이트의 통합 데이터 API 설계 가이드를 참고해 원본 근거, 표준화된 필드, 비즈니스 액션을 계층화할 수 있습니다.

물품 목록 자체가 민감한 자산입니다

가정이 보유한 물품은 건강 상태, 영유아 유무, 거주지, 소비 습관을 드러낼 수 있고, 판매자의 재고와 주문은 운영 데이터에 해당합니다. 리콜 알림 제품이 단지 "안전을 위해"라는 이유로 사진, 영수증, 전체 주문 내역을 기본적으로 무기한 저장해서는 안 됩니다.

첫 버전에서는 사용자가 매칭에 필요한 최소한의 필드만 저장하고 언제든 삭제할 수 있게 하면 됩니다. 이메일, 주문, 리테일 계정에서 자동으로 가져오려면 별도의 명시적 동의를 받고, 접근 범위를 보여 주고, 동기화를 중단한 뒤 어떤 데이터가 남는지 분명히 해야 합니다. 인식이 끝난 사진을 계속 저장할지도 명확한 제품 규칙으로 정해야 합니다.

판매자의 경우 리콜 소스 데이터, 내부 SKU 매핑, 고객 연락처 정보를 계층별로 나누고 권한을 부여해야 합니다. 리콜 확인 담당자가 전체 고객 프로필을 볼 필요는 없으며, 알림 담당자가 소스 근거를 수정할 수 있어서도 안 됩니다. 감사 기록에는 최소한 누가 매칭을 확인했는지, 어떤 공고 버전을 사용했는지, 어떤 대상에게 어떤 액션이 실행되었는지가 남아야 합니다.

MVP는 공고 수를 쌓기보다 매칭 루프를 검증해야 합니다

통제 가능한 파일럿은 규제 소스 하나, 제품 카테고리 하나, 사용자가 자발적으로 등록한 소량의 물품만 다뤄도 됩니다. 먼저 모든 후보를 수동으로 검토한 뒤 어떤 필드 때문에 시스템이 실패하는지 관찰해야 합니다. 이 단계에서는 몇 년 치 과거 공고를 색인했는지보다 관련 알림 하나를 정확하게 설명할 수 있는지가 훨씬 중요합니다.

권장하는 지표는 네 가지 범주입니다. 매칭 가능한 레코드의 비율, 의심 일치에 필요한 필드, 확정 일치 알림의 전달 및 조회, 알림부터 조치 완료까지의 상태입니다. 오탐과 미탐은 따로 검토해야 하며, 소스 필드 누락, 제품 등록 오류, 매칭 규칙 오류도 구분해야 합니다. 그래야 이후 자동화에서 데이터, 상호작용, 규칙 중 무엇을 고쳐야 할지 알 수 있습니다.

이 글은 데이터 제품 설계 방법론을 다루며, EveryInfra가 리콜 알림 서비스를 출시했다는 뜻이 아닙니다. 진정한 제품 리콜 알림 서비스는 공고를 더 많이 스크래핑하는 것이 아니라 "공식 레코드—특정 물품—명확한 행동—후속 정정"으로 이어지는 검증 가능한 연결 고리를 만드는 것입니다. 시스템이 불확실성을 분명히 드러낼 때 비로소 알림을 오래 신뢰할 수 있습니다.