콘텐츠로 이동

4-2. 로그, 메트릭, 트레이싱의 차이

로그(logging), 메트릭(metrics), 트레이싱(tracing)은 운영 품질을 서로 다른 단위로 보는 관측 신호입니다. 4-2에서는 세 도구 이름을 외우기보다, “개별 요청을 볼 때”, “전체 변화를 볼 때”, “처리 흐름을 따라갈 때” 어떤 신호가 필요한지 구분합니다.

이 문서를 읽을 때는 다음 기준을 중심으로 확인합니다.

  • 로그(logging): 요청 하나의 상세 이벤트 확인
  • 메트릭: 여러 요청을 집계한 운영 상태 확인
  • 트레이싱(tracing): 하나의 요청이 여러 처리 단계를 지나가는 흐름 확인
  • 조합 관점: 대시보드에서 이상 신호를 보고 로그로 원인을 좁히는 흐름 확인

4-2-1. 로그(logging) 개념

로그(logging)는 개별 이벤트를 기록합니다. AI 서비스에서는 하나의 예측 요청마다 request_id, trace_id, model_version, score, threshold, prediction, validation_failure, latency_ms를 남깁니다.

OpenTelemetry Signals 관점에서 로그는 특정 시점에 발생한 이벤트를 설명하는 신호입니다. QA에게 로그는 사후 분석의 기본 근거입니다. 대시보드(dashboard)가 “무언가 변했다”를 알려준다면, 로그는 “어떤 요청에서 어떤 값이 어떻게 기록되었는가”를 보여줍니다.

로그는 “무슨 일이 있었는가”를 가장 자세히 보여줍니다. 메트릭(metric)이나 대시보드에서 이상 신호를 발견한 뒤, 실제 원인을 좁힐 때 로그를 사용합니다. 예를 들어 검증 실패(validation failure)가 증가했다면 로그에서 어떤 필드(field)가 누락되었는지 확인해야 합니다.

로그 필드 QA 관점의 의미
request_id 특정 요청을 다시 찾는 기준
trace_id 여러 처리 단계를 하나의 흐름으로 묶는 기준
model_version 어떤 모델이 응답했는지 확인
score 관심 클래스(Positive class) 가능성 확인
threshold 점수(score)가 예측(prediction)으로 바뀐 기준을 확인
prediction 최종 예측 결과를 확인
validation_failure 입력 검증 실패 여부를 확인
latency_ms 서비스 응답 시간을 확인

활용 가능한 로그는 사람이 읽을 수 있을 뿐 아니라 검색과 집계가 가능해야 합니다. 그래서 실습에서는 JSONL 구조화 로그를 사용합니다. 문자열 로그에 “prediction high_risk”처럼 적어두면 검색은 가능할 수 있지만, 안정적인 집계나 패널(panel) 생성에는 불리합니다.

QA는 로그가 너무 많아지는 것도 경계해야 합니다. 개인정보나 불필요한 원본 페이로드(payload)를 그대로 남기면 보안과 운영 비용 문제가 생길 수 있습니다. 실습에서는 품질 판단에 필요한 최소 필드를 중심으로 기록합니다.

4-2-2. 메트릭 개념

메트릭은 여러 이벤트를 집계한 숫자입니다. 로그가 원인 추적에 강하다면, 메트릭은 전체 상태를 빠르게 보는 데 강합니다. 운영자는 대시보드에서 메트릭을 보고 이상 징후를 빠르게 발견합니다.

메트릭은 의사결정의 출발점이지 결론이 아닙니다. 오류율(error rate), 지연 시간(latency), 평균 점수(score average), high_risk 비율 같은 값은 변화를 빠르게 보여주지만 원인을 직접 말해 주지는 않습니다. 따라서 메트릭은 반드시 기준선(baseline), 시간대, 배포 이력, 로그 필드(log field)와 함께 읽어야 합니다.

메트릭 의미 해석
ai_quality_request_total 요청 수 트래픽(traffic) 규모와 장애 영향 범위 확인
ai_quality_error_total 오류 수 API 실패 증가 여부 확인
ai_quality_validation_failure_total 입력 검증 실패 수 클라이언트 페이로드(client payload) 또는 입력 데이터 문제 확인
ai_quality_latency_average_ms 평균 지연 시간 서비스 지연 증가 확인
ai_quality_score_average 전체 이벤트 평균 점수 서비스 영향 범위에서 점수 변화 후보 확인
ai_quality_high_risk_rate 전체 이벤트 high_risk 예측 비율 전체 요청 기준 예측 분포(prediction distribution) 변화 확인
ai_quality_valid_score_average 검증 실패를 제외한 평균 점수 유효 요청의 모델 응답 변화 확인
ai_quality_valid_high_risk_rate 검증 실패를 제외한 high_risk 비율 유효 요청 기준 예측 분포 변화 확인

메트릭은 요약값이므로 원인을 직접 알려주지는 않습니다. 예를 들어 평균 점수가 증가했다는 사실만으로 입력 분포가 바뀌었다고 확정할 수 없습니다. 모델 버전(model_version)이 바뀌었거나 임계값(threshold)이 바뀌었거나 특정 요청 그룹이 늘었을 수도 있습니다.

전체 이벤트 지표와 유효 요청 지표는 목적이 다릅니다. 전체 이벤트 지표는 서비스 관점의 영향 범위를 보여 주고, 유효 요청 지표는 검증 실패를 제외한 모델 응답 경향을 보여 줍니다. 검증 실패가 증가한 상황에서는 두 값을 나란히 보고 “서비스 문제”와 “모델 응답 변화”를 분리해서 보고해야 합니다.

따라서 메트릭은 로그와 함께 사용해야 합니다. 메트릭으로 “무엇이 달라졌는지”를 보고, 로그로 “왜 달라졌는지”를 확인합니다. 이 순서가 운영 QA에서 현실적인 분석 흐름입니다.

4-2-3. 트레이싱(tracing) 개념

트레이싱(tracing)은 하나의 요청이 여러 컴포넌트를 지나가는 흐름을 추적합니다. 예측 API가 단순히 모델만 호출한다면 트레이싱이 과해 보일 수 있지만, 실제 AI 서비스는 인증, feature store, model server, logging pipeline, downstream API를 거칠 수 있습니다.

실습에서는 OpenTelemetry 같은 트레이싱 백엔드(tracing backend)를 구축하지 않습니다. OpenTelemetry는 실무에서 자주 쓰이는 트레이싱 생태계 이름으로만 언급합니다. 수업에서는 trace_id를 로그 필드로 남겨 요청(request) 흐름을 연결할 수 있다는 개념을 확인합니다. request_id가 하나의 요청을 식별한다면, trace_id는 여러 이벤트를 하나의 처리 흐름으로 묶는 역할을 합니다.

구분 역할 예시
request_id 개별 요청 식별 normal-0005
trace_id 관련 로그 흐름 식별 normal-trace-0001
스팬(span) 실제 트레이싱(tracing) 도구에서 단계별 작업 API 검증(validation), 모델 추론(model inference)

트레이싱은 특히 “어디에서 시간이 오래 걸렸는가”를 찾는 데 유용합니다. 교육 자료에서는 개념만 간단히 다루고, 실제 실습은 구조화 로그와 request_id 추적에 집중합니다.

4-2-4. AI 서비스에서의 활용 사례

로그(logging), 메트릭, 트레이싱(tracing)은 서로 대체 관계가 아니라 보완 관계입니다. 대시보드에서 메트릭 이상을 발견하고, 로그로 원인을 확인하며, 트레이싱으로 요청 흐름을 따라가는 식으로 사용합니다.

질문 먼저 볼 것 다음 확인
특정 요청이 왜 실패했는가 로그(logs) request_id, validation_failure, status_code
전체 오류가 증가했는가 메트릭 error_total, validation_failure_total
모델 응답 경향이 바뀌었는가 대시보드 score_average, high_risk_rate
설정 배포가 맞는가 로그(logs) model_version, threshold

QA는 하나의 도구만 보지 않습니다. 대시보드에서 이상 신호를 발견하고, 메트릭으로 규모를 확인한 뒤, 로그로 원인 후보를 좁히는 순서가 현실적입니다.

관측 신호는 대시보드, 메트릭, 로그를 순서대로 연결해야 원인 후보를 줄일 수 있습니다. 예를 들어 high_risk 비율이 갑자기 증가했다고 하겠습니다. 먼저 대시보드에서 증가 시점을 확인합니다. 다음으로 메트릭에서 요청 수와 오류 수가 함께 변했는지 봅니다. 그다음 해당 시간대 로그에서 model_version, threshold, score, validation_failure를 확인합니다. 이 흐름을 거쳐야 데이터 문제인지 설정 문제인지 구분할 수 있습니다.