@Transactional 정리

@Transactional 완전 정복 — 스프링 트랜잭션의 동작 원리(AOP 프록시)부터 7가지 전파 옵션, 격리 수준별 동시성 문제, 롤백 규칙과 readOnly까지 코드와 함께 정리한다.

들어가며

@Transactional은 스프링에서 가장 많이 쓰는 애너테이션 중 하나다. 메서드 위에 한 줄 붙이면 트랜잭션이 알아서 시작되고 커밋되니, 동작 원리를 몰라도 대부분은 잘 돌아간다.

문제는 "대부분"이다. 어느 날 분명 예외가 터졌는데 데이터가 롤백되지 않거나, 다른 메서드를 호출했더니 트랜잭션이 의도와 다르게 묶이거나, 같은 클래스 안에서 호출한 @Transactional 메서드가 아예 동작하지 않는 일이 생긴다. 이 함정들은 전부 @Transactional이 내부적으로 어떻게 동작하는지를 모르면 디버깅조차 어렵다.

이전 N+1 글이 "잘 돌아가는데 느린" 문제였다면, 트랜잭션은 "잘 돌아가는 줄 알았는데 데이터가 안 맞는" 문제다. 둘 다 운영에서야 터진다. 이 글에서는 동작 원리(프록시) → 전파(Propagation) → 격리 수준(Isolation) → 롤백 규칙 → 자주 하는 실수 순으로 정리한다. 예제는 Spring Boot 4 / Spring Framework 6.x 기준이다.

---

1. 트랜잭션과 ACID

트랜잭션(Transaction)은 더 이상 쪼갤 수 없는 하나의 작업 단위다. 계좌 이체를 떠올리면 쉽다. "A 계좌에서 출금"과 "B 계좌로 입금"은 반드시 함께 성공하거나 함께 실패해야 한다. 출금만 되고 입금이 안 되면 돈이 증발한다.

이 보장을 흔히 ACID로 요약한다.

속성	의미
Atomicity (원자성)	전부 성공하거나 전부 실패한다. 중간 상태는 없다
Consistency (일관성)	트랜잭션 전후로 데이터 무결성 규칙이 유지된다
Isolation (격리성)	동시에 실행되는 트랜잭션끼리 서로 간섭하지 않는다
Durability (지속성)	커밋된 결과는 장애가 나도 보존된다

스프링의 @Transactional은 이 중 원자성과 격리성을 애플리케이션 레벨에서 선언적으로 다루게 해준다.

@Service
@RequiredArgsConstructor
public class TransferService {

    private final AccountRepository accountRepository;

    @Transactional
    public void transfer(Long fromId, Long toId, long amount) {
        Account from = accountRepository.findById(fromId).orElseThrow();
        Account to = accountRepository.findById(toId).orElseThrow();

        from.withdraw(amount);   // 출금
        to.deposit(amount);      // 입금
        // 메서드가 정상 종료되면 커밋, 예외가 던져지면 롤백
    }
}

transfer 안에서 예외가 나면 출금도 입금도 모두 취소된다. 이 "선언만 하면 알아서 된다"를 가능하게 하는 게 다음에 볼 프록시다.

---

2. @Transactional은 어떻게 동작하는가 — AOP 프록시

@Transactional의 비밀은 스프링 AOP 프록시다. 스프링은 @Transactional이 붙은 빈을 그대로 쓰지 않고, 그 빈을 감싸는 프록시 객체를 만들어 대신 주입한다. 호출은 항상 이 프록시를 거친다.

프록시는 실제 메서드를 호출하기 전에 트랜잭션을 시작하고, 메서드가 정상 종료되면 커밋, 예외가 던져지면 롤백한다. 개발자가 작성한 비즈니스 코드에는 트랜잭션 관련 코드가 한 줄도 없지만, 프록시가 그 앞뒤를 감싸 처리하는 것이다.

이 "프록시를 거쳐야 한다"는 구조에서 두 가지 중요한 함정이 나온다.

함정 1 — 내부 호출(self-invocation)

같은 클래스 안에서 메서드를 직접 호출하면 프록시를 거치지 않는다. 따라서 그 메서드의 @Transactional은 무시된다.

@Service
public class OrderService {

    public void placeOrder(Order order) {
        // ❌ this.saveOrder() 호출 → 프록시를 안 거침 → @Transactional 무효
        saveOrder(order);
    }

    @Transactional
    public void saveOrder(Order order) {
        // 트랜잭션이 시작될 거라 기대하지만, 내부 호출이라 적용되지 않는다
    }
}

placeOrder에서 saveOrder를 호출하면 this.saveOrder()가 되어 프록시를 우회한다. 해결책은 트랜잭션이 필요한 메서드를 다른 빈으로 분리하거나, 진입 메서드인 placeOrder 쪽에 @Transactional을 붙이는 것이다. 자기 자신을 프록시로 주입받는 우회법도 있지만 권장되진 않는다.

함정 2 — public 메서드에만 적용

프록시 기반이므로 기본적으로 public 메서드에만 트랜잭션이 적용된다. private, protected 메서드에 @Transactional을 붙여도 동작하지 않는다(조용히 무시된다).

---

3. 트랜잭션 전파 (Propagation)

전파(Propagation)는 이미 트랜잭션이 진행 중일 때, 새 트랜잭션 메서드를 만나면 어떻게 할지를 정하는 규칙이다. 합류할지, 새로 만들지, 무시할지를 결정한다. 스프링은 7가지 옵션을 제공한다.

전파 옵션	진행 중인 트랜잭션이 있으면	없으면
REQUIRED (기본)	그 트랜잭션에 합류	새로 시작
REQUIRES_NEW	기존 것을 잠시 보류하고 새로 시작	새로 시작
NESTED	중첩 트랜잭션(savepoint) 생성	새로 시작
SUPPORTS	합류	트랜잭션 없이 실행
NOT_SUPPORTED	보류하고 트랜잭션 없이 실행	트랜잭션 없이 실행
MANDATORY	합류	예외 발생
NEVER	예외 발생	트랜잭션 없이 실행

실무에서 거의 대부분은 기본값인 REQUIRED를 쓴다. 그리고 가끔 REQUIRES_NEW가 필요하다. 이 둘의 차이가 핵심이다.

REQUIRED는 호출 체인 전체를 하나의 트랜잭션으로 묶는다. 그래서 중간 어디서든 예외가 나면 전체가 함께 롤백된다.

REQUIRES_NEW는 기존 트랜잭션을 잠시 보류시키고 완전히 독립된 새 트랜잭션을 시작한다. 안쪽 트랜잭션은 바깥과 무관하게 따로 커밋·롤백된다. 대표적인 사용 예가 "본 작업은 실패하더라도 로그·이력은 반드시 남겨야 하는" 경우다.

@Service
@RequiredArgsConstructor
public class OrderService {

    private final OrderRepository orderRepository;
    private final OrderLogService orderLogService;

    @Transactional // REQUIRED
    public void placeOrder(Order order) {
        orderLogService.writeLog("주문 시도: " + order.getId()); // 독립 트랜잭션
        orderRepository.save(order);
        validateStock(order); // 여기서 예외가 나면 주문은 롤백
    }
}

@Service
@RequiredArgsConstructor
public class OrderLogService {

    private final OrderLogRepository orderLogRepository;

    // 바깥 트랜잭션이 롤백돼도 이 로그는 살아남는다
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void writeLog(String message) {
        orderLogRepository.save(new OrderLog(message));
    }
}

위 코드에서 validateStock이 실패해 placeOrder가 롤백돼도, REQUIRES_NEW로 분리된 로그는 별도 트랜잭션에서 이미 커밋되어 남는다. 단, REQUIRES_NEW는 물리적으로 별도 커넥션을 잡으므로 남용하면 커넥션 풀이 빠르게 고갈된다. 꼭 필요한 곳에만 쓴다.

NESTED는 부모 트랜잭션 안에 세이브포인트(savepoint)를 만든다. 자식이 롤백되면 세이브포인트까지만 되돌리고 부모는 계속 진행할 수 있다. 단, JPA/Hibernate 조합에서는 지원이 제한적이라 실무 사용 빈도는 낮다.

---

4. 격리 수준 (Isolation Level)

격리 수준은 동시에 실행되는 트랜잭션들이 서로의 작업을 얼마나 볼 수 있는지를 정한다. 격리를 느슨하게 하면 성능(동시성)은 좋아지지만 이상 현상이 생기고, 강하게 하면 안전하지만 동시성이 떨어진다. 전형적인 트레이드오프다.

격리가 약할 때 생기는 대표적 이상 현상 세 가지부터 보자.

• Dirty Read — 다른 트랜잭션이 아직 커밋하지 않은 변경을 읽는다. 그 트랜잭션이 롤백되면 존재하지 않는 데이터를 읽은 셈이 된다.
• Non-Repeatable Read — 한 트랜잭션 안에서 같은 행을 두 번 읽었는데, 그 사이 다른 트랜잭션이 수정·커밋해서 값이 달라진다.
• Phantom Read — 같은 조건으로 두 번 조회했는데, 그 사이 다른 트랜잭션이 행을 추가·삭제해서 결과 집합의 행 수가 달라진다.

이 세 현상을 어디까지 막느냐로 표준 SQL은 4단계 격리 수준을 정의한다.

표에서 보듯 아래로 갈수록 더 많은 이상 현상을 막지만, 그만큼 락이 강해져 동시성은 떨어진다. 스프링에서는 다음처럼 지정한다.

@Transactional(isolation = Isolation.REPEATABLE_READ)
public Report buildReport(Long accountId) {
    // 리포트를 만드는 동안 조회 결과가 중간에 바뀌지 않도록 보장
    ...
}

다만 기억할 점이 있다. Isolation.DEFAULT(기본값)는 DB의 기본 격리 수준을 그대로 따른다. 그리고 DB마다 기본값이 다르다. MySQL(InnoDB)은 REPEATABLE READ, PostgreSQL과 Oracle은 READ COMMITTED가 기본이다. 따라서 애플리케이션에서 명시하지 않으면 DB에 따라 동작이 달라질 수 있다. 대부분의 웹 서비스는 READ COMMITTED로 충분하며, 격리 수준을 높이기 전에 정말 필요한지 따져봐야 한다.

---

5. 롤백 규칙 — 가장 흔한 함정

여기서 많은 사람이 한 번씩 데인다. 스프링의 기본 롤백 규칙은 이렇다.

언체크 예외(RuntimeException)와 Error는 롤백한다. 체크 예외(checked exception)는 롤백하지 않는다.

즉, IOException이나 직접 만든 체크 예외를 던지면 트랜잭션이 커밋된다. 의도와 정반대인 경우가 많다.

@Transactional
public void process() throws Exception {
    repository.save(entity);
    throw new Exception("체크 예외!"); // ❌ 롤백 안 됨 → entity가 커밋된다
}

체크 예외에도 롤백을 적용하려면 rollbackFor로 명시해야 한다.

@Transactional(rollbackFor = Exception.class)
public void process() throws Exception {
    repository.save(entity);
    throw new IOException("이제는 롤백된다"); // ✅ rollbackFor 덕분에 롤백
}

반대로 특정 예외는 롤백에서 제외하고 싶다면 noRollbackFor를 쓴다. 실무에서는 "비즈니스 예외는 전부 롤백"을 원하는 경우가 많아 rollbackFor = Exception.class를 자주 본다.

또 하나 자주 하는 실수는 예외를 try-catch로 삼키는 것이다.

@Transactional
public void process() {
    try {
        repository.save(entity);
        riskyOperation(); // 여기서 RuntimeException 발생
    } catch (Exception e) {
        log.error("에러 발생", e); // ❌ 예외를 잡아서 끝냄 → 프록시가 모름 → 커밋된다
    }
}

프록시는 메서드 밖으로 예외가 던져져야 롤백한다. 안에서 잡아버리면 프록시 입장에선 정상 종료로 보여 커밋한다. 잡아서 처리하되 롤백이 필요하다면, 예외를 다시 던지거나 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()로 명시적으로 롤백을 표시해야 한다.

---

6. readOnly와 실수 체크리스트

조회 전용 메서드에는 readOnly = true를 붙이는 게 좋다.

@Transactional(readOnly = true)
public List<Member> findMembers() {
    return memberRepository.findAll();
}

readOnly = true는 JPA에서 더티 체킹(변경 감지)을 위한 스냅샷을 만들지 않아 메모리·성능 이점이 있고, 일부 DB·드라이버에서는 읽기 전용 최적화 힌트로도 작동한다. 또한 "이 메서드는 쓰기를 하지 않는다"는 의도를 코드로 드러내는 문서 역할도 한다.

마지막으로 실무에서 반복적으로 나오는 실수를 정리하면 이렇다.

• 내부 호출(self-invocation) — 같은 클래스 메서드 호출은 프록시를 안 거쳐 @Transactional이 무시된다. 빈을 분리하라.
• private 메서드에 적용 — public 메서드에만 적용된다.
• 예외를 try-catch로 삼킴 — 예외가 밖으로 던져지지 않으면 롤백되지 않는다.
• 체크 예외 롤백 기대 — 기본은 언체크 예외만 롤백. 필요하면 rollbackFor.
• 트랜잭션 범위를 너무 넓게 — 외부 API 호출이나 긴 작업을 트랜잭션 안에 넣으면 커넥션을 오래 점유해 풀이 고갈된다. 트랜잭션은 DB 작업 구간만 짧게 감싸라.
• REQUIRES_NEW 남용 — 별도 커넥션을 잡으므로 커넥션 풀 고갈 위험. 꼭 필요한 곳에만.

---

마치며

@Transactional은 한 줄로 강력한 일을 해주지만, 그 한 줄 뒤에는 프록시라는 동작 원리가 숨어 있다. 이 원리만 이해하면 self-invocation, 롤백 누락, 예외 삼킴 같은 함정이 왜 생기는지 자연스럽게 설명된다.

정리하면 이렇다. 전파(Propagation)는 트랜잭션끼리 어떻게 묶을지를, 격리 수준(Isolation)은 동시 트랜잭션이 서로를 얼마나 볼지를 정한다. 그리고 롤백은 기본적으로 언체크 예외에만 동작하며, 예외가 프록시 밖으로 던져져야 한다는 전제가 깔려 있다.

대부분의 경우 기본값(REQUIRED + DB 기본 격리 수준)으로 충분하다. 중요한 건 "기본값이 무엇이고 언제 벗어나야 하는지"를 아는 것이다. 트랜잭션은 잘 돌아갈 땐 보이지 않다가, 어긋나는 순간 데이터 정합성을 무너뜨린다. 원리를 알아야 그 순간을 막을 수 있다.

---

참고 출처

• Spring Framework Docs — Transaction Management — https://docs.spring.io/spring-framework/reference/data-access/transaction.html
• Spring Framework Docs — Declarative transaction (@Transactional) — https://docs.spring.io/spring-framework/reference/data-access/transaction/declarative.html
• PostgreSQL Docs — Transaction Isolation — https://www.postgresql.org/docs/current/transaction-iso.html
• MySQL Docs — InnoDB Transaction Isolation Levels — https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html