이제 마지막으로 새로 추가한 Rolling Policy를 Spring Boot의 기본 xml 파일에서 어떻게 읽는지 확인해보도록 하자.
대부분 비슷한 내용이지만 <Policies> 블럭에 새로운 Rolling Policy를 적용한 것을 확인할 수 있다. 다시 흐름을 설명해보자면 파일 로깅이 활성화된 경우(LogFile 존재) 이 Log4j2 구성이 사용되며 Boot가 시스템 프로퍼티를 먼저 채우고, XML은 ${sys:...} 치환으로 이를 소비해 최종 구성을 완성하는 흐름이다. xml 대부분의 동작 요소는 log4j2의 플러그인 시스템을 통해 이름/카테고리 매칭으로 읽어 인스턴스화한다. Spring Boot에서는 StructuredLogLayout이라는 커스텀 플러그인을 추가로 작성하여 사용하고 있다.
기본 플러그인
- Console: 콘솔 Appender. 문자셋/임계치 및 레이아웃 선택을 지원
- RollingFile: 파일 Appender(롤링 지원). fileName/filePattern 설정과 Policies/Strategy를 포함
- PatternLayout: 패턴 기반 레이아웃. ${sys:...}로 패턴 파라미터 주입
- ThresholdFilter: 레벨 임계치 필터
- DefaultRolloverStrategy: 롤오버 보관 정책(max, cleanHistoryOnStart, totalSizeCap)
- SystemPropertyArbiter: 지정한 시스템 프로퍼티 존재/값으로 분기 선택. 구조화 vs 패턴 레이아웃 전환에 사용
- DefaultArbiter: 어떤 Arbiter도 매칭되지 않을 때 기본 선택
- Select: 여러 Arbiter 중 하나를 선택하게 하는 컨테이너(내장 플러그인 요소)
이제 롤링 정책을 xml 파일이 소비할 수 있도록 해주어야 한다. 처음엔 여기서 SystemPropertyArbiter를 사용하여 시스템 프로퍼티에 따른 분기를 해주었는데, 만약 이후 추가적인 롤링 전략(여러 롤링 전략을 합성해서 사용하는 경우 등)이 생길 때마다 xml 파일에서 새로운 분기를 넣어주어야하는 단점이 있어서 SpringBootTriggeringPolicy라는 커스텀 플러그인을 정의하여 사용해주었다.
Log4J2의 플러그인은 다음과 같이 동작한다.
1. 발견(Discovery)
- 어노테이션 기반 인덱스: 플러그인 클래스에 @Plugin을 붙이고, 빌드 시 log4j-core 어노테이션 프로세서가 Log4j2Plugins.dat을 생성해 인덱싱한다
- 런타임: 설정을 파싱할 때 플러그인 매니저가 인덱스를 조회해 “카테고리 + 이름”으로 클래스를 찾는다.
2. 생성(Construction)
- 플러그인 클래스 표시: @Plugin 어노테이션
- 인자 주입 방식
- 팩토리: @PluginFactory 정적 메서드의 파라미터에 @PluginAttribute(XML 속성), @PluginElement(자식 요소), @PluginConfiguration(Configuration), @PluginLoggerContext(LoggerContext) 등으로 주입
- 빌더: @PluginBuilderFactory로 빌더를 리턴하고, 빌더 필드에 @PluginBuilderAttribute를 붙여 주입(가독성/유효성에 유리)
XML의 <SpringBootTriggeringPolicy .../>를 파싱할 때
- 빌더 경로(@PluginBuilderFactory) 사용 → 빌더 필드에 @PluginBuilderAttribute(strategy, maxFileSize, timeInterval, timeModulate, cronExpression), @PluginConfiguration(Configuration) 등이 주입 → build() 호출로 인스턴스 생성 또는 팩토리 경로(@PluginFactory)로 동일 파라미터를 직접 주입해 생성
파싱, 생성, 시작 흐름
1. 설정 파일 파싱: ConfigurationFactory가 XML을 파싱해 노드 트리를 구성
2. 플러그인 해석: 노드의 요소명이 “카테고리/이름”으로 매칭되어 해당 플러그인 클래스의 팩토리/빌더가 호출됨
3. 주입: XML 속성/자식 요소/컨텍스트가 @Plugin* 어노테이션에 따라 인자로 전달됨
4. 라이프사이클: 생성된 객체가 start()로 시작되고, 종료 시 stop() 호출(옵션적으로 LifeCycle, LifeCycle2 지원)
전체 코드를 보여주기엔 너무 길어서 핵심적인 부분만 올려두었다. 새로 만든 log4j2 플러그인의 동작은 다음과 같다.
빌더에 주입된 속성 + 시스템 프로퍼티를 읽어 최종 전략/파라미터를 결정(우선순위: 시스템 프로퍼티 → XML 속성 → 기본값)
build()에서 전략을 스위치해 실제 Log4j2 내장 정책을 생성하고(delegate로) 감싸기
- size → SizeBasedTriggeringPolicy
- time → TimeBasedTriggeringPolicy
- size-and-time → CompositeTriggeringPolicy(사이즈+타임)
- cron → CronTriggeringPolicy
이후 이벤트 판단은 delegate(기존 Triggering Policy)가 수행하도록 위임하였다.
마지막으로 additional-spring-configuration-metadata.json에 새로 만든 속성들을 추가해주었다.
additional-spring-configuration-metadata.json은 설정 파일(YAML/properties)의 자동완성/검증을 돕는 메타데이터 파일이다. IDE 자동완성/문서 툴이 참조해 키, 타입, 기본값, 설명, 폐기(replacement) 정보를 제공하고 자동 생성 메타데이터(@ConfigurationProperties)로 커버 안 되는 항목을 수동으로 보강한다. 빌드 시 수집되어 JAR의 메타데이터로 포함되고, IDE와 Spring Boot 구성 프로세서가 참조하여 “설정 키의 스펙”을 기술하는 역할을 해준다. yml이나 properties를 작성할 때 "이 값은 지원하지 않는 값"과 같은 경고 문구, 자동완성 등을 지원해준다!
이렇게 Log4j2의 Rolling Policy Property를 추가해보았는데, 스프링 부트라는 거대 오픈소스 프로젝트를 분석하면서 그동안 몰랐던 신기한 기능들도 많이 보았고, 어떻게 코드를 설계하여 문제를 해결하는지 엿볼 수 있는 시간이었다. 기능을 만들면서 기존 Spring Boot의 코드를 많이 참고했는데, 왜 좋은 코드들을 많이 보라고 하는지 알 것 같다. 잘 설계된 코드들을 보며 "왜 이렇게 설계했을까?"라는 생각을 하며 추측하고 "내가 그동안 작성했던 코드들과는 어떻게 다른가?"생각해보며 뒤돌아볼 수 있던 시간이었다. 기능을 추가하기 위해 밤새며 코드를 분석하고 추가하는 경험은 정말 값진 경험으로 남은 것 같다!
Log4J2 Properties 개발기 1편
개발 배경Spring Boot는 Slf4J의 기본 구현체로 Logback을 지원한다. 하지만 대부분은 성능, 편의상 이유로 기본 의존성 Logback을 제거하고 Log4J2를 사용할 것이다. 로깅에는 Rolling Policy라는 것이 존재한
bird-j.tistory.com
Log4J2 Properties 개발기 2편
지난 번엔 기존 Spring Boot의 Logging 관련 설정들이 어떻게 적용되는지 알아보았다. 이제 그 흐름 사이에 추가하려고 하는 Log4J2의 Rolling Policy 속성들을 읽을 수 있도록 끼워넣으면 된다! 직접 구현
bird-j.tistory.com
'Computer Science > Spring Boot' 카테고리의 다른 글
| Spring AI (0) | 2025.11.27 |
|---|---|
| Spring Boot docker image build fail issue (0) | 2025.10.24 |
| Log4J2 Properties 개발기 2편 (0) | 2025.10.21 |
| Log4J2 Properties 개발기 1편 (0) | 2025.10.20 |
| Spring Security - 인증/인가와 FilterChain (w. JWT, Authorization) (0) | 2025.09.12 |