4. 함부로 실행하지 않는 Agent
어떤 작업에 승인을 붙일까
이 차시를 마치면
어떤 작업에 사람 승인을 붙일지 '되돌릴 수 있는가'로 판단합니다.
어떤 작업에 사람의 승인을 붙일지 정하는 방법입니다. 이 판단이 나머지 설계를 결정합니다.
학습팩의 두 등급
| 등급 | 작업 |
|---|---|
| 높은 위험 | 이메일 실제 발송 · DB 삭제 · 외부 게시 · 결제 · 권한 변경 · 채용과 평가 등 민감 판단 |
| 낮은 위험 | 초안 생성 · 요약 · 분류 후보 제안 · 검색어 추천 |
두 목록을 가르는 질문 하나
되돌릴 수 있는가.
초안은 지우면 되지만 발송한 메일은 회수되지 않습니다. 새 기능을 추가할 때 이 질문 하나로 등급을 정할 수 있습니다. 분석
비유
연필로 쓴 것과 도장을 찍은 것의 차이입니다. 연필은 지우면 되고, 도장은 찍는 순간 효력이 생깁니다. 도장을 찍기 전에는 한 번 더 봐야 합니다.
확인 필요 학습팩은 두 등급만 제시합니다. 중간 등급(예: "로그만 남기고 실행")이나 등급별 승인자 구분은 학습팩에 없습니다.
코드로 옮기기
def validate(state) -> dict:
"""규칙 기반 사전 검사. LLM 판단보다 먼저 결정적 규칙을 적용한다."""
high_risk_markers = ["삭제", "발송", "결제", "권한"]
risk = "high" if any(m in state["request"] for m in high_risk_markers) else "low"
return {"risk_level": risk, "audit_log": [f"validate 완료 (risk={risk})"]}
왜 LLM 에게 위험 판정을 맡기지 않는가
위험 판정을 모델에게 맡기면 prompt 를 고칠 때마다 안전 규칙이 흔들립니다. 규칙 기반 검사는 코드에 있어서 변경 이력이 남고 테스트로 고정할 수 있습니다. 분석
다만 이 방식에도 한계가 있습니다
확인 필요 위 코드의 키워드 목록은 학습팩의 고위험 작업 목록에서 가져온 것입니다. 그런데 키워드 방식은 표현이 바뀌면 놓칩니다.
"고객 목록 삭제해 줘" → high (걸림)
"고객 목록 정리해 줘" → low (놓침)
학습팩의 코드 실행 안전 원칙 7번이 같은 취지를 적어 둡니다. dangerous command filter 만으로 안전하다고 가정하지 않기.
실무에서는 입력 문자열이 아니라 실제 호출되는 도구나 행동을 기준으로 위험을 판정하는 방식이 더 안전합니다. 예를 들어 "쓰기 도구를 부르려 한다"는 사실 자체를 고위험으로 봅니다.
다만 이 대안은 학습팩에 명시되어 있지 않으므로 검증이 필요합니다. 확인 필요
정리
| 방식 | 장점 | 한계 |
|---|---|---|
| 입력 키워드 기준 | 구현이 쉽고 빠릅니다 | 표현이 바뀌면 놓칩니다 |
| 호출 도구 기준 | 표현과 무관하게 걸립니다 | 학습팩에 근거가 없어 검증이 필요합니다 |
| 둘 다 적용 | 놓칠 확률이 줄어듭니다 | 저위험 작업에도 승인이 붙어 번거로워질 수 있습니다 |
이 차시의 파이썬 코드는 개념을 보이려고 떼어 놓은 예시 조각입니다. 문법 검사는 통과하지만 그대로 돌려서 결과를 확인한 코드는 아닙니다. 실행까지 검증한 코드는 4번과 6번 트랙에 있으며, 그 차시에는 무엇을 어떻게 확인했는지 따로 적어 두었습니다.