로깅 레벨 (Logging Level)

좋은 로그 메시지 작성법

레벨만큼 중요한 것이 메시지의 내용과 형태다. 무엇이, 어떤 맥락에서, 어떤 값으로 일어났는지가 담겨야 나중에 검색하고 집계할 수 있다. 최근 표준은 사람이 읽는 문장 대신 키와 값 쌍으로 남기는 구조화 로깅(Structured Logging)이다. JSON 형태로 남기면 로그 수집 시스템에서 필드 단위 검색과 통계가 가능해진다.

{"level":"ERROR","ts":"2026-08-17T09:12:33Z","logger":"payment",
 "msg":"결제 승인 실패","orderId":"ord-1042","pgCode":"E4012",
 "elapsedMs":1830,"traceId":"7f3a9c"}

여기에 요청 단위 식별자인 트레이스 아이디(Trace ID)를 모든 로그에 함께 남기면, 마이크로서비스 여러 개를 거친 한 요청의 흐름을 이어서 추적할 수 있다. 주의할 점도 있다. 비밀번호, 토큰, 주민등록번호 같은 민감 정보는 어떤 레벨에서도 남기지 않아야 하며, 필요한 경우 마스킹(Masking)을 거친다. 또 비활성 레벨이라도 메시지 조립 비용은 발생할 수 있으므로, 문자열 연결 대신 지연 평가되는 자리 표시자 방식을 쓰는 것이 성능상 안전하다.

운영 환경에서의 로그 관리

운영 로그는 파일에 쌓아 두는 것으로 끝나지 않는다. 여러 서버의 로그를 한곳에 모으는 중앙 집중화가 기본이며, 일래스틱서치(Elasticsearch) 기반 스택이나 로키(Loki), 클라우드 관리형 서비스가 흔히 쓰인다. 디스크가 로그로 가득 차는 사고를 막기 위해 날짜나 크기 기준으로 파일을 교체하고 오래된 것을 지우는 로테이션(Rotation) 정책을 두고, 법적 요건과 비용을 고려한 보존 기간을 정한다. 트래픽이 많은 서비스에서는 DEBUG 로그의 양 자체가 성능과 비용 문제를 일으키므로, 전체 요청 중 일부만 상세히 남기는 샘플링(Sampling)이나 운영 중 특정 로거만 레벨을 바꾸는 동적 레벨 조정을 활용한다. 마지막으로 ERROR 이상 레벨은 로그로 남기는 데서 그치지 않고 알림 시스템과 연동해, 로그가 관측 가능성(Observability)의 한 축으로 기능하게 만드는 것이 실무의 완성형이다.

면접에서 이렇게 물어본다

• 로깅 레벨의 종류와 각 레벨의 사용 기준을 예를 들어 설명해 보라.
• 운영 환경에서 DEBUG 로그를 끄는 이유와, 장애 조사 시의 대안을 말해 보라.
• WARN과 ERROR를 나누는 자신만의 기준은 무엇인가.
• 구조화 로깅이 무엇이고 왜 필요한지 설명해 보라.
• 마이크로서비스 환경에서 하나의 요청을 로그로 추적하려면 무엇이 필요한가.