AI로 빌드하기 전에 호스팅할 플랫폼을 선택해야 합니다. 선택에 따라 AI 시스템의 속도, 비용, 확장성, 신뢰성이 달라집니다. 다음 중에서 선택할 수 있습니다.
- 클라이언트 측 AI: 브라우저에서 직접 실행됩니다. 즉, 데이터는 사용자의 기기에 비공개로 유지될 수 있으며 네트워크 지연 시간이 없습니다. 하지만 클라이언트 측 AI가 제대로 작동하려면 매우 구체적이고 잘 정의된 사용 사례가 필요합니다.
- 서버 측 AI: 클라우드에서 실행됩니다. 기능과 확장성이 뛰어나지만 지연 시간과 비용이 더 많이 듭니다.
각 옵션에는 장단점이 있으며, 적절한 설정은 사용 사례, 팀 기술, 리소스에 따라 다릅니다. 예를 들어 사용자가 개인 식별 정보 (PII)를 관리하지 않고도 개인적인 질문을 할 수 있도록 로컬에서 실행되는 요약 도구를 제공할 수 있습니다. 하지만 고객 지원 상담사는 리소스의 대규모 데이터베이스에 액세스할 수 있는 클라우드 기반 모델을 사용하여 더 유용한 답변을 제공할 수 있습니다.
이 모듈에서 학습할 내용은 다음과 같습니다.
- 클라이언트 측 AI와 서버 측 AI의 장단점을 비교합니다.
- 사용 사례 및 팀 역량에 맞는 플랫폼을 선택하세요.
- 클라이언트와 서버에서 AI를 제공하는 하이브리드 시스템을 설계하여 제품과 함께 성장하세요.
옵션 검토
배포의 경우 두 가지 기본 축을 따라 AI 플랫폼을 생각해 보세요. 다음 중에서 선택할 수 있습니다.
- 모델이 실행되는 위치: 클라이언트 측에서 실행되나요, 서버 측에서 실행되나요?
- 맞춤설정 가능성: 모델의 지식과 기능을 얼마나 제어할 수 있나요? 모델을 제어할 수 있는 경우(즉, 모델 가중치를 수정할 수 있는 경우) 특정 요구사항을 충족하도록 동작을 맞춤설정할 수 있습니다.
클라이언트 측 AI
클라이언트 측 AI는 브라우저에서 실행되며 계산은 사용자의 기기에서 로컬로 이루어집니다. 추론 시간 컴퓨팅을 제공할 필요가 없으며 데이터는 사용자 기기에 유지됩니다. 따라서 빠르고 비공개이며 가볍고 대화형 환경에 적합합니다.
하지만 클라이언트 측 모델은 일반적으로 크기가 작기 때문에 기능과 성능이 제한될 수 있습니다. 유해성 감지 또는 감정 분석과 같은 고도로 전문화된 작업에 가장 적합합니다. 이러한 작업은 출력 공간이 제한된 예측 AI 작업인 경우가 많습니다.
두 가지 주요 옵션이 있습니다.
- 내장 AI: Chrome, Microsoft Edge와 같은 브라우저가 AI 모델을 통합하고 있습니다. 이러한 기능은 JavaScript 호출을 통해 액세스할 수 있으며 설정이나 호스팅이 필요하지 않습니다. 모델이 다운로드되면 모델을 사용하는 모든 웹사이트에서 호출할 수 있습니다.
- 맞춤 모델: Transformers.js 및 MediaPipe와 같은 클라이언트 측 라이브러리를 사용하여 모델을 애플리케이션에 통합할 수 있습니다. 즉, 모델 가중치를 제어할 수 있습니다. 하지만 이는 웹사이트의 모든 사용자가 맞춤 모델을 다운로드해야 한다는 의미이기도 합니다. 웹사이트의 맥락에서 가장 작은 AI 모델도 크기 때문입니다.
서버 측 AI
서버 측 AI를 사용하면 웹 애플리케이션이 API를 호출하여 AI 모델에 입력을 보내고 출력을 수신합니다. 이 설정은 더 크고 복잡한 모델을 지원하며 사용자 하드웨어와는 독립적입니다.
서버 측 AI의 두 가지 카테고리는 다음과 같습니다.
- 관리형 서비스: Gemini 3, GPT-5와 같은 서드 파티가 데이터 센터에서 호스팅하는 모델입니다. 모델 소유자는 액세스할 수 있는 API를 제공합니다. 즉, 최소한의 설정으로 최첨단 모델을 사용할 수 있습니다. 빠른 프로토타입 제작, 개방형 대화, 범용 추론에 적합합니다. 하지만 관리형 서비스에서 확장하는 데는 비용이 많이 들 수 있습니다.
- 자체 호스팅 모델: Gemma 또는 Llama와 같은 오픈 가중치 모델을 자체 인프라 또는 Vertex AI 또는 Hugging Face Inference와 같은 관리형 컨테이너에 배포할 수 있습니다. 이 접근 방식을 사용하면 모델 생성자가 수행한 사전 학습의 이점을 누리면서 모델, 파인 튜닝 데이터, 성능을 제어할 수 있습니다.
초기 플랫폼 선택
AI 플랫폼의 아키텍처 특성을 검토하고 절충안을 분석하여 초기 설정을 결정합니다.
아키텍처 요구사항 정의
모든 결정에는 타협이 필요합니다. AI 플랫폼의 비용과 가치를 정의하는 주요 특징을 살펴보세요.
- 모델 성능: 조정 없이 다양한 사용자 및 작업에서 모델이 얼마나 잘 작동하는지입니다. 이는 모델 크기와 상관관계가 있는 경우가 많습니다.
- 맞춤설정 가능성: 모델 동작 및 아키텍처를 미세 조정, 수정 또는 제어할 수 있는 정도입니다.
- 정확성: 모델의 예측 또는 생성의 전반적인 품질과 신뢰성입니다.
- 개인 정보 보호: 사용자 데이터가 로컬에 유지되고 사용자 제어 하에 있는 정도입니다.
- 고정 비용: 사용량과 관계없이 AI 시스템을 운영하는 데 필요한 반복 비용입니다(인프라 프로비저닝 및 유지관리 포함).
- 요청당 비용: 수신되는 각 요청의 추가 비용입니다.
- 호환성: 대체 로직 없이 브라우저, 기기, 환경에서 접근 방식이 얼마나 광범위하게 작동하는지입니다.
- 사용자 편의성: 사용자가 모델을 다운로드하는 등 AI 시스템을 사용하기 위해 추가 단계를 거쳐야 하는지 여부
- 개발자 편의성: 전문 AI 지식이 없는 대부분의 개발자가 모델을 배포, 통합, 유지관리하는 것이 얼마나 빠르고 쉬운가.
다음 표는 각 기준에 대해 각 플랫폼이 얼마나 잘 작동하는지 추정한 예를 보여줍니다. 1이 가장 낮고 5가 가장 높습니다.
| 기준 | 클라이언트 | 서버 | ||
| 내장 AI 또는 온디바이스 | 맞춤 모델 | 관리형 서비스 | 자체 호스팅 모델 | |
| 모델 전원 |
모델 전원에 별 2개를 준 이유는 무엇인가요?내장 및 온디바이스 AI는 개방형 대화나 추론이 아닌 좁은 작업별 기능에 최적화된 작은 사전 로드 브라우저 모델을 사용합니다. |
모델 성능에 별 3개를 준 이유는 무엇인가요?맞춤 클라이언트 측 라이브러리는 내장 AI보다 유연성이 높지만 다운로드 크기, 메모리 제한, 사용자 하드웨어의 제약을 받습니다. |
모델 성능에 별 4개를 준 이유는 무엇인가요?관리형 서비스와 자체 호스팅을 사용하면 복잡한 추론, 긴 컨텍스트 처리, 광범위한 작업 처리가 가능한 대규모 최첨단 모델에 액세스할 수 있습니다. |
|
| 맞춤설정 가능성 |
맞춤설정 가능성에 별 1개를 준 이유는 무엇인가요?기본 제공 모델은 모델 가중치 또는 학습 데이터에 대한 액세스를 허용하지 않습니다. 동작을 맞춤설정하는 기본 방법은 프롬프트 엔지니어링입니다. |
맞춤설정 가능성에 별 5개를 준 이유는 무엇인가요?이 옵션을 사용하면 모델 선택과 가중치를 제어할 수 있습니다. 많은 클라이언트 측 라이브러리에서 모델 미세 조정 및 학습도 허용합니다. |
맞춤설정 가능성에 별 1개를 준 이유는 무엇인가요?관리형 서비스는 강력한 모델을 노출하지만 내부 동작에 대한 제어는 최소한으로 제공합니다. 맞춤설정은 일반적으로 프롬프트 및 입력 컨텍스트로 제한됩니다. |
맞춤설정에 별 5개를 준 이유는 무엇인가요?자체 호스팅 모델은 모델 가중치, 학습 데이터, 파인 튜닝, 배포 구성을 완전히 제어할 수 있습니다. |
| 정확성 |
정확성이 2점인 이유는 무엇인가요?내장 모델의 정확도는 범위가 잘 지정된 작업에는 충분하지만 모델 크기와 일반화가 제한되어 복잡하거나 미묘한 입력의 신뢰성이 떨어집니다. |
정확성 별점이 3개인 이유는 무엇인가요?모델 선택 과정에서 맞춤 클라이언트 측 모델 정확도를 개선할 수 있습니다. 하지만 모델 크기, 양자화, 클라이언트 하드웨어 변동성에 의해 제한됩니다. |
정확성에 별 5개를 준 이유는 무엇인가요?관리형 서비스는 일반적으로 대규모 모델, 광범위한 학습 데이터, 지속적인 제공업체 개선의 이점을 활용하여 비교적 높은 정확도를 제공합니다. |
정확성에서 별 4개를 준 이유는 무엇인가요?정확도는 높을 수 있지만 선택한 모델과 조정 노력에 따라 달라집니다. 성능이 관리형 서비스보다 뒤처질 수 있습니다. |
| 네트워크 지연 시간 |
네트워크 지연 시간에 별 5개를 준 이유는 무엇인가요?처리는 사용자의 기기에서 직접 이루어집니다. |
네트워크 지연에 별 2개를 준 이유는 무엇인가요?서버로의 왕복이 있습니다. |
||
| 개인 정보 보호 |
개인 정보 보호에 별 5개를 준 이유는 무엇인가요?사용자 데이터는 기본적으로 기기에 남아 있어야 데이터 노출을 최소화하고 개인 정보 보호 규정 준수를 간소화할 수 있습니다. |
개인 정보 보호에 별 2개를 준 이유는 무엇인가요?사용자 입력을 외부 서버로 전송해야 하므로 데이터 노출 및 규정 준수 요구사항이 증가합니다. 하지만 비공개 AI 컴퓨팅과 같은 개인 정보 보호 문제를 완화하는 특정 솔루션이 있습니다. |
개인 정보 보호에 별 3개를 준 이유는 무엇인가요?데이터는 조직의 관리 하에 유지되지만 사용자의 기기를 벗어나므로 안전한 처리 및 규정 준수 조치가 필요합니다. |
|
| 고정 비용 |
고정 비용에 별 5개를 부여한 이유는 무엇인가요?모델은 사용자의 기존 기기에서 실행되므로 추가 인프라 비용이 발생하지 않습니다. |
고정 비용에 별 5개를 부여한 이유는 무엇인가요?대부분의 API는 사용량에 따라 요금이 청구되므로 고정 비용이 없습니다. |
고정 비용에 별 2개가 표시되는 이유는 무엇인가요?고정비에는 인프라, 유지관리, 운영 오버헤드가 포함됩니다. |
|
| 요청당 비용 |
비용 대비 요청에 별 5개를 부여한 이유는 무엇인가요?추론은 사용자 기기에서 실행되므로 요청별 비용이 없습니다. |
비용 대비 요청에 별 2개가 부여된 이유는 무엇인가요?관리형 서비스는 요청당 가격 책정 방식인 경우가 많습니다. 특히 트래픽이 많은 경우 확장 비용이 상당할 수 있습니다. |
비용 대비 요청에 별 3개를 부여한 이유는 무엇인가요?요청당 직접 비용이 없습니다. 효과적인 요청당 비용은 인프라 사용률에 따라 달라집니다. |
|
| 호환성 |
호환성에 별 2개를 준 이유는 무엇인가요?지원 여부는 브라우저와 기기에 따라 다르므로 지원되지 않는 환경을 위한 대체가 필요합니다. |
호환성에 별 1개를 준 이유는 무엇인가요?호환성은 하드웨어 기능과 런타임 지원에 따라 달라 기기 간 지원이 제한됩니다. |
호환성에 별 5개를 준 이유는 무엇인가요?서버 측 플랫폼은 추론이 서버 측에서 이루어지고 클라이언트는 API만 사용하므로 모든 사용자와 광범위하게 호환됩니다. |
|
| 사용자 편의성 |
사용자 편의성에 별 3개를 준 이유는 무엇인가요?일반적으로 사용 가능해지면 원활하게 작동하지만, 내장 AI를 사용하려면 초기 모델 다운로드와 브라우저 지원이 필요합니다. |
사용자 편의성이 2점인 이유는 무엇인가요?다운로드 또는 지원되지 않는 하드웨어로 인해 지연이 발생할 수 있습니다. |
사용자 편의성이 4점인 이유는 무엇인가요?다운로드나 기기 요구사항 없이 즉시 작동하여 원활한 사용자 환경을 제공합니다. 하지만 네트워크 연결이 약한 경우 지연이 발생할 수 있습니다. |
|
| 개발자 편의성 |
개발자 편의성에 별 5개를 준 이유는 무엇인가요?기본 제공 AI는 설정이 최소화되어 있고 인프라가 필요하지 않으며 AI 전문 지식이 거의 필요하지 않아 통합 및 유지관리가 쉽습니다. |
개발자 편의성에 별 2개를 준 이유는 무엇인가요?기기 전반에서 모델, 런타임, 성능 최적화, 호환성을 관리해야 합니다. |
개발자 편의를 위해 별 4개를 준 이유는 무엇인가요?관리형 서비스를 사용하면 배포와 확장이 간소화됩니다. 하지만 API 통합, 비용 관리, 프롬프트 엔지니어링은 여전히 필요합니다. |
개발자 편의성에 별 1개를 준 이유는 무엇인가요?맞춤 서버 측 배포에는 인프라, 모델 관리, 모니터링, 최적화에 대한 상당한 전문성이 필요합니다. |
| 유지보수 노력 |
유지보수 노력에 별 4개를 준 이유는 무엇인가요?브라우저에서 모델 업데이트와 최적화를 처리하지만 개발자는 변경되는 사용 가능 여부에 적응해야 합니다. |
유지보수 노력에 별 2개를 준 이유는 무엇인가요?브라우저와 기기가 발전함에 따라 모델, 성능 조정, 호환성을 지속적으로 업데이트해야 합니다. |
유지보수 노력에 별 5개를 준 이유는 무엇인가요?유지보수는 제공업체에서 처리합니다. |
유지보수 노력에 별 2개를 준 이유는 무엇인가요?모델 업데이트, 인프라 관리, 확장, 보안 등 지속적인 유지보수가 필요합니다. |
장단점 분석
의사결정 프로세스를 설명하기 위해 중소 규모 전자상거래 플랫폼인 Example Shoppe에 다른 기능을 추가해 보겠습니다. 근무 외 시간의 고객 서비스 비용을 절감하는 데 관심이 있어 주문, 반품, 제품에 관한 사용자 질문에 답변하는 AI 기반 어시스턴트를 빌드하기로 결정합니다.
기회와 솔루션을 보여주는 전체 AI 시스템 청사진을 검토할 수 있습니다.
사용 사례 요구사항과 비즈니스 또는 팀 제약 조건이라는 두 가지 관점에서 시나리오를 분석합니다.
| 요구사항 | 분석 | 기준 | 의미 |
| 높은 정확성과 다재다능함 | 사용자는 주문, 제품, 반품에 관해 다양한 복잡한 질문을 합니다. | 모델 성능, 정확도 | 대규모 언어 모델 (LLM)이 필요합니다. |
| 데이터 구체성 | 회사 데이터, 제품, 정책과 관련된 질문에 답변해야 합니다. | 맞춤성 | 모델 미세 조정이 아닌 RAG와 같은 데이터 수집이 필요합니다. |
| 요구사항 | 분석 | 기준 | 의미 |
| 사용자층 | 수십만 명의 사용자 | 확장성, 호환성 | 높고 안정적인 트래픽을 처리하는 아키텍처가 필요합니다. |
| 출시 후 중점 | 팀은 버전 1 출시 후 다른 프로젝트로 이동합니다. | 유지보수 노력 | 지속적인 유지관리가 최소화된 솔루션이 필요합니다. |
| 팀 전문성 | 웹 개발 경험이 풍부하지만 AI/ML 전문 지식이 제한적인 경우 | 개발자 편의성 | 솔루션은 전문 AI 기술 없이 쉽게 배포하고 통합할 수 있어야 합니다. |
이제 기준의 우선순위를 지정했으므로 절충안 추정 표를 참고하여 최우선 기준에 맞는 플랫폼을 확인할 수 있습니다.
| 우선순위가 지정된 기준 | 플랫폼 승자 |
| 모델 전원 | 서버 측 |
| 맞춤성 | 서버 측: 자체 호스팅 모델 |
| 개발자 편의성 | 서버 측: 관리형 서비스 |
| 유지보수 노력 | 서버 측: 관리형 서비스 |
| 호환성 및 확장성 | 서버 측 |
이 분석을 통해 서버 측 AI와 관리 서비스를 사용하는 것이 좋다는 것을 알 수 있습니다. 이를 통해 복잡한 고객 질문에 대한 다재다능한 모델을 제공할 수 있습니다. 인프라, 모델 품질, 가동시간을 제공업체에 오프로딩하여 유지보수 및 개발 노력을 최소화합니다.
맞춤설정은 제한적이지만 모델 엔지니어링 경험이 제한적인 웹 개발팀에게는 가치 있는 절충안입니다.
검색 증강 생성 (RAG) 설정을 사용하면 추론 시 모델에 관련 컨텍스트를 제공할 수 있습니다.
하이브리드 AI
성숙한 AI 시스템은 단일 플랫폼이나 단일 모델에서 실행되는 경우가 거의 없습니다. 대신 트레이드오프를 최적화하기 위해 AI 워크로드를 분산합니다.
하이브리드 AI 기회 포착
출시 후에는 실제 데이터와 의견을 바탕으로 요구사항을 개선해야 합니다. 예를 들어 Example Shoppe의 경우 몇 개월 동안 기다려 결과를 분석한 후 다음과 같은 결과를 확인합니다.
- 요청의 약 80% 가 반복됩니다 ('내 주문은 어디에 있나요?', '이 상품을 어떻게 반품해야 하지?') 이러한 요청을 관리형 서비스로 전송하면 오버헤드와 비용이 많이 발생합니다.
- 요청의 20% 만 심층적인 추론과 개방형 대화가 필요합니다.
경량 로컬 모델은 사용자 입력을 분류하고 '환불 정책이 뭐야?'와 같은 일상적인 질문에 답변할 수 있습니다. 복잡하거나 드물거나 모호한 질문은 서버 측 모델로 라우팅할 수 있습니다.
서버 측 AI와 클라이언트 측 AI를 모두 구현하면 필요할 때 강력한 추론에 액세스할 수 있는 동시에 비용과 지연 시간을 줄일 수 있습니다.
워크로드 분산
Example Shoppe의 이 하이브리드 시스템을 빌드하려면 먼저 기본 시스템을 정의해야 합니다. 이 경우 클라이언트 측에서 시작하는 것이 좋습니다. 애플리케이션은 다음 두 가지 경우에 서버 측 AI로 라우팅해야 합니다.
- 호환성 기반 대체: 사용자의 기기 또는 브라우저에서 요청을 처리할 수 없는 경우 서버로 대체해야 합니다.
- 기능 기반 에스컬레이션: 사전 정의된 기준에 따라 요청이 너무 복잡하거나 클라이언트 측 모델에 적합하지 않은 경우 더 큰 서버 측 모델로 에스컬레이션해야 합니다. 모델을 사용하여 요청을 일반적인 요청으로 분류하여 클라이언트 측에서 작업을 실행하거나, 일반적이지 않은 요청으로 분류하여 서버 측 시스템으로 요청을 보낼 수 있습니다. 예를 들어 클라이언트 측 모델에서 질문이 다른 통화로 환불받는 것과 같은 일반적이지 않은 문제와 관련이 있다고 판단하는 경우입니다.
유연성으로 인해 복잡성이 증가함
두 플랫폼 간에 워크로드를 분산하면 유연성이 높아지지만 복잡성도 증가합니다.
- 오케스트레이션: 실행 환경이 두 개이므로 이동하는 부분이 더 많습니다. 라우팅, 재시도, 대체에 관한 로직이 필요합니다.
- 버전 관리: 여러 플랫폼에서 동일한 모델을 사용하는 경우 두 환경 모두에서 호환되어야 합니다.
- 프롬프트 엔지니어링 및 컨텍스트 엔지니어링: 플랫폼마다 다른 모델을 사용하는 경우 각 모델에 대해 프롬프트 엔지니어링을 실행해야 합니다.
- 모니터링: 로그와 측정항목이 분리되어 있어 통합을 위한 추가 노력이 필요합니다.
- 보안: 두 개의 공격 표면을 유지합니다. 로컬 및 클라우드 엔드포인트 모두 강화해야 합니다.
이것도 고려해야 할 또 다른 절충안입니다. 소규모 팀이거나 필수가 아닌 기능을 빌드하는 경우 이러한 복잡성을 추가하지 않는 것이 좋습니다.
핵심 내용
플랫폼 선택은 계속해서 바뀔 수 있습니다. 사용 사례에서 시작하여 팀의 경험과 리소스에 맞게 조정하고 제품과 AI 성숙도가 높아짐에 따라 반복하세요. 사용자에게 적합한 속도, 개인 정보 보호, 제어 기능을 찾아 유연하게 빌드하는 것이 여러분의 과제입니다. 이렇게 하면 변화하는 요구사항에 적응하고 향후 플랫폼 및 모델 업데이트의 이점을 누릴 수 있습니다.
리소스
- 플랫폼과 모델 선택은 상호 의존적이므로 모델 선택에 대해 자세히 알아보세요.
- 하이브리드 및 클라이언트 측 AI로 클라우드를 넘어 확장하는 방법 알아보기
이해도 확인
애플리케이션용 AI 플랫폼을 선택할 때 두 가지 주요 고려사항은 무엇인가요?
Gemini Pro와 같은 서버 측 관리 서비스가 플랫폼에 가장 적합한 경우는 언제인가요?
하이브리드 AI 시스템을 구현할 때 얻을 수 있는 주요 이점은 무엇인가요?