과제별 Foundry 서비스와 모델 고르기

AI-103의 첫 도메인 「Azure AI 솔루션 계획·관리」는 시험 안내에 25~30%로 적힌 자리입니다. 코드를 한 줄도 쓰기 전에 무엇으로 만들 것인가를 정하는 도메인이라, 문항도 「이런 요구사항이면 어느 서비스를 쓰겠는가」 꼴로 나옵니다. 보기 넷이 모두 실제로 존재하는 Azure 서비스라서, 서비스 이름을 아는 것만으로는 안 갈리고 각 서비스가 무슨 문제를 푸는 자리인지 알아야 갈립니다. 이 노트는 그 지도를 그립니다.

Foundry라는 그릇 — 리소스, 프로젝트, 연결

Microsoft Foundry는 모델 카탈로그·에이전트·평가·안전 필터를 한 곳에서 다루는 Azure의 AI 개발 플랫폼입니다. 구조가 세 층이고, 시험은 이 층을 자주 섞어 묻습니다.

가장 자주 틀리는 자리가 할당량이 어디에 붙는가입니다. 할당량과 모델 배포는 리소스와 리전에 붙지 프로젝트에 붙지 않습니다. 그래서 한 리소스 아래 프로젝트를 셋 만들어도 그 셋은 같은 토큰 예산을 나눠 쓰고, 환경을 진짜로 가르려면 리소스부터 갈라야 합니다.

프로젝트에는 두 종류가 있습니다. Foundry 프로젝트는 리소스에 곧바로 붙는 가벼운 형태로 모델 배포와 에이전트를 다루는 데 쓰고, 허브 기반 프로젝트는 Machine Learning 워크스페이스를 밑에 깔아 컴퓨트·파인튜닝·프롬프트 플로까지 함께 씁니다. 「학습용 GPU 컴퓨트가 필요하다」·「기존 ML 워크스페이스 자산을 그대로 쓴다」가 나오면 허브 기반, 그 말이 없으면 Foundry 프로젝트입니다.

Foundry Tools — 예전 인지 서비스가 들어온 자리

Foundry Tools는 문서·이미지·음성·번역·안전처럼 모델 앞뒤에서 도와주는 기능들을 한 이름으로 묶은 것입니다. 예전에 서비스마다 리소스를 따로 만들던 것들이 여기로 들어왔습니다.

워크플로가 서비스를 정한다

시나리오 문항은 결국 아래 표의 왼쪽 열을 문장으로 풀어 쓴 것입니다.

여기서 갈리는 짝이 둘 있습니다. 검색이냐 추출이냐 — 많은 문서 중에서 관련된 것을 골라 오는 일이면 Search, 문서 한 건 안에서 필드를 뽑는 일이면 Content Understanding입니다. 그리고 RAG냐 에이전트냐 — 한 번 찾아 한 번 답하면 RAG로 충분하고, 도구를 몇 번 부를지 모델이 정해야 하면 에이전트입니다.

LLM인가 SLM인가

소형 언어 모델(SLM)은 파라미터 수를 크게 줄여 지연과 비용을 낮춘 모델입니다. 시험은 이 선택을 요구사항 문장에 심어 둡니다.

「단말에서 오프라인으로 돌아야 한다」·「응답이 수백 밀리초 안이어야 한다」·「분류 결과만 필요하다」는 SLM 쪽 신호입니다. 반대로 「여러 문서를 견줘 판단한다」·「도구를 골라 순서를 정한다」는 LLM 쪽입니다. 둘을 한 솔루션에 함께 두는 답도 자주 정답이 됩니다 — 앞단에서 SLM이 분류하고 어려운 것만 LLM으로 올리는 구성입니다.

멀티모달 모델은 이미지나 오디오를 텍스트와 함께 입력으로 받는 모델이고, 코드 모델은 코드 생성·설명·변환에 맞춰진 모델입니다. 이미지 한 장을 설명하게 하는 일은 멀티모달 모델이 맡지만, 이미지에서 표와 필드를 정확히 뽑아 오는 일은 Content Understanding 쪽이 정답인 경우가 많습니다.

카탈로그에서 고를 때 재는 세 축

모델 카탈로그는 같은 일을 하는 모델을 여럿 보여 주므로, 고르는 기준을 비용·지연·품질 세 축으로 잡습니다. 배포 이름만 바꾸면 호출 코드는 그대로이므로 두 모델을 나란히 재 보는 것이 정석입니다.

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

project = AIProjectClient(
    endpoint="https://my-foundry.services.ai.azure.com/api/projects/support",
    credential=DefaultAzureCredential(),
)
client = project.get_openai_client()

for deployment in ("gpt-4o-chat", "phi-4-mini-chat"):
    reply = client.chat.completions.create(
        model=deployment,                    # 모델 이름이 아니라 '배포 이름'이다
        messages=[{"role": "user", "content": "반품 규정을 한 문장으로 요약해 줘."}],
    )
    print(deployment, reply.usage.total_tokens, reply.choices[0].message.content)

세 축 중 품질이 가장 다루기 까다롭습니다. 카탈로그에 붙은 벤치마크 점수는 일반적인 과제에서 잰 값이라 우리 프롬프트와 우리 문서에서도 같은 순서가 나온다는 보장이 없기 때문입니다. 그래서 실제 요청 표본을 몇십 건 모아 두 배포에 같은 입력을 넣고 재는 절차가 카탈로그 순위보다 앞섭니다 — 평가자를 붙여 이 판단을 자동으로 내리는 방법은 뒤쪽 「환각·관련성·품질·안전 평가하기」에서 다룹니다. 지연도 마찬가지로 두 가지를 갈라 재야 합니다. 첫 토큰이 나오기까지의 시간과 응답이 끝나기까지의 시간이 다르고, 스트리밍으로 받으면 뒤엣것이 같아도 사용자가 느끼는 기다림은 앞엣것으로 줄어듭니다.

비용은 배포한 모델이 아니라 흘러가는 토큰이 정합니다. 하루 5만 건을 처리하는데 요청마다 입력 1,500 토큰과 출력 500 토큰이 든다면 하루에 입력 7,500만·출력 2,500만 토큰입니다. 출력 단가가 입력의 네 배인 모델이라면 출력이 전체 비용의 절반을 넘습니다 — 프롬프트를 줄이는 것보다 응답 길이를 제한하는 쪽이 더 크게 듣는다는 뜻이고, 이 계산을 시켜 보기 넷 중 가장 싼 구성을 고르게 하는 문항이 나옵니다.

연습 문제

1. 한 팀이 프로젝트 셋을 만들어 개발·스테이징·운영 환경을 갈랐는데, 개발 팀의 부하 시험이 돌면 운영 앱이 429 오류를 받습니다. 원인으로 가장 알맞은 것은?
   ① 프로젝트마다 엔드포인트가 달라서
   ② 할당량이 프로젝트가 아니라 리소스와 리전에 붙어 셋이 같은 토큰 예산을 나눠 쓰므로
   ③ 연결(connection)을 프로젝트마다 만들지 않아서
   ④ 허브 기반 프로젝트를 써서

   ②. 할당량과 모델 배포는 리소스·리전 단위입니다. 환경을 진짜로 가르려면 리소스를 갈라야 합니다.
2. 「보험 청구서 PDF 한 건에서 사고 일자·청구 금액·차량 번호를 뽑아 JSON으로 넘겨야 한다」는 요구에 가장 알맞은 것은?
   ① Azure AI Search 인덱서
   ② Content Understanding 분석기
   ③ 임베딩 모델과 벡터 필드
   ④ Translator 문서 번역

   ②. 문서 한 건 안에서 필드를 뽑는 일이라 추출 쪽입니다. ①과 ③은 많은 문서 중에서 관련된 것을 골라 오는 자리입니다.
3. 다음 중 SLM을 고를 근거로 보기 어려운 것은?
   ① 인터넷이 끊긴 공장 단말에서 돌아야 한다
   ② 응답이 짧을수록 좋고 출력 형식이 고정되어 있다
   ③ 요청량이 많아 요청당 단가를 낮춰야 한다
   ④ 서로 다른 부서 문서 열 건을 견줘 상충하는 내용을 찾아야 한다

   ④. 여러 문서를 견줘 판단하는 일은 긴 맥락과 추론이 필요하므로 LLM 쪽입니다. ①~③은 전부 SLM 신호입니다.
4. Foundry 프로젝트와 허브 기반 프로젝트를 견준 것으로 옳은 것은?
   ① 허브 기반은 모델 배포를 할 수 없다
   ② Foundry 프로젝트는 Machine Learning 워크스페이스를 밑에 깔고 컴퓨트를 관리한다
   ③ 파인튜닝용 컴퓨트와 프롬프트 플로 자산이 필요하면 허브 기반을 고른다
   ④ 연결(connection)은 허브 기반에만 있다

   ③. ②는 허브 기반의 설명이고, ①·④는 사실이 아닙니다.
5. 위 파이썬 조각에서 model="gpt-4o-chat"의 값은 무엇을 가리킵니까?
   ① 모델 카탈로그에 있는 모델의 공식 이름
   ② 리소스에 만든 배포(deployment)의 이름
   ③ 프로젝트 이름
   ④ 모델 버전 문자열

   ②. 호출할 때 넘기는 것은 배포 이름입니다. 같은 모델을 이름이 다른 배포 둘로 올려 두고 코드에서 골라 부를 수 있는 이유가 이것입니다.
6. 요청마다 입력 1,000 토큰·출력 400 토큰이 들고, 가정한 단가가 입력 100만 토큰당 2달러, 출력 100만 토큰당 8달러입니다. 하루 10만 건을 처리하면 하루 비용은 얼마이고 입력과 출력 중 어느 쪽이 더 큽니까?
   ① 200달러, 입력이 더 크다
   ② 320달러, 출력이 더 크다
   ③ 520달러, 출력이 더 크다
   ④ 520달러, 입력이 더 크다

   ③. 입력은 $1{,}000 \times 100{,}000 = 10^8$ 토큰이므로 $100 \times 2 = 200$ 달러, 출력은 $400 \times 100{,}000 = 4 \times 10^7$ 토큰이므로 $40 \times 8 = 320$ 달러입니다. 합이 520달러이고, 토큰 수는 입력이 2.5배인데 비용은 출력이 더 큽니다 — 단가 차이 네 배가 개수 차이를 뒤집기 때문입니다.

마지막 문항이 보여 주는 것이 이 도메인의 성격입니다. 서비스를 고르는 문항은 이름을 외워 푸는 것이 아니라 요구사항 문장에서 제약이 어디에 걸려 있는지를 읽어 푸는 것입니다. 지연이 걸려 있으면 모델 크기와 배포 위치, 비용이 걸려 있으면 토큰 흐름, 근거가 걸려 있으면 검색과 인덱스로 시선을 옮기면 보기 넷 중 둘은 곧바로 떨어져 나갑니다.