도메인별 통계 격리로 대시보드 관리 자동화

새로운 도메인을 서비스에 추가할 때, 코드 변경은 한두 줄이지만 시스템 전체에 미치는 파급력은 생각보다 크다. blindboxdex.com을 대시보드에 등록하면서 단순히 데이터 소스를 추가하는 것에서 한 발 나아가, 로그 격리(DEDICATED_LOGS)와 표시 순서(DISPLAY_ORDER) 설정까지 함께 점검해야 한다는 점을 다시 한번 체감했다.

도메인 확장에 따른 대시보드 시스템 진화

플랫폼이 처음 설계될 때는 단일 도메인을 가정했을 수도 있다. 하지만 서비스가 성장하면서 여러 도메인을 병렬로 운영하게 되고, 각 도메인의 통계를 구분해서 관리해야 하는 상황이 생긴다. stats-dashboard.py는 이 모든 도메인의 메트릭을 수집하고 시각화하는 중추 역할을 한다.

새 도메인을 추가한다는 것은 "이 도메인의 데이터도 가져와라"라는 뜻만은 아니다. 그 도메인의 로그가 어디 저장될지, 대시보드에서 어느 위치에 표시될지, 다른 도메인과 섞이지 않게 하려면 어떻게 격리할지 같은 의사결정이 모두 따라온다.

DEDICATED_LOGS와 DISPLAY_ORDER가 중요한 이유

DEDICATED_LOGS는 각 도메인의 로그를 별도 저장소나 로그 채널에 기록하겠다는 의미다. 왜 이것이 필요한가?

• 성능: 도메인별 로그가 섞여 있으면 특정 도메인의 문제를 추적할 때마다 전체 로그를 필터링해야 한다
• 보안/접근제어: 도메인별 접근 권한을 달리할 수 있다 (예: 팀 A는 A 도메인 로그만, 팀 B는 B 도메인 로그만)
• 수명주기 관리: 도메인을 폐기할 때 로그도 깔끔하게 함께 정리할 수 있다

DISPLAY_ORDER는 사용자가 대시보드를 열었을 때 도메인들이 어떤 순서로 보일지 정하는 설정이다. 이것도 "보기 좋으라고" 하는 것만은 아니다:

• 비즈니스 우선순위: 매출 규모나 중요도가 높은 도메인을 상단에 배치하면 자연스럽게 주의 집중 가능
• 모니터링 효율: 자주 확인해야 하는 지표를 찾기 쉬워진다
• 온보딩: 신입이 대시보드를 처음 보면, 표시 순서에 따라 서비스 구조를 직관적으로 이해한다

하드코딩 vs. 설정으로 관리

이런 작업을 하다 보면 "그냥 코드에 하드코딩하면 안 되나?"라는 유혹이 생긴다. 하지만 stats-dashboard.py 같은 설정 중심의 스크립트에서는 다음을 염두에 둬야 한다:

우리가 이번에 한 일은 "blindboxdex.com을 등록한다"는 한 줄 작업이 아니라, 설정 인프라를 한 단계 정비한 것이다. 앞으로 새 도메인이 또 생기면, stats-dashboard.py 코드를 건드리지 않고도 DEDICATED_LOGS와 DISPLAY_ORDER만 추가하면 시스템이 자동으로 통합된다.

팀 관점에서 본 영향

이 변경이 팀 전체에 미치는 파급력을 보면:

• 모니터링·운영팀: 새 도메인의 통계를 대시보드에서 바로 추적 가능
• 백엔드·애플리케이션팀: 도메인별 로그 분리로 문제 추적이 명확해진다
• DevOps 인프라팀: DEDICATED_LOGS 설정에 따라 로그 수집 파이프라인이 자동으로 조정될 수 있다

특히 이런 작업을 자동화하지 않으면, 도메인이 늘어날 때마다 "대시보드에도 등록해야 하네", "로그 설정이 빠졌네"라는 누락이 반복된다. 체크리스트에 의존하는 문화에서 벗어나 구조로 보장하는 것이 안정성의 핵심이다.

도메인이 5개, 10개로 늘어날수록 구성 관리(configuration management)의 품질이 시스템 안정성과 팀 생산성을 좌우한다. 이번 작업은 그 기초를 한 단계 다진 것이라고 본다.

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

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

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