리소스

/

ACP 실습 노트

[25편] MCP로 DB를 조회해도, 정해 둔 권한은 그대로였다 — QueryPie Community MCP

MCP 연동 · DB 접근 제어

2026년 11월 9일

AI 도구에 DB를 연결할 때는 누가 어떤 데이터를 볼 수 있는지가 먼저 궁금했다. 업무에 필요한 주문 정보는 조회하되, 정산 자료처럼 따로 관리하는 데이터는 기존 권한에 맞춰 보호하고 싶었다.

 

QueryPie Community에는 MCP 서버가 들어 있다. 이번에는 MCP Inspector를 연결해 주문을 조회하고, 같은 계정으로 정산 테이블도 열어 봤다. 주문 한 건은 정상적으로 나왔고, 정산 테이블은 접근 권한이 없다는 메시지와 함께 차단됐다. 두 요청 모두 QueryPie의 감사 기록에서 찾을 수 있었다.

 

 

평소 쓰던 개발자 계정으로 시작했다

 

앞선 DB 실습에서 사용했던 Demo Developer 계정을 그대로 썼다. Orders Control Lab 연결에는 Read-Only 권한이 있었고, 허용된 작업은 Select였다. MCP 실습을 위해 권한을 추가하지는 않았다.

 

화면 1. Demo Developer에게 부여된 주문 DB의 조회 권한을 확인했다.
화면 1. Demo Developer에게 부여된 주문 DB의 조회 권한을 확인했다.

 

주문 테이블은 조회할 수 있지만, 정산 테이블에는 앞서 설정한 접근 제한이 적용돼 있다. 이 차이가 MCP에서도 유지되는지가 이번에 가장 보고 싶었던 부분이었다.

 

 

QueryPie 주소를 등록하고 MCP에 연결했다

 

MCP는 AI 도구 등이 외부 서비스의 기능을 호출할 때 사용하는 연결 방식이다. 이번에는 요청과 응답을 직접 볼 수 있는 MCP Inspector로 실습했다.

 

서버 주소에는 http://localhost:8000/api/mcp를 넣고 Streamable HTTP로 연결했다. localhost는 내 Mac에 설치한 실습용 QueryPie 주소다. 클라이언트에는 DB 비밀번호를 입력할 필요가 없었다.

 

화면 2. MCP 클라이언트의 연결 대상으로 QueryPie Community 주소를 등록했다.
화면 2. MCP 클라이언트의 연결 대상으로 QueryPie Community 주소를 등록했다.

 

Demo Developer로 로그인한 브라우저에서 연결하자 인증이 완료되고 Connected로 바뀌었다. 사용자 확인 도구인 iam_user_me를 실행해 보니 이름과 로그인 ID도 Demo Developer, demo-dev로 나왔다. 어떤 사용자의 권한으로 요청하는지 바로 확인할 수 있었다.

 

화면 3. MCP에 인증된 사용자가 Demo Developer인지 확인했다.
화면 3. MCP에 인증된 사용자가 Demo Developer인지 확인했다.

 

 

내게 허용된 DB 목록에서 주문 DB를 골랐다

 

dac_list_accessible_connections를 실행하자 Orders Control Lab과 Orders Demo MySQL이 나왔다. QueryPie 사용자 화면에서 보던 두 연결이었다.

 

화면 4. 현재 사용자에게 접근이 허용된 DB 연결 두 개가 반환됐다.
화면 4. 현재 사용자에게 접근이 허용된 DB 연결 두 개가 반환됐다.

 

이 목록에는 다음 조회에 사용할 cluster_uuid도 함께 있었다. Orders Control Lab의 값을 선택해 쿼리 도구에 넣었다. 이미 QueryPie에 등록해 둔 DB 연결과 사용자 권한을 그대로 사용할 수 있어 준비가 간단했다.

 

 

주문 한 건을 조회해 봤다

 

이번 버전의 조회 도구 이름은 dac_query였다. 여기에 주문 4003의 주문번호, 상태, 금액을 가져오는 SELECT를 입력했다.

 

123
SELECT order_id, status, total_amountFROM orders_control.ordersWHERE order_id = 4003;

 

실행 결과는 한 행이었다. 주문번호는 4003, 상태는 DELIVERED, 금액은 18500.00으로 나왔다. 앞서 변경했던 주문 상태를 MCP에서도 확인할 수 있었다.

 

화면 5. MCP로 조회한 주문 한 건의 결과가 반환됐다.
화면 5. MCP로 조회한 주문 한 건의 결과가 반환됐다.

 

 

정산 테이블은 같은 연결에서도 열리지 않았다

 

이번에는 같은 도구와 DB 연결로 settlement_details를 조회했다. 주문번호 4002에 해당하는 정산번호와 정산금액을 읽는 SELECT였다.

 

123
SELECT settlement_id, order_id, settlement_amountFROM orders_control.settlement_detailsWHERE order_id = 4002;

 

결과 대신 해당 테이블에 접근할 권한이 없다는 메시지가 나왔다. 주문 테이블을 조회할 수 있는 계정이어도, 별도로 제한한 정산 자료까지 열리지는 않았다.

 

화면 6. 정산 테이블 조회는 기존 접근 제한에 따라 차단됐다.
화면 6. 정산 테이블 조회는 기존 접근 제한에 따라 차단됐다.

 

MCP용으로 정산 제한 규칙을 새로 만들지 않았는데도 같은 기준이 적용됐다. 업무에 필요한 조회는 허용하면서 민감한 테이블은 보호할 수 있었다. 새로운 도구를 연결할 때마다 권한 체계를 따로 만들 필요가 줄어드는 부분이다.

 

 

감사 기록에도 MCP에서 실행한 요청으로 남았다

 

관리자 화면의 Audit → Databases → Query Audit를 열었다. 방금 실행한 주문 조회와 정산 테이블 조회가 나란히 있었다. 실행자는 둘 다 Demo Developer, 연결은 Orders Control Lab이었다.

 

주문 조회의 결과는 Success였다. 상세 화면의 Executed From에는 MCP가 표시됐다. 어떤 사용자가 어느 경로로 DB를 조회했는지 기존 감사 화면에서 함께 볼 수 있었다.

 

화면 7. 주문 조회 기록에 실행자, DB 연결과 MCP 출처가 남았다.
화면 7. 주문 조회 기록에 실행자, DB 연결과 MCP 출처가 남았다.

 

정산 테이블 요청은 Failure와 Prevented로 기록됐다. 상세를 열어 보니 실행하려던 SELECT와 테이블 접근 권한 오류가 그대로 있었다. 클라이언트에서 본 차단 결과를 관리자가 감사 기록으로도 확인할 수 있었다.

 

화면 8. 차단된 정산 조회의 SQL과 오류 메시지도 감사 상세에 남았다.
화면 8. 차단된 정산 조회의 SQL과 오류 메시지도 감사 상세에 남았다.

 

이번에 가장 마음에 든 점은 연결 이후의 관리가 익숙했다는 것이다. MCP에서 조회해도 QueryPie 사용자와 DB 권한을 그대로 쓰고, 실행한 SQL은 같은 감사 화면에서 확인했다. AI 도구와의 연동을 준비하는 입장에서도 기존 접근 통제와 감사 체계를 이어서 활용할 수 있다는 점이 매력적이었다.

 

이번 실습은 QueryPie Community 11.6.7과 MCP Inspector 2.14.0에서 진행했다. Inspector로 MCP 도구를 직접 호출해 사용자 인증, 주문 조회, 정산 테이블 차단과 감사 기록을 확인했다.

 

참고: Community MCP 설정 가이드 · Query Audit