[기능] 로깅 시스템 중앙화

[kkyungseo]

기능 설명 (Description)

• Lang2SQL 프로젝트 전체에서 중앙화된 로깅 시스템을 구축하여 로깅 설정의 중복과 불일치 문제를 해결합니다. 기존에 5개 파일에서 각각 logging.basicConfig()를 호출하던 것을 중앙화된 모듈에서 한 번만 설정하도록 개선하고, 모든 모듈이 동일한 로깅 포맷과 설정을 공유할 수 있는 개선된 기능을 제시합니다.

왜 필요한가요? (Motivation / Use Case)

• 중복 호출 문제: cli/utils/logger.py, db_utils/logger.py, infra/monitoring/check_server.py, infra/observability/token_usage.py, infra/db/connect_db.py에서 각각 logging.basicConfig()를 중복 호출하여 불필요한 오버헤드 발생
• 포맷 불일치: 각 파일마다 다른 로깅 포맷을 사용하여 로그 일관성 부족
• 유지보수의 어려움: 로깅 설정 변경 시 여러 파일을 수정해야 하는 번거로움
• 디버깅의 어려움: 로그에서 어느 모듈에서 발생한 것인지 식별하기 어려움

제안하는 해결 방법 (Proposed Implementation)

• 중앙화된 로깅 모듈 생성: infra/logging/centralized_logger.py에서 모든 로깅 설정을 관리
• 통일된 포맷 적용: "%(asctime)s [%(levelname)s] %(name)s: %(message)s" 포맷으로 모든 로그 통일
• 중복 방지 메커니즘: 전역 변수 _logging_configured로 중복 설정 방지
• 환경변수 지원: LOG_LEVEL 환경변수로 로깅 레벨 동적 조정 가능
• 기존 파일 수정: 모든 기존 파일에서 logging.basicConfig() 제거하고 get_logger(__name__) 사용

대안 (Alternatives)

• 기존 logging 모듈 활용: Python 표준 logging 모듈의 설정 파일(logging.conf) 사용할 수 있을 것이라 예상됨
• 외부 라이브러리 도입: structlog, loguru 등 고급 로깅 라이브러리 사용
• 점진적 마이그레이션: 기존 코드를 유지하면서 새로운 모듈에만 중앙화된 로깅 적용하는 점진적 방식 활용

추가 고려사항 (Additional Context)

• 성능: 중복 logging.basicConfig() 호출 제거로 초기화 오버헤드 감소
• 확장성: 향후 파일 로깅, JSON 로깅, 로그 로테이션 등 추가 기능 확장
• 테스트: 로깅 설정이 중앙화되어 테스트 시 로깅 레벨 조정

[kkyungseo]

172-기능-로깅-시스템-중앙화에서 작업 중

[ehddnr301]

172-기능-로깅-시스템-중앙화에서 작업 중

• 저는 issue에서 스크린샷의 Create a branch를 눌러 작업을 하긴합니다아아 (이슈와 연결된 브랜치를 알수있어서 좋더라구요!)
• 혹시 더 좋은방법이 있다면 제안주세요!! :)
• 💬 이번 이슈 너무 좋은내용입니다아아아

[kkyungseo]

아 이슈에서 바로 branch를 만드는 기능이 있었군요...!
이슈에서 의견 수합하고 branch 따로 만들고, 슬랙에 보고하는 형식을 쓰다보니 이 기능은 몰랐네요..!
알려주셔서 감사합니다! 😀

(현재 이슈를 생성한 다음, 이슈 번호에 맞춰 이후에 branch를 만든 상태라, branch 번호와 이슈 번호가 동일한 상태이기는 합니다!)