왜 조회 권한만으로는 쿼리가 안 돌아가나

BigQuery의 권한 설계에서 가장 먼저 이해해야 할 것은 역할이 두 축으로 나뉜다는 점입니다. 데이터 역할과 작업 역할이 분리되어 있고, Data Viewer 같은 데이터 역할만으로는 쿼리 작업을 실행할 수 없습니다. 프로젝트 안에서 쿼리를 포함한 작업을 실행하려면 Job User(roles/bigquery.jobUser) 역할이 별도로 필요합니다. 이 분리는 최소권한 원칙을 강제하기 위한 설계입니다.

권한을 줬는데 쿼리가 안 돈다는 문의 대부분이 이 조합 누락에서 나옵니다. 문제는 해결 방식입니다. 급한 마음에 Editor나 Admin을 얹어 해결하면 그 사람은 이제 테이블을 삭제할 수도 있게 됩니다. 조회가 필요한 사람에게는 데이터 역할과 Job User를 함께 주는 것이 정답이고, 이 조합을 등급 정의에 명시해두면 매번 같은 실수를 반복하지 않습니다.

어떤 역할들을 조합해 등급을 만들 수 있나

BigQuery가 제공하는 사전 정의 역할에는 BigQuery Admin(roles/bigquery.admin), Data Viewer(roles/bigquery.dataViewer), Data Editor(roles/bigquery.dataEditor), Data Owner(roles/bigquery.dataOwner), Job User(roles/bigquery.jobUser), Metadata Viewer(roles/bigquery.metadataViewer), Read Session User(roles/bigquery.readSessionUser) 등이 있습니다.

마케팅 조직에 맞춰 등급을 만든다면 대체로 네 단계로 정리됩니다. 대시보드만 보는 열람 등급은 BI 도구에서 만든 보고서만 보고 웨어하우스에는 직접 접근하지 않습니다. 조회 등급은 지정된 데이터세트에 대한 데이터 역할과 Job User를 받아 직접 쿼리합니다. 편집 등급은 표준화 레이어 테이블을 만들고 고치는 역할을 받습니다. 관리 등급은 권한 부여와 비용 상한 설정을 담당합니다. 인원이 적은 조직이라도 이 네 칸을 문서에 적어두는 것과 적어두지 않는 것의 차이가 큽니다.

권한을 어느 수준에 걸어야 하나

IAM 정책은 조직, 프로젝트, 데이터세트, 테이블·뷰, 루틴, 커넥션 수준에서 설정할 수 있습니다. 여기서 실무 판단이 필요합니다. 프로젝트 수준에 걸면 관리가 단순하지만 범위가 넓어지고, 테이블 수준에 걸면 정밀하지만 관리 부담이 커집니다.

현실적인 절충은 데이터세트 수준을 기본 단위로 삼는 것입니다. 원시 레이어 데이터세트와 표준화 레이어 데이터세트를 나누고, 마케팅팀 대부분은 표준화 레이어에만 접근하도록 두는 구조입니다. 원시 레이어에는 개인정보에 해당할 수 있는 값이 그대로 남아 있을 가능성이 높기 때문에, 이 분리는 관리 편의뿐 아니라 개인정보 보호 관점에서도 의미가 있습니다. 쿠키·픽셀·광고 ID로 수집된 행태정보는 단독으로는 개인정보가 아니지만 결합해 특정 개인을 식별할 수 있으면 개인정보에 해당하므로, 결합이 일어난 테이블일수록 접근 범위를 좁게 두는 것이 원칙에 맞습니다.

같은 테이블 안에서 범위를 더 나눌 수 있나

가능합니다. BigQuery는 사용자가 접근할 수 있는 테이블 행을 제한하는 행 수준 보안과, 특정 열 접근을 통제하고 데이터 마스킹을 적용할 수 있는 열 수준 보안을 제공합니다.

마케팅 조직에서 이 기능이 필요한 전형적 상황은 두 가지입니다. 하나는 브랜드나 사업부가 여러 개일 때로, 각 담당자가 자기 브랜드 행만 보게 하려면 행 수준 보안이 적합합니다. 다른 하나는 고객 식별자 열입니다. 세그먼트 집계에는 참여해야 하지만 이메일이나 전화번호 원문을 볼 필요는 없는 담당자에게는 열 수준 보안과 마스킹이 맞습니다.

다만 이 기능들은 설정 자체보다 유지가 어렵습니다. 누가 어떤 등급인지를 정의한 사내 기준이 먼저 있어야 하고, 그 기준 없이 개별 요청마다 예외를 만들면 몇 달 뒤 아무도 현재 권한 상태를 설명할 수 없게 됩니다.

등급 정책을 어떻게 운영해야 무너지지 않나

운영에서 정해야 할 것은 네 가지입니다. 신규 인원이 들어올 때 기본 등급이 무엇인지, 등급 상향은 누가 승인하는지, 퇴사·이동 시 회수는 언제 이뤄지는지, 그리고 현재 권한 상태를 언제 점검하는지입니다.

특히 회수 시점이 자주 비어 있습니다. 개인정보보호위원회가 2026년 실시한 사전 실태점검의 항목에도 개인정보취급자 접근권한 최소부여 여부, 업무 변경 시 접근권한 변경·말소, 계정 공유 여부가 포함돼 있었습니다. 접근권한을 준 기록만 있고 회수한 기록이 없는 조직이 흔하다는 뜻이기도 합니다. 분기에 한 번, 현재 권한 목록을 뽑아 재직·업무 상태와 대조하는 절차를 캘린더에 넣어두는 것이 가장 단순하고 확실한 방법입니다. 비용 통제도 같은 축에서 다룰 수 있습니다. 구글은 맞춤 쿼리 할당량을 만들어 프로젝트나 사용자 단위로 처리 데이터 한도를 두는 것을 권장하는데, 이는 온디맨드 모델에서 등급별 상한을 거는 수단으로 쓸 수 있습니다.