[11편] 가려진 전화번호가 필요할 때 — QueryPie 마스킹 해제 요청과 승인 실습
2026년 11월 8일
지난번에는 고객 연락처를 마스킹해서 조회해 봤다. 주문 정보는 그대로 확인하면서 전화번호와 이메일은 가릴 수 있었다. 그런데 배송 문의를 처리하는 담당자라면 고객에게 연락해야 할 때도 있다. 그때마다 관리자에게 전체 마스킹 설정을 바꿔 달라고 해야 할까?
이번에는 QueryPie의 마스킹 해제 요청(Unmasking Request)을 써봤다. 개발자가 필요한 컬럼과 사용 기간, 사유를 적어 요청하고, 담당자가 승인한 뒤 DBeaver에서 다시 조회했다. 승인받은 전화번호는 원문으로 보였고 이메일은 계속 가려져 있었다.
실습에는 앞선 글에서 만든 가상 주문과 연락처를 사용했다. 화면의 이름과 전화번호, 이메일은 모두 테스트 데이터다.
1. 배송 문의에 필요한 전화번호만 요청해 보기로 했다
개발자 계정으로 DBeaver에서 주문 4002번의 연락처를 조회했다. 주문 상태와 고객 이름은 보였지만 전화번호는 010-****-1002로 표시됐다. 이메일 역시 마스킹된 상태였다.

이번 업무는 배송 문의에 필요한 전화번호 확인으로 정했다. 그래서 마스킹 해제 대상도 customer_contacts 테이블의 phone 컬럼 하나만 선택하기로 했다. 이메일까지 볼 필요는 없었다.
2. 누가 승인할지 먼저 정했다
관리자 화면의 Approval Rules에서 마스킹 해제 요청용 승인 규칙을 만들었다. 이름은 Orders Lab - Contact Unmasking Approval로 정하고, 요청 유형은 Unmasking Request를 선택했다.
승인자는 Demo Approver로 지정했다. 요청하는 개발자와 승인하는 담당자를 나눠 두니, 사용자가 필요하다는 이유만으로 스스로 마스킹을 해제하는 방식이 아니라 담당자의 확인을 거치도록 구성할 수 있었다.

3. 필요한 컬럼과 사용 시간을 적어 요청했다
개발자 계정의 Workflow에서 Unmasking Request를 열었다. 제목은 ‘주문 4002 배송 문의 처리를 위한 전화번호 확인’으로 적었다. Orders Control Lab 연결에서 orders_control 데이터베이스와 customer_contacts 테이블을 고른 뒤 phone 컬럼을 선택했다.
사용 기간은 11월 8일 오후 4시부터 24시간으로 설정했다. 요청 사유에는 배송 문의 처리를 위해 전화번호 원문이 필요하며, 이메일 마스킹은 유지한다는 내용을 적었다.

화면에서 해제 대상을 컬럼 단위로 고르는 점이 좋았다. ‘고객 정보가 필요하다’는 말보다 어떤 정보를 왜, 언제까지 사용하려는지 구체적으로 남길 수 있기 때문이다. 이번 요청의 승인 범위는 phone 컬럼이고, 주문 4002번은 업무 사유와 조회 조건으로 사용했다.

4. 승인자는 요청 내용을 보고 처리했다
Demo Approver 계정으로 로그인해 Received Requests를 열었다. 개발자가 제출한 요청이 To Do에 들어와 있었다. 요청 제목과 신청자, 대상 컬럼, 사용 기간, 사유를 한 요청 안에서 확인할 수 있었다.

전화번호 확인을 승인한다는 의견과 사용 기간을 남긴 뒤 승인했다. 완료된 요청은 Done 목록으로 이동했고, 상태도 Approved로 바뀌었다.

도입 담당자 입장에서 이런 기록은 유용하다. 나중에 연락처 원문을 볼 수 있었던 이유를 확인할 때, 구두로 오간 이야기를 되짚을 필요 없이 실제 요청 내용을 찾아볼 수 있다.
5. DBeaver에서 다시 조회하니 전화번호만 보였다
승인을 마친 뒤 개발자가 사용하던 DBeaver로 돌아와 같은 조회를 다시 실행했다. 이번에는 전화번호가 010-0000-1002로 표시됐다. 함께 조회한 이메일은 여전히 가려져 있었다.

이 결과가 이번 실습에서 가장 마음에 들었다. 필요한 전화번호를 확인하면서도 이메일 보호는 그대로 유지됐다. 개발자는 익숙한 DBeaver에서 업무를 이어갈 수 있었고, 관리자가 공통 마스킹 정책을 통째로 풀 필요도 없었다.
6. 개인정보가 필요한 업무에도 승인 절차를 붙일 수 있었다
마스킹을 적용하면 개인정보 노출을 줄일 수 있다. 여기에 마스킹 해제 요청을 함께 쓰니, 업무상 원문이 필요한 경우도 같은 제품 안에서 처리할 수 있었다.
직접 해보니 필요한 컬럼을 고르고, 사유와 사용 기간을 적고, 담당자가 승인한다는 흐름이 명확했다. 사용자는 무엇을 요청해야 하는지 알 수 있고, 승인자는 어떤 정보를 허용하는지 확인할 수 있다.
이번에는 전화번호 하나가 필요해서 시작했다. 결과적으로 QueryPie가 개인정보를 가리는 기능뿐 아니라, 필요한 사람에게 필요한 정보를 승인해 주는 업무 절차까지 제공한다는 점을 확인할 수 있었다.
![[10편] “필요한 컬럼만 조회해 주세요” — QueryPie Query Rules로 SQL 사용 규칙 적용하기](/assets/content/acp-lab-notes/query-rules/01.webp)
![[12편] DB 자료도 승인받고 내보냈다 — QueryPie SQL Export 실습](/assets/content/acp-lab-notes/sql-export/01.webp)