솔직히 고백하자면, 나도 처음에는 Azure에서 AI 시스템을 설계한다고 했을 때 막막했다. Portal에 로그인하면 수백 개의 서비스가 펼쳐지고, 어디서부터 손대야 할지 감이 안 왔다. OpenAI API를 직접 호출하면 되는 걸 왜 굳이 Azure를 끼고 복잡하게 만들어야 하지? 그때는 진심으로 그렇게 생각했다.
그런데 실제로 기업 환경에서 AI 서비스를 운영하면서 생각이 완전히 바뀌었다. API Key 하나 유출되면 수천만 원짜리 청구서가 날아오고, 사용자 데이터가 외부로 나가면 컴플라이언스 이슈가 터진다. 트래픽이 갑자기 몰리면 서비스가 먹통이 되고, 모델 버전이 바뀌면서 어제까지 잘 되던 답변 품질이 갑자기 떨어지기도 한다. 이런 문제들을 개별적으로 해결하려면 끝이 없다. 결국 검증된 클라우드 플랫폼 위에 설계된 아키텍처가 필요하다.
이 글은 내가 Azure 위에서 엔터프라이즈 AI 시스템을 설계하고 운영하면서 겪은 경험을 바탕으로 정리한 것이다. 이론서가 아니라 실전 가이드다. 각 계층별로 어떤 서비스를 선택해야 하고, 왜 그 선택이 맞는지, 그리고 실제로 어떻게 연결하는지까지 다룬다. 이 한 편의 글이 Azure AI 아키텍처의 전체 그림을 잡는 데 도움이 되었으면 한다.
왜 Azure 기반 AI 아키텍처인가
이 질문에 답하려면 먼저 OpenAI API를 직접 쓰는 것과 Azure OpenAI를 쓰는 것의 차이를 명확히 이해해야 한다. 단순히 “마이크로소프트 거니까”라는 이유로는 설명이 안 된다.
직접 OpenAI API를 호출하면 모델 버전이 예고 없이 바뀌는 경우가 생긴다. 어느 날 갑자기 GPT-4의 응답 스타일이 미묘하게 달라져서, 프로덕션에서 돌아가던 프롬프트가 엉뚱한 결과를 내놓기 시작한다. Rate Limit에 걸려도 대응할 수 있는 방법이 제한적이고, 데이터가 어디 서버에서 처리되는지도 명확하지 않다.
반면 Azure OpenAI는 내가 선택한 모델 버전이 내 리소스에 고정 배포된다. 프로덕션 환경에서 돌아가는 모델을 내가 직접 관리하고, 업데이트 시점도 내가 결정한다. Private Endpoint로 트래픽을 내부 네트워크에 가둘 수 있고, Azure의 전체 보안 체계와 통합된다. 여기에 2026년 1월부터 도입된 v1 API는 매달 API 버전을 업데이트할 필요 없이 표준화된 인터페이스를 제공해서 개발 편의성도 크게 나아졌다.
2026년 현재 Fortune 500 기업의 80% 이상이 Azure AI Foundry를 도입한 데에는 이유가 있다. 단순한 API 호출이 아니라 거버넌스, 보안, 확장성이 동시에 필요하기 때문이다. 그리고 AI Foundry가 제공하는 11,000개 이상의 모델 에코시스템은 OpenAI 모델뿐 아니라 Anthropic Claude, Cohere, 오픈소스 모델까지 하나의 플랫폼에서 관리할 수 있게 해준다. Azure OpenAI vs 직접 OpenAI API, 기업이 Azure를 선택해야 하는 5가지 이유에서 이 비교를 더 깊이 다뤘으니 참고하면 좋겠다.
Azure의 진짜 강점은 AI 서비스 하나가 아니라 전체 생태계가 유기적으로 연결된다는 점이다. 인증은 Entra ID로, 데이터는 Blob Storage로, 검색은 AI Search로, 배포는 Container Apps나 AKS로. 이 조각들을 어떻게 맞추느냐가 아키텍처 설계의 핵심이다. 그리고 이 글에서 그 퍼즐을 하나씩 맞춰볼 것이다.
인증과 보안 설계, 아키텍처의 첫 번째 기둥
아키텍처 설계를 할 때 대부분의 개발자가 기능 구현부터 시작한다. 모델 연결하고, API 만들고, 프론트엔드 붙이고. 보안은 나중에 생각하겠지 하면서. 나도 그랬다. 그리고 나중에 호되게 당했다.
프로토타입에서 잘 돌아가던 시스템을 프로덕션에 올리려는 순간, 보안팀에서 퇴짜를 놓는다. “API Key가 환경변수에 하드코딩되어 있는데요?” “이 서비스가 외부 인터넷을 통해서 OpenAI에 직접 요청을 보내고 있는 게 맞나요?” “사용자 데이터가 어디 서버에서 처리되는지 보장이 안 되는데요?” 이런 질문 앞에서 개발자는 아무 말도 못 한다. 보안은 나중에 덧붙이는 레이어가 아니다. 아키텍처의 첫 번째 기둥이다.
2026년 Microsoft가 보안 전담 부사장직을 신설하고 Zero Trust 아키텍처를 AI 워크로드에까지 확대 적용하고 있는 것도 같은 맥락이다. AI가 더 이상 실험이 아니라 기업의 핵심 인프라로 자리 잡았기 때문에, 보안의 수준도 그에 맞게 올라가야 한다.
가장 먼저 해야 할 일은 API Key를 코드에서 완전히 제거하는 것이다. 농담이 아니다. 아직도 .env 파일에 OpenAI Key를 넣어두고 쓰는 프로젝트가 놀라울 정도로 많다. 깃허브에 실수로 푸시해서 키가 유출되는 사고도 여전히 빈번하다. Azure에서는 Managed Identity를 쓰면 API Key 없이도 Azure 서비스 간 인증이 가능하다. VM이든 Container Apps이든 Functions이든 시스템이 알아서 토큰을 발급하고 갱신한다. 개발자가 키를 만질 일 자체가 없어지니까 유출 위험도 원천 차단된다.
구현 방식은 생각보다 간단하다. DefaultAzureCredential 하나면 로컬 개발 환경에서는 Azure CLI 인증을, 프로덕션에서는 Managed Identity를 자동으로 사용한다. 코드 한 줄 바꾸지 않고 환경에 따라 인증 방식이 전환되는 것이다. 실제 구현 코드와 설정 방법은 Azure Managed Identity로 AI 서비스 연결하기, API Key 없이 안전하게 인증하는 방법에서 코드 레벨까지 설명했다.
그 다음은 Microsoft Entra ID를 통한 접근 제어다. 누가 어떤 AI 리소스에 접근할 수 있는지 RBAC(역할 기반 접근 제어)로 세밀하게 관리해야 한다. 예를 들어 개발팀은 모델 배포와 테스트만 가능하고, 운영팀은 모니터링과 로그 조회만 가능하고, 데이터팀은 학습 데이터 업로드만 가능하게 만드는 식이다. 이렇게 역할별로 권한을 분리하면 한 사람의 계정이 탈취되더라도 피해 범위를 최소화할 수 있다. Microsoft Entra ID 2026년 완벽 가이드에서 기업이 꼭 알아야 할 클라우드 계정 관리의 전체 그림을 설명했다.
한 가지 더 짚고 넘어갈 게 있다. Azure를 처음 접하는 개발자들이 App Registration과 App Service를 혼동하는 경우가 정말 많다. 이름이 비슷하니까 당연하다. 하지만 이 둘은 완전히 다른 개념이다. App Registration은 Entra ID에서 애플리케이션의 신원을 등록하는 것이고, App Service는 웹앱을 호스팅하는 컴퓨팅 서비스다. 인증 아키텍처를 설계하려면 이 구분이 명확해야 하는데, 섞어서 이해하면 나중에 토큰 발급 흐름을 잡을 때 꼬인다. Azure App Registration과 App Service 완벽히 구분하기에서 이 차이를 실제 사례와 함께 정리했다.
AI 모델 배포 전략, 상황에 따라 달라지는 선택지
모델 배포는 크게 두 가지 경로로 나뉜다. Azure에서 제공하는 매니지드 서비스를 쓰거나, 직접 GPU 인스턴스를 잡아서 오픈소스 모델을 올리거나.
첫 번째 경로는 Azure AI Foundry를 통해 GPT 계열이나 Phi 같은 모델을 배포하는 것이다. Portal에서 몇 번 클릭하면 모델이 배포되고 API 엔드포인트가 나온다. 복잡한 인프라를 직접 관리할 필요가 없다. 모델 버전 관리, 컨텐츠 필터링, 사용량 모니터링까지 플랫폼에서 처리해준다. 대신 모델 선택의 폭이 제한되고, 파인튜닝의 자유도가 떨어질 수 있다. AI Foundry가 처음이라면 Azure AI Foundry 입문 가이드, GPT-5 모델 배포부터 API 호출까지부터 시작하는 걸 추천한다.
두 번째 경로는 vLLM 같은 고성능 추론 엔진을 Azure VM에 직접 올리는 것이다. Llama, Mistral, Qwen 같은 오픈소스 모델을 돌리려면 이 방법을 써야 한다. 이 경로를 택하면 모델 선택의 자유도가 훨씬 높아지고, 특정 도메인에 맞게 파인튜닝한 모델도 서빙할 수 있다. 데이터가 절대 외부로 나가면 안 되는 환경에서도 유리하다.
GPU 인스턴스 선택이 관건인데, 내 경험상 Standard_NC24ads_A100_v4가 가성비와 성능 면에서 가장 무난한 선택이다. A100 80GB 하나로 7B에서 13B 파라미터 모델은 물론, 양자화를 적용하면 70B급 모델도 돌릴 수 있다. vLLM의 PagedAttention 메커니즘이 GPU 메모리를 마치 운영체제의 가상 메모리처럼 효율적으로 관리해주기 때문에, 같은 하드웨어에서 HuggingFace Transformers 대비 최대 24배 높은 처리량을 뽑아낼 수 있다.
여기서 중요한 팁 하나. vLLM을 배포할 때 tensor-parallel-size 옵션을 잘 활용해야 한다. 단일 GPU에서는 필요 없지만, 멀티 GPU 환경에서는 이 옵션으로 모델을 여러 GPU에 분산시켜야 대형 모델을 올릴 수 있다. 이런 실전 노하우를 포함한 전체 배포 과정은 Azure VM에 vLLM 배포하기, GPU 인스턴스 선택부터 모델 서빙까지에 정리해뒀다.
실무에서는 두 경로를 동시에 운영하는 하이브리드 전략이 흔하다. 범용 질의응답과 요약 같은 범용 태스크는 Azure OpenAI의 GPT 모델로 처리하고, 사내 용어가 많은 도메인 특화 작업이나 한국어 특화 추론은 vLLM으로 올린 자체 모델에서 처리하는 식이다. 이때 Azure API Management나 자체 구축한 API Gateway를 앞에 두고 라우팅하면, 클라이언트 입장에서는 하나의 엔드포인트만 호출하면 된다. 어떤 요청이 어떤 모델로 가는지는 게이트웨이가 판단한다.
이 하이브리드 접근이 비용 측면에서도 유리하다. GPT-4급 모델로 모든 요청을 처리하면 토큰당 비용이 상당한데, 단순한 분류나 요약 작업은 오픈소스 7B 모델로도 충분히 품질이 나온다. 작업 난이도에 따라 모델을 다르게 라우팅하면 품질은 유지하면서 비용을 절반 이하로 줄일 수 있다.
RAG 시스템 설계, 기업 데이터와 AI를 연결하는 핵심
솔직히 말해서, RAG 없는 엔터프라이즈 AI는 반쪽짜리다. 아무리 좋은 모델을 올려도 회사 내부 문서를 참조하지 못하면 의미가 없다. “우리 회사 휴가 정책이 뭐야?” “지난달 매출 보고서에서 주요 이슈가 뭐였지?” 이런 질문에 일반적인 GPT 모델은 답을 못 한다. 우리 회사 문서를 학습한 적이 없으니까.
이걸 해결하는 게 RAG(Retrieval-Augmented Generation)이다. 사용자 질문이 들어오면, 먼저 기업 내부 문서에서 관련 정보를 검색하고, 그 검색 결과를 LLM의 프롬프트에 함께 넣어서 답변을 생성하는 방식이다. 모델을 파인튜닝하지 않고도 최신 기업 정보를 반영할 수 있다는 게 핵심 장점이다. 문서가 업데이트되면 인덱스만 갱신하면 되니까.
Azure에서 RAG 파이프라인을 설계하려면 세 가지 컴포넌트가 필요하다. 문서를 저장하는 Blob Storage, 문서를 인덱싱하고 검색하는 AI Search, 그리고 검색 결과를 받아서 답변을 생성하는 LLM이다.
데이터 저장 단계부터 보안을 신경 써야 한다. 기업 내부 문서를 Blob Storage에 올릴 때 Public Access를 어떻게 설정할지가 첫 번째 의사결정 포인트다. 완전히 막아버리면 AI Search 인덱서가 접근을 못 하고, 너무 열면 보안 위험이 생긴다. Managed Identity를 통해 AI Search에만 접근 권한을 부여하는 것이 정답인데, 이 설정이 처음에는 좀 까다롭다. Azure Blob Storage로 AI 학습 데이터 관리하기, Public Access 설정과 보안의 균형에서 이 균형 잡기를 자세히 다뤘다.
AI Search와 Blob Storage의 연동이 RAG의 핵심이다. Blob Storage에 올린 PDF, Word, 텍스트 파일을 AI Search의 인덱서가 자동으로 읽어서 청크로 나누고, Azure OpenAI의 임베딩 모델을 통해 벡터를 생성해서 인덱스에 저장한다. 사용자가 질문을 하면 질문도 벡터로 변환해서 인덱스에서 유사한 문서 조각을 검색하고, 그 결과를 LLM의 시스템 프롬프트에 넣어서 답변을 만든다. 이 전체 파이프라인을 Azure AI Search와 Blob Storage 연동하기, RAG 시스템 구축을 위한 실전 아키텍처에서 코드와 함께 구현 과정을 설명했다.
내 경험상 RAG에서 가장 중요한 건 청킹 전략이다. 문서를 어떻게 잘라서 인덱싱하느냐에 따라 검색 품질이 천차만별이다. 너무 작게 자르면 맥락이 사라져서 LLM이 단편적인 정보만 받게 되고, 너무 크게 자르면 검색 정확도가 떨어져서 엉뚱한 문서 조각이 올라온다. 보통 512에서 1024 토큰 사이가 적정선인데, 문서 유형에 따라 조정이 필요하다. 계약서 같은 법률 문서는 조항 단위로 자르는 게 낫고, 기술 문서는 섹션 단위가 효과적이다.
그리고 하나 더. 하이브리드 검색을 반드시 활용하자. 키워드 기반의 전통적인 BM25 검색과 벡터 기반의 시맨틱 검색을 함께 쓰는 것이다. “2025년 4분기 매출”처럼 정확한 키워드가 포함된 질문은 BM25가 강하고, “최근 실적이 어떤가요”처럼 의미 기반 질문은 벡터 검색이 강하다. Azure AI Search는 이 두 가지를 네이티브로 지원하니까 꼭 활용해야 한다.
배포 및 운영 전략, 프로덕션으로 가는 길
개발 환경에서 잘 돌아가는 것과 프로덕션에서 안정적으로 운영되는 것은 완전히 다른 이야기다. 내 로컬 PC에서 Docker로 띄운 서비스가 멀쩡하게 동작했는데, Azure에 올리니까 네트워크 문제, 인증 문제, 스케일링 문제가 줄줄이 터진다. 여기서 가장 중요한 결정이 컴퓨팅 플랫폼 선택이다.
Azure에서 AI API를 서빙할 때 가장 많이 비교하는 것이 Container Apps와 App Service다. 이 둘의 차이를 한 줄로 요약하면, Container Apps는 “내가 직접 컨테이너를 관리하면서 유연하게 운영하는 것”이고, App Service는 “플랫폼에 코드만 올리면 나머지는 알아서 해주는 것”이다.
Container Apps는 Kubernetes 기반이라 자동 스케일링이 유연하다. 요청이 없으면 인스턴스를 0개까지 줄일 수 있어서(scale to zero) 비용 효율이 좋다. 여러 컨테이너를 하나의 앱으로 묶을 수도 있고, Dapr 사이드카 패턴도 지원한다. 반면 App Service는 빠르게 배포할 수 있고 설정이 간단하지만, 세밀한 스케일링 제어가 어렵고 최소 인스턴스 비용이 발생한다. 내 경험상 트래픽 변동이 큰 AI 서비스는 Container Apps가, 안정적인 트래픽의 웹 서비스와 결합된 경우는 App Service가 낫다. Azure Container Apps vs App Service, AI API 서빙에 어떤 걸 선택해야 할까에서 두 서비스의 실제 성능 비교와 선택 기준을 정리해뒀다.
규모가 커지면 결국 Kubernetes로 간다. 이건 피할 수 없는 수순이다. 여러 마이크로서비스가 유기적으로 연결되고, 각각 다른 스케일링 정책이 필요하고, 블루그린이나 카나리 배포를 해야 할 때 Kubernetes만큼 강력한 도구가 없다.
문제는 마이그레이션 과정이다. Docker Compose로 개발하다가 AKS로 옮기는 것은 단순한 설정 변환이 아니다. docker-compose.yml의 네트워크 설정, 볼륨 마운트, 환경 변수 관리 방식이 전부 Kubernetes 방식으로 바뀌어야 한다. Service, Deployment, ConfigMap, Secret, PersistentVolumeClaim 등 Kubernetes 리소스로 하나하나 매핑해야 한다. Docker Compose 애플리케이션을 Azure AKS로 마이그레이션하는 방법에서 nginx, React, Python, PostgreSQL 스택의 실제 마이그레이션 과정을 단계별로 설명했다.
Windows 환경에서 개발하는 팀이라면 로컬에서 Kubernetes를 테스트하고 AKS에 배포하는 워크플로우를 세팅하는 것도 중요하다. Docker Desktop의 Kubernetes 기능을 활용하면 로컬에서 먼저 검증한 뒤 AKS에 올릴 수 있어서, “내 PC에서는 되는데 Azure에서는 안 되는” 상황을 크게 줄일 수 있다. Windows에서 Kubernetes로 Azure AKS에 Nginx + React 배포하기에서 Windows 환경 기준의 전체 배포 과정을 다뤘다.
여기서 한 가지 실전 팁을 더 공유하자면, AKS에서 AI 워크로드를 돌릴 때 노드풀을 분리하는 게 좋다. GPU 노드풀과 CPU 노드풀을 따로 두고, AI 추론 Pod는 GPU 노드에, API 서버나 프론트엔드는 CPU 노드에 배치하는 것이다. 이렇게 하면 GPU 리소스 낭비를 줄이면서도 각 워크로드에 최적화된 인프라를 제공할 수 있다.
서버리스 아키텍처로 비용 최적화하기
AI 서비스를 24시간 돌리면 비용이 상당하다. 특히 스타트업이나 소규모 팀에서는 GPU VM 하나의 월 비용이 수백만 원에 달하니 부담이 크다. 이때 서버리스 아키텍처가 답이 될 수 있다.
Azure Functions를 활용하면 요청이 들어올 때만 컴퓨팅 리소스가 할당되고, 요청이 없으면 비용이 0원이다. 간단한 AI 챗봇이나 문서 분석 API, 알림 기반의 이벤트 처리 등에 이 방식이 효과적이다. 예를 들어 Slack 봇으로 사내 문서를 검색해주는 서비스를 만든다면, 직원들이 질문할 때만 함수가 실행되고 나머지 시간에는 비용이 발생하지 않는다.
물론 콜드 스타트 이슈가 있다. 함수가 한동안 호출되지 않으면 인스턴스가 해제되고, 다음 요청이 올 때 다시 초기화하느라 1~3초 정도 지연이 생긴다. 이게 실시간 대화형 서비스에서는 치명적일 수 있다. Premium Plan을 쓰면 최소 1개의 인스턴스를 항상 대기시켜둘 수 있고, 워밍업 트리거를 설정해서 콜드 스타트를 완화할 수도 있다. 물론 Premium Plan은 상시 비용이 발생하지만, 전용 VM을 돌리는 것보다는 훨씬 저렴하다.
Azure Functions로 서버리스 AI 챗봇 만들기, 비용 최소화하면서 24시간 운영하는 방법에서 실제 구현 코드와 Consumption Plan vs Premium Plan의 비용 비교까지 다뤘다.
서버리스가 모든 상황에 맞는 건 아니다. GPU가 필요한 모델 추론이나 장시간 실행되는 배치 작업, 웹소켓 기반의 실시간 스트리밍에는 적합하지 않다. 중요한 건 워크로드의 특성에 따라 서버리스와 전용 서버를 적절히 조합하는 것이다. 비용에 민감한 부분은 Functions로, 성능에 민감한 부분은 Container Apps나 AKS로 분리하는 것이 현실적인 접근이다.
마무리
이 글에서 다룬 내용을 다시 정리해보면, Azure 기반 엔터프라이즈 AI 아키텍처는 크게 여섯 개의 레이어로 구성된다. 맨 아래에 보안과 인증이 있고, 그 위에 모델 배포 전략, RAG 데이터 파이프라인, 컴퓨팅 플랫폼 선택, 서버리스 비용 최적화, 그리고 전체를 관통하는 운영 전략이 있다.
Azure 기반 AI 아키텍처를 설계하면서 내가 깨달은 가장 중요한 점은, 완벽한 아키텍처는 처음부터 나오지 않는다는 것이다. 처음에는 작게 시작한다. Azure OpenAI 하나 연결해서 챗봇을 만든다. 그다음 보안이 필요해서 Managed Identity를 붙인다. 사내 데이터를 참조해야 하니까 RAG를 도입한다. 사용자가 늘어나니까 Container Apps로 옮긴다. 더 커지면 AKS로 간다. 이 과정을 반복하면서 아키텍처가 진화하는 거다.
다만 처음부터 지켜야 할 원칙이 있다. 보안은 설계 초기에 포함시킬 것. 인증에 API Key 대신 Managed Identity를 쓸 것. 데이터 저장소와 컴퓨팅을 분리할 것. 그리고 모든 구성 요소가 독립적으로 교체 가능하도록 느슨하게 결합할 것. 이 네 가지 원칙만 지키면, 나머지는 필요에 따라 하나씩 붙여나가면 된다. 처음부터 거대한 아키텍처를 그리고 시작하면 오히려 복잡성에 치여서 아무것도 못 만든다.
2026년 현재 엔터프라이즈 AI는 더 이상 실험 단계가 아니다. 인프라이자 기업의 경쟁력이다. 그리고 그 인프라의 중심에 아키텍처가 있다. 이 글이 Azure 위에서 AI 시스템을 설계하려는 개발자와 아키텍트에게, 큰 그림을 잡는 데 도움이 되는 실질적인 로드맵이 되기를 바란다.