허용 명령과 거부 질문을 한 세션에서 실행하기
이벤트 파이프라인을 시작하고 두 요청의 분류·좌표 JSON·감사 이벤트를 끝까지 비교합니다.
이번 단계의 질문
허용된 명령과 거부된 질문은 각각 어떤 결과와 감사 근거를 남길까요?
왜 지금 필요한가
분류 라벨만 확인하면 실제 동작과 기록이 이어졌는지 알 수 없습니다. 허용 경로는 좌표 JSON까지, 거부 경로는 차단 이유까지 확인하고 두 요청 모두 이벤트 큐에 들어갔는지 봅니다.
직접 해보기
파이프라인에서 에이전트 감사 이벤트 적재(map_agent_event_ingestion)를 먼저
시작합니다. 이 이벤트 파이프라인이 실행 중이어야 에이전트 액터가 보낸 메시지가
OM 이벤트 이력에 추가됩니다.
전자해도 제어 에이전트에서 새 세션을 열고 user_id에 OPR-WORKSHOP-01을 사용합니다.
다음 요청을 차례로 입력합니다.
부산항 입출항 통제 구역 보여 줘오늘 순찰 이력 알려 줘
각 실행에서 intent_classification, control_parameters, event_log를 확인합니다. 거부
경로에서는 reject_command 노드의 거부 이유도 함께 확인합니다.
이 화면이 나오면 성공
허용된 첫 요청은 UI_CONTROL로 분류되고 TZ-008의 값이 구조화 JSON으로 나타납니다.
{
"lon": 129.036,
"lat": 35.10405,
"축척": 10000,
"안전구역객체ID": "TZ-008",
"request_id": "REQ-TZ-008"
}
두 번째 요청은 DATA_QUERY로 분류되어 구역·좌표 도구를 호출하지 않습니다. 대신 현재
에이전트가 UI_CONTROL만 자동 실행하며 추가 승인 절차가 필요하다는 이유를 남깁니다.
| 확인 항목 | 허용 명령 | 거부 질문 |
|---|---|---|
| 분류 | UI_CONTROL | DATA_QUERY |
| 구역 조회 | TZ-008 | 실행하지 않음 |
| 제어 파라미터 | 경도·위도·축척 JSON | 생성하지 않음 |
| 기록 노드 | log_event | log_rejection |
| 발행 결과 | queued: true | queued: true |
결과를 읽어 봅니다
자연어에서 자유롭게 생성되는 것은 분류와 구역명 추출까지입니다. 지도에 전달할 최종 값은 조회된 시드와 고정된 키 구조로 만듭니다. 외부 UI가 자유 문장 대신 정해진 JSON만 받게 해 실행 계약을 좁힙니다.
queued: true는 이벤트가 큐에 들어갔다는 뜻이지 데이터셋 저장이 끝났다는 뜻은 아닙니다.
이벤트 파이프라인이 메시지를 처리한 뒤 OM 이벤트 이력을 새로 고쳐야 최종 행을 확인할
수 있습니다.
다음 판단
허용과 거부 두 요청이 이벤트 큐에 들어갔습니다. 다음 챕터에서는 배치가 만든 기준 8행과 방금 만든 런타임 이벤트를 구분해 추적합니다.