Measurement Contract

최소 계측: 저장·업무 완료·반복 사용의 구분

작성일: 2026-09-20. 연결: #297, #289. 기준 main: 9111de74730f0ec3dc240dd807d81eda40ea55d0. 상태: 소스 조사, 이벤트 계약 제안, 합성 계산. 제품 계측 구현·고객 측정은 하지 않았다.

이번 판단

첫 검증은 로컬 관찰 기록과 최소 이벤트로 충분한지 확인한다. 새 분석 서버를 먼저 만들지 않는다. 두 제품을 저장하고 다시 연 행동은 활성화 후보 지표다. 내용이 맞고 업무를 독립적으로 끝냈다는 증거는 별도로 필요하다. 한 제품만 필요한 고객 업무를 실패로 처리하지 않는다.

코드에서 확인한 측정 함정

소스 사실	계측 판단
저장 큐는 충돌한 입력을 별도 초안에 보관한다. pending이 비면 flush()가 true를 반환할 수 있다.	이동 준비 성공을 원본 저장 성공으로 세면 안 된다. committed, conflict_draft, failed를 구분한다.
기존 문서를 열어 모델에 반영한 뒤에도 저장됨 알림이 발생한다.	화면 상태 알림 횟수는 새로운 저장 수가 아니다. 실제 저장 결과와 재열기를 각각 기록한다.
공통 이동은 호스트와 문서 ID의 유지를 검사한다.	이동 버튼 클릭, 저장 완료, 목적지 열기 완료는 다른 단계다. URL 변경만으로 재열기를 확정하지 않는다.
Note는 자체 workspace의 flush를 공통 호스트에 연결한다.	공통 DocumentSession 한 곳에만 계측해도 네 제품이 모두 잡힌다고 가정하지 않는다.
Note→Site는 본문 저장 후 출처 catalog를 쓴다.	본문만 저장된 상태는 전체 변환 성공과 구분한다. #291의 부분 완료 계약을 따른다.
전체 백업 UI는 다운로드 링크를 실행한다.	다운로드 요청을 사용자 디스크 저장·외부 전달·실제 게시 완료로 표시하지 않는다.

근거: 저장 큐, 문서 열기, 공통 이동, Note 호스트, Note→Site, 다운로드.

위 경로는 이전 연구 기준 558714a...와 이번 main 사이의 diff가 없었다. 이번에는 코드만 읽었고 저장 충돌이나 다운로드를 실행하지 않았다.

기존 계측 조사 범위: 이 main의 apps, packages, docs에서 posthog, mixpanel, amplitude, sendBeacon, trackEvent, captureEvent, telemetry, analytics를 검색했다. 찾은 내용은 Site URL 설명·검사 주석이었다. 이 범위에서 재사용할 제품 분석 수집기를 확인하지 못했다. 다른 이름의 구현이나 외부 운영 시스템까지 없다는 결론은 아니다. 구현 착수 시 호스트의 별도 수집기를 다시 확인한다.

업무와 이벤트의 단위

• study_run: 고정된 실험 버전과 실행 빌드. 합성 실행과 고객 실행을 구분한다.
• task_attempt: 한 사람이 한 업무를 시도한 단위. 앱 전환·새로 고침·저장 재시도 때문에 새 업무로 만들지 않는다.
• operation: 저장·변환 같은 논리적 동작. 같은 동작의 재시도는 연결하되, 각각의 시도 번호와 실패를 보존한다.
• event_id: 이벤트 하나의 중복 제거 키. 같은 이벤트를 다시 내보내거나 수집해도 한 번만 센다. 새 재시도를 중복으로 지우지 않는다.
• document_token: 연구 범위 안에서만 쓰는 임의 대응값. 원본 문서 ID·제목·주소를 내보내지 않는다. 여러 제품의 같은 업무를 연결하는 목적이며 전사 사용자 추적 ID가 아니다.

이름은 제안이며 현재 공개 API가 아니다. 업무 시작은 연구자가 과제를 시작하거나 사용자가 명시적으로 업무를 시작한 때로 둔다. 제품을 열었다는 이유로 새 업무를 자동 추정하지 않는다. 업무 맥락은 #290의 프로젝트 구현 없이도 연구 기록으로 유지할 수 있다.

최소 이벤트 사전 제안

이벤트	성립 시점	실패·취소 처리
업무 시작·종료	고정 과제 시작, 완료·중단 판정	독립 완료 / 도움받아 완료 / 기술 실패 / 취소 / 기록 불명 구분
결과물 저장 결과	실제 저장 시도 결과가 확정됨	원본 저장 / 충돌 초안 / 저장 실패 구분. 자동 빈 문서 생성만으로 결과물 완성 처리하지 않음
결과물 재열기 결과	저장한 대상 ID·revision을 읽어 제품에 적용함	다른 문서·더 오래된 revision·누락·읽기 실패 구분. 세션마다 첫 화면을 모두 재열기로 세지 않음
변환 계획 결과·선택	미리보기 결과와 수락·거절 확정	미지원 거절, 사용자 취소, 입력 변경으로 재확인, 부분 저장을 구분
원본 상태 확인	#291의 비교가 실제 끝남	같음 / 변경됨 / 버전 미상 / 사용 불가. 확인 버튼 클릭과 구분
내보내기 요청·생성 결과	제품별로 실제 관찰 가능한 경계	브라우저 다운로드 요청까지이면 그 수준만 기록. 외부 전달 완료로 승격하지 않음

변환 계획·원본 상태 기능은 아직 제안 범위다. 존재하지 않는 기능의 이벤트를 임의로 발생시키지 않는다. 현재 생성 경로와 향후 갱신 경로를 같은 성공 이름으로 뭉치지 않는다.

관찰자가 별도로 기록할 내용: 과제 필수 내용 일치, 도움 여부, 오류 이후 회복, 새로운 실제 업무인지 여부, 사용자가 예상한 참조·사본 동작. 본문을 수집하지 않고 항목 코드와 통과/불일치/검사 불가를 기록한다. 단순 클릭 기록으로 이 판단을 대체하지 않는다.

산식과 분모

지표	정의	해석 제한
두 제품 활성화 후보	같은 업무에서 필요한 두 제품 각각에 결과물을 저장한 뒤 해당 저장본을 다시 연 업무 수 / 두 제품 과제를 시작한 업무 수	도움 여부는 별도. 기존 샘플을 열기만 한 경우 제외. 고객 효용·지불 의사 아님.
독립 업무 완료	필수 내용·저장·재열기 확인을 통과하고 조작 도움 없이 완료한 수 / 시작한 수	실패·취소·도움 실행도 분모에 남김. #289의 참여자 단위와 업무 단위를 섞지 않음.
작업 시간	과제 시작부터 내용 확인을 포함한 종료까지의 경과 시간	제품 전환·저장·실패 후 회복 포함. 미완료는 제한 시간과 상태를 기록하고 성공 시간처럼 평균 내지 않음.
기술 실패·취소	각각 해당 종료 상태의 업무 수 / 시작한 업무 수	중간 저장 실패 뒤 회복한 업무는 최종 실패와 구분. 중간 시도 실패 수도 별도로 보존.
원본 변경 후 불일치	미리 정한 확인 위치에서 틀린 항목 수 / 같은 과제의 확인 대상 항목 수	자동 source revision 변화와 내용 불일치는 다름. 검사 불가 수를 별도 보고하며 0건으로 채우지 않음.
후속 업무 재사용	후속 7~14일에 다른 실제 업무의 결과물을 저장·재열기한 참여자 수 / 후속 관찰 대상 참여자 수	실제 참여·측정 계획 확정 필요. 단순 재방문·재시도·같은 과제 반복 제외. 무응답은 미확인으로 함께 보고.

반복 사용의 전체 대상 대비 확인 비율과 응답자 내 비율은 분모 이름을 달리 쓴다. 무응답자를 확인된 미사용자로 바꾸지 않는다. 같은 사람이 여러 번 실행한 과제를 여러 사람의 성공으로 세지 않는다. 기존 #289의 4/5·30%는 검토할 가설이며 이 문서에서 변경하거나 확정하지 않는다.

새로 고침·재시도·누락

새로 고침 뒤 같은 업무·동작 ID를 복원할 수 있어야 한다. 복원하지 못하면 별도 불완전 기록으로 표시한다. 이전 시작과 새 종료를 추측으로 합치지 않는다. 종료 이벤트가 없다는 이유만으로 취소나 실패를 확정하지 않는다.

시간은 각 화면 내 경과 시간과 관찰 기록을 우선한다. 여러 페이지의 단조 시계 값을 그대로 빼지 않는다. 화면 사이 구간은 별도 연결 근거가 필요하다. 시계 변경·탭 중단으로 시간이 불명확하면 시간 비교에서 제외한 이유와 수를 남긴다. 첫 소규모 실험은 연구자의 전체 시간 기록을 기준으로 삼을 수 있다.

단일 결과물의 잦은 자동 저장은 업무 완료 수를 늘리지 않는다. 활성화 계산은 필요한 제품·결과물별 저장→재열기 증거를 한 번씩 인정한다. 충돌 초안은 별도 결과물로 복구·저장·재열기와 내용 확인을 마친 경우에만 과제 결과로 재평가한다. 원본에 저장됐다고 소급 처리하지 않는다.

데이터 최소화와 기능 독립

첫 구현은 계측을 명시적으로 켠 로컬 연구 실행과 수동 내보내기로 한정하는 안이다. 외부 자동 전송은 이 단계에 넣지 않는다. 내부 설치의 기본 외부 전송 없음 원칙을 유지한다. 본문·제목·검색어·파일명·문서 URL·이메일·tenant 원본 ID·오류 원문을 이벤트에 넣지 않는다. 오류는 정해진 분류값으로 제한한다. 임의 대응값도 개인과 다시 연결될 수 있으므로 익명이라고 단정하지 않는다.

공개 Wiki에는 합성 자료 또는 식별 가능성을 검토한 집계만 남긴다. 실제 참여자 대응표와 원본 자료는 공개 저장소에 두지 않는다. 보관 기간·삭제 담당·내보내기 범위는 실험 시작 전에 정한다. 이 문서는 법적 적합성 판단이 아니다.

기록 저장소 장애·내보내기 실패·계측 끄기는 제품 저장·이동·파일 내보내기의 성공을 바꾸면 안 된다. 기록이 빠졌으면 기록 누락으로 알리고 성공 숫자를 만들어 채우지 않는다. 본문 저장 큐에 분석 전송을 선행 조건으로 넣지 않는다.

합성 계산: 제품 검증과 분리

고객 없이 만든 네 개의 가상 업무 기록으로 중복 제거와 산식만 계산했다. 실제 앱 실행·참여자 관찰·시장 성과가 아니다. 입력 JSON과 계산 결과를 함께 둔다. 이 자료는 최소 산식 예시이며 위 전체 이벤트 스키마의 적합성 검사가 아니다.

가상 업무	입력 조건	활성화 후보	관찰 종료값
T1	Word 저장·재열기, Slides 저장 실패 후 재시도 성공·재열기, 중복 이벤트 1개	예	독립 완료
T2	Word 충돌 초안, Slides 저장·재열기	아니오	기술 실패
T3	두 제품 저장·재열기, 조작 도움 있음	예	도움받아 완료
T4	Word 저장·재열기 후 취소	아니오	취소

원시 23건에서 동일 event ID 1건을 제외하면 22건이다. 시작 업무는 4건이다. 활성화 후보는 2/4, 독립 완료는 1/4다. 기술 실패·도움 완료·취소는 각 1/4다. T1의 최종 성공 뒤에도 중간 저장 실패 1건을 유지했다. 이 계산에서 고객 참여자는 0명이다. 새로 고침 복원, 시계 이상, 계측 끄기, 데이터 유출 방지, 실제 저장 훅은 검증하지 않았다.

구현에 넘길 인수 범위

기존 #297 안에서 이벤트 계약 → 제품별 연결 → 로컬 실험 기록 순서로 검토한다. 고정 시나리오로 정상 저장·충돌 초안·실패 후 재시도·취소·중복 내보내기·새로 고침·계측 끄기를 확인한다. 원시 이벤트와 예상 수를 대조하고, 관찰자의 업무 판정과 비교한다. Note와 나머지 제품 경로 모두 확인한다.

제품 계측의 완료와 alpha 출시 인수는 구분한다. #322의 실행 증거를 사용량으로 대체하지 않는다. 새 시장 후보는 #326에서 조사 중이므로 여기서 별도 시장 이슈를 만들지 않는다. 고객군과 업무가 달라지면 이벤트·분모를 먼저 재검토한다.

#297은 열린 상태다. 다음 단계는 기존 수집기 최종 확인, 연구 책임자의 과제·기준 확정, 구현 담당자의 연결 설계, 실제 데스크톱 실행이다. 이번 회차는 그중 소스 조사와 계약·합성 계산만 완료했다.