신뢰할 수 있는 에이전트형 AI 시스템을 위한 AI 기반 관측성(Observability) 설계

1. 에이전트형 AI 시스템에서 관측성이 변해야 하는 이유

최근 한 개발자는 단 하나의 통제 불능 AI 에이전트 루프가 모니터링 스택에 어떠한 오류나 경고도 띄우지 않은 채, 단 45분 만에 500달러의 OpenAI API 비용을 소모했던 사례를 들려주었습니다. 이러한 일화는 특이 케이스가 아닙니다. 마이크로소프트의 관측성 팀이 언급했듯이, "어려운 것은 에이전트를 작동시키는 것이 아니라, 계속해서 제대로 작동하게 유지하는 것"입니다. 모델은 업데이트되고, 프롬프트는 수정되며, 검색(retrieval) 파이프라인은 드리프트(drift) 현상을 겪고, 실제 사용자 트래픽은 그 어떤 평가 세트에서도 나타나지 않았던 에지 케이스(edge cases)를 수면 위로 끌어올리기 때문입니다.

이러한 현실은 현대의 AI 애플리케이션이 더 이상 결정론적인 '요청-응답' 파이프라인이 아님을 시사합니다. 현대 AI는 계획하고, 추론하며, 도구를 호출하고, 실시간으로 적응하는 자율적인 다단계 에이전트, 즉 '에이전트형 AI 시스템'입니다. 이는 관측해야 할 대상을 근본적으로 변화시킵니다. 서버와 마이크로서비스를 위해 구축된 전통적인 관측성 도구는 AI 에이전트의 출력이 정확한지, 안전한지, 혹은 비용 효율적인지 알려줄 수 없습니다. 응답이 'HTTP 200 OK'를 반환하더라도 사실과 다르거나 정책을 위반했을 수 있으며, 이러한 격차는 기존의 대시보드에는 절대 나타나지 않습니다.

이제 기업들의 질문은 *"우리가 이것을 만들 수 있는가?"*에서 **"우리가 이것을 신뢰할 수 있는가?"**로 옮겨갔습니다. 프로덕션 수준의 AI는 단순히 성능만 좋은 것이 아니라 책임감 있게 행동해야 하며, 에이전트가 무엇을 생성하는지, 에지 케이스를 어떻게 처리하는지, 그리고 안전성·공정성·준수성을 유지하는지에 대한 지속적인 가시성이 필요합니다. 이러한 신뢰를 얻기 위해서는 인프라의 상태뿐만 아니라 에이전트의 사고 과정, 의사결정 품질, 규정 준수 상태를 캡처하는 차세대 관측성이 필요합니다.

2. 전통적 관측성에서 AI 네이티브 관측성으로

전통적인 모니터링은 고정된 엔드포인트, 결정론적 경로, 잘 알려진 실패 모드 등 상대적으로 예측 가능한 실행을 가정합니다. 하지만 AI 에이전트는 이 모델을 완전히 무너뜨립니다. AI 네이티브 관측성이 필요한 주요 차이점은 다음과 같습니다.

• 비결정론적 실행 경로: 동일한 입력이라도 도구 호출, 재시도, 추론 단계의 체인이 완전히 달라질 수 있습니다. 모니터링할 고정된 엔드포인트 세트가 존재하지 않습니다.
• 숨겨진 비용 누적: 단일 사용자 쿼리가 서로 다른 모델에 걸쳐 15번의 LLM 호출을 트리거할 수 있습니다. 요청당 비용 추적이 없다면 청구서는 블랙박스로 남게 됩니다.
• 성공처럼 보이는 연쇄적 실패: 에이전트가 올바른 컨텍스트를 검색하는 데 실패했음에도 불구하고 확신에 찬 목소리로 틀린 답을 반환할 수 있습니다. HTTP 상태는 200이지만, 사용자는 답변이 틀렸다고 말합니다.
• 극심한 지연 시간 변동성: 동일한 쿼리라도 추론 경로에 따라 800ms가 걸릴 수도, 30초가 걸릴 수도 있습니다. 전통적인 p99 알림으로는 이러한 가변성을 포착할 수 없습니다.
• 토큰 예산 폭주: 통제 불능이 된 에이전트 루프 하나가 한 달 치 토큰 예산을 단 몇 시간 만에 다 써버릴 수 있습니다.

이러한 특성 때문에 AI 네이티브 관측성은 기존의 기둥들을 넘어 의미론적 및 품질적 통찰력으로 확장됩니다. 즉, 에이전트가 무엇을 추론했는지, 컨텍스트와 도구를 어떻게 사용했는지, 출력이 품질 및 규정 준수 표준을 충족하는지를 파악하는 것입니다. 컨텍스트 드리프트, 도구 오용, 비효율적인 추론과 같은 문제는 기존의 로깅만으로는 발견되지 않은 채 지나치게 됩니다.

3. AI 에이전트를 관찰하기 위해 또 다른 AI 에이전트 사용하기

강력한 신흥 패턴 중 하나는 **AI 기반 평가자(evaluators)**를 고용하여 다른 AI 에이전트를 모니터링하고 평가하는 것입니다. Microsoft Foundry는 이를 직접 구현합니다. Foundry의 평가자는 에이전트의 응답을 평가하는 함수이며, 일부 평가자는 AI 모델을 판사로 사용하고(LLM-as-judge 방식, 언어 모델이 루브릭에 따라 다른 모델의 출력을 점수화함), 다른 평가자는 규칙이나 알고리즘을 사용합니다.

추론 트레이스 분석(Reasoning Trace Analysis)

Foundry의 관측성 레이어는 프롬프트, 도구 호출, 도구 응답, 출력 생성 등 에이전트 실행의 모든 단계를 캡처합니다. 이를 통해 개발자는 의사결정 경로를 분석하고, 지연 시간의 원인을 파악하며, 실패 지점을 정확히 짚어낼 수 있습니다. Azure Monitor의 **AI 맞춤형 트레이스 뷰(AI-Tailored Trace View)**는 각 결정을 계획 → 추론 → 도구 호출 → 가드레일 체크와 같이 읽기 쉬운 스토리로 렌더링하여, 팀이 수천 개의 스팬(span)을 뒤지지 않고도 느리거나 안전하지 않은 단계를 식별할 수 있게 합니다. 또한 **AI 기반 트레이스 검색(AI-Aware Trace Search)**을 통해 모델 ID, 그라운딩 점수(grounding score), 비용 등 생성형 AI 관련 속성을 사용하여 수백만 건의 실행 결과 중 이상 징후를 빠르게 진단할 수 있습니다.

그라운딩 및 환각 탐지(Grounding and Hallucination Detection)

Foundry는 NLP 메트릭을 사용하여 생성된 텍스트를 참조 답변과 비교하는 텍스트 유사성 평가자를 제공하여 환각 탐지를 직접 지원합니다. 내장된 평가자는 RAG(검색 증강 생성) 품질 평가 카테고리의 일부로 근거성(groundedness)과 관련성을 평가합니다. LLM 기반 평가자는 각 응답에 대해 *사실(factual) 대 환각(hallucinated)*과 같은 범주형 레이블을 지정하고, 설명과 함께 실행 가능한 피드백을 제공할 수 있습니다.

정책 및 안전 점수(Policy and Safety Scoring)

Microsoft Foundry 제어 평면의 콘텐츠 안전(Content Safety) 기능은 0~7단계의 심각도 점수와 각 플래그에 대한 상세한 추론을 포함한 기업용 유해성 탐지 기능을 제공합니다. 내장된 안전 평가자는 생성된 출력에서 잠재적인 콘텐츠 및 보안 위험을 식별하며, 특히 폭력 평가자는 응답에 폭력적인 내용이 포함되어 있는지 체크합니다. 기본적으로 Foundry는 혐오 및 공정성, 성적 및 폭력적 콘텐츠, 자해, 보호된 텍스트 또는 코드 사용, 프롬프트 인젝션 시도 등을 포함하는 기본 안전 가드레일을 모든 모델과 에이전트에 자동으로 적용합니다. 조직은 또한 민감도 수준을 조정하고, 특정 위험 카테고리를 선택적으로 활성화/비활성화하며, 콘텐츠를 주석 처리하거나 차단하는 등의 조치를 정의하는 맞춤형 가드레일을 생성할 수 있습니다.

4. AI 에이전트를 위한 정량적 상태 메트릭

질적인 평가 외에도 에이전트에는 전통적인 인프라 모니터링을 확장하는 정량적 메트릭이 필요합니다. 다음 표는 현재 플랫폼 기능을 바탕으로 한 주요 메트릭을 요약한 것입니다.

트레이드오프 참고: 모든 응답에 대해 LLM-as-judge를 실행하는 포괄적인 요청별 평가는 지연 시간과 비용을 증가시킵니다. 팀은 일반적으로 모든 응답에 대한 실시간 경량 안전 점검과 샘플링된 심층 평가 사이의 균형을 맞춥니다. 이는 데이터셋 기반 평가(배포 전 큐레이션된 테스트 세트)와 트레이스 기반 평가(프로덕션 환경의 실제 응답 분석)라는 두 가지 보완적인 평가 경로를 반영합니다.

💡 이러한 메트릭의 실제 활용 사례: 에이전트 모니터링 대시보드 가이드를 방문하여 에이전트의 지연 시간, 토큰 사용량, 성공률 및 안전 점수와 같은 라이브 메트릭을 확인해 보세요.

5. Microsoft Foundry가 에이전트 관측성을 지원하는 방법

Microsoft Foundry는 AI 앱과 에이전트를 구축, 최적화 및 거버넌스하기 위한 통합 상호 운용 플랫폼인 **"AI 앱 및 에이전트 팩토리"**로 설명됩니다. Foundry의 관측성 기능은 여러 통합 계층에 걸쳐 있습니다.

• 내장 평가 (Built-in Evaluations): Foundry는 범용, 텍스트 유사성, RAG 품질, 안전 및 보안, 에이전트 품질 등 다양한 범주에 걸쳐 사전 구축된 평가자를 제공합니다. 작업 준수(Task Adherence) 및 **일관성(Coherence)**과 같은 AI 지원 평가자는 GPT 모델(예: gpt-4o 또는 gpt-4o-mini)을 기본 판사로 사용합니다. 팀은 도메인별 요구 사항에 맞는 맞춤형 평가자를 구축할 수도 있습니다. 평가 서비스는 각 테스트 쿼리를 에이전트에게 보내고 응답을 캡처한 후, 선택된 평가자를 적용하여 결과를 자동으로 점수화합니다.

  직접 시도해 보세요: 생성형 AI 앱 평가 가이드를 통해 평가 페이지, 모델 페이지, 에이전트 페이지 또는 에이전트 플레이그라운드에서 평가를 실행해 보거나, 에이전트 평가 단계별 가이드를 따라 평가자 선택 및 결과 해석 방법을 익혀보세요.

• 지속적 모니터링 (Continuous Monitoring): Azure Monitor는 Foundry와 협력하여 에이전트 텔레메트리를 인프라, 애플리케이션, 네트워크 및 하드웨어 신호와 통합하여 엔드투엔드 운영 뷰를 생성합니다. 구체적인 기능으로는 성공률, 그라운딩 품질, 안전 위반, 지연 시간 및 결과당 비용을 추적하는 에이전트 개요 대시보드(Grafana 및 Azure에서 사용 가능)와 Foundry의 시각적 인터페이스를 통해 구축된 에이전트를 별도의 계측 코드 없이 모니터링할 수 있는 Foundry Low-Code 에이전트 모니터링이 포함됩니다. 모든 평가, 트레이스 및 레드팀(red-teaming) 결과는 Azure Monitor에 게시되어 에이전트 신호와 인프라 KPI가 상호 연관됩니다.

• 책임감 있는 AI 및 거버넌스 정렬: 모든 에이전트에는 Microsoft Entra Agent ID가 할당되어, IT 팀이 일반 사용자에게 적용하는 것과 동일하게 조건부 액세스, ID 보호 및 ID 거버넌스 정책을 에이전트에도 적용할 수 있습니다. Foundry는 Microsoft Entra ID를 통한 키리스(keyless) 인증을 강제하고, 저장 및 전송 중 데이터 암호화(더 큰 제어권을 위한 고객 관리 키 지원)를 지원하며, 관리형 VNet 또는 사용자 지정 VNet을 통한 네트워크 격리를 제공합니다. **AI 레드팀 에이전트(AI Red Teaming Agent)**를 사용하면 배포 전에 탈옥(jailbreak), 프롬프트 인젝션 공격 및 기타 보안 취약점을 발견하기 위한 선제적인 적대적 테스트가 가능합니다.

6. AI 라이프사이클 전반에 걸친 관측성 적용

과거에는 평가와 모니터링이 별개의 단계로 취급되었습니다. 데이터 과학자는 모델을 오프라인에서 테스트했고, 엔지니어는 배포 후에 모델을 관찰했습니다. 그러나 LLM과 비결정론의 세계에서는 이러한 구분이 더 이상 유효하지 않습니다. 관측성은 모든 라이프사이클 단계에 녹아들어야 합니다.

• 설계 시점 평가 (Design-Time Evaluation): 개발 중에 테스트 데이터셋을 만들고 수용 임계값을 정의하여 품질 기준선을 수립합니다. Foundry를 사용하면 에이전트를 사용자에게 릴리스하기 전에 85% 작업 준수 통과율과 같은 기준을 설정할 수 있습니다. 프롬프트 엔지니어링 과정에서 평가자를 반복적으로 실행하여 초기 퇴보(regression)를 방지하세요.

• 사전 프로덕션 검증 (Pre-Production Validation): 에이전트 CI/CD는 기존 소프트웨어 파이프라인에는 없었던 모델 버전 관리, 행동 벤치마크 기반 평가, 비결정론적 동작 문제를 처리해야 합니다. 정확한 출력을 확인하는 기존의 유닛 테스트와 달리, 에이전트 평가는 작업 완료율, 도구 사용 정확도, 응답 품질, 지연 시간, 비용 등 다양한 차원에서 가변적인 응답을 종합적으로 평가해야 합니다. 모호한 요청, 도구 실패, 상충되는 정보와 같은 에지 케이스를 의도적으로 테스트하는 **적대적 테스트(Adversarial testing)**는 필수적입니다. Foundry의 AI 레드팀 에이전트가 이를 직접 지원합니다.

  💡 더 알아보기: 클라우드에서 AI 레드팀 실행하기 가이드를 통해 배포 전 잠재적 공격과 에지 케이스에 대해 에이전트를 선제적으로 테스트하는 방법을 확인하세요.

• 런타임 모니터링 (Runtime Monitoring): 메트릭이 임계값을 벗어날 경우 자동 롤백 기능을 갖춘 카나리 배포(canary deployment)(새 버전에 트래픽의 5~10%만 라우팅)와 같은 점진적 전달 패턴을 사용하여 배포하세요. 프로덕션 환경에서는 오프라인 테스트에 사용된 것과 동일한 평가자가 라이브 프로덕션 트래픽도 모니터링하는 지속적 피드백 시스템이 가동되며, 데이터는 트레이스 로그에서 평가 결과, 대시보드로 원활하게 이동합니다. 첫날부터 모든 입력, 출력, API 호출, 토큰 사용량 및 의사결정 포인트를 추적하세요. 어떤 메트릭이 실패를 예측하는지에 대한 패턴은 프로덕션 데이터가 축적된 후에야 비로소 나타납니다.

• 지속적 개선 (Continuous Improvement): 점수가 낮은 상호작용을 분석용으로 내보내 프롬프트를 다듬거나, 지식 베이스를 업데이트하거나, Azure Machine Learning을 통해 모델을 미세 조정(fine-tuning)하는 데 사용하세요. 목표는 폐쇄 루프(closed loop)입니다. 모니터링을 통해 문제 발견 → 문제 조사 및 업데이트 트리거 → 스테이징 환경에서 업데이트 재평가 → 개선 사항 재배포 순으로 진행됩니다. 이를 통해 책임감 있는 AI는 단순한 정책에서 실천으로 바뀝니다.

7. 현대화 관점: 관측성을 위한 LLM 활용

평가자 및 설명자로서의 LLM

LLM 판사는 점수, 순위, 범주형 레이블(예: 사실 vs 환각), 설명 및 실행 가능한 피드백을 생성하여 AI 애플리케이션의 반복적인 정제를 가능하게 합니다. 이러한 확장 가능하고 일관된 접근 방식은 해석 가능한 설명을 제공함으로써 인간의 주석 작업에 대한 의존도를 줄여줍니다. LLM 평가자는 주로 세 가지 입력 유형을 사용합니다: 포인트와이즈(pointwise)(한 번에 하나의 출력 평가), 페어와이즈(pairwise)(두 출력을 비교), 리스트와이즈(listwise)(여러 출력의 순위 지정). 평가 기준은 언어적 품질(유창성, 일관성), 콘텐츠 정확성(사실 확인, 논리적 일관성), 작업별 메트릭(완전성, 정보성) 및 사용자 경험에 걸쳐 있습니다.

장점 및 한계

연구 커뮤니티에서 권장하는 완화 전략으로는 편향 및 공정성에 대한 정기적 감사, 평가 프로세스에 도메인 전문가 참여, 가변성을 줄이기 위한 프롬프트 디자인 표준화, 자동화된 평가 시스템과 인간의 감독 결합 등이 있습니다. 핵심은 인간과 AI의 협업이 신뢰성을 높이고 반복적인 개선을 가능하게 한다는 것입니다. 아키텍트는 LLM 기반 평가를 인간 리뷰어를 대체하는 수단이 아니라, 그들의 능력을 증폭시키는 도구로 사용하도록 관측성 시스템을 설계해야 합니다.

8. 결론: 대규모로 신뢰할 수 있고 관측 가능한 AI 시스템 구축하기

에이전트형 AI 시스템의 관측성을 위해서는 모니터링 대상과 방법에 대한 근본적인 확장이 필요합니다. Foundry와 Azure Monitor를 이용한 마이크로소프트의 접근 방식은 통합된 모델을 보여줍니다. 에이전트는 모든 추론 단계를 캡처하도록 계측되고, LLM 기반 평가자는 품질과 안전성을 지속적으로 평가하며, 모든 신호는 기존 애플리케이션에 사용되는 것과 동일한 엔터프라이즈 모니터링 인프라로 흐릅니다. 다중 에이전트 오케스트레이션 트레이스 및 LLM 추론 컨텍스트에 대한 마이크로소프트의 기여를 포함한 OpenTelemetry 개방형 표준을 기반으로 구축함으로써, 조직은 특정 벤더에 종속되지 않으면서 멀티 클라우드 환경 전반에서 일관된 가시성을 확보할 수 있습니다.

아키텍트들을 위한 실질적인 시사점은 첫날부터 관측성을 고려하여 설계하라는 것입니다. 추론 트레이스를 계측하고, 품질 및 안전 평가자를 조기에 정의하며, CI/CD에서 평가를 자동화하고, 명확한 에스컬레이션 임계값이 있는 지속적 모니터링 체계를 구축하십시오.

즉각적인 다음 단계로, 팀은 에이전트 모니터링 대시보드를 활성화하여 첫 번째 에이전트의 토큰 사용량, 지연 시간, 성공률, 평가 점수 및 레드팀 결과를 추적하기 시작할 수 있습니다. 아직 계획 단계에 있는 팀이라면 트레이스 계측, 평가자 선택, 안전 기준선 구성, 비용 알림 및 거버넌스 제어를 포함하는 관측성 체크리스트를 작성하여 에이전트가 프로덕션에 도달했을 때 중요한 신호를 놓치지 않도록 준비하십시오.

기존 애플리케이션에 적용했던 것과 동일한 수준의 엄격한 테스트, 비용 거버넌스, 규정 준수 및 지속적 개선 노력을 생성형 AI 에이전트에도 적용하는 조직만이 궁극적으로 엔터프라이즈 규모에서 AI 시스템에 대한 신뢰를 얻고 유지할 수 있을 것입니다.

9. 에이전트 관측성 시작하기

이러한 관측성 패턴을 구현할 준비가 되셨나요? 다음 경로 중 하나를 선택해 보세요.

🚀 빠른 시작

• 관측 가능한 에이전트 배포: Microsoft Foundry와 함께 제공되는 호스팅된 에이전트 빠른 시작 단계를 따르세요. Azure Developer CLI를 사용하여 샘플 에이전트를 설정하고 실제 모니터링이 작동하는 모습을 확인할 수 있습니다.
• 에이전트 모니터링 대시보드 탐색: Foundry 프로젝트의 대시보드 가이드를 열어 에이전트가 요청을 처리할 때의 라이브 메트릭, 트레이스 및 안전 점검 결과를 확인하세요.

📚 심화 학습

• 평가 마스터하기: Microsoft Foundry의 내장 평가자 개념을 읽고 품질, 안전 및 에이전트 평가자의 전체 카탈로그를 이해하십시오. 또한 도메인별 기준을 위한 맞춤형 평가자 생성 방법도 알아보세요.
• 레드팀 연습: AI 레드팀 가이드를 따라 적대적 시나리오를 시뮬레이션하고 배포 전후에 에이전트의 방어력을 강화하세요.

🤝 커뮤니티 참여

• Foundry 포럼: GitHub 토론에서 질문을 남기고 통찰력을 공유하세요.
• GitHub 샘플: Foundry 샘플 저장소에서 에이전트, 평가 및 모니터링 설정의 예시를 살펴보세요.
• 커뮤니티 채팅: Discord에서 다른 개발자들과 연결하여 모범 사례를 논의하고 최신 팁을 얻으세요.

📧 최신 소식 받기

• Azure AI 뉴스레터: AI 뉴스레터를 구독하여 Microsoft Foundry 및 관측성 혁신을 포함한 Azure AI의 새로운 기능, 사례 연구 및 모범 사례에 대한 월간 업데이트를 받으세요.