운영 로그 전략

 

이번 시간에는 운영 로그 전략을 학습해 보겠습니다. 이번 학습에서는 로그를 배워볼 것입니다.

우선 학습 자료를 토대로 우선 공부후 실습을 통해 느낀점을 작성해 보는 시간을 가져보겠습니다.

 

학습 목표

● 로그 레벨 개념

● 로그 출력 및 확인 

 

로그 레벨

로그 레벨이란?

로그 레벨 ( Log Level) 은 로그의 심각도를 나타내는 분류입니다. 개발 시에는 상세한 DEBUG 로그가 필요하지만, 운영 시에는 성능을 위해 INFO 이상만 출력합니다.

로그 레벨	용도	예시
ERROR	에러, 예외 상황	DB연결 실패, NPE
WARN	경고, 잠재적 문제	느린 쿼리, 재시도 발생
INFO	일반 정보	앱 시작, 요청 처리 완료
DEBUG	디버깅용 상제 정보	변수 값, SQL 쿼리
TRACE	매우 상세한 정보	메서드 진입/종료

 

● application.yml

logging.level.root=INFO

 

필요에 따라 환경별로 로그 레벨을 결정합니다!

환경	권장 레벨	이유
local	DEBUG	개발 중 상세 정보 필요
prod	INFO	성능 + 충분한 정보

 

핵심 규칙은, prod(라이브서버)에서는 info로 설정해주는 것입니다. 그 외 환경은 일반 유저들이 사용하지 않기에 필요한 로그 레벨만큼 설정을 해주시면 됩니다.

 

Spring Boot에서 로그 출력Spring Boot에서는 slf4j를 사용하여 로그를 출력합니다.

SLF4J란? JDBC가 오라클 / MYSQL 상관 없이 공통된 코드를 쓰게 해주듯, SLF4J는 로깅 라이버르리 종류에 상관없이 공통 된 로깅 코드를 작성하게 해주는 인터페이스입니다.

 

SLF4J 사용 이유	설명
로그 레벨 제어	DEBUG/INFO/WARN/ERROR 중 원하는 레벨만 출력
환경별 설정	local에서는 DEBUG, prod에서는 INFO만 출력 가능
포맷팅 지원	깔끔한 출력
성능 최적화	출력하지 않을 로그는 문자열 연산 자체를 생략

 

● Lombok @Slf4j 사용

import lombok.extern.slf4j.Slf4j;

@Slf4j
@RestController
public class HealthController {

    @GetMapping("/log")
    public String health() {
        log.info("헬스체크 요청");           // INFO 레벨
        log.debug("상세 디버깅 정보");       // DEBUG 레벨
        log.error("에러 발생");            // ERROR 레벨
        return "OK";
    }
}

 

● 로그 메서드

 

로그 확인

로그를 출력하는 방법을 배웠습니다. 이제 그 로그를 어디서 확인할 수 있는지 환경별로 알아봅니다.

 

환경별 로그 확인 방법

환경 : 로컬 과 EC2 로 나뉜다.

 

나머지 자세한 내용은 다음에 실습 시간에 또 다루도록 하겠습니다. 감사합니다

 

 

✏️ 느낀점

이번 운영 로그 전략 학습을 통해 로그는 단순히 개발 중 에러를 확인하기 위한 출력 도구가 아니라, 운영 환경에서 서버의 상태와 흐름을 추적하기 위한 가장 중요한 수단이라는 것을 알게 되었다.
로그 레벨 개념을 학습하면서, 모든 로그를 무작정 많이 남기는 것이 좋은 것이 아니라 상황과 환경에 맞는 로그 레벨 전략이 필요하다는 점이 인상 깊었다. 개발 환경에서는 DEBUG나 TRACE 로그를 통해 세부적인 흐름과 변수 값을 확인하는 것이 중요하지만, 운영 환경에서는 성능과 안정성을 위해 INFO 이상의 로그만 남기는 것이 적절하다는 이유를 이해할 수 있었다.
특히 prod 환경에서 DEBUG 로그를 그대로 유지할 경우 불필요한 로그 출력으로 인해 성능 저하가 발생할 수 있고, 로그 파일 용량 증가로 운영 관리에 부담이 될 수 있다는 점에서 로그 레벨 설정이 단순한 옵션이 아니라 운영 전략의 일부라는 것을 느꼈다.
SLF4J를 사용하는 이유 또한 명확해졌다. 로깅 라이브러리에 종속되지 않고 공통된 인터페이스를 통해 로그를 작성함으로써, 환경이나 설정 변경에 따라 유연하게 로그 레벨을 제어할 수 있다는 점이 실제 서비스 운영에 매우 적합하다고 느꼈다. 또한 문자열 연산 자체를 생략하는 방식의 로그 출력 구조는 단순한 출력 이상의 성능 최적화 역할을 한다는 점에서 인상 깊었다.
실습을 통해 직접 로그를 출력해보며, 같은 코드라도 설정된 로그 레벨에 따라 출력 여부가 달라지는 것을 확인하면서 “로그는 코드가 아니라 설정으로 제어된다”는 개념이 확실하게 와닿았다. 이로 인해 운영 환경에서는 코드 수정 없이도 로그 전략을 조절할 수 있다는 점이 큰 장점으로 느껴졌다.
이번 학습을 통해 로그는 단순한 개발 편의 기능이 아니라, 장애 발생 시 원인을 추적하고 서비스 상태를 판단하는 운영 서버의 핵심 자산이라는 것을 이해하게 되었다. 앞으로는 단순히 기능 구현에만 집중하기보다, 어떤 로그를 어떤 레벨로 남겨야 운영 환경에서 의미 있는 정보가 될 수 있는지 함께 고민하는 개발자가 되어야겠다고 느꼈다.