[Azure OpenAI #5] Azure OpenAI Service 전체 구조 이해하기: 리소스, 모델, 배포, Endpoint
클라우드 기반 생성 AI 모델 사용을 위한 인프라 구조와 필수 용어 완벽 정리
들어가며
이전 글에서는 LLM이 텍스트를 어떻게 처리하고, Transformer와 GPT가 어떤 구조로 동작하는지 정리했다.
이번 글부터는 이론에서 한 단계 넘어가서, 실제로 Azure 환경에서 OpenAI 모델을 사용하는 구조를 정리해보려고 한다. 처음 Azure OpenAI를 보면 헷갈리는 단어가 많다.
Resource Group, Azure OpenAI Resource, Azure AI Foundry, Model, Deployment, Endpoint, API Key, Region, Pricing, PTU, Pay-as-you-go 등 이 단어들이 따로따로 보이면 어렵지만, 사실 전체 흐름은 단순하다.
→ 사용할 모델을 고른다
→ 그 모델을 내 리소스에 배포한다
→ Endpoint와 API Key로 애플리케이션에서 호출한다
이 글에서는 실제 클릭 순서보다는, Azure OpenAI를 사용하기 위해 반드시 알아야 하는 개념 구조를 먼저 정리한다.
1. Azure OpenAI Service란?
Azure OpenAI Service는 Microsoft Azure 환경에서 OpenAI 계열의 생성 AI 모델을 사용할 수 있게 해주는 서비스다.
일반적으로 ChatGPT를 사용할 때는 웹 화면에서 질문을 입력하고 답변을 받는다. 하지만 서비스를 개발하려면 모델을 코드에서 호출할 수 있어야 한다. Azure OpenAI Service는 이런 방식으로 사용할 수 있다.
즉, Azure OpenAI Service는 단순히 “챗봇 화면”이 아니라, 생성 AI 모델을 내 서비스나 업무 시스템에 연결하기 위한 클라우드 기반 AI 서비스라고 볼 수 있다.
2. OpenAI API와 Azure OpenAI의 차이
OpenAI API와 Azure OpenAI는 모두 생성 AI 모델을 API로 사용할 수 있다는 점은 비슷하다. 하지만 운영 구조가 다르다.
| 구분 | OpenAI API | Azure OpenAI |
|---|---|---|
| 사용 환경 | OpenAI 플랫폼 | Microsoft Azure |
| 관리 단위 | API Key, Project 중심 | Subscription, Resource Group, Resource 중심 |
| 모델 호출 | 모델 이름 중심 | 배포 이름 중심 |
| 기업 환경 | OpenAI 플랫폼 설정 중심 | Azure 보안, 네트워크, 권한, 모니터링과 통합 |
| 과금 | OpenAI 계정 기준 | Azure 구독 기준 |
| 지역 선택 | OpenAI 제공 환경 기준 | Azure Region 선택 필요 |
OpenAI API는 모델을 바로 호출하는 느낌에 가깝고, Azure OpenAI는 Azure 리소스 안에 모델을 배포한 뒤 호출한다. 그래서 Azure OpenAI에서는 모델명과 배포명을 철저히 구분해야 한다.
3. 전체 구조 한눈에 보기
Azure OpenAI의 인프라 계층 구조는 다음과 같다.
Azure Subscription
└── Resource Group
└── Azure OpenAI Resource
├── Region
├── Model Deployments
│ ├── deployment-name-1 → gpt-4o-mini
│ └── deployment-name-2 → embedding model
├── Endpoint
└── API Keys애플리케이션 개발 단계에서 연동할 때 필수적으로 요구되는 4가지 정보는 다음과 같다.
- Endpoint: 요청을 보낼 주소
- API Key: 인증 출입증
- Deployment Name: 내가 설정한 배포명
- API Version: 호출할 API 버전
4. Resource Group이란?
Resource Group은 Azure에서 관련 리소스들을 묶어서 관리하는 단위다.
예를 들어 챗봇 서비스를 만든다고 하면 Azure OpenAI Resource, Azure AI Search, Storage Account 등이 함께 필요할 수 있다. 이를 하나의 그룹으로 묶으면 이점이 많다.
- 관리 편의성: 프로젝트별로 리소스를 묶어서 일괄 확인 가능
- 비용 관리: 특정 그룹에서 발생한 비용만 추적하기 용이
- 삭제 편의성: 실습이나 PoC가 끝났을 때 그룹 통째로 삭제하면 잔여 자원 없이 정리 가능
5. Azure OpenAI Resource란?
Azure OpenAI Resource는 Azure에서 OpenAI 모델을 사용하기 위한 실제 서비스 인스턴스, 즉 사용 공간이다.
Azure OpenAI Resource = 폴더 내부의 실제 생성 AI 모델 사용 공간
이 리소스를 생성하면 고유의 Endpoint와 API Key를 얻고, Azure AI Foundry 플랫폼으로 진입할 수 있게 된다.
6. Model과 Deployment의 차이
Azure OpenAI에서 가장 혼동하기 쉬운 개념 구조다.
🎯 Model
Model은 기술 회사가 제공하는 AI 엔진 알고리즘 자체를 의미한다.
예를 들어 gpt-4o-mini, gpt-4o, o-series, DALL-E 등이 모델에 해당한다.
🚀 Deployment
Deployment는 선택한 베이스 모델을 내 리소스 안에서 실제 호출 가능한 상태로 활성화한 단위다.
예를 들어 gpt-4o-mini 엔진을 선택하고 배포명을 my-chat-model로 지정할 수 있다. 코드에서는 베이스 모델명이 아닌 이 배포명을 지정해 요청해야 정상 작동한다.
7. 왜 모델을 바로 쓰지 않고 배포해야 할까?
배포 단계에서 엔진 선택뿐만 아니라 운영 체계의 핵심 스펙이 정의되기 때문이다.
- 어떤 베이스 모델 버전을 쓸 것인가?
- 외부 애플리케이션에서 호출할 고유 이름은 무엇으로 할 것인가?
- 분당 트래픽 허용량은 얼마나 할당할 것인가?
- 어떤 과금 체계를 결합할 것인가?
8. Endpoint와 API Key
- Endpoint: API 요청을 전달할 물리적 주소, 즉 리소스의 대문 주소
- API Key: 해당 주소로 통신할 때 권한을 인증하는 토큰, 즉 출입증
코드 연결 시 Endpoint + API Key + Deployment Name 세 가지 정보가 필수 조합을 이룬다.
9. API Key 보안 관리
보안 사고를 예방하기 위해 API Key는 절대로 소스코드 내에 하드코딩해서는 안 된다. GitHub과 같은 오픈 소스 저장소에 유출될 경우 심각한 비용 청구 및 권한 남용 문제가 발생할 수 있다.
| 관리 방법 | 권장 여부 | 특징 및 설명 |
|---|---|---|
| 코드 직접 작성 | 비권장 | Git 저장소 업로드 시 유출 위험 매우 높음 |
| .env 파일 활용 | 개발 권장 | 로컬 개발 시 소스코드와 비밀값 분리 가능 |
| 시스템 환경 변수 | 운영 권장 | 서버 및 컨테이너 배포 환경에서 유용 |
| Azure Key Vault | 실무 강력 권장 | 암호화된 클라우드 전용 인프라에서 중앙 집중 제어 |
API Key를 코드에 직접 넣은 상태로 GitHub에 업로드하면 키가 외부에 노출될 수 있다. 실습 단계에서는
.env 파일을 사용하고, 운영 환경에서는 환경 변수나 Azure Key Vault 사용을 고려하는 것이 좋다.10. Region이 중요한 이유
Region은 리소스가 물리적으로 구축되는 Azure 데이터센터의 지리적 위치다. 예를 들어 Korea Central, East US 등이 있다.
- 모델 제공 여부: 최신 모델이나 특정 스펙 버전은 특정 리전에 먼저 출시될 수 있음
- 지연 시간: 엔드유저와 물리적으로 가까운 리전일수록 네트워크 지연 감소
- 데이터 거버넌스: 국가 및 산업 규제에 따른 데이터 역외 반출 제한 조항 충족 가능
- 할당량: 리전 및 구독 성격에 따라 확보 가능한 인프라 용량이 다를 수 있음
11. Access 및 보안 승인 절차
Azure OpenAI Service는 무분별한 AI 오남용을 막기 위해 책임 있는 AI 정책을 적용한다.
이에 따라 기업용 구독 승인이나 별도의 신청 절차가 선행되어야 정상 생성이 가능할 수 있다.
12. 트래픽 제어 시스템: Quota, TPM, RPM
- Quota: 내 전체 구독 환경에서 해당 모델 제품군에 최대로 부여받은 파이프 용량
- TPM: Tokens Per Minute. 1분 동안 처리할 수 있는 최대 토큰 개수
- RPM: Requests Per Minute. 1분 동안 허용되는 API 호출 횟수
긴 문서 기반 처리에서는 TPM 한계에 걸리기 쉽고, 짧은 요청을 빠르게 반복하는 서비스에서는 RPM 한계에 걸리기 쉽다.
13. 과금 방식 비교
| 구분 | Pay-as-you-go | PTU |
|---|---|---|
| 정의 | 실제 입출력에 사용한 토큰 양만큼 정산 | 일정 처리량 대역폭을 예약하여 고정 비용 지출 |
| 적합한 상황 | 개인 학습, 개발 초기, PoC 검증, 변동 트래픽 | 엔터프라이즈 프로덕션, 상시 일정한 대규모 트래픽 |
| 장점 | 초기 고정 비용 제로, 안 쓰면 돈 안 나옴 | 트래픽 간섭 없는 성능 보장, 비용 예측 용이 |
| 단점 | 트래픽 폭발 시 비용 급증, 공유 인프라 속도 저하 가능성 | 사용량이 없어도 예약 기간 내 고정 비용 발생 |
14. 생성 AI 서비스 비용 절감 전략
- 작은 모델 우선순위 배치: 복잡한 추론이 아닌 분류, 요약 등은 고성능 엔진 대신
mini제품군을 먼저 고려한다. - Max Tokens 제한 설정: 답변이 불필요하게 길어지는 현상을 API 속성 레벨에서 제한한다.
- 컨텍스트 다이어트: 대화 히스토리 누적 시 불필요한 시스템 프롬프트와 이전 대화 내용을 압축한다.
- 정밀한 RAG 청킹: Vector DB 검색 시 연관도가 높은 데이터 조각만 LLM의 컨텍스트에 넣는다.
- Azure 예산 임계치 경보: Cost Management 메뉴에서 특정 비용 돌파 시 담당자에게 알림이 가도록 설정한다.
15. 실무 아키텍처 수립 시 필수 유의점
- API Key가 코드 형상 관리 툴에 노출되지 않았는가?
- 애플리케이션 코드에서 Model 원본명 대신 내가 정한 Deployment Name을 사용했는가?
- 글로벌 서비스를 기획할 때 선정한 리전이 요구 모델의 특정 버전을 제공하는가?
- 동시 접속자 폭증 시나리오에 대비한 TPM 단위 분배를 마쳤는가?
16. 전체 파이프라인 프로세스 핵심 요약
- Azure Portal 로그인 및 세션 구동
- 연관 자원을 묶어낼 Resource Group 생성
- 전용 서비스 공급 공간인 Azure OpenAI Resource 프로비저닝
- AI 실험실인 Azure AI Foundry 콘솔 포털로 이동
- 비즈니스 목적에 맞는 베이스 Model 선택
- 특정 스펙 명칭을 부여하여 가동 가능한 상태의 Deployment 인스턴스 배포
- 발급된 고유 Endpoint와 API Key 확인 및 보안 변수 바인딩
- UI Playground에서 유효성 테스트 검증
- 공식 API 또는 SDK를 결합하여 내 애플리케이션 서비스 개발 연동 완료
Azure OpenAI 체계는 엔진을 바로 갖다 쓰는 구조가 아니라, 할당받은 리소스 컨테이너 안에 타깃 모델을 특정 권한·용량 스펙으로 배포한 뒤 Endpoint, API Key, Deployment Name을 조합해 통신하는 구조다.
17. 핵심 용어 정리 요약표
| 개념 명칭 | 정의 및 역할 | 가장 쉬운 비유 |
|---|---|---|
| Azure Portal | 전체 인프라 인스턴스를 제어하는 중앙 웹 관리 대시보드 | 종합 관리실 |
| Resource Group | 연관 자원들을 묶어 통합 생명주기를 부여하는 단위 | 프로젝트 폴더 |
| Azure OpenAI Resource | AI 모델을 사용할 수 있도록 할당된 전용 인프라 영역 | AI 사용 전용 공간 |
| Azure AI Foundry | 모델 배포, 프롬프트 실험, 오케스트레이션을 다루는 플랫폼 | AI 개발 전문 가공실 |
| Model | 사전 학습된 생성형 인공지능 가중치 원형 제품 | AI 순정 엔진 원형 |
| Deployment | 베이스 모델에 고유 이름과 용량을 지정해 활성화한 구동 단위 | 주문 제작형 커스텀 엔진 |
| Endpoint | 인터넷 도메인 상에서 해당 인스턴스에 접근할 수 있는 주소 | 물리적 건물 주소 |
| API Key | 인가된 사용자 또는 소프트웨어임을 증명하는 비밀 토큰 | 출입 게이트 보안 키 |
| Region | 클라우드 리소스 서버 장비가 위치한 데이터센터 지역 | 물리 데이터센터 위치 |
| Quota / TPM / RPM | 분당 가용 가능한 호출 속도 및 토큰 소모량 제한 | 속도 및 트래픽 제한 |
| Pay-as-you-go | 입출력 토큰 개수 단위로 후불 산정하는 방식 | 데이터 요금 종량제 |
| PTU | 처리량 대역폭을 전용으로 예약하는 과금 구조 | 지정 전용선 정기 구독제 |
마무리
이번 글에서는 Azure OpenAI Service를 사용하기 전에 알아야 할 전체 아키텍처 구조를 정리했다.
핵심은 단순하다. Azure OpenAI에서는 모델을 바로 호출하는 것이 아니라, Azure 리소스 안에 모델을 배포한 뒤 그 배포를 Endpoint, API Key, Deployment Name으로 호출한다.
다음 글에서는 이 개념 지식을 바탕으로 실제 Azure Portal 웹 화면에서 리소스를 만들고, Azure AI Foundry에서 모델을 배포한 뒤 Playground 및 Python SDK로 직접 호출하는 실습 과정을 정리해보겠다.
