SQL INSERT 후 COMMIT과 ROLLBACK: 트랜잭션을 되돌릴 수 있는 범위

SQL 콘솔에서 INSERT한 행이 같은 연결에서는 보이는데 다른 연결에서는 보이지 않는다면, 트랜잭션이 아직 끝나지 않았을 수 있다. 다만 도구의 자동 커밋 설정에 따라 결과가 달라지므로 시작부터 트랜잭션을 명시해 보자. 아래 예제는 별도의 연습용 테이블을 사용한다.

INSERT는 트랜잭션 안에서 변경을 만든다

도식에서 INSERT는 변경을 만들지만, 트랜잭션의 최종 결과는 COMMIT과 ROLLBACK 중 무엇을 선택하는지에 따라 갈린다. 주문 한 건을 넣고 취소하는 흐름부터 보자.

CREATE TABLE todo (
  id INTEGER PRIMARY KEY,
  title VARCHAR(100) NOT NULL,
  done CHAR(1) NOT NULL
);

BEGIN TRANSACTION;
INSERT INTO todo (id, title, done)
VALUES (101, '트랜잭션 확인', 'N');

SELECT id, title FROM todo WHERE id = 101;

같은 세션에서는 방금 넣은 101번 행을 조회할 수 있다. 이 상태에서 COMMIT을 실행하면 변경이 확정된다. 다른 연결에서 언제 보이는지는 데이터베이스의 격리 설정과 기존 조회 트랜잭션의 상태도 함께 영향을 준다.

COMMIT;

커밋은 '저장 버튼'에 가깝지만 되돌리기 버튼은 아니다. 커밋한 뒤에는 보통 ROLLBACK으로 방금 변경만 취소할 수 없다. 삭제나 보정 SQL을 별도로 작성해야 하므로, 특히 운영 데이터에서는 커밋 전에 대상 행을 다시 확인하는 습관이 필요하다.

ROLLBACK은 아직 확정하지 않은 변경을 취소한다

테스트 데이터라면 결과를 확인한 뒤 다음처럼 되돌릴 수 있다.

BEGIN TRANSACTION;
INSERT INTO todo (id, title, done)
VALUES (102, '임시 행', 'N');

ROLLBACK;
SELECT id, title FROM todo ORDER BY id;

조회 결과에는 101번만 남아야 한다. 102번 행은 확정되지 않았으므로 취소된다. 여러 INSERT와 UPDATE를 한 번의 업무 처리로 묶었다면, 중간 검증 실패 시 모두 되돌려 데이터가 반쯤만 바뀌는 일을 막는다. COMMIT 전에 검증 쿼리의 조건이 맞는지도 확인하자.

자동 커밋 설정을 먼저 확인한다

도구나 드라이버는 자동 커밋을 켤 수 있다. 명시적으로 트랜잭션을 시작하지 않은 상태에서 자동 커밋이 켜져 있으면 각 문장이 바로 확정되어 뒤늦은 ROLLBACK으로 되돌릴 수 없다. 콘솔에서 되돌아갔던 예제가 애플리케이션에서는 되돌아가지 않는다면, SQL 자체보다 연결 설정과 트랜잭션 시작·끝 위치를 먼저 확인하자.

프레임워크를 쓸 때도 원리는 같다. 서비스 메서드의 트랜잭션 경계 안에서 여러 변경을 처리하고, 예외가 나면 어떤 예외에서 롤백할지 명시한다. 예외를 잡아서 아무 일 없었다는 듯 끝내면 롤백 조건이 사라질 수 있다.

DDL은 별도 경계로 생각한다

테이블 생성·변경 같은 DDL은 데이터 변경 언어(DML)와 트랜잭션 동작이 다를 수 있다. 예제에서도 CREATE TABLE을 먼저 끝내고 그다음 INSERT용 트랜잭션을 시작했다. 사용하는 데이터베이스가 DDL 전후에 암묵적으로 커밋하는지 확인하지 않고, CREATE TABLE 뒤 ROLLBACK만 믿으면 기대와 다른 결과를 볼 수 있다. 스키마 변경은 전용 마이그레이션 절차로 관리하는 편이 안전하다.

핵심 요약

INSERT 뒤의 변경은 보통 COMMIT 전까지 현재 트랜잭션에 남고, 그때는 ROLLBACK으로 취소할 수 있다. 자동 커밋이 켜져 있으면 이 전제가 달라진다. 커밋 전에는 대상과 결과를 확인하고, 여러 변경은 하나의 업무 트랜잭션으로 묶어 반쪽짜리 데이터를 막자.