신규 도메인 모니터링 대시보드 추가로 운영 시야 확보

한 이커머스 및 크리에이터 서비스 플랫폼으로 확장하면서, 각 서비스별 통계 대시보드를 개별 관리해야 하는 상황이 생겼다. 이번 작업은 기존 stats-dashboard 스크립트에 신규 서비스를 추가하는 작업인데, 단순 도메인 등록을 넘어 모니터링 시스템의 확장성을 어떻게 설계할지에 대한 고민이 담겨 있다.

배경: 왜 이 변경이 필요했나

보통 서비스가 새로 추가되거나 기존 서비스의 중요도가 높아지면, 운영팀과 개발팀은 그 서비스의 상태를 실시간으로 추적할 수 있는 대시보드를 필요로 한다. 접속자 수, API 응답 시간, 에러율, 트래픽 패턴 같은 지표들이 일관되게 모니터링되어야 하는데, 이런 것들을 수작업으로 관리하면 실수의 여지가 생기고 신규 서비스 추가 때마다 코드 수정의 부담이 커진다.

stats-dashboard 는 이런 문제를 해결하기 위해 설정 기반 구조로 설계된 것 같다. 새로운 도메인을 추가할 때 몇 가지 핵심 파라미터만 정의하면, 나머지 로직은 자동으로 처리하도록 만들어진 것이다. 이번에 추가한 신규 서비스도 그 틀에 맞춰 온보딩하는 과정이다.

작업 내용: DEDICATED_LOGS와 DISPLAY_ORDER

이 커밋에서 핵심적으로 추가한 두 가지 설정 항목은:

DEDICATED_LOGS 는 단순 "이 도메인 로그 여기서 읽어라" 라는 것을 넘어서는 설계다. 어떤 서비스는 실시간 스트림을 쓸 수도, 어떤 서비스는 배치로 집계된 로그를 쓸 수도 있기 때문이다. 각 서비스의 로그 수집 인프라가 다를 수 있으니, 그것을 유연하게 지정해야 한다. 그래서 하드코딩 대신 설정 값으로 뺀 것이다.

DISPLAY_ORDER 는 운영 관점에서 중요한데, 운영팀이 매일 아침 대시보드를 보면서 가장 주목해야 할 서비스가 맨 위에 와야 한다는 뜻이다. 예를 들어 매출 관련 도메인이면 1순위, 부가 기능이면 2순위 이런 식으로. 우선순위가 코드 상수가 아니라 설정 값으로 관리되므로, 운영 정책 변화에 빠르게 대응할 수 있다.

내가 배운 점과 팀 차원의 의의

이런 작업을 하면서 느낀 게, 초창기에 "대시보드 하나"를 만들 때는 그냥 고정된 구조로 가도 빠르다. 하지만 서비스가 2개, 3개로 늘어나면서 매번 코드를 수정하는 것이 누적되면, 결국 설정화된 구조로 리팩토링하게 된다는 것이다. 차라리 처음부터 확장 가능한 설계를 고민했으면 더 좋았을까?

이 부분에서는 타이밍이 중요하다고 본다. 서비스가 1~2개 수준일 때 "미리 확장성을 생각해서" 복잡한 설정 체계를 만들면 오버엔지니어링이 될 수 있다. 하지만 3~4개 서비스가 추가될 기미가 보이면, 그때 "이제 설정화하자"고 결정하는 것이 경험상 가장 합리적이다. 우리도 그런 타이밍에 이 작업을 한 것 같다.

팀 관점에서는, 신규 서비스를 온보딩하는 프로세스가 명확해진다는 게 큰 이점이다. 예를 들어 다음 달에 또 다른 신규 서비스가 추가되면, 운영팀이나 주니어 개발자도 docs/가이드를 보고 DEDICATED_LOGS 와 DISPLAY_ORDER 값만 구하면 스스로 추가할 수 있다. 코드 수정이 아니라 설정 추가가 되었기 때문이다.

앞으로의 확장

이 구조라면 향후에 ALERT_THRESHOLD 같은 임계값이나 RETENTION_DAYS 같은 로그 보관 정책도 쉽게 추가할 수 있다. 각 서비스의 특성에 맞춰 따로 설정할 수 있으니까. 이것이 좋은 설정 기반 설계의 모습이라고 본다.

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

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

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