이 글은 Contoso IT 서비스 데스크인 HelpDesk Copilot의 개발에 대해 논의하며, Microsoft Foundry 에이전트를 활용하여 직원들의 질문을 분류하고 IT 지식 기반에 근거한 답변을 제공합니다. 이 시스템은 정책상 필요할 때 실제 채널을 통해 사람에게 인계하도록 설계되었습니다. 아키텍처는 세 개의 Azure Container Apps, 하나의 Foundry Prompt Agent, 그리고 이벤트 기반 티켓 파이프라인으로 구성됩니다. 이 에이전트는 File Search, create_ticket, get_ticket_status의 세 가지 기능을 가지고 있으며, 직원들의 질문에 답변하고 필요시 문제를 에스컬레이션하는 데 사용됩니다.이 시스템은 Azure Container Apps를 기반으로 구축되었으며, Terraform으로 완전히 프로비저닝되었고 API 키가 전혀 사용되지 않습니다. 모든 서비스 간 호출은 Microsoft Entra ID와 관리 ID를 사용합니다. Foundry 계정은 로컬 키 인증이 완전히 비활성화되어 있습니다. 아키텍처는 이벤트 기반으로 설계되었으며, API는 티켓 이벤트를 Service Bus 토픽으로 게시하고, 이는 Dapr 구독을 통해 워커에게 전달됩니다. 워커는 티켓을 Table Storage에 업서트하고 페이로드를 Power Automate HTTP 흐름으로 게시하여 IT 팀의 Teams 채널로 Adaptive Card를 보냅니다.이 시스템은 멱등성을 갖도록 설계되었으며, 티켓 ID는 대화 ID와 제목에서 결정론적으로 파생되어 동일한 대화에서 동일한 문제에 대해 반복적인 create_ticket 도구 호출이 중복을 생성하는 대신 동일한 ID로 축소되도록 합니다. 또한, 이 시스템은 최종 일관성을 사용하며, 워커가 KEDA에 의해 깨어나는 동안 티켓 행이 몇 초 동안 존재하지 않을 수 있습니다. 아키텍처는 확장 가능하도록 설계되었으며, API를 변경하지 않고 Service Bus 토픽에 새로운 구독을 추가할 수 있습니다.ID 모델은 DefaultAzureCredential을 통해 Entra ID를 사용하도록 설계되었으며, 각 앱은 사용자 할당 관리 ID를 사용합니다. API, 워커, 프론트엔드는 각각 자체 ID를 가지며, API는 AcrPull, Foundry 에이전트 액세스, Storage Table Data Reader, Key Vault Secrets User, Service Bus Sender에 액세스할 수 있습니다. 워커는 AcrPull, Storage Table Data Contributor, Key Vault Secrets User, Service Bus Receiver에 액세스할 수 있으며, 프론트엔드는 AcrPull에만 액세스할 수 있습니다.이 글은 또한 Azure 리소스를 프로비저닝하기 위해 Terraform을 사용하는 것에 대해 논의하며, 저자는 명백해 보이는 리소스가 항상 올바른 것은 아니라고 언급합니다. 저자는 azapi 대신 azurerm_cognitive_account를 사용하여 Foundry Agent Service를 프로비저닝해야 했습니다. 이 글은 시스템이 관리 ID와 Entra ID를 사용하여 서비스 간 호출을 인증하는 데 중점을 두고 안전하고 확장 가능하며 이벤트 기반으로 설계되었다는 점을 언급하며 마무리됩니다.