경매 데이터는 숫자가 많습니다. 감정가, 최저가, 면적, 입찰일, 유찰 횟수처럼 비교하기 좋은 항목이 많아 보여도 실제 구현에서는 ‘값이 없음’을 어떻게 처리하느냐가 더 중요했습니다. 누락된 가격을 0으로 바꾸거나 API 장애를 검색 결과 0건으로 바꾸면 서비스는 멀쩡해 보이지만 사용자는 전혀 다른 결론을 내릴 수 있습니다.
API 오류와 ‘검색 결과 없음’은 완전히 다른 사건입니다
공식 API가 정상 응답으로 0건을 돌려준 경우와, 네트워크 오류·형식 오류·접근 제한 때문에 데이터를 못 받은 경우를 같은 빈 배열로 처리하지 않습니다. 전자는 실제로 조건에 맞는 물건이 없다는 정보지만 후자는 우리가 현재 확인하지 못했다는 뜻입니다.
집찰에서는 malformed 응답이나 HTTP 오류를 성공한 빈 결과로 바꾸지 않고 오류 상태를 유지합니다. 기존에 확인한 물건도 새로운 전체 범위 확인이 끝나기 전에는 단순히 응답에 없었다는 이유만으로 사라진 물건으로 처리하지 않습니다.
가격이 없으면 0원이 아니라 ‘미공개 또는 미확인’입니다
공매에는 공개되지 않은 금액이나 아직 다음 회차 가격이 정해지지 않은 경우가 있습니다. 이 값을 숫자 0으로 저장하면 정렬, 감정가 대비 비율, 최저가 필터에서 모두 왜곡이 생깁니다. 그래서 실제 0이라는 근거가 있을 때만 0을 유지하고, 누락값은 null 상태로 남깁니다.
물건을 합치는 기준도 생각보다 까다로웠습니다
법원 경매는 같은 사건번호가 다른 법원에 존재할 수 있고, 온비드는 관리번호와 공고 조건에 따라 실제 물건 단위가 달라집니다. 단순한 번호 하나만 키로 쓰면 서로 다른 물건이 합쳐질 수 있습니다. 그래서 법원과 사건번호를 함께 보거나, 온비드의 관리번호와 공고 조건을 포함해 실제 물건의 정체성을 잡습니다.
‘위험 신호’는 법률 판단이 아니라 원문을 다시 보게 하는 장치입니다
집찰에 표시하는 위험 신호는 권리분석을 대신하지 않습니다. 면적·구조·지분 여부 등 공식 원문에서 확인 가능한 사실을 바탕으로 “이 부분은 원문을 더 확인해야 한다”는 방향을 주는 데 그칩니다. 명도 가능성이나 법적 안전성을 자동으로 보증하는 문장은 넣지 않습니다.
9만 건이 넘는 목록보다 중요한 것은 갱신 방식이었습니다
2026년 9월 말 운영 점검 당시 집찰에서 확인 가능한 온비드 공매 물건은 9만 건을 넘었습니다. 이 규모에서는 모든 행을 계속 다시 쓰는 방식보다 변경된 내용과 관측 시각을 분리하는 것이 중요해졌습니다. 내용이 같다면 기존 레코드를 불필요하게 다시 쓰지 않고, 최신 확인 시각은 별도로 기록하는 쪽으로 구조를 바꿨습니다.
결국 집찰에서 가장 중요한 기능은 ‘많이 보여주는 검색’보다 데이터가 확실하지 않을 때 확실한 척하지 않는 것입니다. 경매는 마지막 확인을 반드시 공식 원문에서 해야 하는 영역이고, 서비스는 그 확인 지점까지 사용자를 데려가는 도구로 남는 편이 안전합니다.
운영자용 진단정보와 사용자용 상태도 분리했습니다
개발 과정에서는 수집 진행 페이지, API별 오류코드, 호출량 같은 정보가 꼭 필요합니다. 하지만 이런 값이 사용자 화면이나 공개 상태 API에 그대로 나오면 의미 없는 내부 용어가 서비스 설명을 덮어버립니다. 최근에는 공개 상태 응답에는 최신 확인 시각과 현재 확인 가능한 건수만 남기고, 상세 진단은 인증된 운영자 경로로 분리했습니다. 데이터 투명성과 내부 구현 노출은 같은 문제가 아니라는 판단입니다.