[10편] “필요한 컬럼만 조회해 주세요” — QueryPie Query Rules로 SQL 사용 규칙 적용하기

“조회할 때는 필요한 컬럼만 적어 주세요.” DB를 함께 사용하는 팀이라면 한 번쯤 정해 봤을 규칙이다. 주문 상태만 확인하면 되는데 습관적으로 SELECT *를 쓰면 금액 같은 다른 컬럼까지 함께 가져오게 된다.

이런 사용 규칙을 QueryPie에서 적용해 보면 어떨까. 이번에는 Query Rules를 열어, 실습용 주문 테이블에 대한 SELECT * 형태의 조회를 제한해 봤다. 차단할 때 사용자가 볼 안내 문구도 직접 정했다.

설정만 보고 끝내지 않고, 패턴 테스트부터 DBeaver의 실제 실행, 감사 로그까지 차례로 확인했다.

주문 상태만 필요한데 금액까지 조회되고 있었다

환경은 QueryPie ACP Community 11.6.7과 DBeaver 26.2.4다. Demo Developer 계정으로 Orders Control Lab에 접속했다. 데이터는 앞서 만든 가상 주문 3건을 그대로 사용했다.

먼저 SELECT * FROM orders_control.orders 형태의 쿼리를 실행했다. 결과에는 order_id, status, total_amount가 모두 나왔다. 주문 상태를 확인하는 업무라면 앞의 두 컬럼만 있어도 된다.

이번에 정한 팀 규칙은 간단하다. 이 주문 조회에서는 별표 대신 필요한 컬럼을 명시한다. 금액 컬럼 자체를 접근 금지 대상으로 지정한 것은 아니고, SQL을 작성하는 방식을 관리하는 실습이다.

실습 연결에 적용할 SQL 규칙을 만들었다

관리자 화면에서 Databases → Policies → Query Rules로 이동해 Create Query Rule을 눌렀다. 대상은 Connection으로 두고 Orders Control Lab만 선택했다.

Match Type은 RegExp, Action은 Deny로 지정했다. 패턴에는 SELECT * FROM orders_control.orders 형태를 찾도록 입력했다. 이번 글에서는 직접 실행한 이 형태의 SQL을 기준으로 결과를 비교했다.

Error Message에는 “Orders Lab policy: SELECT * is restricted. Please specify the required columns.”를 넣었다. 전체 컬럼 조회가 제한돼 있으니 필요한 컬럼을 적어 달라는 뜻이다. 차단 사유와 수정할 방향이 함께 전달되도록 했다.

저장하기 전에 두 조회문을 나란히 시험했다

설정 화면 안에 Test Pattern이 있어 편했다. SQL을 입력하고 Test를 누르면 입력한 패턴에 해당하는지 바로 확인할 수 있었다.

먼저 SELECT * FROM orders_control.orders ORDER BY order_id;를 넣었다. 결과는 Pattern matched였다. 제한하려던 조회문이 규칙에 걸리는 것을 확인했다.

그다음 SELECT order_id, status FROM orders_control.orders ORDER BY order_id;로 바꿔 시험했다. 이번에는 Pattern not matched가 나왔다. 이 표시는 테스트 실패가 아니라, 해당 조회문이 차단 패턴에 포함되지 않는다는 뜻이다.

막으려는 쿼리와 계속 허용할 쿼리를 설정 화면에서 비교할 수 있으니, 규칙의 의도를 확인하기 쉬웠다. 확인을 마치고 저장했다.

목록의 Test 기능에서도 실행 경로를 PROXY, 연결을 Orders Control Lab으로 정해 확인했다. DBeaver가 붙이는 주석을 포함한 SQL에도 해당 규칙이 잡혔고, APPLIED ACTION: DENY가 표시됐다.

DBeaver에서도 내가 정한 안내 문구가 나왔다

규칙을 저장한 뒤 DBeaver 연결을 새로 열고, 처음 실행했던 전체 컬럼 조회를 다시 실행했다. 이번에는 데이터 대신 오류 영역에 직접 작성한 안내 문구가 표시됐다.

“SELECT * is restricted. Please specify the required columns.” 앞에는 query_rule_id: 1도 붙어 있었다. 사용자 화면에서 어떤 규칙에 의해 제한됐는지 확인할 단서까지 남았다.

차단 화면에서 다음 행동을 알 수 있다는 점이 좋았다. 사용자는 필요한 컬럼을 적어야 한다는 안내를 받는다. 운영 담당자도 문의가 들어왔을 때 같은 문구와 규칙 번호를 기준으로 설명할 수 있겠다.

안내대로 order_id와 status를 명시해 다시 실행했다. 주문 3건이 정상적으로 나왔고, 이번 결과에는 필요한 두 컬럼만 표시됐다.

감사 기록에도 규칙 번호와 차단 사유가 남았다

Audit의 Query Audit에서 16시 21분 11초 기록을 열었다. 사용자는 Demo Developer, 실행 경로는 Agentless Proxy였고, 결과는 Failure로 표시됐다. 목록의 차단 여부에는 Prevented가 기록돼 있었다.

상세 화면에는 실제 실행 SQL과 함께 Error Message가 남았다. DBeaver에서 봤던 query_rule_id: 1과 안내 문구를 관리자도 확인할 수 있었다.

사용자에게 보인 메시지와 관리자가 확인하는 기록이 이어지니, 단순히 “실행이 실패했다”는 것보다 상황을 파악하기 쉬웠다. 어떤 SQL이 어떤 규칙으로 제한됐는지 기록을 근거로 설명할 수 있었다.

팀에서 정한 규칙을 실제 DB 사용에 반영했다

이번에는 작은 조회 규칙 하나를 만들어 봤지만, 설정부터 사용자의 실행 결과까지 연결해서 볼 수 있었다. 대상을 실습 DB로 정하고, SQL 패턴을 시험한 뒤, 차단 안내와 감사 기록을 확인했다.

특히 패턴 테스트와 안내 메시지 설정이 기억에 남는다. 관리자는 규칙이 의도한 쿼리에 적용되는지 살펴볼 수 있고, 사용자는 안내를 따라 SQL을 고쳐 작업을 이어갈 수 있었다.

팀의 DB 사용 규칙을 실제 쿼리 실행 과정에 반영할 수 있다는 점. Query Rules는 접근 권한과 함께 SQL 사용 방식까지 관리하려는 담당자에게 유용한 기능이었다. 이번 실습에서는 필요한 컬럼을 지정하는 간단한 원칙이 DBeaver에서도 그대로 적용되는 모습을 확인했다.