Django EP85: 장고 Logging(로깅) 설정하는 방법에 대해 알아보자

장고 로깅이 왜 필요한가

제가 처음 장고로 서비스를 운영할 때 print()로 로그를 찍었는데, 배포하고 나서야 그게 얼마나 위험한지 깨달았어요. 서버에서 print 문이 보이지 않거나, 로그가 섞여서 어떤 요청에서 에러가 났는지 전혀 알 수 없더라고요.

로깅은 단순히 메시지를 남기는 게 아니라, 시스템에서 발생하는 이벤트를 체계적으로 기록하는 거예요. 장고 공식 문서에서도 로거(Logger), 핸들러(Handler), 포매터(Formatter), 필터(Filter) 네 가지 개념을 중심으로 설명하는데, 이 중에서 실무에서는 로거와 핸들러, 포매터만 제대로 이해해도 충분하더라고요.

로그 레벨은 총 다섯 단계예요. DEBUG → INFO → WARNING → ERROR → CRITICAL 순으로 높아지는데, 레벨을 INFO로 설정하면 WARNING 이상만 기록되고 DEBUG와 INFO는 무시돼요. 반대로 DEBUG로 두면 모든 로그가 다 찍히니까 개발할 때는 DEBUG, 운영 서버에서는 WARNING이나 ERROR로 올리는 게 일반적이에요.

실제로 제가 운영하는 프로젝트에서는 DEBUG는 로컬에서만 쓰고, 스테이징과 프로덕션은 INFO 이상으로 고정해 놨습니다. 이렇게 하면 불필요한 로그가 서버 디스크를 채우는 걸 막을 수 있어요.

settings.py에서 로깅 기본 설정하기

실제 설정은 settings.py 제일 아래에 LOGGING 딕셔너리를 추가하는 방식으로 진행돼요. version은 1로 고정하고, disable_existing_loggers는 False로 두는 게 중요해요. True로 하면 기존 로거들이 전부 꺼져버리거든요.

핸들러는 'console'이라는 이름으로 StreamHandler를 등록해서 터미널에 출력하게 만들었어요. root 로거에 이 핸들러를 연결하고 level을 'INFO'로 설정하면, INFO 이상 로그만 콘솔에 나타납니다. 숫자로 10, 20, 30 등을 직접 써도 되지만 가독성을 위해 문자열을 쓰는 걸 추천해요.

특정 앱만 별도 로거를 만들 수도 있어요. 예를 들어 'my_site.views'라는 이름의 로거를 따로 정의해서 level을 'DEBUG'로 주면, views.py에서 찍는 DEBUG 로그만 별도로 관리할 수 있죠. 이렇게 하면 전체 로그와 앱별 로그를 분리해서 볼 수 있어서 현업에서 정말 편하더라고요.

파일 저장과 JSON 포맷으로 실전 적용

콘솔만으로는 로그가 사라지니까 파일로 저장하는 핸들러를 추가했어요. 'file' 핸들러를 만들어서 filename을 지정하고, level을 'INFO'로 설정한 다음 my_site.views 로거에 연결하면 로그가 파일에 쌓입니다.

여기서 중요한 게 propagate 옵션이에요. False로 두면 해당 로거에서만 처리되고 상위 root 로거로는 전달되지 않아요. True로 바꾸면 root에 설정된 console 핸들러까지 로그가 올라가서 콘솔과 파일에 동시에 남길 수 있죠. 저는 보통 파일 핸들러는 propagate=False로 두고, 필요할 때만 True로 바꿔서 확인하는 식으로 씁니다.

더 나아가서 JSON 포맷으로 저장하고 싶다면 python-json-logger 패키지를 설치하세요. pip install python-json-logger 한 줄이면 끝나요. 그다음 Formatter를 'pythonjsonlogger.jsonlogger.JsonFormatter'로 지정하면 기본 JSON 로그가 생성됩니다.

커스텀 포매터를 만들고 싶다면 my_site/logger.py 파일을 만들어서 JsonFormatter를 상속받아 format 메서드를 재정의하면 돼요. 소스 파일명, 라인 번호, 로그 레벨까지 추가로 넣어서 ELK 스택이나 Loki 같은 도구로 파싱하기 쉽게 만들 수 있죠.

이렇게까지 설정해 놓으면 나중에 로그를 수집할 때 파싱 비용이 확 줄어들어요. 실제로 제가 담당했던 프로젝트에서는 JSON 로그 덕분에 에러 추적 시간이 절반 가까이 줄었습니다.