모델과 Foundry

1.1 모델의 동작과 선택

세부 학습 목표

• LLM·SLM·멀티모달·전용 도구를 입력·품질·지연·비용 조건으로 비교한다.
• 토큰·문맥·출력 예산을 계산하고 벤치마크의 측정 대상과 업무 평가를 구별한다.

개요

• 토큰: 언어 모델이 입력과 출력을 처리하는 단위.
• 모델 선택: 지원 입력 → 요구 품질 → 메모리·응답 시간·비용 순으로 비교.
• 문맥 한도: 지침·대화·검색 자료·도구 결과와 출력 공간을 함께 계산.

입력과 출력 사이에서 일어나는 일

• 언어 모델은 텍스트를 토큰이라는 처리 단위로 바꾸고, 앞선 문맥에 이어질 출력을 생성합니다.

  토큰은 단어와 일대일로 대응하지 않습니다. 같은 길이의 한국어와 영어 문장도 토큰 수가 다를 수 있습니다. 비용과 입력 한도를 계산할 때 글자 수만으로 정확한 사용량을 확정할 수 없는 이유입니다.

• 학습으로 얻은 지식은 모델의 매개변수에 반영됩니다.

  추론은 그 모델에 현재 입력을 주고 결과를 얻는 과정입니다. 앱에서 질문 한 번을 보냈다고 모델의 매개변수가 새로 학습되는 것은 아닙니다. 대화를 이어서 기억하는 것처럼 보여도, 대화 상태나 이전 메시지를 다음 요청에 제공하는 방식일 수 있습니다.

• 자연스러운 답변도 사실과 다를 수 있습니다.

  예를 들어 변경된 사내 규정을 제공하지 않고 숙박비 상한을 물으면 과거 정보나 추정에 기대어 답할 수 있습니다. 날짜·금액·규정은 적용일이 확인된 원문이나 업무 시스템의 조회 결과와 대조해야 합니다. 관련 문서를 검색해 모델 입력에 넣는 방식을 검색 증강 생성(RAG)이라고 하며, 2장에서 문서 처리부터 답변 생성까지 연결합니다.

요구사항을 모델 선택 기준으로 바꾸기

• LLM(대규모 언어 모델)과 SLM(소형 언어 모델)은 상대적인 모델 규모를 나타냅니다.

  멀티모달은 텍스트 외에 이미지·음성 등 여러 종류의 입력이나 출력을 지원한다는 뜻입니다. 규모와 모달리티는 별도 기준이므로 작은 모델도 멀티모달일 수 있습니다.

• 작다는 사실만으로 모든 요청이 빠르거나 정확도가 충분하다고 보장되지는 않습니다.

  공개 벤치마크는 후보를 줄이는 자료로 사용하고, 최종 선택은 같은 업무 요청을 실제 실행 환경에서 처리한 결과로 결정합니다.

• 모델의 크기를 올리기 전에 실패 원인을 분리합니다.

  자료가 검색되지 않았다면 검색 흐름을, 인수가 잘못됐다면 도구 계약을, 정답 기준이 모호하다면 요구사항을 먼저 검토합니다. 이런 결함은 모델 교체만으로 해결되지 않을 수 있습니다.

벤치마크 이름과 측정 대상을 구분하기

스트리밍에서 첫 글자가 늦게 나타나는 문제와 답변 전체가 천천히 생성되는 문제는 비교할 지표가 다릅니다.

같은 입력·출력 길이와 동시 요청 조건에서 지표를 비교합니다. GTPS가 높은 후보라도 첫 토큰이 늦을 수 있으므로 첫 응답 대기를 줄이는 과제에서는 TTFT를 따로 확인합니다.

토큰 예산을 계산하는 작은 예제

다음 숫자는 계산 원리를 설명하기 위한 가상 값입니다. 특정 모델의 실제 한도나 가격이 아닙니다.

context_capacity = 16_000
instructions = 800
user_input = 200
retrieved_context = 10_000
reserved_output = 1_000
 
remaining = context_capacity - (
    instructions + user_input + retrieved_context + reserved_output
)
assert remaining == 4_000
print(remaining)

• 예산이 남아 있어도 필요한 자료가 잘렸다면 답변은 틀릴 수 있습니다.

  반대로 자료를 무조건 많이 넣으면 비용·지연이 늘고 핵심 근거를 찾기 어려워질 수 있습니다. 실제 요청에서는 SDK의 사용량, 도구 정의와 결과, 이미지·오디오 입력 및 모델별 추론/출력 토큰 규칙까지 확인합니다.

• 모델 간 비용과 지연을 비교할 때는 입력 문맥과 출력 길이 조건을 맞춥니다.

  필요한 근거를 빼서 비용만 낮추거나 출력 품질이 다른 결과의 응답 시간만 비교하면 업무에 적합한 모델을 고르기 어렵습니다.

업무 요구에서 모델 유형을 선택하기

• LLM과 SLM은 상대적인 모델 규모를, 멀티모달은 지원하는 입력·출력 종류를 나타냅니다.

  작은 언어 모델도 이미지나 음성을 처리할 수 있습니다. 따라서 먼저 필요한 모달리티를 정하고, 그 조건을 충족하는 후보의 품질·메모리·지연·비용을 비교합니다.

• 상황: 고객센터는 상품 코드 검색, 정책 요약, 제품 사진 해석을 자동화하려 합니다.

  세 업무는 입력 데이터와 검증 방식이 다릅니다.

• 적용: 상품 코드 조회는 정확 일치 검색이나 데이터베이스 조회가 후보입니다.

  정책 요약은 최신 문서를 제공한 텍스트 생성 모델로, 제품 사진 해석은 이미지 입력을 지원하는 모델이나 시각 처리 서비스로 비교합니다. 예를 들어 사진 해석이 필수라면 규모와 관계없이 텍스트 전용 모델은 제외합니다. 각 업무 안에서는 같은 평가 자료와 실행 환경을 사용하고, 작은 모델이 품질 기준을 충족하는지 확인한 뒤 비용과 지연을 비교합니다.

확인 문제

참고 자료

• Select, deploy, and evaluate Microsoft Foundry models 
• Get started with generative AI and agents in Azure 
• Compare models using the model leaderboard (preview) 
• 문장 품질과 사실 정확성의 구분 
• Select models using benchmarks 
• Evaluate model performance 

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

1.2 Foundry의 구성

세부 학습 목표

• Foundry 리소스·프로젝트·모델 배포·연결의 책임을 구별한다.
• 생성·검색·멀티모달·에이전트 요구를 적합한 서비스와 연결한다.

개요

• 리소스: 서비스 접근과 관리의 경계.
• 프로젝트: 앱·에이전트의 개발 작업과 연결을 조직하는 단위.
• 모델 배포: 실제 호출할 모델과 배포 이름·용량 등을 구성.

리소스·프로젝트·배포의 역할

• Azure에서 구독은 사용량과 과금을 묶고, 리소스 그룹은 관련 리소스를 관리하는 단위로 사용합니다.

  그 안에 Foundry·검색·저장소 등 필요한 리소스를 구성합니다. Foundry 리소스의 프로젝트에서는 앱과 에이전트가 사용하는 기능·연결을 조직합니다.

• 모델 배포는 사용할 모델을 앱이 호출할 수 있게 구성하는 작업입니다.

  모델 카탈로그에 표시된 제품명과 내가 정한 배포 이름은 구분합니다. 앱의 model 인수에 어떤 식별자를 넣는지는 사용하는 API와 호출 방식의 계약을 확인해야 합니다.

• 연결을 등록했다면 연결 대상이 실제로 존재하고, 앱의 인증 주체에 접근 권한이 있으며, 네트워크에서 도달 가능한지도 확인합니다.

  인증 주체는 호출하는 개발자 계정이나 앱의 관리 ID 등을 뜻합니다. 연결 이름만 등록해도 외부 리소스의 권한이 자동으로 부여되는 것은 아닙니다.

앱이 기능을 사용하는 관계

아래 그림은 앱에서 기능을 사용하는 논리적 연결 관계입니다. 실제 Azure 리소스의 부모·자식 구조나 모든 네트워크 경로를 그대로 표현한 배치도는 아닙니다.

• 일반 모델 호출만 필요한 앱과 프로젝트의 에이전트·평가 기능까지 사용하는 앱은 필요한 SDK가 다를 수 있습니다.

  Foundry 프로젝트 API, OpenAI 호환 모델 API, Speech·Language 같은 전용 서비스 API를 같은 주소라고 가정하지 않습니다.

첫 프로젝트 준비 순서

1. 앱의 입력과 출력을 적습니다. 예: “정책 문서를 찾아 한국어 답과 근거를 반환한다.”
2. 필요한 모델 입력·도구·검색·평가 기능을 고릅니다.
3. 구독·리소스 그룹·지역과 모델 사용 가능 여부를 확인합니다.
4. Foundry 리소스·프로젝트와 필요한 모델 배포를 준비합니다.
5. 최소 호출을 시험한 뒤 검색·도구·관측을 차례로 연결합니다.

• 프로젝트 엔드포인트와 모델 배포 이름, 호출할 계정의 권한을 준비했다면 1.3의 Python 예제로 첫 요청을 보낼 수 있습니다.

  존재하지 않는 배포, 권한 부족, 잘못된 검색 연결은 원인이 다르므로 실패한 단계의 오류를 기록하며 기능을 하나씩 연결합니다.

Foundry 서비스와 도구의 책임 구분

• 모델은 입력을 받아 출력을 생성합니다.

  검색 인덱스는 관련 문서의 후보를 찾고, 애플리케이션은 인증·도구 실행·결과 검증을 맡습니다. Foundry의 여러 기능을 하나의 제품처럼 혼동하면 책임과 오류 지점을 찾기 어렵습니다.

• 상황: 사내 규정 챗봇은 최신 규정을 검색하고 결재 조회 API를 호출해야 합니다.

  문서 검색과 외부 행동은 서로 다른 보안 경계를 가집니다.

• 적용: 검색은 자료 접근 권한으로 제한하고, 결재 API는 서버 측 권한 검사와 필요한 경우 사용자 승인을 통과해야 실행합니다.

  각 단계를 분리해 추적합니다. API의 성공 응답과 업무 기록을 확인하기 전에는 결재가 완료됐다고 표시하지 않습니다.

프로젝트·리소스·배포 개념 구분

• 프로젝트는 개발 작업과 연결을 조직화하는 논리적 단위입니다.

  실제 서비스 호출은 적절한 리소스·배포·엔드포인트·권한에 연결됩니다. 모델 카탈로그에서 모델을 조회하는 것과 배포된 모델을 호출하는 것은 다릅니다.

• 상황: 개발팀이 모델 카탈로그에서 모델을 찾았지만 호출 시 배포를 찾지 못한다는 오류가 발생했습니다.

• 적용: 모델 카탈로그 조회는 호출 가능한 배포를 뜻하지 않습니다.

  프로젝트·리소스의 실제 배포 목록과 상태, 배포명·엔드포인트를 확인하고 알맞은 호출 경로를 사용합니다.

확인 문제

model_deployment: chat-prod / inference_test=200
agent_definition: helper-v2 / tools=[get_order]
tool_connection: get_order / credential=unset
evaluation_dataset: support-v3 / run=not_started
출시 조건: 주문 조회 성공 + 평가 기준 통과

참고 자료

• Quickstart: Set up Microsoft Foundry resources 
• Microsoft Foundry capability reference 
• Microsoft Foundry SDKs and endpoints 

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

고객 지원 앱은 답변에 사내 문서 근거가 필요하고, 정해진 JSON 구조를 유지해야 합니다. 두 후보 모델의 데모 답변은 모두 자연스럽습니다.