SaaS 클라우드 비용, 이제 ‘전용 서버 섞기’가 다시 진지해지는 중

• SaaS 회사들이 클라우드 비용 때문에 다시 전용 서버를 진지하게 보는 분위기임

  • 이유는 단순함. 모든 워크로드가 ‘썼다 껐다’ 되는 탄력적 부하가 아니기 때문임
  • 데이터베이스, 검색 클러스터, 캐시, 백그라운드 워커, 애플리케이션 서버는 보통 계속 돈 먹는 상시 부하에 가까움
  • 이런 애들은 클라우드의 사용량 기반 과금 모델 안에서 오래 돌릴수록 비용이 꽤 빠르게 커질 수 있음

• 하이벨로시티가 내놓은 ‘SaaS 번들’은 이 지점을 정면으로 찌르는 상품임

  • 베어메탈, 전용 서버, 에지 컴퓨팅, 가상화 클라우드 솔루션을 제공하는 인프라 회사가 SaaS용 컴퓨트 패키지를 낸 것
  • 메시지는 “클라우드 네이티브 운영은 유지하되, 상시 부하 계층은 전용 인프라로 빼서 비용과 성능을 예측 가능하게 만들자”에 가까움
  • 클라우드를 완전히 버리자는 얘기가 아니라, 워크로드별로 맞는 자리를 다시 배치하자는 쪽임

• 특히 데이터베이스가 이 논의의 중심에 있음

  • 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는 하이벨로시티의 통제 증명이지, 고객 애플리케이션 전체의 보안 인증이 아님

• 결국 이 뉴스의 포인트는 SaaS 인프라 운영 모델이 다시 재조정되고 있다는 것임
  • 개발·테스트 환경은 비용 효율과 빠른 구성이 중요함
  • 프로덕션 클러스터는 안정성과 처리량이 중요함
  • 멀티리전 엔터프라이즈 환경은 데이터베이스 성능, DR, 지역 분산, 조달 대응까지 같이 봐야 함
  • 네드 포프 하이벨로시티 최고제품책임자는 “클라우드 비용이 비즈니스보다 더 빠르게 커져서는 안 된다”고 말함. 이 말 하나로 SaaS 인프라팀의 요즘 고민이 거의 정리됨

---

기술 맥락

• 여기서 선택지는 클라우드를 버리는 게 아니라, 부하 패턴이 다른 계층을 분리하는 거예요. 순간적으로 늘었다 줄어드는 웹 트래픽은 클라우드 오토스케일링이 잘 맞지만, 데이터베이스나 검색처럼 하루 종일 일정하게 도는 계층은 사용량 기반 과금이 오히려 불리해질 수 있거든요.

• 베어메탈을 고르는 이유는 성능 예측성 때문이에요. 특히 데이터베이스는 I/O 지연이 조금만 튀어도 전체 응답 시간이 흔들리는데, 공유 클라우드 환경에서는 이 변동성을 완전히 통제하기가 쉽지 않아요. 전용 서버는 자원을 독점하니 처리량과 비용을 더 계산 가능한 형태로 가져갈 수 있어요.

• 하이벨로시티가 티어를 3개로 나눈 것도 SaaS 운영 현실을 반영한 구성이에요. 개발·테스트는 싸고 빨리 만들 수 있어야 하고, 프로덕션은 안정적인 처리량이 필요하고, 엔터프라이즈 멀티리전 환경은 1TB 넘는 데이터베이스와 DR 비용까지 같이 봐야 하니까요.

• 다만 전용 인프라를 쓰면 운영 책임도 같이 따라와요. SOC 2 같은 인프라 제공사의 통제는 조달 대응에 도움은 되지만, 애플리케이션 보안·암호화·접근 제어·로깅 설계까지 대신해주진 않아요. 그래서 이 접근은 비용 절감 카드라기보다 인프라 책임 경계를 다시 설계하는 결정에 가까워요.