리소스

/

ACP 실습 노트

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

승인 · 감사 · 운영

2026년 11월 8일

“DB에는 접속됐는데 작업 하나가 안 됩니다.” 운영 담당자라면 이런 문의를 받았을 때 로그인부터 실패한 것인지, DB 연결 문제인지, 특정 SQL만 막힌 것인지 먼저 확인하게 된다.

 

이번에는 QueryPie의 User Timeline을 열어봤다. 지난 실습에서 주문을 조회하고 UPDATE는 차단됐던 Demo Analyst의 기록을 찾아봤다. 사용자 한 명을 기준으로 접속과 SQL 실행을 함께 보니, 당시 어떤 일이 있었는지 따라가기가 한결 편했다.

 

 

1. 사용자와 기간을 정해 활동을 찾았다

 

관리자 화면의 Audit → General → User Timeline으로 이동했다. 이번 실습 환경에서는 메뉴에 Beta 표시가 붙어 있었다.

 

User에서 Demo Analyst를 고르고, 기간은 실습을 진행한 2026년 11월 8일로 뒀다. 정렬은 최신 기록부터 보는 Newest first를 사용했다. Event Sources에서는 조회할 로그 종류를 선택할 수 있었다.

 

화면 1. 사용자와 기간을 지정해 타임라인을 검색했다.
화면 1. 사용자와 기간을 지정해 타임라인을 검색했다.

 

 

2. 로그인과 DB 사용 기록이 한 목록에 나왔다

 

Search를 누르자 이날의 기록 11건이 나타났다. 로그인과 로그아웃, DB 연결과 종료, SELECT 성공과 UPDATE 차단이 같은 목록에 표시됐다.

 

각 기록에는 시각, 로그 출처, 이벤트, 결과, 사용자와 접속 IP가 있었다. 같은 사용자를 찾기 위해 여러 로그 화면에서 검색을 반복하지 않아도, 우선 전체 흐름을 이곳에서 볼 수 있었다.

 

화면 2. 한 사용자의 로그인, DB 연결, SQL 실행 결과를 시간순으로 확인했다.
화면 2. 한 사용자의 로그인, DB 연결, SQL 실행 결과를 시간순으로 확인했다.

 

로그인 항목도 열어봤다. 상세에는 Demo Analyst의 로그인 ID와 이메일, 17:53:01의 로그인 시각, 접속 IP가 표시됐다. 해당 사용자가 로그인에 성공한 상태에서 작업을 시작했다는 것을 확인했다.

 

화면 3. 로그인 이벤트를 열어 사용자와 접속 정보를 확인했다.
화면 3. 로그인 이벤트를 열어 사용자와 접속 정보를 확인했다.

 

 

3. 막힌 작업을 누르니 이유까지 확인됐다

 

눈에 먼저 들어온 것은 17:55:27의 UPDATE였다. 목록의 결과는 BLOCKED로 표시됐다. 항목을 열자 Timeline Event Details에 당시 사용자의 Read-Only 권한과 대상 DB인 Orders Control Lab이 나왔다.

 

화면 4. 차단된 UPDATE의 실행 계정, 권한과 대상 DB를 확인했다.
화면 4. 차단된 UPDATE의 실행 계정, 권한과 대상 DB를 확인했다.

 

상세 화면을 아래로 내려보니 실제 SQL과 오류 문구도 남아 있었다. No permission to execute UPDATE statement라는 메시지로, 데이터를 수정할 권한이 없어서 막힌 것임을 알 수 있었다.

 

이 UPDATE는 앞선 실습에서 읽기 전용 권한을 확인하기 위해 실행한 문장이다. 존재하지 않는 주문 번호 -1을 조건으로 사용했으며, QueryPie에서 실행이 차단됐다. 사용자에게 보였던 오류와 관리자 기록이 같은 작업을 가리키고 있었다.

 

화면 5. 실제 SQL과 권한 부족으로 차단됐다는 사유를 확인했다.
화면 5. 실제 SQL과 권한 부족으로 차단됐다는 사유를 확인했다.

 

 

4. 바로 앞의 정상 조회와 비교해봤다

 

차단 기록 바로 앞에는 17:55:06의 SELECT가 있었다. 이 항목을 열었을 때는 Result가 Success였고, 웹 SQL 편집기에서 Read-Only 권한으로 실행한 작업임을 확인할 수 있었다.

 

앞서 주문 세 건을 조회한 작업은 성공했고, 그다음 UPDATE만 차단된 것이다. 이 두 기록을 함께 보니 DB를 전혀 사용할 수 없는 상황과, 허용된 작업 범위를 벗어난 상황을 구분하기 쉬웠다.

 

화면 6. 같은 사용자의 정상적인 SELECT는 Success로 기록돼 있었다.
화면 6. 같은 사용자의 정상적인 SELECT는 Success로 기록돼 있었다.

 

 

5. DB 관련 기록만 추려보니 더 간단해졌다

 

이번에는 Event Sources에서 Databases만 선택했다. DB Access History, DB Query Audit, DB Access Control Logs가 선택된 상태로 다시 검색했다.

 

화면 7. DB 관련 로그만 보도록 조회 출처를 좁혔다.
화면 7. DB 관련 로그만 보도록 조회 출처를 좁혔다.

 

결과는 네 건이었다. 17:54:50의 DB 연결, 17:55:06의 조회 성공, 17:55:27의 UPDATE 차단, 18:02:11의 연결 종료가 보였다. 필요한 기록만 남기니 이번 실습의 DB 사용 흐름이 더 분명해졌다.

 

화면 8. DB 연결부터 조회, 차단, 연결 종료까지 네 기록으로 확인했다.
화면 8. DB 연결부터 조회, 차단, 연결 종료까지 네 기록으로 확인했다.

 

 

6. 사용자 문의를 조사할 때 활용하기 좋겠다

 

직접 사용해보니 User Timeline은 특정 사용자의 작업을 따라가고 싶을 때 편했다. 사용자와 시간을 정해 전체 활동을 보고, 궁금한 항목에서 SQL이나 접속 정보를 확인하고, 필요하면 로그 종류를 줄이면 됐다.

 

도입 담당자 입장에서는 통제 기능이 잘 동작하는 것과 함께, 현업 문의에 답할 수 있는지도 중요하다. 이번에는 조회는 정상적으로 끝났고 변경 작업은 읽기 전용 권한에 따라 차단됐다는 사실을 같은 흐름 안에서 확인할 수 있었다.

 

누가 무엇을 했는지뿐 아니라, 어디까지 성공했고 어느 작업이 왜 막혔는지를 살펴볼 수 있다는 점이 좋았다. 보안 정책을 운영하면서 사용자에게 상황을 설명해야 하는 담당자에게 유용한 화면이었다.