[49편] 주문 한 건을 바꾸는 데 어떤 기록이 남았을까

운영 DB의 값을 바꾼 뒤에는 “변경했습니다”라는 말만으로 설명이 끝나지 않을 때가 많다. 왜 바꿨는지, 누가 확인했는지, 실제로 어느 값이 달라졌는지를 함께 봐야 작업 경위가 분명해진다.

앞선 글에서 SQL 승인, DML Snapshot, 감사 로그 내보내기를 각각 써봤다. 이번에는 주문 한 건을 정정하는 작업으로 묶어서 해봤다. 변경 사유를 적는 순간부터 승인과 실행, 변경 전후 값 확인, 감사 파일 다운로드까지 같은 주문을 따라가봤다.

1. 상태를 정정할 주문 한 건을 준비했다

실습용 주문 49001을 새로 만들었다. 현재 상태는 PENDING, 금액은 26,700원이다. 배송 완료를 확인했는데 주문 상태가 아직 반영되지 않아 정정해야 하는 상황으로 잡았다. 기존에 사용하던 다른 테스트 주문은 건드리지 않았다.

작업자 계정의 직접 접속 권한은 Read-Only로 두었다. SQL Editor에서는 변경 전 상태를 조회하고, 실제 UPDATE는 별도의 SQL Request로 승인을 받기로 했다.

2. 변경 이유와 SQL을 함께 승인받았다

요청 제목은 ‘주문 49001 배송 완료 정정’으로 적었다. 사유에는 배송 완료를 확인한 주문 한 건의 상태만 바꾸고, 금액과 다른 주문은 변경하지 않는다고 명시했다.

SQL에도 그 범위를 담았다. 주문 번호가 49001이고 현재 상태가 PENDING인 경우에만 DELIVERED로 바꾸도록 WHERE 조건을 넣었다. 승인자는 작업 설명과 실제 실행할 SQL을 함께 살펴볼 수 있었다.

지정 승인자인 Demo Approver로 요청을 열어 대상과 조건을 확인했다. 주문 한 건만 정정하고 금액과 다른 주문은 변경하지 않는 범위를 확인했다는 의견을 남긴 뒤 승인했다. 요청은 Approved로 바뀌었다.

다시 작업자 계정의 실행 목록에서 승인된 요청을 열어 Execute를 눌렀다. 결과는 ‘1 Rows updated’. 13시 56분 27초에 주문 한 건이 변경됐다. 원본 DB에서도 해당 주문의 상태가 DELIVERED로 바뀐 것을 확인했고, 금액과 다른 주문들은 그대로였다.

여기서 편했던 점은 작업자의 평소 접속 권한을 변경용으로 넓히지 않아도 됐다는 것이다. 직접 조회하는 권한은 유지하면서, 검토한 변경 SQL은 승인 절차를 거쳐 실행할 수 있었다.

3. 바꾸기 전 값도 바로 찾을 수 있었다

이 연결에는 DML Snapshot이 켜져 있었다. 관리자 감사 화면의 DML Snapshots를 열자 방금 실행한 UPDATE가 새 기록으로 나타났다. 실행 시각은 13시 56분 27초, 대상은 Orders Control Lab, 변경 행 수는 1이었다.

상세 화면에서 Before를 누르니 주문 49001의 status가 PENDING으로 보였다. 이어서 After를 누르자 같은 주문의 status가 DELIVERED로 표시됐다. 어떤 SQL을 실행했는지와 그 SQL로 상태가 어떻게 달라졌는지를 한 화면에서 확인할 수 있었다.

나중에 “이 주문은 원래 어떤 상태였나요?”라는 질문을 받더라도 작업자의 기억에만 의존하지 않아도 되겠다. 이번 실습처럼 바뀐 상태 값을 직접 대조할 수 있다는 점이 운영 담당자에게 꽤 실용적으로 느껴졌다.

4. 감사 기록에서도 승인받은 작업임을 확인했다

Query Audit에서도 같은 작업을 찾아봤다. 기록 번호는 512였고, 실행 결과는 Success였다. 사용자 Demo Developer, UPDATE 실행, 실행 시각이 DML Snapshot과 일치했다.

특히 Executed From에 SQL Request가 표시돼 있었다. 작업자의 직접 접속 권한은 Read-Only로 남아 있으면서, 이번 변경은 승인 요청을 통해 실행했다는 점이 기록에서 구분됐다. 누가 실행했는지뿐 아니라 어떤 절차로 실행했는지도 함께 확인할 수 있었다.

5. 같은 작업의 기록을 파일로 꺼내봤다

마지막으로 Audit Log Export에서 감사 자료를 만들었다. 로그 유형은 Query Audit, 파일 형식은 CSV로 골랐다. 기간은 실습 당일로 정하고, 사용자와 DB 연결을 조건으로 걸었다.

미리보기에는 두 건이 나왔다. 변경 전 주문을 확인한 SELECT와, 승인을 받아 실행한 UPDATE였다. 한 주문을 확인하고 정정한 흐름이 실행 시각 순서대로 남아 있었다.

작업이 Completed로 바뀐 뒤 파일을 내려받아 압축을 풀었다. 실제 CSV에는 사용자, SQL 원문, 실행 시각, 결과, 변경 행 수와 실행 경로가 들어 있었다.

UPDATE 행의 Workflow Request UUID도 처음 제출한 요청 ID와 같았다. 화면에서 확인한 감사 번호 512, 13시 56분 27초의 실행 시각, 한 행 변경 결과까지 일치했다. 요청과 실제 실행을 같은 작업으로 대조할 수 있는 자료였다.

주문 상태 하나를 바꿨을 뿐이지만 남은 기록은 꽤 구체적이었다. 요청서에는 변경 이유와 승인자가, 실행 결과에는 처리 시각과 건수가, DML Snapshot에는 바꾸기 전과 후의 상태가 남았다. 감사 파일에도 같은 승인 요청을 가리키는 ID가 담겼다.

도입 담당자 입장에서는 이 연결이 반갑다. 변경을 승인하는 절차와 실제 작업 기록이 따로 흩어져 있으면 설명할 때마다 자료를 맞춰야 한다. 이번에는 QueryPie 안에서 주문 한 건의 변경 경위를 확인하고, 필요한 실행 기록을 파일로 보관하는 데까지 이어갈 수 있었다.