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

이번 단계의 질문

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

왜 지금 필요한가

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

이 워크숍에서 배치 이벤트는 파이프라인을 직접 실행해 만든 기준 기록이고, 런타임 이벤트는 에이전트가 실제 사용자의 요청을 처리하면서 남긴 기록입니다.

직접 해보기

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

이어서 Map Control 온톨로지 적재 파이프라인(ontology_materialization)을 Run합니다. 실행이 끝나면 다음 순서로 TZ-008의 맥락을 확인합니다.

1. 그래프 탐색기에서 이 시나리오의 컬렉션을 선택합니다.
2. 엔티티 목록에서 mc_tactical_zone을 선택합니다.
3. TZ-008 노드를 선택해 속성 패널의 zone_id를 확인합니다.
4. 구역과 함께 조회된 좌표 오버레이와 이벤트 연결을 확인합니다.
5. 연결된 이벤트 노드를 선택해 created_at과 작업 유형을 확인합니다.

확인할 결과

그래프에서 TZ-008 전술 구역이 OV-008 좌표 오버레이와 배치 이벤트에 연결됩니다. 관계선을 선택해 유형이 각각 mc_has_spatial_coordinates, mc_referenced_in_event인지 확인합니다.

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

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

결과를 읽어 봅니다

action_log는 OM 이벤트 이력 데이터셋의 한 칸으로, 요청을 어떻게 처리했는지 JSON 형식으로 담습니다. 배치 이벤트에서는 안전구역객체ID가 이 JSON의 바깥 단계에 바로 있어 온톨로지 변환이 구역을 찾습니다. 에이전트가 남긴 런타임 이벤트에서는 원문 명령과 결과가 result라는 한 겹 안에 들어가므로, 현재 변환은 그 안의 구역 ID를 관계로 만들지 않습니다.

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

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

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

다음 판단

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