실전 로깅과 모니터링: 장애 대응에서 배운 5가지 교훈
내가 로깅과 모니터링의 중요성을 뼈저리게 깨달은 건, 새벽 3시에 터진 장애 때였어요. 알림이 안와서 출근해서야 장애를 발견했습니다. 사용자 불만은 이미 폭주한 뒤였고요. 그때부터 진짜 로깅과 모니터링을 제대로 공부하기 시작했습니다. 오늘은 그동안 겪은 삽질과 교훈을 공유할게요.
1. 로그는 그냥 찍지 마라, 구조화하라
예전 회사에서는 System.out.println("에러 발생: " + e.getMessage()) 이런 식으로 로그를 찍었습니다. 개발자마다 형식이 달라서 "문제 생겼음" 이런 로그도 있고, "2026-07-26 10:30:00 ERROR 뭔가 터짐" 이런 로그도 있고 난리였어요. 장애나면 로그 파일 열어서 ctrl+F로 일일이 찾는게 일상이었습니다. 어느날 새벽에 서버가 뻗었는데 로그가 너무 개판이라 원인 파악에 3시간이나 걸렸어요.
그때 도입한게 구조화 로그(Structured Logging)입니다. JSON 형식으로 timestamp, level, logger, message, requestId, userId, duration 같은 필드를 강제로 넣도록 표준을 만들었어요. Elasticsearch에 바로 밀어넣을수 있게요. 예를 들면 {"timestamp":"2026-07-26T10:30:00Z","level":"ERROR","logger":"OrderService","message":"주문 생성 실패","requestId":"req-123","userId":"user-456","duration":3500} 이런식입니다. 이렇게 바꾸고 나니 ELK에서 검색이 엄청 편해졌어요. "최근 1시간 동안 3초 이상 걸린 주문 실패 로그만 보여줘" 같은 쿼리가 가능해졌습니다.
2. 알림은 진짜 필요한때만 울려라
모니터링 구축할때 가장 많이 하는 실수 중 하나가 "일단 다 알림 걸자" 입니다. 저도 그랬어요. CPU 80% 넘으면 알림, 메모리 70% 넘으면 알림, 디스크 60% 넘으면 알림... 근데 결과는 어땠을까요? 하루에 알림이 200개 넘게 왔습니다. 처음 며칠은 다 확인하다가 나중에는 전부 무시하게 되더라고요. 진짜 중요한 장애 알림도 묻혀서 못본적이 한두번이 아니었습니다.
지금은 알림에 계층을 두고 있습니다. P0은 서비스 다운이나 결제 장애같이 즉시 대응해야하는거, P1은 일부 사용자 영향이 있는거, P2는 주시가 필요한 수준. P0만 24시간 즉시 연락가고 P1은 업무시간 내 대응, P2는 주간 리포트로만 받습니다. 알림이 확 줄어드니까 진짜 긴급한 상황에 집중할수 있게 됐어요. 그리고 알림에는 반드시 "무엇이 어떻게 잘못됐고, 누가 확인해야 하는지"를 명확히 적어야 합니다. 그냥 "CPU HIGH"라고만 적혀있으면 아무도 안움직여요.
3. 분산 추적은 선택이 아니라 필수다
마이크로서비스 아키텍처 쓰면 A 서비스에서 시작된 요청이 B, C, D 서비스를 거쳐가는게 기본입니다. 근데 각 서비스 로그를 개별로 보면 이 요청이 어떻게 흘러갔는지 전혀 알수가 없어요. "A에서는 성공했는데 왜 D에서 실패했지?" 같은 디버깅이 거의 불가능에 가까웠습니다.
이걸 해결해준게 분산 추적(Distributed Tracing)입니다. OpenTelemetry 표준을 도입해서 모든 서비스에 traceId를 전파하도록 했어요. 요청이 들어오면 최초 진입점에서 traceId를 생성하고, 이걸 HTTP 헤더나 메시지 큐의 메타데이터에 실어서 전파합니다. 각 서비스는 자기 로그에 이 traceId를 포함해서 남기고요. Jaeger나 Zipkin 같은 도구로 대시보드를 만들면 하나의 요청이 서비스별로 얼마나 걸렸는지, 어디서 병목이 발생했는지가 한눈에 보입니다. 실제로 이거 도입하고 나서 성능 병목 찾는 시간이 1/10로 줄었어요. "주문 API가 느리다"는 말 대신 "주문 API 중 결제 모듈 호출 부분에서 2초가 소요됩니다"라고 정확히 짚을수 있게 됐습니다.
4. 메트릭은 비즈니스 관점에서도 봐야 한다
처음에는 서버 메트릭(CPU, 메모리, 디스크)만 수집했어요. 근데 이걸로는 비즈니스 상황을 전혀 알수 없었습니다. 서버는 멀쩡한데 사용자가 "서비스 안터지는데 왜 안들어가지?" 하는 경우가 있거든요. 예를 들어, 외부 결제사 API가 느려져서 응답이 30초 걸리는데 서버 CPU는 10%였던적이 있습니다.
그래서 지금은 Prometheus랑 Grafana로 수집하는 메트릭을 크게 세 가지로 나눴습니다. 인프라 메트릭(CPU, 메모리, 디스크, 네트워크), 애플리케이션 메트릭(응답시간, 초당 요청수, 에러율, 액티브 커넥션 수), 비즈니스 메트릭(주문수, 결제 성공률, 회원가입 전환율, 일간 활성 사용자 수). 특히 비즈니스 메트릭은 대시보드에서 가장 눈에 띄는 곳에 배치했습니다. 결제 성공률이 갑자기 떨어지면 인프라는 멀쩡해도 뭔가 문제가 생겼다는 신호니까요. 실제로 이 대시보드 덕분에 외부 PG사 장애를 5분만에 감지하고 대응할수 있었습니다.
5. 온콜(On-Call) 문화와 포스트모템이 진짜 중요하다
아무리 좋은 모니터링 시스템을 갖춰도 사람이 제대로 대응하지 않으면 의미가 없습니다. 저희 팀은 돌아가면서 온콜 당번을 서는데, 처음에는 "장애나면 연락가고 고치면 끝"이었어요. 근데 똑같은 장애가 반복됐습니다. A라는 장애 터지고 "다시는 안그럴게" 하고 넘어가면 한달 뒤에 같은 장애가 또 터지고...
그래서 도입한게 블레이멀리스(Blame-less) 포스트모템 문화입니다. 장애가 발생하면 "누구 잘못인지"를 찾는게 아니라 "왜 이런일이 발생했고, 시스템적으로 어떻게 예방할건지"를 논의합니다. 포스트모템 문서에는 장애 발생 타임라인, 영향 범위, 근본 원인, 재발 방지 대책을 기록합니다. 그리고 이 문서를 전사에 공유합니다. 중요한건 "처벌하지 않는다"는 원칙이에요. 실수를 인정하고 공유할수 있는 문화가 없으면 아무리 좋은 도구를 도입해도 소용없습니다. 실제로 포스트모템 도입 후 반년간 같은 원인의 장애 재발이 70% 감소했습니다.
로깅과 모니터링은 "다 해놓으면 끝"이 아니라 계속 발전시켜나가야 하는 영역입니다. 지금도 우리팀은 매주 모니터링 대시보드를 리뷰하면서 불필요한 알림은 제거하고, 새로운 비즈니스 지표는 추가하고 있습니다. 장애는 언제든 발생할수 있습니다. 중요한건 장애 자체가 아니라, 얼마나 빠르게 감지하고 대응하느냐, 그리고 같은 실수를 반복하지 않느냐입니다.