Azure AI Foundry의 평가(Evaluations), 가드레일 및 레드팀 운영: 타사 또는 온프레미스 에이전트에도 적용될까?

메타 설명: Azure AI Foundry의 평가, 가드레일, 그리고 레드팀 운영 기능이 타사 클라우드나 온프레미스 환경에서 실행되는 에이전트까지 도달할 수 있을까요? 실제 아키텍처, 한계점, 그리고 실제로 작동하는 것에 대해 알아봅니다.

2026년 평균적인 기업 AI 인프라를 상상해 보세요: LangChain으로 구축되어 AWS Lambda에 배포된 고객 지원 에이전트, 사설 데이터 센터의 Kubernetes 클러스터에서 실행되는 내부 코파일럿, 그리고 Azure의 새롭고 멋진 Foundry 네이티브 에이전트가 있습니다. 이 세 가지 모두 법적 승인을 받기 전에 동일한 안전 기준을 충족해야 합니다. 만약 귀사의 거버넌스 도구가 Azure에서 실행되는 것만 감지한다면, 그것은 안전 프로그램이 아닙니다. 그것은 전체 인프라의 3분의 1에 대한 안전 '취미'일 뿐입니다.

바로 이 지점이 팀들을 Azure AI Foundry의 외부 에이전트 등록(external agent registration) 기능으로 끌어당기는 정확한 긴장감이며, 현재 거의 모든 아키텍처 검토에서 듣는 질문을 만들어내고 있습니다: _Foundry가 어디서든 실행되는 에이전트를

심층 분석에 앞서, 답변의 개요를 한 장의 그림으로 보여드리겠습니다. Azure AI Foundry의 거버넌스 표면은 문제가 되는 에이전트가 Azure 외부에서 작동하는 경우 세 가지 영역으로 명확하게 나뉩니다. 즉, 별도의 설정 없이 바로 작동하는 것, 조건적으로만 작동하는 것, 그리고 사용자가 직접 연결 고리를 구축해야 하는 것입니다.

Infographic showing Azure AI Foundry's reach into third-party agents: Evaluation is yes via OpenTelemetry traces, Red Teaming is conditional and needs a reachable endpoint, Guardrails are no by default and need an AI Gateway

이 게시물의 나머지 부분은 이 표를 정당화하기 위해 존재합니다. 왜냐하면 AI 거버넌스에서 '상황에 따라 다르다(it depends)'는 말에 '무엇에 따라'라는 전제가 없으면 그저 어깨를 으쓱하는 것과 같기 때문입니다.

Foundry의 세 가지 관찰 가능성 기둥 (Three Observability Pillars)

Microsoft Foundry는 AI 관찰 가능성(AI observability) 스토리를 함께 작동하지만 목적이 다른 세 가지 핵심 기능으로 구성합니다:

**평가(Evaluation)**는 내장 평가 도구를 사용하여 AI 응답의 품질, 안전성 및 신뢰성을 측정합니다. 여기에는 일관성(coherence)과 유창성(fluency) 같은 일반 목적 지표, 근거성(groundedness)과 관련성(relevance) 같은 RAG(Retrieval-Augmented Generation)-특정 지표, 혐오/불공정 및 폭력 감지 같은 안전성 지표, 그리고 도구 호출 정확도(tool call accuracy)와 작업 완료(task completion) 같은 에이전트 특정 지표가 포함됩니다.

**모니터링(Monitoring)**은 프로덕션 계층입니다. Azure Monitor Application Insights와 통합되어 토큰 소비량, 지연 시간(latency), 오류율, 품질 점수를 실시간으로 추적하며, 출력이 품질 임계값을 위반할 경우 경고를 발생시킵니다.

**추적(Tracing)**은 OpenTelemetry 표준을 기반으로 구축된 분산 추적(distributed tracing)이며, LLM 호출, 도구 호출(tool invocations), 에이전트 의사 결정 체인 등의 실행 흐름을 포착합니다.

그 목록에서 눈에 띄게 빠진 것이 무엇인지 주목하세요: 가드레일과 레드팀 운영은 Foundry 자체의 프레이밍에서 핵심적인 '관측 가능성(observability)' 기본 요소가 아닙니다. 가드레일(Azure AI Content Safety)은 콘텐츠 조정 및 정책 시행 서비스입니다. 레드팀 운영(AI Red Teaming Agent)은 Microsoft의 오픈 소스 PyRIT 프레임워크를 기반으로 구축된 선제적 적대 테스트 서비스입니다. 이 세 가지 요소—평가, 가드레일, 레드팀 운영—는 관련이 있지만 아키텍처적으로 구별되므로, 외부 에이전트에도 같은 방식으로 확장되지 않는 것입니다.

외부 에이전트 등록 작동 방식

이것이 Foundry에 호스팅되지 않은 에이전트에 이 모든 것을 가능하게 하는 기능이므로, 이것이 정확히 무엇을 하는지—그리고 더 중요하게도, 명시적으로 무엇을 하지 않는지 이해할 가치가 있습니다.

Foundry는 어떤 클라우드, 온프레미스 또는 다른 호스트에서 실행되는 에이전트를 등록하여 Foundry의 트레이스 뷰 및 평가 경험을 사용할 수 있도록 합니다. 결정적으로, Foundry는 이러한 에이전트의 등록 메타데이터만 저장합니다—이름, 설명, 그리고 otel_agent_id입니다. Foundry가 에이전트의 런타임을 호스팅하거나, 프록시하거나, 호출하지 않습니다. 사용자의 에이전트는 기존 엔드포인트를 유지하며, AI Gateway가 필요하지 않습니다.

메커니즘은 놀라울 정도로 단순합니다: 외부 에이전트에 OpenTelemetry를 장착하여, gen_ai.agent.id 속성이 태그된 스팬을 Foundry 프로젝트에 연결된 Application Insights 리소스로 방출합니다. 별도의 등록 호출이 Foundry에 에이전트 레코드를 생성합니다. 그런 다음 Foundry 포털은 들어오는 트레이스를 에이전트 ID로 해당 등록과 일치시키고 트레이스 뷰에 표시하며—트레이스가 흐르기 시작하면, 그 트레이스를 대상으로 직접 기반 평가를 실행할 수 있습니다.

[

Architecture diagram showing an external agent on third-party cloud or on-prem sending OpenTelemetry spans to Application Insights, which feeds a Microsoft Foundry Project containing Trace Viewer, Evaluation Engine, and Red Teaming Agent, with red teaming probe calls going back to the external agent](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fxs9l7qt72lwcsdn5t1ep.png

잠시 생각해 볼 가치가 있는 부분입니다. '사용자 에이전트'와 'Foundry의 거버넌스 도구' 사이의 전체 연결 통로는 트래픽 프록시가 아니라 텔레메트리 파이프라는 것입니다. 이 단 하나의 설계 결정이 이후 모든 것의 근본 원인이며, 이것이 평가(evaluation)가 클라우드 경계를 넘어 깨끗하게 이동할 수 있는 이유이자, 가드레일(guardrails)은 근본적으로 할 수 없는 이유입니다.

타사 및 온프레미스 에이전트 평가: 진정한 가능성

세 가지 기능 중 평가가 유일하게, 명확하게 어디서든 실행되는 에이전트에 확장될 수 있는 기능입니다. 그 메커니즘을 살펴보겠습니다.

외부 에이전트를 계측(instrument)하면 — Microsoft OpenTelemetry 배포판(Python, .NET 및 JavaScript용으로 사용 가능) 또는 자체 규격 준수 OpenTelemetry 설정을 사용하여 — 정상 작동 중 방출되는 모든 스팬(span)은 gen_ai.agent.id 속성을 가집니다. 이 스팬들은 에이전트가 AWS, GCP, 코로케이션 시설, 또는 책상 아래에 있든 관계없이 Application Insights에 기록되며, 단지 Application Insights 수집 엔드포인트로 아웃바운드 HTTPS 호출을 할 수만 있다면 가능합니다.

여기서부터 Foundry의 트레이스 기반 평가(trace-based evaluation)는 캡처된 텔레메트리를 통해 OpenAI와 호환되는 evals API를 직접 실행합니다. 별도의 데이터셋 구축이 필요하지 않습니다. Foundry는 조회 기간(lookback window) 동안 (프로젝트, 에이전트_id)를 일치시켜 트레이스를 해결합니다. 에이전트가 안정적인 gen_ai.conversation.id를 방출하는 한, 개별 상호작용(입력, 출력, 도구 호출, 지연 시간)은 물론 다중 턴 대화까지 평가할 수 있습니다.

이는 Azure 외부에서 완전히 실행되는 지원 봇조차도 Microsoft가 Foundry 네이티브 에이전트에 적용하는 것과 정확히 동일한 평가기(evaluators)를 사용하여 근거성(groundedness), 일관성(coherence), 작업 완료, 그리고 증오/불공정성 또는 보호 자료 노출 같은 안전 관련 지표로 점수를 매길 수 있다는 것을 의미합니다. 진정으로 이질적인 에이전트군을 가진 조직에게 있어, 이것은 전체 외부 에이전트 시나리오에서 가장 유용한 기능입니다: 호스팅 위치에 관계없이 단일 평가 대시보드(one evaluation pane of glass).

주의할 점: 여기서의 평가는 오직 사후적으로(after the fact) 이루어지며, 수집된 원격 측정 데이터(telemetry)를 대상으로 실행됩니다. 이는 에이전트의 출력을 실시간으로 차단하거나, 수정하거나, 거부할 수는 없습니다. 그것은 가드레일(guardrail)의 역할이며, 이야기가 달라지는 지점이 바로 여기에 있습니다.

가드레일: 콘텐츠 안전성이 외부 에이전트에 자동으로 적용되지 않는 이유

사람들이 혼동하는 부분이 바로 이 섹션입니다. 왜냐하면 '가드레일'과 '평가(evaluation)'는 함께 움직여야 할 것 같은 느낌을 주기 때문입니다. 하지만 그렇지 않으며, 그 이유는 라이선스 제한이 아니라 아키텍처적인 문제입니다.

Azure AI Content Safety — Prompt Shields(탈옥 탐지), 근거성 탐지(groundedness detection), 보호 자료 스캔(protected material scanning), 유해 카테고리 필터링을 담당하는 서비스 — 는 모델이나 에이전트 호출의 요청/응답 경로 내에 인라인으로(inline) 자리하도록 설계되었습니다. 이는 응답이 사용자에게 도달하기 전, 또는 프롬프트가 모델에 도달하기 전에 발생하는 동기식 API 호출입니다. 바로 이 위치 덕분에 피해가 발생하기 전에 콘텐츠를 실제로 차단하거나, 삭제하거나, 플래그 지정할 수 있습니다.

반면, 외부 에이전트 등록은 그 경로를 주변으로(around) 명시적으로 아키텍처화되었습니다. 핵심 설계 원칙을 기억해 주세요: Foundry는

Microsoft의 자체 문서에서는 이 구분을 명확히 합니다: Control Plane 커스텀 에이전트는 트래픽을 AI Gateway를 통해 라우팅하며, 이 게이트웨이가 인라인 가드레일 적용과 플릿 전체 거버넌스를 가능하게 하는 구성 요소입니다. 외부 에이전트는 통합 마찰(integration friction)을 낮추기 위해 의도적으로 게이트웨이를 건너뜁니다. Foundry가 외부에서 보호 기능을 자동으로 삽입해주지 않기 때문에, 게이트웨이 경로 밖에 있는 에이전트의 프로덕션 안전성을 확보하기 위한 공식 권장 사항은 자체적인 안전 가드레일을 구현하는 것입니다. 즉, 에이전트 코드 내부에서 Content Safety API를 직접 호출하거나 Microsoft의 안전 시스템 메시 템플릿을 사용하는 방식입니다.

따라서 구체적으로 말씀드리자면: 타사 또는 온프레미스 에이전트에 Content Safety 스타일의 가드레일을 적용하려면 정확히 두 가지 실제 옵션이 있습니다. 첫째, Foundry의 Control Plane AI Gateway로 앞에 배치하여 아키텍처를 변경하고 사실상 Azure의 트래픽 경로 아래로 다시 가져오는 것입니다. 둘째, 자체 에이전트의 요청 처리 내부에서 Content Safety REST API를 직접 인라인으로 호출하는 것입니다. 에이전트를 Foundry에 등록한다고 해서 자동으로 인라인 보호가 부여되는 세 번째 옵션은 없습니다. (만약 귀하의 조직이 어떤 경로가 컴플라이언스 자세(compliance posture)에 맞는지 평가하고 있다면, 이는 라이브 전 별도의 아키텍처 논의가 필요합니다.)

레드팀 운영 (Red Teaming): 조건부 '예', 도달 가능성에 의해 제한됨

레드팀 운영은 스펙트럼의 중간 지점에 위치하며, 왜 그런지 이해하려면 레드팀 운영이 기계적으로 실제로 무엇을 하는지를 알아야 합니다. 이는 평가(evaluation)처럼 수동적인 원격 측정 소비자(telemetry consumer)가 아니며, 가드레일(guardrails)처럼 인라인 필터도 아닙니다. 이것은 **능동적인 탐색기(active prober)**입니다. Microsoft의 오픈소스 PyRIT 프레임워크를 기반으로 구축된 Foundry의 AI 레드팀 에이전트는 적대적 프롬프트로 귀하의 에이전트 또는 모델 엔드포인트에 도달하여 호출하고, 그 응답을 캡처하고 점수화해야 합니다.

이 단 하나의 사실만으로 이야기가 끝납니다: 레드팀 운영은 노크할 문이 필요합니다. 만약 귀하의 타사 또는 온프레미스 에이전트가 Foundry 레드팀 서비스가 도달할 수 있는 HTTP(S) 엔드포인트를 적절한 인증과 함께 노출한다면, 이는 표적이 될 수 있습니다. 아키텍처적으로 볼 때, 이는 모든 외부 API에 대한 레드팀 운영과 다르지 않습니다. Foundry는 에이전트를 호스팅할 필요가 없으며, 단지 연결성만 있으면 됩니다.