--- title: "SaaS 클라우드 비용, 이제 ‘전용 서버 섞기’가 다시 진지해지는 중" published: 2026-06-08T16:05:04.781Z canonical: https://jeff.news/article/3890 --- # SaaS 클라우드 비용, 이제 ‘전용 서버 섞기’가 다시 진지해지는 중 SaaS 기업에서 데이터베이스, 검색, 캐시, 백그라운드 워커처럼 계속 켜져 있는 워크로드는 클라우드 과금 구조와 잘 안 맞을 수 있다는 얘기다. 하이벨로시티는 이런 지속 부하 계층을 베어메탈·전용 서버로 옮겨 비용 예측성과 데이터베이스 성능을 동시에 잡는 SaaS 번들을 내놨다. 핵심은 클라우드를 버리자는 게 아니라, 워크로드 성격별로 인프라를 다시 나누자는 쪽에 가깝다. - SaaS 회사들이 클라우드 비용 때문에 다시 전용 서버를 진지하게 보는 분위기임 - 이유는 단순함. 모든 워크로드가 ‘썼다 껐다’ 되는 탄력적 부하가 아니기 때문임 - 데이터베이스, 검색 클러스터, 캐시, 백그라운드 워커, 애플리케이션 서버는 보통 계속 돈 먹는 상시 부하에 가까움 - 이런 애들은 클라우드의 사용량 기반 과금 모델 안에서 오래 돌릴수록 비용이 꽤 빠르게 커질 수 있음 - 하이벨로시티가 내놓은 ‘SaaS 번들’은 이 지점을 정면으로 찌르는 상품임 - 베어메탈, 전용 서버, 에지 컴퓨팅, 가상화 클라우드 솔루션을 제공하는 인프라 회사가 SaaS용 컴퓨트 패키지를 낸 것 - 메시지는 “클라우드 네이티브 운영은 유지하되, 상시 부하 계층은 전용 인프라로 빼서 비용과 성능을 예측 가능하게 만들자”에 가까움 - 클라우드를 완전히 버리자는 얘기가 아니라, 워크로드별로 맞는 자리를 다시 배치하자는 쪽임 > [!IMPORTANT] > 핵심은 ‘클라우드냐 전용 서버냐’ 이분법이 아님. 트래픽이 들쭉날쭉한 계층은 클라우드가 맞고, 높은 사용률로 계속 도는 계층은 베어메탈 경제성이 더 나을 수 있다는 얘기임. - 특히 데이터베이스가 이 논의의 중심에 있음 - SaaS에서 데이터베이스는 성능 병목이면서 비용 비중도 커지기 쉬운 계층임 - 하이벨로시티는 공유 클라우드 I/O만으로는 대규모 환경에서 결정론적인 성능을 확보하기 어렵다고 봄 - 그래서 포스트그레스(Postgres), 마이SQL(MySQL) 같은 핵심 데이터베이스 노드를 전용 서버 위에 두면 처리량과 비용 통제가 나아질 수 있다고 주장함 - 번들은 3단계로 나뉨. 꽤 노골적으로 SaaS 성장 단계를 겨냥한 구성임 - 티어 1은 엔지니어링 컴퓨트(Engineering Compute)로, 개발·테스트·스테이징·CI 빌드 팜·컨테이너 레지스트리·내부 도구·백그라운드 워커 같은 비프로덕션 워크로드가 대상임 - 티어 2는 프로덕션 컴퓨트(Production Compute)로, 멀티테넌트 프로덕션 클러스터를 염두에 둠 - 이 단계에는 애플리케이션 서버 클러스터, 포스트그레스·마이SQL 기본 및 복제 노드, 레디스(Redis), 캐시 계층, 엘라스틱서치(Elasticsearch), 오픈서치(OpenSearch), 내부 API 게이트웨이가 들어감 - 티어 3은 하이 스케일 컴퓨트(Hi-Scale Compute)로, 멀티리전 엔터프라이즈 SaaS와 1TB 초과 자체 관리 데이터베이스, 고객 구축형 재해복구(DR)를 겨냥함 - 재해복구 비용 얘기도 꽤 현실적임 - 대규모 SaaS는 장애 대응을 위해 멀티리전 구성이나 대기 인프라를 준비해야 함 - 그런데 하이퍼스케일 클라우드에서 대기 리소스를 계속 유지하면, 실제로 트래픽을 처리하지 않아도 비용이 계속 나감 - 하이벨로시티는 고객이 직접 구축하는 DR 환경이 이런 대기 비용보다 훨씬 낮게 운영될 수 있다고 주장함 - 이건 개발팀만의 문제가 아니라 재무·조달·보안팀까지 엮이는 문제임 - 기업 고객을 상대하는 SaaS는 보안 질문서, 컴플라이언스 증빙, 조달 요건을 계속 맞춰야 함 - 월별 클라우드 비용이 계속 튀면 재무 계획도 어려워지고, 엔터프라이즈 고객 대응도 빡세짐 - 예측 가능한 청구 구조는 단순히 ‘싸다’가 아니라 예산 승인과 조달 대응에서 의미가 있음 - 하이벨로시티는 SOC 2 타입 II 보고서를 내세워 기업 조달 대응 포인트도 같이 강조함 - 접근 제어, 사고 대응, 침투 테스트, 취약점 관리 같은 통제가 포함된다고 설명함 - HIPAA/HITECH 보안 요구사항과도 정렬돼 있어, SaaS 벤더 실사에서 증빙 자료로 쓸 수 있다는 입장임 - 다만 중요한 선이 있음. 이 SOC 2는 하이벨로시티의 통제 증명이지, 고객 애플리케이션 전체의 보안 인증이 아님 > [!WARNING] > 전용 서버로 옮긴다고 보안 책임이 사라지는 건 아님. 네트워크 분리, 서버 하드닝, 암호화·키 관리, 접근 제어, 로깅, 애플리케이션 계층 통제는 여전히 고객이 챙겨야 함. - 결국 이 뉴스의 포인트는 SaaS 인프라 운영 모델이 다시 재조정되고 있다는 것임 - 개발·테스트 환경은 비용 효율과 빠른 구성이 중요함 - 프로덕션 클러스터는 안정성과 처리량이 중요함 - 멀티리전 엔터프라이즈 환경은 데이터베이스 성능, DR, 지역 분산, 조달 대응까지 같이 봐야 함 - 네드 포프 하이벨로시티 최고제품책임자는 “클라우드 비용이 비즈니스보다 더 빠르게 커져서는 안 된다”고 말함. 이 말 하나로 SaaS 인프라팀의 요즘 고민이 거의 정리됨 --- ## 기술 맥락 - 여기서 선택지는 클라우드를 버리는 게 아니라, 부하 패턴이 다른 계층을 분리하는 거예요. 순간적으로 늘었다 줄어드는 웹 트래픽은 클라우드 오토스케일링이 잘 맞지만, 데이터베이스나 검색처럼 하루 종일 일정하게 도는 계층은 사용량 기반 과금이 오히려 불리해질 수 있거든요. - 베어메탈을 고르는 이유는 성능 예측성 때문이에요. 특히 데이터베이스는 I/O 지연이 조금만 튀어도 전체 응답 시간이 흔들리는데, 공유 클라우드 환경에서는 이 변동성을 완전히 통제하기가 쉽지 않아요. 전용 서버는 자원을 독점하니 처리량과 비용을 더 계산 가능한 형태로 가져갈 수 있어요. - 하이벨로시티가 티어를 3개로 나눈 것도 SaaS 운영 현실을 반영한 구성이에요. 개발·테스트는 싸고 빨리 만들 수 있어야 하고, 프로덕션은 안정적인 처리량이 필요하고, 엔터프라이즈 멀티리전 환경은 1TB 넘는 데이터베이스와 DR 비용까지 같이 봐야 하니까요. - 다만 전용 인프라를 쓰면 운영 책임도 같이 따라와요. SOC 2 같은 인프라 제공사의 통제는 조달 대응에 도움은 되지만, 애플리케이션 보안·암호화·접근 제어·로깅 설계까지 대신해주진 않아요. 그래서 이 접근은 비용 절감 카드라기보다 인프라 책임 경계를 다시 설계하는 결정에 가까워요. ## 핵심 포인트 - SaaS 비용 폭증의 큰 원인은 데이터베이스, 검색, 캐시처럼 상시 가동되는 워크로드임 - 하이벨로시티 SaaS 번들은 비프로덕션, 프로덕션, 대규모 엔터프라이즈 환경을 3단계로 나눠 전용 인프라 구성을 제안함 - 공유 클라우드 I/O는 대규모 데이터베이스에서 성능 예측이 어려울 수 있고, 베어메탈은 처리량과 비용 통제 면에서 장점이 있음 - SOC 2 타입 II 기반 통제를 내세우지만, 고객 애플리케이션 보안과 네트워크 분리·암호화·로깅은 여전히 고객 책임임 ## 인사이트 클라우드 비용 최적화 얘기가 ‘예약 인스턴스 잘 사자’ 수준을 넘어, 어떤 계층을 아예 다른 인프라 모델로 빼낼지 고민하는 단계로 가고 있음. 특히 데이터베이스가 비용과 성능을 동시에 잡아먹는 SaaS라면 꽤 현실적인 논점이다.