[Backend] @Transactional

목차 (OPEN)

• 🔎 @Transactional 이란
• 🏃🏻‍♂️ 프록시 기반 동작 구조
• ⚠️ 고려해야 할 것들
• 1️⃣ 프록시 우회 호출 문제
• 2️⃣ 체크 예외 록백 여부
• 3️⃣ readOnly 옵션의 의미와 주의점
• 4️⃣ 트랜잭션의 크기 조절
• 5️⃣ 비동기 로직과 트랜잭션의 관계
• 📚 결론

 

 

 

 

 

 

🔎 @Transactional 이란

Spring Framework에서 @Transactional은 트랜잭션을 선언적으로 관리하기 위한 핵심 어노테이션이다.

개발자가 비즈니스 로직 메서드에 @Transactional을 명시함으로써,

해당 메서드 실행 전후에 트랜잭션의 시작과 종료를 자동으로 처리할 수 있도록 지원한다.

 

이는 PlatformTransactionalManager를 기반으로 하며,

내부적으로는 AOP (Aspect Oriented Programming)를 통해서 동작한다고 한다.

즉, @Transactional이 붙은 매서드는 Spring이 생성한 프록시 객체를 통해 호출되며,

프록시 내부에서 트랜잭션의 시작과 종료를 담당하게 되는 것이다.

 

---

🏃🏻‍♂️ 프록시 기반 동작 구조

좀 더 풀어서 설명하자면,

Spring에서는 @Transactional이라는 어노테이션을 통해 트랜잭션을 매우 간단하게 선언할 수 있도록 지원해준다.

이 어노테이션을 클래스 또는 메서드에 붙이기만 하면,

Spring이 내부적으로 해당 메서드에 대해 트랜잭션 처리 로직을 자동으로 적용해주기 때문이다.

 

그리고, 이러한 기능이 가능한 이유는 바로 프록시 (Proxy)라는 기술 덕분이다.

애플리케이션이 실행될 때, Spring은 @Transactional이 붙은 클래스나 메서드를 감싸는 프록시 객체를 생성한다.

이 프록시는 실제 원본 클래스의 동작을 대신 수행하는 대리 객체이며,

핵심적인 역할은 비즈니스 로직의 실행 시점을 가로채서, 트랜잭션을 시작하고 관리하는 것이다.

 

즉, 우리가 서비스를 호출하면,

실제로는 원본 클래스가 아닌, Spring이 만든 프록시 객체가 먼저 요청을 받게 된다.

 

그리고, 이 프록시는 요청을 받자마자 아래와 같은 순서로 동작한다.

 

1. 현재 이 메서드를 실행하는 데에 트랜잭션이 필요한지 확인한다.
   예를 들어, @Transactional이 붙어있고, 트랜잭션이 활성화되어 있지 않다면, 새 트랜잭션을 시작해야 할 것이다.
2. 트랜잭션이 필요하다고 판단되면, Spring은 내부적으로 PlatformTransactionManager를 통해 트랜잭션을 시작한다.
   구체적으로는 JDBC 커넥션의 자동 커밋을 끄고, 트랜잭션을 관리할 수 있는 상태로 진입하게 되는 것이다.
   이 시점부터는 데이터베이스와의 모든 변경 작업이 트랜잭션의 관리 하에 놓이게 된다.
3. 트랜잭션이 시작된 상태에서는 이제 실제 비즈니스 로직이 실행된다.
   예를 들어, DB에 값을 저장하거나 업데이트하는 등의 작업이 이루어지게 되는 것이다.
4. 비즈니스 로직이 정상적으로 완료되면, Spring은 트랜잭션을 커밋하여 모든 변경사항을 DB에 최종 반영한다.
   반대로, 로직 중간에 예외가 발생하면 Spring은 트랜잭션을 롤백해서 지금까지 수행된 변경사항을 모두 취소한다.

이처럼 개발자는 @Transactional을 메서드에 선언하기만 하면,

트랜잭션으 시작하거나 종료하는 코드를 전혀 작성하지 않아도,

Spring이 런타임에 생성한 프록시가 위와 같은 작업을 자동으로 처리해준다.

 

이 덕분에 비즈니스 로직 자체는 트랜잭션 제어 로직으로부터 분리되어 깔끔하고 직관적인 코드를 유지할 수 있는 것이다 ✨

 

---

⚠️ 고려해야 할 것들

Spring에서 @Transactional 어노테이션은 매우 강력한 기능이지만,

내부 동작 방식을 정확히 이해하지 못한 채 사용한 경우 예상치 못한 동작이나 버그로 이어질 수 있다.

특히, 실무 환경에서는 트랜잭션 처리의 정확성과 일관성이 시스템 전체의 안정성과 직결되기 때문에,

아래와 같은 항목들을 반드시 고려해야 한다고 한다.

 

1️⃣ 프록시 우회 호출 문제

@Transactional은 프록시 기반 AOP 방식으로 동작한다.
이 말은 곧, 트랜잭션 처리를 담당하는 로직이 실제 비즈니스 로직 메서드에 직접 존재하는 것이 아니라,
해당 메서드를 감싸고 있는 프록세 객체에서 트랜잭션을 관리한다는 의미이다.

이 구조에서 한 가지 흔히 발생하는 문제가 있는데,
바로 동일 클래스 내부에서의 자기 메서드 호출이다.

예를 들어, 클래스 A에 methodA()와 methodB()가 있고,
methodA()에는 @Transactional이 붙어 있으며,
methodB()는 methodA()를 내부에서 호출한다고 가정해보자.

이 경우, methodB()가 this.methodA()처럼 자기 자신을 직접 호출하는 방식으로 methodA()를 실행하면,
해당 호출은 프록시 객체를 거치지 않기 때문에 트랜잭션이 전혀 적용되지 않는다.

이는 스프링 AOP 구조의 근본적인 제약으로,
트랜잭션 로직은 프록시를 통해 우회 호출될 때에만 적용되기 때문이다.

따라서 이러한 상황을 피하기 위해서는,
트랜잭션 경계가 필요한 로직을 별도의 서비스 클래스로 분리하거나,
AopContext.currentProxy()를 활용해서 현재 프록시 객체를 통해 간접 호출해야 한다.

다만, 후자는 사용이 까다롭고 코드 가독성이 떨어지므로, 일반적으로는 클래스 분리를 권장한다고 한다.

 

---

2️⃣ 체크 예외 록백 여부

Spring의 기본 트랜잭션 처리 정책에서는,

RuntimeException과 Error 타입의 예외가 발생했을 때만 트랜잭션을 롤백하고,

Exception 처럼 체크 예외가 발생하는 경우에는 트랜잭션을 커밋하는 것이 기본 동작이라고 한다.

 

이러한 설계는 자바의 예외 처리 규칙을 따르기 위한 것으로,

체크 예외는 원칙적으로 복구 가능한 예외로 간주되기 때문에

Spring은 개발자가 의도적으로 커밋을 원하는 것으로 해석하기 때문이다.

그러나 실무에서는 체크 예외 역시 롤백되어야 하는 경우가 많다.

 

따라서,

예를 들어 파일 업로드나 외부 API 통신 등에서 IOException과 같은 체크 예외가 발생했을 때에도 DB 작업을 롤백하고 싶다면,

@Transactional 어노테이션에 다음과 같이 명시적으로 롤백 대상을 지정해주어야 한다.

@Transactional(rollbackFor = IOException.class)

 

또는, 보다 일반적인 방식으로는 rollbackFor = Exception.class와 같이 모든 체크 예외를 포함시킬 수도 있다고 한다.

 

이러한 것들을 명확히 하지 않으면,

예외가 발생했음에도 불구하고, DB에 잘못된 데이터가 커밋되는 심각한 문제가 발생할 수도 있으니 잘 신경써주어야겠다 🤯

 

---

3️⃣ readOnly 옵션의 의미와 주의점

@Transactional 어노테이션은 readOnly 속성을 지원한다.

따라서 이 속성을 아래와 같이 true로 설정하면 해당 트랜잭션은 읽기 전용으로 처리될 것이다.

@Transactional(readOnly = true)

 

이 설정은 JPA 또는 JDBC 드라이버에게

"이 트랜잭션에서는 데이터 변경이 발생하지 않아."라는 힌트를 제공해준다.

이로 인해 Hibernate는 dirty checking을 비활성화 하고 flush를 생략하는 등, 성능을 향상시킬 수 있는 여러 최적화를 적용한다.

 

하지만 주의할 점은, readOnly = true가 강제적인 쓰기 방지 기능은 아니라는 것이다.

즉, 트랜잭션 내부에서 실수로 엔티티를 수정하거나 삽입하는 경우,

Hibernate는 flush 시점에 해당 변경 내용을 반영하려고 시도하게 되며,

이로 인해서 flush 예외가 발생하거나 의도치 않은 쓰기 작업이 진행될 수 있다고 한다.

 

따라서 readOnly 트랜잭션에서는 정말로 읽기 전용 작업만 수행하도록 코드 구조를 명확히 분리하고,

쓰기 작업은 반드시 readOnly = false가 적용된 별도의 트랜잭션에서 수행하는 것이 바람직할 것이다.

 

---

4️⃣ 트랜잭션의 크기 조절

트랜잭션이 적용되는 코드 블록의 길이나 지속 시간 또한 중요한 고려 사항이라고 한다.

 

만약, 트랜잭션이 너무 짧은 경우에는,

빈번한 begin과 commit 또는 rollback이 발생해서 오히려 성능 오버헤드가 증가할 수 있기 때문에

단순한 조회나 짧은 작업에 트랜잭션을 불필요하게 많이 생성하는 것도 낭비인 것이다.

 

반대로, 트랜잭션이 너무 긴 경우에는,

커넥션이 장시간 점유되거나 데이터베이스의 락이 오랫동안 유지되어 동시성 문제나 deadlock 발생 확률이 높아진다고 한다.

 

따라서 트랜잭션은 DB에 반영되어야 하는 작업 단위를 기준으로 명확히 정의해야 하며,

불필요하게 넓은 범위를 가지지 않도록 항상 유의해야 한다고 한다.

 

일반적으로는 하나의 논리적 작업 단위가 트랜잭션의 경계가 되어야 함을 기억하자.

 

---

5️⃣ 비동기 로직과 트랜잭션의 관계

Spring에서는 @Async를 사용해서 메서드를 비동기적으로 실행할 수 있다.

그러나 이 방식은 별도의 쓰레드에서 메서드가 실행되기 때무에, 기존 트랜잭션 컨텍스트와는 완전히 분리된 상태에서 동작한다.

 

즉, @Transactional이 적용된 메서드 내부에서 @Async 메서드를 호출하면,

해당 비동기 메서드는 트랜잭션이 아직 커밋되기 전에 실행될 수 있으며,

동일한 트랜잭션 컨텍스트를 공유하지 않기 때문에 DB 일관성 문제가 발생할 수 있는 것이다.

 

따라서 이러한 상황에서는 트랜잭션이 성공적으로 커밋된 이후에만 비동기 로직이 실행되도록 설계하는 것이 바람직하다.

 

Spring에서는 이를 위해 @TransactionalEventListener(phase = AFTER_COMMIT)을 제공한다.

이 어노테이션을 사용하면, 지정된 이벤트 리스너는 트랜잭션 커밋 직후에 실행되므로,

DB에 반영이 확정된 이후의 안전한 시점에서 알림 발송이나 메시지 큐 발행 등의 처리를 수행할 수 있는 것이다.

 

---

📚 결론

위에서 살펴본 내용을 종합하면,

@Transactional은 선언적인 트랜잭션 처리를 가능하게 해주는 매우 편리한 도구이지만,

프록시 기반의 동작 특성과 트랜잭션 전파 및 예외 처리 정책을 정확히 이해하지 않으면

실무에서 예기치 않은 동작을 유발할 수 있을 것 같다.

 

오늘 정리한 내용들을 체계적으로 이해하고 적용해서,

@Transactional을 안정적이고 효과적으로 사용함으로써

여러 DB 연산이 얽힌 복잡한 비즈니스 로직에서도 데이터 정합성과 예외 처리 완성도를 높일 수 있도록 해야겠다.