공공 연방 계약 데이터를 활용한 리드 생성 자동화 - 데이터 센터 건설 사례 연구
Automating lead gen from public federal contract data - a data center construction case study
핵심 요약
Claude와 API를 활용해 연방 계약 데이터를 분석하고 하청 기회를 자동으로 발굴하는 리드 생성 파이프라인 구축 사례입니다.
- 데이터 분석 — Claude를 활용해 USAspending API에서 건설 관련 계약을 필터링함
- 자동화 파이프라인 — 브라우저 자동화로 업체 연락처를 찾고 이메일로 영업을 수행함
- 패턴 발견 — VA의 EHRM 프로그램처럼 반복적인 건설 수요를 데이터로 포착함
- 기술 스택 — Claude, USAspending API, Google Sheets, Atomic Mail을 통합함
우리 사용자 중 한 명이 데이터 센터 건설 현장에서 하청을 맡는 소규모 건설 팀을 운영하고 있어. 이 친구가 Claude로 에이전트 파이프라인을 만들어서 쓰고 있는데, 에이전트 전용 메일함으로 Atomic Mail을 쓰거든. 근데 이게 에이전트 문제가 아니라 데이터 문제라는 게 밝혀져서 우리한테 공유해 줬어. 공공 입찰이나 낙찰 데이터를 가지고 영업(lead gen)하는 사람들한테 진짜 유용한 패턴이라 허락받고 공유함.
이 친구 일거리는 대부분 대기업들이 연방 정부 계약을 따내고 나서 하청을 줄 때 생겨. 근데 업계 뉴스나 입소문으로 소식이 돌 때쯤이면 이미 괜찮은 하청 자리는 다 나간 뒤거든. 그래서 고민이, 연방 정부 건설 계약을 따낸 놈들을 남들보다 먼저 자동으로 찾아낼 수 있냐는 거였어. 알고 보니 연방 정부 낙찰 데이터는 공개되어 있고 조회도 무료더라고. USAspending에 JSON API가 있는데 계정도 필요 없고 FPDS에서 바로 긁어올 수 있어. Claude한테 spending_by_award 쿼리 짜달라고 했더니 20분 만에 구조화된 결과물을 뽑아내더라. SAM.gov도 공고문 텍스트용 API가 따로 있긴 한데, 속도 제한이 빡세. 공개 키로는 하루 10번, 등록된 법인은 1,000번까지 가능해.
여기서부터가 진짜 재밌어지는 지점이야. 뻔한 방법은 "data center"라는 키워드로 낙찰 건을 필터링하는 건데, 이러면 계약 건이 수백 개씩 튀어나와. 근데 콘크리트 치는 우리 입장에선 거의 다 쓸모없는 것들이야. Peraton, GDIT, Accenture 같은 애들이 AWS 재판매하는 것들이거든. 연방 정부 입장에서 "데이터 센터"는 실제 건물보다는 IT 서비스인 경우가 훨씬 많으니까.
진짜 효과적인 건 이 키워드를 건설 관련 NAICS 코드인 236220이랑 238210(건물 및 전기 시공업체 표준 분류)이랑 교차 검증하는 거야. 이렇게 하면 연방 정부 지출 내역이 한눈에 볼 수 있을 정도로 확 줄어들어. 텍사스 VA(재향군인부)에 4,890만 달러짜리 Trevino Group, 애틀랜타 EHRM 인프라에 2,780만 달러짜리 Hurley JV, NLM 데이터 센터 냉각수 설비에 1,330만 달러짜리 AG JV, 그랜드 정션의 티어 2 빌드에 670만 달러짜리 Hawk Contracting 등등, 대부분 VA랑 엮인 것들이지. 이거 따라 할 때 주의할 점 두 가지가 있어. 날짜 필터가 계약 시작일이 아니라 거래일 기준으로 돌아가. 그래서 옛날 계약 수정 사항이 진짜 신규 낙찰 건이랑 섞여서 나와. 수정 사항이 곧 현장 투입 자금이라면 상관없지만, "누가 새로 따냈나"를 찾는 거랑은 좀 다르지. 그리고 필터링 거친 12개 낙찰 건 중에서 7개가 VA였고, 5개는 대놓고 EHRM 프로그램이랑 엮여 있었어.
마지막 부분이 진짜 수확이었어. 건설 쪽 일감 상당수가 VA의 전자 건강 기록 현대화(EHRM) 사업 하나에서 나오더라고. 이게 사이트마다 데이터 센터 업그레이드를 계속 만들어내거든. 이건 단일 낙찰 건보다 훨씬 가치 있어. 예측이 가능하니까. 키워드 검색만으로는 절대 안 나왔을 거야. 낙찰 상세 내역을 십여 개 연속으로 읽어보고 나서야 보인 거지.
에이전트가 제값을 하는 건 그다음 단계야. 낙찰 기록에는 회사 이름이랑 UEI(정부 식별 번호)는 있는데, 연락처는 낙찰받은 회사의 영업 담당자가 아니라 계약 담당 공무원이야. 대화할 사람이 없다는 거지. 바로 이럴 때 브라우저 자동화가 딱이야. 낙찰받은 회사 사이트에 들어가서 하청이나 공급업체 담당자 연락처를 찾아내는 거지. 적중률은 그저 그런데, 대형 원청업체일수록 연락처 찾기가 더 힘들어. 근데 사실 걔네가 돈은 제일 많이 되거든. 구조화된 API가 있는 건에 대해서는 브라우저 자동화가 오히려 헛짓거리야. 처음 버전은 페이지를 직접 긁어왔는데 레이아웃 한 번 바뀔 때마다 다 깨졌거든. 근데 API 버전으로 바꾸고 나서는 한 번도 안 깨졌어.
마지막 조각은 이메일이야. 에이전트는 자체 Atomic Mail 받은 편지함을 쓰니까, 개인 메일함을 거칠 필요 없이 같은 스레드 안에서 초안을 보내고 답장을 읽을 수 있어. 처음엔 공유 도메인으로 시작했다가 나중엔 자기 회사 도메인으로 옮겼거든. 그러니까 에이전트가 메일을 보낼 때마다 회사 이름이 딱 뜨는 거지. 그 뒤로는 사람들이 발신자 주소만 보고도 우리 회사를 바로 알아보고 답장을 보내기 시작했어. 그냥 듣보잡 주소 취급하던 때랑은 차원이 다르지.


