도구를 만들고 싶은 충동과, 도구가 정말 필요한 상황은 다르다.
애드센스 블로그를 기획하면서 검색 트렌드 분석 라이브러리를 실전에 투입했다. 그 과정에서 pytrends의 urllib3 호환 문제를 고쳤고, 동시에 "앞으로 뭘 더 만들어야 하나"를 정리했다. 결론부터 말하면, 20개 아이디어를 검토한 결과 신규 개발 0건이었다.
검색 트렌드 라이브러리를 애드센스 블로그 키워드 분석에 쓰려는데, GoogleClient가 에러를 뱉었다. urllib3가 2.x로 올라가면서 retries 파라미터의 처리 방식이 바뀌었는데, pytrends 4.9.2가 이를 따라가지 못한 것이다.
수정은 간단했다.
# 수정 전: urllib3 2.x에서 에러
self._pytrends = TrendReq(hl="ko", tz=540)
# 수정 후: retries=0으로 설정, 자체 재시도 로직 사용
self._pytrends = TrendReq(hl="ko", tz=540, retries=0)덤으로 trending_searches() 기능도 불안정하다는 걸 확인하고 CLI에서 제거했다. 비공식 라이브러리에 의존할 때는 쓰는 기능의 범위를 최소한으로 줄이는 게 답이다.
pytrends 문제를 고치면서 애드센스 블로그의 전체 워크플로우를 정리하게 됐다. 키워드 발굴부터 콘텐츠 작성, 발행, 트래킹, 최적화까지 8단계를 나열하고, 각 단계에 이미 가지고 있는 도구를 매핑했다.
결과는 예상 밖이었다. 그동안 쌓아둔 아이디어가 20개쯤 있었는데, 하나하나 따져보니 상황이 이랬다.
신규 개발이 필요한 항목은 "사이트 코드" 하나뿐이었고, 그것조차 새 도구가 아니라 기존 프로젝트의 코드 작성이었다.
개발자의 본능은 "이거 자동화할 수 있겠는데?"라고 생각하면 바로 코드를 짜기 시작하는 것이다. 나도 그랬다. 키워드 분석 도구, 콘텐츠 스코어링 도구, 자동 발행 파이프라인... 아이디어 목록은 계속 늘어났다.
그런데 워크플로우를 8단계로 나누고 기존 도구를 매핑하는 순간, 빈 칸이 거의 없었다. 검색 트렌드 분석은 이미 만든 라이브러리가 하고, 콘텐츠 생성은 Claude Code가 하고, 발행은 PayloadCMS MCP가 하고, 트래킹은 Umami가 하고, 배포는 ArgoCD가 한다.
"아이디어 포트폴리오"에 "애드센스 필요도" 열을 추가해서 각 아이디어를 재평가한 것도 도움이 됐다. 멋져 보이는 도구와 실제로 필요한 도구는 다르다. 도구를 만드는 건 재밌지만, 도구를 만드느라 실제 블로그 콘텐츠를 못 쓰면 본말이 전도된다.
이번 경험에서 얻은 교훈은 두 가지다. 첫째, 비공식 라이브러리에 의존할 때는 사용하는 기능의 범위를 최소한으로 줄여야 한다. pytrends의 시계열 조회는 괜찮지만 trending_searches는 언제 깨질지 모른다. 둘째, 새 도구를 만들기 전에 기존 도구의 조합으로 워크플로우를 커버할 수 있는지 먼저 매핑해봐야 한다. "뭘 만들까"보다 "뭘 안 만들어도 되는지"를 먼저 확인하는 습관이 시간을 절약해준다.
돌이켜보면 pytrends 호환 문제를 고치는 데 걸린 시간보다, 20개 아이디어를 정리해서 "안 만들어도 된다"는 결론을 내리는 데 들인 시간이 더 가치 있었다.
TrendReq 생성 시 retries=0으로 설정하고, 자체 재시도 로직을 구현한다. trending_searches 같은 불안정한 기능은 사용하지 않는 것이 안전하다.
애드센스 블로그의 8단계 워크플로우(키워드 발굴, 분석, 기획, 작성, 발행, 배포, 트래킹, 최적화)를 나열하고, 각 단계에 이미 있는 도구를 매핑했다. 빈 칸이 없으면 신규 개발이 불필요하다.