안녕하세요, Python 웹 애플리케이션 및 데이터 파이프라인과 같은 고부하 환경에서 파일 I/O 및 로깅 병목을 겪는 분들을 위한 LogXide를 소개합니다.

1. 만든 이유 (The Problem)

Python의 기본 logging 모듈은 순수 Python으로 작성되어 있습니다. 일반적인 환경에서는 충분하지만, 트래픽이 몰리는 구간이나 대규모 로깅 파이프라인에서는 I/O 작업 중 GIL(Global Interpreter Lock)을 점유하며 애플리케이션 전체의 성능을 저하시키는 원인이 됩니다.

2. 어떻게 해결했나 (Architecture)

LogXide는 코어 로직과 핸들러를 Rust로 작성하고 PyO3로 바인딩했습니다.

  • Python-side Level Check: FastLoggerWrapper를 두어 로그 레벨이 비활성화된 경우(예: INFO 레벨 설정 시 DEBUG 호출), PyObject 생성이나 PyO3 경계 통과 없이 Python 단에서 즉시 무시합니다. 이 최적화로 빈 호출 시 속도가 2~5배 향상되었습니다.
  • 논블로킹 I/O: StreamHandler, HTTPHandler, OTLPHandler는 crossbeam 채널과 백그라운드 스레드를 이용해 비동기적으로 로그를 처리합니다. 주 애플리케이션 스레드를 블로킹하지 않습니다.
  • 동기 직접 write: FileHandler의 경우 Mutex<BufWriter>를 사용해 직접 OS I/O를 수행하며, 필요 시에만 flush를 수행하여 I/O 오버헤드를 극단적으로 줄였습니다.

3. 주요 벤치마크 (macOS ARM64, Python 3.12 기준)

  • FileHandler: 2.09M msgs/sec (stdlib 167K 대비 12.5배 빠름)
  • StreamHandler: 2.14M msgs/sec (stdlib 11K 대비 186배 빠름)
  • C로 작성된 Picologging보다 실제 파일 포맷팅 I/O에서 25% 더 빠르고, 순수 파이썬인 Structlog보다 2.4배 빠릅니다.

4. 내장 기능 및 사용법

from logxide import logging 한 줄만 변경하면 기존의 logging.getLogger() 코드를 그대로 사용할 수 있는 구조입니다. 최근 백엔드 아키텍처 트렌드에 맞춰 다음 핸들러들을 Rust 네이티브 수준에서 내장했습니다:

  • OTLPHandler: OpenTelemetry 에이전트 없이 Protobuf 기반 직접 전송
  • HTTPHandler: 배치(Batch) 모아 보내기 기능
  • SentryHandler: 에러 로깅 통합 지원 (pip install logxide[sentry])
  • ColorFormatter: ANSI 제어 문자를 활용한 터미널 컬러 출력 지원

5. 명확한 한계 (Trade-offs)

도입을 검토하실 때 100% Drop-in replacement가 아님을 아셔야 합니다:

  • Python으로 작성된 커스텀 logging.Handler를 상속받아 등록할 수 없습니다. (Rust로 구현된 내장 핸들러만 사용해야 최고 성능이 유지됩니다).
  • LoggerLogRecord 객체를 서브클래싱할 수 없습니다.
  • pytest 환경에서는 빌트인 caplog 대신 LogXide가 제공하는 caplog_logxide fixture를 사용해야 합니다.

성능 병목으로 인해 C 기반 로거나 구조화된 로깅 라이브러리를 찾고 계셨다면 훌륭한 대안이 될 것입니다! Django, FastAPI, Flask에 바로 적용 가능한 연동 가이드도 공식 문서에 포함되어 있으니 한 번 살펴봐 주시고 피드백 주시면 감사하겠습니다.