요약

  • 행 수준 보안으로 보호된 테이블의 사전 실행은 정보 유출을 막으려고 항상 0바이트를 반환한다. 실제 쿼리 비용을 예측하는 숫자로 사용할 수 없다.
  • 실행 후에도 일부 청구 통계는 비어 있다. 빈칸을 0으로 바꾸면 사용량을 아낀 팀과 사용량이 보이지 않는 팀을 혼동하게 된다.

클라우드 비용 절감 대회에서 가장 유리한 팀은 누구일까. 사용량을 줄인 팀이어야 한다. 하지만 비용 집계가 빈칸을 무조건 0으로 채운다면, 통계가 가려진 팀이 우승할 수도 있다. 절약한 것은 계산 자원이 아니라 보고서 작성자의 고민이다.

BigQuery의 행 수준 보안에는 이런 착각을 부르기 쉬운 숫자가 있다. 보호된 테이블을 대상으로 사전 실행, 즉 드라이런을 하면 결과는 항상 0바이트다. Google의 쿼리 실행 문서는 이를 비용 추정에 의존할 수 없는 결과라고 명시한다. 숨긴 데이터에 관한 단서를 처리량으로 알아내지 못하도록 한 조치다.

드라이런 자체는 무료이고 쿼리 실행 슬롯도 사용하지 않는다. 이후 실제 쿼리를 돌리는 일은 별도다. 여기에 적용되는 과금 체계와 무료 구간, 캐시 같은 조건은 그대로 따져야 한다. 보안을 위해 내놓은 0은 다음 작업까지 공짜로 해주겠다는 견적이 아니다.

숫자를 가려야 행을 지킬 수 있다

행 수준 보안은 같은 테이블에서도 사용자별로 허용된 행만 보이게 한다. 데이터를 따로 복제하지 않고 접근 범위를 나누는 데 유용하다. 문제는 데이터의 내용뿐 아니라 처리된 양이나 실행 과정도 정보가 된다는 점이다.

Google의 보안 운영 지침은 이러한 테이블에 대한 쿼리에서 처리 바이트와 파티션 수, 청구 바이트, 쿼리 계획 단계 등을 숨긴다고 설명한다. 사전 견적만 조용한 것이 아니다. 작업이 끝나도 일부 장부는 열리지 않는다.

작업 정보를 제공하는 INFORMATION_SCHEMA.JOBS에서 행 접근 정책이 있는 테이블을 읽으면 total_bytes_billed와 total_bytes_processed 값은 비어 있다. 공식 문서의 비용 추정 예제도 영향을 받았을 가능성이 있는 작업을 셀 수는 있지만 그 작업의 청구 사용량에는 접근할 수 없다고 밝힌다. 가려진 영수증이 열 장이라는 사실만으로 총액을 계산할 수는 없다.

여기서 회사 내부 집계가 의미를 바꾸기 쉽다. 부서별 비용표를 만들며 누락값을 0으로 치환한다고 가정해 보자. 보이지 않는 비용은 표에서 사라지고, 해당 부서의 효율은 좋아 보인다. 이 가상 사례에서 잘못한 주체는 보안 기능이 아니라 누락을 절감으로 바꾼 집계다. 예쁜 그래프도 엉뚱한 인센티브를 만들 수 있다.

재무 권한도 데이터 권한이다

숫자가 안 보이면 더 높은 권한을 요구하는 것이 흔한 대응이다. BigQuery에서는 이 처방부터 구분해야 한다.

Google에 따르면 프로젝트 소유자는 관련 감사 로그에서 처리 바이트를 볼 수 있다. 그렇다고 작업 상세 화면의 해당 청구 메타데이터가 열리는 것은 아니다. 그 메타데이터를 보이게 하는 특정 권한이나 역할도 없다. 한편 Cloud Billing Viewer는 청구 정보에 접근한다. 같은 비용 이야기지만 서로 다른 정보 경로다.

Google은 필터링된 행만 봐야 하는 사용자에게 이런 청구 가시성을 주지 말 것을 권고한다. 비용 정보로도 민감한 내용을 추론할 수 있기 때문이다. 재무팀이 투명성을 높인다고 권한을 넓혔는데, 데이터팀이 닫아둔 문을 옆에서 여는 상황을 피해야 한다.

이제 회사가 풀 문제는 구체적이다. 전체 청구를 대조할 권한이 있는 사람은 누구인가. 사용 부서에는 어느 정도로 묶은 비용 정보를 전달할 것인가. 사용자는 지출을 조절할 수 있어야 하지만 모든 사용자에게 모든 청구 단서를 줄 수는 없다. 비용 책임과 열람 권한을 한 덩어리로 취급하면 둘 중 하나가 무너진다.

적게 보인다고 적게 읽는 것도 아니다

행 접근 정책의 필터는 파티션이나 클러스터를 잘라내 처리량을 줄이는 과정에 참여하지 않는다고 Google은 설명한다. 정책에 파티션 열이 들어 있어도 그 자체로 파티션 제거의 이익을 얻지 못한다. 쿼리 자체에 둔 조건이 처리 범위를 줄이는 경우와는 구별해야 한다.

사용자가 일부 지역의 행만 볼 수 있다는 사실을 그 지역 몫만큼의 처리비로 곧장 환산할 수 없는 이유다. 접근 허용 범위는 과금 비율표가 아니다.

BigQuery 요금 문서는 주문형 과금의 처리 바이트 기준과 용량 기반 과금의 계산 용량·시간 기준을 나눈다. 공유 데이터를 쿼리할 때 비용은 데이터를 가진 쪽에 자동으로 넘어가지 않고, 쿼리를 수행한 프로젝트의 결제 계정으로 간다. 누가 데이터를 소유하고 누가 일부를 보며 누가 계산비를 내는지는 서로 다른 질문이다.

비용 관리 문서에는 주문형 사용량의 일일 할당량과 쿼리당 최대 청구 바이트 설정이 소개되어 있다. 다만 확인한 자료는 최대 청구 바이트 설정과 행 보안으로 가려진 0바이트 추정의 상호작용을 모두 설명하지 않는다. 대상 작업에서 적절한 권한으로 동작을 확인해야 하며, 화면의 0만 보고 한도가 무조건 작동하거나 우회된다고 판단할 수 없다.

이번 분석에는 특정 고객의 실제 청구서나 내부 배분 자료가 없다. 잘못 배분된 금액을 산출하려면 그 기록이 필요하다. 확인된 구조는 충분히 선명하다. 보안이 비용 단서의 노출을 줄이면 회사에는 그 공백을 관리하는 일이 남는다.

빈칸은 우선 빈칸으로 두면 된다. 그다음에는 권한을 갖춘 담당자가 청구를 대조하고, 정확히 나누기 어려운 비용의 부담 주체를 정하고, 사용자에게 허용된 범위의 피드백을 줘야 한다. 0바이트가 지켜주는 것은 비밀이다. 예산까지 대신 지켜주지는 않는다.