Logging
한 줄 정의
Logging은 요청 처리 중 발생한 중요한 상태 변화, 의사결정, 실패 원인을 나중에 추적할 수 있도록 기록하는 것이다.
실무에서 왜 문제 되는가
- 장애 당시 로그가 없으면 원인을 재현하거나 추측해야 한다.
- 로그가 너무 많으면 비용이 커지고 중요한 신호를 찾기 어렵다.
- 민감정보가 로그에 남으면 보안 사고가 될 수 있다.
- request id가 없으면 분산된 로그를 하나의 요청 흐름으로 묶기 어렵다.
- 예외 로그만 있고 비즈니스 상태가 없으면 왜 실패했는지 알기 어렵다.
동작 원리
- 요청 진입 시 request id나 trace id를 생성하거나 전달받는다.
- 주요 처리 단계에서 필요한 상태와 결과를 구조화해 기록한다.
- 예외 발생 시 원인, 영향, 복구 가능성을 구분해 기록한다.
- 로그 수집기가 로그를 중앙 저장소로 전달한다.
- 장애 분석 시 id, endpoint, error code, 시간 범위로 검색한다.
실무 판단 기준
| 상황 | 로그 수준 | 이유 |
|---|---|---|
| 정상 요청 요약 | INFO | 흐름과 처리 결과를 남긴다 |
| 재시도 가능 실패 | WARN | 즉시 장애는 아니지만 관찰이 필요하다 |
| 사용자 영향 실패 | ERROR | 알림과 장애 분석 대상이다 |
| 상세 내부 상태 | DEBUG | 운영 기본 로그로 남기기에는 비용이 크다 |
| 민감정보 포함 가능 | 기록 금지 또는 마스킹 | 공개 저장소와 운영 로그 모두 위험하다 |
자주 나는 실수
e.getMessage()만 남기고 stack trace나 컨텍스트를 남기지 않는다.- user id, token, raw request body 같은 민감정보를 그대로 남긴다.
- 로그 메시지를 문자열로만 남겨 검색과 집계가 어렵다.
- 같은 예외를 여러 계층에서 중복으로 남긴다.
- 성공 로그는 없고 실패 로그만 있어 정상 흐름과 비교하지 못한다.
확인 방법
- 테스트: 실패 케이스에서 원인을 찾는 데 필요한 필드가 남는지 확인한다.
- 로그: trace id, endpoint, status, elapsed time, error code를 확인한다.
- 메트릭: 로그량, error log rate, ingestion 실패율을 확인한다.
- 보안 점검: 토큰, 비밀번호, 주민번호, 이메일 같은 민감정보가 없는지 확인한다.
장점과 한계
| 장점 | 한계 |
|---|---|
| 구체적인 실패 원인을 확인할 수 있다 | 너무 많으면 비용과 노이즈가 커진다 |
| 장애 당시 상황을 재구성할 수 있다 | 로그만으로 전체 영향 범위는 보기 어렵다 |
| 비즈니스 이벤트 분석에 도움이 된다 | 민감정보 관리가 필요하다 |
짧은 예제
log.info("order create completed traceId={} orderId={} elapsedMs={}",
traceId, orderId, elapsedMs);
log.warn("payment retry traceId={} orderId={} attempt={} reason={}",
traceId, orderId, attempt, reason);운영 로그는 사람이 읽을 수 있으면서도 필드 기반 검색이 가능해야 한다.
핵심 요약
로그는 장애 당시의 구체적인 상태와 실패 원인을 확인하기 위한 기록이다.
좋은 로그는 request id, endpoint, 상태, 결과, elapsed time을 포함한다.
운영 로그에는 민감정보를 남기지 않고 필요한 경우 마스킹한다.
ERROR만 남기기보다 정상 흐름과 실패 흐름을 비교할 수 있어야 한다.
로그는 원인 분석에는 강하지만 전체 영향 판단은 메트릭과 함께 봐야 한다.
꼬리 질문
- 좋은 운영 로그에는 어떤 필드가 들어가야 하는가?
- 로그에 민감정보가 남으면 어떤 문제가 생기는가?
- 로그와 메트릭의 역할은 어떻게 다른가?