ai-agents-for-beginners

AI 에이전트의 실제 운영: 관찰 가능성 및 평가

AI 에이전트의 실제 운영

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

학습 목표

이 수업을 완료하면 다음을 알게 되고 이해하게 됩니다:

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

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

트레이스와 스팬

Langfuse 또는 Microsoft Foundry 같은 관찰 도구는 보통 에이전트 실행을 트레이스와 스팬으로 표현합니다.

Langfuse에서의 트레이스 트리

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

운영 환경에서 관찰 가능성이 중요한 이유

AI 에이전트를 운영 환경으로 전환하면 새로운 도전과 요구 사항이 생깁니다. 관찰 가능성은 더 이상 “있으면 좋은 기능”이 아니라 중요한 기능입니다:

추적해야 할 주요 지표

에이전트 행동을 모니터링하고 이해하려면 다양한 메트릭과 신호를 추적해야 합니다. 구체적인 메트릭은 에이전트 목적에 따라 다를 수 있지만 일부는 보편적으로 중요합니다.

관찰 도구가 주로 모니터링하는 일반적인 메트릭은 다음과 같습니다:

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

비용: 에이전트 실행당 비용은 얼마인가? AI 에이전트는 토큰 단위로 청구되는 LLM 호출 또는 외부 API를 사용합니다. 도구 사용이 빈번하거나 여러 프롬프트 호출이 비용을 급격히 증가시킬 수 있습니다. 예를 들어, 에이전트가 품질 향상을 위한 다섯 차례 LLM 호출을 수행한다면, 비용이 정당한지 평가하거나 호출 횟수를 줄이거나 저렴한 모델을 이용할 수 있습니다. 실시간 모니터링은 예상치 못한 급증(예: 버그로 인한 과도한 API 루프)을 식별하는 데도 도움을 줍니다.

요청 오류: 에이전트가 실패한 요청 수는? 이를 API 오류나 실패한 도구 호출도 포함합니다. 운영 환경에서 에이전트를 견고하게 만들려면 폴백 또는 재시도 로직을 설정할 수 있습니다. 예를 들어, LLM 공급자 A가 다운되면 백업으로 LLM 공급자 B를 사용하는 식입니다.

사용자 피드백: 직접 사용자 평가 구현은 귀중한 인사이트를 제공합니다. 명시적 평점(👍좋아요/👎싫어요, ⭐1-5점) 또는 텍스트 코멘트를 포함할 수 있습니다. 일관된 부정 피드백은 에이전트가 기대대로 작동하지 않는 신호로 경고해야 합니다.

암묵적 사용자 피드백: 사용자 행동은 명시적 평점 없이도 간접 피드백을 제공합니다. 즉각적인 질문 재구성, 반복 쿼리, 재시도 버튼 클릭 등이 포함됩니다. 예를 들어, 사용자가 같은 질문을 반복하면 에이전트가 기대에 미치지 못한다는 신호입니다.

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

자동 평가 메트릭: 자동 평가 시스템을 설정할 수도 있습니다. 예를 들어, LLM을 사용해 에이전트 출력이 도움이 되는지, 정확한지 평가 점수를 매길 수 있습니다. 또한, RAG 에이전트를 위한 RAGAS 나 해로운 언어 및 프롬프트 인젝션 탐지를 위한 LLM Guard 같은 여러 오픈 소스 라이브러리가 있습니다.

실무에서는 이러한 메트릭의 조합이 AI 에이전트 상태의 가장 좋은 커버리지를 제공합니다. 이 장의 예제 노트북에서 이러한 메트릭이 실제 예시에서 어떻게 보이는지 보여드리지만, 먼저 일반적인 평가 워크플로우가 어떻게 진행되는지 배우겠습니다.

에이전트에 계측하기

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

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

기존 에이전트 프레임워크를 래핑하고 OpenTelemetry 스팬을 관찰 도구로 쉽게 내보내는 여러 계측 라이브러리가 있습니다. Microsoft Agent Framework는 OpenTelemetry와 네이티브로 통합됩니다. 다음은 MAF 에이전트에 계측을 추가하는 예시입니다:

from agent_framework.observability import get_tracer, get_meter

tracer = get_tracer()
meter = get_meter()

with tracer.start_as_current_span("agent_run"):
    # 에이전트 실행이 자동으로 추적됩니다
    pass

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

수동 스팬 생성: 계측 라이브러리로 기본 기능을 제공하지만, 더 상세하거나 맞춤 정보를 추가해야 하는 경우가 종종 있습니다. 수동으로 스팬을 생성하여 맞춤 애플리케이션 로직을 추가할 수 있습니다. 더 중요한 점은 자동 또는 수동 생성 스팬에 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 에이전트가 연속 루프에 빠짐 - 종료 조건을 명확히 하여 에이전트가 언제 프로세스를 멈춰야 할지 알도록 합니다.
- 추론 및 계획이 필요한 복잡한 작업에는 추론 작업에 특화된 더 큰 모델을 사용합니다.
AI 에이전트 도구 호출이 제대로 작동하지 않음 - 에이전트 시스템 외부에서 도구 결과를 테스트하고 검증합니다.
- 도구의 정의된 매개변수, 프롬프트, 이름을 다듬습니다.
다중 에이전트 시스템이 일관성 없게 작동 - 각 에이전트에 제공하는 프롬프트를 구체적이고 서로 다르도록 개선합니다.
- 어느 에이전트가 적합한지 결정하는 “라우팅” 혹은 컨트롤러 에이전트를 이용해 계층적 시스템을 구축합니다.

이러한 문제 대부분은 관찰 가능성이 적용되어 있을 때 훨씬 효과적으로 파악할 수 있습니다. 앞서 논의한 트레이스와 메트릭은 에이전트 워크플로우 내 문제 발생 위치를 정확히 짚어 주어 디버깅과 최적화를 훨씬 효율적으로 만듭니다.

비용 관리

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

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

라우터 모델 사용: 유사한 전략으로 다양한 모델과 크기를 사용하는 방법이 있습니다. 복잡도에 따라 요청을 최적의 모델로 라우팅할 수 있도록 LLM/SLM 또는 서버리스 함수를 사용할 수 있습니다. 이는 비용을 절감하는 동시에 적합한 작업에 대해 성능을 보장하는 데 도움이 됩니다. 예를 들어, 간단한 쿼리는 더 작고 빠른 모델로 라우팅하고, 복잡한 추론 작업에는 비용이 큰 대형 모델만 사용하는 식입니다.

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

실제로 어떻게 작동하는지 봅시다

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

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

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

이전 강의

메타인지 디자인 패턴

다음 강의

에이전틱 프로토콜

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

This site is open source. Improve this page.