@Transactional을 사용하는 이유

@Transactional의 기본 개념

정의

@Transactional은 스프링 프레임워크에서 제공하는 어노테이션으로, 해당 메소드나 클래스에서 실행되는 DB 작업(INSERT, UPDATE, DELETE 등)을 하나의 트랜잭션 범위 안에서 처리하도록 하는 역할을 한다.

기능

모든 DB 연산을 하나의 원자적 단위로 묶어 성공 시 일괄 커밋, 실패 시 일괄 롤백을 통해 데이터 무결성과 일관성을 보장한다.

---

@Transactional을 사용하는 이유

1. 원자성(Atomicity) 보장

메소드 실행 중 하나의 작업이라도 실패하면, 해당 메소드 내 모든 변경 사항을 롤백한다. 예를 들어 INSERT 후 UPDATE에서 예외 발생 시, INSERT 또한 취소되어 DB 상태가 이전으로 복원된다.

2. 일관성(Consistency) 보장

하나의 트랜잭션 안에서 데이터 변경이 이루어지므로, DB 상태의 일관성이 유지된다.

3. 격리성(Isolation) 확보

트랜잭션 설정에 따라 다른 트랜잭션과의 격리 수준을 조정하여 동시성 문제를 줄일 수 있다.

4. 명확한 트랜잭션 경계

서비스 계층에서 @Transactional을 활용하면 비즈니스 로직 단위로 트랜잭션 경계를 명확히 설정할 수 있어 유지보수가 편리하다.

---

언제 @Transactional을 붙여야 할까?

1. 데이터 변경 로직 (INSERT, UPDATE, DELETE)

여러 DB 변경 작업을 하나의 단위로 묶고 싶을 때 @Transactional을 적용해 원자성을 보장하는 것이 일반적이다.

2. 조회 전용 로직 (SELECT)

단순 조회에서는 필수적이지 않으나, 지연 로딩(Lazy Loading)을 활용하거나 @Transactional(readOnly = true)를 통해 더티 체킹을 생략하는 등의 최적화를 할 수 있다.

3. 서비스 레이어

DAO(Repository) 호출과 비즈니스 로직을 결합하는 서비스 계층에서 트랜잭션을 관리하는 것이 일반적인 패턴이다.

---

@Transactional을 무조건 붙여야 할까?

• "무조건"은 아니다. 불필요하게 모든 메소드에 붙이면 오히려 오버헤드가 발생할 수 있다.
• 비즈니스 로직 상 "이 로직은 하나의 트랜잭션으로 처리해야 한다"는 명확한 기준이 있을 때만 사용한다.
• 단순한 insert 한 번만 수행하는 메소드라도, 향후 확장 가능성이나 명확한 트랜잭션 경계 설정을 위해 붙일 수도 있고, 상위 계층에서 이미 트랜잭션을 관리한다면 생략할 수도 있다.

---

트랜잭션이 없으면 어떤 일이 발생할까?

• 에러나 예외 발생 시 이미 실행된 DB 변경(예: INSERT)은 되돌릴 수 없다. 부분만 DB에 반영되어 데이터 무결성을 잃을 수 있다.
• LazyInitializationException, TransactionRequiredException 등 트랜잭션이 없을 경우 발생하는 예외로 인해 정상적인 엔티티 관리가 어려울 수 있다.

---

@Transactional(readOnly = true)

• 읽기 전용 모드로 설정하면 Hibernate와 같은 ORM이 더티 체킹을 수행하지 않거나 최소화하여 성능 최적화를 제공할 수 있다.
• DB 변경이 없다는 보장이 있을 경우, Flush나 Lock 획득 과정을 생략하여 자원 사용을 줄일 수 있다.

---

정리

• @Transactional은 스프링 애플리케이션에서 트랜잭션 경계를 명확히 설정하고, DB 변경 시의 안정성과 원자성을 확보하는 핵심 도구이다.
• 상황에 따라 readOnly 속성 활용, 적절한 계층(주로 Service 레벨)에서의 설정, 필요할 때만 사용하는 전략을 통해 효율적인 데이터 접근을 구현할 수 있다.
• 커넥션 관리 및 최적화(커넥션 풀, readOnly 트랜잭션)와 결합하여 애플리케이션의 성능과 안정성을 한 단계 높일 수 있다.