4.8.4.2 이벤트 사용에 대한 고려사항

일반적으로 애플리케이션을 작성하다 보면 특정 컴포넌트가 특정 이벤트를 수신해야 할 때가 있습니다. 보통 이럴 때는 명시적으로 개별 컴포넌트에 통지를 하는 코드를 작성하거나 JMS 같은 메시징 기술을 사용해 처리합니다. 개별 컴포넌트에 이벤트를 순차적으로 통지하는 코드를 작성하는 것은 대부분 불필요하게 통지받는 컴포넌트를 발행자에 결합시키는 단점이 있습니다.

시간이 걸리는 데이터베이스 접근을 피하려고 애플리케이션에서 상품 상세 정보를 캐시 컴포넌트에 담는 상황을 생각해 봅시다. 캐시 컴포넌트 외에 상품 상세 정보를 수정해 데이터베이스에 저장하는 갱신 컴포넌트가 있다고 가정하겠습니다. 캐시 컴포넌트에 담긴 정보를 최신으로 유지하려면 갱신 컴포넌트는 명시적으로 캐시 컴포넌트에 상품 정보가 변경됐음을 통지해야 합니다. 이 예시에서 갱신 컴포넌트는 자신의 비즈니스와 전혀 관련이 없는 캐시 컴포넌트와 결합됩니다. 좀 더 나은 해결책은 갱신 컴포넌트는 상품 상세 정보가 변경될 때마다 이벤트를 발행하고 이에 관심 있는 캐시와 같은 컴포넌트가 이 이벤트를 대기하는 것입니다. 이렇게 하면 컴포넌트가 서로 결합되지 않는 장점이 있으며, 캐시 컴포넌트를 제거하거나 상품 정보 변경에 관심이 있는 다른 수신자를 추가하는 작업을 간단하게 할 수 있습니다.

캐시에서 상품 상세 정보를 삭제하는 작업은 처리 속도가 빠르며 비즈니스 관점에서 중요한 작업이 아닙니다. 그러므로 여기에 JMS를 사용하는 것은 지나친 일입니다. 대신 스프링의 이벤트 인프라를 사용하면 애플리케이션에 발생하는 부담을 매우 작게 할 수 있습니다.

보통 이벤트는 빠르게 실행되며 애플리케이션의 주 로직 일부가 아닌 반응 로직(reactionary logic)에서 사용됩니다. 앞 예제에서 캐시의 상품 정보를 제거하는 작업은 상품 정보가 변경될 때 이에 대한 반응으로 발생하며, 신속히 수행될 뿐 아니라 (또는 신속해야 하며) 애플리케이션의 주 기능 중 일부도 아닙니다. 장시간 실행되며 주요 비즈니스 로직의 일부를 담당하는 처리를 할 때는 JMS나 RabbitMQ같은 메시징 시스템을 사용할 것을 권장합니다. JMS를 사용하는 주요 장점은 장시간 실행되는 프로세스에 더 적합하다는 점과 시스템이 커짐에 따라 필요한 경우 JMS 기반 비즈니스 메시지 처리 작업을 별도 서버로 분리할 수 있다는 점을 들 수 있습니다.