표시 명령과 데이터 질문 구분하기
실제 문장 두 개를 비교해 UI_CONTROL만 자동 실행하는 허용 목록 게이트를 이해합니다.
이번 단계의 질문
“구역을 보여 줘”와 “오늘 순찰 이력을 알려 줘”를 같은 권한으로 실행해도 될까요?
왜 지금 필요한가
두 요청 모두 해도 운용과 관련 있지만 결과는 다릅니다. 첫 요청은 화면 표시를 바꾸고, 둘째 요청은 운영 데이터를 조회합니다. 자연어가 비슷하다는 이유로 같은 도구와 권한을 사용하면 에이전트의 실행 범위가 불필요하게 넓어집니다.
직접 해보기
해도 운용 데이터 컬렉션에서 전자해도 제어 에이전트(map-control)의 워크플로를
엽니다. classify_intent 다음의 validate_intent 분기를 확인합니다.
다음 두 문장이 어느 분기로 갈지 먼저 예상합니다.
| 자연어 요청 | 현재 분류 계약 | 자동 실행 | 이유 |
|---|---|---|---|
| 부산항 입출항 통제 구역 보여 줘 | UI_CONTROL | 허용 | 읽기 전용 표시 제어 |
| 오늘 순찰 이력 알려 줘 | DATA_QUERY | 거부 | 별도 조회 도구와 권한이 필요 |
현재 에이전트에는 UI_CONTROL, DATA_QUERY, SYSTEM_CONFIG, RESTRICTED_ACTION,
NAVIGATION 다섯 분류가 있습니다. validate_intent는 이 가운데 UI_CONTROL만
lookup_zone으로 보냅니다.
이 화면이 나오면 성공
허용 분기는 구역 조회와 좌표 해석으로 이어지고, 거부 분기는 reject_command와
log_rejection으로 이어집니다. 거부된 요청도 기록 경로를 통과한다는 점을 확인합니다.
다이어그램을 불러오는 중입니다. Mermaid 원본:
flowchart LR
accTitle: 표시 명령과 데이터 질문의 안전 게이트
accDescr: 부산항 통제 구역 표시 명령은 UI CONTROL로 분류되어 구역 조회와 좌표 JSON으로 이어지고, 순찰 이력 질문은 DATA QUERY로 분류되어 거부되지만 두 요청 모두 감사 이벤트로 기록됩니다.
command["구역을 보여 줘"] --> classify{의도 분류}
query["순찰 이력을 알려 줘"] --> classify
classify -->|UI_CONTROL| allow[구역 조회·좌표 JSON]
classify -->|그 외| block[거부 이유]
allow --> audit[(감사 이벤트)]
block --> audit결과를 읽어 봅니다
이 설계는 허용 목록입니다. 금지 목록에 없는 요청을 모두 통과시키지 않고, 명시적으로
허용한 UI_CONTROL만 실행합니다. 분류가 모호할 때 불편을 감수하고 멈추는 기본 거부
방식입니다.
거부는 실행 실패가 아닙니다. 현재 에이전트가 맡지 않는 조회를 더 적절한 도구와 권한으로 넘기기 위한 책임 경계입니다. 중요한 것은 거부 이유와 원문 요청도 감사 기록으로 남기는 것입니다.
깊이 보기 — 운용 가이드와 현재 에이전트의 경계
가져온 해도 운용 가이드는 일반 정책 설명에서 DATA_QUERY도 안전 범주로 소개합니다.
하지만 현재 map-control 에이전트의 실제 분기 조건은 UI_CONTROL만 허용합니다.
이 워크숍에서는 실행되는 에이전트 정의를 권한의 단일 기준으로 사용합니다. 운영에 적용할 때는 문서와 워크플로의 허용 범위를 먼저 일치시켜야 합니다.
다음 판단
허용 범위를 정했습니다. 다음 챕터에서는 같은 세션에서 허용 명령과 거부 질문을 실행하고, 좌표 출력과 감사 이벤트를 함께 확인합니다.