Microsoft Build 2027 전, Foundry Hosted Agents 배포는 어떻게 검수할까?

이번 주에는 Microsoft Foundry Hosted Agents 배포 검수에서 실행 계약, 준비 상태, 세션, 인증, 배포 뒤 호출을 모두 확인한 다음 확대 여부를 결정하세요. 코드형 에이전트를 Foundry에 올릴 수 있어도 애플리케이션 로직과 실제 실행 결과까지 플랫폼이 대신 검증해 주는 것은 아닙니다.

이 글은 로컬 에이전트를 Microsoft Foundry Hosted Agents로 옮기려는 개발자를 위한 안내입니다.
컨테이너, 준비 상태 확인, 게시 흐름을 맡은 플랫폼 엔지니어도 활용할 수 있습니다.
Microsoft Build 2027을 앞두고 기존 에이전트의 클라우드 운영 준비를 점검하려는 팀에도 적합합니다.

로컬 개발 환경과 클라우드 실행 환경은 책임이 다릅니다

Foundry Hosted Agents는 코드형 에이전트를 컨테이너화된 애플리케이션으로 관리형 인프라에 배포하는 방식입니다. 다만 관리형 실행 환경이 제공된다는 사실만으로 앱의 모든 의존 항목과 동작이 지원된다고 볼 수는 없습니다. 적용 가능한 언어, 패키징 방식, 실행 조건은 Microsoft Learn의 Hosted Agents 개요와 실제 배포 문서에서 확인하세요.

특히 다음 항목은 배포 전에 직접 찾아야 합니다.

• 외부 의존성: 데이터 저장소, 사내 API, 파일 서버에 연결하는 코드와 네트워크 접근 조건을 적습니다.
• 프로세스와 파일: 로컬 경로에 기록하는 파일, 프로세스 종료 처리, 임시 파일 정리 방식을 확인합니다. 로컬에서 동작하는 경로가 관리형 컨테이너에서도 그대로 유지된다고 단정하지 마세요.
• 인증 정보: 코드에 비밀값을 넣지 말고, 실제 배포에서 사용할 인증 방식과 필요한 권한을 구분합니다.
• 세션 상태: 대화 맥락이나 작업 진행 상황이 프로세스 메모리에만 남는지, 외부 저장소를 이용하는지 확인합니다.
• 관찰 가능성: 실패 원인을 추적할 수 있도록 요청 식별 정보와 오류 기록을 남기는 방법을 준비합니다.

Microsoft Foundry Agent Service를 검토할 때는 플랫폼이 제공하는 호스팅 절차와 팀이 책임지는 애플리케이션 검증을 따로 적어 두세요. 공식 자체 코드 배포 빠른 시작은 예제를 따라 해 보는 출발점이지, 당신의 패키지나 계정에 맞는 설정값을 보증하는 자료는 아닙니다.

비교표로 먼저 고를 검수 범위를 정합니다

아래 표는 배포를 진행할지, 로컬 수정으로 돌아갈지 판단하는 기준입니다. 지원 여부와 구체적인 명령은 배포 시점의 공식 문서에서 다시 확인하세요.

1단계: 요청과 응답 계약을 로컬에서 대조합니다

공식 Hosted Agent 실행 계약에서 현재 사용하는 요청 경로, 메서드, 데이터 형식, 응답 조건을 확인하세요. 프레임워크가 요청을 받아 준다고 해도 앱의 입력 해석, 도구 실행, 예외 처리까지 모두 맞다는 뜻은 아닙니다.

로컬 테스트는 다음 순서로 진행합니다.

1. 정상 입력을 보내고 응답 내용과 형식을 기록합니다.
2. 필수 값이 빠진 요청이나 잘못된 형식의 요청을 보내 오류가 예상대로 전달되는지 확인합니다.
3. 스트리밍을 사용하는 앱이면 응답이 여러 조각으로 도착할 때 클라이언트가 이를 올바르게 읽는지 시험합니다.
4. 같은 세션에서 이어지는 요청을 보내 상태가 유지되는지 확인합니다.
5. 준비 상태 확인과 실제 업무 요청을 별도로 실행합니다.

HTTP 응답은 팀의 테스트에서 2xx 성공, 4xx 요청 또는 인증 관련 거부, 5xx 처리 실패처럼 나눠 관찰할 수 있습니다. 이 구분은 테스트 결과를 정리하기 위한 기준입니다. 실제 앱의 기대 응답과 재시도 정책은 실행 계약과 애플리케이션 설계에 맞춰 정하세요. 플랫폼이 특정 앱의 오류 처리까지 보장한다고 해석해서는 안 됩니다. 실행 계약 문서

준비 상태 확인이 성공해도 업무 요청 성공이 증명되는 것은 아닙니다. 준비 상태와 실제 에이전트 호출을 별도 테스트로 남기세요.

2단계: 패키징과 게시 상태를 문서 기준으로 확인합니다

배포 방식에 따라 코드 준비, 패키징, 버전 생성, 게시 상태 확인, 호출 주소 확인의 흐름을 추적하세요. 공식 Hosted Agents 배포 안내에 나온 절차와 용어를 기준으로 삼되, 예전 블로그나 복사해 둔 명령을 그대로 실행하지 마세요. SDK와 배포 선택지는 바뀔 수 있으므로 실제 배포 직전에 현재 문서의 명령과 전제 조건을 확인해야 합니다.

확인할 때는 “성공”이라는 한 가지 표시에 의존하지 말고 다음을 따로 기록합니다.

• 어떤 코드와 패키지로 게시했는지
• 새 버전이 만들어졌는지, 현재 어떤 상태인지
• 호출에 사용한 대상이 방금 게시한 버전과 일치하는지
• 시작 또는 준비 상태 확인 중 오류가 있었는지

게시 단계에서 막히면 앱 코드부터 무작정 바꾸기보다 배포 상태와 로그를 확인하세요. 공식 디버그 안내는 원인 추적에, Hosted Agent 로그 안내는 실행 기록 확인에 참고할 수 있습니다.

3단계: 배포 뒤 호출과 인증을 따로 검증합니다

배포가 끝난 뒤에는 호출 클라이언트가 실제 배포 대상에 연결되는지부터 확인합니다. 이어서 성공 요청, 잘못된 요청, 권한이 없는 요청을 보내 응답 차이를 기록하세요. 인증 설정은 배포 환경의 연결 정보와 앱이 요청자를 판단하는 방식을 나눠 점검해야 합니다. 인증 구성이 있다는 이유만으로 필요한 권한까지 적절하다고 볼 수는 없습니다.

세션 검증은 연속 요청과 새 대화의 결과를 비교합니다. 같은 세션에서는 유지되어야 하는 정보가 보존되는지 확인하고, 새 세션에서는 앞선 대화의 민감한 맥락이 이어지지 않는지 살펴보세요. 이 동작은 앱이 상태를 저장하고 복원하는 방식에 달려 있습니다. 테스트 입력과 응답, 사용한 게시 버전을 묶어 기록하면 재현하기 쉽습니다.

관찰 데이터를 더 연결해 볼 계획이라면 에이전트 추적 설정 문서를 확인하세요. 추적을 켰다는 사실과 팀이 필요한 정보를 실제로 볼 수 있다는 사실은 다릅니다. 요청부터 도구 실행과 응답까지 확인 가능한지 직접 점검해야 합니다.

첫 주에는 확대보다 이상 징후 분류를 우선합니다

첫 주의 관찰 항목은 Microsoft가 약속한 성능 기준이 아니라 팀이 운영 결정을 위해 정하는 지표입니다. 호출 실패 유형, 재시도 여부, 세션 이상, 게시 버전 변경을 기록하세요. 실패율 같은 숫자를 사전에 임의로 합격 기준으로 두기보다, 실제 사용 목적에 맞춰 허용 범위와 중단 조건을 정하는 편이 낫습니다.

• [ ] 실행 계약에 맞는 입력과 응답을 확인했습니다.
• [ ] 준비 상태와 업무 요청 결과를 따로 확인했습니다.
• [ ] 정상 입력, 잘못된 입력, 인증 실패를 시험했습니다.
• [ ] 연속 세션과 새 세션을 비교했습니다.
• [ ] 게시 버전과 호출 대상이 일치하는지 확인했습니다.
• [ ] 실패 유형과 재시도, 세션 이상, 버전 변경을 기록할 담당자를 정했습니다.
• [ ] 문제가 생기면 이전에 검증된 버전으로 되돌릴 절차를 마련했습니다.

이 항목을 충족하고도 실패 원인을 찾지 못하거나 세션과 권한 동작이 불분명하다면 확대를 멈추고 수정하세요. 운영 절차와 문의 경로를 더 살펴봐야 한다면 Hashvps 도움말 센터에서 관련 안내를 확인할 수 있습니다.

자주 묻는 질문

Microsoft Foundry Hosted Agents 배포를 서두르기 전에 실행 계약과 애플리케이션 의존성을 먼저 확인하세요. 아래 질문은 배포 전 준비, 프로토콜과 준비 상태, 세션, 실패 원인을 각각 점검할 때 참고할 수 있습니다.

로컬 장비와 원격 실행 환경 중 무엇을 선택할까요?

로컬 실행은 빠른 코드 수정에 편하지만, 장비가 꺼지거나 네트워크와 로컬 파일에 기대면 팀이 같은 조건으로 재현하기 어려울 수 있습니다. Foundry Hosted Agents는 클라우드에서 코드형 에이전트를 실행하려는 경우 검토할 수 있지만, 앱의 프로토콜과 상태 관리는 여전히 직접 검증해야 합니다. macOS 전용 빌드나 테스트가 필요하다면 별도의 클라우드 맥 환경이 더 적합할 수 있습니다. Hashvps의 서비스 구성 안내를 확인할 때도 필요한 운영체제와 작업 조건이 맞는지 먼저 살펴보세요.