Google SRE는 장애 대응에 AI를 어떻게 쓰는가 — Gemini CLI 실전 활용

새벽 3시, 알림이 울린다

 

서비스에 장애가 발생했다. 대시보드에는 빨간 그래프가 치솟고, Slack 채널에는 알림이 쏟아진다. SRE 엔지니어는 잠에서 깨어 노트북을 열고 로그를 뒤지기 시작한다. 수백만 줄의 로그에서 원인이 될 만한 패턴을 찾아야 한다. 시간은 촉박하고, 머리는 아직 완전히 깨지 않았다.

 

Google Cloud SRE 팀은 이 상황에 Gemini CLI를 투입한다. 터미널에서 바로 AI에게 로그 분석을 시키고, 패턴 인식을 맡기고, 과거 유사 장애와 매칭하는 것이다. 원래 사람이 30분 걸려 하던 일을 5분 이내에 초안을 뽑아내는 것이 목표다.

 

---

 

Gemini CLI란

 

Gemini CLI는 Google의 터미널 기반 AI 도구다. 웹 브라우저의 챗봇 인터페이스가 아니라, 로컬 터미널에서 파일과 명령어를 직접 다루는 AI 에이전트다. 비유하면 이렇다. 웹 챗봇이 "전화 상담원"이라면, CLI 도구는 현장에 와서 같이 일하는 동료다. 같은 터미널을 보고, 같은 로그 파일을 읽고, 같은 명령어를 실행할 수 있다.

 

용어: SRE(Site Reliability Engineering): Google이 창안한 운영 방법론으로, 소프트웨어 엔지니어링 원칙을 인프라 운영에 적용한다. "서비스의 안정성을 코드로 관리한다"는 철학이다.

 

핵심 특징은 다음과 같다.

 

• 로컬 파일 접근: 서버의 로그 파일, 설정 파일, 런북을 직접 읽을 수 있다
• 명령어 실행: 사용자의 승인 하에 터미널 명령어를 실행할 수 있다
• 컨텍스트 유지: 대화 세션 동안 이전 분석 결과를 기억하고 연속적으로 추론한다
• 멀티모달 입력: 텍스트뿐 아니라 스크린샷, 그래프 이미지도 입력으로 받을 수 있다

 

---

 

장애 대응 워크플로우에 AI 통합

 

Google Cloud SRE 팀은 Gemini CLI를 장애 대응의 세 단계에 걸쳐 활용한다.

 

1. 로그 분석: 수백만 줄에서 핵심 추출

 

장애가 발생하면 가장 먼저 하는 일이 로그 확인이다. 문제는 대규모 서비스의 로그는 분당 수십만 줄씩 쌓인다는 것이다. 사람이 grep과 awk로 패턴을 찾는 데 걸리는 시간이 장애 복구 시간의 상당 부분을 차지한다.

 

gemini-log-analysis.sh

# Gemini CLI에게 로그 분석을 요청하는 예시
gemini "아래 로그 파일에서 최근 30분간의 에러 패턴을 분석해줘.
특히 에러율이 급증한 시점과 관련된 요청 경로를 식별해줘." \
  --file /var/log/app/error.log

# Gemini의 분석 결과 예시:
# - 14:23:17부터 /api/v2/payments 경로에서 503 에러 급증
# - 원인 후보: upstream timeout (payment-gateway 서비스)
# - 에러율: 14:20 이전 0.1% → 14:23 이후 34.7%
# - 관련 trace ID: abc123, def456, ghi789

 

사람이 수동으로 하면 15~20분 걸리는 분석을 Gemini CLI는 2~3분에 초안을 제시한다. 물론 이 초안의 정확성을 사람이 검증해야 하지만, "어디를 봐야 하는가"라는 방향 설정 시간을 대폭 줄여준다.

 

2. 패턴 매칭: 과거 유사 장애 연결

 

Google Cloud는 수천 건의 과거 장애 기록(Post-mortem)을 보유하고 있다. Gemini CLI는 현재 장애의 증상(에러 메시지, 영향 범위, 시간대)을 과거 기록과 대조해 유사도가 높은 장애 사례를 찾아낸다.

 

비유하면 경험 많은 의사가 환자의 증상을 보고 "이건 3개월 전 A 환자와 비슷한 패턴인데"라고 떠올리는 것과 같다. 다만 AI는 수천 건의 이력을 동시에 대조할 수 있으므로, 사람보다 빠짐없이 후보를 찾아낸다.

 

gemini-pattern-matching.sh

gemini "현재 장애 증상:
- payment-gateway 서비스 503 에러
- 14:23부터 시작
- us-central1 리전만 영향

과거 post-mortem 문서에서 유사한 패턴을 찾아줘." \
  --directory /docs/postmortems/

 

3. 런북 자동 실행: 정해진 절차를 AI가 대신

 

런북(Runbook)은 특정 장애 상황에서 실행할 절차를 적어둔 문서다. Gemini CLI는 과거 유사 장애에서 효과가 있었던 런북을 식별하고, 사용자의 승인 하에 런북의 단계를 하나씩 실행할 수 있다.

 

gemini-runbook-execution.sh

gemini "payment-gateway 503 에러에 대한 런북을 실행해줘.
각 단계를 실행하기 전에 내 승인을 받아줘." \
  --file /runbooks/payment-gateway-503.md

# Gemini: 런북 Step 1 - payment-gateway 파드의 상태를 확인합니다.
#         실행할 명령어: kubectl get pods -n payment -l app=gateway
#         실행할까요? [y/n]

 

중요한 것은 자동 실행이 아니라 반자동 실행이라는 점이다. 각 단계마다 사람의 승인을 받는다. 이것은 의도적인 설계다. 장애 상황에서 AI가 판단을 잘못해 서버를 내리거나 데이터를 삭제하면 장애가 더 커지기 때문이다.

 

---

 

장애 대응 시간 단축 효과

 

Google Cloud SRE 팀의 내부 데이터에 따르면, Gemini CLI 도입 후 MTTR(Mean Time To Recovery)이 유의미하게 개선되었다.

 

지표	AI 도입 전	AI 도입 후	개선율
로그 분석 시간	평균 18분	평균 4분	~78% 단축
유사 장애 매칭	평균 25분 (수동 검색)	평균 3분	~88% 단축
전체 MTTR	팀/장애마다 상이	약 20~30% 단축	-

 

특히 새벽 시간대의 장애에서 효과가 컸다. 사람의 인지 능력이 떨어지는 시간에 AI가 "일단 이것부터 확인해보세요"라는 방향을 제시해주는 것만으로도 초동 대응 속도가 크게 달라졌다.

 

---

 

한계점: AI를 맹신하면 안 되는 이유

 

환각(Hallucination)

 

AI가 없는 패턴을 있는 것처럼 보고하거나, 과거 장애 사례를 잘못 매칭하는 경우가 발생한다. 장애 상황에서 잘못된 정보에 기반한 조치는 장애를 확대시킬 수 있다. 그래서 Google SRE 팀은 Gemini CLI의 분석 결과를 반드시 사람이 검증하는 절차를 강제한다. AI의 출력은 "정답"이 아니라 "검토할 후보"다.

 

신뢰 경계

 

AI가 접근할 수 있는 시스템의 범위를 명확히 설정해야 한다. 프로덕션 데이터베이스에 직접 쿼리를 날리거나, 인프라 설정을 변경하는 권한을 AI에게 주면 위험하다. Google은 Gemini CLI에게 읽기 전용 접근만 기본으로 허용하고, 쓰기 작업은 명시적 승인을 요구한다.

 

자동 실행의 위험

 

"AI가 알아서 해결해줄 것"이라는 기대는 위험하다. AI는 장애의 맥락(비즈니스 영향, 조직의 우선순위, 고객 커뮤니케이션 타이밍)을 완전히 이해하지 못한다. 기술적 조치만으로 해결되지 않는 부분이 존재하며, 이것은 사람의 판단 영역이다.

 

---

 

다른 AI CLI 도구와의 비교

 

Gemini CLI만이 유일한 선택지는 아니다. 유사한 접근을 하는 도구들이 있다.

 

기준	Gemini CLI	Claude Code	GitHub Copilot CLI
제작사	Google	Anthropic	GitHub (Microsoft)
강점	Google Cloud 통합, 로그 분석	코드 분석, 파일 편집	git 워크플로우 통합
장애 대응 특화	높음 (SRE 워크플로우 최적화)	중간 (범용 코딩 에이전트)	낮음 (개발 워크플로우 중심)
로컬 파일 접근	지원	지원	제한적
명령어 실행	승인 후 실행	승인 후 실행	제한적

 

Gemini CLI는 Google Cloud 인프라와의 네이티브 통합이 가장 큰 차별점이다. GKE, Cloud Logging, Cloud Monitoring과 직접 연동되어, Google Cloud 위에서 운영하는 팀에게는 가장 자연스러운 선택이다. 반면 클라우드에 종속되지 않는 범용적인 코드 분석과 수정이 필요하다면 Claude Code 같은 도구가 더 적합할 수 있다.

 

---

 

SRE/DevOps 엔지니어가 AI 도구를 도입할 때 고려할 점

 

AI CLI 도구를 장애 대응에 도입하려는 팀이 사전에 고려해야 할 사항이 있다.

 

접근 권한 설계가 먼저다. AI에게 어떤 시스템까지 읽기를 허용하고, 어떤 시스템은 차단할 것인지 명확히 정의해야 한다. 프로덕션 데이터베이스의 민감 정보(개인정보, 금융 데이터)가 AI 모델로 전송되는 것은 컴플라이언스 위반이 될 수 있다.

 

점진적으로 도입한다. 처음부터 장애 대응 전 과정에 AI를 투입하는 것이 아니라, 로그 분석 → 패턴 매칭 → 런북 보조 순으로 단계별로 확대한다. 각 단계에서 AI의 정확도와 신뢰도를 측정하고, 팀원들의 신뢰가 쌓인 후에 다음 단계로 넘어간다.

 

AI의 출력을 검증하는 절차를 자동화한다. AI가 "이 서비스를 재시작하라"고 제안했을 때, 제안의 근거(어떤 로그, 어떤 메트릭)를 함께 출력하도록 프롬프트를 설계한다. 근거가 없는 제안은 실행하지 않는 원칙을 세운다.

 

---

 

마무리

 

AI가 장애 대응에서 사람을 대체하는 것이 아니다. AI는 "어디를 봐야 하는지"를 빠르게 찾아주는 탐조등이다. 어두운 곳에서 길을 비춰주지만, 그 길을 걸어갈지 말지는 사람이 결정한다. Google SRE 팀의 Gemini CLI 활용은 이 원칙을 잘 보여준다. 분석은 AI에게 맡기되, 판단과 실행은 사람이 한다. 새벽 3시에 울리는 알림이 사라지지는 않겠지만, 그 알림에 대응하는 속도와 정확도는 확실히 달라질 수 있다.