사이트별 로그 추적 기능 추가

최근에 페이지뷰 로깅 시스템(site-pv)에 새로운 서비스를 등록하고, 등록된 서비스 목록을 한눈에 볼 수 있는 기능을 추가했다. 단순한 데이터 등록처럼 보이지만, 실제로는 멀티사이트 환경에서 로그 추적의 운영 방식을 크게 개선한 작업이다.

문제의 배경

우리 팀이 운영하는 서비스들이 점점 많아지면서, 각 서비스의 페이지뷰 데이터를 중앙에서 일관되게 추적하고 모니터링해야 할 필요가 생겼다. 문제는 새로운 서비스가 추가될 때마다 로그 시스템에 수동으로 등록하고, 설정 파일을 수정하고, 배포 후에 실제로 로그가 수집되는지 일일이 확인해야 한다는 것이었다.

특히 운영팀이나 신입 개발자 입장에서는 어떤 서비스가 로그 시스템에 등록되어 있는지 한눈에 알 수 없었다. 설정이 산재되어 있으면 누군가는 빠진 서비스가 있는 줄 모르고 일하게 되고, 그 결과 데이터 공백이 생기거나 원인을 파악하기 어려워진다. 특별히 급하게 서비스를 오픈할 때는 이런 설정 누락이 더 잘 일어난다.

무엇을 변경했나

site-pv 로그 시스템에 DEDICATED_LOGS 개념을 도입했다. 각 서비스는 고유한 로그 채널을 갖게 되고, site-pv.py에 서비스를 등록하는 순간 다음이 연쇄적으로 동작한다:

1. 서비스 정보가 site-pv.py에 등록되면
2. 자동으로 해당 서비스의 전용 로그(DEDICATED_LOGS) 설정이 생성되고
3. 대시보드나 관리 인터페이스에서 "등록된 서비스 목록"을 조회하면 모든 서비스와 그 로그 상태를 한눈에 볼 수 있다

로그 추적의 일반론

멀티사이트 환경에서 로깅을 설계할 때 자주 마주치는 선택지들이 있다:

중앙화 vs 분산화
모든 서비스의 로그를 한곳으로 모을까, 각 서비스별로 관리할까? 우리는 중앙화를 선택했고, DEDICATED_LOGS를 통해 각 서비스의 로그를 분리하면서도 중앙에서 추적 가능한 구조를 만들었다. 이렇게 하면 한 서비스의 로그 폭주가 다른 서비스에 영향을 주지 않는다.

자동화 vs 수동
새 서비스가 생길 때마다 개발자가 매번 개입할 필요가 있을까? 가능하면 자동화하되, 설정이 명시적으로 표현되어야 한다. 우리는 site-pv.py에 서비스를 등록하는 순간 로그 시스템이 자동으로 반응하도록 했지만, 코드에 명확히 기록되므로 누가 언제 무엇을 추가했는지 추적 가능하다.

가시성의 중요성
운영자 입장에서 "지금 어떤 서비스가 추적 중인가?"를 빠르게 파악할 수 있어야 한다. 이것이 display list 기능을 추가한 이유다. UI가 있으면 설정 파일을 열고 읽을 필요 없이 현재 상태를 직관적으로 알 수 있다.

# site-pv.py 에 새로운 서비스를 등록하는 것만으로
# DEDICATED_LOGS에 자동으로 채널이 생성되는 구조

SITE_CONFIGS = {
    "ecommerce_platform": {"dedicated_log": "logs/ecommerce.log", "active": True},
    "admin_panel": {"dedicated_log": "logs/admin.log", "active": True},
    "new_service": {"dedicated_log": "logs/new_service.log", "active": True},
}

# display_list() 호출하면 위 서비스들이 모두 보인다
def display_list():
    return list(SITE_CONFIGS.keys())

코드 리뷰 관점에서의 고민

이 작업을 하면서 몇 가지 트레이드오프를 고민했다:

• 설정 vs 코드: DEDICATED_LOGS를 설정 파일에 선언할까, 아니면 Python 코드에서 동적으로 생성할까? 코드에 넣으면 버전 관리가 쉽지만, 설정이 코드에 섞인다. 우리는 site-pv.py를 중심으로 하되, 코드 주석으로 충분히 문서화하기로 했다.

• 에러 처리: 서비스 등록 시 로그 채널 생성이 실패하면 어떻게 할까? 누군가는 서비스가 등록된 줄 알지만 실제로는 로그가 수집 안 되는 상황을 피해야 한다. 등록과 로그 채널 생성을 가능한 한 원자적으로 처리하거나, 최소한 그 상태를 명확하게 표시하는 것이 중요하다.

• 확장성: 앞으로 더 많은 서비스가 추가될 때도 이 구조가 견딜 수 있을까? 현재는 Python 파일 한 곳에서 관리하지만, 서비스가 수십, 수백 개로 늘어나면 데이터베이스 기반 레지스트리로 전환해야 할 것 같다.

배운 점

이 작업은 "작은 기능"이지만, 그 뒤에는 운영 방식에 대한 철학이 담겨 있다는 걸 느꼈다.

새로운 서비스가 추가되는 것은 개발팀만의 일이 아니라, 운영팀이나 비개발자도 관여할 수 있어야 한다. 그렇다면 UI/대시보드가 중요하고, display list 기능이 단순한 기능이 아니라 팀 전체의 효율성을 높이는 도구가 된다.

또한 자동화할 때는 "무엇이 자동화되었는가"를 명확하게 표시하고, 나중에 문제가 생겼을 때 추적할 수 있어야 한다. 로그 시스템이 DEDICATED_LOGS로 서비스별 격리를 제공하면, 문제 발생 시 "어느 서비스의 로그가 누락되었는가"를 빨리 파악할 수 있다.

기술적 부채는 작을 때 갚는 게 낫다. 지금 당장 "서비스 목록을 정렬하는 기능"이나 "더 이상 필요 없는 서비스를 비활성화하는 기능" 같은 것들을 넣지는 않았지만, 다음 반복에서 추가할 때는 현재의 기초 위에 자연스럽게 올려놓을 수 있는 구조를 만들었다.

다음 번에는 로그 수집 지연이나 누락 사항이 실제로 줄어들었는지를 측정하고, 운영 과정에서의 피드백을 받아서 더 개선해야겠다.

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

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

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