AWS에서 오픈 모델 (Open Models)을 직접 호스팅하는 데 드는 비용은 얼마인가?
요약
오픈 모델을 AWS 등 자체 인프라에서 호스팅할 때 발생하는 비용과 하드웨어 요구사항을 분석합니다. GPU 메모리의 중요성과 vLLM 같은 서빙 소프트웨어를 활용한 효율적인 추론 스택 구축 방법을 다룹니다.
핵심 포인트
- 오픈 모델 전환 시 최대 70%의 비용 절감 가능
- 추론 성능의 핵심은 CPU가 아닌 GPU 메모리 대역폭과 병렬 처리
- vLLM과 같은 오픈 소스 추론 엔진을 통한 프로덕션 환경 구축 가능
- 모델 크기에 따른 하드웨어 스택 및 GPU 메모리 확보 필수
지난 분기에 AI 비용이 세 배로 늘었습니다. CTO는 오픈 모델 (open models)로 전환하여 70%를 절감한 기업들에 관한 기사를 당신에게 전달했습니다. 이제 누군가가 당신에게 그것이 실제로 어떤 모습일지 파악해 보라고 요청하고 있습니다.
저는 지난 몇 주 동안 이 문제를 깊이 파고들었습니다. 수치, 하드웨어, 그리고 실제 트레이드오프 (trade-offs)를 조사했습니다. 단순히 "오픈 소스가 미래다"라는 식의 생각 위주의 글에 고개를 끄덕이는 수준을 넘어, 당신이 실제로 결정을 내릴 수 있을 만큼 충분히 구체적인 내용을 아래에 정리했습니다.
"오픈 모델 (Open Models)"이 실제로 의미하는 것
누군가 "오픈 모델 (open model)"이라고 말할 때, 그것은 가중치 (weights, 모델을 작동하게 만드는 학습된 파라미터)를 공개적으로 다운로드할 수 있는 AI 모델을 의미합니다. 파일을 가져와 자신의 하드웨어에서 실행하면, 요청당 비용을 누구에게도 지불하지 않습니다.
현재 가장 유명한 이름들: Meta의 Llama 4, DeepSeek V4, Zhipu의 GLM-5.2, Moonshot의 Kimi K3, Alibaba의 Qwen 3.5, 그리고 Google의 Gemma 4.
이것들은 장난감이 아닙니다. 이들 중 일부는 실제 벤치마크 (benchmarks)에서 프런티어 모델 (frontier models)과 진정으로 경쟁합니다. 중국의 오픈 모델들은 OpenRouter에서의 기업 트래픽 중 30% 이상을 처리하고 있으며, 이는 2025년 초 4.5%에서 상승한 수치입니다. 이는 불과 1년 만에 일어난 거대한 변화입니다.
아키텍처 (Architecture): 실제로 필요한 것
당신의 팀이 오픈 모델을 사용하기를 원한다면, 아래는 바닥부터 꼭대기까지의 스택 (stack)입니다.
하드웨어 (Hardware, 비용이 많이 드는 부분)
모델은 거대한 파일입니다. 양자화 (quantized)된 작은 7B 모델의 4GB부터 Kimi K3의 전체 가중치인 1.5TB까지의 범위를 말하고 있습니다. 빠르게 실행하려면 파일 전체가 GPU 메모리 (GPU memory)에 있어야 합니다.
왜 특히 GPU 메모리인가요? 응답의 각 단어를 생성하려면 수십억 번의 곱셈 및 덧셈 연산이 필요하기 때문입니다. GPU는 이러한 연산을 수천 개씩 병렬로 수행합니다. CPU는 이를 한 번에 하나씩 수행합니다.
실질적인 차이는 다음과 같습니다: CPU에서 7B 모델을 사용하면 초당 25개의 토큰을 생성합니다 (대화형 사용에는 고통스러울 정도로 느립니다). 동일한 모델을 GPU에서 실행하면 초당 3080개의 토큰을 생성합니다 (즉각적인 느낌을 줍니다). CPU를 사용하는 한 명의 사용자에게는 참을 만할 수도 있습니다. 하지만 10명의 팀원이 모두 동일한 엔드포인트(endpoint)에 접속한다면 어떨까요? 사용이 불가능합니다. 요청이 대기열에 쌓이고 모든 사람이 응답을 받기 위해 30~60초를 기다려야 합니다.
이를 고속도로에 비유해 보세요. CPU는 속도 제한이 높은 단일 차선입니다. GPU는 적당한 속도로 달리는 4,000개의 차선입니다. 언어 모델 추론 (Inference)은 속도의 문제가 아니라 교통량의 문제입니다. 당신에게 필요한 것은 더 빠른 자동차가 아니라 더 많은 차선입니다.
서빙 소프트웨어 (무료 부분)
좋은 소식은 소프트웨어 스택이 성숙해 있고, 오픈 소스이며, 지금 바로 작동한다는 점입니다. 별도의 커스텀 코드가 필요하지 않습니다.
- vLLM: 추론 엔진 (Inference engine) 용입니다. 모델을 로드하고, 동시 요청을 처리하며, GPU 활용도를 최적화하고, OpenAI 호환 API를 제공합니다. 프로덕션 (Production) 환경에서의 업계 표준입니다.
- Open WebUI: ChatGPT와 유사한 브라우저 인터페이스를 제공합니다. 사용자 계정, 대화 기록, 파일 업로드 기능을 갖추고 있습니다. 팀원들은 상용 제품과 차이를 느끼지 못할 것입니다.
- 인증, TLS 종료 (TLS termination), 그리고 속도 제한 (Rate limiting)을 위해 앞단에 nginx 또는 Caddy를 배치합니다.
설정 방법: vLLM을 설치하고, vllm serve meta-llama/Llama-4-Maverick을 실행한 뒤, Open WebUI를 해당 엔드포인트로 지정하고 팀원들에게 URL을 전달하면 됩니다. Linux에 익숙한 사람이라면 하루 만에 끝낼 수 있는 작업입니다. vLLM API는 OpenAI와 호환되므로, OpenAI API로 작동하는 모든 도구, 확장 프로그램 또는 스크립트를 코드 변경 없이 그대로 사용할 수 있습니다. 엔드포인트 URL만 교체하면 됩니다.
모델
단 한 줄의 명령어로 Hugging Face에서 다운로드할 수 있습니다. 모델은 다양한 양자화 (Quantization) 수준(압축과 성능 사이의 절충안)으로 제공됩니다. 4비트 양자화 버전은 품질 저하가 미미하면서도 전체 정밀도 (Full-precision) 버전보다 대략 4배 더 작습니다. 대부분의 팀 사용 사례에서는 양자화 버전이 더 적은 GPU 메모리에 적합하기 때문에 실질적인 선택지가 됩니다.
비용 상세 내역
이제 본격적인 이야기가 시작됩니다. 2026년 8월 기준 AWS 온디맨드 (On-demand) 가격을 사용합니다.
시나리오 1: 10명 규모의 팀
10명 규모라면 모든 사람이 API 또는 웹 UI를 통해 접속할 수 있는 단일 추론 (Inference) 서버가 필요합니다. 가장 적합한 모델은 Llama 4 Maverick (400B 파라미터, MoE 아키텍처, 하지만 요청당 활성 파라미터는 약 17B)입니다. 이는 Meta의 모델 (미국 원산, 커뮤니티 라이선스)로, 강력한 올라운더이며 4개의 GPU가 장착된 단일 노드에서 실행됩니다.
| 설정 | AWS 인스턴스 | 월간 비용 (업무 시간) | 월간 비용 (24/7) |
|---|---|---|---|
| 저예산 (Qwen 3.5-27B) | g5.2xlarge (1x A10G) | ~$440 | ~$1,460 |
| ... |
업무 시간 활용 전략이 핵심적인 비용 절감 방법입니다. 팀이 평일 기준 하루 10시간 근무한다면, 730시간 대신 월 약 220시간만큼만 비용을 지불하면 됩니다. Lambda 또는 EventBridge 스케줄러를 설정하여 밤에는 인스턴스를 중지하고 매일 아침 시작하도록 만드세요. 이 단 하나의 최적화만으로 청구 금액의 70%를 줄일 수 있습니다.
Maverick에 왜 4개의 GPU가 필요할까요? 이 모델은 총 400B 파라미터를 가지고 있습니다. 요청당 17B만 활성화되더라도 400B 전체가 메모리에 올라가 있어야 합니다. 각 A10G는 24GB의 VRAM을 가집니다. 4개를 사용하면 총 96GB가 되며, 이는 요청 배치 (Batching)를 위한 여유 공간을 남겨두면서 양자화 (Quantized)된 Maverick 모델을 여유롭게 수용하기에 충분한 용량입니다.
시나리오 2: 500명 규모의 기업
500명 규모에서는 병목 현상이 동시 요청 (Concurrent requests)에서 발생합니다. 회사 인원의 1015%가 동시에 모델을 사용한다면, 이는 5075개의 동시 요청에 해당합니다. 서버 한 대로는 감당할 수 없습니다. 로드 밸런서 (Load balancer) 뒤에 3~4개의 복제본 (Replicas)이 필요합니다.
| 설정 | 월간 비용 |
|---|---|
| 저예산 (업무 시간, 예약 인스턴스, 피크 시 일부 대기열 발생) | $3,500-5,000 |
| ... |
비교를 위해: ChatGPT Enterprise 500개 계정은 월 약 $30,000가 소요됩니다. 500명이 적당한 사용량(1인당 하루 50회 요청)으로 Claude API를 호출할 경우 월 $6,000-12,000가 소요됩니다. 자체 호스팅 (Self-hosted) 경로는 이 규모에서 경쟁력이 있으며, 추가로 데이터 주권 (Data sovereignty)까지 확보할 수 있습니다.
숨겨진 비용을 잊지 마세요. 누군가(또는 소규모 팀)가 이를 계속 운영해야 합니다. 모델 업데이트, 인스턴스 재부팅, 모니터링 (Monitoring), 스케일링 조정 (Scaling adjustments) 등이 필요합니다. 사용자 500명 규모라면 정당화될 수 있지만, 10명 규모라면 가치보다 번거로움이 더 클 수 있습니다.
(가격은 2026년 8월 AWS 온디맨드 (On-demand) 요금을 기준으로 합니다. 최신 수치는 EC2 가격 페이지에서 확인하세요.)
사람들이 전환하고 있는 모델들
이 대화가 시의적절한 이유가 여기에 있습니다. 오픈 모델 (Open models)과 폐쇄형 모델 (Closed models) 사이의 격차가 무너졌습니다. 2023년 말에는 표준 벤치마크 (Benchmarks)에서 17.5%포인트 차이가 났습니다. 2026년 중반에 이르러서는 대부분의 작업에서 한 자릿수 차이로 좁혀졌으며, 지식 벤치마크 (Knowledge benchmarks)에서는 사실상 차이가 없습니다.
현재 가장 강력한 경쟁자들은 다음과 같습니다:
DeepSeek V4 Pro는 SWE-Bench Verified에서 80.6점을 기록하며 코딩 작업에서 프런티어 (Frontier) 모델과 대등한 성능을 보여줍니다. MIT 라이선스이며, 중국 연구소에서 개발되었습니다.
GLM-5.2 (Zhipu AI)는 일부 코딩 벤치마크에서 Claude Opus를 능가하면서도 비용은 46% 수준입니다. MIT 라이선스이며, 최상위권 오픈 모델 중 가장 빠른 처리량 (Throughput)을 자랑합니다.
Kimi K3 (Moonshot)는 2.8조 개의 파라미터 (Parameter)를 가진 괴물 같은 모델입니다. 프런티어에 근접한 품질을 제공합니다. API를 통해 입력 토큰 100만 개당 3달러에 이용 가능합니다. 이를 셀프 호스팅 (Self-hosting)하려면 8개 이상의 NVIDIA B300 GPU가 필요하며 월 비용이 7만 달러 이상 발생하므로, 대부분의 조직에게는 전혀 합리적이지 않습니다. 대신 API를 사용하세요.
그럼에도 불구하고, 만약 AWS에서 Kimi K3를 직접 호스팅하고 싶다면, 이제 방법이 문서화되어 있습니다. AWS는 Amazon SageMaker HyperPod 및 Amazon EKS에 Kimi K3를 배포하기 위한 단계별 가이드를 게시했습니다. 인프라는 다음과 같습니다: vLLM을 서빙 엔진 (Serving engine)으로 사용하는 p6-b300 인스턴스 (8x NVIDIA B300 Blackwell Ultra GPU), GPU 예약(Reservation)을 위한 유연한 트레이닝 플랜 (Flexible Training Plans) 또는 캐파시티 블록 (Capacity Blocks) 활용. 이는 엔터프라이즈급 (Enterprise-grade) 작업이며 주말 동안 해볼 만한 프로젝트는 아니지만, 적어도 그 경로가 문서로 정리되어 있습니다.
Llama 4 Maverick (Meta)은 미국산 워크호스 (workhorse)입니다. 일반적인 작업에서 프론티어 (frontier) 급 품질의 약 90%를 보여줍니다. 성능과 합리적인 하드웨어 요구 사항 사이의 균형이 잘 잡혀 있어 셀프 호스팅 (self-host)하기에 가장 실용적인 모델입니다.
Qwen 3.5 (Alibaba)는 Apache 2.0 라이선스를 보유하고 있으며, 27B 모델은 코딩 및 구조화된 작업에서 놀라울 정도로 뛰어난 성능을 발휘합니다. 단일 GPU에서 실행 가능합니다. 가성비 있는 선택지입니다.
솔직한 트레이드오프 (Trade-offs)
실제로 이 작업을 수행해야 할까요? 저의 프레임워크는 다음과 같습니다.
다음의 경우 셀프 호스팅을 하세요:
- 사용자가 200명 이상인 경우 (경제성이 유리해지기 시작합니다)
- 데이터 프라이버시가 타협 불가능한 경우 (데이터가 인프라 외부로 나가지 않습니다)
- 독점 데이터 (proprietary data)로 파인튜닝 (fine-tune)을 원하는 경우
- 예측 불가능한 토큰당 과금 (per-token billing)을 감당하기 어려운 경우
- 인프라를 유지 관리할 수 있는 인력이 있는 경우
다음의 경우 API 제공업체를 계속 이용하세요:
- 팀 규모가 작은 경우 (50명 미만)
- 대부분의 작업에서 절대적인 최상위 추론 (reasoning) 품질이 필요한 경우
- GPU 인프라를 유지 관리할 인력이 없는 경우
- 사용량이 급증하거나 예측 불가능한 경우
중도적인 방법 (대부분의 팀이 실제로 해야 할 일):
트래픽을 라우팅 (route) 하세요. 프론티어 급 품질이 필요하지 않은 80%의 작업(요약, 초안 작성, 코드 완성, 내부 Q&A)에는 오픈 모델 (open models)을 사용하세요. 복잡한 추론, 중대한 결정, 미묘한 분석과 같이 품질이 중요한 나머지 20%의 작업에는 Claude나 GPT를 유지하세요. 이것만으로도 중요한 부분의 품질을 희생하지 않으면서 AI 비용을 60-80% 절감할 수 있습니다.
지정학적 관점
이 부분을 언급하지 않는다면 정직하지 못한 것이 될 것입니다. 거의 모든 선도적인 오픈 모델들은 중국 연구소에서 나오고 있습니다. DeepSeek, Zhipu, Moonshot, Alibaba 등이 그 예입니다. 이들은 대부분의 벤치마크 (benchmarks)에서 Meta의 Llama를 앞지르고 있습니다.
귀하의 컴플라이언스 (compliance) 태도에 따라 이는 중요하지 않을 수도 있습니다. 가중치 (weights)는 MIT 라이선스이며, 직접 셀프 호스팅을 하므로 데이터가 인프라 외부로 나가지 않습니다. 또는 보안 팀에서 회사 인프라에 중국산 모델 코드를 허용하지 않는다면 이는 강력한 차단 요소가 될 수도 있습니다.
만약 후자에 속한다면, 실질적인 선택지는 Llama 4 Maverick와 Google이 다음에 출시할 Gemma가 될 것입니다. 둘 다 역량을 갖추고 있지만, 현재로서는 최고의 오픈 모델이라고 할 수는 없습니다. 이것이 현황입니다.
자체 호스팅(self-hosted)된 모델에서 에이전트 기반 AI 워크플로우를 실행하는 경우, 보안 표면(security surface)은 API 호스팅과 다릅니다. 저는 The OWASP Agentic AI Top 10: What Builders on AWS Need to Know에서 이 내용을 다루었습니다. 이러한 모델에 도구 접근 권한을 부여할 계획이라면 읽어볼 가치가 있습니다.
월요일 아침에 할 일
이것이 낯선 영역이라면, 시작하는 가장 위험도가 낮은 방법은 다음과 같습니다:
- AWS에서 g5.xlarge를 구동합니다 (~시간당 $1). Ollama를 설치하고 Llama 4 Scout 또는 Qwen 3.5-27B를 다운로드합니다.
- Open WebUI를 여기에 연결합니다. 팀원 3~4명에게 접근 권한을 부여합니다.
- 2주 동안 실행해봅니다. 실제 워크로드를 위한 품질이 요구 사항을 충족하는지 확인합니다.
- 격차를 측정합니다. Claude나 GPT에서 얻는 결과와 비교합니다. 많은 작업의 경우, 차이를 알아채지 못할 것입니다.
- 그런 다음 결정합니다 Maverick로 확장하여 광범위하게 배포할지 여부를 말입니다.
이 실험의 총 비용: 약 $200.
더 이상 질문은 '오픈 대 클로즈드'가 아닙니다. 그 논쟁은 끝났습니다. 질문은 다음과 같습니다: 어떤 작업을 어디에 배치할 것인가? 그리고 만약 여러분의 아키텍처가 AI 제공업체가 항상 존재한다고 가정한다면, 여러분은 희망에 기대어 운영하고 있는 것입니다. 자체 호스팅은 헤지(hedge)를 제공합니다. 그 헤지가 운영 비용만큼 가치가 있는지 여부는 팀, 사용량, 그리고 위험 감수 능력에 달려 있습니다.
하지만 $200로 알아낸다면? 그것은 베팅이 아닙니다. 그것은 반올림 오차입니다.
여러분의 생각이나 의견을 듣는 것이 매우 흥미로울 것 같으니, Twitter나 LinkedIn에서 저에게 편하게 연락 주시거나 아래에 댓글을 남겨주세요.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기