없음
- 코딩은 엔지니어링 시간의 30%. 나머지 70%는 프로덕션 운영
- 다운타임과 서비스 저하로 Global 2000 기업에 연간 약 $400B 비용 발생
- 운영 모니터링, 온콜 대응, 트러블슈팅, 인프라 관리, 보안
- 인시던트 해결 시 여러 소스와 팀에서 정보를 조합해야 함
- 종종 구식인 런북(runbook) 유지 관리
- 클라우드 네이티브(컨테이너, Kubernetes) 전환으로 복잡성 증가
- 온콜 시프트로 인한 SRE 번아웃
Google SRE Book (Beyer et al., O'Reilly, 2016) 유래:
- Latency: 요청 처리 시간. 성공/실패 분리 추적 필요
- Traffic: 시스템 수요 (requests/sec, 세션 수, 트랜잭션 수 등)
- Errors: 실패율. 명시적(HTTP 500), 암묵적(200인데 잘못된 콘텐츠), 정책 기반(SLA(Service Level Agreement) 위반)
- Saturation: 시스템 포화도. CPU, 메모리, I/O 등. 100% 전에 성능 저하 시작
시나리오: 새벽 3:12 AM, PagerDuty에서 DB 쿼리 500 에러 스파이크 알림
- Acknowledge & Assess — PagerDuty 확인, 심각도 판단, 부분/전체 장애 확인
- Check DB + App — 골든 시그널 기준 점검
- Identify Recent Changes — 최근 배포, DB 마이그레이션, 설정 변경, 오토스케일링 이벤트 → 상관관계 있으면 즉시 롤백
- Localize Blast Radius — 전체 vs 특정 쿼리, Read vs Write, Primary vs Replica, 앱 vs DB
- Execute Mitigations — 커넥션 문제: 앱 팟 재시작 / DB 포화: 무거운 잡 비활성화, 트래픽 스로틀 / 느린 쿼리: 기능 비활성화 / 레플리카 lag: Primary로 라우팅
- Stabilize + Monitor — 500 비율, DB 레이턴시, 트래픽 정상화 확인. 리트라이 스톰/연쇄 장애 주의
- Communicate — 10-15분 간격 업데이트
- Document — 타임라인, 근본 원인, 후속 조치 기록
추적 지표: MTTR(Mean Time To Repair), 투입 엔지니어 수, 고객 대상 SLA
주요 플레이어: Resolve AI, Datadog Bits AI Agent, Splunk Observability Assistant
특성:
- 동적 지식 그래프 매핑으로 서비스 간 의존관계 자동 파악
- observability 스택과 클라우드 전반에 걸친 에이전틱 시스템
- 실시간 내러티브 생성: 상황 설명 + 근본 원인 추정(증거 포함) + 처방적 조치 권고
- 설명 가능성 및 감사 가능성 강조
변화:
- AI가 조직/서비스 수준의 지식을 스케일 아웃 → 특정 엔지니어에게 사일로되지 않음
- 패러다임 전환: AI assisted (사람 → 도구 → AI 보조) → AI-native (사람 → AI agents → 도구)
- 코드 리뷰 자동화: 리뷰 시간 단축, 일관된 기준, 루틴 체크 자동화
한계:
- 해결 가능한 인시던트 복잡도에 한계
- 현대 프로덕션 스택의 이질성
- 탐지 결과 기반 실제 코드 수정 능력 부족. 모든 프로바이더가 우선 RCA(Root Cause Analysis)에서 출발 중
- 좋은 RCA를 위해서는 좋은 모니터링 가드닝이 필수
- AI 시스템 자체가 새로운 공격 벡터
- 엔지니어 시간의 70%+가 Grunt work: 로그 쿼리, 컨텍스트 구축, 증거 수집, 문서화, 팀 간 조율, 온콜, 배포 등
- Creative work (문제 해결, 최적화, 설계 결정)은 ~30%
- 사일로된 데이터: 수백 개 도구에 데이터 분산. 수천 서비스 × 수백 팀. 복잡하고 일시적(ephemeral)인 인프라
- 팀 간 조율: Application Engineers, Platform Engineers, SREs, IT Ops, Security Engineers, Support Engineers 각각 다른 전문성
- 단편적/미문서화된 지식: Runbooks, Meetings, Messaging에 흩어지거나 아예 미문서화
비즈니스 임팩트:
- 인시던트 해결 수 시간~수 일, 정기적으로 20+명 투입
- 소수 엔지니어만 프로덕션을 완전히 이해, 신규 온보딩 3~6개월
- 고객이 내부보다 먼저 이슈 발견
- AI 생성 코드가 문제를 악화 (더 많은 코드 → 더 많은 프로덕션 복잡성)
기둥 1 — 모든 프로덕션 도구 이해/운영:
- 코드/인프라/도구/지식에 연결 (Logs, Metrics, Traces, Alerts, Dashboards, Change Events, Runbooks)
- 서비스 의존성 그래프 자동 구축으로 시스템 동작 모델링
- 그래프 탐색으로 증거 수집 (코드 파일, 인프라, 메트릭 단계별 실행)
- 도구를 전문가처럼 운영 (예: Loki 로그 쿼리 자동 생성, 1,991 로그 분석 후 관련성 태깅)
기둥 2 — 트라이벌 지식 캡처:
- 회사/팀 지식 캡처: 서비스별 커스텀 지침 등록
- 인-더-루프 피드백 기억: 분석 결과에 대한 피드백 반영
- 컨텍스트 특화 정보 검색: 조사 시 Runbooks + 과거 조사 학습 자동 검색
기둥 3 — 전 팀의 전문성 결합:
- 조사 계획 수립 (Alert 분석 → 증거 수집 → 근본 원인 추적)
- 다수 가설 병렬 추구 (트리 구조 분기)
- 근본 원인까지 계획 지속 정제. 예: Redis 커넥션 장애 + 리트라이 로직(30회 동기 블로킹, 서킷 브레이커 부재) → 프론트엔드 연쇄 지연 (코드 레벨 추적)
- 조직 경계를 넘는 다중 사용자 협업: 분 단위 인시던트 타임라인
- 모델 문제만이 아님: 도메인 전문성이 아키텍처에 내장되어야 함. 프롬프트 엔지니어링만으로 불가
- 컨텍스트 윈도우는 유한, 프로덕션 컨텍스트는 무한: 지능은 무엇을/언제/어떻게 쿼리할지 아는 것
- 도구 연동은 비자명: Raw API 출력은 크고 지저분하며 인간용. 노이즈 필터링, 구조화된 요약, 에러 핸들링, 병렬 처리 필요
- 평가(Evaluation)가 제품만큼 어려움: AI 출력의 정확성을 검증하려면 실제 프로덕션의 서비스 구조·의존성·장애 시나리오를 복제한 테스트 환경이 필요
- Models (현재): Grunt work 대부분. LLM이 일부 보조
- Agents (진행 중): Grunt work 감소. 에이전트가 반복 작업 자동화
- Closed loop agents (목표): Grunt work 최소화. 에이전트가 자율 운영, 엔지니어는 창의적 작업에 집중
- Google SRE Books — Google이 무료 공개한 SRE 관련 서적 3권
- Site Reliability Engineering (2016): SRE의 원전. SRE 철학, 리스크 관리, SLO, 모니터링(4대 골든 시그널 포함), 온콜, 인시던트 관리, 포스트모템, 장애 대응 등 전반을 다룸. 강의의 "기존 SRE의 세계" 내용의 배경 지식.
- (메모: 강의에선 이거만 링크했는데 찾아보니까 여러 개 있고, 지금 읽기에는 분량이 많아서 메모만)
- The Site Reliability Workbook (2018): 위 책의 실무 적용 가이드. SLO 구현, 모니터링 설정, 알림 설계, 인시던트 대응 프로세스 등 실습 중심.
- Building Secure & Reliable Systems (2020): 보안과 신뢰성의 교차점. 설계 단계부터 보안을 내장하는 방법론.
- Site Reliability Engineering (2016): SRE의 원전. SRE 철학, 리스크 관리, SLO, 모니터링(4대 골든 시그널 포함), 온콜, 인시던트 관리, 포스트모템, 장애 대응 등 전반을 다룸. 강의의 "기존 SRE의 세계" 내용의 배경 지식.
- Traces & Spans: Observability Basics You Should Know — Last9
- 분산 시스템에서 요청 흐름을 추적하는 Trace/Span 개념 정리.
- 핵심:
- Trace는 요청 전체 흐름, Span은 그 내부 개별 작업 단위이며 부모-자식 구조로 구성.
- Context Propagation으로 trace ID/span ID를 헤더에 실어 서비스 간 동일 요청을 연결.
- Sampling으로 수집량 제어: Head, Tail, Priority 방식.
- OpenTelemetry가 사실상 표준.
- 강의의 4대 골든 시그널, Resolve AI의 "Traces" 데이터소스 이해에 필요한 기초.
메모: resolve-ai 유튜브 채널보면 핵심 소개 영상도 조회수 수백따리인데, 잘 되는거 맞나...? 기업 영상이 조회수가 낮긴 한데, 공식 예시조차 이러면 인지도가 낮은거 아닌가.
아래 내용은 주의깊게 공부한다기보다는 2025년 하반기 기준 이런 식으로 SRE에 AI를 활용했다는 정도로 보면 될 듯.
-
AI Production Engineer — Product Deep Dive — Resolve AI
- Resolve AI의 첫 번째 제품인 "AI Production Engineer"의 동작 방식.
- 핵심:
- 연결 즉시 동적 지식 그래프를 구축하고 실시간 갱신 (배포, 설정 변경, 코드 변경 반영).
- 알림 발생 시 1분 내에 근본 원인 이론 + 수정 단계를 자동 제시. 실시간 런북을 자동 생성·실행.
- Slack 멘션으로 협업, 조치 지시 (롤백, 팟 재시작 등) 가능.
- 인시던트 해결 후 자동으로 포스트모템 문서 생성.
-
Kubernetes Troubleshooting in Resolve AI — Resolve AI
- Kubernetes 프로덕션 환경에서 Resolve AI가 트러블슈팅하는 방식.
- 핵심:
- K8s 특유의 문제: 노이즈 알림 (self-healing으로 자동 해소되는 팟 재시작이 경고 유발), 일시적(ephemeral) 팟이 크래시하면 디버깅 컨텍스트 소실, observability 데이터가 노드/팟/컨테이너에 분산.
- 에이전틱 AI 접근: 지식 그래프로 팟/노드/서비스/네임스페이스 간 관계 매핑. 유사한 메모리 스파이크나 불균형 트래픽 등 시스템적 이슈 탐지.
- 팟 크래시 시: 이벤트 타임라인 재구성 → 클러스터 전체 이상 상관분석 → 자동 가설 검증 (OOM? 잘못된 startup 커맨드?) → 해결책 제시.
-
The role of multi agent systems in making software engineers AI-native — Resolve AI
- 단일 LLM이나 단일 에이전트가 아닌 멀티 에이전트 시스템이 필요한 이유.
- 핵심:
- AI-Assisted vs AI-Native 구분: AI-Assisted는 기존 워크플로우에서 개별 작업을 가속. AI-Native는 AI가 주 인터페이스로, 엔지니어는 목표를 설정하고 에이전트가 운영.
- 접근법별 한계: LLM(피드백 루프 없음) → LLM+Tools(상관분석은 인간 몫) → Single Agent(순차적 조사, 잘못된 가설에 갇힘) → Multi-Agent(병렬 가설 검증, 도메인별 전문화).
- 구축이 어려운 이유: 도메인 전문성(프로덕션 디버깅 경험)과 AI 아키텍처 전문성(에이전트 간 컨텍스트 전파, DAG 기반 정보 흐름, 레이스 컨디션/데드락 방지) 둘 다 필요.
- 강의 슬라이드 32 "Lessons Learned"와 직접 대응.
-
The Top 5 Benefits of Agentic AI in On-call Engineering — Resolve AI
- 에이전틱 AI가 온콜 엔지니어링에 가져오는 5가지 이점.
- 핵심:
- 알림 피로 제거: 에이전트가 24/7 알림 대응, 1분 내 근본 원인 + 조치 제시.
- 동적 지식 유지: 정적 런북과 달리 매 인시던트에서 학습. 핵심 인력 이탈 시에도 지식 보존.
- 일관된 조사: 에이전트마다 전문 영역(로그, 메트릭 등) 분담 → 체계적·반복 가능한 프로세스.
- 증거 기반 협업: Slack 연동, 조사 단계·근거를 실시간 문서화 → 포스트모템에 활용.
- 선제적 해결: 메트릭/로그/시스템 행동 패턴 분석으로 인시던트 발생 전 탐지.