메시지 브로커 없이 회원 탈퇴 후처리 연결하기

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

회원 탈퇴는 서비스 곳곳에 닿는다. 리뷰, 포인트, 찜을 비롯한 여러 도메인 데이터에 후처리가 필요할 수 있다. 그렇다고 사용자 서비스가 모든 도메인 서비스를 직접 호출하면 의존관계가 금세 복잡해진다.

작은 서비스라면 이 결합을 피하기 위해 곧바로 메시지 브로커를 도입할 필요는 없다. 공통 후처리 인터페이스를 만들고, 영향을 받는 각 도메인이 구현체를 제공한 뒤, 사용자 서비스가 구현체 목록을 주입받아 순회하는 방법이 있다. 사용자 서비스는 구체적인 도메인 서비스를 몰라도 된다.

구현체 목록으로 흐름을 한곳에 남긴다

포인트와 리뷰 도메인이 같은 정리 인터페이스를 구현한다고 해보자. 사용자 서비스는 두 구현체를 목록으로 받아 회원 탈퇴 시 차례로 호출한다. 포인트 서비스와 리뷰 서비스에 직접 의존하는 대신, 회원 탈퇴 후처리라는 공통 역할에 의존하는 구조다.

이 방식은 조정 흐름을 코드에 드러낸다. 애플리케이션 이벤트도 직접 참조를 줄일 수 있지만, 발행 지점과 수신 지점이 흩어지면 처리 경로를 따라가기 어려울 수 있다. 구현체 목록을 쓰면 후처리가 어디서 시작되고 등록된 구현체를 순회한다는 사실을 바로 볼 수 있다.

탈퇴가 모든 후처리까지 끝나야 완료되는 흐름이라면 동기적으로 차례로 실행할 수 있다. 탈퇴 자체를 먼저 끝내고 나머지를 후처리로 본다면 백그라운드 실행도 생각할 수 있다. 둘은 예시에서 제시한 선택지이며, 실패 처리 전체를 해결한 설계는 아니다.

규모가 커지면 선택도 달라질 수 있다

구현체 목록을 선호하는 전제는 사용자 수와 탈퇴 로직이 아직 복잡하지 않고 인프라도 넉넉하지 않은 작은 서비스다. 이런 상황에서 Kafka 같은 브로커를 추가하면 현재 문제보다 운영할 장치가 더 커질 수 있다.

반대로 탈퇴 시 반응해야 할 기능이 아주 많다면 이벤트를 발행하고 각 영역이 받아 처리하는 편이 더 깔끔해질 수 있다. 이벤트가 틀렸다는 뜻이 아니다. 작은 흐름의 결합도를 낮추기 위해 그 흐름이 감당할 필요가 없는 인프라부터 숨겨 넣지 말자는 판단에 가깝다.

작은 규모에서는 인터페이스와 구현체 목록만으로도 적당한 경계를 만들 수 있다. 정리 동작은 각 도메인이 소유하고, 사용자 서비스에는 전체 조정 흐름이 보인다. 회원 탈퇴 자체가 쉬운 문제는 아니지만, 현재 조건에서 필요한 만큼만 의존성을 느슨하게 만드는 선택이다.