운영에서 살아남는 스프링 앱은 로그와 메트릭이 먼저다

맞습니다. 운영에서 스프링은 기능보다 관측 가능성(Observability) 이 먼저입니다.
로그/메트릭 없으면 장애는 “추측”으로만 대응하고, 그 순간부터 운영은 지옥입니다.

---

1) 운영 생존 우선순위

1. 로그: “무슨 일이 일어났는지” 사건 기록
2. 메트릭: “지금 상태가 어떤지” 수치 추세
3. 트레이싱: “어디서 느려지는지” 경로(있으면 좋음)

---

2) 스프링 운영에서 반드시 깔아야 하는 로그(최소 세트)

A. 요청 단위 상관관계 (Correlation)

• requestId / traceId를 모든 로그에 찍기 (MDC)
• API 한 번 호출이 WAS → DB → 외부연계를 타도 한 묶음으로 보이게

B. 구조화 로그

• 문자열 덕지덕지 말고 JSON 로그로 쌓기
• 운영/분석은 grep가 아니라 필터/집계로 합니다.

C. 예외 로그 규격

• errorCode, cause, httpStatus, userId(있으면) 같이 필수 필드 고정
• “NullPointerException”만 남기면 아무 의미 없습니다.

---

3) 메트릭은 “장애를 미리 알게 해주는 계기판”

스프링 부트라면 실무에서 이거부터 봅니다.

A. RED(요청 중심)

• Rate: TPS
• Errors: 4xx/5xx 비율
• Duration: p95/p99 응답시간

B. USE(자원 중심)

• CPU / 메모리 / GC
• Thread 풀
• DB 커넥션 풀(active/idle/wait)
• 외부 API 타임아웃/리트라이 횟수

운영 장애의 절반은 DB 커넥션 풀 + 타임아웃에서 시작합니다.

---

4) Spring Boot 기준 “바로 적용 가능한” 구성 방향

• Actuator + Micrometer로 메트릭 노출
• 로그는
  • MDC(traceId/requestId)
  • 요청/응답 요약 로깅(민감정보 마스킹)
  • 에러는 표준 에러 포맷 + errorCode

이 조합이 SI 운영에서 가장 ROI 높습니다.

---

5) 실무 한 줄 요약 (르무엘님 문장 강화 버전)

운영에서 살아남는 스프링 앱은 기능보다 관측 가능성이 먼저다.
로그가 없으면 원인 분석이 아니라 책임공방이 시작된다.