새벽 3시의 탐조등 — Google SRE가 Gemini CLI로 장애를 잡는 법

서비스에 장애가 터졌다. 대시보드에 빨간 그래프가 치솟고, Slack 채널에 알림이 폭포처럼 쏟아진다. 새벽 3시, 잠에서 깨어 노트북을 연 SRE 엔지니어의 머리는 아직 절반만 가동 중이다. 수백만 줄의 로그에서 원인이 될 만한 패턴을 찾아야 하는데, 시간은 흐르고 눈은 침침하다.

Google Cloud SRE 팀은 이 상황에 Gemini CLI를 투입한다. 어두운 바다에서 물고기를 찾는 어부에게 강력한 탐조등을 쥐여주는 것과 같다. 물고기를 잡는 것은 여전히 어부의 일이지만, "어디를 비춰봐야 하는가"를 AI가 알려준다.

터미널에 앉은 동료 — Gemini CLI의 정체

Gemini CLI는 Google의 터미널 기반 AI 도구다. 웹 브라우저의 챗봇이 아니다. 같은 터미널에서 같은 로그 파일을 읽고, 같은 명령어를 실행할 수 있는 현장 동료다. 웹 챗봇이 전화 상담원이라면, CLI 도구는 옆자리에 앉아 모니터를 함께 보는 시니어와 같다.

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

핵심 특징을 정리하면 이렇다.

장애 대응의 세 국면 — AI가 개입하는 지점

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

1단계: 로그 분석 — 건초 더미에서 바늘 찾기

대규모 서비스의 로그는 분당 수십만 줄씩 쌓인다. 사람이 grep과 awk로 패턴을 찾는 시간이 장애 복구 시간의 상당 부분을 차지한다. 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분 걸리는 분석을 2~3분에 초안으로 제시한다. 이 초안의 정확성은 사람이 검증해야 하지만, "어디를 봐야 하는가"라는 방향 설정 시간을 대폭 줄여준다.

2단계: 패턴 매칭 — 과거의 기억을 소환하다

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

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

gemini "현재 장애 증상:
- payment-gateway 서비스 503 에러
- 14:23부터 시작
- us-central1 리전만 영향
 
과거 post-mortem 문서에서 유사한 패턴을 찾아줘." \
  --directory /docs/postmortems/

[💡 잠깐! 이 용어는?] Post-mortem: 장애가 해결된 후 작성하는 사후 분석 문서. 장애의 타임라인, 근본 원인, 영향 범위, 재발 방지책을 기록한다. "같은 실수를 두 번 하지 않기 위한" 조직적 학습 장치.

3단계: 런북 반자동 실행 — 사람이 브레이크를 쥔다

런북(Runbook)은 특정 장애 상황에서 실행할 절차를 적어둔 문서다. Gemini CLI는 적합한 런북을 식별하고, 사용자의 승인 하에 단계별로 실행한다.

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가 "일단 이것부터 확인해보세요"라는 방향을 잡아주는 것만으로도 초동 대응 속도가 확연히 달라졌다.

[💡 잠깐! 이 용어는?] MTTR(Mean Time To Recovery): 장애 발생 시점부터 서비스가 정상으로 복구되는 시점까지의 평균 소요 시간. SRE 핵심 지표 중 하나로, 이 시간이 짧을수록 서비스 안정성이 높다고 평가한다.

맹신은 금물 — AI 장애 대응의 함정들

환각이 장애를 키운다

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

신뢰 경계를 명확히

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

맥락의 한계

AI는 장애의 기술적 측면은 분석하지만, 비즈니스 영향, 조직 우선순위, 고객 커뮤니케이션 타이밍을 이해하지 못한다. 이것은 사람의 판단 영역이다.

경쟁 지형 — AI CLI 도구 비교

Gemini CLI만이 유일한 선택지는 아니다.

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

도입을 고려하는 팀에게

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

점진적으로 확대한다. 로그 분석 → 패턴 매칭 → 런북 보조 순으로 단계별로 넓혀간다. 각 단계에서 AI의 정확도를 측정하고, 팀원의 신뢰가 쌓인 후 다음 단계로 넘어간다.

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

마무리

AI는 장애 대응에서 사람을 대체하는 것이 아니다. 어두운 바다에서 방향을 비춰주는 탐조등이다. 길을 비춰주지만, 그 길을 걸어갈지는 사람이 결정한다. Google SRE 팀의 사례는 이 원칙을 잘 보여준다. 분석은 AI에게, 판단과 실행은 사람에게. 새벽 3시에 울리는 알림이 사라지지는 않겠지만, 그 알림에 대응하는 속도와 정확도는 확실히 달라질 수 있다.