[OpenTelemetry 실전] Day 3: Log 상관관계 - 검색 가능한 사건으로 바꾸기
이 글은 AI(Claude)의 도움을 받아 작성하고, 작성자가 검토·편집했습니다.
서론: 오늘의 문제
로그는 사람이 읽는 문장만이 아니라 trace와 metric을 연결하는 구조화된 사건이다. 기존 로깅 라이브러리를 유지하면서 공통 필드와 민감 정보 정책을 정한다.
1. 구조화 로그의 최소 필드
timestamp, severity, service, environment, event name을 안정된 필드로 둔다. 메시지 문구가 바뀌어도 대시보드와 경보가 깨지지 않도록 event name을 계약으로 관리한다.
2. Trace 상관관계
trace_id와 span_id를 로그 레코드에 주입하면 한 오류에서 전체 호출 경로로 이동할 수 있다. 비동기 스레드나 코루틴에서도 context가 유지되는지 테스트한다.
3. Resource 속성
서비스 이름, 버전, 배포 환경, 인스턴스 정보는 각 로그마다 애플리케이션이 반복 생성하기보다 Resource로 일관되게 부여한다. Collector 보강 시 덮어쓰기 규칙을 정한다.
4. 민감 정보와 크기
토큰, 쿠키, 개인정보, 요청 본문은 기본적으로 기록하지 않는다. 허용 필드 목록과 마스킹을 수집 이전에 적용해 백엔드 도착 후 삭제에 의존하지 않는다.
5. 로그 레벨의 운영 계약
DEBUG를 상시 켜거나 모든 예외를 ERROR로 남기면 비용과 경보 품질이 나빠진다. 레벨별 의미, 샘플링, 일시적 상세 로깅의 만료 절차를 문서화한다.
6. 자주 실패하는 방식
자유 형식 메시지 파싱에 대시보드가 의존하면 문구 변경이 운영 장애가 된다. trace context가 없는 백그라운드 작업은 연관 로그를 찾지 못해 복구 시간이 길어진다.
7. 관측과 검증
상관 가능한 로그 비율, 필드 파싱 실패, 레벨별 유입량, 평균 레코드 크기, 민감 정보 탐지 건수, 저장 비용을 추적한다. 기준값은 정상 시간대와 변경 전후를 비교해 정하고, 점검 결과가 실제 행동으로 이어지는지 정기적으로 확인한다.
실행 흐름
1
2
3
4
5
6
7
8
9
1. 구조화 로그의 최소 필드
↓
2. Trace 상관관계
↓
3. Resource 속성
↓
4. 민감 정보와 크기
↓
5. 로그 레벨의 운영 계약
개별 도구보다 이 순서를 팀의 설계 리뷰와 Runbook에 남기는 것이 중요하다. 상황이 달라져도 판단 근거와 검증 결과가 이어져야 한다.
실전 체크리스트
- 구조화 로그의 최소 필드: 기준과 책임자를 문서화했다.
- Trace 상관관계: 기준과 책임자를 문서화했다.
- Resource 속성: 기준과 책임자를 문서화했다.
- 민감 정보와 크기: 기준과 책임자를 문서화했다.
- 로그 레벨의 운영 계약: 기준과 책임자를 문서화했다.
- 실패 패턴을 재현하고 안전한 복구 경로를 확인했다.
- 핵심 신호를 대시보드와 변경 검증에 연결했다.
참고 자료
다음 글
다음 글에서는 Collector 파이프라인 - 수집과 처리의 경계 만들기를 다룬다.