Exception Handling

예외는 어디서 잡고, 어떻게 던져야 할까요?

재시도와 타임아웃 구현을 다루면서 예외를 외부 API를 호출하는 클라이언트에서 잡아서 던져야 할지, 아니면 서비스 계층에서 처리해야 할지와 같은 고민을 해볼 수 있습니다.

• 메일 예제에서는 SMTP Clinet를 호출하는 서비스 계층에서 재시도

• 결제 예제에서는 PG를 호출하는 PG Client에서 예외를 핸들링하여 재시도

이런 차이는 적절한 기준을 가지고 적절한 위치에 적용해야 합니다.

예외 핸들링 위치를 결정하는 기준

1. 라이브러리 의존성 격리

외부 라이브러리(RestTemplate, WebClient, SMTP Client 등)는 각자 고유한 예외(ReadTimeoutException, RestClientException 등)를 던집니다.

[나쁜 예] 라이브러리의 예외를 서비스나 컨트롤러까지 그대로 흘려보내는 경우입니다.

// Service Layer
try {
    // WebClient 사용 중 발생한 Netty 전용 예외
} catch (io.netty.handler.timeout.ReadTimeoutException e) { 
    // ...
}

이렇게 하면 서비스 코드가 특정 라이브러리(Netty)에 강하게 결합됩니다.

나중에 HTTP 클라이언트를 OpenFeign이나 RestTemplate으로 바꾸면, 서비스 코드의 catch 블록을 전부 다 고쳐야 합니다.

[좋은 예] 라이브러리를 호출하는 클라이언트(Client/Adapter) 계층에서 예외를 잡고, 우리 시스템의 커스텀 예외로 바꿔서 던져야 합니다.

// Client Layer
try {
    webClient.post()...
} catch (ReadTimeoutException e) {
    // 라이브러리 예외를 커스텀 예외로 변환 (추상화)
    throw new PaymentGatewayTimeoutException("PG사 응답 지연", e);
}

이렇게 하면 서비스 계층은 구체적인 통신 기술을 몰라도 되고, PaymentGatewayTimeoutException만 처리하면 되므로 유지보수성이 크게 향상(DIP 준수)됩니다.

2. 재시도 범위 최소화

@Retryable을 어디에 붙이느냐에 따라 재시도되는 코드의 범위가 달라집니다.

메일 전송 서비스에 이메일 유효성 검사(Validation) 로직과 SMTP 전송 로직이 섞여 있다고 가정해 보겠습니다.

[서비스 전체에 재시도 적용 시 문제점]

@Service
public class MailService {
    @Retryable // 메서드 전체가 재시도됨
    public void sendMail(String email) {
        validate(email); // 1. 유효성 검사 (가벼움)
        // ... 기타 비즈니스 로직 ...
        // 만약 DB 커넥션이나 락을 길게 잡는 로직이 재시도에 포함된다면?
        
        smtpClient.send(); // 2. 외부 통신 (무거움, 실패 가능성 높음)
    }
}

만약 smtpClient.send()에서 실패하면, validate(email)부터 다시 실행됩니다.

물론 유효성 검사는 가볍지만, 만약 무거운 DB 작업이나 중복되면 안 되는 로직이 섞여 있다면 문제가 커집니다.

[해결책: 책임 분리] 재시도가 필요한 외부 통신 로직만 별도 클래스로 분리하고, 그곳에 재시도를 적용하는 것이 안전합니다.

@Service
public class MailService {
    private final MailClient mailClient; // 별도 분리된 클라이언트

    public void sendMail(String email) {
        validate(email); // 재시도 대상 아님
        mailClient.send(email); // ★ 여기 내부에서만 재시도 수행
    }
}

앞에서 결제 예시와 유사한 코드로 구성되면서, 이렇게 하면 재시도 단위를 좁게 제한하여 사이드 이펙트를 최소화할 수 있습니다.

요약: 예외 처리 기준

1. 어디서 잡을까? (Catch)

   • 외부 라이브러리를 사용하는 가장 최전선(Client/Adapter Class)에서 잡는것이 좋습니다.

2. 무엇을 던질까? (Throw)

   • 기술 종속적인 예외(NettyException 등)를 그대로 던지지 말고, 비즈니스 의미를 담은 커스텀 예외(PaymentException 등)로 포장(Wrap)해서 던지는 것이 좋습니다.

3. 어디를 재시도할까? (Retry)

   • 서비스 전체를 재시도하지 말고, 실패 가능성이 높은 외부 통신 구간만 별도 클래스로 분리하여 재시도를 적용하는 것이 좋습니다.

이러한 예외 처리 기준은 단순히 에러를 막는 것이 아니라, 좋은 구조를 만드는 핵심이 될 수 있습니다.

• 추상화: 구현 기술이 바뀌어도 비즈니스 로직은 변경되지 않고 보호받을 수 있습니다.

• 격리: 재시도는 반드시 필요한 부분만 수행될 수 있습니다.