[스프링] 3. 실패 허용 설계와 보상 전략

1편에서 이벤트로 코드 구조를 분리했고, 2편에서 @TransactionalEventListener로 트랜잭션 경계를 정리했다. 그런데 아직 해결하지 않은 질문이 있다. "커밋이 끝난 뒤 리스너에서 실패하면 어떻게 되는가?" 이벤트 기반 설계의 핵심은 분리 자체가 아니라 실패를 어떻게 다루느냐에 있다. 이 질문에 답하려면 비동기 이벤트, 실패 허용 설계, 보상 전략까지 이해해야 한다.

@Async와 비동기 이벤트

2편에서 @TransactionalEventListener(AFTER_COMMIT)을 사용하면 커밋이 확정된 뒤에 리스너가 실행된다는 것을 확인했다. 하지만 이 리스너는 여전히 발행자와 같은 스레드에서 동기적으로 실행된다. 알림 발송에 3초가 걸리면, API 응답도 3초 늦어진다.

@Async를 추가하면 리스너가 별도 스레드에서 실행된다. 발행자는 리스너의 완료를 기다리지 않고 즉시 응답할 수 있다.

@Async
@TransactionalEventListener(phase = AFTER_COMMIT)
public void sendNotification(ClothesCreatedEvent event) {
    notificationService.notifyFollowers(event.getClothesId());
}

이 조합이 어떤 실행 흐름을 만드는지 보자.

초록 영역에서 클라이언트는 이미 응답을 받았다. 파란 영역의 알림 발송은 별도 스레드에서 독립적으로 진행된다. 알림이 3초 걸려도 API 응답 시간에는 영향이 없다.

@Async + AFTER_COMMIT이 표준 패턴인 이유

외부 부수효과(알림, 이메일, 외부 API 호출)에는 이 조합이 사실상 표준이다. 세 가지 조건을 동시에 충족하기 때문이다.

• 트랜잭션 안전성 : 커밋이 확정된 뒤에 실행되므로, 롤백된 데이터에 대한 부수효과가 발생하지 않는다
• 장애 격리 : 별도 스레드이므로, 리스너 예외가 발행자에게 전파되지 않는다
• 응답 속도 : 발행자는 리스너의 완료를 기다리지 않으므로, API 응답이 빠르다

@Async의 활성화

@Async는 선언만으로 동작하지 않는다. 스프링 설정에서 @EnableAsync를 추가해야 한다.

@EnableAsync
@Configuration
public class AsyncConfig {
}

이 설정이 없으면 @Async가 무시되고 동기로 실행된다. 에러가 나지 않아서 놓치기 쉽다.

스레드 풀 설정

@Async를 활성화하면 Spring은 기본적으로 SimpleAsyncTaskExecutor를 사용한다. 이 실행기는 요청마다 새 스레드를 생성한다. 스레드 풀이 아니라 스레드 팩토리에 가깝기 때문에, 요청이 몰리면 스레드가 무한히 늘어난다.

운영 환경에서는 ThreadPoolTaskExecutor로 교체해야 한다.

@EnableAsync
@Configuration
public class AsyncConfig {

    @Bean
    public TaskExecutor taskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(5);
        executor.setMaxPoolSize(20);
        executor.setQueueCapacity(100);
        executor.setThreadNamePrefix("async-event-");
        executor.setRejectedExecutionHandler(new CallerRunsPolicy());
        executor.initialize();
        return executor;
    }
}

각 설정의 의미를 정리하면 이렇다.

• corePoolSize : 기본으로 유지하는 스레드 수. 요청이 없어도 이만큼은 살아 있다
• maxPoolSize : 큐가 가득 찼을 때 늘어날 수 있는 최대 스레드 수
• queueCapacity : core 스레드가 모두 바쁠 때 대기하는 작업 큐 크기
• rejectedExecutionHandler : 큐도 꽉 차고 max 스레드도 꽉 찼을 때의 정책. CallerRunsPolicy는 호출한 스레드가 직접 실행한다 — 작업을 버리지 않는다

요청이 들어올 때 스레드 풀이 어떤 순서로 반응하는지 보자.

대부분의 작업은 core 스레드 → 큐 대기 → 추가 스레드 생성 순서로 처리된다. 마지막 단계(CallerRunsPolicy)에 도달하면 호출 스레드가 직접 처리하므로, 일시적으로 동기 실행이 된다. 작업을 버리는 것보다는 낫다.

동기 이벤트와 비동기 이벤트의 판단 기준

모든 이벤트 리스너를 비동기로 만들면 안 된다. 두 가지 질문으로 판단한다.

호출자가 결과를 알아야 하는가

첫 번째 질문은 "호출자가 이 작업의 성공/실패를 알아야 하는가?"이다.

• 옷 등록 후 이미지 썸네일 생성 → 실패해도 등록은 유효하다. 호출자가 몰라도 된다 → 비동기
• 결제 후 주문 상태 변경 → 실패하면 주문이 잘못된 상태에 머문다. 호출자가 알아야 한다 → 동기

나중에 재시도할 수 있는가

두 번째 질문은 "이 작업이 실패했을 때 나중에 다시 시도할 수 있는가?"이다.

• 알림 발송 실패 → 1분 뒤에 다시 보내면 된다 → 비동기 + 재시도
• DB 정합성을 맞추는 작업 → 나중에 재시도하면 그 사이에 데이터가 꼬인다 → 동기

이 두 질문을 의사결정 흐름으로 정리하면 이렇다.

"아니오 → 예"의 경로가 비동기 이벤트의 적용 영역이다. 대부분의 부수효과(알림, 로그 기록, 외부 연동)가 여기에 해당한다.

비동기 리스너의 실패 처리

비동기 이벤트의 가장 큰 특징은 발행자가 이미 응답을 반환한 뒤에 리스너가 실행된다는 것이다. 리스너에서 예외가 발생해도 발행자에게 전파할 방법이 없다. 클라이언트는 성공 응답을 받았지만, 부수효과는 실패한 상태가 된다.

이 상황에서 아무 처리도 하지 않으면 실패가 조용히 묻힌다. 이것을 방지하려면 단계적으로 대응해야 한다.

로깅

가장 기본적인 대응이다. 비동기 스레드에서 발생한 예외는 기본적으로 콘솔에만 찍히고 사라진다. 리스너 안에서 명시적으로 로그를 남겨야 한다.

@Async
@TransactionalEventListener(phase = AFTER_COMMIT)
public void sendNotification(ClothesCreatedEvent event) {
    try {
        notificationService.notifyFollowers(event.getClothesId());
    } catch (Exception e) {
        log.error("알림 발송 실패. clothesId={}", event.getClothesId(), e);
    }
}

로깅만으로 문제를 해결할 수는 없지만, 장애를 인지할 수 있게 된다. 모니터링 시스템이 이 로그를 감지하면 알림을 보낼 수 있다.

자동 재시도

일시적인 네트워크 장애라면, 잠시 후 다시 시도하면 성공할 수 있다. Spring Retry의 @Retryable을 사용하면 재시도 로직을 선언적으로 적용할 수 있다.

@Async
@TransactionalEventListener(phase = AFTER_COMMIT)
@Retryable(
    retryFor = NotificationException.class,
    maxAttempts = 3,
    backoff = @Backoff(delay = 1000, multiplier = 2)
)
public void sendNotification(ClothesCreatedEvent event) {
    notificationService.notifyFollowers(event.getClothesId());
}

@Recover
public void recoverNotification(NotificationException e, ClothesCreatedEvent event) {
    log.error("알림 발송 3회 실패. clothesId={}", event.getClothesId(), e);
    // 실패 기록을 DB에 저장하거나, Dead Letter 큐에 넣기
}

@Retryable은 지정한 예외가 발생하면 자동으로 재시도한다. backoff으로 재시도 간격을 점진적으로 늘린다. 3회 모두 실패하면 @Recover 메서드가 호출된다.

재시도 흐름을 시각적으로 보면 이렇다.

분홍 영역에서 첫 시도가 실패하고, 주황 영역에서 두 번째도 실패했지만, 초록 영역에서 세 번째 시도에 성공했다. 재시도 간격이 1초 → 2초로 늘어나는 것이 multiplier = 2의 효과다.

Dead Letter 패턴

재시도까지 전부 실패하면, 그 작업을 어딘가에 기록해두고 나중에 수동이나 배치로 처리하는 방식이다. 메시지 큐 시스템에서 유래한 이름이지만, 개념 자체는 단순하다 — 처리 못 한 작업을 버리지 않고 보관하는 것이다.

@Recover
public void recoverNotification(NotificationException e, ClothesCreatedEvent event) {
    failedEventRepository.save(FailedEvent.of(
        "NOTIFICATION",
        event.getClothesId(),
        e.getMessage()
    ));
}

보관된 실패 이벤트는 배치 잡이나 관리자 화면에서 재처리할 수 있다. 이 패턴의 흐름을 정리하면 이렇다.

점선 화살표는 비동기 연결을 나타낸다. 이벤트 발행에서 리스너까지, 그리고 Dead Letter에서 배치 재처리까지가 비동기다.

보상 트랜잭션

비동기 리스너의 실패는 "아직 안 한 것"이다. 알림을 못 보냈으면 다시 보내면 된다. 그런데 "이미 한 것"을 되돌려야 하는 경우도 있다. 이것을 보상 트랜잭션이라 한다.

외부 시스템과의 불일치

옷 등록 시 이미지를 S3에 업로드하는 시나리오를 보자. @TransactionalEventListener(AFTER_COMMIT)으로 커밋 후에 S3 업로드를 실행한다. 그런데 업로드는 성공했는데, 후속 처리(이미지 메타데이터 저장 등)에서 실패하면 어떻게 되는가?

초록 영역에서 S3 업로드는 성공했지만, 분홍 영역에서 메타데이터 저장이 실패했다. S3에는 파일이 있고 DB에는 메타데이터가 없는 불일치 상태다. DB 트랜잭션이 롤백돼도 S3 업로드는 되돌려지지 않는다 — 외부 시스템은 우리의 트랜잭션에 참여하지 않기 때문이다.

보상 로직의 구현

이런 불일치를 해결하려면, 실패 시 이전에 성공한 외부 작업을 명시적으로 되돌리는 로직이 필요하다.

@Async
@TransactionalEventListener(phase = AFTER_COMMIT)
public void processImage(ClothesCreatedEvent event) {
    String s3Key = null;
    try {
        s3Key = s3Service.upload(event.getClothesId(), event.getImageData());
        imageMetadataService.save(event.getClothesId(), s3Key);
    } catch (Exception e) {
        // 보상: S3에 올린 파일 삭제
        if (s3Key != null) {
            s3Service.delete(s3Key);
        }
        log.error("이미지 처리 실패, 보상 완료. clothesId={}", event.getClothesId(), e);
    }
}

보상 트랜잭션의 핵심 원칙은 실패 시 이전 단계의 부수효과를 역순으로 되돌리는 것이다. DB에서 ROLLBACK이 자동으로 해주는 일을 직접 코드로 구현한다.

최종 일관성과 강한 일관성

지금까지 다룬 비동기 이벤트 패턴은 근본적으로 최종 일관성을 선택한 것이다. 이 개념을 정리하자.

강한 일관성

모든 작업이 하나의 트랜잭션 안에서 완료된다. 성공하면 모든 데이터가 즉시 일관되고, 실패하면 전부 롤백된다.

• 옷 저장 + 이미지 업로드 + 알림 발송이 모두 같은 트랜잭션
• 하나라도 실패하면 전부 취소
• 사용자는 항상 완벽하게 일관된 데이터를 본다

대신 1편에서 봤듯이, 부가 로직의 실패가 핵심 로직을 롤백시키고, 외부 호출이 트랜잭션 시간을 늘린다.

최종 일관성

핵심 작업만 즉시 완료하고, 부수효과는 "언젠가 반드시 완료된다"고 보장한다. 잠시 동안 데이터 불일치가 있을 수 있지만, 결국 일관된 상태에 도달한다.

• 옷 저장은 즉시 커밋
• 알림 발송은 비동기로 나중에 처리
• 알림이 실패하면 재시도하고, 재시도도 실패하면 Dead Letter에 보관

두 방식의 차이를 비교하면 이렇다.

왼쪽의 강한 일관성은 실선 화살표로 순차 실행되고, 오른쪽의 최종 일관성은 점선 화살표로 비동기 실행된다. 실패 시 재시도까지 포함하면 최종 일관성이 더 복잡하지만, 핵심 로직의 안정성과 응답 속도에서 유리하다.

선택 기준

강한 일관성이 필요한 경우는 생각보다 적다. 판단 기준은 이렇다.

• 강한 일관성 : 금융 거래, 재고 차감처럼 즉시 정확해야 하고 불일치가 치명적인 경우
• 최종 일관성 : 알림, 로그, 검색 인덱스 갱신처럼 잠시 지연돼도 비즈니스에 영향이 없는 경우

대부분의 부수효과는 최종 일관성으로 충분하다. "옷 등록 후 알림이 3초 늦게 도착했다"는 것은 사용자 경험에 거의 영향이 없지만, "알림 서버 장애로 옷 등록이 실패했다"는 것은 심각한 문제다.

면접 Q&A

자주 하는 실수