트랜잭션 롤백 시 결제 취소 요청하기 - @TransactionalEventListener & ApplicationEventPublisher 모킹 이슈

결제 프로세스를 설계하면서, 기존에는 try-catch를 활용해 트랜잭션 내부에서 발생하는 런타임 예외를 처리하고, 결제 취소 요청을 보냈습니다. 그러나, 이에 대한 한계를 느꼈고 트랜잭션 롤백 시 결제 취소 요청을 명확하고 직관적으로 처리하기 위해 @TransactionalEventListener를 도입했습니다. 

 

기존 try-catch 방식의 한계

try-catch에서는 주로 DB 예외(예: DataIntegrityViolationException)나 비즈니스 로직에서 발생하는 예외를 처리하고, 결제 취소 요청을 보냈습니다. 하지만, try-catch를 사용하면 예외를 정상적인 흐름으로 제어하는 것처럼 보이게 됩니다. 이는 "트랜잭션이 롤백되었을 때 결제 취소를 수행한다"라는 의미를 정확히 표현하지 못한다고 생각했습니다.

결과적으로 try-catch 안에서 RuntimeException을 잡아 결제 취소를 요청하는 것은 "예외를 핸들링한다"는 의미일 뿐, 트랜잭션의 롤백 상태를 기준으로 결제 취소 요청을 보낸다는 의도를 명확히 전달하지 못한다고 판단했습니다.

 

@TransactionalEventListener 도입

이 문제를 해결하기 위해 스프링 4.2부터 지원하는 @TransactionalEventListener를 도입했습니다. 이 어노테이션은 트랜잭션의 상태에 따라 이벤트 리스너를 실행할 수 있도록 도와줍니다. 이를 통해 트랜잭션이 롤백되었을 때만 결제 취소 요청을 보낼 수 있도록 구현할 수 있었습니다.

 

Spring-Events 소개

@TransactionalEventListener를 소개하기 앞서 Baeldung-spring-events를 참고하여 스프링 이벤트를 설명합니다.

• Spring Framework 4.2 이전 버전을 사용하는 경우 이벤트 클래스는 ApplicationEvent를 확장해야 합니다. 4.2 버전부터 이벤트 클래스는 더 이상  ApplicationEvent  클래스를 확장할 필요가 없습니다.
• 이벤트 발행: ApplicationEventPublisher 객체를 DI하고, publishEvent() 메서드를 호출
• 이벤트 리스너: ApplicationListener 인터페이스를 구현하지 않고, @EventListener를 통해 간단히 메서드 등록
• 이벤트 리스너는 이벤트 발행자와 동일 쓰레드이며, 동기적으로 호출됩니다. 

@TransactionalEventListener 소개

@TransactionalEventListener 는 트랜잭션 단계(TransactionPhase) 에 따라 호출되는 이벤트 리스너를 정의하기 위한 어노테이션입니다.

 

1. 트랜잭션 단계별 동작

• AFTER_COMMIT (기본값): 트랜잭션이 성공적으로 완료된 경우 이벤트를 발생시키는 데 사용
• AFTER_ROLLBACK: 트랜잭션이 롤백 된 후 실행
• AFTER_COMPLETION: 트랜잭션이 완료된 후 실행( AFTER_COMMIT 와 AFTER_ROLLBACK 포함 )
• BEFORE_COMMIT: 트랜잭션이 커밋되기 직전에 이벤트를 발생시키는 데 사용

 

2. fallbackExecution=false 를 통해 트랜잭션이 없는 경우 리스너는 실행되지 않습니다.

/**
 * Whether the event should be handled if no transaction is running.
 */
boolean fallbackExecution() default false;

 

3. Javadoc에 따르면 @TransactionalEventListener 에서 변경된 발생 사항은 트랜잭션에 커밋되지 않습니다.

** @TransactionalEventListener Javadoc **
WARNING: if the TransactionPhase is set to AFTER_COMMIT (the default), AFTER_ROLLBACK, or AFTER_COMPLETION, the transaction will have been committed or rolled back already, but the transactional resources might still be active and accessible. As a consequence, any data access code triggered at this point will still "participate" in the original transaction, but changes will not be committed to the transactional resource. See TransactionSynchronization.afterCompletion(int) for details.

• 해석
  트랜잭션이 커밋되거나 롤백된 후에 실행되는 작업에서, 트랜잭션 리소스는 아직 활성 상태일 수 있습니다. 즉, 트랜잭션의 물리적 연결(데이터베이스 커넥션 등)이 완전히 닫히지 않았다는 뜻입니다. 이 시점에서 DB 쓰기 작업(INSERT, UPDATE 등)을 시도하면, 트랜잭션에 "참여"할 수는 있지만, 트랜잭션이 이미 종료되었기 때문에 실제 변경 사항은 커밋되지 않음. 트랜잭션이 끝났더라도 리소스가 아직 완전히 해제되지 않았으므로, DB 쓰기 작업 시 예상치 못한 동작이 발생할 수 있음.

그래서, @TransactionalEventListener 에서 DB 쓰기 작업을 할 경우, 트랜잭션 전파 속성을 REQUIRES_NEW 를 사용하여 새로운 트랜잭션을 열어줘야 합니다.

 

4. TransactionPhase.AFTER_COMMIT 단계의 예외는 DEBUG모드

추가로, 렌딧 개발팀에서 쓴 글인 예외 먹는 @TransactionalEventListener에서 'TransactionPhase.AFTER_COMMIT 단계의 예외는 DEBUG 모드로 발생' 한다고 합니다. 함께 읽으면 좋을 것 같아 추가로 남깁니다.

 

구현 단계

* 간단하게 설명하기 위해 코드를 간소화했습니다.

 

1. 이벤트 발행자: 결제 서비스

이벤트를 발행하는 코드는 트랜잭션 롤백이 발생해도 이벤트가 정상적으로 발행될 수 있도록 구성해야 합니다. 그래서, 이벤트 발행이 DB 작업보다 먼저 실행되어야 한다는 것입니다.

@Slf4j
@RequiredArgsConstructor
@Service
@Transactional(readOnly = true)
public class PaymentService {

    ...
    private final ApplicationEventPublisher eventPublisher;

    @Transactional
    public PaymentReservationResponse confirmReservation(
            TossPaymentConfirm tossPaymentConfirm, PaymentConfirmServiceRequest request) {
        
        // 이벤트 발행
        eventPublisher.publishEvent(new PaymentEvent(request.paymentKey()));

        // 결제 승인 데이터 INSERT
        // 예약 확정 데이터 INSERT

        return PaymentReservationResponse.of(paymentConfirmResponse, reservationResponse);
    }
}

 

2. 이벤트 리스너: 결제 취소 요청

이벤트 리스너는 트랜잭션 롤백 시에만 동작하도록 AFTER_ROLLBACK을 설정합니다.

이벤트 리스너를 Bean 으로 등록해주기 위해 @Component 어노테이션을 추가합니다.

@Slf4j
@Component
@RequiredArgsConstructor
public class PaymentEventListener {

    private final TossClient tossClient;

    @TransactionalEventListener(phase = TransactionPhase.AFTER_ROLLBACK)
    public void handleRollback(PaymentEvent paymentEvent) {
        log.info("이벤트 리스너 시작");
        tossClient.cancelPayment(paymentEvent.getPaymentKey());
    }
}

 

3. 이벤트 클래스

PaymentEvent는 간단한 POJO 객체로 구현했습니다. 요구사항에 따라 엔티티로 확장 가능합니다.

@Getter
public class PaymentEvent {

    private final String paymentKey;

    public PaymentEvent(String paymentKey) {
        this.paymentKey = paymentKey;
    }
}

 

이벤트 기반의 장점과 단점

이벤트 기반 설계를 활용하면 서비스 간 강한 의존성을 줄일 수 있을 것입니다. (현재 예시에서는 잘 나와있지 않지만..)
예를 들어, 결제 승인 시 고객에게 알림을 보내거나 배송사에 배송 시작 요청을 해야 한다고 가정해봅니다. 기존 방식에서는 결제 서비스에서 직접 알림 서비스를 호출하거나 배송 관련 코드를 포함해야 했습니다. 그러나 이벤트 리스너를 활용하면 알림 서비스나 배송 서비스의 코드가 결제 서비스로부터 분리되고, 서비스들간의 결합도를 낮출 수 있습니다.

 

다만, 단점은 Ctrl B 로 코드를 따라가기가 어려워 코드 흐름을 추적하기가 어려워 이벤트를 어떤 리스너가 처리하는지 직접 확인해야 하는 불편함이 있었습니다.

 

이벤트 발행 테스트: ApplicationEventPublisher 모킹 이슈와 해결 방법

이벤트가 제대로 발행되었는지 테스트하는 방법을 고민해보았습니다. 처음에는 ApplicationEventPublisher를 @MockBean으로 처리하여 publishEvent() 메서드의 호출 횟수를 검증하려 했지만 모킹이 되지 않는 문제가 발생했습니다.

 

에러 메시지는 다음과 같습니다.

-> at org.springframework.context.ApplicationEventPublisher.publishEvent(ApplicationEventPublisher.java:65)
Actually, there were zero interactions with this mock.

그리고, 이와 관련해서 Spring GitHub Issue가 존재하며 ApplicationEventPublisher 는 모킹이 될 수 없다고 합니다.

이러한 이유는 스프링의 한계로 ApplicationEventPublisher는 regular bean 이기 때문이라고 Issue 에서는 설명합니다.

 

이를 풀어 설명하자면 ApplicationEventPublisher는 스프링 컨텍스트의 여러 이벤트 기반 컴포넌트(ex. @EventListener로 구현된 리스너)에서 사용되며, 모킹하면 다른 이벤트 기반의 컴포넌트에 예상치 못한 문제가 발생하기 때문에 @MockBean 처리가 안되지 않을까 생각해봅니다.

Spring Context의 기본 Bean들

 

해결 방법: @RecordApplicationEvents와 ApplicationEvents 활용

@RecordApplicationEvents를 사용하면 ApplicationContext에서 발생한 모든 애플리케이션 이벤트를 기록하고, 이를 테스트 내에서 검증할 수 있습니다.

* 참고: Make it possible to mock ApplicationEventPublisher in Spring Boot tests

 

@RecordApplicationEvents란?

• @RecordApplicationEvents는 테스트 클래스에 적용할 수 있는 어노테이션으로, Spring TestContext Framework에 테스트 실행 중 발생한 모든 애플리케이션 이벤트를 기록하도록 지시합니다.
• 기록된 이벤트는 ApplicationEvents API를 통해 확인할 수 있습니다

* 참고: @RecordApplicationEvents Spring Docs 

 

테스트 클래스에 @RecordApplicationEvents 어노테이션을 추가하고, ApplicationEvents 를 주입합니다.

그리고, events.stream(T.class).count() 를 통해 이벤트 발행 수를 검증합니다.

 

다음은 전체 테스트 코드입니다.

@RecordApplicationEvents
class PaymentServiceTest extends IntegrationTestSupport { // IntegrationTestSupport 는 전체 테스트 시 1대의 스프링만 띄우기 위한 추상 클래스로 @SpringBootTest 어노테이션이 존재

    @Autowired
    private PaymentService paymentService;

    @MockBean
    private ReservationServiceV2 reservationServiceV2;

    @Autowired
    private ReservationRepository reservationRepository;

    @Autowired
    private PaymentTemporaryRepository paymentTemporaryRepository;

    @Autowired
    private TossPaymentConfirmRepository tossPaymentConfirmRepository;

    @Autowired
    private ApplicationEvents events;

    @AfterEach
    void tearDown() {
        ...
    }
    
    @DisplayName("결제 및 예약을 확정지을 때, 논리 트랜잭션이 롤백되면 물리 트랜잭션이 롤백되며 이벤트가 발행된다")
    @Test
    void confirmReservationWithException() {
        // given
        TossPaymentConfirm tossPaymentConfirm = TossPaymentConfirm.builder()
                .paymentKey("결제 고유 키")
                .orderId("주문 번호")
                .orderName("주문 이름")
                .mId("상점 아이디")
                .taxExemptionAmount(50000)
                .status(TossPaymentStatus.READY)
                .requestedAt("결제 시간")
                .build();

        PaymentConfirmServiceRequest request = new PaymentConfirmServiceRequest(
                1L,
                1L,
                1L, "paymentKey", "amount", "orderId"
        );

        given(reservationServiceV2.confirmReservation(anyLong(), anyLong()))
                .willThrow(new RuntimeException());

        // when
        assertThatThrownBy(() -> paymentService.confirmReservation(tossPaymentConfirm, request))
                .isInstanceOf(RuntimeException.class);

        // then
        assertThat(tossPaymentConfirmRepository.findAll()).hasSize(0);
        assertThat(reservationRepository.findAll()).hasSize(0);

        long count = events.stream(PaymentEvent.class).count();
        assertThat(count).isEqualTo(1);
    }
}

 

이를 통해, 서비스 트랜잭션이 롤백됐을 때 이벤트가 발행되었는지 간접적으로 검증할 수 있었습니다.

다만 여러 이벤트가 있을 경우, count() 로만 검증하기에는 무리가 있다고 판단이 되는데요. 이 부분은 앞으로 학습이 필요한 부분이라 생각합니다.

 

이상으로 트랜잭션 롤백 시 결제 취소 요청하기 - @TransactionalEventListener &  ApplicationEventPublisher 모킹 이슈를 마치겠습니다.