Agentic AI를 위한 LLM 보안: 인젝션, 도구 호출, 데이터 레지던시, HITL, 테스트

LLM 보안은 더 이상 안전하지 않은 프롬프트를 차단하는 것만의 문제가 아닙니다. LLM이 Agentic 워크플로의 일부가 되면 문서를 검색하고, API를 호출하고, 레코드를 업데이트하거나 비즈니스 프로세스를 트리거할 수 있습니다. 이는 보안 모델을 “채팅 보호”에서 “모델 주변의 행동 시스템 보호”로 바꿉니다.

팀이 더 폭넓은 프로덕션 Agentic AI를 계획하고 있다면, LLM 보안은 최종 체크리스트가 아니라 릴리스 게이트로 다뤄져야 합니다. EU/US 팀의 경우 출시 전에 프롬프트 인젝션, 안전한 도구 접근, 데이터 레지던시, 감사 가능성, 인간 감독, 테스트, 프로덕션 모니터링을 고려해야 한다는 뜻입니다.

이 위험은 더 이상 이론적이지 않습니다. Stanford HAI의 2025 AI Index는 2024년에 AI 관련 사고 233건이 보고되어 사상 최고치를 기록했고, 2023년 대비 56.4% 증가했다고 밝혔습니다. IBM의 2025 Cost of a Data Breach Report도 조직의 13%가 AI 모델 또는 애플리케이션과 관련된 침해를 보고했으며, 침해를 겪은 조직 중 97%는 적절한 AI 접근 통제가 부족했다고 밝혔습니다.

이 가이드는 팀이 LLM 기반 에이전트를 안전하게 출시하기 위해 필요한 실질적인 통제를 설명합니다.

핵심 요점

• LLM 보안은 프롬프트, 도구, 데이터, 로그, 사람, 벤더, 모니터링을 포함합니다.
• Agentic AI는 텍스트 생성에 그치지 않고 행동을 수행할 수 있기 때문에 보안 위험을 높입니다.
• 프롬프트 인젝션에는 더 강력한 시스템 프롬프트 하나가 아니라 계층화된 방어가 필요합니다.
• 안전한 도구 호출은 최소 권한, 검증, 샌드박싱, 감사 로그에 달려 있습니다.
• EU/US 배포에서는 데이터 레지던시가 아키텍처에 설계되어야 합니다.
• HITL 통제는 위험 기반이며, 감사 가능하고, 운영상 현실적이어야 합니다.
• 테스트와 모니터링은 프로덕션 릴리스 이후에도 계속되어야 합니다.

Agentic AI에서 LLM 보안이 의미하는 것

LLM 보안은 프롬프트 안전보다 넓은 개념입니다

LLM 보안은 LLM 기반 시스템을 데이터 유출, 프롬프트 인젝션, 무단 도구 사용, 안전하지 않은 출력, 규정 준수 실패로부터 보호하는 실무입니다.

단순한 챗봇의 경우 보안은 주로 프롬프트, 출력, 사용자 데이터에 집중될 수 있습니다. Agentic AI 시스템에서는 범위가 더 넓습니다. 시스템에는 다음이 포함될 수 있습니다:

• 하나의 모델 또는 여러 모델
• 시스템 프롬프트와 정책
• RAG 파이프라인과 벡터 데이터베이스
• API와 비즈니스 도구
• 메모리 또는 세션 컨텍스트
• 로그와 모니터링 시스템
• 인간 승인 워크플로
• 제3자 모델 또는 인프라 벤더

안전한 LLM 애플리케이션은 단순히 안전한 프롬프트가 아닙니다. 모델 주변의 안전한 아키텍처입니다.

Agentic 시스템이 위험 수준을 높이는 이유

Agentic AI는 모델이 행동에 영향을 줄 수 있기 때문에 위험 프로필을 바꿉니다. 에이전트는 질문에 답하는 데 그치지 않고 다음과 같은 작업을 할 수 있습니다:

• 내부 문서 검색
• CRM API 호출
• 티켓 업데이트
• 이메일 트리거
• 코드 생성
• 고객 레코드 분석
• 도구 간 데이터 전달
• 워크플로 단계 추천 또는 실행

이는 잘못된 지시, 안전하지 않은 검색 결과, 과도한 권한 또는 약한 검증 계층이 실제 운영 영향으로 이어질 수 있음을 의미합니다. 실패 모드는 더 이상 “답변이 틀렸다”에 그치지 않습니다. “잘못된 행동이 수행되었다”가 될 수 있습니다.

프로덕션 LLM 에이전트를 위한 보안 목표

프로덕션 LLM 에이전트의 보안 목표는 명확해야 합니다. 최소한 팀은 다음을 목표로 해야 합니다:

• 무단 데이터 접근 방지
• 민감 데이터 유출 방지
• 안전하지 않거나 무단인 도구 사용 방지
• 중요한 행동에 대한 감사 로그 유지
• 고위험 워크플로에 인간 승인 적용
• 비정상 행동 조기 탐지
• 사고 대응과 롤백 지원
• 모델, 프롬프트, 도구 변경 사항의 추적 가능성 유지

이러한 목표는 보안, 제품, 엔지니어링 팀이 에이전트가 프로덕션 준비가 되었는지 평가하는 데 도움이 됩니다.

위협 모델: 프로덕션에서 LLM 에이전트가 실패하는 지점

위협 모델링은 LLM 에이전트가 고객, 직원 또는 규제 대상 데이터에 영향을 주기 전에 어떻게 실패할 수 있는지 팀이 실질적으로 이해하도록 돕습니다.

IBM의 2025년 보고서에 따르면 AI 관련 보안 사고의 60%는 데이터 침해로 이어졌고, 31%는 운영 중단을 초래했습니다. Agentic AI에서는 침해된 에이전트가 정보 노출과 비즈니스 프로세스 연속성 모두에 영향을 줄 수 있기 때문에 이러한 수치가 중요합니다.

기밀성 위험

기밀성 위험은 민감 정보가 잘못된 사용자, 도구, 벤더, 로그 또는 다운스트림 시스템에 노출될 때 발생합니다.

일반적인 예시는 다음과 같습니다:

• 프롬프트에 불필요하게 포함된 PII
• 로그에 나타나는 비밀 또는 자격 증명
• 사용자가 접근해서는 안 되는 문서를 노출하는 RAG 검색
• 숨겨진 시스템 지시를 드러내는 모델 출력
• 민감한 프롬프트를 예상보다 오래 보존하는 벤더 설정
• 명확한 승인 없이 외부 서비스로 전송되는 내부 데이터

실질적인 통제는 데이터 분류에서 시작됩니다. 팀은 에이전트가 어떤 데이터에 접근할 수 있는지, 해당 데이터가 어디에서 처리되는지, 누가 출력을 볼 수 있는지 알아야 합니다.

무결성 위험

무결성 위험은 에이전트의 행동, 추론 또는 조치가 조작될 때 발생합니다.

LLM 시스템에서 무결성 위험은 종종 프롬프트 인젝션으로 나타납니다. Agentic 시스템에서는 더 멀리 확장될 수 있습니다:

• 악성 문서가 에이전트에게 이전 지시를 무시하라고 말합니다.
• 도구 응답에 모델이 새로운 명령으로 취급하는 텍스트가 포함됩니다.
• 사용자가 에이전트를 속여 승인되지 않은 기능을 호출하게 합니다.
• 에이전트가 검증되지 않은 정보를 기반으로 레코드를 수정합니다.
• RAG 결과가 에이전트의 의사결정 경로를 바꿉니다.

무결성 통제는 신뢰할 수 있는 지시와 신뢰할 수 없는 콘텐츠를 분리하고, 도구 호출을 검증하며, 민감한 행동 전에 정책 검사를 적용하는 데 초점을 맞춰야 합니다.

가용성과 비용 위험

LLM 에이전트는 가용성과 비용 문제도 만들 수 있습니다. 예를 들어:

• 에이전트가 반복 루프에 빠집니다.
• 도구 호출이 예기치 않게 급증합니다.
• 토큰 사용량이 예산을 초과합니다.
• 모델 또는 벤더 장애가 워크플로를 중단시킵니다.
• 잘못된 형식의 입력이 반복 재시도를 유발합니다.
• 높은 지연 시간이 필요한 단계가 비즈니스 프로세스를 막습니다.

과도한 모델 사용이 예상치 못한 비용을 만들 때 이를 “지갑 거부(denial of wallet)”라고 부르기도 합니다. 프로덕션 에이전트에는 속도 제한, 시간 제한, 재시도 제한, 예산 통제, 알림이 필요합니다.

규정 준수 위험

EU/US 배포에서 규정 준수 위험은 대개 불명확한 데이터 처리와 약한 거버넌스에서 비롯됩니다.

예시는 다음과 같습니다:

• 문서화된 데이터 흐름이 없음
• 처리 지역이 불명확함
• 프롬프트와 로그에 대한 약한 보존 설정
• 고위험 행동에 대한 감사 추적이 없음
• 민감한 워크플로에 대한 인간 감독이 없음
• 벤더/하위 처리자 검토가 없음
• AI 관련 실패에 대한 사고 대응 계획이 없음

보안 및 규정 준수 팀은 에이전트가 이미 비즈니스 워크플로에 내장된 후가 아니라 출시 전에 이러한 위험을 검토해야 합니다.

프롬프트 인젝션 및 간접 인젝션 통제

직접 프롬프트 인젝션

직접 프롬프트 인젝션은 사용자가 의도적으로 모델의 지시를 조작하려고 할 때 발생합니다. 사용자는 모델에게 시스템 규칙을 무시하거나, 숨겨진 컨텍스트를 공개하거나, 정책을 우회하거나, 허용 범위를 벗어난 행동을 수행하라고 요청할 수 있습니다.

기본 챗봇에서는 직접 인젝션이 안전하지 않거나 부정확한 답변으로 이어질 수 있습니다. AI 에이전트에서는 도구 오용, 데이터 노출 또는 무단 워크플로 실행으로 이어질 수 있습니다.

OWASP는 OWASP Top 10 for LLM Applications에서 Prompt Injection을 주요 LLM 애플리케이션 위험으로 제시합니다. 그렇기 때문에 민감 데이터나 비즈니스 행동을 처리하는 모든 LLM 워크플로의 릴리스 프로세스에는 인젝션 테스트가 포함되어야 합니다.

간접 프롬프트 인젝션

간접 프롬프트 인젝션은 에이전트가 읽는 콘텐츠 안에 악성 지시가 숨겨져 있을 때 발생합니다. 이 콘텐츠는 다음에서 올 수 있습니다:

• 웹페이지
• 이메일
• 업로드된 파일
• PDF
• 티켓
• 채팅 기록
• RAG 결과
• 도구 응답
• 공유 문서

이는 Agentic AI에서 특히 중요합니다. 에이전트는 다음에 무엇을 할지 결정하기 전에 외부 또는 반신뢰 콘텐츠를 소비하는 경우가 많기 때문입니다.

간접 인젝션이 에이전트에 위험한 이유

간접 인젝션은 악성 지시가 사용자에게서 직접 오지 않기 때문에 위험합니다. 이는 에이전트가 처리하도록 요청받은 데이터 안에 나타납니다.

예를 들어, 에이전트가 내부 정책을 공개하거나, 우선순위 필드를 변경하거나, 다른 도구를 호출하라는 숨겨진 지시가 포함된 지원 티켓을 읽을 수 있습니다. 시스템이 검색된 콘텐츠를 신뢰할 수 있는 지시로 취급하면 에이전트는 이를 따를 수 있습니다.

핵심 원칙은 간단합니다: 외부 콘텐츠는 권한이 아니라 데이터로 취급해야 합니다.

방어 통제

프롬프트 인젝션 완화에는 계층화된 통제를 사용해야 합니다:

• 시스템 지시를 사용자 및 도구 콘텐츠와 분리합니다.
• 검색된 문서를 신뢰할 수 없는 데이터로 취급합니다.
• 개방형 도구 접근 대신 도구 허용 목록을 사용합니다.
• 서버 측에서 도구 인수를 검증합니다.
• 도구 호출에는 구조화된 출력을 요구합니다.
• 민감한 행동 전에 정책 검사를 추가합니다.
• 역할과 워크플로에 따라 에이전트 권한을 제한합니다.
• 외부 콘텐츠를 사용하기 전에 정제하거나 격리합니다.
• 영향이 큰 행동에는 승인 게이트를 추가합니다.
• 의심스러운 프롬프트 패턴과 차단된 시도를 모니터링합니다.

단일 통제만으로는 충분하지 않습니다. 강력한 시스템 프롬프트는 도움이 되지만 유일한 보안 경계가 되어서는 안 됩니다.

단독으로 의존해서는 안 되는 것

팀은 다음에만 의존하는 것을 피해야 합니다:

• 일반적인 “규칙을 어기지 마세요” 시스템 프롬프트
• 키워드 필터
• 로그 없는 수동 검토
• 단일 모델 안전 설정
• 모든 RAG 콘텐츠를 신뢰하는 것
• 에이전트에 광범위한 API 권한을 부여하는 것
• 사용자가 적대적 입력을 시도하지 않을 것이라고 가정하는 것

LLM 보안은 프롬프트, 검색된 콘텐츠, 도구 출력이 조작될 수 있다고 가정해야 합니다.

안전한 도구 호출과 최소 권한 접근

도구 호출이 보안 모델을 바꾸는 이유

도구 호출은 일반적인 LLM 챗봇과 Agentic AI 시스템의 가장 큰 차이 중 하나입니다.

챗봇은 텍스트를 생성합니다. 도구가 있는 에이전트는 부작용을 만들 수 있습니다. 데이터베이스를 검색하고, 이메일을 보내고, CRM 필드를 업데이트하고, 지원 티켓을 생성하고, 스크립트를 실행하거나 내부 워크플로를 트리거할 수 있습니다.

이는 모델 출력이 가능한 시스템 행동이 된다는 의미입니다. 보안 통제는 텍스트 계층뿐 아니라 행동 계층을 보호해야 합니다.

프로덕션에서 흔한 도구 호출 위험

일반적인 위험은 다음과 같습니다:

• 에이전트가 접근해서는 안 되는 도구를 호출합니다.
• 에이전트가 민감 데이터를 잘못된 도구로 보냅니다.
• 에이전트가 올바른 도구를 안전하지 않은 인수와 함께 사용합니다.
• 에이전트가 도구 호출을 반복해 비용 또는 가용성 문제를 만듭니다.
• 도구 응답에 악성 지시가 포함됩니다.
• 도구가 워크플로에 필요한 것보다 넓은 권한을 가집니다.
• 프롬프트 또는 도구 출력을 통해 비밀이 모델에 노출됩니다.
• 도구 행동을 사용자, 에이전트 또는 승인으로 추적할 수 없습니다.

OWASP는 또한 도구를 호출하거나 외부 시스템과 상호 작용할 수 있는 시스템에서 특히 Excessive Agency를 주요 LLM 애플리케이션 위험으로 강조합니다. 이 문제는 흔히 과도한 기능, 과도한 권한 또는 과도한 자율성에 뿌리를 둡니다. 이는 광범위한 도구 접근 권한을 가진 프로덕션 에이전트와 직접 연결됩니다.

LLM 에이전트를 위한 최소 권한 접근

최소 권한은 에이전트가 특정 작업에 필요한 권한만 가져야 한다는 의미입니다.

예를 들어 고객 지원 응답을 초안 작성하는 에이전트는 티켓 이력에 대한 읽기 접근이 필요할 수 있지만, 환불 처리, 계정 삭제 또는 청구 기록 변경 권한은 필요하지 않을 수 있습니다. 행동이 고위험이라면 에이전트는 이를 초안 작성하거나 추천하고, 인간이 승인해야 합니다.

실질적인 최소 권한 모델은 다음을 정의해야 합니다:

• 에이전트가 사용할 수 있는 도구
• 허용되는 작업
• 허용되는 데이터 범위
• 워크플로를 트리거할 수 있는 사용자 또는 역할
• 승인이 필요한 행동
• 완전히 차단되는 행동

가능하면 각 에이전트에는 자체 서비스 ID가 있어야 합니다. 공유 관리자 자격 증명을 통해 에이전트에 광범위한 접근 권한을 부여하는 것은 피해야 합니다.

도구 허용 목록, 범위, 정책 검사

프로덕션 에이전트가 무제한 도구 중에서 선택하도록 해서는 안 됩니다. 도구 접근은 허용 목록화되고 범위가 제한되어야 합니다.

유용한 통제는 다음과 같습니다:

• 에이전트 유형별 도구 허용 목록
• 워크플로별 API 범위
• 도구별 속도 제한
• 실행 전 정책 검사
• 개발, 스테이징, 프로덕션 간 환경 분리
• 민감한 작업에 대한 승인 검사
• 컨텍스트가 불명확할 때 기본 거부 동작

정책 계층은 행동이 발생하기 전에 도구 호출이 허용되는지 결정할 수 있습니다. 이는 고객 데이터, 재무 영향, 법적 영향, 보안 영향 또는 외부 커뮤니케이션과 관련된 행동에 특히 유용합니다.

인수 검증과 출력 검증

도구 호출은 구조화된 스키마를 사용해야 합니다. 에이전트가 민감한 API에 임의의 자유 형식 인수를 전달해서는 안 됩니다.

예를 들어:

• ID는 예상 형식과 일치해야 합니다.
• 금액은 승인된 한도 내에 있어야 합니다.
• 이메일 수신자는 허용된 도메인 또는 검증된 연락처와 일치해야 합니다.
• 파일 경로는 허용된 위치 안에 머물러야 합니다.
• 필수 필드가 누락되면 도구 호출은 안전하게 실패해야 합니다.

도구 출력도 신중하게 다뤄야 합니다. 도구 응답에는 신뢰할 수 없는 텍스트, 잘못된 형식의 데이터 또는 삽입된 지시가 포함될 수 있습니다. 모델은 도구 출력을 새로운 권한 출처가 아니라 데이터로 사용해야 합니다.

고위험 도구 샌드박싱

일부 도구에는 격리가 필요합니다. 예시는 다음과 같습니다:

• 코드 실행
• 웹 브라우징
• 파일 처리
• 문서 수집
• 데이터 변환
• 외부 부작용이 있는 워크플로 자동화

샌드박싱은 에이전트가 예기치 않게 행동할 때 피해를 제한하는 데 도움이 됩니다. 사용 사례에 따라 샌드박싱에는 네트워크 제한, 파일 시스템 제한, 실행 시간 제한, 메모리 제한, 별도 자격 증명, 제한된 환경이 포함될 수 있습니다.

에이전트 워크플로를 위한 비밀 관리

비밀은 프롬프트, 모델 컨텍스트 또는 일반 텍스트 로그에 배치해서는 안 됩니다. 에이전트는 안전한 백엔드 서비스를 통해서만 비밀에 접근해야 합니다.

좋은 실무는 다음과 같습니다:

• 비밀을 시크릿 매니저에 저장합니다.
• 자격 증명을 프롬프트 템플릿에서 제외합니다.
• 로그에서 비밀을 마스킹합니다.
• 자격 증명을 정기적으로 교체합니다.
• 가능하면 수명이 짧은 토큰을 사용합니다.
• 환경별로 자격 증명을 분리합니다.
• 원시 API 키가 모델 출력이나 도구 응답에 노출되지 않도록 합니다.

모델은 행동을 요청해야 하지만, 백엔드는 권한 부여를 적용하고 안전한 작업을 수행해야 합니다.

도구 호출을 위한 감사 로깅

모든 중요한 도구 호출은 로깅되어야 합니다. 로그는 다음 질문에 답하는 데 도움이 되어야 합니다:

• 어떤 사용자가 워크플로를 트리거했나요?
• 어떤 에이전트가 결정을 내렸나요?
• 어떤 도구가 호출되었나요?
• 어떤 행동이 요청되었나요?
• 해당 행동이 승인되었나요?
• 결과는 무엇이었나요?
• 민감 데이터가 관련되었나요?
• 행동이 차단, 재시도 또는 롤백되었나요?

EU/US 엔터프라이즈 환경에서는 감사 가능성이 예방만큼 중요한 경우가 많습니다. 문제가 발생하면 조직은 무슨 일이 일어났는지 재구성할 수 있어야 합니다.

EU/US 배포를 위한 데이터 레지던시와 개인정보 보호

데이터 맵에서 시작하세요

데이터 레지던시는 데이터 흐름을 이해하는 것에서 시작됩니다. 모델 제공자나 아키텍처를 선택하기 전에 팀은 다음을 매핑해야 합니다:

• 프롬프트에 어떤 데이터가 들어가는지
• 내부 시스템에서 어떤 데이터가 검색되는지
• 모델 제공자에게 어떤 데이터가 전송되는지
• 벡터 데이터베이스에 어떤 데이터가 임베딩되는지
• 어떤 데이터가 로깅되는지
• 데이터가 얼마나 오래 보존되는지
• 각 구성 요소가 어느 지역에서 처리되거나 저장되는지
• 어떤 벤더 또는 하위 처리자가 관여하는지

데이터 맵이 없으면 보안 및 규정 준수 검토는 추측이 됩니다.

IBM은 또한 침해를 겪은 조직의 63%가 AI 거버넌스 정책이 없거나 아직 개발 중이었다고 보고했습니다. EU/US 배포에서는 이러한 거버넌스 격차가 불명확한 데이터 흐름, 약한 보존 결정, 불완전한 벤더 검토 또는 shadow AI 주변의 누락된 통제로 나타나는 경우가 많습니다.

EU 고려 사항

EU 배포의 경우 팀은 일반적으로 데이터 최소화, 목적 제한, 접근 제어, 보존, 국경 간 이전 검토와 같은 개인정보 보호 원칙을 고려해야 합니다. 구체적인 의무는 조직, 사용 사례, 데이터 유형, 법적 근거에 따라 달라집니다.

실질적인 아키텍처 질문은 다음과 같습니다:

• 프롬프트를 구성하기 전에 민감 데이터를 최소화할 수 있는가?
• 추론을 특정 지역에 고정할 수 있는가?
• 로그가 올바른 지역에 저장되는가?
• 이 사용 사례에서 임베딩이 민감한 것으로 간주되는가?
• 고객 데이터를 제공자 학습에서 제외할 수 있는가?
• 삭제 및 보존 설정을 구성할 수 있는가?

법적 해석은 게시 또는 구현 결정을 내리기 전에 자격을 갖춘 법률 전문가의 검토를 받아야 합니다.

US 고려 사항

US 배포는 산업에 따라 부문별 기대 사항이 포함될 수 있습니다. 헬스케어, 금융, 교육, 공공 부문, 엔터프라이즈 SaaS 환경은 접근 통제, 감사 로그, 보존, 벤더 위험 관리에 대해 더 엄격한 기대치를 갖는 경우가 많습니다.

규정이 LLM을 명시적으로 언급하지 않더라도, 구매자는 SOC 2 또는 ISO/IEC 27001과 같은 엔터프라이즈 프레임워크에 맞춘 보안 통제를 기대할 수 있습니다.

레지던시에 민감한 LLM 시스템을 위한 아키텍처 패턴

일반적인 패턴은 다음과 같습니다:

• 지역별 모델 엔드포인트
• 지역별 벡터 저장소
• 사용 가능한 경우 프라이빗 네트워킹
• 고객 관리 암호화 키
• 모델 호출 전 데이터 마스킹
• 프롬프트 구성 전 PII 탐지
• 별도의 EU 및 US 환경
• 프롬프트와 출력에 대한 짧은 보존 기간
• 운영 메타데이터와 민감 콘텐츠를 분리하는 로깅 계층
• 임베딩과 검색된 문서에 대한 접근 통제

목표는 불필요한 데이터 이동을 줄이고, 피할 수 없는 데이터 이동을 가시적이고 통제 가능하며 문서화된 상태로 만드는 것입니다.

벤더 실사 체크리스트

LLM 제공자 또는 AI 인프라 벤더를 사용하기 전에 팀은 다음을 질문해야 합니다:

• 데이터는 어디에서 처리되는가?
• 데이터는 어디에 저장되는가?
• 고객 데이터가 학습에 사용되는가?
• 어떤 보존 통제가 제공되는가?
• 어떤 하위 처리자가 관여하는가?
• 엔터프라이즈 보안 통제를 지원하는가?
• 감사 로그를 사용할 수 있는가?
• 요청 시 데이터를 삭제할 수 있는가?
• 프라이빗 네트워킹 또는 지역 고정 옵션을 사용할 수 있는가?
• 사고 대응 중에는 어떤 일이 발생하는가?

벤더 설정은 LLM 시스템의 보안 태세를 실질적으로 바꿀 수 있습니다. 프로덕션 사용 전에 검토되어야 합니다.

HITL 통제: 속도를 죽이지 않는 인간 감독

HITL은 위험 기반이어야 합니다

휴먼 인 더 루프(Human-in-the-loop)는 모든 에이전트 행동에 수동 승인이 필요하다는 뜻이 아닙니다. 그렇게 하면 대부분의 워크플로가 너무 느려집니다. 또한 모든 행동이 자동화되어야 한다는 뜻도 아닙니다.

올바른 접근 방식은 위험 기반입니다. 저위험 행동은 로깅하고 모니터링할 수 있습니다. 중간 위험 행동은 샘플링, 규칙 기반 검사 또는 특정 조건에서의 승인이 필요할 수 있습니다. 고위험 행동은 명시적인 인간 검토가 필요해야 합니다.

제안 위험 등급

위험 등급	에이전트 행동 예시	제안 통제
낮음	내부 요약 초안 작성	로그만 기록
중간	중요하지 않은 CRM 필드 업데이트	규칙 기반 검증 또는 샘플 검토
높음	고객 대상 메시지 전송	인간 승인 필요
치명적	결제, 계정 삭제, 법적/보안 영향이 있는 행동	인간 승인과 2차 통제

이 구조를 통해 팀은 영향이 큰 결정은 통제하면서도 속도를 유지할 수 있습니다.

HITL을 감사 준비 상태로 만드는 통제

유용한 HITL 워크플로는 다음을 캡처해야 합니다:

• 검토자 ID
• 승인 또는 거부 결정
• 결정 사유
• 원래 에이전트 추천
• 수행된 최종 행동
• 관련되는 경우 전/후 상태
• 타임스탬프
• 에스컬레이션 경로
• 롤백 옵션

이러한 기록이 없으면 HITL은 운영적으로는 도움이 될 수 있지만 감사 또는 사고 검토를 지원하지 못할 수 있습니다.

킬 스위치를 추가해야 하는 시점

킬 스위치를 사용하면 팀이 에이전트를 중지하거나 특정 도구 행동을 빠르게 비활성화할 수 있습니다.

팀은 다음과 같은 경우 킬 스위치를 고려해야 합니다:

• 예기치 않은 도구 호출량
• 반복되는 검증 실패
• 의심스러운 인젝션 시도
• 민감 데이터 노출
• 비용 급증
• 모델/벤더 장애
• 반복되는 낮은 신뢰도 결정
• 비정상적인 사용자 불만 또는 지원 에스컬레이션

킬 스위치는 출시 전에 테스트되어야 합니다. 이론상의 통제로만 존재해서는 안 됩니다.

프로덕션 전 LLM 에이전트 테스트와 모니터링

전통적인 QA만으로는 충분하지 않습니다

전통적인 QA는 대부분 결정론적 동작을 가정합니다. LLM 에이전트는 다릅니다. 출력은 달라질 수 있고, 추론 경로는 바뀔 수 있으며, 행동은 검색된 데이터, 도구 응답, 사용자 컨텍스트, 모델 설정에 따라 달라질 수 있습니다.

따라서 에이전트 테스트에는 기능 평가와 보안 평가가 모두 포함되어야 합니다. 워크플로가 정상 경로 테스트를 통과하더라도 적대적 입력, 특이한 문서, 잘못된 형식의 도구 응답 또는 권한 경계 사례에서 실패할 수 있습니다.

핵심 테스트 유형

프로덕션 준비 테스트 계획에는 다음이 포함되어야 합니다:

• 작업 성공 테스트
• 프롬프트 인젝션 테스트
• 간접 인젝션 테스트
• 도구 권한 테스트
• 도구 인수 검증 테스트
• 데이터 유출 테스트
• RAG 검색 접근 테스트
• HITL 워크플로 테스트
• 회귀 테스트
• 비용 및 지연 시간 테스트
• 실패 모드 테스트
• 롤백 및 킬 스위치 테스트

보안 테스트에는 인위적인 프롬프트뿐만 아니라 현실적인 비즈니스 워크플로가 포함되어야 합니다.

평가 하네스 구축

평가 하네스는 팀이 릴리스 전에 에이전트를 일관되게 테스트하도록 돕습니다. 여기에는 다음이 포함되어야 합니다:

• 버전 관리되는 테스트 사례 세트
• 예상 결과 또는 채점 기준
• 적대적 예시
• 현실적인 사용자 작업
• 도구 사용 시나리오
• 정책 위반 검사
• 모델 또는 프롬프트 변경 전반의 회귀 추적
• 엔지니어링, 보안, 제품 팀이 검토할 수 있는 보고서

하네스는 주요 릴리스 전과 프롬프트, 도구, 모델, 검색 로직 또는 정책 규칙이 변경될 때마다 실행되어야 합니다.

출시 전에 정의할 모니터링 신호

모니터링은 에이전트가 라이브로 전환되기 전에 설계되어야 합니다. 유용한 신호는 다음과 같습니다:

• 도구 호출 빈도
• 실패한 검증
• 차단된 행동
• HITL 승인 및 거부율
• 반복 재시도
• 토큰 및 비용 이상
• 지연 시간 급증
• 민감 데이터 탐지
• 의심스러운 프롬프트 패턴
• 예상치 못한 데이터 접근
• 사용자 불만
• 정책 위반 시도

이러한 신호는 알림, 대시보드, 사고 대응 워크플로로 연결되어야 합니다.

릴리스 후 프로덕션 모니터링

테스트는 출시에서 끝나지 않습니다. 데이터, 도구, 프롬프트, 모델, 사용자 행동이 변하면서 LLM 에이전트는 드리프트할 수 있습니다.

이 라이프사이클 관점은 AI 위험 작업을 거버넌스, 매핑, 측정, 관리 중심으로 구성하는 NIST AI Risk Management Framework와 일치합니다. LLM 에이전트의 경우 팀은 배포 전에 위험을 매핑하고, 평가와 모니터링을 통해 동작을 측정하며, 알림, 롤백 경로, 사고 대응을 통해 실패를 관리해야 함을 의미합니다.

릴리스 후 팀은 다음을 검토해야 합니다:

• 에이전트가 여전히 작업 성공 목표를 충족하는지
• 보안 차단이 증가하고 있는지
• HITL 검토자가 에이전트를 자주 재정의하는지
• 비용 패턴이 안정적인지
• 사용자가 새로운 실패 모드를 발견하고 있는지
• 모델 또는 벤더 변경이 동작에 영향을 주는지

프로덕션 모니터링은 LLM 보안을 일회성 체크리스트에서 지속적인 운영 실무로 전환합니다.

안전한 출시를 위한 LLM 보안 체크리스트

아키텍처 통제

출시 전에 다음을 확인하세요:

• 데이터 흐름이 매핑되어 있습니다.
• 민감 데이터 클래스가 식별되어 있습니다.
• 도구 권한이 문서화되어 있습니다.
• RAG 접근 통제가 테스트되어 있습니다.
• 모델 및 벤더 설정이 검토되어 있습니다.
• 지역 및 보존 설정이 확인되어 있습니다.
• 비밀이 프롬프트와 로그에서 제외되어 있습니다.
• 환경이 분리되어 있습니다.

보안 통제

다음을 확인하세요:

• 프롬프트 인젝션 방어가 테스트되어 있습니다.
• 간접 인젝션 사례가 평가에 포함되어 있습니다.
• 도구 허용 목록이 적용되어 있습니다.
• 도구 인수가 서버 측에서 검증됩니다.
• 도구 출력이 신뢰할 수 없는 데이터로 취급됩니다.
• 최소 권한 접근이 적용됩니다.
• 고위험 행동에 게이트가 적용됩니다.
• 감사 로그가 활성화되어 있습니다.
• 속도 제한과 시간 제한이 구성되어 있습니다.

규정 준수 통제

다음을 확인하세요:

• 데이터 보존이 문서화되어 있습니다.
• 벤더/하위 처리자 검토가 완료되어 있습니다.
• 인간 감독 정책이 정의되어 있습니다.
• 고위험 워크플로가 감사 가능합니다.
• 접근 통제가 역할 기반입니다.
• 사고 대응 단계가 문서화되어 있습니다.
• 삭제 및 데이터 접근 프로세스가 이해되어 있습니다.
• 법무 및 규정 준수 팀이 관련 요구 사항을 검토했습니다.

릴리스 통제

다음을 확인하세요:

• 평가 스위트가 통과되었습니다.
• 회귀 테스트가 완료되었습니다.
• 보안 테스트 사례가 검토되었습니다.
• 모니터링 알림이 구성되었습니다.
• 롤백 경로가 테스트되었습니다.
• 킬 스위치가 테스트되었습니다.
• 릴리스 후 소유자가 지정되었습니다.
• 검토 주기가 예정되어 있습니다.

안전한 출시는 단순한 기술적 이정표가 아닙니다. 이는 운영상의 약속입니다.

HDWEBSOFT가 팀의 LLM 및 Agentic AI 시스템 보안을 지원하는 방법

LLM 기반 에이전트를 안전하게 출시하려면 AI 엔지니어링과 보안 사고가 모두 필요합니다. 팀은 제공 속도를 불필요하게 늦추지 않으면서 워크플로를 설계하고, 도구를 통합하고, 데이터를 보호하고, 동작을 테스트하고, 프로덕션 시스템을 모니터링해야 합니다.

HDWEBSOFT는 실질적인 엔지니어링 지원으로 팀이 AI 시스템을 계획, 구축, 보호하도록 돕습니다. 조직이 LLM 또는 Agentic AI 롤아웃을 준비하고 있다면, 저희 팀은 아키텍처 설계, AI 워크플로 구현, 도구 통합, 보안 검토, 프로덕션 준비를 지원할 수 있습니다.

안전한 AI 구현을 위한 AI 개발 서비스와 보안 평가, 위험 검토, 더 강력한 프로덕션 통제를 위한 사이버 보안 서비스를 살펴보세요.

결론

LLM 보안은 하나의 프롬프트, 하나의 정책 또는 하나의 체크리스트가 아닙니다. Agentic AI에서는 프롬프트, 검색된 데이터, 도구, 권한, 로그, 인간 승인, 테스트, 프로덕션 모니터링까지 전체 시스템을 포괄해야 합니다.

안전하게 출시하는 팀은 처음부터 보안을 아키텍처의 일부로 다루는 팀입니다. 프롬프트 인젝션 통제, 최소 권한 도구 접근, 데이터 레지던시 계획, HITL 워크플로, 지속적 평가는 모두 함께 작동하여 위험을 줄입니다.

EU/US 프로덕션 환경에서 목표는 에이전트를 유용하게 만드는 것만이 아닙니다. 목표는 에이전트를 통제 가능하고, 감사 가능하며, 회복력 있고, 실제 비즈니스 워크플로에서 운영하기에 충분히 안전하게 만드는 것입니다.

FAQ

LLM 보안이란 무엇인가요?

LLM 보안은 LLM 기반 시스템을 프롬프트 인젝션, 데이터 유출, 무단 도구 사용, 안전하지 않은 출력, 규정 준수 실패로부터 보호하는 실무입니다. Agentic AI의 경우 도구 권한, 감사 로그, HITL 워크플로, 테스트, 모니터링도 포함됩니다.

AI 에이전트에서 LLM 보안이 더 어려운 이유는 무엇인가요?

AI 에이전트는 행동을 수행할 수 있기 때문에 LLM 보안이 더 어렵습니다. 에이전트는 문서를 검색하고, API를 호출하고, 시스템을 업데이트하거나 워크플로를 트리거할 수 있습니다. 따라서 보안은 모델 출력뿐 아니라 에이전트에 연결된 도구와 데이터까지 보호해야 합니다.

LLM 에이전트에서 프롬프트 인젝션을 어떻게 방지하나요?

프롬프트 인젝션 방지는 계층화된 통제가 필요합니다. 팀은 신뢰할 수 있는 지시와 신뢰할 수 없는 콘텐츠를 분리하고, 도구 호출을 검증하고, 최소 권한 접근을 적용하고, 검색된 콘텐츠를 데이터로 취급하고, 정책 검사를 추가하고, 의심스러운 패턴을 모니터링하며, 적대적 사례로 테스트해야 합니다.

간접 프롬프트 인젝션이란 무엇인가요?

간접 프롬프트 인젝션은 웹페이지, 이메일, 문서, 지원 티켓, PDF, RAG 결과처럼 에이전트가 읽는 콘텐츠 안에 악성 지시가 숨겨져 있을 때 발생합니다. 시스템이 이를 격리하고 검증하도록 설계되지 않았다면 에이전트는 해당 콘텐츠를 지시로 취급할 수 있습니다.

LLM 에이전트를 위한 도구 호출은 어떻게 안전하게 보호하나요?

안전한 도구 호출에는 최소 권한 접근, 범위가 제한된 API, 도구 허용 목록, 구조화된 스키마, 서버 측 인수 검증, 출력 검증, 속도 제한, 고위험 도구를 위한 샌드박싱, 비밀 관리, 도구 작업에 대한 감사 로깅이 필요합니다.

데이터 레지던시는 LLM 애플리케이션에 어떤 영향을 주나요?

데이터 레지던시는 프롬프트, 검색된 문서, 임베딩, 출력, 로그가 처리되고 저장되는 위치에 영향을 줍니다. EU/US 배포에서는 데이터 흐름을 매핑하고, 벤더 설정을 검토하고, 보존 정책을 구성하며, 개인정보 보호 및 규정 준수 요구 사항에 맞는 아키텍처 패턴을 선택해야 합니다.

LLM 에이전트를 배포하기 전에 팀은 무엇을 테스트해야 하나요?

팀은 작업 성공률, 프롬프트 인젝션 저항성, 간접 인젝션 시나리오, 도구 권한, 데이터 유출, RAG 접근 제어, HITL 승인 흐름, 회귀 동작, 모니터링 알림, 지연 시간, 비용 동작, 롤백 경로, 킬 스위치 동작을 테스트해야 합니다.