LLM의 예기치 않은 도구 호출을 방지하자! Guardrails AI로 안전한 에이전트 구축하기

LLM 에이전트를 개발하다 보면, 의도하지 않은 도구 호출이나 예기치 않은 동작에 직면하여 가슴이 철렁했던 경험이 있지 않으신가요? 부적절한 API 호출로 인한 보안 리스크, 데이터 유출, 혹은 고액의 이용 요금 발생 등 LLM의 "폭주"는 현실적인 위협입니다. 이 기사에서는 Guardrails AI를 활용하여 이러한 과제를 해결하고, 안전하고 신뢰성 높은 LLM 에이전트를 구축하는 실천적인 방법을 해설합니다. Guardrails AI를 도입함으로써 LLM의 출력을 엄격하게 검증·제어하여, 예기치 않은 도구 호출이나 부적절한 응답을 미연에 방지합니다.

LLM 에이전트는 외부 도구를 호출함으로써 그 능력을 비약적으로 향상시키지만, 이 강력한 기능에는 큰 리스크가 따릅니다. 구체적으로 어떤 문제가 발생할 수 있을까요?

에이전트가 사용자 입력에 의해 의도하지 않은 데이터베이스 조작 도구를 호출하거나, 기밀 정보를 포함한 API에 액세스할 가능성이 있습니다. 이로 인해 정보의 부정 취득이나 변조, 최악의 경우에는 시스템 전체로의 침입으로 이어질 우려가 있습니다.

외부 API 호출에는 통상적으로 비용이 발생합니다. LLM이 불필요하게 고가의 API를 대량으로 호출하게 되면, 예기치 않은 형태로 운영 비용이 급증할 가능성이 있습니다.

LLM이 할루시네이션 (Hallucination, 환각)을 일으켜 존재하지 않는 도구를 호출하려고 하거나, 잘못된 인자(Argument)로 도구를 호출하면 에러가 발생하여 사용자는 기대하는 결과를 얻을 수 없습니다. 이는 사용자 경험을 현저히 저해합니다.

이러한 리스크를 경감하고 LLM의 안전성을 확보하기 위해서는 LLM의 출력, 특히 도구 호출의 제어가 필수적입니다.

Guardrails AI는 LLM으로부터의 데이터 검증과 구조화를 지원하는 Python 프레워크입니다. LLM의 입력과 출력에 대해 가드 (Guard, 검증 규칙)를 적용함으로써, 부적절한 콘텐츠 생성이나 예기치 않은 도구 호출을 방지합니다. 임의의 LLM과 조합하여 사용할 수 있으며, 높은 유연성이 특징입니다.

2024년 6월 시점의 최신 버전은 guardrails-ai 0.10.2이며, Python 3.10 이상을 지원합니다.

LLM의 안전성 확보를 위한 솔루션은 Guardrails AI 외에도 몇 가지 존재합니다.

Guardrails API (Google for Developers): Google GenAI의 입력과 출력에 대한 가드레일 서비스. 현재 프라이빗 프리뷰 버전입니다. -
Amazon Bedrock Guardrails: AWS Bedrock 위에서 이용할 수 있는 가드레일 기능. 콘텐츠 모더레이션, 프롬프트 공격 탐지, PII 리덕션 등 다방면의 세이프가드 정책을 제공합니다. -
NVIDIA NeMo Guardrails: LLM의 안전성에 관한 프로그래머블한 미들웨어를 제공하는 오픈 소스 툴킷. Colang이라는 DSL로 가드레일 정책을 정의합니다. -
OpenAI Guardrails SDK: OpenAI가 제공하는 SDK로, 사용자 입력과 에이전트 출력의 체크 및 검증을 가능하게 합니다.

이러한 솔루션들은 각각 서로 다른 강점이나 적용 범위를 가지고 있지만, Guardrails AI는 특히 프레임워크로서 유연성이 높고, 커스텀 밸리데이터 (Custom Validator) 작성 및 기존 LLM 클라이언트와의 연동이 용이하다는 점이 장점입니다.

이 섹션에서는 Guardrails AI의 설치 방법과, Guardrails Hub에서 제공되는 PII (Personally Identifiable Information, 개인 식별 정보) 탐지 밸리데이터를 사용한 기본적인 이용 사례를 소개합니다.

먼저 Guardrails AI를 설치합니다. Guardrails Hub의 밸리데이터를 이용하는 경우에는 CLI 구성도 필요합니다.

# Guardrails AI 설치
pip install guardrails-ai
# Guardrails CLI 구성 (Guardrails Hub의 밸리데이터를 이용할 경우 필요)
...

guardrails configure 명령으로 설정하는 API 키는 Guardrails Hub에 대한 액세스 권한을 가진 것이어야 합니다.

Guardrails AI의 핵심적인 인터페이스는 Guard 객체입니다. 이를 사용함으로써 LLM 호출을 래핑(Wrap)하고 검증을 적용할 수 있습니다.

import os
from guardrails import Guard
from guardrails.hub import DetectPII
...

위 코드를 실행하면, DetectPII 검증기(Validator)에 의해 이메일 주소와 전화번호가 감지되어, validation_passed가 False가 되거나, validated_output이 수정된 형식으로 출력되는 것을 확인할 수 있습니다.

Guardrails AI는 독자적인 API 서버로 배포하는 것도 가능합니다. 이를 통해 OpenAI 호환 엔드포인트(Endpoint)를 사용하여 기존 애플리케이션에 가드레일 기능을 쉽게 통합할 수 있습니다.

Guardrails API 서버를 시작하려면 guardrails-api 패키지와 uvicorn이 필요합니다.

pip install guardrails-api uvicorn

다음으로, 가드레일을 정의하는 Python 파일과 서버 설정을 기술하는 .env 파일을 생성합니다.

pii-guard.py (가드레일 정의 파일)

from guardrails import Guard
from guardrails.hub import DetectPII
# "pii-guard"라는 이름의 Guard 객체를 생성하고, PII 감지 검증기를 추가합니다.
...

.env (서버 설정 파일)

PORT=8000
GUARDRAILS_LOG_LEVEL=INFO
GUARDRAILS_CONFIG_PATH=./pii-guard.py # 위에서 생성한 가드레일 정의 파일의 경로

설정 파일이 준비되었다면, 다음 명령어로 서버를 시작합니다.

guardrails-api start --env .env

또는 설정 파일을 직접 지정할 수도 있습니다.

guardrails-api start --config pii-guard.py

서버가 시작되면 http://localhost:8000에서 이용할 수 있습니다.

Swagger UI는 http://localhost:8000/docs에서, 헬스 체크(Health check)는 http://localhost:8000/health-check에서 확인할 수 있습니다.

이 API 서버를 통해 LLM의 출력을 검증함으로써, 애플리케이션 아키텍처(Architecture)에 큰 변경을 가하지 않고도 LLM의 안전성을 향상시키는 것이 가능합니다.

Guardrails AI는 강력한 도구이지만, 도입 시 몇 가지 과제에 직면할 수 있습니다. 여기서는 흔히 발생하는 오류와 그 해결책, 그리고 성능에 관한 고려 사항을 설명합니다.

원인:

API 키 설정 오류, LLM API로의 인자(Argument) 오류, LLM API 다운, 커스텀 LLM 래퍼(Wrapper)의 시그니처(Signature) 불일치 등이 있을 수 있습니다.

해결책:

• API 키 확인: 환경 변수 OPENAI_API_KEY 등이 올바르게 설정되어 있는지, Guardrails가 LLM에 API 키를 제대로 전달하고 있는지 확인합니다.
• LLM 인자 확인: guard() 메서드에 전달하는 인자가 사용 중인 LLM 클라이언트(예: openai.chat.completions.create)가 기대하는 인자와 일치하는지 확인합니다. 불필요한 인자는 삭제하거나, LiteLLM 클라이언트를 사용하여 동작을 확인합니다.
• 커스텀 LLM 래퍼: 커스텀 LLM callable을 사용하는 경우, messages 키워드 인자를 받고 문자열을 반환하는 함수로 호출할 수 있는지 확인하십시오.

원인:

Guardrails Hub 접속에 사용 중인 API 키가 유효하지 않거나 권한이 없을 수 있습니다.

해결책:

• API 키 재생성: Guardrails Hub 포털에서 새로운 API 키를 생성합니다.
• CLI 재구성: 새로운 API 키를 사용하여 guardrails configure 명령을 다시 실행하고 CLI를 재구성합니다.

원인:

Guardrails AI는 검증에 실패했을 경우 LLM에 재생성을 요청(on_fail="reask"

）메커니즘을 가지고 있습니다. 이로 인해 LLM 호출이 여러 번 발생하여 응답 시간이 크게 증가할 수 있습니다. 특히 첫 번째 검증 패스에서 실패하는 응답의 비율이 높을 때 두드러집니다.

회피책:

• 입력과 출력 모두를 검증: 출력뿐만 아니라 LLM으로의 입력 프롬프트(Prompt)도 가드레일로 검증하여, 문제가 있는 콘텐츠가 LLM에 도달하는 것을 방지합니다. 이를 통해 LLM이 부적절한 응답을 생성할 가능성 자체를 줄일 수 있습니다.
• 빠르고 결정론적인 Pre-LLM 가드레일: LLM 호출 전에 실행되는 가드레일은 정규 표현식(Regex) 기반의 PII(개인정보) 탐지나 규칙 기반의 인젝션(Injection) 체크와 같이 빠르고 결정론적인 방식을 사용합니다. LLM 기반 체크는 레이턴시(Latency)가 증가하므로, 정말 필요한 경우에만 사용을 고려합니다.
• 적절한 OnFailAction 설정: Guardrails는 검증(Validator)이 실패했을 때의 다양한 OnFailAction을 제공합니다.
  • REASK: LLM에 재생성을 요청하지만, 레이턴시가 증가할 수 있습니다.
  • EXCEPTION: 검증 실패 시 예외를 발생시켜 애플리케이션 측에서 에러 핸들링(Error Handling)을 수행합니다.
  • FIX: 검증 실패 시 프로그래밍 방식으로 출력을 수정합니다 (예: PII를 마스킹하는 등).
  • REFRAIN: 출력을 반환하지 않습니다.

상황에 따라 최적의 액션을 선택하여 레이턴시와 사용자 경험 사이의 균형을 맞춥니다.

• 계층화된 방어: 단일 가드레일에 의존하지 않고 여러 가드레일을 조합함으로써, 각 계층이 서로 다른 종류의 문제를 포착하게 하여 하나가 실패하더라도 다른 계층이 백업을 제공하도록 합니다.

이러한 대책을 강구함으로써 Guardrails AI를 효과적으로 활용하고, LLM 에이전트의 안전성과 성능을 양립시키는 것이 가능해집니다.

안전하고 신뢰할 수 있는 LLM 에이전트를 구축하기 위해서는 Guardrails AI의 도입뿐만 아니라 설계 단계부터의 고려가 중요합니다. 여기서는 설계상의 트레이드오프(Trade-off)와 권장되는 베스트 프랙티스(Best Practice)에 대해 해설합니다.

Guardrails의 도입은 항상 몇 가지 트레이드오프를 수반합니다.

• 커스터마이징 가능성과 성능: 기성(Off-the-shelf) 가드레일은 간편하지만, 특정 도메인에서는 커스텀 정책이 필요합니다. 커스텀 정책은 개발 비용이 들지만, 더 빠르고 견고한 분류기(Classifier)로 기능할 수 있습니다.
• 레이턴시와 정책 준수율: 가드레일을 추가할수록 정책 준수율은 향상되지만, 특히 LLM 기반 체크는 레이턴시를 증대시킵니다. 사용자 경험을 해치지 않도록 적절한 균형을 찾아야 합니다.
• 비용과 정확도: LLM 기반 가드레일은 정확도가 높은 경향이 있지만 비용도 높아집니다. 저렴하고 빠른 모델(예: GPT-4o-mini, Llama의 소규모 모델)을 파인튜닝(Fine-tuning)함으로써 정확도와 비용의 균형을 맞추는 것도 가능합니다.
• 차단과 수정: 위반을 감지했을 때 콘텐츠를 차단할지 또는 자동으로 변경할지를 선택할 수 있습니다. 엄격한 컴플라이언스(Compliance)에는 차단이 적합하지만, 사용자 경험을 고려하면 수정이 바람직한 경우도 있습니다.

LLM 에이전트의 안전성을 확보하는 데 있어 가장 중요한 것은 **다층 방어 (Defense in Depth)**와 **최소 권한의 원칙 (Principle of Least Privilege)**입니다.

• 입력 가드레일 (Input Guardrails): LLM에 도달하기 전에 악의적인 프롬프트, 탈옥(Jailbreak) 시도, 정책 위반 요청을 차단합니다. PII 탐지 및 익명화, 프롬프트 인젝션(Prompt Injection) 탐지 등이 포함됩니다.

• 처리 가드레일 (Processing Guardrails): 모델이 동작하는 실행 컨텍스트(Context)를 형성하여, 접근할 수 있는 것과 행동 방법을 결정합니다. LLM이 사용할 수 있는 도구를 제한하거나 특정 주제 이외의 대화를 금지합니다.

• 출력 가드레일 (Output Guardrails): 모델의 응답이 사용자에게 반환되기 전에 평가합니다. 할루시네이션(Hallucination) 탐지, 유해 콘텐츠 탐지, PII 익명화, 출력 포맷 검증 등을 수행합니다.

• 도구 가드레일 (Tool Guardrails): 에이전트가 호출하는 도구(Tool)나 API에 적용되어, 어떤 도구가 어떤 인자(Argument)로 호출될지를 허용하거나 거부합니다.

• 예를 들어, 데이터베이스 접근 권한이 있는 에이전트가 삭제 명령어나 인증 정보 쿼리를 실행하지 못하도록 방지합니다.

• 에이전트가 호출할 수 있는 모든 도구는 최소 권한 원칙을 따라야 합니다.

• 예를 들어, 데이터베이스에 대한 읽기 권한만 가진 도구와 쓰기 권한을 가진 도구를 명확히 분리하고, 쓰기 권한을 가진 도구는 엄격한 가드레일로 보호합니다.

인간의 승인 (Human-in-the-Loop): 파괴적인 작업(데이터베이스 삭제, 금융 거래 등)이나 고위험 도구 호출 전에 인간의 승인 프로세스를 삽입합니다. -
지속적인 모니터링 및 평가: 가드레일의 트리거율, 오탐률(False Positive Rate), 레이턴시(Latency)에 미치는 영향을 추적합니다. 새로운 공격 패턴이나 모델 드리프트(Model Drift)에 맞춰 가드레일을 정기적으로 검토하고 업데이트합니다. -
적대적 테스트 (Red Teaming): 실제로 가드레일을 돌파하려고 시도함으로써 격차를 식별하고 방어를 강화합니다. -
명확한 에러 메시지: 가드레일이 트리거되었을 경우, 사용자에게 "요청이 차단되었습니다"와 같은 모호한 메시지가 아닌 구체적인 가이드를 제공합니다. -
시스템 프롬프트는 가드레일이 아니다: 시스템 프롬프트는 모델에 대한 "정중한 요청"일 뿐이며, 의도적인 적대적 입력에 대해서는 제대로 작동하지 않는 경우가 많습니다. 진정한 가드레일은 런타임(Runtime)에서 제약을 적용합니다. -
도구 정의의 명확화: 도구 정의에 명확한 경계, 에지 케이스(Edge Case), 명확한 목적을 부여함으로써 모델이 혼란스러운 액션 선택에 빠지는 것을 방지합니다.

이러한 베스트 프랙티스(Best Practices)를 준수함으로써, **LLM의 도구 호출 (Tool Calling)**을 안전하게 관리하고 견고한 AI 에이전트를 구축할 수 있습니다.

이 기사에서는 LLM 에이전트의 예기치 않은 도구 호출이 초래하는 리스크를 해설하고, 그 대책으로서 Guardrails AI를 활용하는 방법을 구체적으로 제시했습니다.

Guardrails AI를 도입함으로써 다음과 같은 이점을 얻을 수 있습니다.

• LLM의 출력, 특히 도구 호출을 엄격하게 검증하고 제어할 수 있습니다.
• PII(개인정보) 탐지나 프롬프트 인젝션(Prompt Injection) 방지 등 다양한 보안 기능을 구현할 수 있습니다.
• API 서버로 배포함으로써 기존 시스템과의 연동도 용이합니다.

도입 시 주의할 점으로 API 키 설정, 레이턴시 문제, 재시도 루프(Retry Loop)에 대한 대책을 언급하며 각각의 회피 방법을 제시했습니다. 또한, LLM 에이전트의 안전성을 극대화하기 위해 다층 방어 및 최소 권한 원칙과 같은 설계상의 베스트 프랙티스도 소개했습니다.

Guardrails AI는 AI 에이전트의 신뢰성과 안전성을 비약적으로 향상시키는 강력한 도구입니다. 꼭 본 기사를 참고하여 여러분의 프로젝트에 Guardrails AI를 도입하고, 더욱 견고한 LLM 에이전트를 구축해 보시기 바랍니다.

더 깊이 학습하고 싶은 분들은 Guardrails AI의 공식 문서 (https://docs.guardrailsai.com/)를 참조하는 것을 권장합니다.