분산된 추적 시스템, 하나의 집계로 통일하기

opsvoro라는 추적 시스템의 PV 집계를 site-pv.py에 새로 등록했다. 단순한 기능 추가처럼 보이지만, 사용자 행동 데이터를 여러 소스에서 수집할 때 마주하는 여러 결정과 트레이드오프를 다시 정리해볼 기회였다.

왜 집계 소스를 늘렸나

팀이 운영하는 서비스에서 사용자 행동을 이해하는 건 중요하다. 매출, 프로덕션 이슈, 유저 경험 개선 — 모두 "실제로 누가 뭘 했는가" 라는 데이터에서 시작된다. 그런데 서비스가 커지면서 자연스레 여러 추적 방식이 생긴다:

• 프론트엔드 SDK가 기록하는 이벤트
• 백엔드 로그
• 외부 분석 라이브러리
• 결제 플랫폼의 거래 데이터
• 새로운 채널이나 파트너사 연동

각각의 소스가 제각기 PV(혹은 그에 상응하는 메트릭)를 수집한다. 문제는 일관성이다. 한 건의 사용자 방문이 여러 시스템에 중복으로 기록될 수 있고, 어떤 시스템은 누락될 수 있으며, 타임스탠프도 다를 수 있다. opsvoro는 그 중 하나의 새로운 소스였다. 이미 A, B 시스템으로부터 받고 있던 데이터에 C를 추가한다는 건, 단순히 "더하기"가 아니라 "어떻게 조화시킬까"의 문제다.

작업의 핵심 — 통합 로직 설계

site-pv.py는 사실 여러 집계원으로부터 데이터를 받아 정규화하고, 때로는 중복을 제거하고, 대시보드와 리포팅에 필요한 형태로 변환하는 역할을 한다. opsvoro를 등록한다는 건 이 파일에 새로운 데이터 소스를 입력으로 연결하고, 기존 로직과 잘 맞게 처리하도록 수정하는 작업이었다.

이 과정에서 고민했던 것들:

배운 점 — 데이터 통합의 현실

이런 작업을 하다 보니 느낀 것들:

첫째, 데이터 소스는 늘릴수록 복잡해진다. 초반엔 한두 개 시스템이 명확하다. 하지만 N개가 되면 관리 포인트가 제곱으로 증가한다. 어떤 시스템이 오동작했을 때 원인을 찾기도 어렵고, 새로운 팀원이 이해하기도 어렵다. 따라서 새로운 소스를 추가할 때마다 "정말 필요한가?"를 먼저 물어본다.

둘째, 검증 기간을 충분히 가져야 한다. opsvoro를 등록할 때 처음부터 "이 수치를 쓴다"고 하지 않았다. 먼저 기존 시스템과 나란히 수집한 후, 몇 주간 비교해서 패턴이 맞는지 확인했다. 이 과정에서 "A 시스템은 로그아웃도 센다, opsvoro는 안 센다" 같은 차이를 발견했다. 이건 버그가 아니라 설계 차이인데, 모르고 쓰면 대시보드가 갑자기 수치를 왔다갔다 한다.

셋째, 문서화를 아무리 해도 부족하다. "opsvoro는 이렇게 수집되고, 이런 경우는 제외된다"는 문서를 아무리 잘 남겨도, 6개월 뒤에 누군가는 왜 A와 B가 다른지 묻는다. 팀이 커질수록 이런 문제는 자주 반복된다. 총괄 입장에서 코드 리뷰나 설계 단계부터 "이 수치들의 차이가 왜 나는가"를 명시적으로 남겨두는 습관이 중요하다고 느꼈다.

마무리

단 한 줄의 커밋 메시지지만, 그 뒤에는 "어떤 소스를 신뢰할 것인가", "어떻게 통합할 것인가", "팀이 이 데이터를 어떻게 이해할 것인가" 같은 여러 의사결정이 담겨 있다. 다음에 비슷한 집계 작업을 추가할 때는 이번 경험을 바탕으로, 검증→문서화→롤백 계획 순서를 먼저 챙길 것 같다.

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

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

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