chore: dev 프로파일의 SQL 콘솔 출력 제거 - #151

[tnals0924]

#️⃣연관된 이슈

• Closes chore: dev 프로파일의 SQL 콘솔 출력 제거 #151

🎯 해결하려는 문제가 무엇인가요?

application-dev.yml 이 show-sql: true + format_sql: true 로 동작하고 있습니다.

show-sql 은 로거를 거치지 않습니다. Hibernate 의 SqlStatementLogger 는 이 옵션이 켜지면 org.hibernate.SQL 로거와 별개로 System.out 에 직접 씁니다. 그래서

• 로그 레벨로 끌 수 없습니다. 끄려면 설정을 바꿔 재배포해야 합니다.
• 비동기 appender 로 돌릴 수 없습니다. System.out 은 동기화된 스트림이라 요청 스레드들이 출력 락에서 직렬화됩니다.
• 포맷·목적지·보존정책 등 Logback 설정이 하나도 적용되지 않습니다.

format_sql 은 쿼리마다 포매팅 비용을 붙입니다. BasicFormatterImpl 이 매 실행마다 SQL 문자열을 파싱해 들여쓰기·줄바꿈을 넣습니다. 출력이 꺼져 있으면 수행되지 않으므로 show-sql 과 함께만 의미가 있습니다.

❓ 왜 해결해야 하나요?

dev 는 부하 테스트 대상 환경입니다(#140). 요청마다 SQL 을 동기로 stdout 에 뱉는 설정이 기본으로 켜져 있으면, 측정하려는 대상이 아니라 로깅 경합을 재게 됩니다.

실제로 dev(스테이징) 서버에 GET /admin/members/payers 부하를 걸어 측정한 결과, 이 설정만으로 p95 가 452ms → 240ms 로 줄었습니다 (100 VU / 5분). payer 테이블이 2천 건 규모라 쿼리 자체는 1ms 미만인데, 응답시간의 절반가량이 SQL 을 stdout 에 쓰는 데 들어가고 있었습니다.

일상적으로도 SQL 로깅을 아예 못 끄는 것보다 레벨로 켜고 끌 수 있는 편이 낫습니다.

⭐ 어떻게 해결했나요?

show-sql 과 format_sql 을 끄고, 대신 SQL 이 필요할 때 올릴 수 있는 로거 레벨을 명시해 두었습니다.

  jpa:
    properties:
      hibernate:
        # show-sql 과 함께만 의미가 있고, 켜면 쿼리마다 포매팅 비용이 붙는다
        format_sql: false
    # show-sql 은 로거를 거치지 않고 System.out 에 직접 쓴다.
    # 레벨로 끌 수도, 비동기 appender 로 돌릴 수도 없고 요청 스레드들이 출력 락에서 직렬화된다.
    # SQL 을 봐야 할 때는 아래 logging.level 을 debug 로 올린다 (로거 경로라 제어가 된다).
    show-sql: false

logging:
  level:
    org.hibernate.SQL: info                # debug 로 올리면 실행 SQL 출력
    org.hibernate.orm.jdbc.bind: info      # trace 로 올리면 바인딩 파라미터까지 출력

logging.level 항목은 지금 info 라 아무것도 출력하지 않습니다. 켜는 방법을 설정 파일 안에 남겨두는 게 목적입니다.

🧩 이 PR의 한계 & 트레이드오프

문제의 절반만 해결합니다. p95 가 240ms 로 내려왔지만 2천 건 테이블 조회로는 여전히 큽니다. LoggingFilter 가 요청마다 남기는 한 줄이 아직 같은 경로로 나갑니다. 이 레포엔 logback-spring.xml 이 없어 Spring Boot 기본 CONSOLE appender 를 쓰는데, Logback 의 ConsoleAppender 는 OutputStreamAppender 를 상속해 write 가 동기화돼 있습니다. 즉 출력량만 줄었을 뿐 톰캣 스레드들이 한 스트림에서 직렬화되는 구조는 그대로입니다. 비동기 appender 도입은 별도 이슈로 진행합니다.

SQL 을 보려면 한 단계가 늘어납니다. 이전엔 dev 로 띄우면 바로 보이던 게, 이제는 logging.level.org.hibernate.SQL 을 debug 로 올려야 합니다. dev 는 공유 환경이라 기본으로 켜 두는 쪽이 손해가 크다고 봤습니다.

⛓️ 기존 기능에 미치는 영향

애플리케이션 동작에는 영향이 없습니다. 로깅 출력만 달라집니다.

application-local.yml 은 건드리지 않았습니다. 개발자 개인 머신이라 SQL 이 바로 보이는 편이 유용하고, 공유 환경이 아니라 출력 경합이 문제가 되지 않습니다. 부하 테스트는 dev 프로파일로 배포된 스테이징 서버를 대상으로 하므로 측정에도 영향이 없습니다.

application-prod.yml 도 건드리지 않았습니다. 이미 show-sql: false 입니다. format_sql: true 가 남아 있지만 출력이 꺼져 있어 실제로 수행되지 않습니다.

🔀 Edge Case & 실패 시나리오

없습니다. 로깅 설정 변경이라 실패 경로가 없습니다.

YAML 구조는 파싱해서 확인했습니다. logging 블록을 루트 레벨에 두었고 spring.servlet 등 기존 키들의 계층이 유지됩니다.

📋 검토한 대안과 선택 이유

show-sql: false + org.hibernate.SQL: debug 로 로거 경로만 켜 두는 방법 — 출력은 유지하면서 Logback 제어를 얻습니다. 다만 로깅 비용 자체는 그대로 남아 부하 테스트 잡음이 사라지지 않습니다. dev 의 기본값은 꺼진 상태가 맞다고 봤습니다.

logback-spring.xml 을 두고 비동기 appender 로 감싸는 방법 — 출력을 유지하면서 요청 스레드에서 I/O 를 떼어낼 수 있습니다. 다만 지금 이 레포엔 Logback 설정 파일 자체가 없어서, 로깅 정책 전반을 정하는 별도 작업으로 보는 게 맞다고 판단했습니다.

local 까지 같이 끄는 방법 — 어느 프로파일로 측정했든 변수가 사라진다는 장점이 있지만, 로컬 개발 중 SQL 을 보려면 매번 레벨을 올려야 해서 일상 개발 경험을 깎습니다. dev 로 범위를 좁혔습니다.

💬 리뷰 포인트

• [c] dev 에서 SQL 이 안 보이게 되는 걸 감수할 수 있는지 봐주세요. 필요할 때 logging.level.org.hibernate.SQL 을 debug 로 올리면 되지만, 재배포가 필요합니다. 불편하면 Actuator 로 런타임에 레벨을 바꾸는 방향도 있습니다.
• [c] logging.level 을 info 로 명시해 둔 게 과하다고 보시면 지우고 주석으로만 남겨도 됩니다. 설정 파일 안에 켜는 방법을 남겨두는 의도입니다.
• [a] application-prod.yml 의 format_sql: true 는 죽은 설정입니다. 정리하려면 별도로 하겠습니다.

🧪 테스트

부하 테스트 — dev(스테이징) 서버 대상, GET /admin/members/payers, 100 VU / 5분

	p95
before	452ms
after	240ms

payer 테이블은 2천 건 규모입니다.

설정 검증 — YAML 파싱으로 구조 확인 (루트 키 계층, spring.servlet 유지, show-sql/format_sql 값).