SEO 모니터링 사이트 설정을 단일 모듈로 중앙화한 이유

들어가면서, 최근 한 refactor 작업으로 SEO 모니터링 시스템의 설정 관리를 다시 정리했다. _lib/gsc_submit.py와 seo-monitor/daily-report.py에 흩어져 있던 하드코딩된 SITES 목록을 sites.py 헬퍼 모듈로 통합하는 작업이었다. 작은 작업처럼 보이지만, 이 과정에서 팀 코드 관리의 질과 유지보수 비용에 대해 다시 생각해볼 기회가 됐다.

왜 이 중복이 계속 남아 있었나

시스템이 처음 구축될 때만 해도 SEO 모니터링 기능은 한두 개 모듈에서만 필요했을 것이다. 하지만 시간이 지나면서 Search Console 제출(gsc_submit.py)과 일일 리포트(daily-report.py) 두 곳에서 동일한 사이트 목록을 관리하게 됐다. 처음엔 누군가가 복사해서 넣었고, 이후로는 "이 정도면 괜찮지 않을까"라는 생각으로 넘어갔을 것이다.

그런데 이게 문제가 되는 순간이 언제일까? 누군가 새로운 사이트를 추가하려고 할 때다. 한 곳만 수정하면 다른 곳이 빠져있고, 그걸 발견하려면 두 파일을 일일이 비교해야 한다. 스쿼드가 커질수록, 커밋이 늘어날수록 이런 불일치 리스크는 기하급수적으로 커진다.

중앙화된 설정의 효과

# 변경 전: 여러 곳에서 각자 관리
# _lib/gsc_submit.py
SITES = ["site1.com", "site2.com", "site3.com"]

# seo-monitor/daily-report.py  
SITES = ["site1.com", "site2.com", "site3.com"]  # 복사본

이를 sites.py로 정리하면:

# sites.py
MONITOR_SITES = ["site1.com", "site2.com", "site3.com"]

# _lib/gsc_submit.py 와 seo-monitor/daily-report.py 
from _lib.sites import MONITOR_SITES

이 작은 변화의 의미:
- Single Source of Truth: 새 사이트 추가는 한 곳에서만
- 버전 관리: 누가 언제 뭘 변경했는지 git log로 추적 가능
- 의도의 명확성: "이 값은 공유 설정이다"라는 신호를 팀에게 전달

팀 리딩 관점에서의 결정

사실 이런 작업을 우선순위에 올리는 건 팀장 입장에서 간단하지 않다. 기능도 아니고, 버그 수정도 아니고, 성능 최적화도 아니니까. "지금 당장은 문제 없잖아"라는 의견도 많다.

하지만 내가 이 작업을 선택한 이유는 세 가지다:

1. 스케일링의 신호: 사이트 목록이 변경되는 빈도와 모듈이 늘어나는 속도를 봤을 때, 6개월 뒤 이 부채는 더 커질 것이 자명했다.
2. 팀 교육: 새로 합류한 팀원들이 SITES를 추가할 때 "어느 파일을 봐야 하나요?"라는 질문이 여러 번 나왔다. 중앙화는 onboarding을 쉽게 한다.
3. 코드리뷰 품질: 두 파일을 다 확인해야 하는 부담을 줄여서, 리뷰어가 실제 비즈니스 로직에 집중하도록.

배운 점: "작은 refactor의 누적"

이런 작업 하나하나는 큰 영향 같지 않다. 하지만 이걸 방치하면 코드는 서서히 엔트로피를 높인다. 여러 곳에서 유사한 패턴의 중복이 쌓이고, 어느 순간 "저 두 값이 정말 같은 건가?"라는 의문이 들기 시작한다.

반대로, 작은 refactor를 지속적으로 하면:
- 팀원들이 코드 규칙을 자연스럽게 배운다
- 변경의 영향도를 명확히 할 수 있다
- 향후 더 큰 리아키텍처가 필요할 때, 기초가 튼튼해 있다

다음 코드리뷰에서 누군가 "어, 이 값 저기랑 같은데?"라고 물으면, 그건 좋은 신호다. 그때 바로 중앙화하는 것. 나는 팀원들에게 이렇게 말한다: "설정은 여러 곳에 흩어져 있으면 안 된다. 복사-붙여넣기는 채무다."

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.