아무도 팔지 않는 데이터 — 21만 개 회사를 매일 기록하기 시작한 이유

Об этом предложении

국세청은 사업자등록 상태를 알려주는 공개 API를 운영합니다. 10자리 번호를 넣으면 계속사업자인지, 휴업인지, 폐업인지 알려줍니다. 무료고, 빠르고, 정확합니다. 그런데 기억이 없습니다. 오늘 물어보면 이 회사가 폐업했다는 걸 알 수 있습니다. 지난달엔 어땠냐고 물으면 답이 없습니다. 그 질문이 API에 없으니까요. as_of 같은 파라미터도, 이력 엔드포인트도, 변경 기록도 없습니다. 쓸 수 있는 시제는 현재형 하나뿐입니다. AI 에이전트용 API를 만들면서 발견한 것 중 이게 가장 흥미로웠고, 그래서 당연한 일을 하기로 했습니다. 매일 보이는 걸 적어두기 시작한 겁니다. 무엇을 만들었나 하루에 한 번 도는 작업입니다. 정해진 목록에 있는 모든 회사의 현재 상태를 묻고, 답을 저장합니다. 그리고 오늘과 어제를 비교해서 바뀐 것만 따로 파일에 씁니다. 사흘째 숫자는 이렇습니다. 날짜 관측 기록된 변화 1일차 211,243 — (첫 실행이라 전부 신규) 2일차 211,243 70 3일차 211,243 94 하루치 스냅샷은 약 42MB, 변화 파일은 1.7MB입니다. 이 비율이 핵심입니다. 제가 기록하는 것의 99.2%는 "아무 일도 없었다"는 확인이고, 나머지 0.8%가 상품입니다. 실제로 저장된 변화 한 건은 이렇게 생겼습니다. json {"business_number":"...","field":"status","previous":"active","current":"closed", "previous_seen_at":"2026-09-29T00:05:14Z","detected_at":"2026-09-30T00:05:14Z"} 29일에 봤을 땐 영업 중이던 회사가 30일엔 폐업으로 바뀌어 있었습니다. 저는 이 회사가 실제로 언제 폐업했는지는 증명할 수 없습니다. 각 상태를 언제 봤는지만 알 뿐이죠. 그래서 그것만 저장합니다. "이 회사는 29일에 폐업했다"가 아니라 "봤을 때 영업 중이었고, 다시 봤을 때 폐업이었다". 둘은 다른 주장이고, 나중에 컴플라이언스 보고서에 들어갈 수도 있는 정보라면 이 차이가 중요합니다. 왜 할 가치가 있나 세 가지, 중요한 순서의 역순으로. 하나, 돈으로 살 수 없습니다. 원천에 이력이 없습니다. 원천을 감싼 다른 누구의 서비스에도 없고요. 경쟁자가 내일 "회사 상태 이력이 값지네"라고 깨달으면, 그의 이력은 내일부터 시작됩니다. 제 것은 오늘부터입니다. 이 격차는 벌어지기만 하고, 자본으로 메울 수 없습니다. 둘, 사업의 모양이 바뀝니다. 상태 조회는 일회성 거래입니다. 에이전트가 묻고, 2센트 내고, 떠나고, 다시 안 올 수도 있습니다. 반면 감시(watchlist)는 지속적인 관계입니다. 공급업체 100곳을 등록해두면 매일 제가 확인하고 움직인 것만 알려줍니다. 작지만 반복되고, 제 입장에선 이미 돌고 있는 인프라 위에서 공짜로 얹히는 겁니다. 셋, 신호는 상태가 아니라 변화입니다. "이 회사는 폐업했다"는 사실입니다. "이 회사는 3개월 전 휴업했다가 지난주에 재개했다"는 위험에 대한 해석이고, 조달 시스템이 실제로 알고 싶어 하는 건 후자입니다. 현재형 조회를 아무리 많이 해도 두 번째는 못 만듭니다. 쌓아야만 생깁니다. 하마터면 망가질 뻔한 것들 아무것도 안 하고 exit 0으로 끝난 작업. [지난 글](3편 링크)에 썼던 그 버그입니다. 엔트리포인트 가드가 파일 URL을 손으로 조립해서, 윈도에선 되고 리눅스에선 조용히 실패했습니다. 컨테이너는 뜨고, 아무것도 안 하고, 깔끔하게 종료되고, 스케줄러는 초록불이었습니다. 수동 실행 없이 스케줄을 믿었다면 일주일치 "아무것도"를 수집했을 겁니다. 첫날은 아무것도 증명하지 못합니다. 첫 실행에선 모든 레코드가 신규라 비교 경로가 한 번도 실행되지 않습니다. 결과물은 완벽해 보였지만 비교 로직이 도는지에 대해선 아무것도 말해주지 않았어요. 진짜 검증은 2일차에, 변화 70건이 나오고 이전값·현재값·양쪽 타임스탬프가 전부 채워졌는지 확인하면서 됐습니다. "어제와 오늘을 비교하는" 무언가를 만들었다면, 배포한 다음 날까지는 작동하는 시스템을 가진 게 아닙니다. 범위를 좁히는 게 보안 기능입니다. 어떤 회사를 추적할지 정하는 가장 쉬운 방법은 이용자가 조회한 번호를 쓰는 겁니다. 저는 일부러 안 했습니다. 목록은 공개 등록부(조달 업체 목록, 부정당업자 제재 목록)로만 구성했고, 이 원칙을 주석이 아니라 런타임 가드와 테스트로 강제했습니다. 주석은 급한 미래의 저를 막지 못하니까요. 이용자 조회 내용은 목록에 들어가지 않고, 따라서 이 데이터셋에는 제가 고객에게서 알아낸 것이 하나도 없습니다. 비용 하루 약 2,100콜(한도는 100만), 저장소는 월 수백 원, 작업 시간은 2분 30초. 프로젝트 전체에서 가장 싼 부분이고, 아마 가장 값진 부분입니다. 나머지는 전부 남이 일주일이면 다시 만들 수 있지만, 이것만은 못 만드니까요. 일반화하면 공개 데이터를 에이전트용으로 감싸고 계신다면, 원천이 답하지 않는 것이 무엇인지 물어볼 가치가 있습니다. 대개 시제 문제입니다. 무엇인지는 알려주지만, 무엇이었는지와 무엇이 바뀌었는지는 알려주지 않죠. 그 빈자리가 내가 소유할 수 있는 유일한 부분입니다. 나머지는 전부 원천이 이미 주는 것의 얇은 사본입니다. 내가 쌓은 이력만이 내 것이고, 그건 적어두기로 결심한 날부터 시작됩니다. 길게 썼지만 요지는 하나입니다. 할 거라면 필요해진 날이 아니라 오늘 시계를 켜세요. 기록하지 않은 데이터는 영원히 되찾을 수 없는 유일한 종류입니다.