[개발 일기] 2025.01.04 - Event, Publisher, Listener

2025. 1. 4. 21:26·개발 일기

개요

 

프로그래밍 환경에선 이벤트라는 말이 자주 사용된다.

 

 

그리고 이벤트는 Publisher와 Listener와 함께 사용된다.

 

 

늘 개발할 때마다 Event, Publisher와 Listener는 자주 봤지만, 내부 기능과 사용목적은 확실하게 알지 못했다.

 

 

오늘은 이 세 가지 객체의 목적을 알아보자.

 

 

 

Event

 

Spring의 Event란 스프링 애플리케이션 내부에서 발생하는 작업이나 상태변화를 나타내는 객체이다.

 

 

무슨 말인지 모르겠다. 쉽게 설명해 보자.

 

 

예를 들어 "홍길동 사용자가 회원가입을 했다", "홍길동 사용자가 로그인에 성공했다" 같은 상황이 이벤트를 의미한다.

 

 

그리고 이 이벤트는 다른 리스너(Listener)가 "어? 무슨 일이 있었네!" 하고 알아차릴 수 있게 도와주는 일종의 메시지 역할을 한다. 이렇게 하면 코드가 서로 강하게 연결되지 않고도(느슨하게 결합된 상태로) 필요한 작업을 처리할 수 있다. (이게 가장 큰 장점임!)

 

 

 

Publisher

 

"홍길동 사용자가 회원가입을 했다", "홍길동 사용자가 로그인에 성공했다"와 같은 상황이 발생하면 이 상황을 나타내는 이벤트 객체를 생성해야 한다. 이 이벤트 객체를 생성하고 Listener가 감지할 수 있도록 하는 것이 Publisher의 역할이다.

 

 

주요 흐름은 이벤트를 생성한 뒤엔 ApplicationEventPublisher을 사용해 애플리케이션에 Publish 한다.

 

@Component
@RequiredArgsConstructor
public class MemberEventPublisher {

    private final ApplicationEventPublisher publisher;

    public void publishSignUpEvent(String message) {
        // 이벤트 객체 생성
        MemberSignUpEvent event = new MemberSignUpEvent(this, message);

        // 이벤트 발행
        publisher.publishEvent(event);
        System.out.println("Event published: " + message);
    }
}

 

 

 

Listener

 

리스너는 영어론 Listener로 말 그대로 듣는 역할을 한다. 어떤 상황(=이벤트)이 발생하는지 안 하는지 대기하고 있다가, 그에 해당하는 상황이 들리면(=발생하면) 미리 정의된 작업을 수행하는 것이다.

 

 

Spring 환경의 Listener는 웹 애플리케이션의 생명 주기 이벤트를 감지하고, 발생한 이벤트에 따라 작업을 수행한다.

 

@Component
public class MemberEventListener {

    @EventListener
    public void sendMail(MemberSignUpEvent event) {
        // 회원가입에 성공했다는 메일 전송
    }
    
    @EventListener
    public void sendPushMessage(MemberSignUpEvent event) {
        // 회원가입에 성공했다는 푸쉬 메시지 전송
    }
}

 

 

 

느낀 점

 

이 기법을 사용한다면, 기능 구현 시, 특정 서비스와 의존관계를 형성할 필요가 없을 것 같다.

(회원가입 성공 시, 메일이나 푸시 메시지를 전송하는데, MemberService와 MailService(메일 전송), MessageService(푸시 메시지 전송)와 같은 서비스와 의존 관계를 형성할 필요 없음)

 

 

어떻게 보면 늘 개발할 때마다 드는 고민 중 하나는 Service 코드의 수많은 의존 관계를 보고 아래 생각을 꾸준히 하고 있다.

 

이게 맞는 방법인가? 현업에서 이런 코드를 짜면 유지보수가 많이 힘들 것 같은데..

 

 

만약 Event, Publisher, Listener를 적절히 사용한다면 이러한 고민을 조금 해결할 수 있을 것 같다.

 

 

다음 프로젝트에선 한번 도입해 봐야지..!

'개발 일기' 카테고리의 다른 글

[개발 일기] 2025.01.06 - OSI 7계층 (물리 계층)  (0) 2025.01.06
[개발 일기] 2025.01.05 - 자바 객체 락 (synchronized)  (0) 2025.01.05
[개발 일기] 2025.01.03 - Redis의 만료기한  (0) 2025.01.03
[개발 일기] 2025.01.02 - @Transactional (readOnly = true)  (0) 2025.01.02
[개발 일기] 2025.01.01 - 도커 컨테이너 네트워크 (Feat : ports)  (0) 2025.01.01
'개발 일기' 카테고리의 다른 글
  • [개발 일기] 2025.01.06 - OSI 7계층 (물리 계층)
  • [개발 일기] 2025.01.05 - 자바 객체 락 (synchronized)
  • [개발 일기] 2025.01.03 - Redis의 만료기한
  • [개발 일기] 2025.01.02 - @Transactional (readOnly = true)
오도형석
오도형석
  • 오도형석
    형석이의 성장일기
    오도형석
  • 전체
    오늘
    어제
    • 분류 전체보기 N
      • MSA 모니터링 서비스
        • DB
      • 스파르타 코딩클럽
        • SQL
        • Spring
      • 백엔드
        • Internet
        • Java
        • DB
      • 캡스톤
        • Django
        • 자연어처리
      • Spring
        • JPA
        • MSA
      • ETC
        • ERROR
      • 개발 일기 N
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

  • 인기 글

  • 태그

  • 최근 글

  • hELLO· Designed By정상우.v4.10.3
오도형석
[개발 일기] 2025.01.04 - Event, Publisher, Listener
상단으로

티스토리툴바