로그와 메트릭의 차이: 운영 중인 서비스를 어떻게 관찰할 것인가 빠른 답 로그는 개별 사건의 맥락을 남기고, 메트릭은 시간에 따른 상태 변화를 숫자로 요약한다. 이상 징후 감지와 알림은 메트릭이 빠르고, 원인 분석은 로그가 더 깊은 단서를 준다. System.out.println 만으로는 로그 레벨, 포맷, 필터링, 수집 연동, 마스킹을 안정적으로 관리하기 어렵다. 운영 품질은 로그와 메트릭을 따로 도입했는지가 아니라, 탐지부터 분석과 재발 방지까지 이어지는지로 판단하는 편이 좋다. 목차 한눈에 비교 시간 흐름으로 이해하기 왜 운영 품질의 기준선인가 로그와 메트릭이 헷갈리는 이유 스택 중립 기준선 장애 대응에서 함께 쓰는 방식 설정 예시 운영 확인 예시 실제로 막히는 지점 테스트와 품질 게이트 운영 점검 순서 한눈에 비교 목적 로그는 “무슨 일이 있었는가”를 설명하고, 메트릭은 “상태가 얼마나 변했는가”를 보여준다. 단위 로그는 요청, 예외, 결제 실패 같은 개별 이벤트 단위이고, 메트릭은 요청 수, 오류율, 지연 시간 같은 집계 단위다. 형태 로그는 문자열이나 구조화된 이벤트 기록이고, 메트릭은 이름, 숫자 값, 라벨, 시계열로 구성된다. 강점 로그는 요청 맥락과 예외 추적에 유리하고, 메트릭은 추세 파악, 임계치 알림, 대시보드 구성에 유리하다. 비용 로그는 상세할수록 저장량과 검색 비용이 커지고, 메트릭은 라벨 조합이 늘어날수록 시계열 수가 급격히 증가한다. 사용 시점 메트릭은 “지금 이상한가”를 먼저 알려주고, 로그는 “왜 이상한가”를 좁힐 때 쓰인다. 시간 흐름으로 이해하기 첫 요청 발생 애플리케이션은 요청 ID, 경로, 사용자 범주, 처리 시작 시각 같은 로그 맥락을 만든다. → 요청 처리 누적 성공 수, 실패 수, 응답 시간, 큐 적체량 같은 값이 메트릭으로 쌓인다. → 관찰 윈도우 계산 모니터링 시스템은 1분, 5분 같은 구간으로 오류율, 평균, 백분위 지연 시간을 계산한다. → 임계치 도달 오류율이나 지연 시간이 기준을 넘으...