마켓플레이스 AI 앱 및 에이전트에 ‘프로덕션 준비’ 아키텍처가 중요한 이유
작동하는 AI 프로토타입은 Microsoft Marketplace의 프로덕션 준비 AI 앱과 다릅니다. 마켓플레이스 솔루션은 실제 고객 환경에서 미션 크리티컬 워크로드와 함께 엔터프라이즈 제약 조건 하에서 안정적으로 작동할 것으로 기대됩니다. 따라서 마켓플레이스를 통해 게시되는 AI 앱은 "데모에서 작동한다"는 것보다 더 높은 기준을 충족해야 합니다.
프로덕션 준비 마켓플레이스 AI 앱은 다음 사항을 가정해야 합니다.
- 비용 최적화, 보안, 안정성, 운영 우수성, 성능 효율성을 포함한 엔터프라이즈 기대치 및 Azure Well-Architected Framework와의 정렬.
- 특히 고객, 테넌트, 청구 관계가 설정된 후에는 초기에 내린 아키텍처 결정은 되돌리기 어렵습니다.
- 고객으로부터 더 높은 신뢰도를 요구받습니다. 고객은 마켓플레이스 솔루션이 Microsoft의 검토를 거쳐 인증되었으며 프로덕션 환경에서 안전하게 실행될 것으로 기대합니다.
고객은 마켓플레이스에서 실험적인 솔루션이 아닌, 즉시 실행 가능하고, 확장 가능하며, 지원 준비가 된 솔루션을 기대합니다.
이 게시물은 이러한 기대치를 충족하는 데 필요한 아키텍처 원칙과 패턴에 중점을 둡니다. 특정 서비스 및 구현 세부 정보는 시리즈의 다음 게시물에서 다룹니다.
이 게시물은 Microsoft Marketplace에 잘 설계된 AI 앱 및 에이전트를 구축하고 게시하는 시리즈의 일부입니다.
오퍼 유형과 아키텍처를 조기에 정렬하면 성공적인 여정을 위한 기반을 마련할 수 있습니다.
마켓플레이스 여정의 순조로운 진행을 나타내는 강력한 지표는 오퍼 유형과 솔루션 아키텍처 간의 조기 정렬입니다. 오퍼 유형은 AI 앱이 나열되는 방식 이상을 정의합니다. 이는 게시자와 고객 간의 명확한 역할과 책임을 설정하며, 이는 다시 아키텍처 경계를 형성합니다. 다른 모든 오퍼 유형에 걸쳐 아키텍처는 다음 세 가지 질문에 명확하게 답해야 합니다.
- 누가 런타임을 소유합니까?
- AI는 어디에서 실행됩니까?
- 누가 업데이트 및 지속적인 운영을 제어합니까?
이러한 결정은 솔루션이 고객 또는 게시자의 테넌트에 상주하는지 여부와, 다음 거래 가능 마켓플레이스 오퍼 유형에 연결된 속성에 따라 달라집니다.
- SaaS 오퍼, AI 런타임이 게시자의 환경에 존재하며 아키텍처는 다중 테넌시, 강력한 격리 및 중앙 집중식 운영을 지원해야 합니다.
- 컨테이너 오퍼, 워크로드가 고객의 Kubernetes 환경에서 실행되며 아키텍처는 이식성과 명확한 운영 가정을 강조합니다.
- 가상 머신 오퍼, 사전 구성된 환경이 고객의 구독에서 실행되며 아키텍처는 OS 및 인프라 설치 공간에 더 밀접하게 연결됩니다.
- Azure 관리형 애플리케이션, 솔루션이 고객의 구독에 배포되며 아키텍처는 고객 제어와 정의된 수명 주기 경계를 균형 있게 유지해야 합니다. 이 모델이 독특한 이유는 유연성 때문입니다. Azure 관리형 애플리케이션은 컨테이너, 가상 머신 또는 둘의 조합을 패키지할 수 있어, 게시자가 관리하는 운영을 희생하지 않고 고객이 제어하는 인프라가 필요한 솔루션에 자연스럽게 적합합니다. 패키징 선택은 기본 아키텍처를 형성하지만, 관리형 애플리케이션 래퍼는 솔루션이 고객 환경 내에서 배포, 업데이트 및 거버넌스되는 방식을 정의합니다.
아키텍처 결정은 자연스럽게 마켓플레이스 요구 사항을 강화하고 나중에 인증 및 운영 마찰을 줄입니다. 조기 정렬의 이점을 얻을 수 있는 주요 요소는 다음과 같습니다.
- 역할과 책임, AI 런타임 운영자, 가동 시간, 패치, 스케일링, 지속적인 운영에 대한 책임자 등.
- 데이터 근접성, 특히 고객별 또는 독점 데이터에 의존하는 AI 솔루션의 경우 배치 위치가 성능, 데이터 이동 및 규정 준수에 영향을 미칩니다.
AI 앱의 핵심 아키텍처 구성 요소
프로덕션 준비 AI 앱 설계는 솔루션을 단일 서비스가 아닌 시스템으로 취급하는 것에서 시작됩니다. AI 앱, 특히 에이전트 기반 솔루션은 추론, 작업 및 대규모 안전한 운영을 가능하게 하는 여러 협력 계층으로 구성됩니다.
높은 수준에서, 대부분의 프로덕션 준비 AI 앱에는 다음 구성 요소가 포함됩니다.
- 상호 작용 계층, 사용자 또는 시스템의 진입점 역할을 하며 인증, 요청 형식 지정 및 일관된 응답을 담당합니다.
- 오케스트레이션 계층, 다단계 상호 작용 전반에 걸쳐 추론, 도구 선택, 워크플로 실행 및 검색 증강 생성(RAG) 흐름을 조정합니다.
- 모델 엔드포인트, 추론 및 생성 기능을 제공하며 개별적인 지연 시간, 비용 및 종속성 특성을 도입합니다.
- 데이터 소스, AI 시스템이 추론하는 벡터 저장소, 운영 데이터, 문서 및 로그를 포함합니다.
- 컨트롤 플레인, 핵심 로직을 재배포하지 않고 동작을 제어하는 ID, 구성, 정책 적용, 기능 플래그 및 비밀 관리 등.
- 관찰 가능성, 에이전트 결정, 작업 및 결과를 추적, 모니터링 및 진단할 수 있습니다.
- 네트워킹, 모든 호출이 인증되고 아웃바운드 액세스가 명시적으로 제어되는 제로 트러스트(zero‑trust) 자세를 사용하여 구성 요소를 연결합니다.
함께, 이러한 구성 요소는 대부분의 마켓플레이스 준비 AI 아키텍처의 기반을 형성합니다. 이들이 어떻게 구성되는지, 그리고 경계가 어디에 그려지는지는 오퍼 유형, 테넌시 모델 및 고객 요구 사항에 따라 다릅니다. 각 계층에 대한 특정 서비스, 패턴 및 구현 지침은 시리즈의 다음 게시물에서 자세히 다룹니다.
조기 아키텍처 결정으로서의 테넌시 설계 선택
가장 초기이자 가장 중요한 아키텍처 결정 중 하나는 AI 솔루션이 어디에 호스팅되는지입니다. 게시자의 테넌트에서 실행됩니까, 아니면 고객의 테넌트에 배포됩니까? 이 선택은 기본적인 경계를 설정하며, 나중에 상당한 재설계 없이 변경하기 어렵습니다.
솔루션이 게시자의 테넌트에서 실행되는 경우, 본질적으로 다중 테넌트이며 고객 간에 강력한 논리적 격리를 염두에 두고 설계되어야 합니다. 고객의 테넌트에서 실행되는 경우, 배포는 일반적으로 기본적으로 단일 테넌트이며 인프라 경계를 통해 격리가 제공됩니다. 많은 마켓플레이스 AI 앱이 이러한 극단 사이에 속하므로 테넌시 모델을 조기에 정의하는 것이 필수적입니다.
일반적인 테넌시 접근 방식은 다음과 같습니다.
- 게시자 호스팅, 다중 테넌트 솔루션, 공유 AI 런타임이 여러 고객에게 서비스를 제공하며 고객 데이터, 추론 요청, ID 및 비용 할당에 대한 엄격한 격리가 필요합니다.
- 고객 호스팅, 단일 테넌트 배포, 각 고객이 자체 Azure 구독 내에서 격리된 인스턴스를 운영하며, 규제되거나 엄격하게 통제되는 환경에 자주 선호됩니다.
- 하이브리드 모델, 중앙 집중식 AI 서비스와 고객 호스팅 데이터 또는 실행 계층을 결합하며, 신뢰 및 액세스 경계를 신중하게 정의해야 합니다.
테넌시 결정은 다음을 포함하여 여러 핵심 아키텍처 차원에 영향을 미칩니다.
- ID 및 액세스 경계, 사용자 및 에이전트가 테넌트 간에 어떻게 인증하고 작동하는지를 정의합니다.
- 데이터 격리, 고객 데이터가 저장, 처리 및 보호되는 방법을 포함합니다.
- 모델 사용 패턴, 공유 모델 대 테넌트별 모델 등.
- 비용 할당 및 규모, 고객별 사용량을 추적하고 할당하는 방법을 포함합니다.
이러한 고려 사항은 구현 세부 사항이 아니라, AI 시스템이 프로덕션 환경에서 어떻게 동작하고, 확장되며, 거버넌스되는지를 형성합니다. Azure 아키텍처 센터의 다중 테넌트 AI 및 머신러닝 솔루션을 위한 참조 아키텍처 지침에서 이러한 트레이드오프를 더 자세히 다룹니다.
고객의 요구 사항 이해
프로덕션 준비 AI 아키텍처를 설계하는 것은 고객이 솔루션이 작동할 것으로 기대하는 환경을 이해하는 것에서 시작됩니다. 마켓플레이스 고객은 보안 상태, 규정 준수 의무, 운영 방식 및 변화에 대한 허용 범위가 광범위하게 다릅니다. 이러한 현실을 반영하는 아키텍처는 온보딩, 인증 및 장기 운영 중에 마찰을 줄입니다.
아키텍처를 형성하는 주요 고객 고려 사항은 다음과 같습니다.
- 보안 및 규정 준수 기대치, 산업 규정, 내부 거버넌스 정책 또는 지역 데이터 요구 사항 등.
- 대상 환경, 고객이 솔루션이 자체 Azure 구독에서 실행되기를 기대하는지 또는 중앙 집중식 호스팅 서비스를 사용하는 데 편안함을 느끼는지 여부.
- 변경 및 중단 기간, 운영 제약 조건 또는 계절적 제한으로 인해 예측 가능하고 통제된 업데이트가 필요한 경우.
고객 요구 사항과의 아키텍처 정렬은 모든 예외 상황을 위해 설계하는 것이 아닙니다. 이는 고객이 프로덕션 환경에서 AI 솔루션을 어떻게 배포하고, 운영하며, 의존할 것인지를 반영하는 의도적인 트레이드오프를 만드는 것입니다.
특정 보안 제어, 규정 준수 시행 메커니즘 및 운영 정책은 시리즈의 다음 게시물에서 자세히 다룹니다. 이 섹션은 이를 지원하는 데 필요한 아키텍처 사고방식을 확립합니다.
안전한 반복을 위한 환경 분리
프로덕션 AI 시스템은 고객을 위해 안정성을 유지하면서 지속적으로 발전해야 합니다. 환경을 분리하는 것은 게시자가 라이브 사용을 불안정하게 만들지 않고 안전한 반복을 가능하게 하는 방법이며, 고객이 자체 환경에서 AI 솔루션을 채택하고 운영할 때 신뢰를 유지하는 방법입니다.
게시자의 관점에서 환경 분리는 다음을 가능하게 합니다.
- 프로덕션 고객에게 영향을 주지 않고 프롬프트, 모델 및 오케스트레이션 로직을 반복합니다.
- 특히 작은 변경으로 인해 실질적으로 다른 결과가 나올 수 있는 AI 기반 시스템의 경우 출시 전 행동 변경을 검증합니다.
- 운영 위험을 줄이는 통제된 릴리스 전략.
고객의 관점에서 환경 분리는 솔루션이 자체 개발 및 운영 방식에 어떻게 부합하는지를 형성합니다.
- 솔루션이 개발, 스테이징 및 프로덕션 환경에 걸쳐 배포되는 위치.
- 특히 솔루션이 고객의 테넌트에서 실행될 때 배포가 반복되거나 승격되는 방법.
- 환경을 예측 가능하게 다시 생성할 수 있는지 여부 또는 고객이 각 반복마다 배포를 수동으로 재구성해야 하는지 여부.
AI 솔루션이 고객의 테넌트에 배포될 때 환경 설계는 특히 중요해집니다. 고객은 솔루션이 발전할 때마다 배포 로직을 역설계하거나, 환경을 처음부터 다시 만들거나, 신뢰 경계를 다시 설정하도록 요구받아서는 안 됩니다. 이러한 우려는 운영상의 임시방편으로 미루지 않고 아키텍처적으로 해결되어야 합니다.
따라서 환경 분리는 단순한 DevOps 선택이 아니라 아키텍처 결정입니다. 이는 ID 경계, 배포 토폴로지, 검증 전략, 그리고 게시자와 고객 간의 공유 운영 계약에 영향을 미칩니다.
AI 특정 확장성 패턴 설계
AI 워크로드는 기존 웹 또는 CRUD 기반 애플리케이션처럼 확장되지 않습니다. 프런트엔드 및 API 계층은 익숙한 확장 패턴을 따를 수 있지만, AI 시스템은 다른 아키텍처 가정을 필요로 하는 동작을 도입합니다.
프로덕션 준비 AI 아키텍처는 다음을 고려해야 합니다.
- 버스트(Bursty) 추론 수요, 사용자 행동 또는 다운스트림 자동화에 따라 사용량이 예측할 수 없이 급증할 수 있습니다.
- 장기 실행 또는 다단계 에이전트 워크플로, 도구, 데이터 소스 및 시간을 아우를 수 있습니다.
- 모델 기반 지연 시간 및 비용 특성, 애플리케이션 로직과 독립적으로 처리량과 응답성에 영향을 미칩니다.
결과적으로 확장성 결정은 종종 계층별로 다릅니다. 수평 확장은 일반적으로 상호 작용, 오케스트레이션 및 검색 구성 요소에서 가장 효과적이며, 모델 엔드포인트는 별도의 용량 계획, 격리 또는 스로틀링 전략이 필요할 수 있습니다.
ID를 아키텍처 경계로 취급
ID는 마켓플레이스 AI 앱의 기반이지만, 아키텍처는 이를 명시적으로 계획해야 합니다. ID 결정은 사용자, 에이전트 및 서비스 전반에 걸친 신뢰 경계를 정의하고, 솔루션이 확장되고, 액세스를 보호하며, 규정 준수 요구 사항을 충족하는 방식을 형성합니다.
주요 아키텍처 고려 사항은 다음과 같습니다.
- 기반으로서의 Microsoft Entra ID, ID를 늦은 단계의 통합이 아닌 핵심 제어 플레인으로 취급합니다.
- 사용자가 로그인하는 방법, 다음을 포함합니다.
- 자체 기업 Microsoft Entra ID 테넌트
- 하나의 Entra ID 테넌트가 다른 테넌트를 신뢰하는 B2B 시나리오
- 고객 대면 경험을 위한 B2C ID 공급자
- 테넌트가 인증하는 방법, 특히 다중 테넌트 또는 조직 간 시나리오에서.
- AI 에이전트가 사용자를 대신하여 작동하는 방법, 위임된 액세스, 권한 부여 범위 및 감사 가능성을 포함합니다.
- 서비스가 안전하게 통신하는 방법, 모든 호출이 인증되고 권한이 부여되는 제로 트러스트(zero‑trust) 자세를 사용합니다.
ID를 아키텍처 경계로 취급하면 신뢰 관계가 테넌트 및 환경 전반에 걸쳐 명시적이고, 시행 가능하며, 일관되게 유지되도록 하는 데 도움이 됩니다. 이 기반은 보안 운영, 규정 준수 시행 및 향후 테넌트 연결 시나리오를 지원하는 데 중요합니다.
관찰 가능성 및 감사 가능성 설계
프로덕션 준비 AI 앱은 설계상 관찰 가능하고 감사 가능해야 합니다. 마켓플레이스 고객은 시스템이 프로덕션에서 어떻게 동작하는지에 대한 가시성을 기대하며, 게시자는 문제를 진단하고, 안정적으로 운영하며, 기업의 신뢰 및 규정 준수 기대치를 충족하기 위한 명확한 통찰력이 필요합니다.
주요 아키텍처 고려 사항은 다음과 같습니다.
- 종단 간 관찰 가능성, 사용자 상호 작용, 에이전트 추론 단계, 도구 호출 및 다운스트림 서비스 호출을 포함합니다.
- 명확한 감사 추적, 누가 작업을 시작했는지, AI 시스템이 무엇을 했는지, 결정이 어떻게 실행되었는지(특히 에이전트가 사용자를 대신하여 작동할 때)를 캡처합니다.
- 테넌트 인식 가시성, 로그, 메트릭 및 추적이 테넌트 간에 데이터를 노출하지 않고 올바르게 할당되도록 보장합니다.
- 운영 투명성, 즉흥적인 계측 없이 효과적인 문제 해결, 사고 대응 및 지속적인 개선을 가능하게 합니다.
AI 시스템의 경우, 관찰 가능성은 인프라 상태를 넘어섭니다. 또한 프롬프트 실행, 모델 선택, 검색 결과 및 도구 사용과 같은 AI 특정 동작을 고려해야 합니다. 이러한 가시성이 없으면 실제 고객 환경에서 실패를 진단하거나, 변경 사항을 검증하거나, 결과를 설명하는 것이 어려워집니다.
감사 가능성도 똑같이 중요합니다. ID, 액세스 및 작업 기록은 보안 검토, 규제 의무 및 고객 신뢰를 지원하기 위해 추적 가능해야 합니다. 특히 규제되거나 엔터프라이즈 환경에서 더욱 그렇습니다.
마켓플레이스 AI 앱의 일반적인 아키텍처 함정
숙련된 팀조차도 AI 프로토타입에서 프로덕션 준비 마켓플레이스 솔루션으로 전환할 때 유사한 문제에 직면합니다. 다음 함정은 아키텍처 결정이 연기되거나 암묵적으로 이루어질 때 자주 나타납니다.
일반적인 함정은 다음과 같습니다.
- AI를 시스템이 아닌 단일 서비스로 취급하는 경우, 오케스트레이션, 데이터 액세스, ID, 관찰 가능성 및 운영 경계를 고려하지 않고 모델 추론을 구현합니다.
- 테넌트 가정을 하드 코딩하는 경우, 단일 테넌트, ID 모델 또는 배포 토폴로지를 가정하여 고객 요구 사항이 다양해질수록 되돌리기 어려워집니다.
- 탄력적인 모델 전략을 계획하지 않는 경우, 모델 버전이 변경되거나, 기능이 발전하거나, 공급자가 파괴적인 동작을 도입할 때 아키텍처가 취약해집니다.
- 데이터가 솔루션과 동일한 경계 내에 있다고 가정하는 경우, 실제로는 다른 테넌트, 구독 또는 제어 플레인에 상주할 수 있습니다.
- 프롬프트 로직을 애플리케이션 코드에 긴밀하게 결합하는 경우, 전체 재배포 없이 AI 동작을 반복하거나, 변경 사항을 검증하거나, 위험을 관리하기 어렵게 만듭니다.
- 문제가 출시 후 해결될 수 있다고 가정하는 경우, 고객, 구독 및 신뢰 관계가 설정된 후 아키텍처를 변경하는 데 드는 비용과 복잡성을 과소평가합니다.
이러한 함정은 고객 측의 기술 부족으로 인해 발생할 수도 있지만, 일반적으로 속도를 위해 아키텍처 결정이 연기되거나 AI 동작이 프로덕션 시스템의 일부가 아닌 고립된 문제로 취급될 때 나타날 수 있습니다.
여정의 다음 단계
오퍼 유형, 테넌시, ID, 환경 및 관찰 가능성에 대한 초기에 이루어진 아키텍처 결정은 다른 모든 것이 구축되는 기반을 마련합니다. 이러한 선택이 의도적일 때, 솔루션이 진화하고, 확장되며, 실제 고객 요구 사항에 적응함에 따라 마찰이 줄어듭니다. 다음 게시물 세트는 이 기반 위에서 프로덕션 환경에서 마켓플레이스 AI 앱을 운영하고, 보호하며, 발전시키는 다양한 측면을 탐구합니다.
주요 자료
- App Advisor에서 앱 또는 에이전트를 구축, 게시 또는 판매하는 데 도움이 되는 엄선된 단계별 지침을 확인하세요(어디에서 시작하든 상관없음).
- 퀵스타트 개발 툴킷(Quick-Start Development Toolkit)을 통해 AI 솔루션 패턴을 위한 코드 템플릿에 연결할 수 있습니다.
- Microsoft AI Envisioning Day 이벤트
- Microsoft Marketplace용 AI 앱 및 에이전트를 구축하고 게시하는 방법
- ISV Success를 통해 앱을 복제하고 게시하는 데 도움이 되는 $126K USD 이상의 혜택 및 기술 컨설팅을 받으세요.