two-thirteen
에이전트에게 데이터베이스를 열어줄 때: 관리형 MCP 서버와 도구 설계의 입도
에이전트에게 데이터베이스를 열어줄 때: 관리형 MCP 서버와 도구 설계의 입도
2026-10-31 AI Agents

에이전트에게 데이터베이스를 열어줄 때: 관리형 MCP 서버와 도구 설계의 입도

Next '26에서 데이터베이스·Cloud Run·Looker·Cloud Storage용 관리형 원격 MCP 서버가 대거 발표됐습니다. 범용 execute_sql 도구 대신 좁고 파라미터화된 도구를 설계해야 하는 이유와 MCP Toolbox 설정 예시, 비용 안전장치를 다룹니다.

MCP 서버가 쏟아진 행사

Next '26 발표 목록에서 MCP라는 단어를 세어 보다가 중간에 그만뒀습니다. 그만큼 많았습니다.

  • 데이터베이스용 관리형 원격 MCP 서버
  • Cloud Run의 완전 관리형 원격 MCP 서버(GA)
  • 구글이 관리하는 Looker MCP 서버와 MCP Toolbox
  • Cloud Storage MCP 서버, Workspace MCP 서버(프리뷰)
  • VS Code와 Gemini CLI용 MCP 도구를 묶은 Data Agent Kit
  • Gemini Enterprise 앱에 직접 만든 MCP 서버를 붙이는 BYO-MCP

MCP(Model Context Protocol)는 에이전트가 외부 도구를 부르는 표준 규약입니다. USB 포트에 비유하곤 합니다. 규격만 맞으면 어떤 에이전트든 어떤 도구든 꽂아 쓸 수 있습니다.

연결이 쉬워졌다는 건 좋은 소식입니다. 동시에 질문이 하나 생깁니다. 무엇을 꽂을 것인가.

가장 쉬운 선택, execute_sql

에이전트에게 데이터베이스를 연결할 때 가장 쉬운 방법은 SQL 실행 도구 하나를 주는 것입니다. 에이전트가 알아서 쿼리를 짜서 실행합니다. 데모에서는 마법처럼 보입니다.

운영에 올리려고 하면 걱정이 줄줄이 따라옵니다.

먼저 비용입니다. 파티션 필터 없이 수 TB 테이블 전체를 훑는 쿼리를 에이전트가 만들 수 있습니다. 사용자 질문 하나에 몇만 원이 나갈 수도 있습니다.

다음은 범위입니다. 서비스 계정이 읽을 수 있는 모든 테이블을 에이전트도 읽을 수 있습니다. 사용자가 "급여 테이블 보여줘"라고 하면 어떻게 될까요.

마지막은 정확도입니다. 앞선 Knowledge Catalog 글에서 다뤘듯, 매출처럼 생긴 컬럼이 여러 개면 에이전트는 그중 하나를 그럴듯하게 고릅니다.

도구는 좁을수록 안전하다

여기서 생각을 바꿔 보면 답이 보입니다. 에이전트에게 SQL을 짜게 할 게 아니라, 우리가 미리 짜둔 쿼리를 고르게 하는 겁니다.

"최근 수정된 위키 문서 검색", "특정 문서의 변경 이력 조회", "팀별 문서 수 집계". 이렇게 질문 유형별로 좁은 도구를 만들고, 바뀌는 부분만 파라미터로 받습니다.

에이전트의 자유도는 줄어듭니다. 대신 비용, 범위, 정확도가 전부 우리 통제 안으로 들어옵니다. 쿼리는 사람이 리뷰한 것이고, 테이블 선택은 이미 끝났고, 파티션 필터도 박혀 있습니다.

MCP Toolbox for Databases가 정확히 이런 방식을 지원합니다. 설정 파일에 데이터 소스와 도구를 선언하면, 그게 MCP 도구로 노출됩니다.

sources:
  wiki-bq:
    kind: bigquery
    project: my-project

tools:
  search-recent-wiki-docs:
    kind: bigquery-sql
    source: wiki-bq
    description: 제목에 키워드가 포함된 위키 문서를 최근 수정순으로 최대 20건 찾습니다.
    parameters:
      - name: keyword
        type: string
        description: 문서 제목에 포함될 검색어
    statement: |
      SELECT doc_id, title, updated_at
      FROM `my-project.wiki.documents`
      WHERE updated_at >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 180 DAY)
        AND STRPOS(LOWER(title), LOWER(@keyword)) > 0
      ORDER BY updated_at DESC
      LIMIT 20

toolsets:
  wiki-reader:
    - search-recent-wiki-docs

설정 키 이름은 Toolbox 버전에 따라 바뀐 적이 있으니, 쓰는 버전의 문서를 확인하는 게 좋습니다.

도구의 description에 공을 들여야 합니다. 에이전트는 이 문장을 읽고 언제 이 도구를 쓸지 판단합니다. "최대 20건", "최근 수정순"처럼 결과의 성격까지 적어두면 에이전트가 결과를 해석할 때도 덜 헤맵니다.

그래도 자유 쿼리가 필요하다면

탐색적 분석처럼 질문을 미리 예상할 수 없는 경우도 있습니다. 그럴 때는 자유 쿼리 도구를 주되 안전장치를 겹겹이 겁니다.

  • 전용 서비스 계정에 분석용 데이터셋 읽기 권한만 줍니다.
  • 쿼리당 최대 처리 바이트(maximum_bytes_billed)를 걸어 비싼 쿼리는 실행 전에 실패하게 합니다.
  • 실행 전에 dry run으로 처리량을 먼저 확인하게 합니다.
  • 결과 행 수를 제한해 대량 유출을 막습니다.

Next '26에서 발표된 "데이터 에이전트용 도구" 중 고정밀 text-to-SQL이 있었습니다. 정확도는 좋아질 겁니다. 하지만 정확한 쿼리가 곧 안전한 쿼리는 아닙니다. 둘은 따로 챙겨야 합니다.

관리형이라 달라지는 것

지금까지는 MCP 서버를 직접 띄우고 운영해야 했습니다. 컨테이너를 만들고, 인증을 붙이고, 스케일링을 신경 써야 했습니다.

관리형 원격 MCP 서버는 이 부담을 덜어줍니다. 특히 Cloud Run의 관리형 MCP 서버가 GA로 나온 건 반가운 소식입니다. 직접 만든 도구 서버도 같은 방식으로 올리고 관리할 수 있다는 뜻이니까요.

다만 관리형이라고 도구 설계까지 대신해 주지는 않습니다. 서버를 띄우는 일이 쉬워질수록, 어떤 도구를 어떤 입도로 노출할지가 더 중요한 결정이 됩니다.

MCP를 처음 도입한다면 범용 도구 하나 대신 좁은 도구 다섯 개로 시작해 보길 권합니다. 사용 로그를 보면서 자주 실패하는 질문 유형에 맞춰 도구를 하나씩 늘려가면 됩니다. 에이전트의 능력은 결국 우리가 쥐여준 도구의 품질을 넘지 못합니다.