Data Agent Kit GA, 데이터 접근 전에 남길 권한 기록

코딩 에이전트가 SQL을 쓰고, 파이프라인 코드를 만들고, 실패한 작업의 단서를 읽어 주는 장면은 이제 낯설지 않다. 하지만 에이전트가 데이터 서비스에 연결되는 순간부터 질문은 “무엇을 할 수 있나”만이 아니다. 어떤 도구가 어떤 리소스를 어떤 자격으로 읽거나 바꿀 수 있는지, 그리고 그 결정을 나중에 어떻게 설명할 수 있는지가 함께 따라온다. 이 글은 Google Cloud에서 데이터 작업을 에이전트에 연결하려는 데이터 엔지니어와 플랫폼 담당자를 위해, 연결 전에 확인할 권한 경계를 정리한다.

Google Cloud는 2026년 9월 30일 Data Agent Kit의 일반 제공 발표에서 이 도구를 코딩 에이전트가 Google Cloud 데이터 제품과 직접 작업하게 하는 MCP 도구 및 에이전트 스킬 모음으로 소개했다. 같은 발표는 일반 제공과 함께 BigQuery Graph, Bigtable, Managed Service for Apache Spark 접근 지원을 추가했다고 밝힌다. 이 변화는 에이전트가 대화창 밖의 데이터 자산을 더 많이 발견하고 다룰 수 있는 선택지를 넓힌다. 그러나 일반 제공이라는 제품 상태가 곧 각 조직의 데이터 접근 정책이 준비됐다는 뜻은 아니다.

공식 Data Agent Kit 개요 문서는 이 도구가 BigQuery, Dataflow, Managed Service for Apache Spark, Cloud SQL, Spanner, Cloud Storage 등 여러 서비스를 개발 환경에 연결한다고 설명한다. 지원 서비스 목록은 “모든 데이터가 한 권한으로 열렸다”는 목록이 아니다. 실제 접근은 서비스별 API와 역할에 다시 묶인다. 예를 들어 권한 문서는 BigQuery, Dataflow, Spanner, Cloud Storage에 필요한 역할을 분리해서 제시한다. 에이전트의 대화 능력과 클라우드 리소스의 접근 권한은 같은 층위가 아니라는 뜻이다.

일반 제공 이후에도 남는 첫 번째 질문

제품이 일반 제공되었다는 발표는 도입 검토의 시작점이다. 팀은 우선 어떤 작업 단위를 에이전트에 맡길지 정해야 한다. 여기서 작업 단위는 “데이터를 분석한다”처럼 넓은 문장이 아니라, 예를 들어 특정 프로젝트의 BigQuery 테이블 메타데이터를 읽어 질의 초안을 만들거나, 실패한 Dataflow 작업의 로그를 찾아 원인을 요약하는 일처럼 입력과 결과가 구분되는 활동이어야 한다. 이 구분이 없으면 최소 권한도 정할 수 없다.

Data Agent Kit의 원격 MCP 서버 사용 문서는 MCP 서버가 도구를 통해 Google Cloud 리소스를 만들고, 관리하고, 조회할 수 있다고 설명한다. 또한 원격 MCP 서버의 특성으로 세분화된 인가와 중앙 감사 로깅을 든다. 이는 중요한 기반이지만, “MCP를 설치했다”가 특정 도구의 실행을 승인했다는 뜻은 아니다. 같은 문서는 MCP Tool User 역할과, 접근하려는 리소스에 따라 추가 역할이 필요할 수 있음을 구분한다. 따라서 팀이 먼저 결정할 대상은 모델이 아니라 도구와 리소스의 조합이다.

다음과 같은 질문은 구성 작업 전에 답할 수 있다.

• 에이전트가 읽을 데이터는 어떤 프로젝트·데이터셋·버킷·인스턴스로 한정되는가?
• 질의 초안, 메타데이터 조회, 로그 요약처럼 결과가 외부 상태를 바꾸지 않는 작업과, 테이블 생성·파이프라인 실행처럼 상태를 바꾸는 작업을 같은 권한으로 묶었는가?
• 사람이 검토해야 할 변경은 어느 단계에서 멈추며, 승인 근거는 어디에 남는가?
• 사용자 자격 증명과 서비스 계정 위임 중 어떤 경로를 쓸지, 그 선택이 감사와 책임 추적에 어떤 차이를 만드는가?

이 질문들은 Data Agent Kit이 직접 요구하는 단일 체크리스트가 아니다. 이 글의 제안은 제품의 도구 연결을 실제 업무 권한으로 바꾸기 전, 작업 단위를 잘라 내자는 것이다. 범위가 설명되지 않은 요청은 기능 검증이 아니라 보류의 후보가 된다. 특히 테스트 환경에서 읽을 수 있다는 확인과 운영 데이터에서 같은 요청을 허용한다는 결정은 구분해야 한다. 두 환경의 데이터 분류, 계정, 로그 보존 조건이 다르면 같은 프롬프트와 같은 도구 이름도 같은 위험을 뜻하지 않는다. 기록에는 어느 환경을 대상으로 판단했는지도 남기는 편이 좋다.

권한은 서비스와 행위에 따라 다시 갈린다

권한 문서에는 서비스마다 다른 역할이 나온다. BigQuery는 BigQuery User와 BigQuery Data Viewer 등을, Cloud Storage는 Storage Viewer를 예로 든다. Spanner는 Viewer 역할과 데이터베이스 사용자 또는 읽기 역할을 별도로 나열한다. 이 목록은 역할을 넓게 부여하라는 처방이 아니다. 오히려 에이전트가 수행하려는 행위가 메타데이터 탐색인지, 데이터 읽기인지, 데이터 변경인지에 따라 필요한 권한과 검토자가 달라질 수 있음을 보여 준다.

예를 들어 에이전트에게 “이번 주 이상치를 찾아 달라”고 요청했다고 하자. 같은 문장 안에도 테이블 스키마를 확인하는 도구 호출, SQL을 생성하는 활동, 쿼리를 실제 실행하는 행위, 결과를 다른 위치에 저장하는 행위가 섞일 수 있다. 첫 두 활동은 사람이 내용을 보고 고칠 기회가 남아 있다. 반면 실행과 저장은 비용·데이터 노출·영구 상태에 영향을 줄 수 있다. 문장 하나를 승인 단위로 삼으면 이 차이를 잃는다.

이 글에서는 요청을 세 경로로 나누어 기록하는 방식을 권한다. 읽기 경로는 명시된 범위 안에서 메타데이터나 로그를 확인하고, 출력은 사람의 검토 대상으로 남긴다. 변경 경로는 도구가 외부 상태를 바꿀 수 있으므로, 대상 리소스·변경 내용·승인자·되돌릴 수 있는지 여부를 연결한다. 보류 경로는 권한이 없거나 요청 범위가 불명확할 때 실패로 취급하지 않는다. 어떤 정보가 빠졌는지 적고, 사람에게 질문을 되돌리는 경로다.

▲ 도구 연결 뒤의 요청을 읽기·변경·보류로 분기해 다루는 관계를 보여줍니다. 실제 권한 설정이나 실행 결과를 나타내지는 않습니다.

요청 하나를 닫는 검토 기록

아래 양식은 Google Cloud의 공식 설정 화면이나 필수 문서가 아니다. 에이전트가 데이터 작업을 수행하기 전후에, 누가 무엇을 허용했는지 설명하기 위한 짧은 제안서다. 적용 범위는 사람이 에이전트에게 데이터 작업을 요청하고 결과를 검토하는 한 건의 업무다. 데이터 범위, 도구, 행위 중 하나라도 비어 있으면 실행을 진행하지 않고 보류 이유를 남긴다. 이것이 이 글이 독자에게 남기려는 판단 도구다.

## 데이터 에이전트 요청 기록

- 요청 목적: 어떤 업무 질문에 답하려는가?
- 대상 범위: 프로젝트 / 데이터셋·버킷·인스턴스 / 제외할 리소스
- 허용 도구: 조회 / 질의 생성 / 실행 / 변경 중 실제로 허용한 것
- 실행 자격: 사용자 자격 증명 또는 서비스 계정 위임, 선택 이유
- 결과 처리: 출력의 저장 위치와 외부 공유 여부
- 검토 지점: 사람이 확인할 쿼리·변경·비용·민감 데이터 조건
- 보류 조건: 범위·권한·승인 근거 중 비어 있는 항목
- 감사 단서: 요청 시각, 사용한 도구, 검토자, 다음 재검토 시점

이 기록에서 중요한 부분은 “승인”이라는 한 줄이 아니다. 읽기 요청이라도 범위가 넓으면 민감한 열이나 다른 프로젝트에 닿을 수 있다. 반대로 변경 요청이라도 영향이 작고 되돌리기 쉽다고 판단될 수 있다. 그래서 행위의 이름만으로 위험을 점수화하기보다, 대상과 권한과 결과 처리 방법을 함께 남겨야 한다. 팀의 기존 IAM 정책, 데이터 분류, 변경 관리 절차가 있다면 이 양식은 그것을 대체하지 않고 요청 맥락을 연결하는 메모가 된다.

서비스 계정 위임도 같은 방식으로 다뤄야 한다. 원격 MCP 서버 문서는 IDE에서 연결할 때 사용자 자격 증명 또는 서비스 계정 위임을 사용할 수 있으며, gcloud CLI와 애플리케이션 기본 자격 증명에 대해서는 서비스 계정 위임을 권장한다고 설명한다. 하지만 그 권고를 “모든 에이전트가 넓은 서비스 계정 역할을 가져야 한다”로 바꾸면 안 된다. 어떤 서비스 계정이 어떤 리소스에 어떤 기간 동안 필요한지, 사람이 그 위임을 다시 확인할 위치가 어디인지가 먼저 정리되어야 한다.

보안 도구는 범위 밖의 영향을 남길 수 있다

원격 MCP 서버 문서는 Model Armor를 선택적으로 연결해 프롬프트와 응답을 검사할 수 있다고 설명한다. 동시에 로깅을 켠 Model Armor가 전체 페이로드를 로그에 남길 수 있고, 지원되지 않는 지역에서의 라우팅이 데이터 레지던시 요구와 충돌할 수 있다고 경고한다. 보안 기능을 켰다는 사실만으로 데이터 처리 경로가 닫히지 않는 이유다. 보호 도구의 적용 범위와 로그의 보존·접근 권한도 원래 데이터 요청의 검토 대상에 포함해야 한다.

간접 프롬프트 주입 위험에 관한 Google Cloud 안내도 에이전트가 서비스 계정 또는 사용자 위임 권한으로 동작할 수 있음을 전제로, 리소스 접근 범위를 제한하는 Principal Access Boundaries와 VPC Service Controls 같은 경계를 함께 소개한다. 이 문서는 특정 조직에 하나의 구성을 강제하지 않는다. 다만 에이전트가 데이터에 닿는 경로에서는 프롬프트 내용만 검토해도 충분하지 않으며, 신원·네트워크·리소스 범위가 별도의 통제점이라는 사실을 확인하게 한다.

따라서 도입 초기에는 가장 넓은 데이터 연결을 목표로 삼기보다, 하나의 읽기 전용 작업 단위로 시작하는 편이 판단을 단순하게 만든다. 실제로 어떤 도구 호출이 필요한지, 로그에는 무엇이 남는지, 결과가 기대와 다를 때 어떤 사람이 어디서 멈추는지를 관찰한 뒤에만 범위를 넓힌다. 이 관찰에서 결과가 유용했다는 평가와 권한 경계가 충분했다는 평가는 따로 남긴다. 전자는 업무 품질의 질문이고, 후자는 접근 통제의 질문이어서 한 번의 성공으로 함께 닫을 수 없다. 이는 Data Agent Kit의 성능 효과를 예측하는 말이 아니라, 권한 모델을 추측으로 확장하지 않기 위한 운영 순서다.

연결이 아니라 경계를 검토하는 시점

Data Agent Kit의 일반 제공은 코딩 에이전트가 여러 Google Cloud 데이터 서비스와 만나는 길을 넓혔다. 도입 여부를 결정할 때는 지원 서비스 수보다, 팀이 그 연결을 어떤 책임 단위로 나눌 수 있는지를 먼저 묻는 편이 유용하다. 특정 데이터셋의 메타데이터 읽기처럼 좁은 요청을 명시하고, 필요한 서비스 역할을 확인하며, 결과·보류 이유·검토자를 남기면 “에이전트가 데이터에 접근한다”는 큰 문장이 실제 검토 가능한 결정으로 바뀐다.

공식 문서는 도구 연결, 역할, 원격 MCP 서버의 인가·감사 기능과 보안 옵션을 설명한다. 이 글의 해석은 그 기능을 팀의 자동 승인으로 읽지 말고, 요청 단위의 읽기·변경·보류 경로와 기록을 먼저 만들자는 것이다. 이 구분이 있으면 기능을 더 연결하자는 요구와 아직 범위를 설명할 수 없다는 보류를 같은 화면에서 다룰 수 있다.

출처를 다시 확인할 곳

• Data Agent Kit 일반 제공 발표: 일반 제공 시점과 지원 범위의 변경을 확인한다.
• Data Agent Kit 권한과 API 문서: 서비스별 필요한 역할과 API를 확인한다.
• 원격 MCP 서버 사용 문서: 도구 권한, 서비스 계정 위임, 감사·보안 옵션을 확인한다.
• 간접 프롬프트 주입 위험 완화 안내: 신원과 리소스 범위를 분리해 제한하는 선택지를 확인한다.