[Spring] 순환 참조의 올바른 방향

1) 의존성이 불변(final)이라 설계가 명확해짐

나쁜 예: 필드 주입 (숨은 의존성 + 가변 상태)

@Service
public class OrderService {

    @Autowired
    private PaymentClient paymentClient; // 어디서 어떻게 들어오는지 밖에서 안 보임

    public void pay(Order order) {
        paymentClient.requestPayment(order);
    }
}

• 이 클래스를 단독으로 봤을 때는:
  • OrderService가 어떤 의존성을 꼭 가져야 하는지 명확하지 않다.
  • 테스트 코드에서 new로 만들면 paymentClient가 null 이라 또 다른 문제가 된다.

좋은 예: 생성자 + final (의존성이 드러남)

@Service
public class OrderService {

    private final PaymentClient paymentClient;

    public OrderService(PaymentClient paymentClient) {
        this.paymentClient = paymentClient; // 생성 시점에 반드시 주입
    }

    public void pay(Order order) {
        paymentClient.requestPayment(order);
    }
}

• OrderService가 PaymentClient 없이는 의미가 없는 서비스라는 것이 설계 레벨에서 드러난다.

• 스프링 없이 순수 자바 코드로 테스트할 때도:

  PaymentClient fake = new FakePaymentClient();
  OrderService service = new OrderService(fake);

  처럼 의존성이 강제되기 때문에 “숨은 의존성” 문제가 없다.

2) 필수 의존성이 생성 시점에 다 채워져서 null 위험 감소

필드/세터 주입에서 흔한 NPE 패턴

@Service
public class EmailService {

    @Autowired
    private EmailSender emailSender;

    public void sendWelcome(User user) {
        emailSender.send("WELCOME", user.getEmail()); // 여기가 NPE 포인트
    }
}

• 실수로 new EmailService() 로 직접 생성하거나,

• 테스트에서 스프링 컨텍스트 없이 인스턴스를 만들면:

  EmailService service = new EmailService();
  service.sendWelcome(user); // emailSender == null → NPE

• 필드는 @Autowired라고 해서 언제나 초기화된다는 보장이 없다
  (스프링이 관리하지 않는 객체에서는 아예 주입이 안 됨).

생성자 주입으로 null 자체를 막는 예

@Service
public class EmailService {

    private final EmailSender emailSender;

    public EmailService(EmailSender emailSender) {
        this.emailSender = Objects.requireNonNull(emailSender);
    }

    public void sendWelcome(User user) {
        emailSender.send("WELCOME", user.getEmail());
    }
}

• EmailService를 만들려면 무조건 EmailSender를 넘겨야 한다.
• 못 넘기면 컴파일/런타임에서 즉시 실패하고,
  최소한 “null인 상태로 돌아다니는 객체”는 만들 수 없다.

3) 순환 의존이 생기면 애플리케이션이 뜨지 않아 구조 문제가 빨리 드러남

순환 의존 예: A ↔ B

@Service
public class AService {
    private final BService b;

    public AService(BService b) {
        this.b = b;
    }
}

@Service
public class BService {
    private final AService a;

    public BService(AService a) {
        this.a = a;
    }
}

• 스프링이 시작하면서:

  1. AService 생성 → BService 필요
  2. BService 생성 → 다시 AService 필요
  3. 서로를 요구하다가 BeanCurrentlyInCreationException 같은 예외를 던지고
     애플리케이션이 부팅 단계에서 바로 실패한다.

이게 오히려 장점이다.

• “순환 구조가 애초에 잘못됐다”는 사실을 아주 이른 시점에 강하게 알려준다.
• 운영 중 애매한 버그 대신, 시작 단계에서 바로 문제를 발견하고 설계를 다시 보게 만든다.

세터/필드 주입이면 어떻게 되나

@Service
public class AService {
    @Autowired
    private BService b;
}

@Service
public class BService {
    @Autowired
    private AService a;
}

• 스프링이 둘 다 먼저 인스턴스를 만들고, 나중에 세터/필드로 서로 주입할 수 있어서
  애플리케이션은 일단 뜬다.
• 대신:
  • 라이프사이클 복잡,
  • 어디서 어떤 타이밍에 null인지/아닌지 추적이 어려움,
  • 구조적으로는 여전히 꼬여 있는데 눈에 잘 안 띄는 상태로 남는다.

그래서 생성자 주입은:

순환 의존이 있으면 “애초에 안 뜨게” 만들어서,
구조 문제가 운영 중이 아니라 개발 단계에서 바로 드러나게 해준다.