Wide Events는 JSON 로그와 무엇이 다를까?

로그 한 줄의 형식보다, 한 요청의 정보가 모여 있는지가 중요하다

JSON 로그를 이미 쓰고 있어도 오류 결과, 앱 버전, 기능 설정이 서로 다른 줄에 흩어져 있을 수 있다. Wide Events는 이 정보를 요청 같은 작업 단위로 모아, 한 기록 안의 필드만으로 여러 조건을 조회할 수 있게 하는 접근이다. JSON은 그 기록을 표현하는 방법 중 하나다.

최근 Hacker News에 다시 등장한 Ivan Burmistrov의 2024년 글은 로그·지표·트레이스를 구분하는 설명보다, 풍부한 이벤트를 여러 조건으로 탐색하는 경험을 강조한다. 새 규격의 출시 소식이 아니라 시스템을 어떻게 기록하고 조사할지에 관한 논의다.

Stripe의 canonical log line 사례에서는 요청이 끝날 때 핵심 정보를 모은 기록을 기존 로그와 함께 남긴다. 제한에 걸렸다는 로그와 사용자를 식별하는 로그가 따로 있으면 둘을 먼저 연결해야 한다. 같은 기록에 있으면 ‘누가 제한에 걸렸는가’를 곧바로 집계할 수 있다.

‘오류가 늘었다’에서 ‘어떤 조건에서 늘었나’로 이동한다

앱 버전과 오류가 같은 이벤트에 있으면 버전별로 묶고, 문제가 있는 버전만 고른 뒤 다른 조건을 살펴볼 수 있다. 전체 오류 수를 보는 데서 멈추지 않고 조사 대상을 줄여 가는 것이다.

다음은 결제 요청에 적용한 가상 예시다. 실제 장애 데이터나 필수 필드 목록은 아니며, 각 값이 같은 요청에 속한다는 점이 핵심이다.

Burmistrov가 든 광고 노출 예시도 캠페인 종류, 운영체제, OS 버전으로 조건을 좁힌다. 그 조합을 미리 예상해 지표를 만들어 놓지 않았더라도 이벤트에 맥락이 남아 있으면 조사에 쓸 수 있다는 주장이다. 특정 조합에서 문제가 보인다는 사실은 원인을 확정하는 결론이 아니라 다음 조사 대상을 찾는 단서다.

OpenTelemetry를 버릴 필요 없이 span에 맥락을 더할 수 있다

OpenTelemetry의 span은 한 작업을 나타내며 키와 값으로 된 속성을 담을 수 있다. trace ID와 span ID는 관련 작업을 연결하는 데 쓰인다. 여기에 버전이나 기능 적용 여부처럼 조사에 필요한 속성을 더하면 기존 계측에서도 Wide Events 방식을 활용할 수 있다.

Jeremy Morrell의 실무 가이드는 요청을 감싸는 span을 보관하고 처리 과정에서 정보를 추가하는 방식을 제시한다. 하위 span이 생기면 현재 활성 span이 달라질 수 있으므로, 대표 기록으로 정한 span을 일관되게 찾아야 한다. 가이드의 main 표시는 저자가 택한 관례다.

자동 계측은 회사의 새 요금제나 실험 기능이 무엇인지 알지 못한다. 어떤 업무 조건을 속성으로 남길지는 애플리케이션 개발자가 정해야 한다. 도구를 설치한 일과 조사에 필요한 기록을 갖춘 일은 그 지점에서 갈린다.

한 요청의 대표 기록을 만들되, 다른 기록까지 없애지는 않는다

대표 이벤트 하나를 둔다는 말은 세부 로그와 하위 span을 모두 지우라는 뜻이 아니다. Stripe도 기존 로그에 대표 기록을 더한다. 전체 요청의 결과에서 세부 실행 흐름으로 이동할 수 있도록 둘을 연결하는 편이 이 방식의 목적에 맞는다.

수집량도 함께 결정해야 한다. Morrell은 모든 요청을 저장하는 비용이 커질 때 샘플링을 고려한다. OpenTelemetry의 민감 데이터 지침은 관측 목적에 필요한 값만 수집하도록 권한다. 맥락을 넓힌다는 이유로 비밀번호나 세션 토큰까지 기록할 필요는 없다.

적용을 시작할 때는 오류를 자주 조사하는 요청 하나의 기록부터 읽어 볼 수 있다. 결과와 버전, 기능 적용 여부가 같은 작업의 정보로 묶여 있는지 살피고, 흩어진 맥락을 모은다. 이미 그 조건으로 조회할 수 있다면, 이름을 바꾸기 위해 로깅 시스템을 새로 만들 필요는 없다.