장애 대응의 기술은 지난 몇 년 사이 조용히 바뀌었다. 바뀐 것은 도구 이름만이 아니다. 무엇을 증거로 삼는가, 그리고 첫 5분에 누가 가설을 내는가가 달라졌다. 새 도구를 하나 더 설치하는 이야기가 아니라, 장애를 읽는 순서가 통째로 재배열된 이야기다. 최근 흐름에서 실제로 값을 하는 네 가지를 정리한다.
1. 장애는 대체로 내 코드 밖에서 온다
먼저 전제를 고쳐야 한다. IncidentHub의 2026년 상반기 리포트는 1,082개 제공사에서 3만 246건의 장애를 집계했다. 이 중 클라우드 제공사 범주가 86개 사업자·4,723건으로 가장 많았고, 개발자 도구가 4,589건으로 뒤를 이었다. 같은 리포트가 반복해서 지목한 주제는 의존성 위험이다. 한 지역의 설정 하나가 전역으로 전파되고, 상위 제공사의 정책 자동화가 내려와 멀쩡한 서비스를 끈다.
실제 사례가 이 패턴을 그대로 보여준다. 마이크로소프트 애저의 2월 장애는 정비 정책이 VM 확장 패키지 저장소의 익명 접근을 잘못 차단하면서 시작됐다. 5월에는 레일웨이(Railway)가 구글 클라우드 계정 정지 여파로 8시간 동안 플랫폼 전체가 멈췄다. 두 경우 모두 고객 쪽 코드에는 아무 문제가 없었다.
그래서 트러블슈팅의 첫 질문이 바뀐다. “우리가 뭘 배포했지?”에서 “우리 위에서 뭐가 바뀌었지?“로. 서비스 상태 페이지, 상위 SaaS·CDN·DNS 제공사, 그리고 어제 들어간 정책·권한 변경이 조사 대상의 앞줄로 올라온다.
2. eBPF: 앱을 고치지 않고 커널에서 사실을 받는다
애플리케이션 로그는 개발자가 미리 남기기로 결정한 것만 보여준다. 정작 장애는 아무도 로그를 안 남긴 자리에서 난다. eBPF는 이 간극을 메운다. 커널에 안전한 프로그램을 붙여 시스템 콜, TCP 재전송과 드롭, 연결 지연, DNS 응답 시간을 애플리케이션을 재배포하지 않고 관측한다.
- 언제 값을 하나: 코드는 정상인데 꼬리 지연(p99)만 튈 때, 컨테이너끼리의 통신만 이상할 때, “네트워크 문제 같은데 증거가 없을 때”.
- 무엇을 보나: 실제 커널이 본 사실. 추정이 아니라 드롭된 패킷 수와 syscall 지연 같은 원자료다.
- 무엇이 걸림돌인가: 커널 버전과 권한 요구, 관리형 서비스에서의 제약, 그리고 수집량을 방치하면 비용이 는다는 점.
핵심은 도구 선택이 아니라 위치다. eBPF는 계측 없이 얻는 바닥면의 진실이고, 뒤에 나올 AI 에이전트가 추론할 재료가 된다.
3. OpenTelemetry: 신호를 하나의 축으로 꿰기
두 번째 변화는 표준화다. OpenTelemetry가 트레이스·메트릭·로그의 공통 형식 자리를 사실상 가져갔고, 최근에는 LLM 호출과 에이전트 실행까지 같은 스팬 체계로 기록하는 흐름이 자리를 잡았다. 이게 왜 트러블슈팅을 바꾸는가. 느린 LLM 응답 하나를 백엔드 DB 병목이나 클러스터 네트워크 지연과 같은 화면에서 이어 볼 수 있기 때문이다.
거창하게 시작할 필요는 없다. 순서는 이렇다.
- 요청 하나에
trace_id를 만들고, 모든 로그 줄에 그 값을 넣는다. 이 한 가지만 해도 조사 시간이 눈에 띄게 줄어든다. - 서비스 경계(게이트웨이·큐·외부 API 호출)에만 스팬을 붙인다. 내부 함수까지 계측하는 건 나중 일이다.
- 지표에 예시 트레이스(exemplar)를 연결해, 그래프의 튄 점에서 실제 요청으로 바로 내려갈 수 있게 한다.
4. AI SRE 에이전트: 1차 가설을 기계가 낸다
가장 최근의 변화다. 인시던트가 열리면 에이전트가 최근 배포·설정 변경·유사 과거 장애·관련 대시보드를 긁어 가설 목록과 요약을 먼저 올린다. 사람은 빈 화면이 아니라 초안 위에서 시작한다.
잘하는 일과 못하는 일이 뚜렷하다. 잘하는 일은 상관관계 찾기, 과거 인시던트와의 대조, 타임라인 정리, 보고서 초안이다. 못하는 일은 책임이 따르는 판단이다. 롤백 여부, 고객 공지, 데이터 정합성 판정은 여전히 사람의 몫이고, 에이전트에게 프로덕션 쓰기 권한을 통째로 주는 것은 아직 권할 일이 아니다.
그리고 결정적인 조건이 하나 있다. 에이전트의 품질은 입력 데이터의 품질을 넘지 못한다. 앞의 2·3번이 먼저다. 표준화된 트레이스와 커널 수준 사실이 없으면, 에이전트는 사람과 똑같이 흐릿한 로그를 읽고 그럴듯한 오답을 낸다.
이번 주에 할 수 있는 것
- 모든 로그에
trace_id를 넣는다. 가장 싸고 효과가 큰 한 수다. - 우리 서비스가 죽을 수 있는 상위 의존성 목록을 한 장으로 만든다. 클라우드·DNS·CDN·인증·결제·모니터링까지.
- 설정과 정책 변경을 배포처럼 다룬다. 리뷰·점진 적용·즉시 롤백 경로를 갖춘다. 2026년의 큰 장애들이 여기서 시작했다.
- 첫 5분 스크립트를 문서로 고정한다. ①상태 페이지 확인 ②최근 30분 변경 목록 ③오류율·지연 그래프 ④의존성 상태. 순서를 정해두면 사람이 덜 흔들린다.
- 비용 급증 알림을 장애 알림과 같은 채널에 둔다. 폭주하는 재시도 루프는 청구서에 먼저 나타나는 경우가 많다.
⚠️ 이 글의 사례와 통계는 2026년 9월 기준 공개 자료를 정리한 것이다. 장애 집계치는 집계 기관의 수집 범위에 따라 달라지고, 도구 생태계도 빠르게 바뀐다. 도입 전에는 각 도구의 최신 문서와 자사 환경의 제약(커널 버전·관리형 서비스 정책·수집 비용)을 반드시 확인하는 것이 좋다.
자주 묻는 질문
eBPF를 쓰려면 애플리케이션을 고쳐야 하나요?
아닙니다. eBPF의 장점이 바로 그 지점입니다. 커널에서 관측하기 때문에 애플리케이션 코드를 수정하거나 재배포하지 않고도 시스템 콜, TCP 재전송, 연결 지연 같은 사실을 볼 수 있습니다. 다만 커널 버전과 권한 요건, 관리형 서비스에서의 제약은 미리 확인해야 합니다.
AI SRE 에이전트에게 어디까지 맡길 수 있나요?
가설 제시, 과거 인시던트 대조, 타임라인과 보고서 초안까지가 현실적인 범위입니다. 롤백 실행, 고객 공지, 데이터 정합성 판단처럼 책임이 따르는 결정은 사람이 유지하는 편이 안전합니다. 에이전트의 결과 품질은 입력 데이터의 품질을 넘지 못한다는 점도 함께 봐야 합니다.
관측 도구를 다 도입할 여력이 없다면 무엇부터 하나요?
모든 로그에 동일한 trace_id를 넣는 것부터 시작하시면 됩니다. 비용이 거의 들지 않으면서 조사 속도를 가장 크게 바꾸는 조치입니다. 그다음이 서비스 경계에만 붙이는 최소 트레이싱, 그다음이 상위 의존성 목록 정리입니다.
Leave a Reply