안전한 자연어 제어 흐름을 설명하고 워크숍 마치기
대시보드에서 허용·거부 이력을 확인하고 처음 요청부터 감사 근거까지 해결 흐름을 정리합니다.
이번 단계의 질문
구역 ID와 좌표를 모르는 운용자의 요청을 안전하게 실행하려면 무엇이 필요할까요?
왜 지금 필요한가
한 명령의 JSON만 확인하면 거부 요청이 기록됐는지, 팀이 전체 활동을 다시 볼 수 있는지 알기 어렵습니다. 마지막으로 운영 화면에서 두 경로를 확인하고 처음 질문에 답합니다.
직접 해보기
해도 운용 대시보드(map_operations)를 엽니다. 새 실습 공간에서 배치 한 번과 에이전트
요청 두 번을 실행했다면 다음 값을 확인합니다.
| 위젯 | 확인할 값 | 해석 |
|---|---|---|
| Total Events | 10 | 배치 8행 + 런타임 2행 |
| Events by Intent Type | UI_CONTROL 9, DATA_QUERY 1 | 허용과 거부가 모두 집계됨 |
| Events by User | AGENT 8, OPR-WORKSHOP-01 2 | 배치와 운용자 요청 구분 |
| Recent Events | 최근 허용·거부 2행 | 원문 명령과 처리 결과 추적 |
재실행하거나 다른 사용자의 이벤트가 있으면 전체 수는 달라집니다. 이때는 Recent Events에서
OPR-WORKSHOP-01을 찾아 두 행의 intent_type과 action_log를 비교합니다.
이 화면이 나오면 성공
허용된 부산항 표시 명령과 거부된 순찰 이력 질문이 서로 다른 의도로 보이고, 두 행 모두 같은 사용자 ID와 감사 결과를 갖습니다. 대시보드는 새 결정을 만들지 않고 이벤트 데이터셋에 남은 사실을 운영 질문에 맞게 묶어 보여 줍니다.
처음 문제로 돌아가 봅니다
처음 운용자는 부산항 통제 구역의 ID와 좌표를 몰랐습니다. 자연어를 곧바로 지도에 보내면 조회 질문이나 설정 변경까지 실행될 수 있었고, 거부된 요청은 기록에서 빠질 위험도 있었습니다.
앞의 여섯 단계에서 만든 해법은 다음과 같습니다.
| 처음 마주한 문제 | 적용한 해결 | 남은 근거 | 달라진 점 |
|---|---|---|---|
| 구역 이름만 알고 ID와 좌표를 몰랐습니다. | 구역 정의와 오버레이를 zone_id로 연결했습니다. | TZ-008, OV-008, WGS84 좌표 | 이름만으로 결정론적 지도 값을 찾습니다. |
| 명령과 질문의 권한 경계가 모호했습니다. | UI_CONTROL만 허용하는 기본 거부 게이트를 적용했습니다. | intent_classification | 허용하지 않은 동작은 좌표 도구로 가지 않습니다. |
| 자유 문장을 외부 UI가 바로 처리하기 어려웠습니다. | 경도·위도·축척을 고정 JSON으로 만들었습니다. | control_parameters | 외부 UI가 파싱할 계약이 분명해집니다. |
| 거부된 요청이 사라질 수 있었습니다. | 허용·거부 모두 이벤트 파이프라인으로 보냈습니다. | event_log.queued, OM 이벤트 이력 | 실행하지 않은 이유도 감사할 수 있습니다. |
| 배치와 런타임 이력이 섞여 보였습니다. | 사용자와 실행 계약을 나눠 그래프·대시보드에서 읽었습니다. | 배치 8행, 런타임 2행 | 기준값과 실제 요청을 구분해 설명합니다. |
결론을 설명해 봅니다
부산항 입출항 통제 구역 표시 요청은
UI_CONTROL로 허용합니다. 에이전트는 구역 이름을TZ-008로 찾고 WGS84 중심 좌표와 축척을 고정 JSON으로 만듭니다. 순찰 이력 질문은DATA_QUERY라 현재 에이전트의 권한 밖에서 멈춥니다. 두 요청 모두 같은 이벤트 파이프라인을 거쳐 원문, 분류, 결과 또는 거부 이유를 감사 이력에 남깁니다.
이 설명에는 대상 조회, 권한 경계, 결정론적 출력, 허용·거부 기록이 모두 들어 있습니다. 자연어를 편리한 입력으로 사용하면서 실행 범위를 좁히고 근거를 남기는 것이 이번 워크숍의 결론입니다.
완료 체크
-
TZ-008의 구역 이름, WGS84 좌표, 권장 축척을 확인했습니다. -
UI_CONTROL은 허용하고DATA_QUERY는 거부하는 이유를 설명할 수 있습니다. - 허용 명령의 구조화 JSON과 거부 질문의 이유를 확인했습니다.
- 배치 8행과 런타임 이벤트의 차이를 설명할 수 있습니다.
- 그래프가 연결하는 범위와 런타임 이벤트의 현재 한계를 구분할 수 있습니다.
- 대시보드에서 허용·거부 이력을 같은 사용자 기준으로 확인했습니다.
체크하지 못한 항목이 있다면 해당 챕터로 돌아가 성공 신호만 다시 확인하세요.
다음에 적용해 봅니다
- 스마트 팩토리 명령에서는 어떤 표시·조회·제어 의도를 각각 허용할지 정합니다.
- 콜센터 자동화에서는 실행 가능한 응답과 사람 승인이 필요한 변경을 분리합니다.
- 런타임 감사 이벤트를 그래프에 연결할 때 중첩 결과에서 어떤 업무 키를 꺼낼지 정의합니다.