LearningCollector: auto 모드는 PR 요약만 포스팅

cron으로 돌아가는 auto 모드가 매번 그날의 커밋들을 훑어서 블로그 글을 만들다 보니, 임시 파일 정리하는 커밋이나 뭔가 검증해보려고 찍은 커밋, 차트 하나 추가한 커밋까지 죄다 개별 글이 되어 쌓이고 있었다. 문제는 이게 단순히 글이 많아지는 수준이 아니라, website 레포처럼 feature 브랜치에서 작업하다 PR로 병합하는 워크플로를 쓰는 곳에서 특히 두드러졌다는 점이다. PR을 병합하면 그 작업 전체를 요약한 draft가 따로 생기는데, 그 안에 이미 다 포함된 내용이 커밋 단위로 또 한 번 개별 포스팅되고 있었던 거다. 결과적으로 같은 작업 내용이 PR 요약 글 하나, 그 PR에 속한 커밋들 여러 개로 중복되는 구조였다.

고칠 부분을 찾아보니 의외로 손댈 곳이 많지 않았다. core/github_collector.py의 collect() 메서드 안에서 JSON을 저장하는 단계 중 _save_dev_commits(dev_commits)를 호출해서 개발 커밋들을 파일로 저장하고 있었는데, 이 호출 하나가 개별 커밋 포스팅의 시작점이었다. auto 모드 전체가 이 collector를 거쳐 돌아가기 때문에, 여기서 저장 자체를 막으면 그 뒤 포스팅 파이프라인까지 자연스럽게 정리되는 구조였다.

baekjoon_files = self._save_baekjoon_commits(baekjoon_commits)
dev_files = []

_save_dev_commits 호출을 지우고 dev_files를 빈 리스트로 두는 것으로 끝났다. 백준 커밋 저장 로직은 그대로 두고, 개발 커밋 쪽만 결과를 비워버리는 식이라 변경 범위가 딱 한 줄짜리 로직 수정에 그쳤다. 다만 나중에 이 코드를 다시 볼 때 "왜 갑자기 빈 리스트를 넣었지"라는 의문이 들 게 뻔해서, 주석으로 배경을 꽤 자세히 남겨뒀다. 자잘한 커밋까지 블로그 글이 되어 포스팅이 잘게 쪼개졌다는 것, PR 요약 draft가 이미 작업 전체를 설명한다는 것, 그래서 auto 모드에서는 PR 요약만 포스팅 대상으로 삼는다는 것까지 코드 옆에 그대로 적어뒀다.

이 변경을 auto 모드로만 한정한 이유는 명확했다. interactive 모드는 사람이 직접 커밋을 골라서 포스팅하는 자리이기 때문에, 자잘한 커밋이라도 본인이 필요하다고 판단하면 여전히 개별로 포스팅할 수 있어야 한다. 그래서 이번 수정은 github_collector.py의 auto 흐름에만 손을 댔고, interactive 쪽 로직은 건드리지 않았다.

이미 DB에 저장돼서 개별 포스팅으로 나간, PR에 포함된 커밋들의 기존 글들은 이 PR의 범위 밖으로 남겨뒀다. 과거 데이터 정리는 성격이 다른 작업이라 별도로 처리하기로 하고, 이번 PR은 앞으로 생성되는 흐름만 바꾸는 데 집중했다. 커밋 하나, PR 생성 후 20분 만에 병합까지 끝난 걸 보면 변경 자체는 작았지만, 배경이 되는 문제 인식(포스팅 중복과 파편화)은 코드 한 줄보다 주석에 더 많이 담겨 있는 PR이었다.