리소스

[1편] 해킹 이후, 공격자는 어디까지 갈 수 있을까 — 내가 ACP를 직접 써보려는 이유

최근 보안 사고 뉴스를 보면서 자꾸 같은 질문을 하게 된다. “공격자가 이미 내부에 들어왔다면, 우리는 무엇을 막을 수 있을까?”

2026년 11월 7일

[2편] QueryPie ACP 커뮤니티 버전 설치하기 — 도입 검토를 위한 첫 실습 환경 만들기

지난 글에서 던진 질문은 “공격자가 이미 내부에 들어왔다면, 어디까지 움직일 수 있을까?”였다. 그 질문에 답하려면 접근통제 제품의 기능 목록을 읽는 것에서 한 걸음 더 나아가야 한다. 실제 환경에 올려 보고, 계정과 권한을 설정하고, 허용한 작업과 차단한 작업이 어떻게 기록되는지 확인해야 한다. 이번에는 그 출발점으로 

2026년 11월 7일

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

지난 2편에서 Mac에 QueryPie ACP 커뮤니티 버전을 설치했다. 로그인까지 해봤으니, 이번에는 DB를 연결해서 실제로 데이터를 조회해 보려고 한다. 궁금했던 건 개발자가 쓰는 화면이었다. 관리자가 DB를 등록해 주면 개발자는 어디로 들어가서 SQL을 실행할까? 웹에서만 써야 할까, 쓰던 DB 클라이언트로도 접속할

2026년 11월 7일

[4편] QueryPie ACP 읽기 권한으로 UPDATE를 실행해 보면? — 쿼리 차단부터 권한 회수, 감사 로그까지

지난 편에서는 QueryPie에 DB를 등록하고 DBeaver로 주문 데이터를 조회했다. 접속 정보를 직접 넣는 방법과 Multi Agent에서 DBeaver를 여는 방법까지 써봤다. 조회가 되는 건 확인했으니, 이번에는 반대로 해보고 싶었다. 읽기 권한만 받은 개발자가 UPDATE를 실행하면 어떻게 될까? 관리자가 접근

2026년 11월 8일

[5편] QueryPie ACP에서 DB 권한 요청하고 승인받기 — DBeaver 조회까지 직접 해봤다

“주문 정산 내역을 확인해야 하는데, 내일까지 DB 조회 권한을 받을 수 있을까요?” DB를 운영하다 보면 이런 요청을 자주 받게 된다. 어떤 DB가 필요한지, 조회만 하면 되는지, 언제까지 쓸 것인지 확인하고 권한을 열어주는 일이다. 요청이 몇 건 없을 때는 메신저로도 처리할 수 있지만, 사람이 늘어나면 누가 어떤 이유

2026년 11월 8일

[6편] QueryPie ACP에서 SQL 승인받고 데이터 수정하기 — 조회 권한은 그대로, 필요한 작업만

운영 DB를 조회하다 보면 데이터를 한두 건 고쳐야 할 때가 있다. 배송은 끝났는데 주문 상태가 그대로이거나, 잘못 들어간 값을 정정해야 하는 경우다. 수정할 내용은 간단해도 운영 데이터인 만큼 누가 어떤 이유로 바꾸는지는 분명하게 남기고 싶다. 지난 5편에서는 필요한 DB 접근 권한을 요청하고 승인받아 봤다. 이번에는

2026년 11월 8일

[7편] DB 조회는 허용하고 개인정보는 가려봤다 — QueryPie 데이터 마스킹 실습

지난 6편에서는 조회 권한을 유지한 채, 승인을 받은 SQL로 필요한 데이터만 수정해 봤다. 이번에는 조회할 때 보이는 정보에 관심이 갔다. 배송 상태를 확인하려고 DB를 열었는데 고객의 전화번호와 이메일까지 함께 보인다면 어떨까. 주문이 정상적으로 처리됐는지 확인하는 데 연락처 전체가 꼭 필요한 것은 아니다. 그렇다고

2026년 11월 8일

[8편] 누가 고객 정보를 조회했을까? — QueryPie 감사 로그로 DB 사용 이력 찾아보기

지난 7편에서는 고객의 전화번호와 이메일에 마스킹을 적용했다. 개발자는 가려진 연락처를 보고, 원문이 필요한 담당자에게만 예외를 주는 것까지 확인했다. 이번에는 그다음 상황을 생각해 봤다. 배송 문의를 처리한 뒤 “4002번 주문은 누가 조회했나요?”라는 확인 요청이 들어온다면, 관리자는 어디에서 무엇을 찾아보면 될까.

2026년 11월 8일

[9편] 주문 조회는 허용하고 정산 정보는 보호했다 — QueryPie 테이블 접근 제한 실습

DB 접속을 허용했다고 해서 그 안의 모든 데이터를 볼 필요는 없다. 주문 상태를 확인하는 개발자에게 정산 금액이나 내부 메모까지 필요한 것은 아니기 때문이다. 이번에는 그 구분을 QueryPie ACP에서 직접 해봤다. 같은 DB 안에 주문 테이블과 정산 테이블을 두고, 개발자는 주문을 계속 조회하되 정산 정보에는 접근

2026년 11월 8일

[10편] “필요한 컬럼만 조회해 주세요” — QueryPie Query Rules로 SQL 사용 규칙 적용하기

“조회할 때는 필요한 컬럼만 적어 주세요.” DB를 함께 사용하는 팀이라면 한 번쯤 정해 봤을 규칙이다. 주문 상태만 확인하면 되는데 습관적으로 SELECT *를 쓰면 금액 같은 다른 컬럼까지 함께 가져오게 된다. 이런 사용 규칙을 QueryPie에서 적용해 보면 어떨까. 이번에는 Query Rules를 열어, 실습용 주

2026년 11월 8일

[11편] 가려진 전화번호가 필요할 때 — QueryPie 마스킹 해제 요청과 승인 실습

지난번에는 고객 연락처를 마스킹해서 조회해 봤다. 주문 정보는 그대로 확인하면서 전화번호와 이메일은 가릴 수 있었다. 그런데 배송 문의를 처리하는 담당자라면 고객에게 연락해야 할 때도 있다. 그때마다 관리자에게 전체 마스킹 설정을 바꿔 달라고 해야 할까? 이번에는 QueryPie의 마스킹 해제 요청(Unmasking Re

2026년 11월 8일

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

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

2026년 11월 8일

[13편] 정산 정보가 필요할 때 — QueryPie 제한 데이터 접근 승인 실습

9편에서는 주문 테이블은 조회할 수 있게 두고, 정산 테이블은 접근을 제한했다. 평소 주문 상태만 확인하는 개발자에게 정산 정보까지 열어 줄 필요는 없었다. 그런데 주문 금액과 정산 내역을 대조해야 하는 업무가 생기면 어떨까? 이번에는 QueryPie의 Restricted Data Access Request로 제한된 정산

2026년 11월 8일

[14편] 실행 중인 SQL을 멈춰봤다 — QueryPie 쿼리 모니터링

DB 접근 권한을 정하고 승인 절차를 마련해도, 운영하다 보면 이미 실행 중인 SQL을 살펴봐야 할 때가 있다. 조회가 평소보다 오래 걸린다는 연락을 받으면 누가 어느 DB에서 어떤 SQL을 실행했는지부터 찾게 된다. 이번에는 QueryPie의 Running Queries를 열어봤다. 개발자 계정으로 웹 SQL 편집기에서

2026년 11월 8일

[15편] 팀에 들어오면 DB 권한도 함께 — QueryPie 그룹 관리 실습

처음에는 사용자 한 명에게 DB 권한을 주는 것만으로도 충분했다. 그런데 같은 일을 하는 팀원이 늘어난다면 어떨까. 누구에게 어떤 권한을 줬는지 한 사람씩 확인하는 일이 점점 번거로워질 것 같았다. 이번에는 QueryPie에서 주문 분석팀을 만들어봤다. 팀에 읽기 전용 권한을 먼저 정해두고, 새 담당자를 그 팀에 추가했다

2026년 11월 8일

[16편] 이 DB 권한은 누가 줬을까? — QueryPie 관리자 변경 이력

지난 글에서는 주문 분석팀 그룹을 만들고, 새 담당자를 추가해 DB를 조회해봤다. 설정이 잘 적용되는 것을 확인하고 나니 한 가지가 더 궁금했다. 나중에 다른 담당자가 이 환경을 넘겨받으면, 지금의 권한이 어떻게 만들어졌는지도 알 수 있을까. 이번에는 QueryPie의 감사 메뉴에서 내가 조금 전 했던 작업을 찾아봤다.

2026년 11월 8일

[17편] 이 사용자는 무슨 작업을 했을까? — QueryPie 사용자 타임라인

“DB에는 접속됐는데 작업 하나가 안 됩니다.” 운영 담당자라면 이런 문의를 받았을 때 로그인부터 실패한 것인지, DB 연결 문제인지, 특정 SQL만 막힌 것인지 먼저 확인하게 된다. 이번에는 QueryPie의 User Timeline을 열어봤다. 지난 실습에서 주문을 조회하고 UPDATE는 차단됐던 Demo Analys

2026년 11월 8일

[18편] 임시 권한에도 끝나는 시간이 필요했다 — QueryPie 정책 예외 관리

“정산 금액만 잠깐 확인하고 싶습니다.” 이런 요청을 받아 권한을 열어 줬다면, 그다음에는 언제까지 허용할지도 챙겨야 한다. 업무는 끝났는데 예외 권한은 계속 남아 있는 상황을 피하고 싶어서다.

2026년 11월 9일

[19편] 주문 상태를 바꾼 뒤, 이전 값까지 찾아봤다 — QueryPie DML Snapshot

6편에서는 개발자에게 수정 권한을 계속 열어 주지 않고, 필요한 SQL만 승인받아 실행해 봤다. 이번에는 실행이 끝난 뒤의 기록을 살펴봤다. 누가 어떤 SQL을 실행했는지에 더해, 실제 데이터가 어떻게 바뀌었는지도 보고 싶었다. 가상 주문 한 건의 상태를 PENDING에서 DELIVERED로 바꾸고 QueryPie의 DM

2026년 11월 9일

[20편] 감사 자료를 준비할 때, 필요한 기록만 골라봤다 — QueryPie Audit Log Export

19편에서는 주문 상태를 바꾼 뒤 DML Snapshot으로 변경 전후 값을 확인했다. 이번에는 그 작업 기록을 파일로 꺼내 봤다. 감사나 내부 점검 때 특정 사용자가 어느 DB에서 어떤 작업을 했는지 자료로 전달해야 하는 상황을 생각했다. QueryPie의 Audit Log Export에서 기간과 사용자를 지정하니, 주

2026년 11월 9일

[21편] 감사 담당자에게 필요한 권한만 맡겨봤다 — QueryPie 관리자 역할 분리

앞선 글에서는 관리자 계정으로 DB 감사 기록을 보고 파일로 내려받았다. 실제 운영에서는 DB를 설정하는 사람과 그 기록을 점검하는 사람이 다를 수 있다. 감사 담당자가 자기 계정으로 필요한 자료를 확인할 수 있으면 좋겠다는 생각이 들었다. 이번에는 QueryPie에 감사 담당자 역할을 따로 만들었다. 그 계정으로 주문

2026년 11월 9일

[22편] 서버 비밀번호를 입력하지 않고 SSH에 접속했다 — QueryPie 웹 터미널

지금까지는 DB에 접속하고 데이터를 조회하거나 변경하는 과정을 살펴봤다. 이번에는 서버로 넘어가 봤다. 서버에 접속할 사람이 늘어날 때마다 비밀번호를 따로 알려 주는 대신, QueryPie에서 권한을 주고 접속하게 해 보고 싶었다. 실습용 Ubuntu 서버를 등록하고 개발자 계정에 SSH 접속 역할을 부여했다. 개발자는

2026년 11월 9일

[23편] 서버 접속은 허용하고, 삭제 명령은 막았다 — QueryPie 명령어 통제

지난 글에서는 개발자 계정으로 웹 터미널에 접속했다. 서버 비밀번호를 따로 알려 주지 않아도 접속할 수 있었다. 이번에는 서버에 들어온 뒤 실행하는 명령을 제한해 봤다. 상황은 간단하게 잡았다. 담당자는 서버의 계정과 파일 내용을 확인할 수 있지만, 파일을 지우는 rm 명령은 사용하지 못하게 하는 것이다. 실습용 파일 하

2026년 11월 9일

[24편] 서버에서 한 작업을 다시 재생해봤다 — QueryPie 세션 녹화

지난 글에서는 서버의 rm 명령을 제한하고 감사 기록까지 확인했다. 기록에는 누가 어떤 명령을 입력했고, 그 명령이 차단됐는지가 남아 있었다. 이번에는 그때 사용했던 터미널 화면을 다시 열어 봤다. QueryPie의 Session Logs에서 작업 세션을 골라 재생하니, 접속 당시 화면과 명령 결과가 다시 나타났다. 삭제

2026년 11월 9일

[25편] MCP로 DB를 조회해도, 정해 둔 권한은 그대로였다 — QueryPie Community MCP

AI 도구에 DB를 연결할 때는 누가 어떤 데이터를 볼 수 있는지가 먼저 궁금했다. 업무에 필요한 주문 정보는 조회하되, 정산 자료처럼 따로 관리하는 데이터는 기존 권한에 맞춰 보호하고 싶었다. QueryPie Community에는 MCP 서버가 들어 있다. 이번에는 MCP Inspector를 연결해 주문을 조회하고, 같

2026년 11월 9일

[26편] Kubernetes 설정은 읽고, 변경은 막아봤다 — QueryPie 역할과 접근 정책

운영 중인 Kubernetes 설정을 확인해야 한다고 해서, 그 설정을 바꾸는 권한까지 필요한 것은 아니다. 장애를 살펴보거나 배포 상태를 점검할 때도 현재 값을 읽는 것만으로 충분한 일이 많다. 이번에는 QueryPie Community에서 개발자에게 ConfigMap 조회 권한을 주고, 설정값을 바꾸는 요청은 막아 봤

2026년 11월 9일

[27편] DBeaver는 그대로, DB 직접 접속은 닫아봤다 — QueryPie 접속 경로 정리

QueryPie로 DB 권한을 관리하고 작업 기록을 남겨도, 사용자가 예전 DB 주소로 직접 접속한다면 그 경로는 따로 정리해야 한다. 도입을 준비하는 입장에서는 “앞으로 어디로 접속하게 할 것인가”도 중요한 문제다. 이번에는 DBeaver에서 같은 DB에 두 가지 방법으로 접속해 봤다. 먼저 DB에 직접 연결하고, 다음

2026년 11월 9일

[28편] 막아 둔 삭제 명령이 필요할 때 — 승인받은 시간 동안만 사용해 봤다

23편에서는 서버에 접속할 수 있어도 삭제 명령은 실행하지 못하도록 막아 봤다. 그런데 운영하다 보면 오래된 파일을 정리하는 것처럼, 평소 제한한 명령을 꼭 써야 할 때가 있다. 이번에는 기존 제한을 그대로 두고 필요한 시간만 승인받아 작업해 봤다. QueryPie의 Server Privilege Request로 rm 사

2026년 11월 9일

[29편] 로그는 확인하고, 컨테이너 셸 접속은 제한해봤다

장애가 나면 가장 먼저 로그부터 확인하게 된다. 그런데 로그를 보는 사람 모두에게 컨테이너 안에서 명령을 실행할 권한까지 필요한 것은 아니다. 원인을 살펴보는 일과 직접 조치하는 일을 나눠 맡기는 경우도 많다. 26편에서는 쿠버네티스 설정을 읽는 권한과 바꾸는 권한을 구분해 봤다. 이번에는 같은 Pod에서 로그 조회와 셸

2026년 11월 9일

[30편] 지금 연결된 서버 세션을 찾아 종료해봤다

서버 접속을 허용한 뒤에도 관리할 일은 남는다. 지금 누가 접속해 있는지 확인하고, 필요할 때는 특정 연결을 끝낼 수 있어야 한다. 접근 권한을 정하는 것과 이미 열려 있는 연결을 관리하는 것은 서로 다른 일이기 때문이다. 24편에서는 서버에서 했던 작업을 녹화로 다시 확인했다. 이번에는 접속 중인 SSH 세션을 관리자

2026년 11월 9일

[31편] 서버 파일은 내려받고, 업로드는 막아봤다

운영 서버에서 상태 파일이나 점검 자료를 내려받아야 할 때가 있다. 자료를 확인하는 업무라면 파일을 올리는 권한까지 함께 줄 필요는 없을 것이다. 이번에는 QueryPie의 웹 SFTP로 이 두 작업을 나눠 봤다. 같은 사용자와 서버 계정으로 파일을 주고받아 본 뒤, 업로드만 제한했다. 필요한 파일은 계속 내려받을 수 있

2026년 11월 9일

[32편] 조회한 이유를 SQL과 함께 남겨봤다

감사 기록을 보면 누가 어떤 SQL을 실행했는지 알 수 있다. 그런데 같은 주문 조회라도 배송 문의 때문에 봤는지, 처리 내역을 맞춰 보려던 것인지는 SQL만으로 알기 어렵다. 이번에는 조회할 때 그 이유도 함께 남겨 봤다. QueryPie에서 SQL 실행 사유를 입력하도록 설정하고, 서로 다른 업무를 가정해 주문 두 건

2026년 11월 9일

[33편] DB 권한과 접속 이력을 보고서로 묶어봤다

DB 권한을 점검할 때는 두 가지가 궁금하다. 이 사람에게 지금 어떤 권한이 있는지, 최근에는 어느 DB에 접속했는지다. 권한 목록과 접속 기록을 함께 보면 사용 현황을 파악하기가 한결 쉽다. 이번에는 QueryPie의 Reports로 이 두 자료를 묶어 봤다. 앞선 실습에 사용한 Demo Developer 한 명을 골라

2026년 11월 9일

[34편] 같은 서버에 있는 DB도 업무별로 권한을 나눠봤다

같은 DB 서버에 여러 업무의 데이터베이스를 함께 두는 경우가 있다. 그렇다고 주문을 확인하는 담당자에게 정산 자료까지 모두 열어 줄 필요는 없다. 이번에는 QueryPie에서 담당자가 조회할 수 있는 DB를 따로 정해 봤다. 앞서 테이블별 접근 제한을 다뤘다면, 이번에는 DB 자체를 나누는 설정이다. 하나의 MySQL

2026년 11월 9일

[35편] WHERE를 빠뜨린 UPDATE와 DELETE를 막아봤다

주문 한 건의 상태를 바꾸려고 UPDATE를 작성했다가 WHERE 조건을 빠뜨리면 어떻게 될까. 실행 버튼을 누르는 순간 다른 주문까지 함께 바뀔 수 있다. DELETE라면 테이블에 남아 있는 데이터를 모두 지울 수도 있다. 이번에는 QueryPie에서 이런 조건 누락을 막는 설정을 켜 봤다. 수정과 삭제 권한이 있는 계

2026년 11월 9일

[36편] 조회는 허용하고 파일 내보내기는 따로 관리해봤다

배송 상태를 확인하는 업무는 화면에서 주문을 조회하는 것으로 충분할 때가 있다. 조회한 데이터를 파일로 내려받는 기능은 업무에 따라 따로 허용하고 싶었다. 이번에는 QueryPie 웹 SQL 에디터에서 조회 권한과 파일 내보내기 권한을 나눠 봤다. 먼저 주문 세 건을 CSV로 내려받은 다음, 같은 권한에서 Can Expo

2026년 11월 9일

[37편] SQL을 승인하기 전에 실행 계획도 함께 봤다

SQL을 승인할 때는 쿼리 내용과 작업 사유를 읽게 된다. 여기에 DB의 실행 계획도 함께 있으면 어떤 테이블과 인덱스를 사용할지 살펴보며 검토할 수 있다. 이번에는 QueryPie의 SQL Request에 실행 계획을 붙여 보냈다. 작성자가 확인한 자료를 승인자도 같은 요청 안에서 열어 볼 수 있는지 직접 확인했다.

2026년 11월 9일

[38편] 서버 태그를 바꾸니 그룹 구성도 따라 바뀌었다

서버를 등록하고 접속 권한을 정하는 것까지는 앞선 글에서 해 봤다. 이번에는 등록한 서버들을 어떻게 묶어 관리할 수 있는지 살펴봤다. 서버의 용도나 분류가 달라질 때 그룹 목록도 하나씩 고쳐야 하는지 궁금했다. QueryPie의 Server Groups에는 태그 조건으로 서버를 포함하는 기능이 있다. 같은 실습 서버를 태

2026년 11월 9일

[39편] DB 담당자가 바뀌어도 결재 규칙은 그대로였다

SQL 승인 규칙을 만들어 두면 요청을 정해진 담당자에게 보낼 수 있다. 그런데 DB 담당자가 바뀌면 결재 규칙에 들어 있는 승인자도 다시 고쳐야 할까? 이번에는 QueryPie의 Connection Owner를 승인자로 사용하는 규칙을 만들어 봤다. 첫 요청을 처리한 뒤 DB 연결의 담당자만 바꾸고, 같은 규칙으로 올린

2026년 11월 9일

[40편] DB 접속 권한은 그대로 두고 허용 IP를 정해봤다

DB 조회 권한을 받은 사람이라도 접속할 수 있는 IP까지 함께 정해 두고 싶을 때가 있다. 업무에 필요한 권한은 주되, 정해진 네트워크에서만 DB를 사용하게 하는 방식이다. 이번에는 QueryPie의 Allowed Zone을 써봤다. 같은 사용자에게 같은 조회 권한을 둔 채 허용 IP만 바꿔 보고, 다시 원래 값으로 되

2026년 11월 13일

[41편] 조회용 권한과 작업용 권한에 서로 다른 DB 계정을 연결해봤다

DB를 운영하다 보면 조회용 계정과 작업용 계정을 따로 두게 된다. 주문 내역을 확인하는 사람에게는 조회 권한만 주고, 상태를 바꾸는 담당자에게는 필요한 변경 권한을 주는 식이다. 이번에는 이렇게 나눠 둔 DB 계정을 QueryPie 권한에 연결해봤다. Advanced Privilege를 사용하면 같은 DB 연결에서도 권

2026년 11월 13일

[42편] 운영 DB 작업에 두 단계 승인을 붙여봤다

운영 DB 작업을 승인할 때 한 사람의 확인만으로 끝내기 어려운 경우가 있다. 개발 담당자가 SQL과 조회 조건을 먼저 살펴보고, 운영 담당자가 대상과 작업 목적을 확인한 뒤 최종 승인하는 식이다. 이번에는 그 순서를 QueryPie에 넣어봤다. SQL Request에 승인 단계를 두 개 만들고, 서로 다른 담당자가 차례

2026년 11월 13일

[43편] 평소 쓰던 Mac 터미널로 서버에 접속해봤다

서버에 접속할 때는 터미널이 가장 익숙하다. 계정을 확인하고, 파일을 살펴보고, 필요한 명령을 입력하는 작업을 매일 쓰던 도구에서 이어가고 싶었다. 이번에는 Mac 터미널에서 Multi Agent를 거쳐 실습 서버에 접속해봤다. 접속한 뒤에는 간단한 점검 명령을 실행하고, 관리자가 제한한 삭제 명령도 입력했다. 마지막으로

2026년 11월 13일

[44편] kubectl을 그대로 쓰면서 접근 범위를 나눠봤다

쿠버네티스를 운영하는 팀이라면 kubectl을 자주 쓸 것이다. 설정을 확인할 때마다 웹 화면으로 옮겨가기보다, 평소 쓰던 명령으로 필요한 내용을 바로 보고 싶다. 이번에는 Multi Agent와 kubectl로 실습 클러스터에 접속해봤다. 같은 ConfigMap을 읽고 값을 바꾸는 요청을 차례로 보낸 뒤, QueryPi

2026년 11월 13일

[45편] 컨테이너 안에서 한 작업도 다시 재생해봤다

컨테이너에 접속했다는 기록을 보고 나면, 그 안에서 무슨 작업을 했는지도 궁금해진다. 장애를 점검하다 어떤 파일을 읽었는지, 화면에는 어떤 값이 나왔는지까지 확인할 수 있으면 작업 내용을 훨씬 쉽게 이해할 수 있다. 이번에는 테스트 Pod에 들어가 짧은 점검을 하고, Pod Session Recordings에서 그 작업을

2026년 11월 13일

[46편] 서버 계정 비밀번호를 QueryPie에서 바꿔봤다

서버 계정 비밀번호를 바꾸는 일은 변경 버튼을 누르는 것으로 끝나지 않는다. 바뀐 비밀번호로 접속할 수 있는지 확인하고, 작업하는 사람에게도 새 접속 방법을 알려줘야 한다. 서버가 늘어나면 어느 계정을 언제 바꿨는지 챙기는 일도 만만치 않다. 이번에는 QueryPie의 Password Provisioning으로 테스트 서

2026년 11월 13일

[47편] 차단된 SQL 실행을 알림으로 받아봤다

앞선 실습에서 권한 없는 SQL이 차단되는 것은 확인했다. 운영하는 입장에서는 그다음도 궁금했다. 누군가 권한 밖의 작업을 시도했을 때, 담당자가 감사 화면을 열어보지 않아도 알 수 있을까? 이번에는 QueryPie의 Alerts로 차단된 SQL 실행을 알림으로 받아봤다. 조회만 허용된 계정으로 UPDATE를 실행하고,

2026년 11월 13일

[48편] 외부 유지보수 담당자에게 필요한 작업만 맡겨봤다

외부 유지보수 담당자에게 DB 점검을 맡길 때면 권한을 어디까지 열어줘야 할지부터 고민하게 된다. 주문 상태를 확인하는 일인데 데이터를 바꿀 권한까지 줄 필요는 없고, 작업이 끝난 뒤에도 접속 권한을 남겨둘 이유는 없다. 이번에는 QueryPie에서 이 과정을 처음부터 끝까지 해봤다. 테스트 사용자에게 외부 유지보수 담당

2026년 11월 13일

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

운영 DB의 값을 바꾼 뒤에는 “변경했습니다”라는 말만으로 설명이 끝나지 않을 때가 많다. 왜 바꿨는지, 누가 확인했는지, 실제로 어느 값이 달라졌는지를 함께 봐야 작업 경위가 분명해진다. 앞선 글에서 SQL 승인, DML Snapshot, 감사 로그 내보내기를 각각 써봤다. 이번에는 주문 한 건을 정정하는 작업으로 묶어

2026년 11월 13일

[50편] 해킹 이후, 공격자는 어디까지 갈 수 있을까 — ACP 첫 연재를 마치며

첫 글을 쓸 때 가장 마음에 걸렸던 것은 계정 하나가 노출된 다음의 일이었다. 그 계정으로 다른 서버에 들어갈 수 있다면, 필요한 것보다 많은 데이터를 읽을 수 있다면, 한 번의 사고가 어디까지 커질까. 그래서 QueryPie ACP 커뮤니티 버전을 직접 설치했다. Mac에서 테스트 DB를 연결하는 것부터 시작해 서버와

2026년 11월 13일