[41편] 조회용 권한과 작업용 권한에 서로 다른 DB 계정을 연결해봤다
2026년 11월 13일
DB를 운영하다 보면 조회용 계정과 작업용 계정을 따로 두게 된다. 주문 내역을 확인하는 사람에게는 조회 권한만 주고, 상태를 바꾸는 담당자에게는 필요한 변경 권한을 주는 식이다.
이번에는 이렇게 나눠 둔 DB 계정을 QueryPie 권한에 연결해봤다. Advanced Privilege를 사용하면 같은 DB 연결에서도 권한별로 다른 계정을 지정할 수 있다. 실제로 접속하는 계정이 바뀌는지, 작업 기록에는 어떻게 남는지 직접 확인했다.
조회용과 작업용 DB 계정을 준비했다
실습용 주문 테이블에 계정 두 개를 만들었다. ep41_reader에는 SELECT만, ep41_operator에는 SELECT와 UPDATE를 부여했다. 주문번호 41001의 상태는 READY, 금액은 25000.00으로 준비했다.
QueryPie 관리자 화면에서 Databases → General → Configurations로 들어가 Advanced Privilege Setting을 켰다. 이어서 새로 만든 DB Privilege Account Lab 연결의 Privilege Setting을 열었다.

Read-Only에는 ep41_reader, Read/Write에는 ep41_operator를 지정했다. 각 계정의 Test Connection이 성공하는 것을 확인하고 저장했다. 한 연결 안에서 조회용과 작업용 계정의 구분이 한눈에 보였다.

회사에서 이미 용도별로 DB 계정을 나눠 쓰고 있다면 그 구분을 QueryPie에도 이어갈 수 있겠다. 관리자는 어떤 권한에 어떤 DB 계정을 사용할지 정하고, 사용자에게는 업무에 맞는 QueryPie 권한을 부여하는 구성이다.
조회 권한으로 접속하니 조회용 계정이 사용됐다
먼저 Demo Developer에게 이번 연결의 Read-Only 권한을 부여했다. 사용자 화면에서 연결을 선택하니 권한이 Read-Only로 표시됐다. DB 비밀번호를 직접 입력할 필요 없이 Connect를 눌러 웹 SQL 에디터를 열 수 있었다.

주문 한 건을 조회하면서 CURRENT_USER()도 함께 확인했다. 이 함수는 MySQL에서 실제 인증에 사용된 계정을 보여준다. 결과에 ep41_reader@%가 나왔고, 주문 상태와 금액도 준비한 값대로 조회됐다.

권한 이름만 보고 판단하는 대신 조회 결과에서 실제 계정까지 확인하니 설정이 어떻게 적용됐는지 분명했다.
작업 권한을 주고 다시 접속하니 계정이 바뀌었다
조회용 연결을 끊은 뒤, 관리자가 같은 사용자의 이번 연결 권한을 Read/Write로 변경했다. 다시 접속해 같은 SQL을 실행하자 실제 DB 계정이 ep41_operator@%로 바뀌었다.

사용자는 같은 DB 연결을 이용했지만, 부여받은 권한에 맞춰 DB 계정이 달라졌다. 조회용 비밀번호와 작업용 비밀번호를 사용자에게 각각 전달할 필요 없이, 관리자가 지정한 계정으로 연결되는 점이 편했다.
이번에는 주문번호 41001의 상태를 READY에서 CHECKED로 변경했다. UPDATE 결과는 1 Rows updated. 다시 조회해 보니 상태가 CHECKED로 바뀌었고, 금액은 25000.00 그대로였다.

사용자와 실제 DB 계정이 감사 기록에 함께 남았다
관리자 화면의 DB Access History에서 방금 접속한 기록을 열었다. 사용자 Demo Developer, 권한 Read/Write, DB User ep41_operator가 함께 표시됐다. 앞선 조회용 접속 기록에는 Read-Only와 ep41_reader가 남아 있었다.

Query Audit에서는 주문 상태를 변경한 UPDATE를 찾아봤다. 실행 결과는 Success였고, 사용자와 실행 시각, Read/Write 권한, Web Editor에서 실행했다는 정보가 표시됐다.

같은 상세 화면 아래에는 DB User와 대상 테이블, 실행한 SQL도 나왔다. 누가 어떤 권한으로 어느 DB 계정을 사용했고, 무슨 SQL을 실행했는지 이어서 확인할 수 있었다.

기존 DB 계정 구분을 권한 관리에 그대로 연결할 수 있었다
이번에 좋았던 점은 회사의 DB 계정 운영 방식과 QueryPie의 사용자 권한을 자연스럽게 연결할 수 있다는 것이었다. 조회용 계정과 작업용 계정을 유지하면서, 사용자가 맡은 업무에 맞게 접속 계정을 적용할 수 있었다.
사용자는 본인에게 주어진 연결로 작업하고, 관리자는 권한과 DB 계정을 한곳에서 관리한다. 여기에 실제 사용자와 작업 내용이 감사 기록으로 이어지니, 계정을 나눠 운영하는 이유가 접속과 작업 이력에도 분명하게 드러났다.
실습은 QueryPie Community 11.6.7과 MySQL 8.0.42에서 진행했다. 화면의 사용자와 주문 데이터는 실습용이다.
참고: Databases Configurations · DB Connections
![[40편] DB 접속 권한은 그대로 두고 허용 IP를 정해봤다](/assets/content/acp-lab-notes/database-ip-restrictions/01.webp)
![[42편] 운영 DB 작업에 두 단계 승인을 붙여봤다](/assets/content/acp-lab-notes/multi-step-approval/01.webp)