PRODUCTS & SYSTEMS · 2026 · PUBLIC ACTOR · MARKET NOT VALIDATED
입찰 공고의 새 버전이 올라왔다는 알림만으로는 부족했다. 무엇이 바뀌었고, 그 변화가 어느 원문에서 나왔으며, 담당자가 무엇을 다시 확인해야 하는지까지 남아야 했다. 이 문제를 BidDelta라는 변경 기록 서비스로 시험했고, 이후 공식 나라장터 Open API를 정규화하는 KONEPS Live Tender Matcher를 공개했다.
공개 제품과 외부 접촉은 남았다. 9월 3일 장부에서 확인된 구매와 매출은 0이었다. 다음 날 Apify의 공개 수치는 총 사용자 1, 월간 활성 사용자 0이었다. 그 한 명이 외부 고객이라는 근거도 없다.
BidDelta
변경 전후와 미해결 항목
KONEPS Actor
공식 API 기반 공개 도구
외부 접촉
문의폼·이메일 시도
구매·확인 매출 0
시장 검증 미완료
첫 제품은 문서 변경을 놓치는 문제에서 시작했다
BidDelta의 초기 대상은 영국의 기계·전기 설비 견적팀이었다. 마감이 가까워질수록 도면, 사양서, 추가 문서가 바뀌는데, 수정 사실을 알아도 가격에 반영했는지, 질의가 남았는지, 어떤 페이지를 근거로 삼았는지는 따로 관리해야 했다.
그래서 단순한 ‘변경 있음’ 알림 대신 페이지 근거가 붙은 변경 목록과 미해결 항목 인계표를 제품 범위로 잡았다. 자동 비교 결과는 사람이 다시 확인하도록 두었다. 판매 페이지, 범위·가격 문서, 실제 변경 사례 보고서, 운영 절차, CRM과 백테스트를 만들었다.
공개 출시 흔적은 2026년 8월 17일 외부 제품 목록에도 남아 있다. 잠재고객에게 문의폼과 이메일로 첫 접촉을 진행했지만, 다른 캠페인과 기록이 섞여 정확한 발송 수는 이 글에서 세지 않는다. 긍정 답변이나 구매는 확인되지 않았다.
속도제한은 코드보다 운영 방식을 바꿨다
공공 레코드를 한꺼번에 조회하자 속도제한 문제가 생겼다. 병렬 요청을 늘리는 방식 대신 조회 속도를 낮추고 실패한 요청을 다시 시도하게 바꿨다. 외부 발송 전에는 타깃 순위 오류와 깨진 근거 연결도 다시 점검했다. 변경을 찾는 것보다 그 변경이 맞는 문서와 연결됐는지 확인하는 일이 더 중요했다.
공식 조달 레코드와 몇 개의 사례를 대조했을 때 핵심 변경 신호는 재현됐다. 이것은 기술 검증이다. 누군가 그 보고서를 반복해서 쓰거나 돈을 냈다는 뜻은 아니다.
같은 질문을 나라장터 공개 데이터로 다시 구현했다
KONEPS Live Tender Matcher는 조달청 나라장터 입찰 공고 Open API를 직접 조회한다. 서비스·물품·공사·외자·기타 공고를 날짜, 키워드와 지역으로 걸러 낸 뒤 공고 번호, 기관, 예산, 마감일, 변경 상태와 원문 링크를 평면 레코드로 돌려준다. 공식 공고 번호와 차수를 기준으로 중복을 제거하고, 값이 없으면 추측하지 않고 비워 둔다.
사용자는 data.go.kr에서 받은 자기 서비스 키를 넣는다. 키는 비밀 입력으로 처리하고 결과에는 쓰지 않는다. 출력은 JSON, CSV나 Excel로 내보낼 수 있다. Actor의 역할은 공고를 찾아 정리하는 데서 끝난다. 입찰 자격을 판정하거나 서류를 작성하고 제출하는 도구는 아니다.
BidDelta와 KONEPS Actor의 구현과 구매자는 다르다. 같은 계보로 묶은 이유는 제품 질문이 이어졌기 때문이다. 공공조달에서 바뀐 정보를 사람이 확인할 수 있는 근거와 함께 어떻게 전달할 것인가. 하나는 문서 비교 서비스로, 다른 하나는 공식 API를 읽는 공개 Actor로 답했다.
공개 숫자는 아직 시장을 말해 주지 않는다
2026년 9월 4일 Apify 제품 페이지에는 북마크 0, 총 사용자 1, 월간 활성 사용자 0이 표시됐다. 개발자인 내가 시험한 실행이 포함됐는지, 외부 사용자가 실제 공고를 받았는지는 그 숫자로 알 수 없다. 유료 가격이 붙어 있다는 사실도 매출을 뜻하지 않는다.
확인된 결과는 공개 Actor 한 개와 남아 있는 BidDelta 출시 기록, 실제 외부 접촉이다. 구매, 반복 사용, 고객 계약과 확인 매출은 0이다. 제품은 만들었지만 무료 공식 알림과 무엇이 다른지, 누가 그 차이에 돈을 낼지까지는 답하지 못했다.
기술적으로는 변경을 찾고 원문으로 돌아갈 수 있었다. 영업에서는 그 차이가 구매 이유가 되지 않았다.
다음 시험의 기준
다음 단계는 더 많은 공고 유형을 붙이는 일이 아니다. 실제 입찰 실무자가 최근 놓친 변경 하나를 가져와 현재 방식으로 다시 찾을 수 있는지 확인하는 편이 먼저다. 원문으로 돌아가는 시간, 잘못 잡은 변화, 놓친 변화와 후속 조치를 함께 기록해야 한다. 그 시험에서 반복 사용 신호가 생길 때 제품 범위를 넓힐 수 있다.
Project record
기간: 2026년
역할: 제품 범위 설정, 공공 레코드 정규화, 변경 비교, 근거 연결, 속도제한·재시도 설계, QA, 공개와 초기 영업
내부 산출물: 사례 보고서, CRM, 운영 절차, 단위시험과 백테스트
외부 확인: BidDelta 공개 출시 흔적, 공개 Apify Actor, 문의폼·이메일을 통한 첫 접촉
확인되지 않은 것: 외부 고객 귀속, 반복 사용, 구매, 계약, 매출 또는 입찰 성과
Apify 공개 상태 확인일: 2026년 9월 4일