LLM 정책은 문서로만 존재하면 거의 작동하지 않습니다. 실제 서비스에서는 “무엇을 허용할지”, “무엇을 차단할지”, “무엇을 사람 승인으로 보낼지"를 코드로 구현해야 합니다. 그래야 에이전트가 커져도 동작이 흔들리지 않습니다.
이 글은 정책 강제를 어디에 넣어야 하는지, 어떤 규칙이 먼저 와야 하는지, 그리고 OpenAI와 Anthropic 계열 도구를 붙일 때 어떤 순서로 검증할지 정리합니다. OpenAI Agents SDK, Anthropic API, NeMo Guardrails를 함께 보면 좋습니다.
왜 중요한가 #
정책이 없으면 모델은 매번 다르게 반응합니다. 같은 질문이라도 맥락에 따라 답이 달라지고, 도구가 붙으면 그 차이는 곧 운영 리스크가 됩니다.
- 개인정보 응답 기준이 일관되지 않는다
- 금지된 기능 호출이 모델 판단에 의존한다
- 승인 필요 작업이 자동 실행된다
- 감사 로그가 남지 않아 사고 원인을 추적하기 어렵다
정책 강제는 이런 변동성을 줄이는 장치입니다.
문제 구조 #
정책을 강제하려면 세 레이어를 분리해야 합니다.
- 콘텐츠 정책: 어떤 답변이 허용되는가
- 도구 정책: 어떤 API, 함수, MCP 서버를 호출할 수 있는가
- 실행 정책: 어떤 작업은 사람 승인 없이는 못 하는가
이걸 한 군데에 몰아넣으면 유지보수가 어려워집니다. 대신 각 레이어가 자기 역할만 하게 만드는 편이 낫습니다.
실무 대응 방법 #
추천하는 패턴은 아래와 같습니다.
- 요청 분류: 일반 질문, 민감 질문, 고위험 작업으로 나눈다
- 정책 검사: 사전 정의된 규칙과 금칙어, 위험 점수를 본다
- 도구 가드: 실행 가능한 도구 목록을 제한한다
- 승인 단계: 결제, 삭제, 배포 같은 작업은 별도 확인을 둔다
- 사후 기록: 정책 위반과 예외 처리를 모두 로그에 남긴다
이 흐름은 OpenAI Agents SDK의 tool orchestration, Guardrails AI의 checks, Cloudflare Remote MCP Security의 원격 도구 경계와 잘 맞습니다.
체크리스트 #
- 정책이 프롬프트가 아니라 코드로 존재하는가
- 도구별 허용 목록이 분리되어 있는가
- 승인 흐름이 자동 실행보다 앞에 있는가
- 정책 위반이 로그와 메트릭으로 보이는가
- 예외 상황에서 안전한 기본값으로 떨어지는가
- 운영자가 정책을 쉽게 갱신할 수 있는가
결론 #
LLM 정책 강제는 거창한 거버넌스보다 먼저, 코드에 있는 명확한 허용/차단/승인 규칙에서 시작해야 합니다. 작은 규칙이라도 일관되게 강제되면 에이전트 운영의 불확실성이 크게 줄어듭니다.