트래픽 학습 시스템의 전사 커버리지 확보

초기 설계가 일부 콘텐츠 사이트만 커버하도록 했던 traffic-watcher를 이제 전사의 모든 콘텐츠 사이트로 확장했고, 그 과정에서 빠진 서비스 하나를 발견해 추가했다.

왜 커버리지 작업이 필요했나

팀에서 운영하는 콘텐츠 플랫폼들의 SEO 성능과 트래픽 추이를 학습·모니터링하는 일은 중요하다. 어떤 사이트의 검색 순위가 떨어지고 있는지, 트래픽은 어디서 들어오는지 알아야 문제를 빨리 잡을 수 있고, 신규 기능이나 콘텐츠 전략의 효과도 측정할 수 있으니까.

처음 시스템을 만들 때는 "가장 트래픽이 큰 몇몇 사이트부터 시작하자"는 생각으로 진행했다. 빠르게 돌려보고 검증하려면 스코프를 줄이는 게 맞다. 그런데 시간이 지나면서 새로운 서비스가 생겼고, 기존 서비스도 전략상 중요도가 달라졌다. 어느 날 팀 회의에서 "음, 우리가 모든 사이트를 monitoring하고 있나?"라는 질문이 나왔다. 그때 느낀 게 "아, 지금이 커버리지를 정리할 타이밍이다"는 생각이었다.

작업 내용

두 가지를 했다:

1. 전 콘텐츠 사이트 명시적 포함: 기존에는 설정 파일에 사이트 목록이 하드코딩되거나 부분적으로만 있었다. 이를 재정리해서 현재 운영 중인 모든 콘텐츠 사이트가 자동으로 학습 대상에 포함되도록 구조화했다. 신규 서비스 추가 시에도 명확한 프로세스가 생겼다.

2. 누락된 서비스 발견: 전사 목록을 재점검하는 과정에서 werebridge가 빠져 있었음을 발견했다. 신규 서비스였거나, 아니면 초기 설정할 때 단순히 누락된 것일 수도 있다. 어쨌든 이제는 모니터링 대상에 포함됐다.

설계와 운영 사이의 갭

흥미로운 건, 시스템 초기 설계할 때는 "현재 상태"를 기준으로 스코프를 정한다는 거다. 그런데 조직이 성장하면서 새로운 서비스들이 계속 생기는데, 그게 자동으로 기존 모니터링 시스템에 반영되지는 않는다. 이건 design issue가 아니라 ownership 문제다.

팀이 작을 때는 "누가 신규 서비스 만들 때 traffic-watcher도 업데이트하겠지?"라는 암묵적 가정이 먹힌다. 하지만 팀이 커질수록 이런 가정은 위험해진다. 내가 자주 하는 실수 중 하나인데, 초기 설계의 "합리적인 가정"이 시간이 지나면 누락의 원인이 된다.

해결책은 두 가지:
- 수동 방식: 신규 서비스 런칭 체크리스트에 "traffic-watcher에 추가"를 명시적으로 포함
- 자동화 방식: 서비스 레지스트리나 배포 설정이 단일 진실 소스가 되어, traffic-watcher가 거기서 자동으로 읽도록 함

현재는 전자를 강화하는 방향으로 진행했다. 이 정도면 충분할 것 같긴 한데, 장기적으로는 후자도 고려할 필요가 있다. 팀이 커질수록 자동화의 가치는 기하급수적으로 커진다.

이번 변경이 주는 것

모니터링 커버리지가 거의 100%에 가까워지면서:
- 블라인드 스팟 제거: 우리가 놓친 서비스가 있었다면, 그게 정상 상태인지 문제인지 이제는 파악 가능
- 의사결정 근거 강화: 전사 트래픽 데이터를 가지고 더 정확한 분석과 판단 가능
- 팀 신뢰도: "traffic-watcher의 데이터는 믿을 만하다"는 신뢰 형성

작은 시스템도 시간이 지나면 "전사 커버리지"를 고민해야 하는 순간이 온다. 그 타이밍을 놓치지 않으려면 주기적으로 "우리가 뭘 놓치고 있지?"라는 질문을 하는 습관이 중요하다. 이런 작은 정리들이 모여서 팀 전체의 모니터링 체계를 한 단계 업그레이드하는 것 같다.

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

• 듀얼모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →

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