AI 추론 패턴

Chris Hain

AI 및 머신 러닝 역량이 모든 규모의 기업에서 혁신과 효율성을 촉진하는 데 필수적인 요소로 점점 더 중요하게 인식됨에 따라, 조직은 애플리케이션 개발자가 이러한 역량을 활용할 수 있도록 지원하는 최적의 방법을 결정해야 합니다. 많은 경우 AI 추론 서비스가 사용됩니다. AI 추론 서비스란 “주어진 입력을 바탕으로 AI 모델을 호출하여 결과를 생성하는 서비스”(예: 분류 예측 또는 텍스트 생성)로, 일반적으로 다른 애플리케이션 코드의 API 호출에 응답하는 방식으로 작동합니다.

이러한 추론 서비스는 매우 다양한 방식으로 구축하고 사용할 수 있습니다(단일 조직 내에서도 마찬가지입니다). 서비스 전체를 자체 개발하거나 SaaS 형태로 이용할 수 있으며, 오픈 소스 프로젝트를 활용하고 공개 또는 상용 모델을 사용할 수도 있습니다. 광범위한 데이터 과학 및 모델 개발 작업을 지원하는 완전한 기능의 ‘머신 러닝 플랫폼’에 포함되어 제공될 수도 있고, 모델을 호출하기 위한 API 엔드포인트만 제공될 수도 있습니다. 또한 프라이빗 데이터 센터, 퍼블릭 클라우드, 코로케이션 시설 또는 이들을 혼합한 환경에서 실행될 수 있습니다. 대규모 조직은 AI 추론을 위해 두 가지 이상의 옵션을 활용할 가능성이 높습니다(특히 이 분야에 대한 조직의 성숙도가 낮은 단계일수록 그렇습니다). 모두에게 적합한 단 하나의 접근 방식은 없지만, 몇 가지 공통적인 패턴이 나타나고 있습니다.

패턴 개요

세 가지 주요 AI 추론 사용 패턴과 각 패턴의 다양한 장단점을 살펴보겠습니다:

1. SaaS형 AI 추론 – 애플리케이션이 외부의 전문 AI 추론 서비스 제공업체에 연결됩니다.
2. 클라우드 관리형 AI 추론 – 애플리케이션은 퍼블릭 클라우드에서 실행되는 완전 관리형 AI 추론 서비스에 연결됩니다.
3. 자체 관리형 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의 Text Generation Inference 서버와 같이 추론 서빙에 보다 특화된 도구나 사내에서 개발한 소프트웨어를 사용할 수도 있습니다. 자체 관리형 추론을 사용하는 조직은 직접 학습했거나 로컬에서 실행할 수 있는 모델만 사용할 수 있습니다. 따라서 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 투자 가치와 효과를 극대화하는 데 매우 중요합니다.

작성자 소개

Chris Hain

Chris Hain의 다른 블로그 게시물