Azure AI 시스템을 처음 설계하려고 Portal 앞에 앉았을 때 솔직히 말하면 나도 처음엔 Azure Portal 앞에서 멍하니 앉아 있었다. 수백 개 서비스가 화면 가득 펼쳐져 있는데, 뭘 먼저 눌러야 할지 도통 감이 안 잡혔다. 주변에서는 AI Foundry가 어쩌고, Managed Identity가 저쩌고 하는데, 나는 OpenAI API Key 하나 .env 파일에 넣고 직접 호출하면 되지 왜 이렇게 복잡하게 만드나 싶었다.
그런 내가 지금은 Azure 위에서 엔터프라이즈 AI 시스템을 설계하고 운영하고 있다. 이 과정에서 뼈아프게 배운 것들이 있다. 누군가 처음부터 알려줬으면 시행착오를 반 이상 줄일 수 있었을 텐데. 오늘 그 이야기를 해보려고 한다.
Azure OpenAI를 써야 하는 진짜 이유
작년에 프로토타입으로 만든 사내 챗봇이 있었다. OpenAI API를 직접 호출하는 방식이었고, 개발팀 내에서 테스트할 때는 문제없이 돌아갔다. 그런데 전사 오픈을 하자마자 상황이 달라졌다. 금요일 오후 트래픽이 몰리면서 Rate Limit에 걸리기 시작했고, 월요일 아침에 API Key가 Slack 채널에 공유된 게 발견됐다. 누군가 테스트하려고 올린 건데, 그 사이에 외부 요청이 들어와서 토큰이 수만 개 소모됐다.
이때 깨달았다. 개인 프로젝트라면 OpenAI 직접 호출로 충분하지만, 회사에서 쓰려면 보안, 접근 제어, 트래픽 관리, 모델 버전 고정이 전부 필요하다. 이걸 직접 만들면 Azure가 이미 해놓은 걸 처음부터 다시 만드는 셈이다.
Azure OpenAI를 쓰면 내가 선택한 모델 버전이 내 리소스에 고정 배포된다. 프로덕션 환경에서 모델 업데이트 시점을 내가 결정할 수 있다는 거다. 직접 API를 호출하면 모델이 예고 없이 바뀌어서, 어제까지 잘 되던 프롬프트가 오늘 엉뚱한 결과를 내놓는 상황이 실제로 발생한다.
2026년 2월 기준으로 Microsoft Foundry(구 AI Foundry)는 11,000개 이상의 모델을 제공하고 있다. GPT 시리즈만이 아니다. Anthropic Claude, Llama, Mistral, Cohere까지 한 플랫폼에서 관리할 수 있게 됐다. 최근에는 Moonshot AI의 Kimi-K2 Thinking 모델도 추가됐고, 올해 1월에 도입된 v1 API 덕분에 매달 버전 업데이트 없이 표준 인터페이스 하나로 안정적인 운영이 가능해졌다.
API Key 유출 사고 이후 보안을 처음부터 다시 했다
그 사건 이후 보안 설계를 아예 처음부터 다시 했다. 솔직히 보안은 나중에 덧붙이면 되는 거라고 생각했다. 모델 연결하고, API 만들고, 프론트엔드 붙이고, 보안은 나중에 하면 되겠지. 그리고 보안팀에서 정확히 예상한 대로 퇴짜를 놨다.
Azure 보안의 핵심은 Managed Identity다. API Key를 아예 안 쓰는 방식이다. Azure 서비스가 알아서 토큰을 발급하고 갱신하니까, 개발자가 키를 만질 일이 없어진다. 유출 위험 자체가 사라지는 거다.
코드는 오히려 더 간단해진다. DefaultAzureCredential 하나면 로컬에서는 Azure CLI 인증을, 프로덕션에서는 Managed Identity를 자동으로 사용한다. 코드 변경 없이 환경에 따라 인증 방식이 바뀐다.
내가 범한 실수 중 하나를 고백하자면, App Registration과 App Service를 완전히 헷갈렸다. 이름이 비슷해서 같은 계열 서비스인 줄 알았는데 전혀 다르다. App Registration은 Entra ID에서 앱의 신원을 등록하는 거고, App Service는 웹앱 호스팅 서비스다. 이 구분 없이 인증 아키텍처를 짜면 토큰 흐름이 반드시 꼬인다.
Azure App Registration과 App Service 완벽히 구분하려면 해당 링크 참조
2026년에는 에이전틱 AI가 본격 확산되면서 보안이 더 중요해지고 있다. 각 AI 에이전트에 명확한 신원을 부여하고 접근 권한을 제한하는 체계적 보안 설계가 필수가 됐다. 보안은 아키텍처의 첫 번째 기둥이지 나중에 덧붙이는 장식이 아니다.
모델 배포, 매니지드 vs 직접 서빙
이 고민은 Azure에서 AI 시스템을 설계하는 팀이라면 반드시 겪는다. 두 가지 경로가 있다.
첫 번째는 Foundry를 통해 GPT-5, Claude 같은 모델을 매니지드로 배포하는 것이다. Portal에서 몇 번 클릭하면 끝이고, 인프라 관리가 거의 없다.
Azure AI Foundry 정확히 뭐 하는 곳인지 궁금하면 이 글을 참조하길 바란다.
최근 호스티드 에이전트 기능이 프리뷰로 나오면서 LangGraph나 CrewAI 같은 오픈소스 프레임워크를 컨테이너 없이 바로 매니지드 런타임에 배포할 수 있게 됐다. 정식 과금은 4월 이후라 지금이 테스트 적기다.
두 번째는 vLLM을 Azure VM에 직접 올리는 것이다. Llama, Qwen 같은 오픈소스 모델을 자유롭게 돌리거나, 한국어 특화 모델을 파인튜닝해서 서빙할 때 필요하다. GPU는 Standard_NC24ads_A100_v4가 가성비가 괜찮다. A100 80GB 하나로 7B~13B 모델은 여유 있게 돌리고, 양자화 적용 시 70B급도 올릴 수 있다.
실무에서는 두 경로를 동시에 쓰는 하이브리드 전략이 현실적이다. 범용 작업은 GPT-5로, 도메인 특화 작업은 vLLM 자체 모델로 처리하고, API Gateway를 앞에 둬서 라우팅한다. 작업 난이도에 따라 모델을 다르게 배분하면 품질 유지하면서 비용을 절반 넘게 줄일 수 있다.
RAG 구축할 때 가장 많이 실수하는 것
RAG 없는 엔터프라이즈 AI는 반쪽짜리다. GPT-5를 올려도 회사 문서를 참조 못 하면 “우리 회사 연차 정책 어떻게 돼?” 같은 질문에 답을 못 한다.
Azure에서 RAG는 Blob Storage에 문서를 올리고, AI Search로 인덱싱하고, LLM이 검색 결과를 참조해서 답변을 만드는 구조다. 단순해 보이지만 의외의 곳에서 막힌다.
내가 가장 삽질한 부분은 청킹 전략이다. 문서를 어떤 크기로 자르느냐에 따라 검색 품질이 완전히 달라진다. 처음에 기본 512토큰으로 잘랐더니 맥락이 끊긴 단편적인 내용만 올라왔다. 크게 자르니까 관련 없는 내용이 섞였다. 결국 문서 유형에 따라 다르게 가야 한다. 계약서는 조항 단위로, 기술 문서는 섹션 헤더 기준으로 자르는 게 효과적이다.
하이브리드 검색도 꼭 활용하자. BM25(키워드 검색)와 벡터(시맨틱) 검색을 동시에 쓰는 것이다. “2025년 4분기 매출”은 BM25가, “최근 실적이 어땠나요”는 벡터가 강하다. Azure AI Search가 둘 다 네이티브 지원하니까 하나만 쓰면 손해다.
최근 Foundry에 에이전트 메모리 기능이 프리뷰로 추가됐다. 세션 간 장기 기억을 자동으로 관리해주는 건데, 기존 RAG의 한계를 보완할 수 있는 방향이다. 프리뷰 기간에는 모델 호출 비용만 발생하니 테스트해볼 만하다.
프로덕션 배포, Container Apps vs App Service
로컬에서 Docker로 잘 돌아가는데 Azure에서 안 되는 상황, 누구나 겪는다.
배포 플랫폼은 Container Apps와 App Service 중 고민하게 되는데, 간단하게 정리하면 이렇다. 트래픽 변동이 크고 비용 절감이 우선이면 Container Apps, 빠른 배포와 관리 단순성이 우선이면 App Service다. Container Apps는 요청이 없으면 인스턴스를 0개까지 줄일 수 있어서 AI 서비스처럼 피크와 비피크 차이가 큰 경우에 비용 효율이 좋다.
규모가 커지면 결국 AKS로 간다. 이때 실전 팁은 노드풀 분리다. GPU 노드풀과 CPU 노드풀을 따로 두고, AI 추론 Pod는 GPU에, API 서버는 CPU에 배치해야 한다. 안 그러면 GPU가 엉뚱한 곳에 낭비된다.
서버리스인 Azure Functions도 간헐적 워크로드에는 효과적이다. Slack 봇이나 이벤트 기반 처리처럼 요청이 들어올 때만 리소스가 필요한 경우에 비용이 0원에 가까워진다. 다만 콜드 스타트 이슈가 있어서 실시간 대화 서비스에는 부적합할 수 있다.
마무리
Azure 기반 AI 아키텍처를 설계하면서 가장 크게 배운 건, 완벽한 구조는 처음부터 나오지 않는다는 것이다. 시작은 작게 한다. OpenAI 하나 연결해서 챗봇 만들고, Managed Identity 붙이고, RAG 도입하고, Container Apps로 옮기고, 필요하면 AKS로 가는 거다.
다만 처음부터 지켜야 할 원칙은 분명하다. 보안은 설계 초기에, API Key 대신 Managed Identity를, 저장소와 컴퓨팅은 분리, 구성 요소는 느슨하게 결합. 이 네 가지만 지키면 나머지는 필요에 따라 붙여나갈 수 있다.
2026년은 에이전틱 AI 시대로 접어들면서 아키텍처의 중요성이 더 커지고 있다. Microsoft Foundry가 에이전트 런타임과 모델 관리를 통합 플랫폼으로 제공하면서 진입 장벽은 낮아졌지만, 설계의 깊이에서 차이가 나는 시대가 됐다. 처음부터 거대한 그림을 그리지 말고 원칙을 지키면서 작게 시작하자. 복잡성은 필요할 때 자연스럽게 따라온다.
Build in the cloud with an Azure account
Azure 기반 엔터프라이즈 AI 아키텍처에 대해 설계와 운영 실전 로드맵이 필요하다면 아래 글을 참조하길 바란다.