대시보드에 버튼·응답시간 메트릭 독립 추적 추가

지난주 stats-dashboard 스크립트에 두 가지 새로운 메트릭을 등록했다. 버튼 상호작용과 초 단위 응답시간(seconds)을 추적하는 토이 메트릭인데, 각각 전용 로그를 갖춰서 독립적으로 수집할 수 있게 했다. 단순해 보이지만, 이 작은 변경이 팀의 관측성 기반을 다시 한 번 정리하는 좋은 타이밍이었다.

왜 별도의 메트릭인가

내가 이전에 경험한 많은 프로젝트에서, 모니터링 대시보드는 "나중에 필요하면 추가하지" 하다가 문제가 터진 후에야 급하게 손을 댄다. 이번엔 좀 다르게 접근해 보고 싶었다. 사용자가 버튼을 클릭하는 행동 자체와 그 버튼이 응답하는 시간을 실시간으로 들여다볼 수 있다면, 성능 저하나 UX 이슈를 사전에 포착할 수 있을 거라 생각했다.

특히 "토이 메트릭(toy metrics)"이라고 이름 붙인 이유는, 이게 아직 프로덕션 KPI와는 다르다는 신호를 남기기 위함이었다. 팀원들이 대시보드를 볼 때 "아, 이건 아직 초기 단계의 관측 데이터군" 하고 빨리 파악할 수 있게. 향후 이 데이터들이 쌓이면서 정식 메트릭으로 승격할 수도 있고, 다른 대시보드로 옮길 수도 있으니까.

Dedicated Logs의 선택

"dedicated logs"는 단순해 보이지만 생각해 볼 점이 많다. 처음 방안은 기존 통합 로그에 metric_type: button, metric_type: seconds 같은 필드를 추가하고 필터링하는 것이었다. 하지만 그렇게 하면:

• 로그 크기가 불필요하게 커진다 (모든 이벤트에 메타데이터 추가)
• 쿼리 시 항상 필터링 오버헤드가 생긴다
• 스토리지 정책이 메트릭별로 다를 수 있다 (버튼은 1주일, seconds는 1개월 보관 등)

그래서 파이썬 스크립트에서 로그 포인트를 분리했다. 각 메트릭이 자신의 로그 스트림으로 나가게 함으로써, 나중에 처리/분석하는 쪽에서 훨씬 깔끔하게 파이프라인을 구성할 수 있다.

우리는 중장기적으로 메트릭 양이 늘어날 것 같아서 전용 로그 방식을 택했다.

토이 메트릭이 남기는 신호

팀 내에서 대시보드를 볼 때 메트릭의 성숙도를 구분하는 게 중요하다. 누군가는 button metrics를 보고 "이걸로 버튼 배치를 최적화해야 하나?" 물을 수 있는데, 아직 초기 데이터일 수도 있으니까. "토이"라는 라벨을 붙임으로써 암묵적인 신뢰도 신호를 전달할 수 있다.

또 이름이 명확하면 코드리뷰도 훨씬 빨라진다. 6개월 뒤에 누군가 이 부분을 들여다볼 때 "아, button/seconds는 아직 프로토타입 단계고, 필터링이나 정합성 체크는 추후에…" 하고 바로 맥락을 잡을 수 있다.

데이터 기반 의사결정의 작은 한 발

지금은 로그만 수집하지만, 이 데이터가 쌓이면 여러 질문에 답할 수 있게 된다:
- 사용자가 어떤 버튼을 많이 누르는가?
- 버튼 응답 시간이 최근 늘어났는가?
- 기능 A 배포 후 버튼 상호작용 패턴이 바뀌었는가?

이런 질문들이 팀의 의사결정을 좌우할 수 있다. "성능 최적화가 필요한가?"라는 물음에 데이터로 답할 수 있게 되는 것이다.

작은 작업, 큰 의미

파이썬 스크립트에 몇 줄 추가한 것 같지만, 이건 팀의 관측성 문화를 한 단계 높이는 신호다. 메트릭을 체계적으로 수집하고, 각각 독립적으로 추적하고, 명확한 이름으로 커뮤니케이션한다는 습관. 이게 쌓이면 나중에 성능 문제나 사용자 이슈가 터졌을 때 "아, 우리 데이터가 있으니 분석해 볼 수 있겠다"는 자신감으로 이어진다.

다음 스프린트에는 이 메트릭들이 실제로 의미 있는 신호를 주는지 검증하고, 필요하면 추가 메트릭을 등록할 계획이다.

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

• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

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