ai-agents-for-beginners

생산 환경에서의 AI 에이전트: 관찰 가능성과 평가

AI 에이전트가 실험적 프로토타입에서 실제 세계의 애플리케이션으로 옮겨감에 따라, 그들의 행동을 이해하고, 성능을 모니터링하며, 결과물을 체계적으로 평가하는 능력이 중요해졌습니다.

학습 목표

이 수업을 마치면 다음을 알게 되거나 이해하게 될 것입니다:

에이전트 관찰 가능성과 평가의 핵심 개념
에이전트의 성능, 비용, 효과를 개선하는 기술
AI 에이전트를 체계적으로 평가하는 방법과 내용
AI 에이전트를 생산 환경에 배포할 때 비용을 제어하는 방법
Microsoft Agent Framework로 제작된 에이전트에 대한 계측 방법

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

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

트레이스와 스팬

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

트레이스는 시작부터 끝까지 전체 에이전트 작업(예: 사용자 쿼리 처리)을 나타냅니다.
스팬은 트레이스 내 개별 단계(예: 언어 모델 호출 또는 데이터 검색)를 나타냅니다.

Langfuse의 트레이스 트리

관찰 가능성이 없으면 AI 에이전트는 “블랙박스”처럼 느껴져 내부 상태와 추론이 불투명해 문제 진단이나 성능 최적화가 어렵습니다. 관찰 가능성을 통해 에이전트는 “글래스 박스”가 되어 신뢰 구축과 의도된 대로 작동함을 보장하는 데 필수적인 투명성을 제공합니다.

생산 환경에서 관찰 가능성이 중요한 이유

AI 에이전트를 생산 환경으로 옮기면 새로운 도전과 요구사항이 생깁니다. 관찰 가능성은 더 이상 선택이 아니라 필수 기능입니다:

디버깅 및 근본 원인 분석: 에이전트가 실패하거나 예상치 못한 출력을 할 때, 관찰 가능성 도구는 오류 원인을 정확히 찾아내는 데 필요한 트레이스를 제공합니다. 이는 여러 LLM 호출, 도구 상호작용, 조건부 논리가 포함된 복잡한 에이전트에 특히 중요합니다.
지연 시간 및 비용 관리: AI 에이전트는 종종 토큰이나 호출 단위로 과금되는 LLM이나 외부 API에 의존합니다. 관찰 가능성은 이런 호출을 정밀 추적해 지나치게 느리거나 비용이 많이 드는 작업을 식별할 수 있게 합니다. 이를 통해 팀은 프롬프트 최적화, 효율적인 모델 선택 또는 워크플로우 재설계로 운영 비용을 관리하고 우수한 사용자 경험을 보장할 수 있습니다.
신뢰, 안전 및 규제 준수: 많은 애플리케이션에서 에이전트가 안전하고 윤리적으로 행동하는지 확인하는 것이 중요합니다. 관찰 가능성은 에이전트의 행동과 결정을 기록하는 감사 추적을 제공합니다. 이를 통해 프롬프트 인젝션, 유해 콘텐츠 생성, 개인 식별 정보(PII) 오용 같은 문제를 탐지하고 완화할 수 있습니다. 예를 들어, 특정 응답을 제공한 이유나 특정 도구를 사용한 이유를 트레이스를 검토할 수 있습니다.
지속적 개선 루프: 관찰 가능성 데이터는 반복 개발 프로세스의 기반입니다. 실제 환경에서 에이전트 성능을 모니터링해 개선 영역을 찾아내고, 모델 미세 조정 데이터를 수집하며, 변경 영향도를 검증할 수 있습니다. 이는 온라인 평가에서 얻은 인사이트가 오프라인 실험과 개선에 반영되어 점차 더 나은 에이전트 성능으로 이어지는 피드백 루프를 만듭니다.

추적해야 할 주요 지표

에이전트 행동을 모니터링하고 이해하기 위해 다양한 지표와 신호를 추적해야 합니다. 특정 지표는 에이전트 목적에 따라 다를 수 있지만, 일부는 보편적으로 중요합니다.

여기 관찰 가능성 도구가 주로 모니터링하는 일반적인 지표들이 있습니다:

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

비용: 에이전트 실행당 비용은 얼마인가? AI 에이전트는 토큰 단위 과금되는 LLM 호출이나 외부 API에 의존합니다. 잦은 도구 사용이나 다중 프롬프트는 비용을 급격히 증가시킬 수 있습니다. 예를 들어, 품질 향상을 위해 LLM을 5회 호출한다면 비용이 정당한지, 호출 수를 줄이거나 더 저렴한 모델을 사용할 수 있는지 평가해야 합니다. 실시간 모니터링은 예상치 못한 급증(예: 버그로 인한 과도한 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 파이프라인 일부로) 개선 확인이나 회귀 방지를 위해 종종 수행됩니다. 장점은 반복 가능하며 기준 진실이 있어 명확한 정확도 지표를 얻을 수 있습니다. 사용자가 묻는 질문을 시뮬레이션하고 이상적인 답변과 비교하거나 위에서 설명한 자동 지표를 사용할 수도 있습니다.

오프라인 평가의 핵심 과제는 테스트 데이터셋이 포괄적이고 관련성을 유지하도록 하는 것입니다. 에이전트는 고정된 테스트 집합에서는 잘 작동하지만 실제 환경에서 전혀 다른 쿼리를 만날 수 있습니다. 따라서 현실을 반영하는 새로운 엣지 케이스와 사례로 테스트 세트를 계속 업데이트해야 합니다. 작은 “스모크 테스트” 케이스와 더 큰 평가 세트를 혼합하는 것이 유용합니다: 작은 세트는 빠른 확인용, 큰 세트는 광범위한 성능 지표용입니다.

온라인 평가

관찰 가능성 지표 개요

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

예를 들어, 성공률, 사용자 만족도 점수, 기타 지표를 라이브 트래픽에서 추적할 수 있습니다. 온라인 평가의 장점은 실험실 환경에서 예상하지 못한 것을 포착한다는 것입니다. 입력 패턴 변화에 따라 모델 드리프트를 관찰하고, 테스트 데이터에 없던 예기치 않은 쿼리나 상황을 포착할 수 있습니다. 실제로 에이전트가 현장에서 어떻게 행동하는지 진정한 모습을 보여줍니다.

온라인 평가는 앞서 논의한 명시적/암묵적 사용자 피드백 수집 및 그림자 테스트(shadow test), 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.