AI 에이전트를 위한 Google Looker MCP 대 Google Looker API 비교 (2026)

요약

• Google은 Looker로 진입하는 두 가지 MCP 경로를 제공하지만, 둘 다 SLA가 있는 GA(General Availability) 상태는 아닙니다. Looker에서 관리하는 MCP 서버는 Preview 단계입니다. 오픈 소스 MCP Toolbox for Databases는 현 상태 그대로 제공됩니다.
• 커뮤니티 서버와 Scalekit을 포함한 모든 경로는 동일한 Looker API 4.0을 호출하며 인스턴스의 API 할당량을 공유합니다. 차이점은 신원(Identity)과 도구 표면(tool surface)입니다.
• Looker (Google Cloud core)에서 관리자는 login_user를 통해 일반 사용자를 사칭할 수 없습니다. 다중 사용자 에이전트는 사용자별 OAuth가 필요합니다.
• 어떤 경로도 자격 증명 라이프사이클을 대신 관리해주지 않습니다. API 키는 SSO(Single Sign-On) 비활성화보다 오래 지속되며, Looker OAuth 새로고침 토큰은 한 달 동안만 유효합니다.
• Scalekit의 Google Looker 커넥터는 사용자별 OAuth를 통해 31개 이상의 도구를 제공합니다. 이는 토큰을 금고에 보관하고 새로 고치며, 모든 호출을 기록하고, 범위가 지정된 가상 MCP 서버를 통해 도구를 제공할 수 있습니다.

Looker 에이전트 시작 지점

사용자의 에이전트는 Looker가 필요합니다. 적절한 Explore를 찾고, 요청한 분석가를 위해 저장된 Look을 실행하며, 때로는 그 결과를 주간 일정에 배치해야 합니다. 현실적인 옵션은 다섯 가지입니다: Looker에서 관리하는 MCP 서버, Google의 MCP Toolbox, 커뮤니티 MCP 서버, Looker API 4.0, 그리고 Scalekit의 Looker 커넥터를 직접 사용하거나 MCP를 통해 사용하는 것입니다. 이들은 기능 범위, 인증 모델, 그리고 프로덕션 환경에서 자격 증명을 누가 소유하는지에 따라 다릅니다. 선택 방법은 다음과 같습니다.

각 Looker 경로가 실제로 무엇인지

이 옵션들 중 두 가지는 Google에서 제공하고, 한 가지는 커뮤니티에서, 한 가지는 순수 API이며, 나머지 하나는 Scalekit의 커넥터입니다. 각각은 신원 질문에 다르게 답합니다: 에이전트가 호출하는 Looker 권한은 누구의 것인가?

Looker에서 관리하는 MCP 서버 (Preview)

Looker에서 관리하는 MCP 서버는 Looker 내부에 구축되어 있습니다. OAuth 2.1과 PKCE를 통해 LOOKER_INSTANCE_URL/mcp에서 서비스됩니다. Google은 Next '26에서 이를 발표했으며, 여전히 Pre-GA(General Availability 이전) 조건의 Preview 기능입니다.

이는 Looker (Google Cloud core) 및 Looker (원본) 인스턴스에서 실행됩니다. 고객 호스팅 인스턴스는 지원되지 않습니다.

설정에는 두 가지 관리자 단계가 있습니다. Looker 관리자는 API Explorer를 통해 모든 AI 에이전트를 OAuth 클라이언트로 등록합니다. 모든 도구는 관리자가 활성화하기 전까지 비활성화된 상태로 시작됩니다.

연결형 에이전트는 인증하는 사용자의 Looker 역할을 상속받습니다. 활동은 System Activity에, Google Cloud core에서는 Cloud Audit Logs에 기록됩니다. Google의 참고 자료는 Looker 문서의 "Looker 관리 MCP 서버" 페이지입니다.

데이터베이스용 MCP 툴박스 (The MCP Toolbox for Databases)

데이터베이스용 MCP 툴박스는 Google의 오픈 소스 MCP 서버입니다. 이 Looker 도구 세트는 2025년 8월에 처음 출시되었습니다. Google의 Looker 문서에 따르면, 이 툴박스는 있는 그대로 제공되며, 지원되는 Google Cloud 제품이 아니며, SLA가 없습니다.

사용자는 다음 두 가지 방법 중 하나로 직접 실행해야 합니다:

• 로컬 stdio 프로세스. 환경 변수에서 Looker API 클라이언트 ID와 시크릿을 읽습니다.
• 공유 서비스 (Shared service). HTTPS 리버스 프록시 뒤에서 실행되며, MCP 클라이언트는 OAuth 토큰을 Looker로 전달합니다. Google은 고객이 호스팅하는 인스턴스와 자체 인프라를 사용하려는 팀에 툴박스를 권장합니다.

커뮤니티 Looker MCP 서버 (Community Looker MCP servers)

여러 타사 MCP 서버는 Looker SDK를 감싸고 Google 옵션에는 없는 도구를 추가합니다. 대부분은 stdio를 통해 로컬로 실행되며, 설정 파일에서 Looker 클라이언트 ID와 시크릿을 읽습니다. 이들은 Google이 아닌 개인이나 판매자가 유지 관리합니다. 보안 태세는 작성자들이 선택한 것입니다.

Looker API 4.0

Looker API 4.0은 완전한 애플리케이션 표면입니다. 이는 쿼리, Looks, 대시보드, 폴더, 예약된 계획(scheduled plans), 알림, 렌더링 작업(render tasks), 사용자, 역할, LookML 프로젝트, Git, 임베딩, 그리고 대화형 분석(Conversational Analytics) 엔드포인트를 포괄합니다. 생성된 Python SDK는 수백 개의 메서드를 노출합니다.

인증은 세 가지 형태로 제공됩니다:

• API 자격 증명(credentials). login 엔드포인트에서 클라이언트 ID와 시크릿을 교환하여 단기 토큰을 얻습니다.
• PKCE를 사용한 OAuth. 인스턴스에 등록된 OAuth 클라이언트 애플리케이션을 통해 이루어집니다.
• 관리자 사칭(Admin impersonation). login_user가 다른 사용자 권한으로 실행되는 토큰을 생성합니다. Google의 참고 자료는

Google의 카탈로그는 인터랙티브하게 작업하는 분석가와 LookML 개발자를 위해 구축되었습니다. 배포 워크플로우까지는 지원하지 않습니다. Look을 예약하거나(schedule), 일회성 전송을 트리거하거나, 폴더를 재구성해야 하는 에이전트에게는 API 또는 Scalekit의 커넥터가 필요합니다.

Scalekit의 커넥터는 LookML 작성, 인스턴스 상태 관리, 관리자 작업을 지원하지 않습니다. 이 기능들은 직접 구축하지 않는 한 모두 API 전용입니다.

API에는 상한선이 없습니다. 하지만 사용자가 사용하는 모든 엔드포인트는 자신이 작성하고 테스트하며 유지해야 하는 도구 스키마(tool schema)입니다. 어려운 부분은 API를 호출하는 것이 아니라, 그 스키마를 작성하는 것입니다.

각 옵션별 인증 경로 (The auth path each option puts you on)

Looker API 자격 증명(credentials)은 항상 Looker 사용자에게 바인딩되며, 모든 호출은 해당 사용자로 실행됩니다. 따라서 인증 결정은 신원(identity)에 대한 결정입니다: 각 에이전트의 호출이 어떤 권한을 가지고 있는가?

관리형 MCP (Managed MCP): 사용자별 OAuth, 관리자 등록 클라이언트

관리 서버는 PKCE를 사용한 OAuth 2.1만 허용합니다. 각 사용자는 브라우저 동의 흐름(browser consent flow)을 완료하며, 에이전트는 해당 사용자의 역할과 콘텐츠 접근 권한을 상속받습니다.

제약 사항은 등록 및 범위 설정에 있습니다:

• 미리보기 중 동적 클라이언트 등록 불가. Looker 관리자는 각 에이전트를 고정된 리디렉트 URI를 가진 OAuth 클라이언트로 등록해야 합니다.
• 아직 OAuth 스코프 없음. 접근 제어는 인스턴스 전체의 도구 허용 목록(tool allowlist)과 사용자의 기본 권한으로 이루어집니다. B2B 제품의 경우, 모든 고객의 Looker 관리자가 에이전트가 연결되기 전에 귀하의 에이전트를 등록해야 합니다. 그리고 하나의 허용 목록이 해당 인스턴스의 모든 에이전트를 통제합니다.

MCP 툴박스 (MCP Toolbox): 공유 키 또는 패스스루 OAuth

기본적으로 툴박스는 환경 변수에서 LOOKER_CLIENT_ID와 LOOKER_CLIENT_SECRET을 읽습니다. 그러면 에이전트를 누가 요청했는지에 관계없이, 해당 키를 소유한 단일 Looker 사용자로 모든 도구 호출이 실행됩니다.

Shared-service mode는 신원(identity) 문제를 해결합니다. LOOKER_USE_CLIENT_OAUTH=true를 설정하고, MCP 클라이언트들이 인증 서버로 Looker를 가리키는 보호된 리소스 메타데이터 파일(Protected Resource Metadata file)을 게시합니다. 그런 다음 프록시, TLS 종료(termination), 그리고 Toolbox 프로세스를 운영해야 합니다. 동일한 관리자 OAuth-클라이언트 등록이 여전히 적용됩니다.

Direct API: API 키, OAuth 또는 sudo

API는 세 가지 신원 모델을 제공합니다:

• API 키: 하나의 사용자에게 속합니다. Google은 프로덕션 환경에서 관리자 권한(admin-bound)이 부여된 키 사용을 권장하지 않습니다. 대신 최소 권한 서비스 계정(least-privilege service accounts)을 생성해야 합니다.
• PKCE를 사용한 OAuth: 사용자별 액세스 토큰과 한 달 동안 지속되는 새로고침 토큰(refresh token)을 발급합니다.
• login_user: 관리자가 다른 사용자로 실행되는 토큰을 발행할 수 있게 합니다. 기본적으로, 그 결과로 발생하는 활동은 대상 사용자(target user)가 아닌 관리자에게 귀속됩니다. ### Looker에서의 위임 제한 (Google Cloud core)

sudo 단축키는 Looker (Google Cloud core)에서 작동하지 않습니다. 여기서는 두 가지 조건이 충족되지 않으면 login_user가 거부됩니다:

• 호출자(caller)가 관리자 역할(Admin role)을 가진 API 전용 서비스 계정인 경우.
• 대상(target)이 임베드 사용자(embed user)인 경우. 일반 사용자는 위임될 수 없으며, Google의 API 참조 문서는 대신 OAuth를 사용할 것을 안내합니다. 만약 에이전트가 Google Cloud core에서 실제 분석가들을 지원한다면, 하나의 관리자 자격 증명으로는 그들 각자의 역할을 수행할 수 없습니다. 사용자별 OAuth(Per-user OAuth)만이 호출에 각 분석가의 권한을 가져갈 수 있는 유일한 모델입니다.

모든 경로에서 사용자별 격리가 필요합니다

멀티테넌트 B2B 에이전트는 모든 경로에서 사용자별 자격 증명 격리(per-user credential isolation)가 필요합니다. 관리형 MCP 서버의 OAuth 플로우는 사용자당 토큰을 제공합니다. API의 OAuth 플로우 역시 사용자당 토큰을 제공합니다. 어느 쪽 경로도 저장, 로테이션 또는 취소 문제를 해결하지 못합니다.

이것들은 어떤 경로를 선택하든 관계없이 인프라 문제입니다. Scalekit의 커넥터는 사용자별로 연결된 계정을 하나 유지합니다. 사용자가 Looker에서 할 수 없는 것은 에이전트도 할 수 없습니다.

커뮤니티 및 자체 호스팅(self-hosted) Looker MCP 서버의 위험성

로컬 및 커뮤니티 서버는 Claude Desktop이나 Cursor에서 Looker 데이터를 가장 빠르게 확인할 수 있는 방법입니다. 또한 아무도 검토하지 않은 인프라에 BI 자격 증명을 옮기게 합니다. 이러한 위험은 실제 사용 과정에서 드러납니다.

평문 설정 파일에서의 자격 증명 노출

표준 설정 방식은 Looker 클라이언트 ID와 시크릿을 개발자 노트북의 mcp.json 파일이나 환경 블록에 저장합니다. 해당 파일을 읽을 수 있는 모든 로컬 프로세스가 시크릿을 읽을 수 있게 됩니다. 키가 리포지토리, dotfiles, 화면 공유 등으로 복사되면 더 넓게 퍼집니다.

API 자격 증명은 특정 사용자에게 바인딩됩니다. 따라서 유출된 키는 해당 사용자가 볼 수 있는 모든 Explore 및 폴더를 노출합니다. 만약 그 키가 관리자(admin)의 것이라면, 전체 인스턴스가 노출됩니다.

계정 접근 권한을 가진 검토되지 않은 코드

stdio MCP 서버는 운영 체제 사용자 권한과 Looker 키의 권한으로 실행됩니다. 시작할 때마다 최신 패키지를 로드하는 설정은 검토 없이 새로운 코드를 가져옵니다.

LookML 파일 편집, 폴더 삭제 또는 스키마 읽기를 노출하는 커뮤니티 서버는 이러한 접근 권한을 자체 코드에 부여합니다. 이는 에이전트에 도달하는 모든 프롬프트 주입(prompt injection)에도 동일한 접근 권한을 부여합니다.

유지보수 및 오류 발생

Looker는 자체 일정에 따라 API 계약을 변경합니다. API 3.0과 3.1은 23.18 릴리스에서 제거되었고, 쿼리 ID는 슬러그 값(slug values)으로 이동했습니다. Google은 Toolbox의 사전 구축된 Looker 도구를 pre-1.0으로 표시하며 버전 간 도구 변경을 예상합니다.

커뮤니티 서버가 이러한 변화를 추적하는 것은 해당 유지보수자가 할 때뿐입니다. 도구가 조용히 고장 나면, 에이전트는 오래되거나 실패한 데이터로 계속 답변하게 됩니다.

감사 추적(audit trail) 누락

Looker의 시스템 활동(System Activity) 기록은 API 호출을 해당 자격 증명에 대해 기록합니다. 공유된 키를 사용하면 모든 최종 사용자로부터의 모든 호출이 하나의 Looker 사용자 아래로 들어옵니다. 기본 login_user 토큰을 사용하는 경우, 활동은 관리자에게 귀속됩니다.

어떤 기록도 감사자에게 누가 에이전트에게 쿼리 실행을 요청했는지, 또는 어떤 에이전트 실행이 대시보드를 건드렸는지 알려주지 않습니다.

정책 및 책임 노출

Looker의 API 인증은 사용자 로그인과 독립적입니다. 2FA(2단계 인증), SAML, LDAP는 API 호출에 적용되지 않습니다. 사용자를 로그인 프로토콜에서 제거해도 해당 사용자의 API 자격 증명은 삭제되지 않습니다.

따라서 에이전트 설정에 남아있는 키는 누군가 해당 키를 삭제하거나 Looker 사용자 계정을 삭제하기 전까지 직원들의 SSO(Single Sign-On) 접근 권한보다 오래 지속됩니다. 또한, 라이선스 추가, SLA(Service Level Agreement) 없음, 그리고 Pre-GA(General Availability 이전 단계) 약관 등이 보안 설문지에 답변하기 어렵게 만듭니다.

추천 자료: 프로덕션 에이전트를 위한 MCP 보안 위험.

프로덕션 환경에서 사용자가 소유하는 것들

각 경로에 대해 실질적인 질문은 동일합니다. 무엇이 고장 나는지, 무엇에 주의를 기울여야 하는지, 그리고 누가 그것을 수정해야 하는가입니다.

관리형 MCP 경로(On the managed MCP path)

Google이 서버를 호스팅하고 도구 스키마를 유지 관리합니다. 사용자가 소유하는 것은 다음과 같습니다:

• 모든 인스턴스에 대한 OAuth 클라이언트 등록.
• 전역 도구 허용 목록(global tool allowlist).
• 도구 매니페스트가 스스로 새로 고쳐지지 않기 때문에, 허용 목록 변경 후 재연결되는 클라이언트 처리.
• 실행하는 모든 MCP 클라이언트 내부의 토큰 저장소. Preview 단계에서는 서버가 고정된 용량으로 실행되며, Google은 피크 시간대에 간헐적인 타임아웃이 발생할 수 있다고 경고합니다. 여기에는 SLA가 없습니다.

Toolbox 또는 커뮤니티 경로(On the Toolbox or community path)

사용자가 관리형 경로에서 요구하는 모든 것과 더불어 프로세스 자체를 소유합니다: