검토·리뷰 완료 · 2026

수집처별 법적·운영 경계 정리

수집처별 약관과 API 정책을 대조해 직접 수집, 대체 경로, 서면 협의 대상을 구분했습니다.

기간2026-08 ~ 09

대상labrador-scrapers · crawler fleet

역할데이터 엔지니어 · 수집처 현행화와 기술 사전 검토

Data GovernanceAPI PolicyRate LimitAttribution

작업 요약

수집처 검토·리뷰 완료 · 9월 9일 기준 미통합 수집기 22개 분류

URL이 열린다는 사실만으로 수집할 수는 없습니다

고객사가 직접 운영할 보안데이터 수집 체계를 설명하려면 데이터 종류와 공급처만 적어서는 부족했습니다. 같은 공개 URL이어도 공공데이터, OSS 저장소, API 키가 필요한 서비스, 자동 접근을 제한하는 사이트의 운영 경계가 달랐습니다.

현재 크롤러가 실제로 쓰는 수집처를 다시 맞추고, 약관·데이터 라이선스·API 정책·robots 조건을 한 표에서 비교했습니다. 이 과정은 수집기의 기술 설계에 필요한 사전 검토이며 법률 자문이나 최종 승인 문서가 아닙니다.

고객 보고에 필요한 수집처부터 검토했습니다

고객 보고 범위는 라이브러리, 취약점, 13개 OS 배포판 보안 데이터, 라이선스와 호환성 자료였습니다. 파일·함수·바이너리 컴포넌트, 코드 레벨 취약점, exploit/PoC 데이터, Snyk는 1페이지 요약에서 제외했습니다.

원문 URL, 공식 API·파일·저장소 여부, 수집 방식과 주기, 약관 원문, rate limit, API 키 명의를 함께 보았습니다. “공개되어 있음”과 “현재 운영 모델에서 사용 가능함”을 같은 의미로 쓰지 않았습니다.

9월 9일 확인에서는 실제 저장소와 실행 방식을 다시 대조했습니다. labrador-scrapers 밖에 남은 수집기는 22개였고, 이 중 운영 중인 항목은 21개였습니다. 수동 Docker 실행, 상주 컨테이너, 정기 스케줄이 없는 DAG가 섞여 있어 코드 위치와 이관 여부를 함께 기록했습니다.

위험 등급별로 필요한 조치를 정했습니다

하 · 사용 조건 기록공공데이터나 OSS·데이터 라이선스를 확인하고 출처 표기와 라이선스 의무를 남깁니다.

중 · 런타임 제약 강제요청 간격, 동시성, 재시도, API 키, User-Agent, robots 조건을 crawler와 scheduler 설정으로 옮깁니다.

상 · 수집 경로 중단서면 동의, 공식 지원 인터페이스, 사용 가능한 대체 데이터 중 하나가 정해질 때까지 현재 경로를 사용하지 않습니다.

접근 차단 우회는 선택지에서 제외했습니다. HTML을 다른 방식으로 호출하는 것도 공식 인터페이스나 허가가 없으면 해결책으로 보지 않았습니다.

새 수집처를 검토하는 절차

수집처 inventory와 약관 검토에서 허용 조건에 따른 사용 경로 및 대체나 서면 협의 경로로 분기하고 실행 제한과 출처 기록으로 연결하는 기술 사전 검토 절차 — 이용 조건을 확인한 수집 경로에는 요청 제한과 출처 기록을 붙이고, 허용 근거가 부족한 경로는 대체·서면 협의 대상으로 남깁니다. 설정 반영과 최종 승인 여부는 후속 확인 대상입니다.

새 수집처를 추가할 때는 inventory에 URL과 검토 결과를 함께 기록합니다. 약관과 API 정책을 확인한 뒤 사용, 조건부 사용, 대체, 협의 중 하나로 구분하고 그 조건을 실행 설정과 출처 기록에 남깁니다.

실제 판단 사례

아래 이용 조건은 2026년 8월 20일 기술 사전 검토 당시의 기록입니다. 9월 최신화에서는 수집기 현황과 이관 범위를 다시 확인했습니다.

npm — 공개 crawler 정책이 API 복제를 허용하지만 초당 1회·월 500만 요청 조건을 운영 설정에 반영해야 합니다.
GitLab Advisory — gemnasium-db의 상업적 사용 제한 가능성을 피하기 위해 MIT 라이선스의 advisories-community 전환을 검토 대상으로 뒀습니다.
Amazon·Oracle OS 패키지 — 자동 수집 제한이 있어 vendor repodata 같은 대체 경로나 서면 동의가 필요합니다.
Cloudera·Atlassian Maven — 약관과 robots 제한을 확인해 공식 지원 프로토콜의 허용 범위를 확인하거나 서면 협의하도록 분리했습니다.
NVD·GitHub API — API 키·토큰 명의와 rate limit를 고객 운영 주체에 맞춰 정해야 합니다.

결과

9월 25일 기준으로 현황표의 22개 중 16개가 공통 실행 경로로 옮겨졌습니다. OS 수집기 10종, 취약점 우선순위 계산, CocoaPods·RubyGems·NuGet·Packagist가 먼저 옮겨졌고 Go는 9월 23일에 컷오버했습니다. Maven은 데이터 복사와 검증을 마치고 DAG 활성화를 기다리며, 커밋 URL·코드 취약점·GitHub Advisory 3개는 착수 전, Snyk·SourceClear 2개는 삭제 대상입니다. 이관 과정은 별도 항목에 적었습니다. 아래 22개는 9월 9일의 현황표 집계이며 현재 남은 작업 수로 사용하지 않습니다.

수집처별 검토와 리뷰를 마쳤습니다. 이 작업의 검토 산출물은 완료했으며, 수집기 이관 등을 포함한 관련 과제는 계속 진행 중입니다.

수집 데이터와 공급처를 고객 보고용 1페이지 표로 줄이면서도, 고위험 출처와 필요한 대체 경로를 함께 표시했습니다.
9월 9일 현황표의 미통합 수집기 22개를 이관 대상 20개 · 판단 보류 1개 · 중단으로 제외한 1개로 구분했습니다. 이 숫자는 현황표를 집계한 결과이며, 이관을 완료한 수는 아닙니다.
공개 API·파일·저장소 우선, 접근 차단 우회 금지, source별 rate limit, attribution, API 키 명의를 공통 운영 조건으로 정리했습니다.
고객이 직접 운영하는 수집 체계와 회사가 자체 DB를 제3자에게 제공하는 경우를 분리했습니다. 후자의 공급자 협약 문제는 아직 Needs confirmation입니다.
고위험 출처의 서면 동의 여부, 중위험 출처의 설정 반영 여부, 개인정보·출처 표기 방식은 후속 확인 항목으로 남겼습니다.

역할

운영 중인 크롤러와 기존 수집처 문서를 대조하고, 출처별 이용 조건과 대체 경로를 표로 정리했습니다. 이어서 저장소 밖에 남은 수집기 현황과 이관 범위를 조사했습니다. 법적 결론을 대신 내리지 않고 기술적으로 확인된 제약, 사업 계약에 들어갈 가정, 법무 판단이 필요한 항목을 분리했습니다.