logs, metrics, traces — 셋 다 못 할 때 순서

세 개를 동시에 잘 하는 팀은 없다

솔직히 말하면, logs·metrics·traces를 처음부터 균형 있게 운영하는 팀을 나는 본 적이 없다. 항상 하나가 엉망이고, 나머지 둘이 그걸 보완하거나 못 보완하거나 둘 중 하나다.

문제는 리소스가 한정돼 있을 때 무엇을 먼저 포기하느냐다. 이 선택을 흐지부지 미루면 세 개가 전부 반쪽짜리가 된다. 내가 그 꼴을 직접 경험했다.

logs 먼저. 이건 협상 불가다

2026년 기준, 로그가 없는 장애는 추측 게임이다. 메트릭이 스파이크를 보여줘도 “왜”를 대답하지 못한다. 트레이스가 레이턴시 문제를 잡아줘도 그 시점에 서버가 무슨 에러를 던졌는지는 로그에만 있다.

팀에서 API 게이트웨이 오류율이 갑자기 12%로 튄 적이 있었다. 메트릭 알림은 30초 만에 왔다. 그런데 로그 수집 파이프라인이 한 시간 지연 상태였고, 실시간 로그는 사실상 없었다. 그 한 시간 동안 내가 한 건 kubectl logs —previous 로 죽은 컨테이너 잔해를 뒤지는 것뿐이었다. 결국 원인은 외부 서비스 인증 토큰 만료였는데, 그걸 찾는 데 2시간 걸렸다. 로그 한 줄이 있었으면 5분이었을 사건이다.

구조화 로그(JSON)부터 강제해야 한다. grep 으로 파싱하는 팀은 장애 때 결국 사람이 눈으로 읽는다. 필드가 없으면 쿼리도 없다. 우리는 severity, trace_id, service_name 세 필드를 필수 스키마로 박아두고 CI에서 검사한다.
보존 기간을 최소 30일로 잡아야 한다. 7일로 운영하다가 “저번주 목요일 새벽 건” 분석 요청이 오면 아무것도 없다. 실제로 그런 요청이 고객사 감사에서 왔을 때 30일치 있어서 살았다.
로그 볼륨 비용이 무서우면 DEBUG 레벨을 기본 OFF 하고 feature flag 로 켜라. 전체를 다 버리는 것과는 다르다.

metrics는 두 번째, 단 SLO 하나만

메트릭을 잘 하려다 대시보드 40개 만들고 아무도 안 보는 팀이 너무 많다. 막상 장애 나면 “어느 패널 봐야 해요?”가 먼저 나온다.

처음부터 SLO 하나만 골라서 그것에 집중하는 게 훨씬 낫다. 우리는 p99 레이턴시 800ms를 SLO로 박고, 그 숫자 하나만 메인 대시보드 맨 위에 뒀다. 나머지 패널은 전부 그 숫자가 깨졌을 때 원인을 파고들기 위한 보조 역할이다.

알림 피로는 메트릭 운영의 가장 큰 적이다. 이전에 알림 채널에 하루 80건 넘게 찍혔던 적이 있었다. 팀이 두 달 만에 알림을 무시하기 시작했고, 진짜 장애도 30분간 묻혀 있었다. 알림은 SLO breach 와 error budget 소진율 두 개만 남기고 나머지는 전부 recording rule 로 내렸다.
인프라 메트릭(CPU, 메모리)은 마지막에 본다. 중요하지 않다는 게 아니라, 애플리케이션 레이어 메트릭이 먼저 이상 신호를 준다. CPU가 80% 찍힌다고 사용자가 느끼는 게 아니다.

traces는 세 번째, 그러나 MSA 환경에선 예외

모놀리스라면 traces는 정말 마지막이어도 된다. 스택 트레이스와 로그만으로 대부분의 원인을 찾는다.

단, 서비스가 4개 이상 얽히는 순간부터 로그만으로는 “어느 서비스가 레이턴시를 먹었나”를 추적하는 게 고통스럽다. 각 서비스 로그를 시간순으로 수동 교차 조회하는 건 사건 당 30~40분 뺏긴다. trace_id 하나로 Jaeger에서 워터폴 그림 한 장 보는 것과 차원이 다르다.

트레이스를 뒤늦게 도입할 때 가장 큰 허들은 전파(propagation)다. HTTP 헤더에 W3C Trace Context를 전파하지 않으면 트레이스가 서비스 경계에서 끊긴다. 이걸 레거시 서비스 12개에 소급 적용했을 때, 실제 공수가 2주 걸렸다. 처음부터 라이브러리 설정 한 줄로 할 수 있었던 건데.
샘플링 전략을 처음부터 정해야 한다. 전수 수집은 비용을 금방 죽인다. 우리는 오류 응답은 100%, 정상 응답은 1% tail-based로 가져가고 있다.

세 개가 연결되지 않으면 반쪽이다

가장 치명적인 실수는 세 개를 각자 섬으로 운영하는 것이다. logs에 trace_id 없고, metrics 알림에서 로그 링크 없고, 트레이스에서 에러 로그로 점프가 안 되면 도구가 세 개 있어도 장애 때는 탭 세 개를 수동으로 오가는 신세가 된다.

이 연결이 없으면 MTTR이 줄지 않는다. 우리가 실제로 측정해보니, trace_id를 로그에 심기 전과 후의 평균 장애 원인 파악 시간이 38분에서 11분으로 줄었다. 도구가 더 늘어서가 아니라 연결됐기 때문이다.

다음 한 가지

다음 회고엔 “SLO 알림 두 개만 남기기로 한 거, 실제로 줄였나” 한 줄부터 쓴다.

🛒 이 글과 어울리는 추천 상품

위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.