이벤트 설계와 데이터 품질

이벤트(event)는 정해진 조건에서 발생한 사건의 기록이다. 사건 이름과 함께 발생 시각, 대상, 상태, 버전 등의 속성을 저장할 수 있다. ‘회고 완료’라는 이름만으로는 버튼 클릭인지, 입력 조건 통과인지, 서버 저장 확정인지 알 수 없다. 이벤트 명세에는 이름뿐 아니라 발생 조건과 발생시키지 않아야 하는 조건도 적는다.

주간회고의 저장 과정은 ‘작성 시작 → 저장 요청 → 서버 처리 → 결과 안내’로 나눌 수 있다. 이 중 저장 요청은 사용자의 의도를 나타내고, 서버 확정은 시스템에 내용이 보존된 결과를 나타낸다. 사용자에게 완료 상태가 보였는지는 또 다른 기록이다. 세 사건은 같은 과업 안에서 연결되지만 같은 뜻은 아니다.

03장의 일간 회고 저장 계정 수에는 서버 저장 확정을 사용한다. 저장 버튼 클릭을 함께 수집한다면 요청 후 실패하거나 기다린 과정을 진단하는 용도로 구분한다. 완료 안내 이벤트는 저장 결과와 화면 상태가 일치하는지 검토하는 데 사용할 수 있다. 명칭이 비슷하다는 이유로 이 기록들을 하나의 완료 지표에 넣으면 의미가 섞인다.

이처럼 이벤트를 나누는 목적은 모든 동작을 기록하기 위해서가 아니다. 이번 프로젝트의 의사결정에 필요한 상태를 구별하려는 것이다. 화면의 모든 클릭을 수집해도 저장 성공과 실패를 구분할 속성이 없다면 핵심 질문에 답하기 어렵다. 서버 저장만 기록하면 저장 처리의 성공은 확인할 수 있다. 사용자가 필요한 내용을 완성하고 활용했는지, 저장 전에 왜 중단했는지는 별도 자료로 확인해야 한다.

상태 변화에서 발생 조건 정하기

이벤트를 정의하기 전에 해당 기능의 상태를 정리하면 누락과 중복을 검토하기 쉽다. 주간회고의 작성 시도는 작성 중, 저장 요청 중, 저장 확정, 복구 가능한 실패, 사용자 취소 등으로 구분할 수 있다. 이것은 교재가 제안하는 예시 상태이며 실제 서비스가 반드시 같은 상태 이름을 사용해야 한다는 뜻은 아니다.

이 표는 화면 설계와 분석 설계가 공유할 수 있다. 저장 요청 중에 완료 화면을 보여주면 사용자 안내와 실제 보존 상태가 어긋날 수 있다. 실패를 표시하더라도 작성 내용을 유지하면 사용자는 같은 과업을 이어갈 수 있다. 분석에서는 이를 새 사용자나 새 회고가 발생한 것으로 오해하지 않도록 상태와 식별자를 연결한다.

사건의 발생 지점은 해당 사실을 확인할 수 있는 위치로 정한다. 버튼을 눌렀다는 사실은 화면에서 알 수 있고, 서버 저장 확정은 저장 처리 결과를 통해 알 수 있다. 사용자가 안내를 이해했다는 사실은 단순 노출 기록만으로 판정하기 어렵다. 따라서 이벤트 명세에서 ‘이해 완료’처럼 확인 방법이 불분명한 이름을 사용하는 대신 관찰 가능한 사건을 기록하고, 이해 여부는 과업 평가와 연결한다.

어떤 것을 같은 대상으로 처리할지 결정하려면 식별자가 필요하다. 주간회고에서는 계정, 작성 시도, 회고 문서, 사건, 전송 기록을 구분한다. 하나의 계정이 여러 회고를 작성할 수 있고, 하나의 작성 시도에서 저장 요청을 여러 번 보낼 수 있으며, 하나의 저장 확정 사건이 여러 번 전송될 수 있다.

이 명칭은 교재의 예시 규약이며 업계 공통 표준으로 가정하지 않는다. 도구마다 중복 제거 범위와 키의 의미가 다르므로 실제 구현에서 확인해야 한다. 특히 전송할 때마다 새로운 event_id를 만들면 동일 사건의 재전송을 알아보기 어렵다. 반대로 계정 식별자로 중복을 제거하면 한 사용자가 여러 번 정상적으로 완료한 사건까지 사라진다.

회고 문서가 수정 가능한 경우 review_id만으로 저장 이벤트를 중복 제거해서도 안 된다. 같은 문서의 첫 저장과 다음 날 수정 저장은 서로 다른 사건이다. 서비스가 최초 생성만 셀 것인지 모든 유효한 저장을 셀 것인지 정의하고, 필요한 경우 operation=create/update 또는 문서 버전을 남긴다. 이 장의 자료 T는 각 시도에서 문서를 처음 저장하는 경우만 포함한다.

작성 시도의 경계는 사용 흐름과 함께 정한다. 일시적인 화면 이동이나 통신 재시도는 같은 시도로 이어질 수 있다. 사용자가 취소한 뒤 새 회고를 시작하면 다른 시도로 처리할 수 있다. 일정 시간 이후 자동 종료하는 규칙을 둔다면 그 기준도 명세에 기록한다. 시간 초과는 시스템의 분류 규칙이며 사용자의 포기 의도를 직접 관찰한 결과는 아니다.

로그인 이전 기록과 이후 계정을 연결할 때도 같은 원칙이 적용된다. 확인 가능한 로그인 연결을 사용할 수 있지만, 공용 기기의 모든 과거 활동을 현재 로그인한 사람에게 붙이면 다른 사람의 기록이 섞일 수 있다. 확인되지 않은 연결은 미확인 상태로 남기고 분석 범위를 밝힌다. 로그인 이용자만으로 계산한 지표를 모든 방문자의 결과로 확대해서는 안 된다.

재시도와 재전송을 구별하는 예

재시도는 사용자가 진행하려는 과업의 처리 작업을 다시 수행하는 것이고, 재전송은 이미 발생한 사건의 기록을 분석 시스템에 다시 전달하는 것이다. 저장 처리에 실패한 뒤 사용자가 다시 저장을 요청하면 실제 요청이 추가로 발생한다. 이미 저장이 성공한 뒤 같은 확정 기록을 다시 전달하면 새로운 저장이 발생한 것은 아니다. 두 상황은 모두 여러 행을 만들 수 있지만 중복 제거 기준은 다르다.

주간회고에서 같은 작성 시도를 유지하며 저장 요청을 다시 보냈다면 attempt_id는 유지할 수 있다. 각 요청을 구별해야 한다면 별도의 요청 식별자를 둔다. 반면 저장 확정 사건 e01의 전달을 재시도하는 경우에는 같은 event_id를 유지한다. 시도 식별자만으로 모든 요청을 하나로 줄이면 실패 후 복구 과정을 볼 수 없고, 전달 식별자로 완료를 세면 전송 횟수가 성과에 섞인다.

처리 결과가 불명확한 상황도 있다. 사용자의 화면에는 응답이 오지 않았지만 서버에는 이미 저장되었을 수 있다. 이때 같은 내용을 다시 보내면 중복 문서가 생성되는지, 기존 결과를 확인하여 같은 문서를 반환하는지 서비스 동작을 정해야 한다. 분석상의 중복 제거만으로 실제 중복 문서 생성을 해결할 수는 없다. 구현 검수와 지표 검수가 서로 다른 층위를 다룬다는 점을 명세에 반영한다.

작성 시도가 며칠에 걸쳐 이어지는 서비스라면 과업의 경계도 다시 검토한다. 화면을 닫는 순간마다 새로운 시도로 나누면 이어 쓰기를 실패 후 신규 시작으로 분류할 수 있다. 반대로 모든 수정을 하나의 시도로 묶으면 이후의 별도 작업을 구분하기 어렵다. 작성 목적, 저장 문서, 종료 조건을 바탕으로 연결 규칙을 정하고 대표적인 이어 쓰기 사례를 검수 자료로 남긴다.

수집 품질 지표의 이름과 분모

포착률은 기준 원장에 존재하는 적격 사건 중 분석 저장소에서 대응 기록을 찾은 사건의 비율이다. 기준 원장 자체가 불완전하면 전체 현실에 대한 포착률이라고 주장할 수 없다. 중복률은 고유 사건 외에 중복 전송된 기록의 비율 등으로 정의할 수 있지만, 사건 기준과 전송 행 기준은 분모가 다르므로 산식을 붙여 적는다. 수집 지연은 사건 발생부터 정한 저장·분석 가능 시점까지의 경과 시간이다. 평균만으로 늦게 도착한 꼬리를 숨기지 않도록 분포도 확인한다.

이 세 항목은 수집 과정의 상태다. 포착률이 높고 중복이 없더라도 해당 사건이 과업 성공을 뜻하는지는 별도 검토해야 한다. 02장의 관찰 신호와 의미 구분을 이벤트 명세에도 적용한다.

분석에 쓰는 사건에는 최소한 두 시간 관점이 있다. 발생 시각은 사건이 원천에서 일어난 시각이고, 수신 시각은 분석 수집 계층에서 해당 기록을 받은 시각이다. 서비스의 이용 날짜와 수집 지연을 함께 판단하려면 이 차이를 보존하는 것이 좋다.

이 구분은 제품 분석에만 있는 아이디어가 아니다. OpenTelemetry의 로그 데이터 모델도 사건 발생의 Timestamp와 수집 계층 관찰의 ObservedTimestamp를 구분한다. 여기서는 동일한 시간 구분의 필요성을 참고하며, 교재의 이벤트 스키마가 해당 사양을 구현했다고 주장하지 않는다. 제품 행동과 시스템 관측은 관리 대상과 수집 조건이 다를 수 있다. 공식 사양 · S42

주간회고의 이용 지표는 Asia/Seoul에서 발생한 날짜에 배정한다. 9월 1일 정오에 저장되었지만 9월 2일 오전에 도착한 사건은 9월 1일의 이용에 포함된다. 다만 9월 2일 00:00에 자료를 마감하면 그 사건은 아직 보이지 않는다. 보고서를 재집계할 때 값이 달라지는 이유를 설명하려면 발생 기간과 수신 마감을 모두 남겨야 한다.

클라이언트의 시계가 부정확할 수 있다는 점도 고려한다. 서버가 확정한 저장은 서버 처리 시각을 기준으로 삼을 수 있지만, 오프라인 작성의 실제 시작은 다르게 다뤄야 할 수 있다. 시각을 보정한다면 원래 값과 보정 규칙을 보존하고, 시간이 불명확한 사건을 임의로 정상 순서에 끼워 넣지 않는다. 어느 정도의 지연을 허용하고 언제 수치를 확정할지는 실제 수집 지연 분포와 보고 목적을 보고 결정한다.

잠정 수치와 재집계의 관리

운영 회의에서 당일 수치가 필요하다면 지연 기록이 모두 도착할 때까지 기다리기 어려울 수 있다. 이 경우 잠정 수치를 제공하고, 어느 시점의 수신 자료를 반영했는지 표시할 수 있다. 이후 더 늦게 도착한 사건을 포함하여 재집계하면 변경된 기간과 차이의 원인을 남긴다. ‘확정’이라는 표시는 데이터가 더 이상 바뀔 가능성이 전혀 없다는 뜻인지, 정해진 운영 마감 이후에는 별도 수정 절차를 따른다는 뜻인지 명확해야 한다.

자료 T에서 발생일은 9월 1일로 고정되어 있지만 초기 마감과 다음 날 마감의 포착 수는 다르다. 사용자가 뒤늦게 저장한 것이 아니라, 이미 발생한 저장 기록이 뒤늦게 도착한 것이다. 보고서에서 발생 시각을 사용하면 이용 날짜는 유지하고 과거 값만 수정한다. 수신 시각으로 이용 날짜를 배정하면 9월 2일에 새로운 이용이 생긴 것처럼 보일 수 있다.

지연 분포를 볼 때에는 정상적으로 도착한 기록만으로 영구 누락의 규모를 알 수 없다는 점도 고려한다. 수신된 사건의 평균 지연이 짧아도 빠진 사건이 남아 있을 수 있다. 지연은 두 시각의 차이로 확인하고, 누락은 별도의 기준 자료와 대조한다. 하나의 품질 지표로 두 문제를 동시에 해결했다고 처리하지 않는다.

자료 T에는 다섯 계정의 작성 시도가 하나씩 있다. 세 시도는 실제로 저장되었고, 한 시도는 서버 처리에 실패했으며, 나머지 하나는 저장 전에 취소되었다. 비교 기준이 되는 저장 원장은 예제에서 실제 보존 상태를 알고 있다고 가정한 자료다. 실제 프로젝트에서는 원장 자체의 범위와 삭제·수정 이력도 검토해야 한다.

9월 2일 00:00 이전에 받은 행은 a01의 두 행과 a02의 구버전 행, 총 세 행이다. 이를 모두 완료로 세면 우연히 실제 저장 세 건과 같아진다. 하지만 기록에 나타난 대상은 실제 저장 대상과 다르다. 잘못 포함된 것과 빠진 것이 상쇄되었기 때문이다. 총합이 일치한다는 이유만으로 계측을 통과시키지 말고 동일한 시도 또는 문서 단위로 대조해야 한다.

구버전 사건을 제외하고 같은 event_id의 중복을 제거하면 초기 보고서에서 확인되는 유효 저장은 a01의 한 건이다. 다음 날의 자료 마감에는 a03의 지연 기록이 추가되어 두 건이 된다. a04는 여전히 빠져 있다. 같은 기간의 실제 저장 세 건과 대조하면 초기 포착률은 1/3 ≈ 33.3%, 다음 날 마감에서는 2/3 ≈ 66.7%다. 이 값은 자료 T의 수집 상태를 나타내며 사용자의 과업 성공률이 아니다.

실제 저장 성공률은 다섯 시도 중 세 번이므로 60%다. 이를 수신된 유효 이벤트 두 건만으로 계산하면 40%가 되며, 사용자 실패와 기록 누락이 섞인다. 누락이 임의로 발생한다고 볼 근거도 없다. 특정 앱 버전이나 통신 환경에서 주로 빠진다면 관찰된 이용자만의 결과는 그 집단을 과소대표할 수 있다.

누락된 사건을 원장으로 복구할 때는 새로 수신한 실제 이벤트처럼 위장하지 않는다. 복구 근거, 복구 시각, 대상 기간, 처리 버전을 남기고, 원천에 없는 사용자 행동을 추정해 채우지 않는다. 원장에는 저장 성공만 있고 사용자가 확인 화면을 보았는지는 없다면, 저장 수는 복원해도 안내 노출 수는 복원할 수 없다.

원본에서 집계 대상까지의 처리 기록

자료 T를 검수하는 사람은 원본 행, 해석된 사건, 집계 대상을 순서대로 대조할 수 있어야 한다. 원본 단계에서는 무엇이 도착했는지를 그대로 확인한다. 해석 단계에서는 스키마 버전과 발생 조건에 따라 어떤 사건인지 구분한다. 집계 단계에서는 인정 사건과 중복 기준을 적용한다. 아래 표는 초기 수신 세 행을 이 순서로 처리한 예다.

이후 d04로 e03이 도착하면 실제 발생일에 맞춰 추가한다. r04는 원장에 있지만 분석 사건이 없어 불일치 목록에 남는다. a05는 저장 전에 취소되었으므로 저장 사건이 없는 것이 정상이다. 기록이 없다는 현상은 a04와 a05에서 같지만, 기준 상태를 대조하면 누락과 정상적인 미발생을 구분할 수 있다.

수집된 기록을 정제할 때에는 어떤 규칙으로 제외했는지 확인할 수 있어야 한다. 중복, 정의 불일치, 직원 계정, 필수 값 결측을 모두 ‘필터링’이라는 한 항목으로 합치면 이상이 발생했을 때 원인을 찾기 어렵다. 원본 행을 분석상 집계에서 제외하는 것과 원본 자체를 삭제하는 것도 구분한다. 실제 보관 범위는 서비스의 운영 정책에 맞추되, 검수에 필요한 처리 이력은 설계에 포함한다.

원장을 사용할 때는 그 자료의 시점도 맞춘다. 과거에 저장된 뒤 현재 삭제된 회고가 있다고 가정하면, 현재 남아 있는 문서만 조회한 목록은 과거 저장 사건 전체와 다를 수 있다. 비교 기준은 ‘현재 존재하는 회고’인지 ‘그 기간에 성공한 저장’인지 명확해야 한다. 자료 T는 이 차이를 없애고 저장 이력이 모두 알려진 예제지만, 실제 대조에서 같은 가정을 무심코 적용해서는 안 된다.

이 대조의 결과를 제품 성과와 함께 보고할 때에는 구분된 문장을 사용한다. ‘다섯 시도 중 세 건이 저장되었고, 그중 두 건의 분석 기록을 다음 날 마감까지 확인했다’고 쓰면 처리 결과와 포착 상태가 드러난다. ‘완료율 40%’라는 한 줄은 기록 누락을 실제 실패로 섞어 해석하게 만들 수 있다.

이벤트 명세의 핵심은 발생 조건, 필수 속성, 제외 조건, 검수 사례다. 아래 예시는 review_saved에 대한 것으로, 저장 여부를 판정하는 조건을 기술과 업무 양쪽에서 확인할 수 있게 작성한다.

‘서버 측에서 보내면 누락되지 않는다’고 가정할 수는 없다. 저장 처리와 분석 전송은 다른 작업이므로 그 사이에서 실패할 수 있다. 저장된 결과와 전달 상태를 대조하여 재시도하거나 누락을 감지하는 설계가 필요하다. 구체적인 구현 방식은 서비스 구조에 따라 결정하되, PM은 실제 저장과 분석 포착의 대조가 가능한지 인수 기준에 포함한다.

수집 속성은 사용할 질문이 있어야 한다. 앱 버전은 배포별 누락을 점검하는 데 도움이 되고, 환경 구분은 검수 기록이 실사용 집계에 섞이는 것을 막는다. 회고 내용 전체는 저장 성공을 세는 데 필요하지 않다. 원문 분석이 별도 연구에 필요하다면 그 목적과 접근·보관 범위를 따로 설계한다. 수집 가능한 모든 정보를 기본값으로 추가하는 방식은 명세를 복잡하게 하고 불필요한 데이터 취급을 늘린다.

수집이 허용되지 않거나 기술적으로 관찰할 수 없는 범위는 별도 상태로 관리한다. 분석 기록이 없다는 사실을 이용하지 않았다는 사실로 바꾸면 안 된다. 관찰 가능한 집단의 범위와 빠진 경로를 지표 정의서에 반영하고, 필요한 경우 제한된 집단의 결과로 보고한다.

필수 속성의 의미와 빠진 값의 처리

필수 속성을 적는 것만으로 명세가 완성되지는 않는다. 값의 형식, 허용 범위, 누락되었을 때의 처리도 정해야 한다. operation이 생성과 수정을 구별한다면 허용 값과 두 값의 발생 조건을 적는다. app_version이 비어 있을 때 이를 최신 버전으로 간주하면 안 된다. ‘확인되지 않음’으로 보존하고 그 규모를 점검해야 버전별 분석의 범위를 알 수 있다.

속성의 현재 값과 사건 당시 값도 구분한다. 계정이 나중에 유료로 전환되었다고 해서 과거 무료 이용의 모든 사건을 유료 이용으로 분류하면 과거 보고서가 달라질 수 있다. 지표가 사건 당시 이용 조건을 묻는지 현재 고객의 과거 행동을 묻는지에 따라 필요한 자료가 다르다. 정의서에서 정한 질문을 기준으로 어느 시점의 속성을 사용할지 합의한다.

이벤트 명세에는 대표 예시 한 건과 인정하지 않는 예시를 함께 붙이는 편이 좋다. 형식은 같아도 서버 실패를 저장 확정으로 보내는 오류가 있을 수 있기 때문이다. 올바른 자료의 모양을 확인하는 검수와 실제 동작에서 올바른 사건이 발생하는지 확인하는 검수를 함께 수행한다.

인수 기준은 ‘이벤트가 도착한다’보다 구체적이어야 한다. 같은 시나리오를 실행했을 때 원장과 분석 기록의 관계가 어떻게 나타나야 하는지 정한다. 오류 상황도 정상 시나리오와 같은 비중으로 포함한다.

검수에서 품질을 볼 때는 정확성, 완전성, 적시성, 의미의 일관성을 나누어 기록할 수 있다. 잘못된 저장을 포함하는 문제는 정확성, 실제 저장이 빠지는 문제는 완전성, 늦게 도착하는 문제는 적시성과 관련된다. 이름이 같아도 버전별 의미가 달라지는 문제는 해석의 일관성과 관련된다. 여기서의 구분은 검수 업무를 정리하기 위한 교재의 분류다.

자동 점검에는 필수 식별자 누락, 허용하지 않은 버전, 중복 급증, 수신 지연 증가, 저장 원장 대비 포착 변화 등을 넣을 수 있다. 임계값은 예제의 66.7% 같은 수치를 그대로 가져오지 않고 서비스의 정상 범위와 업무 위험을 보고 정한다. 신규 배포 직후 특정 운영체제에서만 지표가 급감하면 제품 경험의 변화와 계측 오류를 함께 확인한다.

검수 결과는 ‘성공’ 한 줄보다 대상 버전, 실행 조건, 확인 시각, 차이 목록, 담당자와 남은 범위로 기록하는 편이 좋다. 분석 오류 때문에 지표를 쓸 수 없는 기간에는 보고서에도 그 상태를 표시한다. 수치를 숨기는 대신 현재 무엇을 알 수 있고 무엇을 비교할 수 없는지 명확히 한다.

출시 이후 지표가 급감했을 때의 점검 순서

새 버전 배포 뒤 회고 저장 계정 수가 줄었다면 곧바로 사용성 악화로 결론 내리지 않는다. 먼저 같은 기간의 원장 저장이 줄었는지, 분석 포착만 줄었는지 대조한다. 원장 결과는 유지되는데 분석 수치만 줄었다면 수집 경로를 우선 점검한다. 둘 다 줄었다면 실제 기능 문제나 이용 변화, 대상 구성 변화 등을 검토할 필요가 있다.

그다음 배포 버전·기기·경로별로 차이를 확인한다. 특정 버전에서만 필수 식별자가 빠지면 계정 집계가 줄어들 수 있다. 특정 화면을 거치는 사용자만 기록된다면 전체 수치의 변화에 경로 구성도 영향을 줄 수 있다. 이때 세분 집단의 표본 수와 관찰 범위를 함께 보고, 작은 집단의 큰 비율 변화만으로 범위를 확정하지 않는다.

프로젝트 기록에는 발견 시각, 영향을 받은 지표와 기간, 현재 확인된 사실, 임시 보고 방식, 복구 담당, 재집계 계획을 남긴다. 수집 장애 기간에도 제품 이용이 실제로 이루어졌을 수 있으므로 사용자 성과를 0으로 처리하지 않는다. 복구가 끝나면 어떤 사실을 복원했고 어떤 범위는 여전히 알 수 없는지 보고한다.

역할은 조직 규모에 따라 한 사람이 겸할 수 있다. 중요한 것은 이상 발견 이후의 책임이 ‘데이터 팀 확인 중’에 머물지 않도록 결과물과 종료 조건을 정하는 것이다.

이벤트 스키마 버전과 지표 정의 버전은 별도다. 앱 버전 속성을 추가해도 저장 사건의 의미는 유지될 수 있다. 반면 같은 이벤트를 사용하면서 집계 대상을 유료 계정으로 제한하면 지표 정의가 바뀐다. 사건의 의미가 바뀌었는지, 기록 구조만 바뀌었는지, 집계 기준이 바뀌었는지 구분하여 변경 이력을 남긴다.

자료 T의 구버전 review_completed는 클릭을 기록하고 신버전 review_saved는 서버 확정을 기록한다. 두 기록을 같은 완료 시계열로 합치면 전후 비교가 성립하지 않는다. 전환 기간에 두 사건과 원장 결과를 동시에 확인할 수 있다면 차이를 설명할 자료를 확보할 수 있다. 구버전에 저장 결과가 없으면 과거 클릭 수에서 정확한 저장 수를 복원할 수는 없다.

이벤트 명세와 지표 정의서는 출시 이후에도 갱신한다. 새로운 로그인 방식, 저장 구조, 동의 상태, 지원 기기가 추가되면 관찰 범위가 달라질 수 있다. 프로젝트 종료 시점에는 구현물뿐 아니라 최신 명세, 검수 기록, 운영 점검 담당, 변경 절차까지 인계해야 이후의 지표 비교가 유지된다.

병행 관찰과 과거 자료의 연결

새 정의를 도입할 때에는 가능하면 일정 기간 같은 실제 동작에 대해 종전 기록과 새 기록을 함께 확인한다. 목적은 두 값을 하나로 맞추는 데 있지 않다. 종전 정의가 포함하던 행동과 새 정의가 포함하는 결과의 차이를 설명하려는 것이다. 클릭과 서버 저장의 차이를 확인하면 정의 변경 이후의 수치 변화 중 어떤 부분이 측정 기준에서 발생하는지 검토할 수 있다.

병행 기간의 평균 차이를 과거 모든 기간에 일괄 적용하는 방법은 별도의 가정을 요구한다. 실패 비율, 사용자 구성, 기기 환경이 과거에도 같았는지 확인되지 않으면 정확한 환산이라고 부를 수 없다. 과거 원장으로 다시 계산할 수 있는 범위는 실제 재집계로 구분하고, 비율을 적용한 추정은 추정이라는 표지를 남긴다. 검토 근거가 없다면 정의 변경 경계를 표시한 채 두 시계열을 나누어 제공하는 편이 적절하다.

배포가 끝난 뒤에는 지표 정의서, 이벤트 명세, 실제 집계, 검수 표본이 같은 버전을 가리키는지 확인한다. 문서만 수정하고 대시보드 계산이 그대로 남거나, 새 이벤트가 도착하지만 제외 규칙 때문에 집계되지 않는 경우를 점검하는 절차다. 이후 변경 요청에도 같은 검토를 적용할 수 있도록 담당과 문서 위치를 인계한다.

1. 저장 버튼 클릭, 서버 저장 확정, 완료 안내 노출을 구분하여 각각 지원하는 질문을 작성하라.
2. 같은 사건이 두 번 전송될 때 유지되어야 할 식별자와 바뀔 수 있는 식별자를 구분하라. user_id만으로 중복을 제거하면 생기는 문제도 설명하라.
3. 자료 T의 초기 수신 행 세 개가 실제 저장 세 건과 같아도 검수를 통과할 수 없는 이유를 대상 단위로 설명하라.
4. 초기 마감과 다음 날 마감의 유효 저장 수·포착률을 계산하라. 실제 저장 성공률과 구분하라.
5. 누락된 r04를 원장으로 복구할 때 남길 정보를 정하라. 원장만으로 확인 화면 노출까지 복구할 수 있는가.
6. 사건의 필수 속성 추가와 지표 대상 집단 변경을 구분하여, 각각 관리해야 할 버전과 비교 영향을 작성하라.
7. 담당 서비스의 이벤트 하나를 선택하여 발생 조건·제외 조건·식별자·시각·검수 시나리오를 작성하라. 원문 내용 수집 없이도 판단 가능한 질문을 포함하라.
8. 서버에는 저장되었지만 화면에 응답이 오지 않아 사용자가 다시 저장을 요청했다. 실제 처리의 중복 방지와 분석 기록의 중복 제거를 구분하여 검수 항목을 작성하라.
9. 배포 후 저장 계정 수가 감소했다. 원장과 분석 기록을 대조하는 조사 순서, 보고 상태, 복구 종료 기준을 작성하라.

연습문제 해설과 재현 결과에서 계산을 확인할 수 있다. 다음 장에서는 수집된 기록과 과업 관찰을 함께 사용하여 이용 품질을 평가한다.

• S42. OpenTelemetry, Logs Data Model. 공식 사양. 2026-09-17 확인. 발생 시각·관찰 시각 및 필드 의미 설명을 참고했다. 교재의 사건 이름·식별자·스키마는 자체 예제다.
• 이 장의 누락·중복·지연 수치와 세부 인수 기준은 교육용 설계다. 특정 분석 솔루션의 보장 수준이나 업계 벤치마크를 나타내지 않는다. 원자료·계산, 출처 장부를 참조할 수 있다.
• 분산된 기록을 연결하는 문제와 제품 행동 측정은 방법을 공유하지만 모든 제품 이벤트의 단일 역사적 기원을 확정하지 않는다. 실제 도구 도입 시에는 그 도구의 중복 제거 범위·시간 처리·식별 정책을 별도로 검토해야 한다.