[Backend] 유저 활동 로그 수집 모듈 개발기 5편 : 마무리 회고

 

도입

앞선 글들에서는 Outbox 패턴을 통한 신뢰성 있는 로그 발행, Kafka 기반 로그 수집 처리, 그리고 분석 최적화를 위한 수신 시스템 설계까지 다루었습니다.

이제 마지막으로, BFF 모듈에서의 로그 발행 흐름과 전체 서비스 구성 흐름을 정리하고 마무리하겠습니다.

---

BFF에서의 로그 발행 흐름

클라이언트 요청이 들어오면, 다음과 같은 구조로 로그를 발행합니다.

@Slf4j
@RestController
@RequiredArgsConstructor
public class PostController {

    private final LogEventPublisher logPublisher;

    @GetMapping("/posts/{id}")
    public ResponseEntity<?> getPost(@PathVariable Long id, HttpServletRequest request) {
        long start = System.currentTimeMillis();

        PostDto post = postService.getPost(id);

        long duration = System.currentTimeMillis() - start;

        logPublisher.publish(
            LogEvent.builder()
                .userId(SecurityContext.getUserId())
                .actionType(LogActionType.VIEW_POST)
                .timestamp(LocalDateTime.now())
                .metadata(LogMetadata.nowKST(true, duration, request.getRemoteAddr()))
                .payload(Map.of("postId", id))
                .build()
        );

        return ResponseEntity.ok(post);
    }
}

발행 흐름 요약

1. 클라이언트가 /posts/{id} 요청
2. 서비스 처리 시간 측정
3. 로그 메타데이터 생성 (duration, IP 등)
4. LogEvent 생성 후 logPublisher.publish() 호출
5. 이벤트가 Outbox 테이블에 저장됨
6. 배치 스케줄러가 Kafka로 전송
7. 수신 서비스에서 분석용 DB에 저장

---

전체 서비스 흐름도

[클라이언트 요청]
        │
        ▼
[BFF Controller]
        │
        ├── 서비스 로직
        │
        └── 로그 발행
              │
              ▼
        [Outbox 테이블]
              │
     (배치 스케줄러)
              │
              ▼
     [Kafka Topic: activity.log.save]
              │
              ▼
[Consumer 모듈 - log ingestor]
              │
              ▼
   [MySQL 로그 분석용 테이블]

---

시스템 요약

항목 설계 요소

전송 신뢰성	Outbox + Kafka
로그 구조	LogEvent, LogMetadata 분리
발행 시점	BFF Controller 내부
수신 처리	Kafka Consumer + JPA 저장
분석 확장성	정규화된 DB + URL 기반 필드

---

주요 설계 포인트 복습

• Outbox 상태 기반 관리: 실패, 재시도, 죽은 이벤트까지 감지
• 배치 전송: Kafka 발송 처리량 최적화
• 분석 테이블 정규화: userId, actionType, targetId, url, client, duration, success 등 분석 필드 명확화
• 비즈니스 흐름과의 분리: 로그는 비동기 처리로 성능 영향 최소화

---

 마무리

1인 개발 환경에서 Kafka 기반 로그 수집 시스템을 차근차근 설계하면서 많은 고민을 거쳤습니다. 서비스 흐름을 해치지 않으면서도, 유연하고 신뢰성 있는 구조를 만드는 것이 핵심이었습니다.

다음은 이 구조를 기반으로 Slack 알림 연동, DeadLetter 큐 시각화, 로그 기반 알람 시스템 등으로 확장할 수 있습니다.

서비스는 쌓이는 로그만큼 성장합니다. 그 로그가 말이 되려면, 구조가 먼저 말이 되어야 합니다.

---