배치 기준값과 런타임 이벤트를 구분해 추적하기

이번 단계의 질문

배치가 만든 8행과 에이전트가 만든 두 이벤트는 같은 의미일까요?

왜 지금 필요한가

행 수만 보면 모두 om_event_history에 있으므로 같은 실행처럼 보일 수 있습니다. 하지만 배치는 8개 구역의 기준값을 재현하고, 런타임 이벤트는 한 사용자의 허용·거부 요청을 기록합니다. 이 차이를 알아야 감사 이력을 잘못 해석하지 않습니다.

직접 해보기

OM 이벤트 이력을 새로 고칩니다. 새 실습 공간에서 앞 챕터를 한 번씩 실행했다면 배치 8행 뒤에 OPR-WORKSHOP-01의 이벤트 2행이 추가되어 총 10행입니다.

이어서 Map Control 온톨로지 적재 파이프라인(ontology_materialization)을 Run합니다. 실행이 끝나면 그래프 탐색기에서 다음 쿼리를 실행합니다.

MATCH coordinatePath = (z:mc_tactical_zone {zone_id: 'TZ-008'})
  -[:mc_has_spatial_coordinates]->(o:mc_graphic_overlay)
MATCH eventPath = (z)-[:mc_referenced_in_event]->(e:mc_event_history)
RETURN coordinatePath, eventPath
ORDER BY e.created_at DESC
LIMIT 20

이 화면이 나오면 성공

그래프에서 TZ-008 전술 구역이 OV-008 좌표 오버레이와 배치 이벤트에 연결됩니다. RETURN coordinatePath, eventPath를 사용했으므로 노드뿐 아니라 두 관계도 함께 표시됩니다.

배치 8행을 기준으로 온톨로지를 만들면 다음 수가 나옵니다.

런타임 이벤트 2행까지 적재한 뒤 다시 실행하면 이벤트 엔티티는 10행이 됩니다. 공간 관계는 여전히 8행이고, 이벤트 참조 관계도 현재 변환 계약에서는 배치의 8행만 연결합니다.

결과를 읽어 봅니다

배치 이벤트의 action_log에는 안전구역객체ID가 최상위에 있어 온톨로지 변환이 구역을 바로 찾습니다. 에이전트 런타임 이벤트는 원문 명령과 결과를 result 아래에 중첩하므로 현재 변환은 그 안의 구역 ID를 관계로 만들지 않습니다.

따라서 현재 증거는 다음처럼 나눠 읽습니다.

• 배치 구역·좌표·이벤트 관계: 그래프 탐색기에서 확인합니다.
• 런타임 허용·거부 원문과 결과: OM 이벤트 이력에서 user_id로 확인합니다.
• 런타임 전체 분포: 다음 챕터의 대시보드에서 확인합니다.

이 한계는 감사 이벤트가 사라졌다는 뜻이 아닙니다. 데이터셋에는 남지만 그래프 관계로 물질화되지 않은 상태입니다. 실제 운영에서는 중첩 결과의 구역 ID도 관계로 만드는 변환을 추가해야 한 명령을 그래프까지 끝단 추적할 수 있습니다.

다음 판단

두 실행 계약과 현재 그래프의 범위를 구분했습니다. 다음 챕터에서 안전한 자연어 제어에 필요한 조건을 네 문항으로 점검한 뒤, 마지막에 운영 화면과 전체 흐름을 정리합니다.