Developer Knowledge

개발자가 알아야 할 지식: 골든 시그널, 서비스 상태를 네 가지 질문으로 보는 법

지연 시간, 트래픽, 오류, 포화도를 중심으로 운영 지표를 단순하고 실용적으로 잡는 방법을 정리합니다.

2026년 6월 12일 Google SRE

모니터링은 지표를 많이 모으는 일이 아니라, 문제가 생겼을 때 무엇을 먼저 볼지 정하는 일입니다.

왜 개발자가 알아야 하나

서비스가 커질수록 대시보드는 쉽게 복잡해집니다. CPU, 메모리, GC, 큐 길이, DB 커넥션, 캐시 hit rate, 네트워크 재전송률까지 모두 중요해 보입니다. 하지만 장애 순간에 모든 그래프를 동시에 읽을 수는 없습니다.

Google SRE 책에서 말하는 네 가지 골든 시그널은 이 혼란을 줄이는 출발점입니다. 사용자가 얼마나 요청하는지, 얼마나 느린지, 얼마나 실패하는지, 시스템이 얼마나 꽉 찼는지를 먼저 봅니다.

개발자가 이 기준을 알면 기능을 만들 때부터 운영 가능한 형태로 계측할 수 있습니다. “로그 남겼으니 됐다”가 아니라, 사용자의 경험과 시스템 한계를 보여주는 지표를 남기는 습관이 생깁니다.

Latency는 요청이 완료되기까지 걸린 시간입니다. 평균보다 p95, p99 같은 상위 백분위가 중요할 때가 많습니다. 대부분의 사용자는 평균 사용자가 아니고, 느린 꼬리 지연이 실제 체감을 망칩니다.

Traffic은 시스템이 받는 수요입니다. HTTP 요청 수, 작업 큐 처리량, 초당 메시지 수, 활성 사용자 수처럼 서비스 성격에 맞게 정의합니다. 트래픽을 모르면 오류율과 지연 시간의 의미도 흐려집니다.

Errors는 실패한 요청의 비율이나 수입니다. HTTP 500만 오류가 아닙니다. timeout, 잘못된 fallback, 결제 거절, background job 실패처럼 사용자 목표가 실패한 사건을 서비스 기준으로 정의해야 합니다.

Saturation은 시스템이 얼마나 한계에 가까운지 보여줍니다. CPU 90% 자체보다 큐가 계속 쌓이는지, connection pool이 고갈되는지, 디스크 I/O가 밀리는지가 더 직접적인 신호일 수 있습니다.

새 API를 배포한다면 최소한 endpoint별 요청 수, 상태 코드별 오류율, p50/p95/p99 지연 시간, 주요 의존성 timeout 수를 남겨야 합니다. 큐 기반 작업이라면 처리량, 실패율, 처리 지연, 큐 backlog가 첫 화면에 있어야 합니다.

“CPU가 낮으니 괜찮다”는 판단은 위험합니다. 서비스는 CPU보다 DB 락, 외부 API, 큐 backlog, connection pool 때문에 먼저 막힐 수 있습니다.
“로그가 많으면 나중에 보면 된다”는 생각도 부족합니다. 장애 대응의 첫 5분에는 검색보다 대시보드의 방향성이 중요합니다.
“오류율 0%면 정상이다”도 아닙니다. timeout 전에 사용자가 이탈하거나, fallback만 계속 제공되거나, 비동기 작업이 뒤에서 실패하면 성공 응답만으로는 알 수 없습니다.
“모든 지표에 알림을 걸자”는 접근은 알림 피로를 만듭니다. 사용자의 실제 영향과 가까운 소수의 신호에서 시작하고, 원인 분석용 지표는 대시보드에 두는 편이 낫습니다.

운영 중인 서비스 하나를 골라 네 가지 질문으로 대시보드를 다시 그려보세요. 얼마나 들어오는가, 얼마나 느린가, 얼마나 실패하는가, 어디가 꽉 차는가입니다.

새 기능을 만들 때는 구현 완료 조건에 지표를 포함하세요. API가 동작하는 것과 운영 가능한 것은 다릅니다.

알림을 정리할 때는 “이 알림을 받으면 사용자가 어떤 피해를 보는가”를 기준으로 남기세요. 설명할 수 없는 알림은 대개 조정이 필요합니다.

대시보드가 복잡해질수록 먼저 볼 것은 네 가지입니다. 얼마나 들어오고, 얼마나 느리고, 얼마나 실패하고, 얼마나 꽉 찼는가.