이 페이지는 AI 에이전트란? 가이드의 이어지는 내용입니다. 에이전트 개념, 구성 요소, 아키텍처 패턴, 메모리 관리는 이전 페이지를 참고하세요.
에이전트 보안 설계
프로덕션 에이전트는 실제 시스템에 접근하므로, 보안이 매우 중요합니다. 잘못 설계하면 데이터 유출이나 의도치 않은 시스템 변경이 발생할 수 있습니다.도구 접근 제어
| 보안 원칙 | 설명 | 구현 방법 |
|---|---|---|
| 최소 권한 원칙 | 에이전트에 필요한 최소한의 도구만 부여합니다 | Unity Catalog Functions에서 GRANT로 도구별 권한 제어 |
| 읽기/쓰기 분리 | 조회 도구와 변경 도구를 분리합니다 | 읽기 전용 에이전트와 쓰기 가능 에이전트를 별도 엔드포인트로 분리 |
| 승인 기반 실행 | 위험한 작업(삭제, 결제 등)은 인간 승인을 필수로 합니다 | Human-in-the-loop 패턴 적용 |
| 도구 호출 제한 | 한 세션에서 도구를 호출할 수 있는 최대 횟수를 제한합니다 | 무한 루프 방지를 위해 max_iterations 설정 |
데이터 유출 방지 (Data Exfiltration Prevention)
| 위험 | 시나리오 | 방어 방법 |
|---|---|---|
| 프롬프트 인젝션 | 악의적 입력으로 시스템 프롬프트를 우회합니다 | 입력 필터링, Guardrails, 시스템 프롬프트와 사용자 입력 분리 |
| 민감 데이터 노출 | 에이전트가 답변에 PII(개인정보)를 포함합니다 | 출력 필터링(정규식, NER 기반 마스킹) |
| 도구 체인 공격 | 에이전트가 여러 도구를 조합하여 의도하지 않은 데이터를 추출합니다 | 도구 간 데이터 흐름 모니터링, 조합 제한 |
| 간접 프롬프트 인젝션 | 검색된 문서에 악의적 명령이 포함되어 있습니다 | RAG 소스 데이터 검증, 검색 결과와 명령 분리 |
MLflow Tracing 기반 보안 감사
프로덕션 SLA 설계
에이전트를 프로덕션에 배포할 때는 가용성, 지연시간, 비용을 명확히 정의하고 관리해야 합니다.지연시간(Latency) 최적화
| 최적화 전략 | 설명 | 예상 효과 |
|---|---|---|
| LLM 선택 | 작업 복잡도에 맞는 모델 크기를 선택합니다 | 소형 모델은 2~5x 빠름 |
| 스트리밍 응답 | 토큰 단위로 실시간 스트리밍하여 체감 지연을 줄입니다 | 첫 토큰까지 시간(TTFT) 단축 |
| 도구 병렬 호출 | 독립적인 도구를 동시에 호출합니다 | 도구가 3개면 지연이 1/3로 감소 |
| 검색 결과 캐싱 | 자주 묻는 질문의 Vector Search 결과를 캐싱합니다 | 검색 지연 제거 |
| 프롬프트 최적화 | 시스템 프롬프트를 간결하게 유지합니다 | 토큰 처리 시간 감소 |
가용성 및 확장성
| 설계 항목 | 권장 설정 | 이유 |
|---|---|---|
| Model Serving 엔드포인트 | Provisioned Throughput 사용 | 트래픽 급증 시에도 안정적인 지연시간 보장 |
| 자동 스케일링 | min_instances=2, max_instances=10 | 고가용성 유지 + 트래픽 대응 |
| 헬스 체크 | 30초 간격으로 엔드포인트 상태 확인 | 장애 조기 발견 |
| 타임아웃 설정 | 도구 호출 30초, 전체 응답 120초 | 무한 대기 방지 |
| 재시도 전략 | 최대 3회, 지수 백오프 | 일시적 오류 복구 |
비용 예산 관리
에이전트 비용은 주로 LLM 토큰 소비와 Model Serving 인프라에서 발생합니다.| 비용 요소 | 산정 방법 | 최적화 전략 |
|---|---|---|
| LLM 토큰 | 입력 토큰 + 출력 토큰 x 단가 | 프롬프트 압축, 불필요한 컨텍스트 제거 |
| Model Serving | 인스턴스 수 x 시간 x DBU 단가 | Provisioned Throughput 적정 사이징 |
| Vector Search | 엔드포인트 + 쿼리 수 | 캐싱, 배치 쿼리 |
| 도구 호출 | SQL Warehouse 쿼리 수, API 호출 수 | 불필요한 도구 호출 최소화 |
비용 모니터링: Inference Tables에 기록되는 토큰 사용량을 SQL로 조회하여 일별/주별 비용 트렌드를 대시보드로 관리하세요. 예상치를 초과하면 즉시 알림을 받도록 설정합니다.
에이전트 디버깅 전략
에이전트는 비결정적(non-deterministic)이므로, 전통적인 소프트웨어 디버깅과 다른 접근이 필요합니다.MLflow Tracing 활용
MLflow Tracing은 에이전트의 실행 흐름을 단계별로 추적할 수 있는 핵심 도구입니다.| 추적 대상 | 확인 가능한 정보 |
|---|---|
| LLM 호출 | 입력 프롬프트, 출력 텍스트, 토큰 수, 지연시간 |
| 도구 호출 | 호출된 도구 이름, 파라미터, 반환값, 실행 시간 |
| 검색(Retrieval) | 검색 쿼리, 반환된 문서, 유사도 점수 |
| 전체 체인 | 각 단계의 순서, 소요 시간, 오류 발생 지점 |
일반적인 실패 모드와 디버깅 방법
| 실패 모드 | 증상 | 디버깅 방법 |
|---|---|---|
| 도구 선택 오류 | 잘못된 도구를 호출하거나 도구를 호출하지 않습니다 | Tracing에서 LLM의 reasoning 확인 → 도구 설명(description) 개선 |
| 파라미터 추출 오류 | 올바른 도구를 선택하지만 잘못된 파라미터를 전달합니다 | 도구의 파라미터 스키마를 더 명확하게 정의 |
| 무한 루프 | 같은 도구를 반복 호출합니다 | max_iterations 설정, 루프 감지 로직 추가 |
| 환각 응답 | 도구 결과를 무시하고 지어낸 답변을 반환합니다 | 시스템 프롬프트에 “도구 결과만 사용하라”는 지시 강화 |
| 컨텍스트 유실 | 긴 대화에서 초반 맥락을 잊습니다 | 메모리 관리 전략 개선(요약 기반 압축) |
체계적 평가 파이프라인
프로덕션 모니터링 체크리스트
| 모니터링 항목 | 임계값 예시 | 알림 조건 |
|---|---|---|
| P50 응답 지연시간 | < 5초 | P50 > 8초 시 경고 |
| P99 응답 지연시간 | < 30초 | P99 > 60초 시 경고 |
| 도구 호출 실패율 | < 1% | > 5% 시 긴급 |
| 사용자 피드백 비율 | > 80% | < 60% 시 경고 |
| 일일 토큰 소비량 | 예산 이내 | 예산 120% 초과 시 경고 |
| 환각 비율 | < 5% | > 10% 시 긴급 |
정리
| 핵심 개념 | 설명 |
|---|---|
| AI 에이전트 | LLM을 두뇌로, 도구를 수족으로 사용하여 자율적으로 작업을 수행하는 시스템입니다 |
| ReAct 패턴 | 생각(Reasoning) → 행동(Acting) → 관찰(Observation)의 반복 루프입니다 |
| RAG | 문서 검색 → LLM 답변 생성. 내부 데이터 기반 정확한 답변에 필수적입니다 |
| Tool | 에이전트가 호출하는 외부 기능. DB 조회, API 호출, 코드 실행 등입니다 |
| 환각(Hallucination) | LLM이 근거 없이 그럴듯한 답변을 생성하는 현상. RAG로 완화합니다 |
| 아키텍처 패턴 | Single Agent → Multi-Agent → Supervisor 순으로 복잡도가 증가합니다 |
| 메모리 관리 | 단기(세션 내)와 장기(세션 간) 메모리를 적절히 조합해야 합니다 |
| 보안 | 최소 권한, PII 마스킹, 프롬프트 인젝션 방어가 프로덕션 필수 요소입니다 |
| SLA 설계 | 지연시간, 가용성, 비용을 정량적으로 정의하고 모니터링해야 합니다 |