묵시적 커밋과 AUTO COMMIT | TRUNCATE와 DELETE 차이, 롤백 안 되는 자리

작업일2026. 07

트랜잭션 AUTO COMMIT 묵시적 커밋 DDL TRUNCATE

SQL 문법은 익숙해도 커밋이 정확히 언제 일어나는지 놓치기 쉽습니다. 그런데 데이터를 되돌릴 수 없게 만드는 사고는 대개 문법이 아니라 이쪽에서 납니다.

BEGIN을 안 적고 UPDATE를 실행하면 어떻게 될까요?
대부분의 DBMS에서 그 문장은 이미 확정된 상태입니다. ROLLBACK을 칠 기회가 없습니다.

WHERE를 빼고 UPDATE를 날린 이야기는 실수담처럼 돌아다닙니다. 그게 왜 되돌릴 수 없는 사고가 되는지는 AUTO COMMIT을 알아야 설명이 됩니다. 그리고 트랜잭션을 제대로 열었는데도 중간에 조용히 끊기는 경우가 있는데, 그것이 묵시적 커밋입니다.

AUTO COMMIT

DELETE와 TRUNCATE는 둘 다 데이터를 삭제하지만, DML과 DDL이라는 점에서 근본적으로 다릅니다. 이름만 보면 TRUNCATE가 DELETE의 빠른 버전처럼 보이지만, 트랜잭션과 롤백, 트리거 동작까지 모두 다릅니다.

AUTO COMMIT은 각 SQL 문장이 끝날 때마다 자동으로 COMMIT하는 설정입니다. 기본적으로 켜져 있으면 각 SQL 문장이 하나의 트랜잭션으로 처리되고, 실행이 성공적으로 끝나면 자동으로 COMMIT됩니다.

BEGIN 없이 실행하면

UPDATE students SET grade = 1;

 

즉시 COMMIT

이 뒤에 ROLLBACK 을 쳐도 되돌아오지 않습니다. 되돌릴 트랜잭션이 이미 없습니다

BEGIN 으로 명시적으로 열면

BEGIN;

UPDATE ...

 

확인 후 결정

몇 행이 바뀌었는지 보고 COMMIT 이나 ROLLBACK 을 고를 수 있습니다

DBMS마다 기본값과 트랜잭션 시작 방법이 다릅니다.

DBMS	기본 AUTO COMMIT	트랜잭션 시작	DDL 실행하면
PostgreSQL	ON	BEGIN;	트랜잭션 안에서 실행되고 롤백됩니다
MySQL (InnoDB)	ON	START TRANSACTION;	묵시적 커밋 (ALTER·CREATE·DROP·TRUNCATE)
Oracle	OFF	DML을 시작하면 자동으로 열립니다	DDL 전후로 자동 커밋
SQL Server	ON	BEGIN TRANSACTION;	트랜잭션 안에서 실행되고 롤백됩니다

Oracle만 기본 AUTO COMMIT이 OFF입니다. 그래서 Oracle을 쓰다 MySQL이나 PostgreSQL로 옮기면 실수가 자주 발생합니다. Oracle에서는 UPDATE 후 COMMIT을 해야 변경이 최종 확정되므로 ROLLBACK으로 되돌릴 수 있습니다. 반면 MySQL이나 PostgreSQL은 기본 AUTO COMMIT이 켜져 있어, 명시적으로 트랜잭션을 시작하지 않았다면 문장이 성공적으로 실행되는 즉시 자동으로 COMMIT됩니다.

강의자료 표에는 PostgreSQL의 묵시적 커밋 칸에 "DDL 실행"이 적혀 있는데 괄호에는 "대부분 트랜잭션 내 허용"이 함께 적혀 있습니다. 두 설명이 서로 반대라서 여기서는 실제 동작인 롤백 가능 쪽으로 적었습니다. BEGIN; CREATE TABLE ...; ROLLBACK; 을 돌려보면 테이블이 사라지는 것을 확인할 수 있습니다.

묵시적 커밋

묵시적 커밋(implicit commit)은 COMMIT을 적지 않았는데 DBMS가 커밋을 실행해 버리는 것입니다. 주로 DDL에서 일어납니다. MySQL과 Oracle에서는 테이블 구조를 변경하는 DDL은 진행 중인 트랜잭션을 자동으로 COMMIT합니다.

MySQL 에서 위에서 아래로 실행했다면

1

START TRANSACTION;

2

DELETE FROM orders WHERE id = 101;

3

CREATE INDEX idx_tmp ON orders (created_at);

← 여기서 2번이 묵시적으로 커밋됩니다

4

ROLLBACK;

오류 없이 실행되지만 되돌릴 것이 없습니다

삭제한 주문은 이미 COMMIT되어 되돌릴 수 없습니다. ROLLBACK 이 아무 경고 없이 성공하기 때문에, 되돌렸다고 믿고 넘어가면 나중에 데이터가 왜 사라졌는지 원인을 찾느라 시간을 쓰게 됩니다.

그러므로 DML과 DDL을 같은 트랜잭션 안에서 실행하지 않는 것이 기본 원칙입니다. 스키마를 바꾸는 작업과 데이터를 바꾸는 작업은 따로 실행해야 합니다.

궁금!묵시적 커밋과 묵시적 트랜잭션은 같은 말인가요?

다른 말입니다. 트랜잭션의 어느 쪽 끝이 자동이냐가 갈립니다. 묵시적 커밋은 끝이 자동입니다. COMMIT 을 적지 않았는데 커밋이 일어나며, 위에서 본 DDL 이 여기 해당합니다. 묵시적 트랜잭션은 반대로 시작이 자동입니다. BEGIN 없이 트랜잭션이 열리는 대신 커밋은 직접 해줘야 하고, SQL Server 의 SET IMPLICIT_TRANSACTIONS ON 이 이 동작을 켭니다. 이름은 비슷한데 방향이 반대라, 묵시적 트랜잭션을 켜는 쪽은 오히려 AUTO COMMIT 을 끄는 것에 가깝습니다.

DELETE와 TRUNCATE 차이

같은 함정이 TRUNCATE에도 있습니다. 이름만 보면 DELETE를 더 빠르게 수행하는 명령처럼 보이지만 분류가 다릅니다.

구분	TRUNCATE	DELETE
분류	DDL	DML
속도	빠릅니다	행마다 처리하므로 느립니다
롤백	MySQL·Oracle에서는 불가 (자동 커밋)	가능합니다
트리거	실행되지 않습니다	실행됩니다
WHERE	쓸 수 없습니다 (전체 삭제)	조건을 걸 수 있습니다

트리거가 안 돈다는 점이 특히 위험합니다. 삭제될 때 이력을 남기거나 관련 데이터를 정리하는 트리거를 걸어뒀다면, TRUNCATE로 삭제하면 그 트리거는 전혀 실행되지 않습니다.

정리하면

• AUTO COMMIT은 대부분 켜져 있습니다. Oracle만 기본이 OFF라, DBMS를 옮길 때 여기서 실수가 자주 발생합니다.
• 묵시적 커밋은 DDL에서 일어납니다. MySQL과 Oracle에서는 ALTER·CREATE·DROP·TRUNCATE가 진행 중인 트랜잭션을 끝냅니다
• ROLLBACK은 되돌릴 것이 없어도 성공합니다. 오류가 안 났다고 되돌아간 것은 아닙니다
• TRUNCATE는 DDL입니다. 빠른 DELETE가 아니라 롤백도 안 되고 트리거도 안 도는 다른 문장입니다

한 줄 정리: 커밋은 내가 입력하지 않아도 일어날 수 있고, ROLLBACK은 되돌릴 것이 없어도 성공합니다. 그래서 트랜잭션을 명시적으로 열고, 그 안에 DDL을 섞지 않습니다.

참고

• MySQL 공식 문서: Statements That Cause an Implicit Commit
• PostgreSQL 공식 문서: BEGIN
• PostgreSQL 공식 문서: TRUNCATE