이 게시물은 분산 시스템 환경에서 전통적인 로깅 방식의 한계와, Wide Events(또는 Canonical Log Lines)를 통한 효과적인 관찰가능성(Observability) 개선 방안을 다룬다.

원문: Logging Sucks

1. 핵심 문제: “로그가 당신에게 거짓말을 하고 있다”

  • 시대의 변화: 과거의 로깅 방식은 단일 서버(Monolith) 시대에 맞춰 설계됐다. 하지만 현재는 수많은 서비스와 DB, 캐시가 얽힌 분산 시스템이다.
  • 쓰기 위주의 최적화: 개발자들은 로그를 남기기(Write)는 쉽게 하지만, 정작 문제가 생겨 검색(Query)할 때는 수만 줄의 파편화된 로그 속에서 의미 있는 정보를 찾기 매우 어렵다.
  • 맥락 부족: 단순히 “사용자 123의 결제 실패"라는 텍스트 로그만으로는 왜 실패했는지, 당시의 세부 상황(DB 상태, 이전 단계 등)을 파악하기 어렵다.

2. 제안하는 해결책: Wide Events (또는 Canonical Log Lines)

사이트는 파편화된 여러 줄의 로그 대신, 하나의 요청(Request)당 하나의 상세한 이벤트 로그를 남길 것을 권장한다.

  • Wide Event란?: 하나의 요청이 처리되는 동안 발생하는 모든 중요 정보를 하나의 거대한 JSON 객체로 모아 기록하는 방식이다.
  • 고차원/고카디널리티 데이터 포함: 사용자 ID, 세션 ID, 카트 정보, 실행된 쿼리 수, 에러 코드 등 50개 이상의 필드를 포함하여 맥락을 풍부하게 만든다.
  • 장점: “프리미엄 사용자의 결제 실패” 같은 복잡한 질문도 단 한 번의 쿼리로 즉시 답을 얻을 수 있다.

3. 실용적인 로깅 규칙

무조건 모든 로그를 다 남기는 것이 아니라, 효율적인 샘플링 전략을 제안한다.

  • 100% 저장: 모든 에러(5xx), 예외 상황, 그리고 임계값 이상의 느린 요청(p99 latency)은 반드시 저장한다.
  • 특정 대상 지정: VIP 고객이나 사내 테스트 계정의 로그는 항상 유지한다.
  • 나머지는 샘플링: 성공적이고 빠른 일반 요청은 1~5% 정도만 무작위로 추출하여 저장함으로써 비용과 성능을 최적화한다.

결론 및 시사점

한 줄 결론: 로깅을 단순 기록이 아니라 질의 가능한 데이터베이스처럼 다루고, 요청 단위 Wide Event로 맥락을 보존해야 한다.

분산 시스템에서는 파편화된 텍스트 로그보다 구조화된 광범위 이벤트 방식이 관찰가능성을 높인다. 저장 비용은 샘플링으로 조절하되, 장애 진단에 필요한 맥락은 놓치지 않는 균형이 핵심이다.

관련 포스트