재수집 중복 방지 설계

수집 도구의 사용자는 반드시 같은 대상을 다시 수집합니다. 새 댓글이 달렸는지 보려고, 수집이 중간에 끊겨서, 그냥 불안해서. 이때 이전 데이터 위에 같은 데이터가 또 쌓이면 도구는 순식간에 신뢰를 잃습니다. 주문 두 개가 네 개가 되는 도구를 누가 쓰겠습니까. 카페 댓글 주문 도구를 만들며 정리한 재수집 중복 방지의 설계 원칙입니다.

중복 방지의 시작: 무엇이 "같은 건"인가

중복을 막으려면 먼저 동일성의 정의가 필요합니다. 어떤 두 레코드가 같은 건인가. 이 정의가 곧 자연 키(natural key)의 선정입니다.

댓글 주문에서 우리가 고른 키는 판매 글, 작성자 닉네임, 댓글 원문의 조합이었습니다. 같은 글에 같은 사람이 같은 내용을 단 댓글은 같은 주문이라는 정의입니다. 수집 시각이나 순번은 키에서 뺐습니다. 재수집 때마다 달라지는 값을 키에 넣으면 모든 재수집이 신규가 되기 때문입니다.

자연 키 선정에서 따질 것은 두 가지입니다. 재수집에도 변하지 않는가(안정성), 실제로 다른 건을 같다고 묶지 않는가(변별력). 같은 사람이 같은 글에 정말로 같은 내용을 두 번 다는 경우(추가 주문)는 변별력의 경계 사례인데, 우리 도메인에서는 그런 재댓글도 보통 표현이 조금이라도 달라 실용적으로 충분했습니다. 완벽한 키가 없는 도메인에서는 어느 쪽 오류가 덜 아픈지(중복 등록 vs 누락)를 정하고 그쪽으로 기웁니다.

검사 위치: 수집기가 아니라 저장 단계에서

중복 검사를 어디서 하느냐도 설계입니다. 수집기가 "이미 가져온 것"을 기억하게 하는 방식은 매력적으로 보이지만 취약합니다. 수집기의 기억(마지막 수집 시점, 본 것 목록)은 재설치나 초기화로 사라지고 여러 수집 경로가 생기면 기억이 갈라집니다.

우리는 수집기를 무상태로 두고 저장 단계에서 자연 키로 존재 여부를 확인한 뒤 없을 때만 넣는 구조를 택했습니다. 수집기는 언제나 전체를 읽고 저장소가 신규만 받아들입니다. 이 분담의 장점은 견고함입니다. 수집이 어디서 끊겼는지, 몇 번 재시도했는지와 무관하게 결과가 같습니다. 같은 원리를 서버 간 통신에 적용한 것이 멱등키인데, 그 일반론은 중복 없는 멱등성 설계에서 다룹니다.

입금 내역 쪽도 같은 구조를 썼습니다. 은행 파일은 기간이 겹치게 내려받기 쉬워 중복 유입이 잦은데, 거래일시·금액·입금자명 조합을 키로 저장 단계에서 걸렀습니다. 파일을 몇 번을 겹쳐 올려도 입금 건은 한 번만 등록됩니다.

재수집과 수정의 공존

중복 방지에는 미묘한 짝꿍 문제가 있습니다. 사용자가 수집된 데이터를 수정한 경우입니다. 운영자가 잘못 해석된 주문의 옵션을 고쳐 놨는데, 재수집이 그 행을 원본으로 되돌리면 수정이 증발합니다.

그래서 규칙을 정했습니다. 재수집은 신규만 추가하고 기존 레코드는 건드리지 않는다. 자연 키로 이미 존재하는 건은 갱신이 아니라 스킵입니다. 원본 댓글이 수정되는 경우를 놓치는 대가가 있지만 사람의 수정을 지키는 쪽이 이 도구의 사용 맥락에서는 옳았습니다. 갱신이 필요한 도메인이라면 "원본 필드는 갱신, 사람 입력 필드는 보존"의 필드 단위 정책으로 정교화할 수 있습니다.

중복 방지가 열어 주는 운영 습관

이 구조의 진짜 효용은 사용자의 심리에 있습니다. "다시 눌러도 안전하다"는 확신이 생기면 재수집이 자연스러운 운영 습관이 됩니다. 새 댓글 확인도, 끊긴 수집의 재개도 그냥 버튼을 다시 누르면 됩니다. 도구가 사용자에게 조심을 요구하지 않게 되는 것, 그것이 중복 방지 설계의 목표입니다.

이 설계가 들어간 도구의 전체 이야기는 카페 댓글 주문 정리 자동화 사례에서, 대량 수집 파이프라인에서의 같은 문제(유니크 키 업서트와 의미 중복 제거)는 LLM 의미 중복 제거 설계에서 볼 수 있습니다.

자주 묻는 질문

재수집 중복 방지의 핵심은 무엇인가요?

동일성의 정의, 즉 자연 키의 선정입니다. 재수집에도 변하지 않고(안정성) 다른 건을 같다고 묶지 않는(변별력) 필드 조합을 키로 정하고 저장 단계에서 그 키의 존재 여부로 신규만 받아들이면 몇 번을 다시 수집해도 데이터는 한 번만 쌓입니다.

수집기가 마지막 수집 시점을 기억하면 되지 않나요?

취약한 방식입니다. 수집기의 기억은 재설치·초기화로 사라지고 시점 기준은 수정·지연 게시 같은 경계 사례를 놓칩니다. 수집기는 무상태로 전체를 읽고 저장소가 중복을 거르는 구조가 어떤 상황에서도 같은 결과를 보장합니다.

사용자가 고친 데이터를 재수집이 덮어쓰지 않나요?

정책으로 막아야 합니다. 우리는 "기존 건은 갱신이 아니라 스킵"으로 정해 사람의 수정을 보존했습니다. 원본 갱신도 반영해야 하는 도메인이라면 원본 필드만 갱신하고 사람 입력 필드는 보존하는 필드 단위 정책이 대안입니다.

정말로 같은 내용의 주문이 두 번 들어오면 어떻게 하나요?

자연 키의 변별력 경계 사례라 도메인 판단이 필요합니다. 중복 등록과 누락 중 어느 오류가 덜 아픈지 정하고 그쪽으로 설계를 기울이되, 애매한 건은 사람이 확인할 수 있게 원문을 함께 보관하는 것이 안전합니다.