ai-agents-for-beginners

프로덕션 환경에서의 AI 에이전트: 관찰 가능성과 평가

프로덕션 환경에서의 AI 에이전트

AI 에이전트가 실험적 프로토타입에서 실제 애플리케이션으로 전환됨에 따라, 이들의 행동을 이해하고 성능을 모니터링하며 출력물을 체계적으로 평가하는 능력이 중요해지고 있습니다.

학습 목표

이 강의를 완료한 후, 여러분은 다음을 이해하거나 수행할 수 있습니다:

이 강의의 목표는 “블랙박스” 에이전트를 투명하고 관리 가능하며 신뢰할 수 있는 시스템으로 전환할 수 있는 지식을 제공하는 것입니다.

참고: 안전하고 신뢰할 수 있는 AI 에이전트를 배포하는 것이 중요합니다. 신뢰할 수 있는 AI 에이전트 구축 강의도 확인해 보세요.

트레이스와 스팬

Langfuse나 Azure AI Foundry와 같은 관찰 가능성 도구는 일반적으로 에이전트 실행을 트레이스와 스팬으로 나타냅니다.

Langfuse의 트레이스 트리

관찰 가능성이 없으면 AI 에이전트는 “블랙박스”처럼 느껴질 수 있습니다. 내부 상태와 추론이 불투명하여 문제를 진단하거나 성능을 최적화하기 어렵습니다. 관찰 가능성을 통해 에이전트는 “글래스박스”가 되어 투명성을 제공하며, 이는 신뢰를 구축하고 에이전트가 의도한 대로 작동하도록 보장하는 데 필수적입니다.

프로덕션 환경에서 관찰 가능성이 중요한 이유

AI 에이전트를 프로덕션 환경으로 전환하면 새로운 도전 과제와 요구 사항이 발생합니다. 관찰 가능성은 더 이상 “있으면 좋은” 기능이 아니라 필수적인 역량입니다:

추적해야 할 주요 메트릭

에이전트의 행동을 모니터링하고 이해하려면 다양한 메트릭과 신호를 추적해야 합니다. 에이전트의 목적에 따라 특정 메트릭이 다를 수 있지만, 몇 가지는 보편적으로 중요합니다.

다음은 관찰 가능성 도구가 모니터링하는 가장 일반적인 메트릭입니다:

지연 시간(Latency): 에이전트가 얼마나 빠르게 응답하는가? 긴 대기 시간은 사용자 경험에 부정적인 영향을 미칩니다. 에이전트 실행을 추적하여 작업 및 개별 단계의 지연 시간을 측정해야 합니다. 예를 들어, 모든 모델 호출에 20초가 걸리는 에이전트는 더 빠른 모델을 사용하거나 모델 호출을 병렬로 실행하여 속도를 높일 수 있습니다.

비용(Costs): 에이전트 실행당 비용은 얼마인가? AI 에이전트는 토큰당 과금되는 LLM 호출이나 외부 API에 의존합니다. 도구를 자주 사용하거나 여러 번 프롬프트를 호출하면 비용이 빠르게 증가할 수 있습니다. 예를 들어, 에이전트가 품질을 약간만 개선하기 위해 LLM을 다섯 번 호출한다면, 비용이 정당화되는지 평가하거나 호출 횟수를 줄이거나 더 저렴한 모델을 사용할 수 있습니다. 실시간 모니터링은 예기치 않은 급증(예: 과도한 API 루프를 유발하는 버그)을 식별하는 데도 도움이 됩니다.

요청 오류(Request Errors): 에이전트가 실패한 요청은 몇 건인가? 여기에는 API 오류나 도구 호출 실패가 포함될 수 있습니다. 프로덕션에서 이러한 문제에 대해 에이전트를 더 견고하게 만들기 위해, 폴백(fallback)이나 재시도를 설정할 수 있습니다. 예를 들어, LLM 제공업체 A가 다운되면 LLM 제공업체 B로 전환하는 방식입니다.

사용자 피드백(User Feedback): 직접적인 사용자 평가를 구현하면 귀중한 통찰력을 얻을 수 있습니다. 여기에는 명시적인 평가(👍/👎, ⭐1-5점)나 텍스트 코멘트가 포함될 수 있습니다. 지속적인 부정적 피드백은 에이전트가 예상대로 작동하지 않는다는 신호로 간주해야 합니다.

암묵적 사용자 피드백(Implicit User Feedback): 사용자 행동은 명시적인 평가 없이도 간접적인 피드백을 제공합니다. 여기에는 즉각적인 질문 재구성, 반복된 쿼리, 재시도 버튼 클릭 등이 포함됩니다. 예를 들어, 사용자가 동일한 질문을 반복적으로 묻는다면, 이는 에이전트가 예상대로 작동하지 않는다는 신호입니다.

정확성(Accuracy): 에이전트가 올바르거나 바람직한 출력을 생성하는 빈도는 얼마나 되는가? 정확성의 정의는 다양합니다(예: 문제 해결 정확성, 정보 검색 정확성, 사용자 만족도). 첫 번째 단계는 에이전트의 성공이 무엇인지 정의하는 것입니다. 정확성은 자동화된 검사, 평가 점수, 작업 완료 레이블을 통해 추적할 수 있습니다. 예를 들어, 트레이스를 “성공” 또는 “실패”로 표시하는 방식입니다.

자동화된 평가 메트릭(Automated Evaluation Metrics): 자동 평가를 설정할 수도 있습니다. 예를 들어, 에이전트 출력이 유용하거나 정확한지 여부를 평가하기 위해 LLM을 사용할 수 있습니다. 또한 에이전트를 다양한 측면에서 평가하는 데 도움이 되는 여러 오픈 소스 라이브러리가 있습니다. 예를 들어, RAG 에이전트를 위한 RAGAS나 유해한 언어 또는 프롬프트 주입을 감지하기 위한 LLM Guard 등이 있습니다.

실제로, 이러한 메트릭을 조합하여 AI 에이전트의 상태를 가장 잘 파악할 수 있습니다. 이 장의 예제 노트북에서는 이러한 메트릭이 실제 예제에서 어떻게 나타나는지 보여드리겠지만, 먼저 일반적인 평가 워크플로를 살펴보겠습니다.

에이전트 계측

트레이싱 데이터를 수집하려면 코드를 계측해야 합니다. 목표는 에이전트 코드가 관찰 가능성 플랫폼에서 캡처, 처리, 시각화할 수 있는 트레이스와 메트릭을 생성하도록 계측하는 것입니다.

OpenTelemetry (OTel): OpenTelemetry는 LLM 관찰 가능성의 업계 표준으로 자리 잡았습니다. 이는 텔레메트리 데이터를 생성, 수집, 내보내기 위한 API, SDK, 도구 세트를 제공합니다.

기존 에이전트 프레임워크를 래핑하고 OpenTelemetry 스팬을 관찰 가능성 도구로 쉽게 내보낼 수 있는 많은 계측 라이브러리가 있습니다. 아래는 OpenLit 계측 라이브러리를 사용하여 AutoGen 에이전트를 계측하는 예제입니다:

import openlit

openlit.init(tracer = langfuse._otel_tracer, disable_batch = True)

이 장의 예제 노트북에서는 AutoGen 에이전트를 계측하는 방법을 보여줍니다.

수동 스팬 생성: 계측 라이브러리가 기본적인 기능을 제공하지만, 더 세부적이거나 맞춤화된 정보가 필요한 경우가 종종 있습니다. 수동으로 스팬을 생성하여 사용자 지정 애플리케이션 로직을 추가할 수 있습니다. 더 중요한 것은, 자동 생성되거나 수동으로 생성된 스팬에 사용자 지정 속성(태그 또는 메타데이터라고도 함)을 추가하여 풍부하게 만들 수 있다는 점입니다. 이러한 속성에는 비즈니스별 데이터, 중간 계산, 디버깅 또는 분석에 유용할 수 있는 컨텍스트(예: user_id, session_id, model_version)가 포함될 수 있습니다.

Langfuse Python SDK를 사용하여 트레이스와 스팬을 수동으로 생성하는 예제:

from langfuse import get_client
 
langfuse = get_client()
 
span = langfuse.start_span(name="my-span")
 
span.end()

에이전트 평가

관찰 가능성은 메트릭을 제공합니다. 그러나 평가란 데이터를 분석하고 테스트를 수행하여 AI 에이전트가 얼마나 잘 작동하는지, 그리고 어떻게 개선할 수 있는지를 판단하는 과정입니다. 즉, 트레이스와 메트릭을 확보한 후, 이를 사용하여 에이전트를 평가하고 의사 결정을 내리는 방법입니다.

정기적인 평가는 중요합니다. AI 에이전트는 종종 비결정적이며 업데이트나 모델 동작 변화로 인해 진화할 수 있기 때문입니다. 평가 없이는 “스마트 에이전트”가 실제로 잘 작동하는지, 아니면 성능이 저하되었는지 알 수 없습니다.

AI 에이전트 평가에는 오프라인 평가와 온라인 평가라는 두 가지 범주가 있습니다. 두 가지 모두 가치가 있으며 상호 보완적입니다. 일반적으로 오프라인 평가부터 시작합니다. 이는 에이전트를 배포하기 전에 최소한으로 필요한 단계입니다.

오프라인 평가

Langfuse의 데이터셋 항목

오프라인 평가는 일반적으로 테스트 데이터셋을 사용하여 통제된 환경에서 에이전트를 평가하는 것을 의미합니다. 이는 실제 사용자 쿼리가 아닌, 예상 출력이나 올바른 동작을 알고 있는 데이터셋을 사용하여 에이전트를 실행하는 것입니다.

예를 들어, 수학 단어 문제를 해결하는 에이전트를 구축했다면, 정답이 알려진 100개의 문제로 구성된 테스트 데이터셋을 사용할 수 있습니다. 오프라인 평가는 개발 중에 자주 수행되며(또한 CI/CD 파이프라인의 일부가 될 수 있음), 개선 사항을 확인하거나 성능 저하를 방지하기 위해 사용됩니다. 이 방법의 장점은 반복 가능하며, 정확한 정답이 있으므로 명확한 정확성 메트릭을 얻을 수 있다는 점입니다. 또한 사용자 쿼리를 시뮬레이션하고 에이전트의 응답을 이상적인 답변과 비교하거나 위에서 설명한 자동화된 메트릭을 사용할 수도 있습니다.

오프라인 평가의 주요 과제는 테스트 데이터셋이 포괄적이고 관련성을 유지하도록 보장하는 것입니다. 에이전트가 고정된 테스트 세트에서 잘 작동하더라도, 프로덕션에서는 매우 다른 쿼리에 직면할 수 있습니다. 따라서 테스트 세트를 새로운 엣지 케이스와 실제 시나리오를 반영하는 예제로 업데이트해야 합니다. 소규모 “스모크 테스트” 케이스와 더 큰 평가 세트를 혼합하여 사용하는 것이 유용합니다: 소규모 세트는 빠른 확인용, 대규모 세트는 광범위한 성능 메트릭용으로 사용합니다.

온라인 평가

관찰 가능성 메트릭 개요

온라인 평가는 실제 사용 중인 프로덕션 환경에서 에이전트를 평가하는 것을 의미합니다. 온라인 평가는 실제 사용자 상호작용에서 에이전트의 성능을 모니터링하고 결과를 지속적으로 분석하는 것을 포함합니다.

예를 들어, 성공률, 사용자 만족도 점수 또는 기타 메트릭을 실시간 트래픽에서 추적할 수 있습니다. 온라인 평가의 장점은 실험실 환경에서 예상하지 못한 상황을 포착할 수 있다는 점입니다. 시간 경과에 따른 모델 드리프트(입력 패턴이 변화하면서 에이전트의 효과가 저하되는 경우)를 관찰하고, 테스트 데이터에 없었던 예기치 않은 쿼리나 상황을 감지할 수 있습니다. 이를 통해 에이전트가 실제 환경에서 어떻게 작동하는지에 대한 진정한 그림을 얻을 수 있습니다.

온라인 평가는 앞서 논의한 사용자 피드백(명시적 및 암묵적)을 수집하거나, 섀도우 테스트 또는 A/B 테스트(새로운 버전의 에이전트를 기존 버전과 병렬로 실행하여 비교)를 실행하는 것을 포함할 수 있습니다. 그러나 라이브 상호작용에 대한 신뢰할 수 있는 레이블이나 점수를 얻는 것은 까다로울 수 있습니다. 사용자 피드백이나 다운스트림 메트릭(예: 사용자가 결과를 클릭했는지 여부)에 의존해야 할 수도 있습니다.

두 가지 방법의 결합

온라인 평가와 오프라인 평가는 상호 배타적이지 않으며, 매우 상호 보완적입니다. 온라인 모니터링에서 얻은 통찰력(예: 에이전트가 성능이 저조한 새로운 유형의 사용자 쿼리)은 오프라인 테스트 데이터셋을 보강하고 개선하는 데 사용할 수 있습니다. 반대로, 오프라인 테스트에서 잘 작동하는 에이전트는 더 자신 있게 배포하고 온라인으로 모니터링할 수 있습니다.

실제로 많은 팀이 다음과 같은 루프를 채택합니다:

오프라인 평가 -> 배포 -> 온라인 모니터링 -> 새로운 실패 사례 수집 -> 오프라인 데이터셋에 추가 -> 에이전트 개선 -> 반복.

일반적인 문제

AI 에이전트를 프로덕션에 배포하면 다양한 문제에 직면할 수 있습니다. 다음은 몇 가지 일반적인 문제와 잠재적인 해결책입니다:

문제 잠재적 해결책
에이전트가 작업을 일관되게 수행하지 못함 - 에이전트에 제공되는 프롬프트를 개선하고 목표를 명확히 설정합니다.
- 작업을 하위 작업으로 나누고 여러 에이전트가 처리하도록 하면 도움이 될 수 있습니다.
에이전트가 연속 루프에 빠짐 - 에이전트가 프로세스를 종료해야 할 시점을 알 수 있도록 명확한 종료 조건을 설정합니다.

에이전트 성능 문제 해결

AI 에이전트가 프로덕션 환경에서 제대로 작동하지 않을 때, 문제를 해결하기 위해 다음과 같은 전략을 사용할 수 있습니다:

문제 해결 방법
에이전트가 잘못된 출력을 생성함 - 에이전트의 입력과 출력을 추적하여 문제를 정확히 파악합니다.
- 에이전트의 프롬프트를 개선하고, 더 명확하고 구체적인 지침을 제공합니다.
복잡한 작업에서 성능이 저하됨 - 복잡한 작업을 처리하기 위해 논리적 추론에 특화된 대형 모델을 사용합니다.
AI 에이전트 도구 호출 성능 저하 - 에이전트 시스템 외부에서 도구의 출력을 테스트하고 검증합니다.
- 정의된 매개변수, 프롬프트, 도구 이름을 개선합니다.
멀티 에이전트 시스템이 일관되지 않음 - 각 에이전트에 제공되는 프롬프트를 구체적이고 서로 구별되도록 개선합니다.
- “라우팅” 또는 컨트롤러 에이전트를 사용하여 올바른 에이전트를 결정하는 계층적 시스템을 구축합니다.

이러한 문제는 관찰 가능성을 통해 더 효과적으로 식별할 수 있습니다. 앞서 논의한 추적 및 메트릭은 에이전트 워크플로우에서 문제가 발생하는 정확한 위치를 파악하는 데 도움을 주며, 디버깅과 최적화를 훨씬 더 효율적으로 만들어줍니다.

비용 관리

AI 에이전트를 프로덕션 환경에 배포할 때 비용을 관리하기 위한 몇 가지 전략은 다음과 같습니다:

소형 모델 사용: 소형 언어 모델(SLM)은 특정 에이전트 사용 사례에서 우수한 성능을 발휘하며 비용을 크게 줄일 수 있습니다. 앞서 언급했듯이, 성능을 평가하고 대형 모델과 비교하는 시스템을 구축하여 SLM이 사용 사례에서 얼마나 잘 작동하는지 이해하는 것이 중요합니다. 예를 들어, 의도 분류나 매개변수 추출과 같은 간단한 작업에는 SLM을 사용하고, 복잡한 추론에는 대형 모델을 사용하는 것을 고려하세요.

라우터 모델 사용: 다양한 모델과 크기를 사용하는 전략도 유용합니다. 요청의 복잡성에 따라 적합한 모델로 라우팅하기 위해 LLM/SLM 또는 서버리스 함수를 사용할 수 있습니다. 이를 통해 비용을 절감하면서도 적합한 작업에서 성능을 유지할 수 있습니다. 예를 들어, 간단한 쿼리는 더 작고 빠른 모델로 라우팅하고, 복잡한 추론 작업에는 비용이 많이 드는 대형 모델을 사용하세요.

응답 캐싱: 일반적인 요청과 작업을 식별하고, 에이전트 시스템을 거치기 전에 응답을 제공하는 것은 유사한 요청의 볼륨을 줄이는 좋은 방법입니다. 더 기본적인 AI 모델을 사용하여 요청이 캐시된 응답과 얼마나 유사한지 식별하는 흐름을 구현할 수도 있습니다. 이 전략은 자주 묻는 질문이나 일반적인 워크플로우에 대해 비용을 크게 줄일 수 있습니다.

실제로 어떻게 작동하는지 살펴보기

이 섹션의 예제 노트북에서 관찰 가능성 도구를 사용하여 에이전트를 모니터링하고 평가하는 방법에 대한 예제를 확인할 수 있습니다.

프로덕션 환경에서 AI 에이전트에 대해 더 궁금한 점이 있나요?

Azure AI Foundry Discord에 참여하여 다른 학습자들과 만나고, 오피스 아워에 참석하며, AI 에이전트에 대한 질문에 답변을 받을 수 있습니다.

이전 강의

메타인지 디자인 패턴

다음 강의

에이전트 프로토콜

면책 조항:
이 문서는 AI 번역 서비스 Co-op Translator를 사용하여 번역되었습니다. 정확성을 위해 최선을 다하고 있으나, 자동 번역에는 오류나 부정확성이 포함될 수 있습니다. 원본 문서를 해당 언어로 작성된 상태에서 권위 있는 자료로 간주해야 합니다. 중요한 정보의 경우, 전문적인 인간 번역을 권장합니다. 이 번역 사용으로 인해 발생할 수 있는 오해나 잘못된 해석에 대해 당사는 책임을 지지 않습니다.

This site is open source. Improve this page.