감사 이벤트 모델과 공유 파이프라인 전환
관리자 플랫폼에서 사용자 생성과 역할·권한 변경을 일관된 이벤트로 남기는 작업을 진행했습니다. 처음에는 구조화 로그로 기록하고, 이후 사내 수집 플랫폼에 HTTP로 전송했다가 SNS 기반 공유 파이프라인으로 옮겼습니다.
2025년 하반기부터 2026년 초까지 다른 업무와 병행한 작업입니다. 전송 환경이 준비되는 순서에 맞춰 연결 방식을 바꿨고, 이벤트를 만드는 코드와 외부로 전달하는 부분을 나눠 두려고 했습니다.
먼저 정한 이벤트 모델
시간이 많이 든 부분은 어떤 행동을 하나의 이벤트로 기록하고 어떤 필드를 넣을지 정하는 일이었습니다. 기존 권한 모델을 바탕으로 Actor·Action·Target과 시각, 추가 맥락을 구분했습니다. 같은 필드를 사용하는 서비스가 생기면 이름과 의미를 바꾸기 어려워지기 때문입니다.
사용자 생성과 역할 할당은 다르고, 역할 정의를 수정한 것과 특정 사용자에게 역할을 부여한 것도 다릅니다. 단순히 UPDATE라고 기록하면 어느 대상의 어떤 변경인지 해석하기 어려웠습니다.
다음은 이 구분을 설명하기 위한 이벤트 예시입니다. 실제 내부 스키마나 사용자 정보는 아닙니다.
{
"eventId": "event-demo-001",
"timestamp": "2026-01-15T00:00:00Z",
"actor": { "type": "USER", "id": "actor-demo" },
"action": "ROLE_ASSIGN",
"target": { "type": "ROLE_ASSIGNMENT", "id": "assignment-demo" },
"context": { "requestId": "request-demo" }
}요청을 추적하는 식별자와 개별 이벤트의 식별자도 역할이 다릅니다. 한 요청에서 여러 이벤트가 생길 수 있고, 전송 재시도에서는 같은 이벤트가 다시 도착할 수 있습니다.
로그 기록에서 HTTP 연동으로
처음에는 감사 이벤트를 JSON 로그로 남겨 검색할 수 있도록 했습니다. 이후에는 수집 플랫폼이 제공하던 HTTP API를 사용했습니다. 당시 바로 연결할 수 있는 방식이었지만, 애플리케이션에서 OAuth 토큰과 HTTP 클라이언트, 실패·재시도를 관리해야 했습니다.
로그 수집도 알림과 외부 연동에 사용할 수 있습니다. 로그로도 실시간 처리는 가능하지만, 다른 서비스와 분석 시스템에서 같은 이벤트를 계속 받아 처리할 수 있도록 전달 방식을 바꿨습니다.
발행 인터페이스와 공통 라이브러리
업무 코드는 어떤 사건이 발생했는지 표현하고, 별도 처리 계층에서 감사 이벤트로 변환해 기록·발행하도록 나눴습니다. 발행 인터페이스 아래에서 전송하지 않는 구현과 HTTP·SNS 구현을 선택할 수 있게 구성했습니다.
이 모듈을 다른 서비스에서도 쓸 수 있도록 공통 라이브러리로 분리하는 방향이었습니다. 전송 방식을 라이브러리에 고정하기보다 사용하는 애플리케이션이 환경에 맞게 설정하도록 했습니다. HTTP에서 SNS로 바꿀 때도 이벤트 생성 경로는 유지하고 발행 구현과 설정을 교체할 수 있었습니다.
Spring의 조건부 Bean 선택은 컨텍스트 구성 시 적용되는 설정입니다. 속성 하나를 바꿨다는 이유로 실행 중인 모든 인스턴스가 즉시 전환되는 것은 아니므로 배포와 실제 선택된 구현을 확인해야 합니다.
SNS 기반 공유 파이프라인
이후에는 서비스가 SNS에 이벤트를 발행하고, SQS와 EventBridge Pipes를 거쳐 변환·전달 계층에서 수집 플랫폼으로 보내는 구조를 직접 설계했습니다.
그림은 역할을 단순화한 흐름입니다. Pipes가 Kafka를 직접 쓰기 대상으로 지원한다는 의미는 아니며, 실제 전달은 연결한 처리 계층을 거칩니다.
서비스에서는 기존 HTTP·OAuth 연동 코드를 줄이고 SNS 발행에 필요한 권한과 오류 처리를 맡았습니다. 이후의 변환과 전달을 공유 파이프라인으로 옮긴 대신, 전달 과정에서 발생하는 실패와 지연도 확인해야 했습니다.
발행과 최종 수신의 구분
SNS가 요청을 받았다는 결과와 Kafka에서 이벤트를 받아 처리할 수 있는 상태는 다릅니다. 큐에 쌓인 시간과 전달 실패, 재처리 대상을 구분하고, 이벤트를 받는 쪽에서도 중복을 처리할 수 있어야 합니다.
감사 이벤트는 JSON 로그 검색에서 HTTP 전송을 거쳐 SNS와 공유 파이프라인으로 전달하는 구성으로 바뀌었습니다. 서비스 안에서 직접 관리하던 HTTP·OAuth 처리를 줄인 대신, 큐에 쌓인 시간과 전달 실패, 중복 처리를 확인하는 일이 필요해졌습니다.
큐를 둔 것만으로 업무 데이터 변경과 최초 발행 사이의 누락까지 막은 것은 아닙니다. 보존 기간 초과나 재시도 소진도 따로 봐야 합니다. outbox는 이런 경우 검토할 수 있는 방법이며, 이번 작업에서 적용한 결과로 다루지는 않았습니다.
다음 글에서는 이 경로를 통해 수집한 이벤트를 Bronze·Silver·Gold 데이터로 정리한 과정을 다룹니다.