➰ Logback, 자바 로깅의 표준을 지탱하는 프레임워크

나나's Brain·2025년 9월 9일

개념Study

목록 보기

22/25

개발하다 보면 log 찍어서 데이터 흐름을 확인하는 경우가 많다.
여기서 log는 단순히 값 찍어서 확인하는 용도일까? 아니면 더 큰 의미가 있을까?

생각해 보면 로그는 단순한 System.out.println의 대체제가 아니다.
문제가 터졌을 때 장애 원인을 추적하고, 운영 상태를 모니터링하고, 보안 감사를 위해 기록을 남기고, 심지어는 성능을 최적화하는 단서가 되기도 한다.

그럼 “로그는 어떤 식으로 활용될 수 있을까?”라는 질문이 자연스럽게 따라온다.
→ 그래서 앞으로 글을 쓰면서 로그의 종류, 로그 레벨, 로그가 어떻게 흘러가는지, 그리고 실무에서 어떻게 운영 환경에 연결되는지까지 차근차근 쌓아나가 보려 한다.

📁 Logback은 뭐지? 로그면 SLF4J 아니야?

Logback은 자바 애플리케이션에서 로그를 찍고 관리하는 로깅 프레임워크다.
SLF4J(Simple Logging Facade for Java)의 대표 구현체 중 하나고, 스프링 부트는 기본값으로 이걸 품고 있다.

그러니까 우리가 평소에 쓰는 log.info("Hello") → 이게 찍히는 순간 실제로 콘솔이나 파일에 이쁘게 포맷 맞춰서 뿌려주는 애가 바로 Logback이다.

참고하자면 Logback의 공식 문서(logback.qos.ch)는 정말 잘 정리되어 있다.
읽다 보면 “이걸 이렇게 쓸 수도 있구나!” 싶은 설정들이 제법 있다.

🚨 흔히 헷갈리는 지점: Logback vs SLF4J

여기서 헷갈릴 수 있다. ~~그게 나야 ^^~~
SLF4J는 “로깅을 추상적으로 호출할 수 있게 해주는 인터페이스” 역할을 한다.
Logback은 SLF4J의 실제 구현부, 즉 로그를 어떻게 찍을지, 어디에 저장할지, 어떻게 포맷할지를 직접 처리하는 엔진이다.

Logback 안쪽을 까보면 이렇게 나뉜다.

Logger: 어떤 로그를 찍을지, 레벨은 뭘로 찍을지 정한다
Appender: 찍은 로그를 어디로 보낼지 정한다 (콘솔, 파일, DB, Kafka 등)
Encoder: 찍을 때 어떤 모양으로 보여줄지 정한다 (패턴, JSON 등)

개발 단계에서는 보통 콘솔 찍기만 하고, 운영 환경에서는 파일로 굴리거나, 날짜 단위로 파일을 굴리는 RollingFileAppender를 많이 쓴다.

아 맞다, 로그는 단순히 찍는 게 다가 아니고, 레벨이라는 개념도 있었다.
레벨별로 중요도가 다르고, 상황에 따라 다르게 관리해야 했었는데 정리해보자.

🔖 로그 레벨, 왜 필요할까?

로그는 TRACE → DEBUG → INFO → WARN → ERROR로 레벨이 나뉘며, 상황에 따라 집중하는 레벨이 달라진다.

개발 중엔 디테일한 TRACE/DEBUG가 필요하고, 운영에서는 INFO 이상의 안정적인 로그가 중심이다.
문제가 생겼을 때는 WARN/ERROR를 집중적으로 추적하게 된다.

그런데 여기서 끝이 아니라, Logback을 쓰면 패키지·클래스별로 레벨을 다르게 커스텀할 수도 있다. 즉 필요한 로그는 더 자세히, 불필요한 로그는 줄이는 식으로 운영 환경을 조율할 수 있다.

레벨	의미
TRACE	제일 세세한 로그 (거의 내부 실행 단계까지)
DEBUG	개발자 디버깅용
INFO	운영 중 정상 동작 기록
WARN	주의가 필요한 상황
ERROR	예외/에러 상황, 꼭 확인해야 함

💡 스프링 부트에서는 언제 켜질까?

스프링 부트 앱이 켜지는 순간 logback-classic이 자동으로 로드된다.
application.yml이나 logback-spring.xml 설정만 제대로 잡아주면, 첫 로그가 찍힐 때는 이미 준비가 다 끝나 있는 상태다.

logging:
  file:
    path: ./logs
  level:
    root: INFO

이렇게만 해도 ./logs/spring.log 같은 파일이 뚝딱 생긴다.

그럼 실무와 같은 환경에선 이러한 로그를 어떻게 관리할까?

📈 로그 그냥 찍고 끝? No.

단순히 로그를 찍고 끝내는 게 아니라, 운영 환경에서는 중앙 집중식으로 수집/분석하는 경우가 많다.
예: Logback → Filebeat → Logstash → Elasticsearch → Kibana(ELK) 파이프라인
Logback은 “출발지점”이기 때문에, 초기 로그 구조가 잘 되어 있어야 이후 처리가 수월하다.

만약 logstash-logback-encoder라는 라이브러리를 쓰면 구조화된 JSON 로그를 바로 출력할 수 있어, Kibana에서 userId=nana123 같은 필터링이 바로 가능하다.

logstash-logback-encoder를 붙이면 로그가 이런 식으로 나온다.

{
  "timestamp": "2025-06-16T14:32:21.004+09:00",
  "level": "INFO",
  "logger": "com.nana.api.LogService",
  "thread": "http-nio-8080-exec-1",
  "message": "회원가입 완료",
  "userId": "nana123",
  "traceId": "abc-def-ghi"
}

이러면 Kibana에서 userId=nana123 조건으로 바로 검색할 수 있다.
Slack 알림이든 대시보드든, 다 여기서 출발하는 셈이다.

공식 문서에는 아래와 같은 내용도 유용하다: