색인점검 인프라, 계정 관리를 체계화하다

최근에 Google Search Console(GSC) 색인점검 모니터링을 제대로 정리했다. 우리는 여러 사이트를 운영 중이고, 각 사이트마다 GSC 계정이 따로 있었는데, 색인 상태를 점검할 때마다 계정을 일일이 넘나들어야 했다. 그래서 _lib/adsense_index_watch.py 를 손보고, 멀티계정 기능을 추가하면서 문서도 함께 정리했다.

왜 지금 이 작업이 필요했나

팀이 운영하는 사이트가 2-3개 정도라면 "매번 대시보드 탭을 바꾸는 정도"가 큰 부담이 아닐 수 있다. 하지만 우리는 kpopdex, vtuberprofile을 비롯해 여러 서비스를 동시에 관리한다. 각 사이트의 색인 상태, 크롤 오류, 보안 문제 같은 것들을 월 1-2회 점검하려면:

• GSC 계정 여러 개를 로그인/로그아웃하며 전환
• 각 계정의 메트릭을 수동으로 정리하거나 머릿속으로 비교
• 어느 사이트는 확인했는데 어느 사이트는 빼먹기 쉬움
• "어제 본 색인 오류가 뭐였더라?" 할 때 문서가 없으면 다시 확인해야 함

이런 패턴이 반복되면, 작은 비용이 쌓인다. 운영 팀이 정기적으로 보고해야 하는데 수동 작업이 많고, 자동화 포인트가 명확했다.

멀티계정 기능으로 중앙화하기

adsense_index_watch.py 를 개선하면서 한 번의 실행으로 여러 Google 계정의 색인 데이터를 수집하도록 했다. 구체적으로는:

Python 스크립트에서 여러 Google 계정의 API 인증을 순회하고, 각 사이트의 색인 상태를 수집하는 방식으로 구현했다. 이렇게 하면 자동화 스크립트나 정기 점검 시스템을 통해 "매주 월요일 아침 색인 점검 리포트"를 자동으로 생성할 수 있게 된다.

문서와 실제 맞추기의 가치

이번 작업에서 흥미로운 부분이 하나 더 있었다. docs/seo-infra.md, docs/sites-detail.md 같은 문서들을 정리하면서, 실제 우리 서비스들의 계정 매핑이 문서에 기록된 것과 다르다는 걸 발견했다. kpopdex, vtuberprofile의 GSC 계정이 어느 것인지, 누가 관리하는지 애매한 부분들이 있었다.

"이 사이트는 이 Google 계정으로 관리한다"는 정보가 단순한 문서가 아니라 코드의 설정값과 100% 일치해야 한다는 걸 깨달았다. 왜냐하면:

• 누군가 adsense_index_watch.py 를 실행할 때, 문서를 믿고 credentials를 설정하게 됨
• 문서가 틀리면 → 설정 실수 → 점검 누락 → 색인 오류를 놓치는 사태까지 갈 수 있음
• "근데 이 계정은 뭔데?" 하고 다시 확인하는 시간 낭비

그래서 이번에 hedvion-CLAUDE.md와 sites-detail.md에 각 사이트별 계정 매핑을 명확히 기록했다. 이제 코드가 의존할 수 있는 single source of truth가 생겼다.

팀 차원에서 얻은 것

이 작업이 단순한 "자동화" 정도로 끝나지 않은 이유는, 인프라 코드와 문서의 동기화 필요성을 다시 한 번 확인했기 때문이다. 팀이 성장하면서 여러 사람이 다양한 시스템을 건드리게 되는데:

• 신입이 와서 "kpopdex는 어느 계정으로 관리돼?" 물어봤을 때 1초 안에 답할 수 있어야 함
• 운영 담당자가 색인 문제를 리포트할 때 신뢰할 수 있는 정보 필요
• 자동화 스크립트가 "어? 계정이 없네?" 할 상황을 원천 차단

이런 것들이 결국 팀의 운영 속도와 신뢰도를 좌우한다. 기술 팀장 입장에서는 코드를 짜는 것도 중요하지만, "이 시스템이 앞으로 3개월, 1년 뒤에도 제대로 동작하려면 뭐가 필요한가" 물어야 한다. 그 답이 종종 "더 나은 코드"가 아니라 "더 명확한 문서" 일 때가 있다.

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

• 모니터 쿠팡에서 보기 →
• 도킹스테이션 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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