Foundry 포털에서 모델 배포하고 대화하기

셋째 노트에서 모델을 고르고 배포 유형과 파라미터를 정하는 판단을 다뤘고, 앞 노트에서 그 모델에 보낼 메시지를 짰습니다. 이 노트는 그 둘을 실제 손 순서로 잇습니다. Microsoft Foundry 포털(ai.azure.com)에서 프로젝트를 만들고, 모델을 배포하고, 플레이그라운드에서 대화해 본 뒤, 같은 배포를 코드에서 부르기까지입니다. 시험은 이 순서를 그대로 묻거나 「이 단계에서 무엇을 정하는가」를 묻습니다.

프로젝트와 리소스

두 층의 구조

Foundry에서 일하는 단위는 두 층입니다. 바깥이 Foundry 리소스로, Azure 구독 안에 만들어지는 실체이며 모델 배포·할당량·엔드포인트·키가 여기에 매입니다. 안쪽이 프로젝트로, 한 리소스 안에서 팀이나 과제별로 작업 공간을 가른 것입니다. 에이전트·평가·파일 같은 작업물은 프로젝트에 속하고, 프로젝트는 부모 리소스의 모델 배포를 함께 씁니다.

만드는 순서

1. Foundry 포털에 로그인하고 새 프로젝트 만들기를 고른다.
2. 프로젝트 이름을 적고, 고급 옵션에서 구독·리소스 그룹·지역과 Foundry 리소스 이름을 정한다(없으면 함께 만들어진다).
3. 만들기를 누르면 리소스와 프로젝트가 생기고 프로젝트 개요 화면이 열린다.

지역을 고르는 이 단계가 나중에 배포할 수 있는 모델을 좌우합니다. 모델마다 배포할 수 있는 지역이 다르므로, 쓸 모델이 정해져 있으면 그 모델이 서는 지역을 먼저 확인합니다.

모델 배포

카탈로그에서 배포까지

1. 프로젝트 왼쪽 메뉴에서 모델 카탈로그를 연다.
2. 모델을 골라 카드를 열고 배포를 누른다.
3. 배포 이름, 배포 유형, 할당량을 정하고 배포한다.
4. 배포가 끝나면 모델 및 엔드포인트 목록에 그 배포가 선다.

배포 이름과 할당량

배포 이름은 코드가 이 모델을 부를 때 쓰는 이름입니다. 모델의 공식 이름과 같을 필요가 없고, 같은 모델을 설정이 다른 배포 둘로 올려 support-bot과 summary-batch처럼 따로 부를 수도 있습니다. 시험에서 「코드의 model 인수에 무엇을 넣는가」의 답은 모델 이름이 아니라 이 배포 이름입니다.

할당량은 배포가 1분에 처리할 수 있는 토큰 수, 곧 TPM(분당 토큰)으로 정합니다. 구독과 지역마다 모델별 한도가 있어 그 안에서 배포마다 나눠 줍니다. 할당량을 넘는 요청은 HTTP 429(요청 과다)로 거절되므로, 시험의 「피크 시간에 429 오류가 난다」는 할당량을 늘리거나 배포 유형을 바꾸는 자리입니다.

배포 유형은 셋째 노트에서 고른 그것입니다. 포털의 배포 창에서 Global Standard·Standard·Provisioned 가운데 하나를 고르고, 유형에 따라 할당량을 TPM으로 정할지 미리 사 둔 처리 단위로 정할지가 갈립니다. 데이터가 특정 지역 밖에서 처리되면 안 된다는 요구가 있으면 Global 계열이 아닌 유형을 고르는 것도 이 창에서 합니다.

플레이그라운드에서 시험하기

채팅 플레이그라운드

배포가 서면 코드를 쓰기 전에 채팅 플레이그라운드에서 대화해 볼 수 있습니다. 배포를 골라 플레이그라운드에서 열기를 누르면 왼쪽에 설정 칸, 오른쪽에 대화 창이 섭니다. 여기서 temperature 같은 파라미터와 대화 기록에 넣을 이전 메시지 수를 바꿔 가며 답이 어떻게 달라지는지 봅니다.

시스템 메시지 설정

설정 칸의 모델 지침과 컨텍스트 자리가 앞 노트의 시스템 메시지입니다. 역할·형식·제약을 적고 적용하면 그다음 대화부터 반영됩니다. 마음에 드는 설정이 나오면 코드 보기를 눌러 같은 요청을 Python·C#·REST 같은 언어별 코드로 받아 갈 수 있는데, 이 코드에 시스템 메시지와 파라미터가 그대로 들어 있습니다. 플레이그라운드는 앱이 아니라 시험대라서, 여기서 정한 시스템 메시지가 배포에 저장되는 것은 아닙니다 — 앱 코드가 매 요청마다 보내야 합니다.

콘텐츠 필터

기본 필터

모든 배포에는 기본 콘텐츠 필터가 걸려 있습니다. 혐오·성적 내용·폭력·자해 네 범주를 입력과 출력 양쪽에서 검사하고, 범주마다 심각도가 일정 수준 이상이면 막습니다. 걸린 요청은 오류로 돌아오고, 출력이 걸리면 답이 중간에 끊긴 채 필터 사유가 표시됩니다.

사용자 지정 필터

포털의 안전 메뉴에서 새 필터를 만들어 범주마다 막는 문턱을 조이거나 풀 수 있고, 프롬프트 공격 탐지 같은 추가 검사를 켤 수도 있습니다. 만든 필터는 배포에 연결해야 효력이 생깁니다. 아동 대상 서비스처럼 더 엄격해야 하는 배포에는 문턱을 낮춘 필터를 붙이고, 다른 배포는 기본값을 쓰는 식으로 배포마다 다르게 둘 수 있습니다. 필터를 아예 끄거나 크게 푸는 것은 신청과 승인이 필요한 일입니다.

엔드포인트와 인증

키와 Entra ID

배포를 부르려면 주소와 신원이 필요합니다. 주소는 리소스의 엔드포인트이고, 신원을 밝히는 길이 둘입니다.

Microsoft Entra ID는 Azure의 신원 관리 서비스입니다. 이 길을 쓰려면 호출하는 사용자나 앱의 관리 ID에 모델을 부를 수 있는 역할(예: Cognitive Services OpenAI User)을 리소스 범위로 배정합니다. 시험에서 「키를 코드에 두지 않아야 한다」·「누가 불렀는지 감사해야 한다」가 보이면 Entra ID입니다.

코드에서 부르기

from azure.identity import DefaultAzureCredential, get_bearer_token_provider
from openai import AzureOpenAI

token_provider = get_bearer_token_provider(
    DefaultAzureCredential(), "https://cognitiveservices.azure.com/.default"
)
client = AzureOpenAI(
    azure_endpoint="https://<리소스 이름>.openai.azure.com/",
    azure_ad_token_provider=token_provider,
    api_version="2024-10-21",
)
response = client.chat.completions.create(
    model="support-bot",  # 모델 이름이 아니라 배포 이름
    messages=[
        {"role": "system", "content": "너는 예약 상담원이다. 세 문장 이내로 답한다."},
        {"role": "user", "content": "다음 주 제주 항공권 있나요?"},
    ],
)
print(response.choices[0].message.content)

키를 쓸 때는 azure_ad_token_provider 대신 api_key를 넘기고, REST로 부를 때는 api-key 헤더에 키를, Entra ID면 Authorization: Bearer <토큰> 헤더를 실습니다.

네 가지 도구의 대응

같은 일을 포털에서 누를 수도, REST·SDK·CLI로 할 수도 있습니다. 시험은 「포털의 이 단계는 CLI에서 무엇인가」를 짝지어 묻습니다.

배포와 키 같은 관리 작업은 Azure Resource Manager를 거치고, 대화 같은 추론 작업은 리소스 엔드포인트로 직접 갑니다. 이 둘을 가르면 표의 빈칸이 대부분 메워집니다 — CLI가 대화 요청 줄에서 빠지는 것도 CLI가 관리 도구이기 때문입니다.

연습 문제

1. 같은 GPT 모델을 고객 상담용과 야간 요약용으로 TPM을 다르게 나눠 쓰려 합니다. 가장 알맞은 방법은?
   ① 프로젝트를 둘 만든다
   ② 같은 모델로 배포 이름이 다른 배포 둘을 만들어 할당량을 나눈다
   ③ 시스템 메시지를 둘 쓴다
   ④ 콘텐츠 필터를 끈다

   ②. 할당량은 배포마다 정하므로 배포를 둘로 나누면 됩니다. 프로젝트를 나눈다고 할당량이 갈리지는 않습니다.
2. 앱 코드에서 model="gpt-4o"로 불렀더니 배포를 찾을 수 없다는 오류가 났습니다. 배포 이름은 chat-prod입니다. 고칠 것은?
   ① API 키를 다시 만든다
   ② model 인수에 chat-prod를 넣는다
   ③ temperature를 0으로 둔다
   ④ 지역을 바꾼다

   ②. 코드가 넘기는 것은 모델 이름이 아니라 배포 이름입니다.
3. 플레이그라운드에서 시스템 메시지를 정해 만족스러운 답을 얻었습니다. 그런데 앱에서 부르니 그 지시가 반영되지 않습니다. 이유로 가장 알맞은 것은?
   ① 플레이그라운드의 시스템 메시지는 배포에 저장되지 않아 앱이 직접 보내야 한다
   ② 콘텐츠 필터가 시스템 메시지를 지웠다
   ③ 할당량이 모자라다
   ④ Entra ID 인증을 썼기 때문이다

   ①. 플레이그라운드는 시험대라서 앱 코드가 매 요청에 시스템 메시지를 실어야 합니다.
4. 어린이용 학습 앱에 쓰는 배포만 폭력 범주를 더 엄격하게 막으려 합니다. 알맞은 것은?
   ① 모든 배포의 기본 필터를 지운다
   ② 문턱을 조인 사용자 지정 필터를 만들어 그 배포에 연결한다
   ③ max tokens를 줄인다
   ④ 배포 유형을 Provisioned로 바꾼다

   ②. 필터는 배포마다 연결하므로 그 배포에만 엄격한 필터를 붙입니다.
5. 운영 환경에서 키를 코드에 두지 않고, 누가 모델을 불렀는지 신원 단위로 관리해야 합니다. 알맞은 것은?
   ① API 키를 환경 변수에 넣는다
   ② 앱의 관리 ID에 역할을 배정하고 Entra ID 토큰으로 부른다
   ③ 키를 두 개 번갈아 쓴다
   ④ 플레이그라운드에서만 쓴다

   ②. Entra ID는 비밀을 코드에 두지 않고, 배정한 역할만큼만 권한을 줍니다.
6. 다음 중 Azure CLI로 하는 일이 아닌 것은?
   ① 모델 배포 만들기
   ② 리소스의 키 목록 보기
   ③ 배포에 채팅 요청을 보내 답 받기
   ④ Foundry 리소스 만들기

   ③. CLI는 관리 작업 도구라서 대화 같은 추론 요청은 REST나 SDK로 보냅니다.

여섯 문항이 「무엇이 어느 층에 매이는가」로 갈렸습니다. 할당량·필터는 배포, 작업물은 프로젝트, 키와 엔드포인트는 리소스, 시스템 메시지는 매 요청입니다.