리소스

/

ACP 실습 노트

[19편] 주문 상태를 바꾼 뒤, 이전 값까지 찾아봤다 — QueryPie DML Snapshot

DB 접근 제어 · 승인 · 감사 · 운영

2026년 11월 9일

6편에서는 개발자에게 수정 권한을 계속 열어 주지 않고, 필요한 SQL만 승인받아 실행해 봤다. 이번에는 실행이 끝난 뒤의 기록을 살펴봤다. 누가 어떤 SQL을 실행했는지에 더해, 실제 데이터가 어떻게 바뀌었는지도 보고 싶었다.

 

가상 주문 한 건의 상태를 PENDING에서 DELIVERED로 바꾸고 QueryPie의 DML Snapshot을 열어 봤다. 주문 상태가 어떻게 바뀌었는지 기록에 남아 있어, 어떤 처리를 했는지 설명하기가 훨씬 수월했다.

 

 

먼저 실습 DB에서 DML Snapshot을 켰다

 

관리자 화면의 Databases → DB Connections에서 Orders Control Lab을 열었다. 이 연결의 추가 설정에 DML Snapshot 항목이 있었고, 처음에는 Off였다. On으로 바꾸고 Save Changes를 눌렀다.

 

화면 1. Orders Control Lab 연결에서 DML Snapshot을 On으로 설정했다.
화면 1. Orders Control Lab 연결에서 DML Snapshot을 On으로 설정했다.

 

DML Snapshot은 연결별로 활성화하는 기능이다. 공식 문서에서는 QueryPie를 통해 실행을 마친 INSERT, UPDATE, DELETE의 변경 전후 데이터를 기록한다고 설명한다. 이번에는 이전 글에서 사용하던 MySQL 주문 DB에서 UPDATE 한 건을 직접 실행해 보기로 했다.

 

 

주문 4003은 아직 PENDING이었다

 

개발자 계정으로 웹 SQL 에디터에 접속해 주문 4003을 조회했다. 현재 상태는 PENDING, 주문 금액은 18,500원이었다.

 

화면 2. 변경 전 주문 4003의 상태가 PENDING으로 조회됐다.
화면 2. 변경 전 주문 4003의 상태가 PENDING으로 조회됐다.

 

이번에 바꿀 값은 이 주문의 상태 하나다. 주문 번호를 조건에 넣고, 기존 상태가 PENDING인 경우에만 DELIVERED로 바꾸도록 SQL을 준비했다. 개발자의 평소 접속 권한은 Read-Only로 유지했다.

 

 

수정은 기존 SQL 승인 절차로 진행했다

 

Workflow에서 SQL Request를 만들었다. 제목은 ‘주문 4003 배송 완료 처리 — DML Snapshot 확인’으로 적고, 대상 연결과 DB, 실행할 SQL, 요청 사유를 넣었다.

 

기존에 설정해 둔 승인 규칙에 따라 Demo Approver가 승인자로 지정됐다. 요청자와 실행자는 Demo Developer다. 변경할 SQL은 다음과 같다.

 

1234
UPDATE orders_control.ordersSET status = 'DELIVERED'WHERE order_id = 4003  AND status = 'PENDING';

 

화면 3. Demo Developer가 변경을 요청하고 실행하며, Demo Approver가 승인하도록 요청을 제출했다.
화면 3. Demo Developer가 변경을 요청하고 실행하며, Demo Approver가 승인하도록 요청을 제출했다.

 

승인자 계정에서 주문 한 건만 변경하는 조건을 확인하고 승인했다. 개발자 계정으로 돌아와 승인된 요청을 실행하니 Results에 ‘1 Rows updated’가 표시됐다.

 

화면 4. 승인된 SQL을 실행한 결과, 주문 한 행이 변경됐다.
화면 4. 승인된 SQL을 실행한 결과, 주문 한 행이 변경됐다.

 

평소에는 조회 권한으로 일하고, 수정이 필요할 때는 승인된 SQL을 실행하는 방식이다. 앞서 사용했던 승인 절차를 그대로 거치면서 이번에는 변경 전후 기록까지 남길 수 있었다.

 

 

실행한 UPDATE가 DML Snapshots에 올라왔다

 

관리자 화면에서 Audit → Databases → DML Snapshots를 열었다. 방금 실행한 UPDATE가 목록에 나타났다. 실행 시각은 2026년 11월 9일 00:17:13, 사용자는 Demo Developer였다.

 

화면 5. 주문 상태를 변경한 UPDATE가 DML Snapshots 목록에 기록됐다.
화면 5. 주문 상태를 변경한 UPDATE가 DML Snapshots 목록에 기록됐다.

 

상세 화면에는 Orders Control Lab 연결과 대상 테이블, 실행한 SQL이 나왔다. Rows는 1이었고, Executed From에는 SQL Request가 표시됐다. 승인받아 실행한 작업이라는 점까지 같은 기록에서 확인할 수 있었다.

 

 

Before와 After에서 바뀐 값을 확인했다

 

상세 화면 아래에서 orders_control.orders를 확인했다. Before 탭에는 주문 4003의 status가 PENDING으로 남아 있었다. SQL을 실행하기 전에 조회했던 상태와 같았다.

 

화면 6. Before 탭에 주문 4003의 변경 전 상태 PENDING이 기록돼 있다.
화면 6. Before 탭에 주문 4003의 변경 전 상태 PENDING이 기록돼 있다.

 

After 탭으로 바꾸자 같은 주문의 status가 DELIVERED로 나왔다. 실행한 SQL과 실제로 바뀐 값을 한 화면에서 살펴볼 수 있어 이해하기 편했다.

 

화면 7. After 탭에서는 변경 후 상태 DELIVERED를 확인했다.
화면 7. After 탭에서는 변경 후 상태 DELIVERED를 확인했다.

 

나중에 담당자가 “처리 전에는 어떤 상태였나요?”라고 물어도 이 기록을 보면서 설명할 수 있겠다. 작업자가 별도로 남겨 둔 메모를 찾지 않아도, 해당 작업의 변경 전후 값을 확인할 수 있다는 점이 좋았다.

 

 

실행 이력과 변경 내용을 함께 볼 수 있었다

 

Query Audit에서도 같은 시각의 실행 기록을 찾아봤다. Demo Developer가 실행한 UPDATE가 Success로 남아 있었다. Query Audit에서 실행자와 SQL의 처리 결과를 보고, DML Snapshot에서 변경 전후 값을 확인하니 작업 내용을 파악하기 쉬웠다.

 

화면 8. Query Audit에서도 같은 UPDATE의 실행자와 성공 결과를 확인했다.
화면 8. Query Audit에서도 같은 UPDATE의 실행자와 성공 결과를 확인했다.

 

직접 써보니 승인된 SQL이 실행됐는지뿐 아니라 실제 주문 상태가 어떻게 바뀌었는지까지 확인할 수 있어 좋았다. 개발자의 평소 조회 권한은 유지하면서 필요한 수정만 승인받아 처리했고, 실행 후에는 변경 전후 상태까지 기록으로 남았다.

 

운영 변경 이력을 설명하거나 감사 자료를 준비할 때도 유용하겠다. 누가 요청하고 승인했는지, 어떤 SQL이 실행됐는지, 그 결과 어떤 값이 바뀌었는지를 QueryPie에서 차례로 확인할 수 있었다. 담당자가 당시 상황을 기억해 설명해야 하는 부담도 줄어들 것 같다.

 

이번 실습은 QueryPie Community 11.6.7과 MySQL 8.0.42 환경에서 가상 주문 데이터로 진행했다.

 

참고: QueryPie 공식 DML Snapshots 문서