Two Years to Feel the Need. One Night to Fix It.

Two Years to Feel the Need. One Night to Fix It.

100개 프로젝트가 가르쳐준 것: 로깅 표준화의 실무적 가치

백엔드 개발을 하다 보면 프로젝트마다 로깅 방식이 제각각인 상황을 자주 마주치게 된다. 어떤 서비스는 System.out.println으로 도배되어 있고, 어떤 서비스는 외부 라이브러리를 사용하지만 설정이 제각각이다. 한 개발자가 100개 이상의 프로젝트를 거치며 이 문제를 2년간 피부로 느낀 끝에, 단 하루 만에 해결책을 만들어 배포했다는 이야기는 Java 백엔드 개발자에게도 충분히 유효한 메시지를 담고 있다.

핵심 통찰은 간단하다. "무엇이 필요한지 알기까지 2년이 걸렸고, 알고 나서 만드는 데는 하루면 충분했다." 문제를 정확히 정의하는 것이 구현보다 훨씬 어렵다.

로깅 비표준화가 실무에서 만드는 마찰

프로젝트가 쌓일수록 일관성 없는 로깅은 조용한 기술 부채가 된다. 운영 중인 서비스에서 장애가 발생했을 때, 로그 포맷이 서비스마다 다르면 집계 및 분석이 불가능하다. Elasticsearch나 Datadog 같은 중앙 로그 수집 시스템은 구조화된 JSON 포맷을 전제로 설계되어 있는데, 비정형 텍스트 로그는 파싱 비용을 크게 높인다.

Java 생태계에서도 동일한 문제가 반복된다. Logback을 쓰는 팀, Log4j2를 쓰는 팀, 심지어 팀 내에서도 logback.xml 설정이 프로젝트마다 다른 경우가 흔하다. MDC(Mapped Diagnostic Context) 활용 여부, 로그 레벨 정책, 파일 로테이션 전략 등이 표준화되지 않으면 각 프로젝트를 온보딩할 때마다 동일한 맥락 파악 비용이 발생한다.

표준화 설계 시 고려해야 할 핵심 요소

해당 라이브러리가 단일 get_logger 호출로 해결한 문제들을 Java 관점에서 번역하면 다음과 같다.

  • 구조화된 JSON 출력: Logback의 logstash-logback-encoder 같은 JSON 인코더를 기본값으로 채택해, 별도 설정 없이도 ELK 스택에 바로 연동 가능한 포맷을 출력
  • 로테이션 정책: RollingFileAppender에 크기 기반·날짜 기반 조합 정책을 표준화해 디스크 관리 이슈를 사전 차단
  • 런타임 의존성 최소화: 공통 로깅 모듈이 불필요한 외부 의존성을 끌어들이면 오히려 충돌 원인이 됨
// 표준화 전: 프로젝트마다 제각각
Logger log = LoggerFactory.getLogger(MyService.class);
log.info("처리 완료: " + userId); // 문자열 연결, 구조화 없음

// 표준화 후: 공통 설정 기반 구조화 로깅
log.info("처리 완료", kv("userId", userId), kv("duration", elapsed));

공통 로깅 설정을 별도 내부 라이브러리로 분리하고, 각 서비스는 이를 의존성으로 추가하는 방식이 실무에서 효과적이다. Spring Boot의 spring-boot-starter 패턴처럼, 로깅 스타터를 내부 아티팩토리에 배포하면 신규 프로젝트 시작 시 설정 비용이 거의 0에 수렴한다.

충분한 고통 없이는 올바른 추상화가 나오지 않는다

이 이야기에서 기술적 내용만큼 중요한 것이 있다. 저자는 2년, 100개 이상의 프로젝트를 경험한 후에야 비로소 올바른 추상화가 무엇인지 명확해졌다고 말한다. 너무 이른 표준화는 잘못된 가정을 굳혀버리는 위험이 있다. 첫 번째 프로젝트에서 만든 공통 모듈이 다섯 번째 프로젝트에서는 오히려 족쇄가 되는 경험은 4년 이상 된 개발자라면 낯설지 않을 것이다.

PyPI 배포라는 행위 자체도 시사하는 바가 있다. "이 프로젝트에서 동작하는가"가 아니라 "다른 누군가도 쓸 수 있는가"를 묻는 순간, 설계의 질이 달라진다. 내부 공통 모듈을 만들 때도 이 질문을 던지는 습관이 모듈의 범용성과 완성도를 높인다.

정리

  • 프로젝트가 누적될수록 로깅 비표준화의 마찰 비용은 기하급수적으로 증가하며, 조기에 공통 설정 라이브러리로 표준화하는 것이 실질적인 생산성 차이를 만든다
  • 구조화된 JSON 출력, 일관된 로테이션 정책, 최소 의존성은 로깅 표준화의 세 가지 핵심 축이다
  • 올바른 추상화는 충분한 실무 경험 후에 나온다; 이른 표준화보다 반복에서 패턴을 발견한 뒤 추상화하는 순서가 더 견고한 결과를 만든다
Source
Dev.to
원문 보기 →
← 목록으로 돌아가기