[Backend] 유저 활동 로그 수집 모듈 개발기 1편 유저 활동 로그 수집기 구상하기

---

"왜 우리는 로그 수집기를 직접 만들기로 했을까?"

---

1. 도입

플랫폼이 성장하고 트래픽이 늘어나면서, 단순한 서버 로그만으로는 부족해지는 순간이 온다.
우리는 사용자와 플랫폼 간의 상호작용을 정밀하게 추적하고 싶었다.

• 사용자가 어떤 합주실을 둘러보는지
• 어떤 경로로 예약까지 이어지는지
• 비정상 요청이 반복되는 경로는 어디인지

이 모든 것을 알기 위해선, 단순 로그가 아닌 행동 기반 이벤트 수집기가 필요했다.

---

2. 설계 목표

처음부터 무리한 대시보드나 통계 시스템을 만들 생각은 없었다.
우리의 목표는 다음 세 가지였다.

• 유저의 주요 활동을 놓치지 않고 수집한다
• 플랫폼 장애나 지연에도 유실되지 않도록 설계한다
• 추후 분석 시스템과도 유연하게 연동할 수 있게 한다

→ 이 목표를 만족하기 위해선,
단순한 DB INSERT 또는 파일 로깅 방식은 너무 취약했다.

---

3. 기존 방식이 가진 한계

방식	장점	한계
DB에 직접 저장	구현 간단	트래픽 증가 시 부하, 확장성 낮음
로컬 파일 로깅	간단하고 빠름	검색/조회 어려움, 유실 가능성 높음
ELK 직접 연동	시각화 강점	높은 진입장벽, 운영 복잡도

그래서 우리는 고민 끝에 중앙 이벤트 버스를 도입하기로 결정했다.
→ 바로 Kafka였다.

---

4. Kafka 도입을 결정하게 된 이유

• 대량 이벤트 처리를 위한 비동기 메시지 큐
• Replay 가능한 로그 → 장애 시 재처리 가능
• **다양한 소비자(Consumer)**에게 분산 가능
• 운영 경험이 많고, 레퍼런스도 많음

하지만 Kafka는 단순히 "발행만 하면 끝"이 아니다.
어떤 시점에 데이터를 발행할지,
어떤 형식으로 묶어서 보낼지,
어떤 장애를 고려해야 할지가 핵심이었다.

---

5. 우리가 직접 수집기를 만들기로 한 이유

Kafka를 쓴다고 해서, 모든 게 해결되는 건 아니었다.

• 매 요청마다 바로 Kafka로 보내면 비용이 크다
• 수백 TPS의 로그를 매번 직렬화하면 CPU도 낭비
• Kafka Producer 실패에 대한 대응도 복잡하다

그래서 우리는 Kafka를 감싸는 버퍼 기반 수집기를 직접 설계하기로 했다.

---

6. 다음 편 예고

2편에서는 실제로 우리가 어떻게

• 로그를 메모리 버퍼에 쌓고
• 일정 조건에서만 Kafka로 flush하고
• 그동안의 동시성 이슈를 어떻게 해결했는지

직접 만든 LogBufferManager, FlushExecutor 구조를 설명할 예정이다.

---