AI 추론 패턴
AI와 머신 러닝 기능이 모든 규모의 회사에서 혁신과 효율성을 촉진하는 데 중요한 것으로 여겨짐에 따라, 조직에서는 애플리케이션 개발자에게 이러한 기능에 대한 액세스를 제공하는 가장 좋은 방법을 결정해야 합니다. 많은 경우 AI 추론 서비스가 사용됩니다. 즉, "주어진 입력을 기반으로 출력을 생성하기 위해 AI 모델을 호출하는 서비스"(분류 예측 또는 텍스트 생성 등)이며, 일반적으로 다른 애플리케이션 코드의 API 호출에 대한 응답으로 사용됩니다.
이러한 추론 서비스는 (단일 조직 내에서도) 매우 다양한 방식으로 구축되고 소비될 수 있습니다. 이러한 서비스는 전적으로 자체적으로 개발할 수도 있고 SaaS로 사용할 수도 있으며, 오픈 소스 프로젝트를 활용하고 개방형 또는 상업적 모델을 사용할 수도 있습니다. 이러한 기능은 더 광범위한 데이터 과학 및 모델 생성 작업을 지원하는 완전한 기능을 갖춘 "머신 러닝 플랫폼"의 일부로 제공될 수도 있고, 모델을 호출하기 위한 API 엔드포인트만 제공할 수도 있습니다. 개인 데이터 센터, 퍼블릭 클라우드, 콜로케이션 시설에서 실행될 수도 있고 이러한 시설을 혼합한 형태로 실행될 수도 있습니다. 대규모 조직에서는 AI 추론을 위해 두 개 이상의 단일 옵션에 의존할 가능성이 높습니다(특히 이 분야에서 조직적 성숙도가 낮을수록 그렇습니다). 모든 사람에게 통용되는 단일 접근 방식은 없지만, 몇 가지 공통적인 패턴이 나타나고 있습니다.
패턴 개요
우리는 세 가지 광범위한 AI 추론 소비 패턴과 그 다양한 강점과 약점을 살펴볼 것입니다.
- SaaS로서의 AI 추론 – 애플리케이션은 외부 전담 AI 추론 서비스 공급자에 연결됩니다.
- 클라우드 관리형 AI 추론 – 애플리케이션은 퍼블릭 클라우드에서 실행되는 완전 관리형 AI 추론 서비스에 연결됩니다.
- 자체 관리형 AI 추론 – 애플리케이션은 조직 자체가 관리하는 AI 추론을 중앙 집중식 서비스의 일부로 사용하거나 애플리케이션 수준에서 직접 사용합니다.
주요 결정 사항
다음 운영 패턴 간의 균형을 평가할 때 염두에 두어야 할 몇 가지 핵심 요소가 있습니다.
운영 고려 사항
- 확장성 – 누가 책임을 져야 하며, 시간이 지남에 따라 용량 요구 사항이 변함에 따라 주어진 옵션이 얼마나 잘 확장되거나 축소됩니까? 수용 인원에 제한이나 상한이 있나요?
- 비용 – 완전 관리형 서비스는 언뜻 보기에 비용이 더 많이 드는 것처럼 보일 수 있지만 총 소유 비용(특수 하드웨어 및 인력 포함)을 고려하면 결정이 덜 명확해질 수 있습니다. 운영 비용은 용량이 늘어나거나 줄어들 때 어떻게 증가합니까? 비용에 한계가 있습니까?
- 유지 관리/지원 – 추론 서비스의 유지 관리를 담당하는 사람은 누구입니까? 귀하의 조직에서는 이 분야의 전문 지식을 갖춘 직원을 고용하거나 컨설턴트에게 급여를 지급해야 할까요, 아니면 관리형 서비스를 제공하는 것이 더 합리적일까요?
개발 고려 사항
- 워크로드 통합의 용이성 – AI 서비스를 소비 워크로드와 얼마나 빨리 통합할 수 있습니까? 서비스 제공이 예상 사용 패턴(예: 오프라인/일괄 추론) 및 운영 환경과 호환됩니까?
- 민첩성 – 전체 애플리케이션을 변화하는 비즈니스 요구 사항에 얼마나 빨리 적응시킬 수 있습니까? 아키텍처의 어떤 측면이 더 오래 전부터 자리 잡고 있어 변경하기 어려울까요?
성능 고려 사항
- 성능 – 서비스의 물리적 위치(서비스 소비자 대비)와 추론 지연 시간이 사용 사례에 중요합니까?
- 하드웨어 가용성 – 서비스에 대한 특별한 하드웨어 요구 사항이 있습니까? 있다면 예상 수요를 충족할 수 있는 용량이 있습니까(온프레미스 및 클라우드 환경 모두에 적용 가능)?
데이터 고려 사항
- 데이터 유출 – 중요한 데이터가 추론 서비스로 전송되거나 추론 결과에 포함될 수 있다는 우려가 있습니까? 그렇다면 교통을 점검하고 가드레일을 설치할 수 있을까요?
- 데이터 거버넌스 – 애플리케이션 데이터는 지리적으로 어디로 전송됩니까(그리고 어떻게)? 직접적인 통제권은 조직 내부에 있나요, 아니면 제3자에게 넘겨집니까? 데이터를 처리하는 방법에 적용되는 특별 규정이나 준수 정책이 있습니까?
SaaS 패턴
조직에서는 추론을 위한 AI 모델 호스팅에 중점을 둔 전담 SaaS 공급업체(예: OpenAI 또는 Cohere)의 서비스를 사용할 수 있습니다. 이 경우 조직의 인프라(개인 데이터 센터, 콜로케이션 또는 퍼블릭 클라우드)에서 실행되는 워크로드는 SaaS 제공자가 게시한 API를 활용합니다. 이 패턴을 사용하면 모델 호스팅에 필요한 인프라를 운영하는 데 따르는 부담이 전적으로 SaaS 제공업체에게 있으며, 구축하고 실행하는 데 걸리는 시간이 매우 짧을 수 있습니다. 하지만 이러한 이점은 통제력의 희생으로 제공되며, 이 패턴은 우리가 다룰 패턴 중에서 가장 "유연하지" 않습니다. 마찬가지로 이 모델에서는 민감한 데이터에 대한 통제가 일반적으로 가장 낮습니다. 이 모델에서는 일반적으로 공용 인터넷을 사용하여 서비스에 연결하고 외부 SaaS 공급업체가 엄격한 규정 준수 문제를 해결할 수 있는 가능성이 낮습니다.
매우 적합합니다
- 출시 시간: 신속한 프로토타입 제작, MVP 출시.
- 내부적으로 AI 추론에 대한 전문 지식/경험이 부족한 조직.
- 상당하거나 엄격한 데이터 보안/거버넌스 요구 사항이 없는 애플리케이션입니다.
강점
- 출시까지 걸리는 시간이 짧음: 운영 모델이 단순하면 통합 시간이 단축될 수 있습니다.
- 전문 서비스 제공업체는 추론 확장 문제를 해결하는 데 필요한 충분한 역량을 갖추고 있습니다.
- 특수 하드웨어나 인력에 대한 투자가 필요하지 않습니다.
도전 과제
- 앱 워크로드와 함께 배치된 서비스와 관련된 지연 및 연결 문제.
- 데이터 개인정보 보호, 거버넌스, 보안 문제는 외부 SaaS 공급자에 의존하거나 이와 호환되지 않을 수 있습니다.
- 더 큰 규모에서는 운영 비용이 셀프 호스팅 모델보다 더 높을 수 있습니다.
- 사용자 정의 모델 호스팅 및 모델 사용자 정의 서비스가 지원되지 않을 수 있습니다.
클라우드 관리 패턴
이 패턴에서 조직은 퍼블릭 클라우드 공급자(예: Azure OpenAI, Google Vertex, AWS Bedrock)가 제공하는 관리 서비스를 활용합니다. 첫 번째 패턴과 마찬가지로, AI 모델을 배포, 확장, 유지하는 데 따른 운영적 부담은 소비 조직이 아닌 클라우드 공급자에게 있습니다. 이 패턴과 위의 SaaS 패턴의 주요 차이점은 이 경우 추론 API 엔드포인트는 일반적으로 개인 네트워크를 통해 액세스할 수 있고 AI 소비자 워크로드는 AI 모델 서비스(예: 동일 영역, 지역)와 동일한 위치에 배치될 수 있다는 것입니다. 결과적으로 데이터는 일반적으로 공용 인터넷을 전송하지 않으며 대기 시간이 더 짧을 가능성이 높고 이러한 서비스에 연결하기 위한 메커니즘은 다른 클라우드 공급자 관리 서비스(예: 서비스 계정, 액세스 정책, 네트워크 ACL)와 유사합니다. 멀티 클라우드 네트워킹을 활용하는 조직은 워크로드와 AI 추론 서비스가 서로 다른 클라우드에 호스팅된 경우에도 동일한 이점 중 일부를 실현할 수 있습니다.
매우 적합합니다
- 기존에 퍼블릭 클라우드에 투자를 한 조직.
- 다른 클라우드 관리 서비스에서 실행되거나 연결되는 애플리케이션입니다.
강점
- 많은 조직에서는 이미 자사 워크로드를 다른 클라우드 공급자 관리 서비스(예: 데이터베이스, 개체 저장소 등)에 연결하는 데 익숙합니다.
- 모델을 실행하고 확장하는 데 따른 운영 및 인프라 부담은 주로 클라우드 제공업체에서 발생합니다.
- 지연 시간과 일부 데이터 개인정보 보호 문제는 해결하기가 더 쉬울 수 있습니다.
도전 과제
- 멀티/하이브리드 클라우드 애플리케이션을 연결하고 보안을 유지하려면 추가적인 노력이 필요합니다.
- 클라우드 관리 서비스와 API 전반에 걸쳐 균일성이 부족하면 공급업체에 종속될 수 있습니다.
- 광범위한 퍼블릭 클라우드를 갖추지 않은 조직은 어려움에 직면할 수 있습니다.
- 더 큰 규모에서는 운영 비용이 셀프 호스팅 모델보다 더 높을 수 있습니다.
- 사용자 정의 모델 호스팅 및 모델 사용자 정의 서비스가 지원되지 않을 수 있습니다.
자체 관리 패턴
자체 관리형 모델의 경우, 먼저 AI 모델 추론이 중앙 집중화된 "공유 서비스"로 실행되는 경우를 논의한 다음, 중앙 집중화된 서비스가 없고 운영상의 문제가 개별 애플리케이션 팀에 맡겨지는 경우를 살펴보겠습니다.
자체 관리, 공유 서비스
자체 관리 패턴의 "공유 서비스" 변형에서 조직은 추론 인프라, 이를 실행하는 모델, 이를 연결하는 데 사용되는 API 및 추론 서비스 수명 주기의 모든 운영 측면을 유지 관리하는 전담 팀을 가질 수 있습니다. 다른 패턴과 마찬가지로 AI 애플리케이션 워크로드는 API 호출을 통해 추론 서비스를 사용합니다. 인프라를 제공하는 모델은 개인 데이터 센터, 퍼블릭 클라우드 또는 콜로케이션 시설에서 실행될 수 있습니다. 추론 서비스를 운영하는 팀은 자체 호스팅 머신 러닝 플랫폼(예: Anyscale Ray 또는 MLFlow)을 활용할 수 있습니다. 혹은 Hugging Face의 텍스트 생성 추론 서버 나 자체적으로 개발한 소프트웨어와 같이 좀 더 좁은 범위에 초점을 맞춘 추론 제공 도구에 의존할 수도 있습니다. 자체 관리형 추론을 사용하면 조직에서는 직접 훈련한 모델이나 로컬에서 실행할 수 있는 모델만 사용할 수 있습니다(따라서 SaaS 지향 서비스의 독점 모델은 옵션이 아닐 수 있음).
매우 적합합니다
- 광범위한 인프라 관리 경험을 갖춘 성숙한 조직입니다.
- 자체 관리형 서비스의 TCO를 정당화할 만큼 높은 추론 요구 사항이 있는 조직.
- 가장 엄격한 데이터 개인정보 보호 및 규정 준수 요구 사항이 있는 애플리케이션입니다.
강점
- 조직은 추론 서비스의 모든 측면을 완벽하게 제어합니다.
- 데이터 개인 정보 보호 문제는 일반적으로 자체 호스팅 모델을 사용하면 가장 쉽게 해결할 수 있습니다.
- 대규모 비용은 클라우드 관리형 또는 SaaS 기반 추론 서비스보다 더 효율적일 수 있습니다.
도전 과제
- 조직은 추론 서비스의 모든 측면을 완벽하게 제어합니다(지속적인 유지 관리, 개발, 확장성 문제와 함께 대규모 인프라 및 인력 투자가 필요할 가능성이 높음).
- 최소한의 추론 요구 사항과 최소한의 데이터 개인정보 보호 문제가 있는 조직에는 일반적으로 비용 효율적이지 않습니다.
- SaaS 또는 클라우드 관리 서비스로 제공될 수 있는 폐쇄형/독점형 모델에 액세스할 수 없습니다.
자체 관리, 공유 서비스가 아님
애플리케이션에서 사용할 AI 추론 서비스를 실행하는 중앙 팀이 없는 조직은 자체 관리 패턴의 또 다른 변형입니다. 이 버전에서는 개별 애플리케이션 팀이 애플리케이션 워크로드에 할당된 것과 동일한 인프라에서 모델을 실행할 수 있습니다. 그들은 API를 통해 해당 모델에 액세스하거나 "오프라인" 방식으로 직접 사용할 수 있습니다. 이 패턴을 사용하면 개발자는 더 작은 규모에서 "공유 서비스" 자체 관리 모델과 동일한 이점 중 일부를 실현할 수 있습니다.
매우 적합합니다
- 일괄 처리 및 오프라인 추론이 필요한 애플리케이션.
- 추론 소비량이 매우 적지만 데이터 개인 정보 보호 및 규정 준수 요구 사항이 엄격한 조직입니다.
강점
- 애플리케이션 개발자에게 가장 유연한 환경을 제공하며, 작업 부하와의 통합을 위한 광범위한 가능성을 제공합니다.
- 소규모로 데이터 개인정보 보호 및 지연 시간 목표를 달성할 수 있습니다.
- 어떤 경우에는 논의된 다른 모델보다 비용 효율성이 더 높을 수 있습니다(예: 소비 요구 사항이 높은 단일 팀).
도전 과제
- 모델 수명 주기의 운영적 부담은 개별 애플리케이션 팀에 주어집니다.
- 조직의 AI 추론 소비가 증가함에 따라 규모의 경제를 활용하지 못함(일관성 부족, 비효율적인 리소스 활용 등)
패턴 트레이드오프 요약
AI 앱 및 모델 추론 서비스 보안
AI 애플리케이션은 근본적으로 다른 모든 최신 앱과 매우 유사합니다. 사용자 중심 및 백엔드 구성 요소를 혼합하여 구축되고, 종종 외부 데이터 저장소에 의존하고, API 호출을 많이 사용합니다. 이러한 애플리케이션은 모든 최신 앱에서 공통적으로 나타나는 동일한 보안 과제를 상속받으며 동일한 방식으로 동일한 보호 기능을 적용해야 합니다(예: AuthNZ, DDoS 보호, WAF, 안전한 개발 관행 등). 그러나 AI 앱, 특히 생성 AI를 활용하는 앱은 다른 애플리케이션에는 적용되지 않는 여러 가지 고유한 문제에 직면할 수도 있습니다(예: LLM을 위한 OWASP 상위 10개 참조). 일반적으로 이러한 모델의 예측 불가능한 특성은 새로운 문제로 이어질 수 있으며, 특히 모델에 상당한 권한이 부여된 사용 사례에서는 더욱 그렇습니다.
다행히도 위에서 설명한 패턴에서 AI 모델 추론을 통한 API 기반 상호작용에 크게 의존하기 때문에 많은 조직이 이러한 새로운 보안 조치를 구현할 좋은 위치에 이미 있습니다. 예를 들어, 기존의 속도 제한, 인증, 권한 부여 및 트래픽 관리 기능을 제공하는 API 게이트웨이는 비용 제어에 도움이 되는 토큰 기반 속도 제한을 지원하도록 확장될 수 있습니다(앱 수준에서 SaaS/공급자 관리 서비스로의 아웃바운드 또는 자체 관리 추론 서비스 앞에서 보호 기능으로 인바운드 RBAC 권한 부여). 마찬가지로, 현재 SQL 주입이나 XSS를 확인하는 것과 같은 기존 웹 애플리케이션 방화벽(WAF) 서비스를 수행하고 있는 인프라는 즉각적인 주입 및 이와 유사한 공격에 대한 보호 기능을 추가하는 데 논리적인 장소가 될 수 있습니다. 대부분의 최신 관찰성 관행은 API 기반 AI 추론 특정 사용 사례에 직접적으로 적용할 수 있으며, 팀은 이 분야의 기존 툴과 관행을 잘 활용할 수 있어야 합니다.
결론
AI 기반 애플리케이션과 추론 서비스를 둘러싼 화제는 분명 새로운 것이지만, 이를 배포하고 보안할 때 적용되는 기본 원칙은 오랫동안 존재해 왔습니다. 조직에서는 다른 기술을 사용할 때와 마찬가지로 AI 기능을 가장 잘 활용하는 방법을 결정하기 위해 특정 사용 사례, 사용 가능한 리소스, 장기 목표에 따라 균형을 맞춰야 합니다. 마찬가지로 AI(특히 생성 AI) 사용 사례가 몇 가지 새로운 보안 과제를 제시하더라도 다른 최신 애플리케이션과 동일한 요구 사항과 API 기반 모델 상호 작용에 대한 높은 의존도는 기존 패턴, 관행 및 도구를 사용하고 확장할 수 있는 좋은 기회를 제공합니다. 셀프 호스팅이든 관리형 서비스이든, 개발자가 특정 비즈니스 요구 사항을 충족하는 안전하고 확장 가능하며 성능이 뛰어난 솔루션에 액세스할 수 있도록 보장하는 것은 AI 투자의 가치와 효과를 극대화하는 데 중요합니다.