이벤트

이벤트는 어떤 일이 일어났다는 사실을 한 건으로 붙잡아 다른 쪽에 알립니다. 버튼이 눌렸다는 사실도, 주문 하나가 결제됐다는 사실도 이벤트 한 건이 됩니다. 알리는 쪽은 누가 받아서 무엇을 할지 정하지 않습니다. 받는 쪽이 그 한 건을 보고 스스로 정합니다.

쉽고 빠른 이해

이벤트는 「방금 이런 일이 있었다」를 한 건으로 적어 둔 알림입니다. 결제가 끝났을 때 결제 모듈이 남기는 한 건이 그렇습니다.

이벤트가 없으면 일을 끝낸 쪽이 그 뒤에 무엇을 해야 하는지까지 전부 알고 있어야 합니다. 결제 코드가 영수증 발송도 부르고 적립도 부르게 됩니다. 뒤에 할 일이 하나 늘 때마다 결제 코드를 고쳐야 합니다.

어떻게 도는가:

1. 일이 벌어진 쪽이 무슨 일인지와 언제인지를 한 건으로 만듭니다
2. 그 한 건을 받을 쪽에 날라 주는 통로에 내놓습니다
3. 그런 일이 오기를 기다리던 쪽이 받아서 각자 처리합니다

대가는 흐름이 안 보인다는 것입니다. 부르는 줄이 없으니 무엇 다음에 무엇이 이어지는지 코드만 읽어서는 따라가기 어렵습니다.

뒤에 붙을 처리가 몇 개가 될지 모를 때 씁니다. 받는 쪽이 하나로 정해져 있으면 그냥 함수를 부르는 편이 낫습니다.

상세

가게 문에 달린 종을 떠올려 봅시다. 손님이 문을 밀면 종이 한 번 울립니다. 종은 누가 그 소리를 듣는지 모릅니다.

주방에 있던 사람이 들으면 나와 봅니다. 아무도 없으면 소리는 그냥 지나갑니다.

이벤트는 일어난 일 하나를 데이터 한 건으로 적은 것입니다. 무슨 일이었는지와 언제 일어났는지, 그리고 그 일에 딸린 값이 함께 담깁니다. 결제 모듈이 남기는 「주문 4821 결제 완료」 한 건이 그런 데이터입니다.

이 절은 먼저 이벤트 한 건에 무엇이 담기는지 봅니다. 이어서 알리는 쪽과 받는 쪽이 어떻게 갈라지는지, 분야마다 이 말이 무엇을 가리키는지, 이벤트를 흘려보낼지 남길지를 짚습니다. 끝으로 이벤트로 짜면 무엇이 어려워지는지를 봅니다.

이벤트 한 건에 담기는 것

이벤트 한 건은 대개 넷을 담습니다. 「주문 4821 결제 완료」를 예로 들면 이렇습니다.

이름은 이미 벌어진 일을 과거형으로 적습니다. 결제하라가 아니라 주문 결제됨입니다. 시키는 말로 이름을 지으면 받을 쪽이 하나로 정해져 버립니다. 그러면 굳이 이벤트로 만들 이유가 없습니다.

한 번 만들어진 이벤트는 고치지 않습니다. 이미 일어난 일이라 나중에 사실이 바뀌지 않기 때문입니다. 값이 틀렸다면 그 건을 고치는 대신 「주문 결제 취소됨」을 하나 더 남깁니다.

알리는 쪽과 받는 쪽

이벤트를 쓰는 이유는 하나입니다. 알리는 쪽이 받는 쪽을 몰라도 된다는 것입니다.

함수를 직접 부르면 부르는 쪽이 상대의 이름을 알아야 합니다. 결제가 끝나고 영수증을 보내려면 결제 코드 안에 영수증 코드를 부르는 줄이 들어갑니다. 적립을 붙이려면 줄이 하나 더 늡니다. 통계 적재를 붙이려면 또 하나 늡니다.

이벤트로 바꾸면 결제 코드는 「주문 결제됨」 한 건을 내놓고 끝냅니다. 영수증도 적립도 그 이름을 기다리다가 각자 받아 갑니다. 새 처리를 붙일 때 결제 코드는 손대지 않습니다.

가운데에서 한 건을 날라 주는 것을 통로라고 부릅니다. 이벤트 버스나 메시지 큐가 그 노릇을 합니다.

sequenceDiagram
    participant 결제
    participant 통로
    participant 영수증
    participant 적립
    결제->>통로: 「주문 결제됨」 한 건
    통로->>영수증: 같은 한 건
    통로->>적립: 같은 한 건
    Note over 통로: 기다리는 쪽이 없으면 여기서 끝난다

받아 가는 쪽은 리스너라고 부릅니다. 리스너는 받을 이벤트 이름을 미리 걸어 두고 기다립니다. 통로는 그 이름에 걸린 리스너 모두에게 같은 한 건을 건넵니다.

분야마다 가리키는 것

이벤트라는 말은 여러 분야가 같이 씁니다. 가리키는 대상은 분야마다 다릅니다. 그래도 「일어난 일 하나를 한 건으로 적는다」는 점은 같습니다.

제품 분석에서 이벤트는 세는 단위입니다. 「장바구니 담기」가 하루에 몇 번 일어났고 그중 결제까지 간 것이 몇 건인지를 이 단위로 셉니다.

한 사람이 들어와 나갈 때까지 벌인 이벤트를 묶은 것이 세션입니다. 한 번 들어와 장바구니에 담고 결제하고 나간 것이 세션 하나입니다. 그 세션이나 사용자를 조건으로 추려낸 묶음은 세그먼트입니다.

관측성에서 이벤트는 로그·메트릭·스팬 옆에 놓이는 기록 갈래입니다. 로그는 그때 무슨 일이 있었는지 줄글로 남긴 것입니다. 메트릭은 수를 시간에 따라 잽니다. 스팬은 한 작업의 시작과 끝을 잽니다.

이벤트는 이 셋과 달리 「이 시점에 이런 일이 있었다」 한 건을 남깁니다. 배포가 나갔다거나 설정이 바뀌었다는 것이 그런 한 건입니다.

흘려보내는 쓰임과 쌓아 두는 쓰임

같은 이벤트라도 쓰임이 둘로 갈립니다. 알림으로 쓰고 버리는 쪽과, 기록으로 쌓아 두는 쪽입니다.

알림으로 쓰면 받는 쪽이 처리한 뒤 그 건은 사라집니다. 화면의 버튼 눌림이 그렇습니다. 지금 반응하는 것이 전부입니다. 어제 눌린 것을 다시 꺼내 볼 이유가 없습니다.

기록으로 쌓아 두면 이벤트가 이력이 됩니다. 계좌의 입금과 출금을 순서대로 쌓아 두면 잔액은 그 건들을 처음부터 더해 다시 만들 수 있습니다. 현재 값 대신 일어난 일을 저장하는 이 방식을 이벤트 소싱이라고 합니다.

쌓아 두면 「지금 얼마인가」뿐 아니라 「어떻게 그 값이 됐나」를 나중에 물어볼 수 있습니다. 대가는 양입니다. 일어난 일을 전부 남기므로 보관할 데이터가 계속 늘어납니다.

이벤트로 짜면 어려워지는 것

이벤트는 부르는 줄을 없애는 대신 셋을 떠안깁니다.

첫째, 흐름이 코드에 안 보입니다. 결제 코드를 읽어도 그 뒤에 영수증이 나가는지 알 수 없습니다. 무엇이 무엇을 듣고 있는지는 리스너를 걸어 둔 대목을 따로 찾아봐야 합니다.

둘째, 같은 이벤트가 두 번 올 수 있습니다. 보내는 쪽이 응답을 못 받아 다시 보내면 받는 쪽은 같은 건을 두 번 봅니다. 그래서 받는 쪽은 두 번 처리해도 결과가 같도록 짜 둡니다. 이 성질을 멱등성이라고 합니다.

셋째, 도착 순서가 뒤바뀔 수 있습니다. 「주문됨」보다 「주문 결제됨」이 먼저 도착하면 받는 쪽은 없는 주문의 결제를 보게 됩니다. 도착 순서가 결과를 바꾸는 처리라면 이벤트에 순번을 실어 보내거나, 순서가 지켜지는 통로를 골라 씁니다.

그래서 받는 쪽이 하나로 정해져 있고 앞으로도 늘지 않는다면 이벤트로 돌릴 이유가 없습니다. 함수를 직접 부르는 편이 읽기 쉽고 터질 곳도 적습니다. 이벤트는 뒤에 붙을 처리가 몇 개가 될지 모를 때, 그리고 일어난 일 자체를 남겨 두고 싶을 때 이득이 큽니다.

관련 항목

이벤트와 나란히 놓이는 관측 기록

로그 · 메트릭 · 트레이스 · 스팬 · 텔레메트리 · 관측성

이벤트 한 건을 실어 나르는 통로

메시지 큐 · 메시지 브로커 · 토픽 · 이벤트 스트림 · 이벤트 버스 · 웹훅

이벤트를 받아 실행되는 코드

리스너 · 핸들러 · 콜백 · 구독자 · 컨슈머 · 이벤트 루프

이벤트를 중심에 두는 설계 방식

이벤트 주도 · 이벤트 소싱 · 발행-구독 · 옵저버 패턴 · CQRS · 스트림 처리

이벤트 한 건을 이루는 구성 요소

타임스탬프 · 이벤트 이름 · 페이로드 · 상관 ID · 스키마

이벤트를 모아 세는 분석 단위

사용자 · 세션 · 세그먼트 · 퍼널 · 코호트

이벤트를 주고받다 터지는 문제

중복 전달 · 순서 뒤바뀜 · 메시지 유실 · 멱등성 · 재시도

이벤트를 일으키는 계기

트리거 · 워크플로 · 상태 전이 · 사용자 동작