멀티사이트 모니터링에 전용 로그와 관리자 UI 추가

여러 사이트의 페이지뷰를 중앙에서 모니터링하는 시스템에 kpopdex.com을 추가하면서, 동시에 전용 로그 저장 옵션과 관리자가 사이트 목록을 직접 등록할 수 있는 기능을 구현했다.

이전엔 새 사이트를 추가할 때마다 개발자가 코드를 수정하고 배포해야 했다. 당연히 운영팀에서 자주 요청했고, "간단한 추가인데 왜 배포가 필요하냐"는 질문이 빠지지 않았다. 문제는 그뿐만이 아니었다.

멀티테넌트 환경에서의 로그 관리 문제

사이트별로 트래픽 패턴이 다르다 보니, 모든 로그가 뒤섞여 있으면 분석이 어려워진다. 한 사이트의 대규모 이벤트로 로그가 폭증하면, 다른 사이트의 정상 트래픽도 함께 묻혀버린다. 특정 사이트의 이슈를 디버깅할 때 전체 로그를 뒤져야 하는 비효율도 생긴다.

DEDICATED_LOGS 옵션을 추가한 이유가 여기 있다. 선택적으로 사이트별 독립 로그를 생성하면, 운영팀이 필요한 사이트만 집중해서 모니터링할 수 있다. 이건 단순한 편의 기능이 아니라 시스템 확장성과 직결된 설계 결정이다.

site-pv.py에서의 구현

site-pv.py는 전체 페이지뷰 트래킹의 핵심 로직을 담당한다. 이번에 추가한 것들:

• 사이트 등록 엔드포인트: 관리자가 사이트를 추가하면 시스템에 즉시 반영되는 로직
• DEDICATED_LOGS 플래그 처리: 사이트별로 로그 격리 여부를 관리하는 조건부 로직
• 표시목록 조회 및 갱신: 관리 화면에 현재 등록된 사이트 목록을 표시하고 실시간 갱신

코드 라인 수로는 크지 않은 변경이지만, 구조적으로는 의미가 크다. 기존엔 사이트 정보가 설정 파일이나 상수로 고정되어 있었다면, 이제부턴 런타임에 동적으로 관리될 수 있게 됐다.

의사결정: 왜 지금인가?

팀에서 논의한 건 이거였다—운영팀이 자주 요청하는 기능인데, 얼마나 투자할 가치가 있나?

결론은 간단했다. 매번 배포를 요청받는 것도 비용이고, 운영팀이 배포 일정을 기다리는 것도 비용이다. 게다가 시스템이 '전문가 도구'에 불과해선 안 된다. 프로덕트가 '누군가는 설정해야 하는 것'이 아니라 '운영자가 손쉽게 관리할 수 있는 것'이 되려면, 이 정도의 투자는 필수였다.

DEDICATED_LOGS는 선제 기능이다. 지금 당장 필수는 아니지만, 시스템이 성장했을 때 "사이트별 로그 격리가 필요해"는 요청이 들어올 게 뻔했다. 그때 되면 코드를 뜯어고쳐야 하는데, 지금 미리 구조를 준비해두면 나중에 설정값 하나로 처리할 수 있다.

배운 패턴

멀티테넌트 시스템을 여러 번 운영해본 입장에서, 이런 진화는 반복된다:
1. 처음: 하드코딩된 정보
2. 두 번째: 설정 파일로 외부화
3. 세 번째: 관리 UI로 자동화

문제는 각 단계를 밟을 때마다 "작은 변경"이라고 생각하다가, 나중에 보면 상당한 기술 부채로 남는다는 거다. 그래서 나는 지금 배운 것 몇 가지를 항상 염두에 둔다:

• 운영팀이 자주 요청하는 작업은 자동화의 신호다. 요청이 빈번하다는 건 프로세스가 비효율적이라는 뜻이니까.
• 플래그나 옵션은 미리 설계하자. 나중에 추가하려면 마이그레이션이 필요하지만, 미리 필드를 예약해두면 훨씬 간단하다.
• 관리 기능은 항상 사용자 입장에서 생각하자. 개발자 입장에선 '간단한 기능'도 운영자 입장에선 '복잡한 UI'일 수 있다.

이 작업을 마친 후, 운영팀이 새 사이트를 추가할 때 배포를 기다리지 않아도 된다는 피드백을 받았다. 작은 것 같지만, 팀의 속도와 자율성이 한 단계 올라간 셈이다.

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

• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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