[3편] QueryPie ACP에 첫 DB 연결하기 — 개발자의 접속 방식은 어떻게 바뀔까?

지난 2편에서 Mac에 QueryPie ACP 커뮤니티 버전을 설치했다. 로그인까지 해봤으니, 이번에는 DB를 연결해서 실제로 데이터를 조회해 보려고 한다.

궁금했던 건 개발자가 쓰는 화면이었다. 관리자가 DB를 등록해 주면 개발자는 어디로 들어가서 SQL을 실행할까? 웹에서만 써야 할까, 쓰던 DB 클라이언트로도 접속할 수 있을까?

테스트용 주문 DB를 하나 만들고 QueryPie 웹 화면에서 먼저 조회했다. 이어서 DBeaver에 프록시 접속 정보를 직접 넣는 방법과, PC에 Multi Agent를 설치해 연결하는 방법도 해봤다. 세 방법 모두 같은 주문 5건이 나오는 것까지 확인했다.

사용한 버전은 QueryPie ACP Community 11.6.7과 MySQL 8.0.42다. 아래 화면에 나오는 고객과 주문은 전부 실습용으로 만든 가상 데이터다.

1. DB를 연결하고 직접 조회해 보자

우선 MySQL 컨테이너를 하나 더 띄웠다. QueryPie가 내부적으로 사용하는 DB와 섞이지 않도록 실습용 DB를 따로 준비했다.

DB 이름은 orders_demo로 정했다. customers 테이블에 고객 4명, orders 테이블에 주문 12건을 넣었다. 배송 대기 주문을 찾거나 상태별 건수를 세어 보면 접속과 조회가 잘 되는지 확인하기에 충분하다.

MySQL에는 orders_reader라는 계정을 만들고 orders_demo의 SELECT 권한만 줬다. 이번 편에서는 조회만 해볼 생각이라 DB 계정에도 그만큼의 권한만 열어 뒀다. 이 권한은 뒤에서 설정할 QueryPie 사용자 권한과는 별개다.

준비가 끝났으니 관리자 계정으로 DB를 등록하고, 개발자 계정으로 바꿔 접속해 보자.

2. QueryPie에 MySQL을 등록했다

관리자로 로그인한 뒤 Databases → Connection Management → DB Connections에서 MySQL 연결을 만들었다. 입력한 값은 아래와 같다.

• 연결 이름: Orders Demo MySQL

• DB 종류: MySQL

• Host / Port: orders-db / 3306

• Database Name: orders_demo

• DB 계정: orders_reader

Host에는 localhost 대신 orders-db를 넣었다. QueryPie와 MySQL을 같은 Docker 네트워크에 두었기 때문에 컨테이너 이름으로 접속할 수 있다. 여기서 localhost를 넣으면 QueryPie 컨테이너 자신을 가리키게 된다.

회사 DB를 연결할 때도 이 부분은 먼저 확인해야겠다. 내 PC에서 접속되는 주소인지보다, QueryPie 서버에서 그 DB까지 접속할 수 있는지가 중요하다.

DB 계정과 비밀번호까지 입력하고 Test Connection을 눌렀다. 연결 성공을 확인한 뒤 저장했다.

아래쪽의 Hide this credential from Connection List page도 체크했다. 사용자 연결 목록에서 원본 DB 인증 정보를 숨기는 옵션이다. 개발자에게 DB 비밀번호가 어떻게 보이는지는 개발자 계정으로 들어가서 확인해 보기로 했다.

3. 개발자 계정에는 읽기 권한만 줬다

관리자 계정으로 계속 테스트하면 개발자가 실제로 보게 될 화면을 놓칠 수 있다. General → User Management → Users에서 사용자를 하나 더 만들었다. 이름은 Demo Developer, 로그인 ID는 demo-dev다. 관리자 역할은 None으로 뒀다.

그다음 Databases → DB Access Control → Access Control로 이동했다. Demo Developer를 선택하고 Grant Privilege에서 방금 등록한 Orders Demo MySQL에 Read-Only 권한을 줬다.

해보니 DB를 등록하는 것과 사용자에게 접속 권한을 주는 작업이 따로 나뉘어 있었다. 이번에는 한 명에게 직접 권한을 줬지만, 사람이 많아지면 팀별 그룹으로 관리하는 편이 나을 것 같다. 임시로 접속하는 사람에게는 만료일을 두는 방법도 함께 검토해 볼 만하다.

4. 개발자로 로그인해서 주문을 조회해 봤다

이제 demo-dev로 로그인했다. 첫 로그인에서는 비밀번호를 바꾸라는 화면이 나왔다. 변경을 마치고 Databases의 QueryPie Connections를 펼치니 Orders Demo MySQL이 보였다.

연결을 선택하자 Read-Only (User), Select 권한과 Active 상태가 표시됐다. 여기까지 개발자가 원본 MySQL 비밀번호를 입력할 일은 없었다.

Connect를 누르니 웹 SQL 에디터가 열렸다. orders_demo에서 배송 대기 상태인 주문을 찾아봤다.

SELECT order_id, customer_id, order_date, status, total_amountFROM ordersWHERE status = 'PENDING'ORDER BY order_date, order_idLIMIT 20;

목록이 잘 나오는 것을 보고 상태별 주문 건수도 세어 봤다.

SELECT status, COUNT(*) AS order_countFROM ordersGROUP BY statusORDER BY status;

개발자 입장에서 해본 작업은 QueryPie에 로그인하고, DB를 고르고, SQL을 실행하는 정도였다. MySQL 계정과 비밀번호를 따로 전달받지 않아도 조회할 수 있었다.

물론 조회만으로 업무가 끝나지는 않는다. 이 계정에는 결과 복사나 내보내기, 트랜잭션 관련 권한이 체크돼 있지 않았다. 실제로 팀에서 쓰려면 이런 기능도 필요한 만큼 열어 주고 따로 테스트해야겠다.

5. DBeaver에서도 접속해 보자

이번에는 DBeaver에서도 같은 주문 데이터를 조회해 봤다. QueryPie 프록시로 접속하면 기존 DB 클라이언트에서도 SQL을 실행할 수 있다.

사용한 방법은 Agentless Proxy다. 별도 에이전트를 설치하지 않고 DB 클라이언트에서 QueryPie 프록시로 접속하는 방식이다.

다시 관리자 화면으로 돌아가 DB 연결 상세에서 Proxy Usage를 켰다. Use QueryPie registered account를 선택하고 저장했다. 이렇게 설정하면 QueryPie가 앞서 등록한 DB 계정으로 MySQL에 접속한다.

개발자 화면에서 Proxy Info를 열어 보니 포트 40000이 할당돼 있었다. Create Token을 눌러 접속에 쓸 Username과 Password를 발급받았다. DBeaver에는 MySQL의 원래 비밀번호 대신 이 토큰을 넣으면 된다.

토큰 값은 발급할 때만 확인할 수 있어 따로 안전하게 보관했다. 잃어버리면 기존 토큰을 폐기하고 다시 발급해야 한다. 아래 사진에는 토큰 값이 나오지 않는 안내 화면을 넣었다.

DBeaver를 열고 MySQL 연결을 새로 만들었다.

• Host: 127.0.0.1

• Port: 40000

• Database: orders_demo

• Username / Password: 개발자 계정에서 발급한 프록시 토큰

127.0.0.1은 QueryPie와 DBeaver가 같은 Mac에서 실행 중이라 넣은 주소다. 회사에서 여러 사람이 접속한다면 각자의 PC에서 접근할 수 있는 QueryPie 프록시 주소를 사용해야 한다. 해당 포트가 방화벽에서 허용돼 있는지도 확인해야 한다.

Test Connection을 누르니 MySQL 8.0.42에 연결됐다는 결과가 나왔다. 이어서 웹에서 실행했던 배송 대기 주문 쿼리를 그대로 붙여 넣었다.

이번에 실행한 쿼리는 웹과 DBeaver에서 똑같았다. DBeaver에서는 접속 주소와 포트, 로그인 정보만 QueryPie 프록시에 맞게 설정했다. 적어도 이번 MySQL 조회에서는 DB 도구를 바꾸지 않고 사용할 수 있었다.

6. PC에 Multi Agent를 설치해서 연결해 봤다

접속 정보를 직접 입력하는 방법 외에, PC에 에이전트를 설치해서 쓰는 방법도 있다. 이번에는 QueryPie Multi Agent를 설치하고 에이전트의 DB 목록에서 DBeaver를 열어 봤다.

QueryPie 오른쪽 위 프로필에서 Download & Support → Multi-Agent를 눌렀다. Mac, Windows, Linux용 설치 파일이 함께 나온다. 내 Mac에 맞는 Apple Silicon 파일을 받았다. 이 서버에서 제공하는 에이전트 버전은 v9였다.

내려받은 dmg 파일을 열고 QueryPieMultiAgent 앱을 Applications 폴더에 복사해 설치했다.

에이전트에 등록할 주소는 DB 주소가 아니라 QueryPie 웹 주소다. 이번 실습에서는 http://localhost:8000을 등록했다. 이미 다른 서버가 등록돼 있다면 Settings에서 Add New Host로 추가할 수 있다. 여러 QueryPie 서버를 함께 등록할 수 있어서 이름이 Multi Agent다.

서버를 선택하니 로그인 화면이 열렸다. 웹에서 사용한 개발자 계정 demo-dev로 로그인했다.

관리자가 먼저 해둘 설정도 하나 있다. 에이전트가 접속할 프록시 주소를 서버에 등록해야 한다. 이번에는 QueryPie와 에이전트를 같은 Mac에서 실행하므로 공식 초기 설정 가이드에 따라 127.0.0.1을 등록했다. 회사 서버라면 직원 PC에서 접근할 수 있는 프록시 IP나 도메인을 넣어야 한다. 이 작업은 관리자에게 필요한 초기 설정이고, 개발자가 각자 DB에 들어가 설정할 일은 아니다.

Databases에서 QueryPie Connections를 펼치니 Orders Demo MySQL이 보였다. 그 아래에는 orders-db와 Read-Only (User) 권한이 표시됐다. 웹에서 부여한 권한을 에이전트에서도 확인할 수 있었다.

orders-db를 우클릭하고 Open Connection With → DBeaver를 선택했다. DBeaver에 Orders Demo MySQL이라는 연결이 추가됐다. 앞에서 했던 것처럼 웹에서 토큰을 발급받아 접속 정보를 하나씩 입력할 필요가 없었다.

DBeaver에 추가된 Orders Demo MySQL 연결을 열고 새 SQL 에디터에서 같은 배송 대기 주문 쿼리를 실행했다. 이번에도 주문 1001, 1003, 1006, 1009, 1012가 나왔다.

직접 해보니 차이는 접속을 준비하는 과정에 있었다. 에이전트 없이 쓸 때는 토큰과 접속 정보를 DBeaver에 직접 넣었다. Multi Agent에서는 로그인한 다음 DB를 골라 DBeaver로 열면 됐다. 매일 여러 DB에 접속하는 팀이라면 이 방식도 함께 써보고 비교해 볼 만하다.

7. 회사에서 쓰려면 더 확인할 것들

직접 연결해 보니, 도입할 때 누구와 어떤 이야기를 나눠야 할지 조금 구체적으로 보였다.

우선 DB 등록과 권한 부여를 누가 맡을지 정해야 한다. 이번에는 혼자 관리자와 개발자를 번갈아 맡았지만, 회사에서는 개발자가 접속을 요청하면 누가 승인하고 권한을 줄지 정해져 있어야 한다. 팀을 옮기거나 퇴사했을 때 권한을 거두는 일도 마찬가지다.

개발팀이 실제로 쓰는 도구로 테스트하는 것도 필요하다. 나는 이번에 MySQL과 DBeaver에서 간단한 SELECT를 실행했다. 팀에서 DataGrip이나 다른 DB를 쓴다면 그 조합으로 다시 해봐야 한다. 조회량이 많을 때나 트랜잭션을 사용할 때도 같은 결과가 나올지는 아직 확인하지 않았다.

보안 기능도 설정 화면만 보고 넘어갈 수는 없다. Read-Only를 줬으니 변경 쿼리는 정말 막히는지, 권한을 회수하면 이미 연결된 세션은 어떻게 되는지 직접 해봐야 한다. Query Audit가 On인 것은 확인했지만, 실제 로그에 사용자와 쿼리가 어떻게 남았는지는 다음 편에서 살펴볼 생각이다.

8. DB에 바로 접속하는 길도 확인해야겠다

여기까지 하고 나니 1편에서 썼던 ‘침투 이후의 통제’가 다시 떠올랐다. QueryPie를 거쳐 접속하는 데는 성공했다. 그런데 원래 DB로 바로 들어갈 수 있는 길이 남아 있으면 어떻게 될까?

지금 내 실습 환경에도 그 길이 남아 있다. 비교와 점검을 위해 Mac의 127.0.0.1:13306에서 MySQL로 직접 접속할 수 있게 해뒀다. DBeaver에서 사용한 QueryPie 프록시 포트는 40000이다.

회사에 도입한다면 이 부분을 함께 정리해야겠다. DB에 접속할 수 있는 출발지를 제한하고, 원본 DB 계정을 누가 갖고 있는지도 확인해야 한다. 앞에서 체크한 인증 정보 숨김 옵션만으로 직접 접속까지 차단되는 것은 아니다.

DB 비밀번호나 개발자 PC가 유출됐을 때도 QueryPie의 통제를 거치게 하려면, 이런 접속 경로까지 챙겨야겠다는 생각이 들었다.

다음에는 수정 쿼리를 실행해 볼 생각이다

이번에는 DB를 등록하고 개발자 계정으로 접속해, 웹과 DBeaver에서 주문 데이터를 조회해 봤다. DBeaver에서는 접속 정보를 직접 넣는 방법과 Multi Agent에서 연결을 여는 방법까지 해봤다. 사용자는 익숙한 도구에서 SQL을 실행하면서 QueryPie에 부여된 권한으로 DB를 이용할 수 있었다.

다음 4편에서는 조금 더 들어가 보려고 한다. 읽기 권한만 가진 계정으로 데이터를 바꾸려 하면 어떤 메시지가 나오는지, 권한을 거두면 접속은 어떻게 되는지, 그 기록은 어디에 남는지 확인해 보겠다. DB 자체에도 SELECT 권한만 줬으니, 어느 쪽에서 작업을 막는지도 구분해서 살펴볼 예정이다.

참고 문서: Database Proxy 사용 활성화 · 에이전트 없이 프록시 접속하기 · Multi Agent 사용 가이드 · 설치 후 초기 설정