운영 배포와 변경 관리

7.1 운영 배포와 변경 관리

세부 학습 목표

• Azure 인프라·모델·에이전트·앱·검색 구성의 배포 책임을 나눈다.
• Global/Data Zone/geography와 Standard/Provisioned/Batch의 선택 축을 비교한다.
• 자료·프롬프트·모델·도구·평가 버전을 묶어 CI/CD 승격·관측·복구를 정한다.

개요

• 배포 대상: 모델·앱 코드·검색 인덱스·도구·환경 설정.
• 유형 선택: 처리 위치·요청 부하·응답 시간·비용 비교.
• 변경 관리: 함께 동작하는 버전과 복구 경로 기록.

모델 배포와 앱 배포

• 모델을 선택했다는 것만으로 웹 앱이 완성되지는 않습니다.

  모델 배포에는 호출에 사용할 이름과 용량, 처리 위치 등의 설정이 필요합니다. 앱에는 사용자의 인증, API 호출, 오류 처리, 화면이 들어갑니다. 검색 시스템에는 문서 수집과 인덱스 갱신이 별도로 필요합니다. 같은 모델을 사용해도 이 구성 중 하나가 바뀌면 답변이 달라질 수 있습니다.

• 예를 들어 환불 상담 서비스를 운영한다면 refund-chat이라는 모델 배포, 고객 상담 API, 약관 검색 인덱스, 환불 요청 도구를 각각 확인합니다.

  모델 호출만 성공해도 검색 권한이 없으면 근거를 가져오지 못합니다. 도구 API가 개발용 주소를 바라보면 실제 업무를 처리할 수 없습니다. 배포 후 검증은 사용자 요청에서 도구 결과까지 이어져야 합니다.

위치와 용량을 다른 축으로 비교한다

• Global이라는 이름은 저장 데이터의 위치와 추론 처리 위치가 같다는 뜻이 아닙니다.

  저장 위치와 처리 경로를 나눠 확인합니다. 또한 Provisioned를 사용해도 앱의 데이터베이스 지연이나 잘못된 검색 설계까지 해결되지는 않습니다. 모델별로 선택 가능한 유형이 다르므로 배포 화면과 공식 지원 표를 확인합니다.

Standard의 geography 경계는 단일 데이터센터나 한 Azure 지역에 고정된다는 보장이 아닙니다. 같은 geography의 여러 지역 사이에서 처리될 수 있습니다. 단일 지역 고정이 필수라면 유형 이름만으로 충족한다고 판단하지 말고 현재 제품의 처리 위치 계약을 확인합니다.

• 예를 들어 야간에 문서 10만 건을 분류하는 작업은 Batch를 검토할 수 있습니다.

  사용자가 기다리는 실시간 상담에는 응답 지연과 혼잡 시 동작이 더 중요합니다. 이러한 선택은 업무 조건에 따른 설계 판단이며 모든 프로젝트에 동일한 유형을 적용하는 규칙은 아닙니다.

변경한 구성을 재현할 수 있어야 한다

아래는 이 교재에서 정의한 앱 배포 기록 예시입니다. Azure에 그대로 제출하는 설정 파일이 아닙니다.

{
  "release": "refund-app-2026-10-21.1",
  "code_commit": "example-commit",
  "model_deployment": "refund-chat",
  "prompt_version": "refund-v3",
  "index_version": "policy-2026-10",
  "evaluation_set": "refund-regression-v2",
  "tool_contract": "refund-request-v1"
}

• 오류가 늘었을 때 이 기록이 있어야 “프롬프트만 되돌릴지, 인덱스도 되돌릴지”를 판단할 수 있습니다.

  운영 중인 인덱스를 바로 덮어쓰기보다 새 버전을 만들고 평가한 뒤 전환하면 이전 구성을 보존하기 쉽습니다. 단, 모델 버전이 종료되면 과거 구성을 영구히 재현할 수 있는 것은 아니므로 지원 기간도 변경 계획에 넣습니다.

CI/CD에서 검사할 것

• CI는 변경 사항을 자동으로 검사하는 과정이고, CD는 검증한 결과물을 대상 환경에 전달하는 과정입니다.

  코드 문법 검사와 단위 테스트, 답변 평가, 제한된 테스트 환경에서의 호출 검증은 서로 다른 실패를 찾습니다. “한 번 답했다”는 확인은 가용성을 점검하는 smoke test이며, 정확성·안전성 평가를 대신하지 않습니다.

• 배포 작업의 클라우드 인증은 장기 키를 소스에 저장하는 방식보다 워크로드 ID 연동을 검토합니다.

  GitHub Actions에서 OIDC를 쓰더라도 해당 ID에 실제 배포 권한을 부여해야 합니다. 평가 기준과 배포 절차를 구분하는 실습은 CI/CD 보충 실습에 있습니다.

Azure 인프라 경계 설계

• AI 앱 배포는 모델 배포만으로 끝나지 않습니다.

  앱의 호출자, 서비스 신원, 검색 저장소, 모니터링 및 장애 경로까지 설계해야 합니다. 공용 접근이 가능한 리소스와 사설 네트워크 자원을 구분합니다.

• 상황: 사내 문서 챗봇을 브라우저에서 직접 모델 API로 호출하도록 설계하니 비밀키 노출 위험이 생겼습니다.

• 적용: 브라우저는 앱 서버에 요청하고 서버는 사용자·자료 권한을 검증한 다음 필요한 리소스를 호출하도록 구성합니다.

지역·데이터 거주성 조건 확인

• 모델이 지원되는 지역과 데이터 저장·처리 관련 조건은 서비스 및 배포 옵션별로 다를 수 있습니다.

  지역만 맞췄다고 모든 데이터 경로가 같은 지역에 남는다고 가정하지 않습니다.

• 상황: 고객 데이터의 지정 지역 처리가 계약 조건인데 원하는 모델은 다른 배포 유형에서만 제공되는 상황입니다.

• 적용: 서비스·배포 유형별 처리 위치 및 계약 조건을 공식 문서로 확인하고, 허용 모델 대체 또는 설계 변경을 비교합니다.

모델 배포 방식 비교

• 표준형과 프로비저닝형 등 배포 옵션은 이용 가능한 기능, 용량, 과금·확장 조건이 다를 수 있습니다.

  최신 지원 상태와 용량·지역 조건을 확인한 뒤 선택합니다.

• 상황: 야간에는 요청이 적고 오전 업무 시작 직후 집중되는 고객지원 서비스가 있습니다.

• 적용: 피크 시점의 요청량과 평균 이용률을 따로 측정한 뒤 표준형의 탄력성·할당량과 프로비저닝형의 용량·비용을 비교합니다.

모델·에이전트·앱 배포 구분

• 모델 엔드포인트가 준비되어도 앱 코드·프롬프트·도구 정의·에이전트 설정은 별도로 관리해야 합니다.

  장애가 발생하면 바뀐 구성과 호환성을 확인하고, 함께 정상 동작했던 버전 조합으로 복구할 수 있어야 합니다.

• 상황: 새 에이전트 도구를 추가한 뒤 오류가 발생했지만 모델 배포는 정상입니다.

• 적용: 모델 배포 ID, 에이전트 지침/도구 버전, 앱 릴리스 ID와 호출 trace를 비교해 변화 지점을 찾습니다.

  변경한 도구나 앱을 되돌릴 때도 프롬프트·상태·인덱스와 호환되는지 확인하고 대표 요청으로 복구 결과를 검증합니다.

확인 문제

app: R1 / model_processing: R1
search: R1 / storage: R1
trace_export: R2 / payload=full_prompt_and_documents
access: private / identity=managed_identity
R2: 승인되지 않은 지역

model_call: HTTP 200 / identity=app-id
agent_run: started / identity=agent-id
tool_call inventory: DNS resolution failed
agent_runtime: private network N1
inventory.internal: private DNS zone linked to N2 only

기준: answer_pass_rate ≥ 0.90 AND unauthorized_actions == 0
이전: code=c7 / prompt=p2 / index=i4 / rate=0.93 / actions=0
후보: code=c7 / prompt=p3 / index=i4 / rate=0.95 / actions=1
smoke_test: passed

참고 자료

• Deployment types for Microsoft Foundry Models 
• Baseline Microsoft Foundry chat reference architecture 
• Quickstart: Hosted agent CI/CD templates 
• How to run an evaluation in GitHub Action (preview) 

자료 확인: 2026-10-25 · 적용 사례 교정: 2026-10-23. 사례는 교육용이며 Azure API 호출·요금은 실행 검증하지 않았습니다.

새 배포에서 코드 v8, 프롬프트 p4, 인덱스 i9로 바꾼 뒤 오답이 늘었습니다. 코드만 v7로 되돌렸지만 오답이 계속됩니다.