국방/우주항공 분야의 새 프로젝트를 뉴스 검색으로 찾는 리포트를 만들다가, 뉴스만으로는 사업 이름도 사업 목록도 제대로 못 찾는다는 걸 알았다. 그래서 정부 공공데이터 API를 직접 조회하는 스크립트를 만들었다. 열린재정(국가재정정보공개시스템) 예산 데이터로 새로 생긴 사업을 찾고, 나라장터(조달청) 입찰공고와 낙찰정보로 참여 기업을 찾는 스크립트 네 개다. 경위는 2편에 적었다.
이 스크립트들은 원래 뉴스 리포트 프로젝트 안의 scripts/ 폴더에 있었다. 그런데
나라장터 검색이 생각보다 쓸모 있다는 걸 확인하던 무렵, 차라리 저장소를 따로 만드는 게
낫지 않을까 싶었다.
같은 폴더에 있었지만 다른 종류의 도구 (정부 공공데이터 API)
원래 프로젝트가 하는 일은 명확했다 — 사업 이름과 키워드를 가이드 파일에 적어두면, 뉴스를 검색하고 크롤링하고 요약해서 리포트를 만든다. 새로 만든 스크립트들은 전혀 다른 일을 한다 — 사업 이름 자체를 몰라도, 정부 예산·조달 데이터를 뒤져서 사업 이름과 참여 기업을 찾아낸다. 하나는 “이미 아는 이름으로 뉴스를 모으는” 도구고, 다른 하나는 “이름 자체를 모를 때 찾아내는” 도구다. 실제로 스크립트들은 원래 프로젝트의 뉴스 검색 엔진도, 가이드 파일도 쓰지 않았다.
나누지 않을 이유도 있었다. 스크립트는 네 개뿐이었고, 찾아낸 사업 이름은 결국 원래 프로젝트의 가이드 파일에 손으로 옮겨 넣는 흐름이라 저장소를 나누면 그 연결이 한 단계 늘어난다. 그래도 나누기로 했다. 이 발굴 방법은 국방/우주항공이 아닌 다른 분야의 정부기관에도 그대로 쓸 수 있는데, 한 저장소에 계속 두면 그때마다 뉴스 리포트 프로젝트 전체를 끌고 가야 한다.
그래서 별도 저장소로 분리했다. 이름은 gov-data-lead-finder.
국방/우주항공에 종속되지 않는, 정부 공공데이터 기반 범용 발굴
도구로 설계했다.
새 저장소를 만들다가 겪은 두 가지 잡음 — GitHub CLI 권한 부족, master/main 브랜치 불일치
저장소를 만드는 과정에서 원래 계획대로 되지 않은 게 두 가지 있었다.
첫 번째는 GitHub CLI로 저장소를 바로 만들고 밀어넣으려던 게 막힌 것이었다. 사용 중인 토큰(fine-grained 개인 액세스 토큰)에 저장소 생성 권한이 없어서 “Resource not accessible by personal access token” 에러가 났다. GitHub 웹에서 직접 저장소를 만들고, 그 원격 저장소에 코드를 올리는 쪽으로 바꿨다.
두 번째는 브랜치 이름 불일치였다. 로컬에서 git init으로 만든 저장소의 브랜치는
master였는데, push 명령에는 main을 적었다. 그러자 “src refspec main does not
match any” 에러가 났다. 로컬 브랜치 이름을 main으로 바꾸고 나서야 정상적으로 올라갔다.
도구가 하는 일과 안 하는 일을 명확히 적었다 — README와 crontab API 키
README를 쓰면서 신경 쓴 건 범위였다. 이 도구는 “이 정부기관에 어떤 사업이 있고, 정확히 뭐라고 불리는지, 어느 기업이 관련됐는지” 까지만 찾아준다. 그 데이터를 가지고 산업이나 시장을 분석하거나 어디에 어떻게 접근할지 정하는 건 이 도구의 역할이 아니다 — 그건 사람이, 또는 원래의 뉴스 기반 리포트 도구가 후속으로 할 일이다. 이 경계를 분명히 해두지 않으면, 나중에 “발굴”과 “분석”이 다시 한 저장소에 뒤섞이는 걸 막기 어렵다고 판단했다.
API 키는 두 개(열린재정, 나라장터)를 crontab에 등록했다. 어디서 어떻게 발급받았는지를 주석으로 정확히 남겨서, 나중에 키가 만료되거나 재발급이 필요할 때 같은 절차를 다시 밟을 수 있게 했다.
이렇게 뉴스 검색으로 국방/우주항공 프로젝트를 찾다가, 이름이 안 맞아서 막히고(1편), 정부 예산 데이터로 우회로를 뚫고(2편), 그 우회로가 별도 도구로 독립하는(3편) 데까지 왔다. 다음 편은 이 도구를 들고 원래 리포트로 돌아갔다가, 나라장터에서 국방 대형 사업이 전부 0건으로 나온 이야기다.