deploying-scalable-agents

Microsoft Foundry로 확장 가능한 에이전트 배포하기

Lesson 16 – Deploying Scalable Agents의 동반 스킬입니다. 학습자가 에이전트를 프로토타입에서 확장 가능하고 관찰 가능한 운영 배포로 옮길 수 있도록 지원하는 데 사용하세요. 모든 권장사항은 수업 내용과 실행 가능한 노트북에 근거해야 하며, Foundry API를 새로 창작하지 마세요.

트리거

학습자가 다음을 원할 때 이 스킬을 활성화하세요:

• 에이전트를 Microsoft Foundry에 <strong>호스팅된 에이전트</strong>로 배포하고 버전 관리 및 관찰 가능하게 만들기.
• 클라이언트 호스팅, 호스팅 에이전트, 에이전트 워크플로우 배포 패턴 중 선택.
• 지연 시간과 비용을 제어하기 위해 모델 라우팅, 응답 캐싱, 또는 유한 동시성 추가.
• 불량 에이전트 버전이 배포되지 않도록 하는 평가 게이트 추가.
• 고위험 작업에 대해 사람 개입 승인 절차 추가.
• 운영 관찰성을 위해 에이전트를 OpenTelemetry 추적 도구로 계측.
• 배포 후 빠른 검증을 위한 스모크 테스트 실행.

핵심 정신 모델

운영 에이전트는 대체로 모델(~80%) <em>주변</em>의 운영 스켈레톤이며, 모델 자체가 아닙니다. 모든 권장사항을 다음 관심사 중 하나에 매핑하세요:

관심사	프로토타입 → 운영
호스팅	노트북 → 버전 관리 호스팅 서비스
ID	여러분의 az login → 관리 ID + 범위가 지정된 RBAC
상태	인메모리 → 외부화된 스레드/메모리 저장소
실패	트레이스백 → 재시도, 폴백, 알림
비용	"몇 센트" → 추적, 라우팅, 캐싱, 예산 적용
품질	육안 검사 → 자동화 평가 게이트
신뢰	당신 승인 → 정책 + 사람 개입 루프

배포 패턴 (하나 선택하거나 조합)

1. 클라이언트 호스팅 — 추론 루프가 본인 프로세스에서 실행됩니다. 최대 제어; 확장/상태 관리를 직접 수행.
2. 호스팅 에이전트 (Foundry Agent Service) — Foundry가 루프를 호스팅하고, 스레드를 저장하며, RBAC/콘텐츠 안전을 시행해 포털에 에이전트를 표시. 제어는 줄고 운영 부담이 훨씬 적음.
3. 에이전트 워크플로우 — 여러 에이전트 및 도구를 그래프로 구성, 분기, 승인 노드, 내구성 체크포인트 포함.

라이프사이클 (에이전트가 배포되는 루프)

생성 → 버전 관리 → 평가(게이트) → 호스팅 배포 → 온라인 관찰 → 실패 수집 → 반복. 오프라인 평가는 게이트이지 사후 처리 아님 — 문턱값을 통과하지 못하면 버전은 배포되지 않습니다. 온라인 관찰성은 실제 실패를 오프라인 테스트셋으로 되돌려 줍니다.

확장 및 비용 조절 장치 (우선순위 순)

1. 적절한 크기의 모델 선택 — 평가 게이트를 통과하는 가장 작은 모델을 사용.
2. 복잡도 별 라우팅 — 간단한 요청엔 작고 빠른 모델, 복잡한 추론엔 큰 모델 사용 (DIY 분류기 또는 Foundry 모델 라우터).
3. <strong>캐시</strong> — 거의 중복된 요청은 모델 호출 없이 응답.
4. 무상태 설계 + 유한 동시성 — 상태 외부화; 백오프 기반 재시도.

재현해야 할 주요 패턴

학습자에게 노트북 내 다음 내용을 안내하세요 16-python-agent-framework.ipynb:

• 요청 처리기: 캐시 → 복잡도 별 라우팅 → 추적 스팬 → 실행 → 캐시.
• 평가 게이트: 오프라인 테스트셋 점수 계산; pass_rate >= threshold 반환 및 통과 시에만 배포.
• 사람 승인: 대규모 환불 같은 작업은 @tool(approval_mode="always_require") 사용.
• <strong>추적</strong>: 각 요청을 tracer.start_as_current_span(...)으로 감싸고 routed.model, customer.id 같은 속성 설정.

배포된 에이전트 스모크 테스트

배포 후 실제로 엔드포인트가 응답하는지 확인 (배포 상태가 “성공”이라도 무응답일 수 있음). AI Smoke Test 액션을 .github/workflows/smoke-test.yml 과 tests/ 카탈로그와 함께 사용하세요. 실행기는 각 프롬프트를 POST {project_endpoint}/agents/{agent_name}/endpoint/protocols/openai/responses 엔드포인트에 보내고 응답 텍스트를 검증합니다. ID는 Foundry 프로젝트 범위에서 Azure AI User 역할을 필요로 하며 토큰 대상은 https://ai.azure.com/이어야 합니다.

게이트를 층별로 쌓으세요: 스모크 테스트 (모든 배포마다 도달 가능/응답성 확인) → 오프라인 평가 (출시 전 충분히 우수함 확인) → 온라인 평가 (실제 운영 중 성능 모니터링).

기업 통제 수단

• RBAC: 각 호스팅 에이전트에 최소 권한의 관리 ID 부여.
• 운영 중 MCP: 모든 MCP 서버를 신뢰할 수 없는 경계로 취급 — 버전 고정, ID 범위 지정, 출력 검증, 속도 제한, 비밀 노출 절대 금지.

어시스턴트 보호 장치

• 이 과정 전반에서 사용하는 정식 FoundryChatClient(...) + provider.as_agent(...) 패턴 선호.
• 검증하지 않은 라이브 Azure 결과를 약속하지 말고 배포 확인을 위해 스모크 테스트 워크플로 권장.
• 평가와 비용 조언을 연계 유지: 평가는 품질 기준을 세우고, 라우팅/캐싱은 비용을 그 기준 근처에 유지.

---

<!-- CO-OP TRANSLATOR DISCLAIMER START --> 면책 조항: 이 문서는 AI 번역 서비스 Co-op Translator를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역은 오류나 부정확한 부분이 있을 수 있음을 유의하시기 바랍니다. 원본 문서의 원어본이 권위 있는 자료로 간주되어야 합니다. 중요한 정보의 경우, 전문가의 인간 번역을 권장합니다. 이 번역 사용으로 인해 발생하는 오해나 잘못된 해석에 대해 당사는 책임을 지지 않습니다. <!-- CO-OP TRANSLATOR DISCLAIMER END -->