로그 샘플링 실전 가이드

1. 문제 정의: 로그가 많을수록 디버깅이 쉬워지는가

로그는 많이 쌓을수록 안전할 것 같지만, 어느 순간부터는 반대로 작동합니다. 저희가 신규 기능을 열었던 주에도 그랬습니다. 장애는 작았는데 로그가 폭증해서 검색이 느려졌고, 정작 원인 이벤트를 찾는 데 시간이 더 걸렸습니다. 비용은 당연히 올랐고요. 그때 팀에서 합의한 질문이 “무엇을 지울까?”가 아니라 “무조건 남겨야 할 신호는 뭔가?”였습니다. 이 관점으로 바꾸고 나서야 샘플링이 단순 절감이 아니라 복구 속도를 지키는 운영 도구가 됐습니다. 샘플링의 목적을 미리 못 박지 않으면, 나중에는 비용팀과 개발팀이 서로 다른 목표로 움직이게 됩니다.

2. 판단 기준: 어떤 이벤트를 100% 보존해야 하는가

샘플링 기준은 핵심 흐름부터 정해야 흔들리지 않습니다. 결제, 로그인, 권한 변경 같은 임계 이벤트는 100% 남기고, 반복 성공 로그는 비율을 줄이는 방식이 기본입니다. 그리고 에러 로그도 “전부 저장”이 정답은 아닙니다. 같은 스택트레이스가 수만 건 쏟아지면 중요한 신호가 묻힙니다. 이때는 대표 샘플과 해시 기반 집계를 같이 쓰는 편이 실무에서 훨씬 낫습니다. 기준을 세울 때는 항상 한 문장으로 확인합니다. “이 로그가 없어지면 어떤 장애를 못 푸나?” 이 질문에 답이 안 나오면 저장 우선순위를 낮춰도 됩니다.

3. 실행 절차: 결정적 샘플링과 임계 이벤트 보존

실행은 복잡하게 갈 필요가 없습니다. request_id나 user_id 해시를 기준으로 남길지 말지를 결정하는 결정적 샘플링이 가장 다루기 쉽습니다. 이렇게 해야 같은 사용자 흐름을 다시 추적할 수 있습니다. 여기에 임계 이벤트 예외 규칙을 붙입니다. 결제 실패, 권한 오류, 무결성 위반은 샘플링을 무시하고 전량 저장합니다. 구현도 shouldLog() 하나로 충분합니다. 이벤트 타입, 해시 값, 현재 샘플링 비율을 받아 판단하게 만들면 운영자가 이해하기 쉽습니다. 비율은 환경 변수로 빼 두고 피크 시간에 조정하세요. 단, 적용 후 검증 없이 넘어가면 안 됩니다. 로그량만 줄고 복구 시간이 늘면 실패한 샘플링입니다.

4. 운영 체크리스트와 주의사항

운영에서는 “변경 이력 기록”이 생각보다 중요합니다. 샘플링 비율을 바꿨는데 기록이 없으면 회고 때 모두 기억에 의존하게 됩니다. 그래서 저희는 비율, 적용 시점, 사유를 릴리스 노트처럼 남깁니다. 새 기능 출시 주간에는 비율을 일시 상향하고 안정화 후 다시 내립니다. 개인정보 마스킹은 샘플링 이전 단계에서 먼저 적용해야 하고요. 대시보드에는 보정 계수를 표시해 숫자 해석이 흔들리지 않게 했습니다. 결론적으로 샘플링의 품질은 알고리즘보다 운영 습관에서 갈립니다. 팀이 주간 리뷰를 꾸준히 하면 비용도 잡고, 장애 때 필요한 근거도 놓치지 않습니다.