P3-9.5 같은 사건은 여러 산출물 사이에서 무엇으로 계속 추적하는가¶
Section ID:
P3-9.5Version:v2026.09.20
공통 ID는 같은 대상을 찾게 해 주지만, 그 대상의 어떤 계산을 사용했는지까지 알려 주지는 않습니다. 같은 비교 구간 A를 기준선 두 개로 계산했다면 window_id=A만으로는 큐의 판단 근거를 하나로 고를 수 없습니다. 산출물을 연결할 때는 대상의 ID와 사용한 리포트·정책·결과 근거를 함께 남깁니다.
구간 A와 구성 동작은 다른 식별자를 쓴다¶
P3-9.3의 비교 구간 A를 이어 씁니다. A는 최근 완료 동작 20건을 묶은 구간이지 한 동작의 event_id가 아닙니다. 이 절에서는 연결을 보여 주기 위해 그 20건에 다음 가상 ID를 부여합니다. 표의 두 행은 읽기 위한 묶음이며 실제 연결 관계는 window_id와 event_id의 쌍 20개입니다.
| window_id | 구성 event_id 목록 |
|---|---|
| A | E001, E002, E003, E004, E005, E006, E007, E008, E009, E010 |
| A | E011, E012, E013, E014, E015, E016, E017, E018, E019, E020 |
동작 20건이 구간 하나로 연결됩니다. 구간이 겹치면 한 동작이 여러 구간에 들어갈 수도 있으므로 각 연결을 기록해야 합니다. 구성 목록이 바뀌면 새 구간 ID 또는 별도 구성 버전으로 구분합니다. 이 예시에서는 A의 구성 목록을 고정합니다. 구간 점검 결과를 E001~E020 모두의 개별 결과로 복사하지 않습니다.
A의 두 리포트는 왜 서로 바꿔 쓸 수 없는가¶
앞 절의 A에 남은 차이 −0.35 L/min을 그대로 사용하고, 계산 근거를 보여 주기 위해 최근 평균 2.20과 기준 평균 2.55 L/min을 가상으로 보충합니다. 아래 시각은 모두 2026-09-20의 같은 시간대입니다. 두 번째 리포트는 기준선만 다른 비교이며, 새 버전이 자동으로 더 올바르다는 뜻은 아닙니다.
| report_id | window_id | 생성 시각 | baseline_version | 기준 평균 | 최근 평균 | diff_mean |
|---|---|---|---|---|---|---|
| REP-A-1 | A | 10:00 | base-v1 | 2.55 | 2.20 | -0.35 |
| REP-A-2 | A | 11:00 | base-v2 | 2.30 | 2.20 | -0.10 |
평균과 차이의 단위는 L/min이며 동작별 후반 평균을 같은 비중으로 평균 냅니다. 2.20−2.55=−0.35, 2.20−2.30=−0.10입니다. A의 실제 최근 값과 구성은 바뀌지 않았습니다. 차이가 0.25 L/min만큼 달라진 것은 기준선 변경 때문이며 상태가 회복되었다는 증거가 아닙니다.
base-v1과 base-v2는 각각 참조 기간·설비와 운전 조건·포함 동작·집계 정의를 찾을 수 있는 기준선 기록을 가리켜야 합니다. 이름만 남기고 그 정의를 잃으면 계산을 재현할 수 없습니다. 이 예시는 차이를 보이기 위한 요약값이며 어느 기준선이 업무 목적에 더 적합한지까지 판정한 자료는 아닙니다.
큐는 실제 사용한 리포트를 지정한다¶
10:30에 만든 배정 Q-01은 P3-8.5의 queue-v1과 처리 여력 2를 사용합니다. B의 차이 −0.35와 안전 분류 no, C의 차이 −0.18과 yes는 앞 절과 같습니다. A는 yes이고 REP-A-1의 −0.35를 사용했으므로 순서는 A→C→B, 선택된 큐는 A·C입니다.
| queue_id | 배정 시각 | window_id | queue_rank | source_report_id | policy_version |
|---|---|---|---|---|---|
| Q-01 | 10:30 | A | 1 | REP-A-1 | queue-v1 |
이 표는 선택된 큐에서 A행만 발췌한 것입니다. 전체 큐의 C행과 원본 후보 B도 별도로 보존합니다. source_report_id가 없으면 A에 대한 리포트 두 개 중 무엇을 썼는지 모릅니다. 단지 최신 리포트를 붙이면 10:30의 판단에 11:00에 만든 REP-A-2를 끼워 넣게 됩니다.
만약 REP-A-2로 새 배정을 계산한다면 yes 묶음 안에서 C의 0.18이 A의 0.10보다 커져 C→A→B가 됩니다. 새 배정 ID와 시점으로 기록해야 하며 Q-01의 과거 근거를 덮어쓰지 않습니다. 시각은 검산에 도움이 되지만, 여러 리포트가 같은 시각에 생성될 수도 있으므로 리포트 ID와 명시적 참조를 대신하지는 않습니다.
결과 후보에서 점검 메모까지 돌아가기¶
P3-9.3의 A 점검 결과 1도 같은 방식으로 연결합니다. 아래 식별자와 시각은 추적 연습을 위해 보충한 가상 기록입니다. 메모는 실제 파일이 아니라 그 출처를 식별하는 예시입니다.
| note_id | window_id | inspection_id | reviewer_id | 작성 시각 | 원문 메모 |
|---|---|---|---|---|---|
| NOTE-A-1 | A | check-A | RV1 | 12:00 | inspection-v1의 점검 범위를 완료했고, 정의된 문제를 확인함. |
| window_id | source_queue_id | source_report_id | source_note_id | label_definition_version | confirmed_issue |
|---|---|---|---|---|---|
| A | Q-01 | REP-A-1 | NOTE-A-1 | inspection-v1 | 1 |
결과 후보의 1은 점검 메모에서, 비교 차이는 REP-A-1에서, 순위는 Q-01의 정책 적용에서 왔습니다. 세 값은 출처가 다릅니다. inspection-v1은 확인할 문제와 점검 범위를 정의하는 기록에 연결되어야 합니다. 12:00에 작성된 결과 메모를 10:30 배정 당시 이미 알고 있던 입력처럼 사용하지 않습니다.
공통 식별자로 산출물 사이의 사건 추적하기¶
flowchart TD
A["결과 후보: A = 1"] --> B["Q-01 / queue-v1"]
B --> C["REP-A-1 / base-v1"]
A --> D["NOTE-A-1 / check-A"]
C --> E["비교 구간 A"]
E --> F["구성 동작 E001~E020"]
큐 한 행을 확인할 때는 Q-01→REP-A-1→base-v1로 비교 근거를 찾고, 결과 후보의 NOTE-A-1→check-A로 점검 근거를 찾습니다. 구성 사건은 별도의 A→E001~E020 연결로 확인합니다. 모두를 event_id 하나로 합치면 구간·계산 버전·배정·점검이라는 서로 다른 단위를 잃습니다.
잘못 연결된 리포트 고치기¶
Q-01의 A행에 “최신 값”이라는 이유로 REP-A-2의 −0.10을 붙이고, confirmed_issue=1을 E001~E020에 모두 복사했습니다. 두 오류를 찾아 올바른 연결을 적어 보세요.
해설: Q-01은 source_report_id=REP-A-1이므로 당시 차이는 −0.35, 기준선은 base-v1입니다. REP-A-2는 별도 계산으로 보존하며 필요하면 새 배정을 만듭니다. 결과 1은 A와 연결된 점검 기준의 결과이므로 각 동작의 정답으로 복사하지 않습니다. 개별 동작 라벨을 쓰려면 그 단위에 맞는 별도 확인 근거가 필요합니다.
체크리스트¶
- 큐에서 대상 ID뿐 아니라 실제 리포트와 기준선 버전까지 찾을 수 있는가?
- 결과 후보를 점검 메모·담당자·정의 버전과 연결하고 당시 없던 정보를 섞지 않는가?
- 구간 ID와 구성 동작 ID를 분리해 기록하고 결과를 다른 단위에 자동 전파하지 않는가?
출처와 참고 자료¶
- W3C, PROV-Overview — 대상·처리 활동·파생 관계와 버전을 추적하는 관점을 참고했습니다. 본문의 수치·ID·시각은 자체 가상 사례입니다. 확인일: 2026-09-20.