정부지원사업 찾는 게 귀찮아서 Claude Code 세션에 맡겨봤습니다

혼자 일하다 보면 챙겨야 할 잡무가 의외로 많습니다. 그중 하나가 정부지원사업이었습니다. 1인 사업자에게도 도움이 될 만한 지원정책이 분명 어딘가에 열려 있을 텐데, 그걸 알아보려면 이 포털 저 포털을 일일이 들어가 새 공고를 훑어야 했습니다. 한두 번은 했지만, 같은 일을 주기적으로 반복할 생각을 하니 솔직히 귀찮아졌습니다. 그러던 차에, 마침 옆에 켜둔 Claude Code 대화 세션에 이 일을 한번 맡겨보면 어떨까 하는 생각이 들었습니다. 이 글은 그 작은 시도에 대한 기록입니다.

내가 원한 건 '목록'이 아니었습니다

처음엔 으레 그렇듯 자동화부터 떠올렸습니다. 공고를 긁어 오는 스크립트를 짜고, 거기에 LLM API를 하나 붙여서 자동으로 분류하게 만들면 그럴듯하겠다는 생각이었습니다. 그런데 그 그림을 그리다 말고 한 가지를 스스로에게 물어보게 되었습니다. 나는 이 작업에서 정확히 무엇을 받고 싶은가.

답은 의외로 분명했습니다. 제가 귀찮았던 것은 공고가 어디 있는지 찾는 일이 아니라, 찾아낸 공고들 중에서 "이건 나한테 맞고, 이건 아니다"를 가려내는 일이었습니다. "이런 공고들이 올라와 있습니다" 하는 목록은 포털이 이미 보여주고 있고, 제가 진짜 바란 것은 그 목록을 두고 "당신이 하는 일이라면 이건 자격이 되고 해볼 만하다 / 이건 대상이 아니다"를 근거와 함께 짚어주는 판단이었습니다.

그렇게 정리하고 나니, 판단에 굳이 외부 LLM API를 새로 붙일 이유가 흐릿해졌습니다. 근거 있는 판단을 가장 잘해줄 상대가 마침 이 작업을 함께 하고 있는 대화 세션 안에 이미 켜져 있었기 때문입니다. 그래서 처음 떠올렸던 그림 중 판단을 외부 모델에 맡기는 쪽은 접기로 했습니다. 다만 공고를 어디서 어떻게 받아 올지, 즉 데이터를 모으는 쪽은 별개의 이야기였고, 이건 오히려 제대로 갖춰야 했습니다.

공고는 포털을 눈으로 훑는 대신 데이터로 받았습니다

판단을 사람의 맥락에 맡기기로 한 만큼, 그 판단에 넘길 재료는 깔끔하고 일관되게 들어와야 했습니다. 포털 화면을 매번 눈으로 스크롤하며 제목을 줍다 보면 어제 본 걸 오늘 또 보거나 빠뜨리기 십상입니다. 그래서 공고를 화면이 아니라 데이터로 받아 오기로 했고, 다행히 우리나라에는 이런 공고를 정식으로 열어주는 공공 데이터 창구가 있었습니다.

제가 쓴 곳은 두 군데였습니다. 하나는 중소벤처기업부 계열의 기업지원 공고가 모이는 기업마당(bizinfo)이고, 다른 하나는 창업 분야 공고가 올라오는 K-Startup의 사업공고 데이터였습니다. 두 곳 모두 사람이 보라고 만든 웹페이지와는 별개로, 프로그램이 받아 갈 수 있는 OpenAPI 창구를 따로 열어두고 있었습니다.

인증키 두 개를 발급받았습니다 (체계가 서로 달랐습니다)

두 창구를 쓰려면 각각의 인증을 받아야 했는데, 여기서 살짝 의외였던 건 두 키의 발급 체계가 서로 다르다는 점이었습니다. 같은 '공공 데이터'라고 한데 묶기 쉽지만, 실제로는 발급처도 키의 형태도 따로였습니다.

• 기업마당은 자체 OpenAPI 인증키를 발급합니다. 안내 페이지에서 신청 양식을 작성하니, 생각보다 간단하게 곧바로 발급되어 이메일로 전송되었습니다.
• K-Startup 공고는 공공데이터포털(data.go.kr)을 통해 데이터셋 활용신청을 하고, 거기서 별도의 serviceKey를 받는 방식이었습니다. 이쪽은 자동승인이라 신청과 거의 동시에 키가 떨어졌습니다.

그러니까 기업마당의 자체 인증키와 공공데이터포털의 serviceKey는 이름도 출처도 다른 별개의 키였고, 둘 중 하나만 있어서는 한쪽 공고밖에 받지 못해 양쪽을 각각 발급받아 둬야 했습니다. 막상 해보니 "공공 데이터를 키 받아서 가져온다"는 일이 막연히 생각했던 것보다 훨씬 가벼웠다는 생각이 들었습니다.

발급받으면 무엇을 얻는가

키를 받고 실제로 호출해 보니, 돌아온 것은 제가 막연히 떠올렸던 '제목이 죽 늘어선 목록'이 아니었습니다. 공고 하나하나가 여러 항목으로 쪼개진 구조화된 데이터로 왔습니다. 한 건의 공고가 대략 이런 항목들을 달고 들어왔습니다.

• 공고명과 사업 개요(요약)
• 소관 기관 / 주관 기관
• 지원 분야 (경영·창업·기술 같은 분류)
• 지원 대상 (누구를 위한 사업인지)
• 신청(접수) 시작일과 마감일
• 상세 페이지로 가는 링크

그리고 이게 사람이 읽으라고 풀어 쓴 문장이 아니라, 기업마당은 JSON으로 K-Startup은 XML로, 즉 기계가 바로 다룰 수 있는 형태로 떨어졌습니다. 화면을 볼 때는 제목과 마감일이 한 덩어리의 글로 보여서 무엇이 분야이고 무엇이 대상인지를 매번 제 머릿속에서 잘라내야 했는데, 데이터로 받으니 분야는 분야 칸에 마감일은 마감일 칸에 이미 나뉘어 있었습니다. 덕분에 "마감이 지난 건은 빼고", "이 날짜 이후 새로 올라온 것만" 같은 추림을 항목 기준으로 깔끔하게 걸러낼 수 있었고, 뒤에서 판단을 붙이기에도 훨씬 좋은 재료가 되었습니다.

한 가지만 덧붙이면, 여기서 발급받은 인증키와 serviceKey는 공고 데이터를 가져오기 위한 출입증일 뿐, 앞서 접기로 한 LLM API와는 전혀 다른 것입니다. 공공 데이터 API는 "공고를 데이터로 받아 오는" 수집 쪽에 적극적으로 썼고, LLM API는 "이게 나한테 맞는지 판단하는" 쪽에 굳이 붙이지 않았습니다. 같은 'API'라는 말에 묶이지만, 제 경우 둘은 정반대 자리에 있었던 셈입니다.

모으는 일과 가려내는 일을 나눴습니다

재료를 데이터로 확보하고 나니, 한 덩어리처럼 보이던 일이 성격이 다른 두 조각으로 갈렸습니다. 모으는 일은 공개된 데이터를 키로 받아 오는, 판단이 끼어들 자리가 없는 기계적인 영역입니다. 반면 가려내는 일은 같은 공고라도 누가 보느냐에 따라 답이 달라지는, 맥락이 필요한 일이었습니다. 그래서 둘을 칼같이 갈라, 수집은 공공 데이터에 맡기고 판단만 세션에게 넘겼습니다. 흐름으로 보면 이런 모양이었습니다.

공고 수집   →   적합 여부 판단   →   결과 정리
 (공공 API)      (맥락이 필요)        (남겨두기)

이렇게 적어두고 나니 고민할 곳이 가운데 한 칸으로 또렷해졌습니다. 양옆의 수집과 정리는 손댈 게 별로 없었고, "이게 나한테 맞는가"를 가리는 가운데 판단만 잘 채우면 되는 것이었습니다.

세션은 내가 무슨 일을 하는지 이미 알고 있었습니다

판단을 맡기는 단계에서, 대화 세션을 택하길 잘했다는 생각이 가장 크게 들었습니다. 만약 외부 모델에 공고를 하나씩 보내 점수를 받았다면, 모델은 제가 어떤 일을 하는 사람인지 모르니 누구에게나 통하는 범용 점수를 돌려받았을 겁니다. 제 사정을 매번 새로 실어 보내야 했을 테고요.

그런데 옆에 켜둔 세션은 사정이 달랐습니다. 그동안의 대화 속에서, 제가 어떤 일을 하는 1인 사업자인지 무엇을 우선으로 보는지를 이미 어느 정도 알고 있었습니다. 그러니 잘 정돈된 공고 데이터를 건네기만 하면, "당신이 하는 일이라면 이 공고는 신청 자격이 되고 이런 점에서 해볼 만하다", "이건 대상 업종이 아니라서 맞지 않는다" 하는 식으로, 제 맥락에 비춰 근거를 붙여 추려주었습니다. 단순한 검색이었다면 키워드로 끝났을 일이지만, "나에게 맞느냐"는 물음은 제 입장을 아는 누군가가 목록을 같이 들여다봐 주어야 답이 나옵니다. 제가 처음에 바랐던 것이 정확히 이것이었습니다.

판단은 눈으로만 보고 흘리지 않았습니다

다만 한 가지 함정이 있었습니다. 세션이 추려준 판단을 채팅 화면에서 눈으로만 확인하고 넘어가면, 그 판단은 대화와 함께 사라진다는 점입니다. 어떤 공고를 왜 맞다고 봤고 왜 걸렀는지를 며칠 뒤에 다시 들여다볼 수 없게 됩니다. 그래서 결과를 흘려보내지 않고 형태를 갖춰 따로 쌓아두니, 휘발되던 대화가 비로소 나중에 다시 열어볼 수 있는 자산이 되었습니다.

마침 수집 단계에서 공고마다 고유한 식별 항목이 함께 들어왔던 덕에, 한 번 본 공고는 다음에 다시 받아 와도 "이건 지난번에 처리한 것"이라고 가려낼 수 있었습니다. 그래서 새 공고를 다시 받을 때도 지난번에 무엇을 어떤 이유로 걸렀는지가 남아 있으니, 같은 고민을 처음부터 되풀이하지 않아도 되었습니다. 결국 이 작은 작업의 골격은 단순했습니다. 모으고 쌓아두는 일은 공공 데이터와 기계적인 처리에 맡기고, 맥락이 필요한 판단 한 조각만 세션이 메우는 구조였습니다. 처음 떠올렸던, 판단까지 외부 모델에 떠넘기는 거창한 자동화는 결국 필요하지 않았습니다.

찾는 일과 가려내는 일은 다른 일입니다

이 일을 끝내고 든 생각을 한 문장으로 줄이면 이렇습니다. 정보를 찾는 것과, 그 정보가 나에게 맞는지 가리는 것은 다른 일이라는 것. 찾는 일은 누가 해도 같은 목록으로 끝나기에 공공 데이터 창구에서 키 받아 데이터로 받아 오면 되지만, 가리는 일은 나를 아는 누군가의 판단을 필요로 합니다. 그리고 후자야말로, 내 맥락을 이미 알고 있는 대화 세션에게 맡기기에 가장 잘 맞는 일이었습니다.

공고를 일일이 뒤지는 게 귀찮아 시작한 일이었지만, 끝에 남은 건 손품을 던 경험만은 아니었습니다. 공고를 데이터로 받아 올 창구가 생각보다 가까이 열려 있었다는 것, 그리고 제가 진짜 원한 것이 "목록"이 아니라 "근거 있는 판단"이었다는 걸 또렷이 알게 된 것이 어쩌면 더 큰 수확이었습니다. 무언가를 자동화하고 싶어질 때 곧장 도구부터 붙이기 전에 "나는 여기서 정확히 무엇을 받고 싶은가"를 한 번 물어보면, 의외로 그 답이 가까운 곳에 이미 켜져 있는 경우가 있었습니다.