리소스

/

ACP 실습 노트

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

DB 접근 제어

2026년 11월 9일

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

 

이번에는 QueryPie에서 이런 조건 누락을 막는 설정을 켜 봤다. 수정과 삭제 권한이 있는 계정으로 조건을 넣은 SQL과 빠뜨린 SQL을 차례로 실행하고, 데이터가 어떻게 남았는지 확인했다.

 

 

수정과 삭제 권한부터 준비했다

 

실습용 연결 DML Guard Lab을 만들고, 가상 주문 세 건을 넣었다. 주문번호는 35001, 35002, 35003이다. 앞의 두 건은 PENDING, 마지막 한 건은 TEMPORARY 상태로 시작했다.

 

Demo Developer에게는 이 연결의 SELECT·UPDATE·DELETE 권한을 줬다. 사용자 화면에서도 세 가지 작업이 허용돼 있는지 확인했다. 이 권한을 유지한 채 WHERE 조건에 따라 실행 결과가 달라지는지 볼 생각이었다.

 

화면 1. 실습 계정에는 조회뿐 아니라 수정과 삭제 권한도 부여했다.
화면 1. 실습 계정에는 조회뿐 아니라 수정과 삭제 권한도 부여했다.

 

 

관리자 화면에서 WHERE 차단 설정을 켰다

 

관리자 화면의 Databases → General → Configurations에서 Block UPDATE/DELETE without WHERE를 On으로 바꾸고 저장했다. 이름 그대로 WHERE 조건이 없는 UPDATE와 DELETE를 제한하는 옵션이며, 관리자 전역 설정으로 적용된다.

 

화면 2. WHERE 조건을 빠뜨린 UPDATE와 DELETE를 차단하도록 설정했다.
화면 2. WHERE 조건을 빠뜨린 UPDATE와 DELETE를 차단하도록 설정했다.

 

설정이 저장된 것을 확인한 뒤 Demo Developer의 웹 SQL 에디터에서 실습용 연결에 새로 접속했다. 이후 수정과 삭제는 모두 같은 연결에서 진행했다.

 

 

한 건만 수정하는 SQL은 실행됐다

 

먼저 주문번호 35001의 상태를 CHECKED로 바꿨다. UPDATE에 WHERE work_id = 35001을 넣어 대상을 지정했다. 결과 창에는 1 Rows updated.가 표시됐다.

 

화면 3. 주문번호를 지정한 UPDATE는 정상적으로 실행돼 한 행이 바뀌었다.
화면 3. 주문번호를 지정한 UPDATE는 정상적으로 실행돼 한 행이 바뀌었다.

 

이어서 같은 UPDATE에서 WHERE 조건만 뺐다. 상태를 CHECKED로 바꾸는 내용은 같지만, 이번에는 특정 주문을 고르는 조건이 없는 문장이다.

 

실행하자 Query execution blocked 창이 나타났다. 안내에는 There is no WHERE clause found라고 적혀 있었다. 조건이 빠졌다는 이유로 QueryPie가 실행을 차단한 것이다.

 

화면 4. WHERE를 뺀 UPDATE는 조건이 없다는 안내와 함께 차단됐다.
화면 4. WHERE를 뺀 UPDATE는 조건이 없다는 안내와 함께 차단됐다.

 

창을 닫고 테이블을 다시 조회했다. 35001만 CHECKED였고, 35002는 PENDING, 35003은 TEMPORARY로 남아 있었다. 처음 지정한 한 건만 바뀌었고, 조건을 빠뜨린 두 번째 UPDATE는 나머지 주문에 영향을 주지 않았다.

 

화면 5. 차단 후에도 세 행이 남았고, 나머지 두 주문의 상태는 그대로였다.
화면 5. 차단 후에도 세 행이 남았고, 나머지 두 주문의 상태는 그대로였다.

 

 

DELETE에서도 같은 차이를 확인했다

 

이번에는 TEMPORARY 상태인 주문 35003을 지웠다. WHERE work_id = 35003을 넣은 DELETE를 실행하니 1 Rows deleted.가 표시됐다. 대상을 지정한 삭제는 정상적으로 처리됐다.

 

화면 6. 주문번호 35003을 지정한 DELETE는 해당 한 행을 삭제했다.
화면 6. 주문번호 35003을 지정한 DELETE는 해당 한 행을 삭제했다.

 

그다음 WHERE가 없는 DELETE FROM ep35_guard.work_orders;를 실행했다. 이번에도 Query execution blocked 창이 나타났고, WHERE 조건이 없다는 이유가 표시됐다.

 

화면 7. 조건 없이 전체 행을 지우는 DELETE도 실행이 차단됐다.
화면 7. 조건 없이 전체 행을 지우는 DELETE도 실행이 차단됐다.

 

다시 조회해 보니 35001 CHECKED와 35002 PENDING, 두 행이 그대로 남아 있었다. 앞에서 지정해 삭제한 35003만 사라졌고, 나머지 데이터는 유지됐다.

 

화면 8. 차단 이후에도 남아 있던 두 주문을 그대로 조회할 수 있었다.
화면 8. 차단 이후에도 남아 있던 두 주문을 그대로 조회할 수 있었다.

 

 

작업 권한에 실수 방지 설정을 더할 수 있었다

 

수정과 삭제가 필요한 담당자에게 작업 권한을 주면서, WHERE 조건 누락은 별도로 막을 수 있다는 점이 유용했다. 같은 사용자와 연결에서 주문번호를 지정한 작업은 실행됐고, 조건을 뺀 작업은 차단됐다.

 

DB 운영 담당자 입장에서는 자주 쓰는 변경 작업에 보호 장치를 하나 더 두는 셈이다. QueryPie 관리자 화면에서 설정하고, 실행 화면에서는 차단 이유를 바로 확인할 수 있었다. 이번처럼 특정 주문만 수정하거나 삭제하는 업무에서 조건 누락으로 변경 범위가 커지는 일을 막는 데 도움이 되겠다.

 

실습은 QueryPie Community 11.6.7과 MySQL 8.0.42의 웹 SQL 에디터에서 진행했다. 사용자와 데이터는 모두 실습용이다. 확인을 마친 뒤 데이터는 처음 상태로 복원하고, 전역 차단 설정도 실습 전 값인 Off로 되돌렸다.

 

참고: QueryPie 11.6 릴리즈 노트 · DAC General Configurations