[13편] 정산 정보가 필요할 때 — QueryPie 제한 데이터 접근 승인 실습

9편에서는 주문 테이블은 조회할 수 있게 두고, 정산 테이블은 접근을 제한했다. 평소 주문 상태만 확인하는 개발자에게 정산 정보까지 열어 줄 필요는 없었다.

그런데 주문 금액과 정산 내역을 대조해야 하는 업무가 생기면 어떨까? 이번에는 QueryPie의 Restricted Data Access Request로 제한된 정산 테이블에 접근을 요청해 봤다. 사용 시간과 사유를 적어 승인받은 뒤, DBeaver에서 같은 쿼리를 다시 실행했다.

승인 전에는 막혔던 정산 조회가 승인 후에는 성공했다. 기존 주문 조회도 계속 사용할 수 있었다. 이번 글은 그때 확인한 화면과 결과를 정리한 후기다. 실습 데이터는 모두 앞선 글에서 만든 가상 데이터다.

1. 정산 테이블은 여전히 조회할 수 없었다

먼저 개발자 계정의 DBeaver에서 settlement_details 테이블을 조회했다. 주문 4002번의 정산 번호, 주문 번호, 정산 금액을 확인하는 쿼리였다.

결과 창에는 해당 테이블에 접근할 권한이 없다는 메시지가 나왔다. 앞서 설정한 Data Access 정책이 정산 데이터 접근을 제한하고 있었다.

이번에는 이 제한 정책을 유지하면서 필요한 접근을 승인받아 보기로 했다. 정산 확인 업무가 생겼다는 이유로 공통 정책을 변경할 필요 없이 처리할 수 있는지 보고 싶었다.

2. 정산 정보 접근을 승인할 담당자를 정했다

관리자 화면의 Approval Rules에서 정산 조회용 승인 규칙을 만들었다. 이름은 Orders Lab - Settlement Review Approval, 요청 유형은 Restricted Data Access Request로 선택했다.

승인자는 Demo Approver로 지정했다. 개발자가 요청하고 담당자가 검토하도록 나눴으며 자기 승인은 허용하지 않았다.

DB 연결 권한을 요청하는 것과, 이미 연결한 DB 안의 제한된 데이터를 요청하는 것은 업무가 다르다. QueryPie에서는 이번처럼 정산 테이블 접근에 맞는 요청 유형과 승인 규칙을 따로 구성할 수 있었다.

3. 필요한 테이블과 사용 시간을 적어 요청했다

개발자 계정에서 Restricted Data Access Request를 열었다. 제목은 ‘주문 4002 정산 금액 대조를 위한 정산 테이블 조회’로 적었다.

Orders Control Lab 연결의 orders_control 데이터베이스에서 settlement_details 테이블을 선택했다. 사용 시간은 실습 당일인 11월 8일 오후 5시부터 6시까지 한 시간으로 정했다. 사유에는 정산 금액을 대조하기 위해 접근이 필요하다고 적었다.

이번 승인 요청의 대상은 settlement_details 테이블이다. 주문 4002번은 정산을 확인하려는 업무 대상이며, 실제 조회할 때 WHERE 조건으로 지정했다.

요청 내용을 남기고 기다리는 흐름이 분명했다. 관리자에게 ‘잠깐 열어 주세요’라고 따로 설명하는 대신, 대상과 기간, 사유를 한 요청에 담을 수 있었다.

4. 담당자가 내용을 확인하고 승인했다

Demo Approver 계정의 Received Requests에서 개발자가 올린 요청을 열었다. 신청자와 대상 테이블, 요청한 사용 시간, 업무 사유를 확인한 뒤 승인했다.

승인 의견에는 정산 금액 대조를 위한 접근을 허용하며, 요청된 사용 시간이 오후 5시부터 6시까지라는 내용을 남겼다. 처리가 끝난 요청은 Done 목록에 Approved 상태로 나타났다.

도입 담당자 입장에서는 예외 권한에도 근거가 남는다는 점이 유용하다. 누가 정산 정보를 필요로 했는지, 어떤 업무 때문에 요청했는지 승인 내용과 함께 찾아볼 수 있다.

5. 같은 DBeaver에서 정산 금액이 조회됐다

승인을 마친 뒤 개발자가 사용하던 DBeaver로 돌아왔다. 승인 전에 실패했던 정산 조회를 같은 연결에서 다시 실행했다.

이번에는 결과가 나왔다. 정산 번호 9002, 주문 번호 4002, 가상 정산 금액 87,000이 표시됐다. 공통 접근 제한 정책을 삭제하거나 개발자의 DB 연결 권한을 새로 바꾸는 작업은 하지 않았다.

이어 기존 orders 테이블도 조회해 봤다. 주문 4002번의 상태와 금액이 정상적으로 표시됐다. 개발자는 익숙한 도구에서 정산 확인과 원래 하던 주문 조회를 이어갈 수 있었다.

6. 제한된 데이터도 업무에 맞게 승인받을 수 있었다

이번 실습은 9편에서 설정한 접근 제한을 실제 업무와 연결해 본 경험이었다. 평소에는 정산 테이블을 보호하고, 필요한 업무가 생기면 사용자가 대상과 기간을 정해 요청하는 식으로 운영할 수 있었다.

직접 써보니 접근 제한과 예외 승인을 함께 관리할 수 있다는 점이 가장 좋았다. 사용자는 필요한 데이터를 요청할 수 있고, 담당자는 사유와 범위를 확인한 뒤 허용할 수 있다.

승인을 받은 개발자는 DBeaver에서 하던 작업을 계속했다. 데이터 보호 규칙을 두면서도 업무에 필요한 접근을 처리할 수 있다는 점에서, 도입 담당자가 운영 방식을 설명하기 좋은 기능이었다.