채용 공고 봇을 만들다 접은 개발자가 깨달은 자동화의 함정

매일 채용 사이트를 확인하는 게 귀찮았어요. 내 기준에 맞는 공고만 텔레그램으로 자동 전달해주는 봇을 만들면 되겠다 싶었죠. GitHub Actions로 주기 실행하고, Python 스크립트를 기능별로 분리하고, 가점과 감점 요소를 두고 점수를 계산하는 구조까지 설계했어요. 완벽한 계획이었는데, 결론부터 말하면 접었어요.

서버를 따로 둘 것까진 아니라서 GitHub Actions를 선택한 건 합리적이었어요. cron 관리도 간단하고, 실행 로그를 GitHub에서 바로 볼 수 있으니까요. `crawler.py`, `parser.py`, `matcher.py`, `notifier.py`까지 깔끔하게 분리했죠.

수집되는 정보가 형편없었고, AI는 없는 정보를 우겼다

문제는 데이터 품질이었어요. 채용 사이트가 크롤링을 허용하지 않을 것 같다는 불안도 있었고, AI 특유의 없는 정보를 있다고 우기는 현상까지 겹쳤거든요. 계속 손보면 쓸 수 있는 수준까지 갈 수 있었겠지만, 거기에 들이는 시간이 아까웠어요. "그럴 바에 내가 직접 하고 말지"라는 생각이 든 순간, 이 프로젝트의 존재 이유가 사라진 거예요.

패착을 돌아보면 명확해요. 어떤 데이터를 어떻게 수집할지에 대한 방향이 없는 채로 자동화를 시작했어요. 자동화할 작업에 대한 구조화가 덜 된 상태에서 도구부터 만든 거죠. 진짜 필요해서 만든 게 아니라, 해보고 싶어서 한 게 더 컸다는 솔직한 고백이 인상적이에요.

"만들 수 있느냐"에서 "무엇을 왜 만드느냐"로 질문이 바뀌었다

AI가 등장하기 전에는 "구현할 수 있느냐"가 핵심 질문이었어요. 지금은 달라졌죠. 무엇을, 어떻게, 왜 구현할 것인가에 집중하는 시대가 됐어요. 구현 능력의 문턱이 낮아진 만큼, 문제 정의의 질이 결과물의 질을 결정하는 셈이에요.

자동화가 늘 생산성으로 이어지진 않는다는 건, 실패해본 사람만 체감하는 교훈이에요. AI 홍수 속에서 결국 이것저것 만들어보며 몸으로 부딪혀보는 수밖에 없다는 결론도, 역설적으로 가장 정직한 방법론이죠.