개발 slecs

서비스 접근 로그 독립 추적 체계 구축

목차

특정 도메인의 사용자 접근 패턴을 더 정확히 추적하기 위해 기존 통합 로깅 시스템에서 전용 로그 채널을 등록했다.

기존 로깅의 한계

여러 서비스가 같은 로그 스트림을 사용하다 보면 각 서비스별 접근 패턴을 따로 분석하기 어려워진다. 특히 트래픽 규모가 다른 서비스들이 섞여 있으면, 한 서비스의 성능 저하나 비정상 트래픽이 다른 서비스의 로그 신호를 방해할 수 있다. 게다가 운영 대시보드에서 특정 도메인에 대한 실시간 모니터링을 하려면 통합 로그에서 계속 필터링 쿼리를 작성해야 하는데, 이건 운영 비용도 크고 지연도 발생한다.

이런 상황에서 DEDICATED_LOGS 개념은 각 서비스나 도메인이 자신만의 독립적인 로그 채널을 갖는 것이다. site-pv.py 파일을 수정해 특정 도메인에 대한 접근 로그를 전용 스트림으로 등록하면, 이후로는 모든 페이지뷰 이벤트가 그 채널로 바로 흘러들어간다.

site-pv.py 변경의 의미

일반적인 로깅 등록 패턴은 다음 같다:

# 기존: 통합 로그 채널 하나에만 쓰기
logger.info("page_view", service="platform", domain="service-a.example.com", user_id=123)

# 변경: 전용 채널 추가 등록
DEDICATED_LOGS = {
    "life/name": {
        "channel": "pv_log_dedicated_life_name",
        "retention": "30d",
        "alert_threshold": 100000  # 일일 임계값
    }
}
# 결과: 이제부터 이 도메인의 이벤트는 별도 채널로도 동시 기록됨

이렇게 하면 여러 효과가 생긴다. 첫째, 대시보드 구성이 단순해진다. 운영자는 통합 로그에서 필터링할 필요 없이 전용 채널만 구독하면 되기 때문에 쿼리 비용과 렌더 지연이 줄어든다. 둘째, 알림 규칙을 더 정밀하게 설정할 수 있다. 각 서비스별로 정상/비정상 트래픽 범위가 다를 텐데, 전용 채널이 있으면 각각에 맞는 임계값 설정이 가능하다. 셋째, 데이터 거버넌스 측면에서도 깔끔해진다. 특정 도메인의 로그를 장기 보관하거나 삭제할 때 전용 채널이면 훨씬 간편하다.

로깅 계획 확대의 판단 기준

이런 작업을 할 때 스스로에게 묻는 질문들이 있다:

  • 모니터링 필요성: 이 서비스의 트래픽 패턴이 다른 서비스와 독립적으로 추적할 만큼 중요한가?
  • 운영 빈도: 운영자가 실시간으로 이 도메인의 상태를 확인해야 하는가? 아니면 월 1회 리포트로 충분한가?
  • 알림 정책: 트래픽 급증이나 접근 실패 시 즉시 대응해야 하는 수준인가?
  • 확장성: 향후 이런 도메인이 더 늘어날 예정인가?

이 경우 site-pv 라는 네이밍과 DEDICATED_LOGS 구조를 보면, 아마도 어떤 사용자 여정 추적(user journey)이나 특정 기능 페이지의 접근 분석이 중요한 비즈니스 요구사항이 된 걸로 보인다. 단순히 "로그가 필요해" 수준이 아니라, 그 도메인의 성능과 사용자 행동을 실시간으로 분석해야 하는 단계가 된 것이다.

회고와 확장성

이런 작업을 진행하면서 느낀 점은, 로깅 설계는 초기엔 단순하게 시작하되 운영 과정에서 천천히 정교해진다는 것이다. 처음부터 모든 도메인을 위해 전용 채널을 만드는 건 낭비지만, 필요가 명확해진 시점에 빠르게 추가할 수 있도록 구조를 설계해두는 게 중요하다.

site-pv.py 에 DEDICATED_LOGS 딕셔너리를 추가하면, 앞으로 새로운 도메인을 추가할 때도 일관된 방식으로 진행할 수 있다. 팀원들이 같은 패턴을 따르게 되고, 코드 리뷰도 수월해진다. 또한 나중에 로그 아카이빙이나 비용 최적화를 할 때도, 구조화된 설정이 있으면 자동화 스크립트를 작성하기 쉽다.

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

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

이어보기

댓글 0

첫 댓글 달아줘.