[6편] QueryPie ACP에서 SQL 승인받고 데이터 수정하기 — 조회 권한은 그대로, 필요한 작업만

운영 DB를 조회하다 보면 데이터를 한두 건 고쳐야 할 때가 있다. 배송은 끝났는데 주문 상태가 그대로이거나, 잘못 들어간 값을 정정해야 하는 경우다. 수정할 내용은 간단해도 운영 데이터인 만큼 누가 어떤 이유로 바꾸는지는 분명하게 남기고 싶다.

지난 5편에서는 필요한 DB 접근 권한을 요청하고 승인받아 봤다. 이번에는 한 걸음 더 들어가 실제로 실행할 SQL을 올리고, 담당자의 승인을 받아 데이터를 수정해 봤다. QueryPie ACP 커뮤니티 버전의 SQL Request 기능을 사용했다.

가장 궁금했던 건 개발자에게 평소보다 넓은 권한을 주지 않고도 이런 작업을 처리할 수 있느냐는 점이었다. 직접 해보니 기존 조회 권한은 그대로 둔 채, 승인받은 SQL을 실행하고 결과까지 확인할 수 있었다.

주문 한 건의 배송 상태를 바꿔보기로 했다

이번에도 앞선 글에서 만든 Orders Control Lab을 사용했다. 배송은 완료됐지만 DB에는 아직 배송 중으로 남아 있는 상황을 가정했다. 실제 고객 주문이 아닌 실습용 데이터다.

DBeaver에서 먼저 주문 목록을 조회했다. 4002번 주문은 SHIPPED, 금액은 32,000원이었다. 이번에 바꿀 값은 이 주문의 상태 하나다. 나머지 주문과 금액은 그대로 두기로 했다.

개발자 계정은 Demo Developer, 승인 담당자는 Demo Approver로 나눴다. SQL 요청용 승인 규칙도 따로 만들었다. 담당자가 검토하고 승인하면 개발자가 실행하는 순서다. 본인이 올린 요청을 스스로 승인하는 설정은 사용하지 않았다.

바꿀 내용과 이유를 SQL 요청에 함께 적었다

개발자 계정에서 Workflow의 SQL Request를 열었다. 대상 연결은 Orders Control Lab, 데이터베이스는 orders_control을 선택했다. 제목은 ‘주문 4002 배송 완료 상태 정정’으로 적고 아래 SQL을 입력했다.

UPDATE orders_control.ordersSET status = 'DELIVERED'WHERE order_id = 4002  AND status = 'SHIPPED';

WHERE 절에는 주문 번호와 기존 상태를 함께 넣었다. 4002번이면서 아직 SHIPPED인 주문만 바뀌도록 했다. 요청 사유에도 배송 완료 상태를 반영하는 작업이며, 예상 변경 건수는 1건이라고 적었다.

입력하다 보니 승인 담당자가 무엇을 확인해야 할지 자연스럽게 정리됐다. 어느 DB에서 무엇을 바꾸는지, 왜 필요한지, 몇 건을 예상하는지가 요청 안에 함께 있었다. 실행 희망일과 실행 만료일도 이번 작업일로 지정했다.

요청을 제출한 뒤에는 요청자, 승인자, 실행자가 차례로 표시됐다. 누가 검토할 차례인지 화면에서 바로 알 수 있었다.

승인 담당자는 실제 SQL을 보고 판단했다

이번에는 Demo Approver 계정으로 들어갔다. Received Requests의 To Do 목록에 방금 올린 요청이 도착해 있었다.

요청을 열어보니 개발자가 적은 SQL과 작업 사유가 그대로 보였다. 주문 번호가 4002로 지정됐는지, 기존 상태를 확인하는 조건이 있는지 살펴봤다. 요청 사유에 적은 ‘예상 변경 1건’과 SQL을 나란히 놓고 검토할 수 있었다.

도입 담당자 입장에서 이 부분이 마음에 들었다. 승인 화면 안에 판단에 필요한 내용이 모여 있으니, 작업자에게 SQL을 다시 보내달라고 할 일이 줄어든다. 데이터를 바꾸기 전에 담당자가 내용을 확인하는 절차를 제품 안에서 운영할 수 있다.

Approve를 누르고 검토 의견도 남겼다. 주문 번호와 기존 상태 조건을 확인했으며, 한 건의 배송 완료 상태 정정을 승인한다는 내용이다.

승인된 작업을 개발자가 실행했다

다시 개발자 계정으로 돌아오니 요청이 Executions의 To Do에 나타났다. 승인 단계가 끝났고, 이번에는 실행할 차례였다. 요청 상세 화면에는 Execute 버튼이 표시됐다.

승인과 실행이 별도 단계로 나뉜 점도 좋았다. 담당자가 내용을 확인한 다음, 지정된 실행자가 작업을 이어갈 수 있었다. 이번 실습에서는 요청한 개발자를 실행자로 지정해 두었다.

Execute를 눌렀다. 자동 커밋으로 DB에 반영된다는 안내를 확인하고 실행을 진행했다. 완료 후 Results 탭에 방금 실행한 UPDATE문과 함께 ‘1 Rows updated.’가 표시됐다. 요청할 때 적었던 예상 변경 건수와 같았다.

요청을 올리고 승인받은 뒤 실행 결과를 확인하기까지 한 작업으로 이어졌다. 나중에 이 주문을 왜 수정했는지 찾아볼 때도 요청 사유와 SQL, 담당자, 처리 결과를 함께 볼 수 있다는 점이 편했다.

DBeaver에서도 바뀐 값을 확인했다

마지막으로 DBeaver에 돌아와 처음과 같은 SELECT문을 다시 실행했다. 4002번 주문의 상태가 DELIVERED로 바뀌어 있었다. 금액은 32,000원 그대로였고, 4001번과 4003번 주문도 변하지 않았다.

이번 UPDATE는 QueryPie의 승인된 요청에서 실행했고, DBeaver는 수정 전후 데이터를 조회하는 데 사용했다. 익숙한 DB 도구로 내용을 살펴보고, 변경 작업은 정해진 승인 절차로 처리하는 방식이 잘 맞았다.

작업을 마친 뒤 개발자의 DB 접근 권한도 다시 열어봤다. Read-Only (User), Select가 그대로 표시됐다. 이번 수정을 위해 개발자의 평소 접속 권한을 쓰기 권한으로 올리지는 않았다.

필요한 수정은 처리하고, 평소 권한은 그대로

직접 써보니 SQL Request의 장점은 꽤 분명했다. 개발자는 바꿔야 할 SQL과 이유를 올리고, 승인 담당자는 실제 작업 내용을 확인하고, 실행자는 승인된 요청을 처리한다. 각자 해야 할 일이 화면에서 구분돼 있었다.

특히 일회성 데이터 정정을 위해 개발자의 일반 접속 권한을 넓히지 않아도 된다는 점이 인상적이었다. 이번에는 조회 권한을 유지하면서 주문 한 건을 정정했다. 작업이 끝난 뒤 다시 쓰기 권한을 회수하는 과정도 필요하지 않았다.

운영을 맡는 입장에서는 업무를 처리하는 속도만큼 작업의 근거가 남는 것도 중요하다. QueryPie에서는 무엇을 바꾸려고 했는지부터 누가 승인하고 실행했는지, 실제 몇 건이 바뀌었는지까지 같은 요청에서 확인할 수 있었다.

작은 주문 상태 변경 하나였지만, 필요한 업무를 처리하면서 최소한의 권한을 유지하는 방법이 꽤 구체적으로 보였다. 운영 DB의 수정 작업을 일정한 절차로 관리하고 싶은 팀에 SQL Request가 유용하겠다는 생각이 들었다.

실습 환경: QueryPie ACP 커뮤니티 11.6.7 / MySQL 8.0.42 / DBeaver 26.2.4