리소스

/

ACP 실습 노트

[12편] DB 자료도 승인받고 내보냈다 — QueryPie SQL Export 실습

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

2026년 11월 8일

DB에서 조회한 내용을 보고서에 옮겨야 할 때가 있다. 배송 현황을 정리하거나 주문 금액을 비교하려면 파일로 받아서 작업하는 편이 편하다. 도입 담당자라면 이때 누가 어떤 데이터를 어떤 목적으로 내려받았는지도 함께 관리하고 싶을 것이다.

 

이번에는 QueryPie의 SQL Export Request로 주문 요약 자료를 내보내 봤다. 개발자가 내보낼 SQL과 사유를 적어 요청하고, 담당자가 승인한 뒤 파일을 내려받았다. 요청부터 승인, 실행 결과까지 Workflow 안에서 확인할 수 있었다.

 

실습에는 커뮤니티 버전에 연결한 가상 주문 DB를 사용했다. 실제 고객 정보는 사용하지 않았다.

 

 

1. 주문 보고서에 필요한 항목부터 골랐다

 

이번 업무는 주문 세 건의 배송 현황을 보고하는 것으로 정했다. 필요한 정보는 주문 번호, 상태, 금액이었다. 고객 이름이나 연락처를 보고서에 넣을 이유는 없어서 조회할 컬럼에서 제외했다.

 

내보내기에 사용할 SQL은 아래처럼 작성했다. orders 테이블에서 order_id, status, total_amount만 고르고, 주문 번호는 4001번부터 4003번까지로 정했다.

 

1234
SELECT order_id, status, total_amountFROM orders_control.ordersWHERE order_id BETWEEN 4001 AND 4003ORDER BY order_id;

 

내보낼 범위를 SQL로 적어 두면 승인자도 어떤 자료를 요청하는지 구체적으로 확인할 수 있다. ‘주문 데이터가 필요하다’는 설명만 전달하는 것보다 검토하기가 훨씬 수월하다.

 

 

2. 승인하는 사람과 파일을 받는 사람을 정했다

 

관리자 화면의 Approval Rules에서 Orders Lab - Export Approval이라는 규칙을 만들었다. 요청 유형은 SQL Export Request로 선택했다.

 

승인자는 Demo Approver, 실행자는 Demo Developer로 지정했다. 개발자가 필요한 자료를 요청하고, 담당자의 승인을 받은 뒤 직접 내보내는 구성이다. 자기 승인은 허용하지 않았다.

 

화면 1. SQL Export Request용 승인 규칙에서 승인자와 실행자를 각각 지정했다.
화면 1. SQL Export Request용 승인 규칙에서 승인자와 실행자를 각각 지정했다.

 

파일을 내려받는 단계에도 역할을 정할 수 있다는 점이 좋았다. 승인하는 담당자와 실제 자료를 사용하는 담당자를 업무에 맞게 구분할 수 있었다.

 

 

3. SQL과 사용 목적을 함께 제출했다

 

개발자 계정으로 Workflow의 SQL Export Request를 열었다. 앞에서 만든 규칙을 사용하니 승인자와 실행자가 정해진 대로 표시됐다.

 

제목은 ‘배송 현황 보고를 위한 주문 요약 내보내기’로 적었다. Orders Control Lab 연결과 orders_control 데이터베이스를 선택하고, Query Result 방식으로 준비한 SQL을 입력했다. 승인 기한과 실행 기한은 모두 실습 당일로 정했다.

 

화면 2. 내보내기 요청에 승인자와 실행자, 대상 연결을 지정한 모습.
화면 2. 내보내기 요청에 승인자와 실행자, 대상 연결을 지정한 모습.

 

사유에는 주문 번호·상태·금액만 필요하며 고객 이름과 전화번호, 이메일은 포함하지 않는다고 적었다. 제출 후에는 요청이 In Progress 목록에 나타났고, 승인과 실행 상태가 모두 Pending으로 표시됐다.

 

화면 3. 요청을 제출한 뒤 승인과 실행을 기다리는 상태가 각각 표시됐다.
화면 3. 요청을 제출한 뒤 승인과 실행을 기다리는 상태가 각각 표시됐다.

 

 

4. 승인자는 실제로 내보낼 SQL을 확인했다

 

Demo Approver 계정의 Received Requests에서 요청을 열었다. 개발자가 작성한 SQL과 업무 사유, 실행 기한을 확인할 수 있었다.

 

화면 4. 승인자 화면에서 내보낼 컬럼과 주문 범위, 요청 사유를 확인했다.
화면 4. 승인자 화면에서 내보낼 컬럼과 주문 범위, 요청 사유를 확인했다.

 

연락처가 SQL에 포함되지 않았는지 확인한 뒤 승인했다. 승인 의견에도 배송 현황 보고 목적의 내보내기를 허용하며, 연락처가 포함되지 않았음을 확인했다고 남겼다.

 

이렇게 처리하니 승인 기록에 업무 목적과 실제 SQL이 함께 남았다. 나중에 이 자료를 왜 내보냈는지 확인할 때도 요청 내용부터 살펴볼 수 있다.

 

 

5. 승인 후 내려받은 파일에는 요청한 주문 세 건이 들어 있었다

 

개발자 계정으로 돌아와 Executions의 To Do에서 승인된 요청을 열었다. Execute를 누른 뒤 CSV 형식과 첫 줄에 컬럼 이름을 넣는 옵션으로 내보냈다.

 

파일 다운로드가 완료됐고, Results에는 3 Rows selected라는 실행 결과가 남았다.

 

화면 5. 내보내기를 실행한 뒤 Results에서 처리한 SQL과 조회 건수를 확인했다.
화면 5. 내보내기를 실행한 뒤 Results에서 처리한 SQL과 조회 건수를 확인했다.

 

내려받은 ZIP 파일 안의 export.csv도 직접 열어봤다. 첫 줄에는 order_id, status, total_amount가 있었고, 그 아래에는 주문 4001·4002·4003번의 상태와 금액이 들어 있었다. 요청한 세 컬럼과 세 건이 그대로 파일로 만들어졌다.

 

화면 6. 실제 내려받은 CSV에는 승인받은 SQL의 조회 결과가 담겨 있었다.
화면 6. 실제 내려받은 CSV에는 승인받은 SQL의 조회 결과가 담겨 있었다.

 

실행을 마친 요청은 Executions의 Done 목록으로 이동했다. 상태는 Success였고 신청자, 요청 시각, 갱신 시각도 함께 표시됐다.

 

화면 7. 완료된 내보내기 작업을 Success 상태로 다시 확인할 수 있었다.
화면 7. 완료된 내보내기 작업을 Success 상태로 다시 확인할 수 있었다.

 

 

6. 자료를 받는 업무에도 확인할 기록이 생겼다

 

직접 해보니 SQL Export Request의 장점은 파일을 만들기 전후의 업무가 연결된다는 데 있었다. 사용자는 필요한 SQL과 사유를 제출하고, 승인자는 내보낼 내용을 검토하고, 실행자는 승인된 요청에서 파일을 받을 수 있었다.

 

도입 담당자에게도 설명하기 좋은 기능이다. 누가 무엇을 요청했고, 누가 승인했으며, 실행이 성공했는지를 요청과 결과 화면에서 따라갈 수 있기 때문이다.

 

이번에는 주문 세 건을 CSV로 받는 간단한 업무였지만, 자료를 내보내는 데도 승인 절차와 실행 기록을 붙일 수 있다는 점을 확인했다. 보고서 작성처럼 일상적인 DB 업무를 QueryPie 안에서 관리하는 모습을 보여 주는 실습이었다.