📚[Spring] 보상 트랜잭션

이벤트 기반 아키텍처에서의 무결성 보완 - 보상 트랜잭션

사용자 저장 시 사용자의 정보와 일치하는 데이터를 가진 조회용 프로필 데이터도 함께 저장한다고 가정하자.
이 두 데이터는 각각 다른 테이블에 존재하지만 같은 정보를 공유하므로 데이터 무결성을 보장받아야 한다.

---

모놀리식 아키텍처에서의 원자성 보장

일반적인 모놀리식 아키텍처(monolithic architecture) 에서는 다음과 같이 두 개의 레포지터리를 서비스에 주입하고
단일 트랜잭션 내에서 처리함으로써 원자성을 통해 데이터 무결성을 보장할 수 있다.

@Transactional
public CreateUserResponse createUserAndProfile(CreateRequest request){
	String encodedPassword = passwordEncoder.encode(request.getPassword());
	User user = new User(request.getEmail(), request.getName(), encodedPassword);
	Profile profile = new Profile(request.getEmail, request.getName());
	
	userRepository.save(user);
	profileRepository.save(profile);
    ...       
}

위의 createUserAndProfile() 메서드는 @Transactional 어노테이션으로 트랜잭션이 묶여 있기 때문에 중간에 예외가 발생할 경우 전체 트랜잭션이 롤백되어 데이터의 원자성과 무결성을 보장할 수 있다.

---

이벤트 기반 처리 시 데이터 무결성 문제

하지만 두 데이터가 서로 다른 트랜잭션에서 처리될 경우 데이터의 원자성을 보장받을 수 없다.
도메인 간 의존도를 낮추기 위해 사용자 저장 이후 이벤트를 발행하여 프로필 데이터를 처리하는 방식을 사용한다고 가정해보자.

@Transactional
public CreateUserResponse signup(SignupRequest request) {
	String encodedPassword = passwordEncoder.encode(request.getPassword());
	User user = new User(request.getEmail(), request.getName(), encodedPassword);
	User savedUser = userRepository.save(user);

	//회원가입 이벤트 발행
	eventPublisher.publishEvent(
		UserRegisteredEvent.of(savedUser.getUserId(), savedUser.getEmail(),
			savedUser.getName())
	);
	
    ...
}

@Transactional(propagation = Propagation.REQUIRES_NEW)
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void handlerUserRegisteredEvent(UserRegisteredEvent event) {
    Profile profile = Profile.fromUserEvent(
		event.getUserId(), 
        event.getEmail(), 
        event.getName()
    );	
    profileRepository.save(profile);
}

위 코드에서 @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) 어노테이션은 해당 이벤트가 발행된 트랜잭션이 정상적으로 커밋된 이후에 이벤트 로직이 실행되도록 보장한다.

따라서 사용자 저장(User)은 커밋이 완료된 상태이므로 이벤트 리스너에서 사용자 정보를 기반으로 프로필 저장이 시작된다.
하지만 이 후속 작업 중에 예상치 못한 예외가 발생할 수 있다.

• 이벤트 처리 중 네트워크 오류 발생
• profileRepository.save(profile) 수행 중 DB 제약조건 위반
  이런 경우 프로필 저장은 실패하고 이미 커밋된 사용자 정보는 되돌릴 수 없다.
  결과적으로 User는 저장되었지만 Profile은 존재하지 않는 비정상적인 상태가 발생하게 되고 이는 시스템 데이터의 무결성을 해칠 수 있다.

---

BEFORE_COMMIT과 AFTER_COMMIT의 차이와 선택 이유

사실 해당 구조에서는 @TransactionalEventListener(phase = TransactionPhase.BEFORE_COMMIT) 으로 설정하면 이벤트 리스너가 트랜잭션 커밋 전에 실행되기 때문에 이벤트 처리 로직도 동일한 트랜잭션 안에서 처리할 수 있어 이론적으로는 데이터 원자성 보장이 가능해진다.

하지만 실무에서는 이 방식보다 AFTER_COMMIT 이 선호되는데 그 이유는 크게 두 가지 이유가 있다.

1. 트랜잭션 상태에 따라 이벤트가 무시되거나 실패할 수 있음
   • BEFORE_COMMIT은 메인 트랜잭션 도중 예외가 발생하면 실행되지 않거나 이벤트 처리 중 예외가 트랜잭션 전체에 영향을 줄 수 있다.
   • 이벤트 자체를 실패해도 메인 로직엔 영향이 없도록 설계됐다면 그 목적과 어긋난다.
2. 도메인 간 결합도를 높이는 결과가 됨
   • 도메인 이벤트는 본질적으로 후속 작업을 분리하여 느슨한 결합을 지향하는 개념이다.
   • BEFORE_COMMIT은 이벤트 리스너가 메인 트랜잭션에 얽히게 되므로 결과적으로 도메인 간 결합도가 생긴다.

무결성만 고려하면 BEFORE_COMMIT도 유효한 선택일 수 있지만 트랜잭션 경계 분리, 도메인 결합도 최소화, 실패 시 유연한 복구를 고려한다면 보상 트랜잭션이나 Outbox 패턴을 통한 접근이 더 적절한 선택일 수 있다.

---

보상 트랜잭션(Compensating Transaction)

보상 트랜잭션은 분산 시스템과 같은
원래 작업을 되돌릴 수 없는 환경 에서 실패한 작업에 대해 반대 방향의 동작을 실행해 상태를 복구하는 패턴이다.

예를 들어 사용자 저장 후 프로필 저장에 실패한 경우 사용자 등록을 취소하거나 무효화하는 등의 보상 작업을 수행하여 데이터 일관성을 맞춘다.

---

Outbox 패턴

Outbox 패턴은 이벤트 기반 시스템에서 이벤트 발행과 데이터 저장을 동일한 트랜잭션 안에서 처리하기 위한 패턴이다.

메인 트랜잭션 안에서 도메인 데이터와 함께 이벤트 레코드(Outbox 테이블) 를 함께 저장하고 스케줄러나 Kafka 등 별도의 프로세서가 Outbox 테이블을 모니터링하여 해당 이벤트를 메세지 큐(Message Queue)로 비동기 전송한다.
이를 통해 이벤트 유실을 방지하고 DB에 저장된 데이터만 이벤트로 발행되도록 보장해 데이터와 이벤트 간 정합성을 확보할 수 있다.

---

보상 트랜잭션을 활용한 이벤트 기반 무결성 보완

나는 위와 같은 무결성 문제를 해결하기 위해 보상 트랜잭션 방식을 도입하여 이벤트 리스너를 리팩토링하였다.

@Transactional(propagation = Propagation.REQUIRES_NEW)
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void handlerUserRegisteredEvent(UserRegisteredEvent event) {
	try {
        Profile profile = Profile.fromUserEvent(
            event.getUserId(), 
            event.getEmail(), 
            event.getName()
        );	
        profileRepository.save(profile);
	} catch (Exception e) {
		log.info("프로필 생성 실패: userId={}, error={}", event.getUserId(), e.getMessage());
		eventPublisher.publishEvent(UserSaveFailedEvent.of(event.getUserId()));
	}
}

이벤트 리스너는 try-catch를 통해 예상 가능한 예외를 방어하고 실패 시 UserSaveFailedEvent라는 보상 이벤트를
발행하여 후속조치가 이어질 수 있도록 유연하게 설계했다.

@EventListener
	public void handlerUserSaveFailedEvent(UserSaveFailedEvent event) {
		try {
			authRepository.deleteByAuthId(event.getAuthId());
		} catch (Exception e) {
			log.error("Auth 롤백 실패 : authId={}", event.getAuthId());
		}
	}

보상 이벤트 리스너에서는 사용자 등록을 취소하는 동작을 수행하여 Profile 저장 실패로 인해 불완전하게 남은 사용자 데이터(User)를 제거하여 데이터 일관성을 유지할 수 있도록 한다.
이벤트 처리 중 실패 상황을 감지하고 보상 트랜잭션을 발행함으로써 이벤트 기반 아키텍처의 장점은 유지하며 트랜잭션 분리로 인한 무결성 문제를 현실적인 방식으로 보완하는 것이다.

---

마치며

이벤트 기반 아키텍처에서 발생할 수 있는 데이터 무결성 문제와 그 해결책으로 보상 트랜잭션 패턴을 살펴봤다.
트랜잭션 경계가 분리된 환경에서도 안정적으로 데이터 일관성을 유지하기 위해선 실패를 감지하고 적절히 복구하는 설계가 반드시 필요하다고 생각된다.
다음에는 Outbox 패턴을 실제 적용해보고 보상 트랜잭션과 어떻게 조합할지 고민해보는 걸 목표로 하겠다.