[5편] QueryPie ACP에서 DB 권한 요청하고 승인받기 — DBeaver 조회까지 직접 해봤다

“주문 정산 내역을 확인해야 하는데, 내일까지 DB 조회 권한을 받을 수 있을까요?”

DB를 운영하다 보면 이런 요청을 자주 받게 된다. 어떤 DB가 필요한지, 조회만 하면 되는지, 언제까지 쓸 것인지 확인하고 권한을 열어주는 일이다. 요청이 몇 건 없을 때는 메신저로도 처리할 수 있지만, 사람이 늘어나면 누가 어떤 이유로 권한을 받았는지 함께 관리하는 일이 중요해진다.

지난 4편에서는 QueryPie ACP에서 읽기 권한으로 쿼리를 제한하고, 권한을 회수했을 때 접속이 차단되는 것을 확인했다. 이번에는 사용자가 직접 권한을 요청하고 담당자가 승인하는 과정을 해봤다. 승인받은 뒤에는 DBeaver에서 실제 주문 데이터도 조회했다.

이번에도 Mac에 설치한 QueryPie ACP Community 11.6.7과 실습용 MySQL을 사용했다. 요청자는 Demo Developer, 승인 담당자는 Demo Approver로 나눴다.

1. 먼저, 누가 승인할지 정해뒀다

관리자 화면의 Workflow Management → Approval Rules에서 DB 접근 요청용 규칙을 만들었다. 이름은 ‘Orders Lab - Read Access Approval’로 정하고, 승인 담당자로 Demo Approver를 지정했다.

이번에는 담당자 한 명이 승인하면 처리되도록 설정했다. 요청자가 자기 요청을 승인하는 Self-Approval은 꺼뒀다. 권한을 쓰는 사람과 승인하는 사람의 역할을 분리한 셈이다.

규칙을 저장한 뒤 개발자 계정으로 요청 화면을 열었더니, 방금 만든 규칙과 승인 담당자가 표시됐다. 매번 누구에게 요청해야 하는지 찾을 필요 없이, 정해진 담당자에게 요청을 올릴 수 있었다. 운영팀 입장에서도 승인 절차를 미리 정해두고 같은 방식으로 처리하기 좋겠다.

2. 필요한 DB와 권한, 사용 기한을 한 번에 요청했다

개발자 화면에서 Workflow → Submit Request → DB Access Request로 들어갔다. 이번 상황은 주문 정산 내역과 배송 상태를 확인하는 작업이다. 데이터 수정은 필요하지 않아서 ‘Orders Control Lab’의 Read-Only 권한만 선택했다.

제목은 ‘주문 정산 확인을 위한 읽기 권한 요청’으로 적었다. 요청 사유에는 확인할 테이블과 작업 목적, 조회만 한다는 내용, 필요한 기간을 함께 남겼다.

여기서 눈에 들어온 것은 날짜가 두 개라는 점이었다. Approval Expiration Date는 승인 처리 기한이고, Access Expiration Date는 DB 접근 만료일이다. 이번에는 11월 8일에 승인받아 11월 9일까지 사용하는 요청으로 작성했다.

‘DB 권한을 주세요’라는 한마디 대신, 어디에 어떤 권한이 언제까지 필요한지가 요청서에 담겼다. 승인하는 쪽에서도 필요한 정보를 다시 물어보는 수고를 줄일 수 있는 구성이다. 특히 조회 업무에 맞춰 읽기 권한과 사용 기한을 함께 정할 수 있다는 점이 좋았다.

3. 제출한 요청은 승인 대기 상태로 남았다

Submit을 누르자 Sent Requests의 In Progress에 요청이 등록됐다. 상세 화면에는 요청자와 승인 담당자가 나란히 표시되고, 아래에서 신청한 DB와 Read-Only 권한을 다시 확인할 수 있었다.

요청을 보낸 사람도 진행 상태를 직접 볼 수 있었다. 메신저 대화를 다시 찾아보지 않아도 내가 무엇을 요청했고 누구의 승인을 기다리는지 분명했다. 여러 건을 요청하는 상황에서는 이런 목록이 꽤 편하겠다.

4. 담당자 계정에서 내용을 확인하고 승인했다

이번에는 Demo Approver로 로그인했다. 대시보드의 Received Requests To Do에 요청 한 건이 잡혀 있었다. 열어보니 개발자가 작성한 제목, 요청 사유, 대상 DB, 읽기 권한과 접근 만료일이 그대로 보였다.

조회 업무에 맞는 요청인지 확인한 뒤 Approve를 눌렀다. 승인할 때 의견을 남길 수 있어서, ‘주문 정산 확인 목적의 읽기 권한을 승인합니다. 접근 만료일은 2026-11-09입니다.’라고 적었다.

처리를 마치자 요청은 Received Requests의 Done으로 이동했고, 대상 DB의 상태가 Approved로 바뀌었다. 요청한 사람과 승인한 사람, 승인된 권한이 같은 요청 안에 남았다.

도입 담당자 입장에서 마음에 든 부분은 이 기록이었다. 나중에 ‘이 사람에게 왜 DB 권한이 있지?’라는 질문이 생겼을 때, 권한을 신청한 업무 사유와 승인 결과를 찾아볼 수 있다. 권한 목록만 보고 사용 목적을 추측하는 일이 줄어든다.

5. 승인받은 권한으로 DBeaver에서 바로 조회해봤다

개발자 계정으로 돌아와 Databases에서 Orders Control Lab을 열었다. 권한은 Read-Only (User), 허용된 작업은 Select, 상태는 Active였다. 만료일도 요청한 날짜에 맞춰 2026-11-09 23:59:59로 표시됐다.

관리자 화면에서 사용자 권한을 한 번 더 수동으로 추가하지 않았다. 담당자가 승인한 내용이 실제로 사용할 권한에 반영돼 있었다. 승인 처리와 권한 부여가 이어지니 담당자가 같은 내용을 두 번 입력할 필요가 없었다.

이어서 DBeaver 26.2.4에서 기존에 만들어둔 ‘Orders Control - QueryPie’ 연결을 사용했다. QueryPie 프록시를 거치는 연결로 접속해 다음 SELECT를 실행했다.

SELECT *FROM orders_control.ordersORDER BY order_id;

주문 4001, 4002, 4003의 상태와 금액이 정상적으로 조회됐다. 개발자가 권한을 요청하고, 담당자가 승인하고, 익숙한 DB 도구로 데이터를 확인하는 과정까지 끝냈다.

권한을 주는 과정까지 관리할 수 있었다

직접 해보니 QueryPie의 접근 요청 기능은 운영 업무와 잘 맞았다. 개발자는 필요한 DB와 권한, 기간을 정해 신청하고, 담당자는 업무 사유를 보고 승인한다. 승인 결과는 실제 접속 권한에 반영되고, 처리한 요청은 완료 목록에서 다시 볼 수 있다.

특히 이번처럼 정산 확인을 위해 잠시 조회해야 하는 업무에 유용하겠다. 처음 요청할 때부터 읽기 권한과 접근 만료일을 함께 정해두니, 필요한 범위와 기간을 분명하게 관리할 수 있었다. 개발자는 쓰던 DBeaver를 그대로 사용하면 됐다.

지난 편에서 확인한 쿼리 통제와 권한 회수에, 이번 요청·승인 절차까지 더해졌다. 누가 DB에 접속할 수 있는지뿐 아니라, 어떤 업무 때문에 그 권한을 받았는지까지 QueryPie 안에서 확인할 수 있다는 점이 가장 마음에 남았다.