개인 학습 자동화 파이프라인, Gemini 폴백을 걷어내고 Claude Pro 단일 구조로 정리하기 (연재 1/3)

학습 주제

• 주제: LearningCollector 파이프라인의 로그 정리 및 Gemini→Claude 폴백 로직을 Claude Pro 단일 구조로 전환
• 날짜: 2026년 7월 21일

탐구 과정

원래 이 파이프라인은 초안(draft) 생성을 Gemini로 먼저 시도하고, 실패하면 Claude로 폴백하는 구조로 짜여 있었다. 그런데 실제로 돌려보니 Gemini의 flash 모델이 과금이 필요한 상황이라는 걸 알게 됐다. 무료로 쓸 수 있을 거라 생각했던 부분이 막히니, 굳이 두 개의 API를 동시에 관리할 이유가 없어졌다. 어차피 폴백될 거라면 처음부터 Claude Pro 하나만 쓰는 게 구조도 단순해지고 유지보수도 편할 것 같았다.

그래서 이번 작업은 두 갈래로 진행했다.

1. log 폴더에 더 이상 쓰이지 않는 로그 파일 정리
2. Gemini 관련 코드를 걷어내고 Claude Pro만 쓰도록 전체 로직 수정

로그 정리는 생각보다 까다로웠다. 파일명만 보고 지우면 안 되고, 코드 전체에서 해당 로그를 실제로 쓰고 있는지 확인해야 했다. exec_date.log와 cron_test.log는 데이터 파일 안에 과거 이력으로만 언급될 뿐, 실제로 어떤 코드도 쓰거나 읽지 않는다는 걸 확인한 뒤에야 삭제했다. "혹시 쓰고 있는데 지우면 어떡하지"라는 불안감 때문에 이 확인 과정을 건너뛰지 않은 게 다행이었다.

핵심 학습 내용

1. 죽은 코드(dead code)를 지우는 순서

Gemini 관련 로직을 걷어낼 때 순서를 다음과 같이 잡았다.

• core/gemini_draft_generator.py에서 gemini_exhausted_flag 관련 플러밍 코드 제거
• 더 이상 쓰지 않는 STUDY_MODEL (Gemini 모델 참조) 삭제
• 초안 생성 호출부 두 곳에서 model=STUDY_MODEL 인자 제거
• 남은 참조가 있는지 재검색 + _handle_ai_failure 예외 처리 메시지가 여전히 말이 되는지 검토
• 파일 문법 검사 및 죽은 GeminiClient import 여부 확인
• 이제 아무도 안 쓰는 api/gemini_client.py 파일 자체를 삭제
• google-genai 의존성을 프로젝트에서 제거

이 과정을 통해 배운 건, 코드 하나를 지울 때 "이 코드를 지우면 무엇이 깨지는가"를 역순으로 추적해야 한다는 점이었다. 단순히 함수 하나를 지우는 게 아니라, 그 함수를 호출하는 곳, 그 함수가 참조하는 설정값, 그리고 그 설정값을 만드는 의존성 패키지까지 체인 전체를 봐야 진짜로 깔끔하게 정리된다.

2. import 정리와 문법 검사의 중요성

파이썬에서는 사용하지 않는 import를 남겨둬도 당장 에러가 나지 않는다. 그래서 지우고 나서 "실행이 되니까 됐다"고 넘어가기 쉬운데, 실제로 모듈 해석(module resolution) 기준으로 google.genai가 다른 어디에서도 import되지 않는지 확인하는 절차를 거쳤다. 겉보기엔 돌아가도 나중에 배포 환경에서 의존성 문제로 터질 수 있다는 걸 다시 한번 느꼈다.

3. 문서와 코드의 동기화

README도 "Claude Pro 전용 초안 생성"으로 갱신했다. 코드만 고치고 문서를 안 고치면 나중에 내가 이 프로젝트를 다시 열었을 때 옛날 구조로 착각하고 헷갈릴 게 뻔하다.

이해한 내용

• 폴백 구조는 공짜가 아니다. 두 개의 API를 다 관리하는 건 안정성 측면에서 장점이 있지만, 그만큼 코드 복잡도와 과금 리스크를 동시에 짊어지는 거였다. 지금 상황에서는 폴백보다 단일 구조의 단순함이 더 필요했다.
• 삭제 작업일수록 신중하게, 단계별로. 로그 파일이든 코드든, 지우기 전에 "누가 이걸 쓰고 있는가"를 먼저 확인하는 습관이 사고를 막아준다.
• 자동화 스크립트는 실행 전에 부작용을 꼭 확인해야 한다. python main.py --auto가 단순히 초안만 생성하는 게 아니라, 생성 직후 검토 단계 없이 바로 실제 블로그에 게시까지 해버리는 구조라는 걸 다시 확인했다. 게다가 이미 매일 같은 명령을 실행하는 cron 작업도 걸려 있는 상태였다. 코드를 고쳤다고 바로 실행 버튼을 누르면 안 되고, "이 스크립트가 실제로 어디까지 자동으로 처리하는지"를 항상 먼저 짚고 넘어가야 한다는 걸 다시금 새겼다.

실전 적용

이번에 정리한 구조는 앞으로 파이프라인에 다른 AI API를 추가하거나 뺄 때도 그대로 써먹을 수 있는 절차라고 생각한다.

• 새 기능을 걷어낼 땐 플래그 → 호출부 → import → 의존성 순으로 역추적하며 지우기
• 자동 실행 스크립트를 건드릴 땐 실행 전에 "이게 실제로 어디까지 자동으로 진행되는지" 다시 확인하기
• 로그/캐시 파일 정리 전엔 코드베이스 전체 검색으로 실제 사용 여부 확인하기

다음엔 이 파이프라인에 초안 생성 후 검토(리뷰) 단계를 하나 추가해서, 자동 게시 전에 최소한의 확인 절차를 넣어보고 싶다.

추가 학습 계획

• cron으로 도는 자동화 스크립트에 안전장치(dry-run 모드, 게시 전 확인 단계)를 어떻게 설계하는지 더 찾아보기
• 의존성을 제거할 때 자동으로 미사용 import를 잡아주는 린트 도구 활용법 익히기
• API 과금 정책을 사전에 더 꼼꼼히 확인하는 습관 들이기 (이번처럼 실행하고 나서 발견하지 않도록)