BigQuery·Snowflake, 빠른 쿼리보다 과금 단위가 먼저

BigQuery와 Snowflake의 비용을 비교하려면 같은 SQL을 실행하는 데 걸린 시간보다 먼저 월간 업무량을 과금 단위로 바꿔야 한다. Google Cloud의 BigQuery 비용 안내에 따르면 온디맨드 쿼리는 읽은 바이트를 기준으로, 용량 기반 쿼리는 시간에 따라 할당된 슬롯 용량을 기준으로 과금된다. 읽는 범위가 작고 실행이 드문 업무라면 온디맨드 처리량부터 계산하고, 반복 작업이 많다면 슬롯 용량의 가동 시간도 비교해야 한다.

Snowflake에서는 쿼리 사이의 공백까지 웨어하우스가 켜져 있으면 크레딧이 쌓인다. Snowflake의 웨어하우스 운영 안내에 따르면 크레딧은 웨어하우스 크기·클러스터 수·가동 시간에 좌우되며, 컴퓨팅 자원을 켤 때마다 최소 60초가 청구되고 이후에는 초 단위로 계산된다. 따라서 같은 분석 업무의 스캔량, 실행 횟수, 완료 시간, 중지 전 유휴시간을 한 달 일정에 놓고 비교해야 한다.

저장 용량보다 쿼리마다 읽는 범위가 중요하다

BigQuery 온디맨드의 핵심 입력값은 저장한 데이터의 크기가 아니라 쿼리별 청구 대상 바이트다. 원천 데이터가 같아도 필요한 열과 기간만 읽는 쿼리와 넓은 범위를 반복해서 읽는 쿼리의 월간 처리량은 크게 달라진다. 데이터셋 용량 하나에 단가를 곱하면 대시보드 새로고침의 반복 비용이 계산에서 빠진다.

대표 SQL의 드라이런은 실행 전 스캔량을 가늠하는 출발점이다. 드라이런 수치는 상한 추정치라 실제 청구 바이트와 다를 수 있으므로, 실행 후 수치로 계산표를 고쳐야 한다. 파티션 조건을 주거나 필요한 열만 선택하면 읽는 범위가 달라지지만, 결과 행을 제한하는 문구만으로 스캔량이 줄어든다고 가정해서는 안 된다.

실행 횟수도 업무별로 나눠야 한다. 하루 한 번의 배치, 업무 시간 내내 새로고침되는 대시보드, 분석가가 가끔 실행하는 광범위한 SQL은 월간 비용을 만드는 방식이 서로 다르다. 쿼리당 바이트가 큰 비정기 분석도 횟수가 적으면 월간 처리량이 작을 수 있고, 반대로 작은 대시보드 쿼리는 반복 횟수가 많으면 총량이 커진다.

BigQuery 슬롯 요금은 이 바이트 계산에 단가만 바꿔 끼우는 방식으로 추정할 수 없다. 기준으로 확보한 슬롯과 자동 확장으로 할당된 슬롯의 시간, 적용 에디션과 약정 조건을 따로 입력해야 한다. 쿼리 하나가 실제로 소비한 슬롯 시간은 업무별 비용을 배분하는 데 유용하지만, 예약 용량 전체의 청구액과 같지는 않다.

Snowflake는 실행 시간과 중지 지연을 함께 센다

Snowflake의 계산표에는 쿼리 완료 시간 외에 웨어하우스가 쿼리를 기다리며 켜져 있는 시간을 넣어야 한다. 대시보드 요청이 짧은 간격으로 계속 들어오면 개별 쿼리가 빨라도 웨어하우스는 장시간 가동될 수 있다. 요청 간격이 길어 자동 중지가 작동하면 가동 시간은 줄지만, 다시 켤 때마다 최소 과금이 새로 시작한다.

자동 중지 시간을 무조건 짧게 잡는 것도 해답은 아니다. 요청 사이에 규칙적인 공백이 있다면 중지와 재가동이 반복되고, 각 재가동의 최소 청구 시간이 누적된다. 반대로 웨어하우스를 오래 켜 두면 유휴시간에 크레딧을 쓰지만, 이전 쿼리의 데이터 캐시가 남아 후속 쿼리에 도움이 될 수 있다. 비용과 응답 시간을 함께 평가해야 하는 이유다.

웨어하우스 크기를 키우면 복잡한 쿼리의 완료 시간이 줄거나 대기열이 완화될 수 있지만 시간당 크레딧 소비도 늘어난다. 작은 쿼리에서는 크기 증가만큼 속도가 개선되지 않을 수도 있다. 동일한 SQL 묶음을 후보 크기별로 실행해 완료 시간, 동시 요청의 대기 시간, 총 크레딧을 함께 기록해야 빠른 구성과 저렴한 구성이 같은지 알 수 있다.

같은 업무량을 두 과금 단위로 환산하면

다음은 측정 결과가 아닌 조건부 계산 예시다. 원천 데이터 1TB, 한 달 30일을 가정하고 대시보드·배치·비정기 분석을 업무별로 분리한다. Snowflake는 각 업무에 단일 클러스터 웨어하우스를 쓴다고 가정하며, 시간당 크레딧 계수 R을 설명용으로 2로 둔다. 실제 실행 시간과 계약 단가를 뜻하는 값은 아니다.

대시보드: 쿼리당 50GB를 하루 20회 읽으면 BigQuery의 월간 처리량은 50GB × 20회 × 30일로 30TB다. Snowflake 웨어하우스를 하루 8시간 연속 켜 둔다는 가정에서는 월 240시간, 즉 240R 또는 예시 계수로 480크레딧이다. 모든 쿼리가 60초 안에 끝나고 매번 즉시 중지된다는 이론적 하한에서는 600회의 최소 청구 시간이 합계 10시간이므로 10R 또는 20크레딧이다. 실제 자동 중지 지연은 이 하한에 포함되지 않는다.
일일 배치: 한 번에 1TB를 읽는 작업을 매일 실행하면 BigQuery 처리량은 월 30TB다. Snowflake에서 실행과 중지까지 매일 20분이 걸린다는 가정이면 월 가동 시간은 10시간, 소비량은 10R 또는 20크레딧이다. 다른 작업을 기다리며 웨어하우스가 계속 켜져 있거나 배치 시간이 길어지면 그 시간만큼 더해진다.
비정기 분석: 쿼리당 200GB를 한 달에 10회 읽으면 BigQuery 처리량은 2TB다. 각 쿼리가 별도로 웨어하우스를 켜고 60초 안에 끝난 뒤 즉시 중지된다고 가정하면 최소 청구 시간의 합은 10분, 예시 계수로 약 0.33크레딧이다. 중지 지연과 실제 실행 시간이 길다면 이 값보다 크다.

세 업무의 BigQuery 온디맨드 처리량은 월 62TB, 십진수 TB를 요금표의 이진수 단위로 바꾸면 약 56.4TiB다. Snowflake는 대시보드를 매번 즉시 중지하는 하한 가정에서 세 업무 합계가 약 40.3크레딧이고, 대시보드 웨어하우스를 하루 8시간 유지하면 약 500.3크레딧이다. 이 차이는 제품 성능의 측정 결과가 아니라 동일한 실행 횟수에 서로 다른 유휴시간을 대입한 결과다.

계약 단가를 넣어 손익분기점을 구한다

BigQuery 온디맨드의 실효 단가를 P원/TiB, Snowflake의 실효 단가를 C원/크레딧으로 두면 예시의 쿼리 비용은 각각 약 56.4P원과 약 40.3C~500.3C원이다. Snowflake의 실제 가동 기록에서 나온 크레딧에 C를 곱한 금액이 56.4P보다 낮고 요구 응답 시간을 충족할 때, 이 예시의 웨어하우스 컴퓨팅 비용은 Snowflake 쪽이 낮다. 무료 사용량과 할인이 적용된다면 표시 단가 대신 청구서에 반영되는 실효 단가를 써야 한다.

한국 팀의 견적에서는 배포 지역과 계약 조건을 맞추는 일이 중요하다. Snowflake의 에디션 안내는 크레딧 단가에 에디션, 계정 지역, 온디맨드 또는 선구매 용량 계약 여부가 영향을 준다고 설명한다. BigQuery도 선택한 지역과 슬롯 약정 조건에 따라 적용 단가가 달라지므로, 서로 다른 지역의 표시 가격만 나란히 놓으면 업무량 계산이 정확해도 구매 결론은 어긋난다.

BigQuery 용량 기반 요금이 후보라면 계산표에 별도 열을 만든다. 기준 슬롯의 월간 할당 시간과 자동 확장분의 할당 시간에 각각 적용 단가를 곱해 온디맨드 결과와 비교한다. 반복 쿼리가 많다는 이유만으로 예약 슬롯이 저렴하다고 단정할 수는 없다. 쿼리가 특정 시간대에 몰리는지, 확보한 용량이 쉬는 시간은 얼마나 되는지에 따라 손익분기점이 바뀐다. 저장, 데이터 이동, 두 서비스의 다른 부가 과금은 쿼리·웨어하우스 비용과 구분해 더해야 차이의 원인을 알 수 있다.

공개 벤치마크가 답하지 못하는 비용

Fivetran의 공개 비교 스크립트는 TPC-DS 기반 쿼리를 이식성에 맞춰 일부 수정하고 1TB 데이터와 최대 팩트 테이블 약 40억 행을 사용하며, Snowflake Large 웨어하우스와 BigQuery의 정액 500슬롯 구성을 포함한다. 이 구성의 실행 결과를 BigQuery 온디맨드와 특정 한국 계정의 Snowflake 계약 비용으로 곧바로 옮길 수는 없다.

벤치마크의 조인·집계 중심 쿼리는 복잡한 분석 성능을 살펴보는 참고점이 된다. 다만 실제 구매 비용에는 팀의 SQL, 대시보드 새로고침 간격, 배치 창과 동시 요청이 만든 가동·유휴 패턴이 들어간다. 같은 기간에 BigQuery의 청구 바이트 또는 할당 슬롯 시간과 Snowflake의 웨어하우스 가동 시간을 모으면, 요구 응답 시간을 충족하는 구성끼리 월간 비용을 비교할 수 있다.

함께 읽기: