8. 현실과 미래 — 프로덕션 적용과 엔지니어의 역할 변화

기술적으로는 그림이 완성됐다. 데이터 파이프라인, 이상 탐지, RCA, AI Agent, Runbook 자동화, 멀티 에이전트, 포스트모템. 다 설계했다.

그런데 이걸 팀에 도입하겠다고 하면, 기술과 전혀 다른 질문이 쏟아진다.

마지막 편에서는 이 현실적인 문제들과, SRE 엔지니어의 미래를 다룬다.

보안 — 어떤 데이터를 LLM에 넣을 수 있나

모든 운영 데이터를 LLM에 넣을 수 있는 건 아니다. 데이터를 분류하고 각각에 맞는 처리 방식을 정해야 한다.

경로 A를 선택했다면 마스킹 파이프라인이 필수다. IP를 [IP_MASKED]로, 호스트명을 [HOST_MASKED]로 치환하고 LLM에 보낸다. 마스킹해도 분석이 되는가? 대부분 된다. LLM이 필요한 건 "어떤 에러가 어떤 순서로 발생했는가"이지, 구체적인 IP 주소가 아니다.

다만 "특정 IP에서만 에러가 발생하는가" 같은 분석은 마스킹하면 불가능해진다. 이런 경우에는 경로 B를 쓰거나, 해당 부분만 사람이 직접 확인해야 한다.

경로 B는 데이터가 사내에 있으니 마스킹이 필요 없다. 대신 GPU 서버 자체의 보안(접근 제어, 네트워크 격리)을 관리해야 한다. 2편에서 다뤘던 "추론 서버도 운영 대상"이라는 이야기의 연장선이다.

비용과 ROI

"이거 도입하면 얼마 들어?" 경영진이 가장 먼저 묻는 질문이다.

경로 A 비용.

Claude API: 월 $50~200 (SRE 용도 호출량 기준)
또는 Claude Max 구독: 월 $100~200
추가 인프라: 없음
세팅 시간: 엔지니어 2~3일
─────────────────────────
월 총 비용: $100~400

경로 B 비용.

GPU 서버: A100 80GB 1대 (구입 $15,000~20,000 또는 클라우드 렌탈 월 $2,000~3,000)
전기세: 월 $50~100
세팅 시간: 엔지니어 1~2주
유지 관리: 주 2~4시간
─────────────────────────
월 총 비용: $200~500 (구입 시) 또는 $2,000~3,500 (렌탈 시)

이걸 절감 효과와 비교해야 한다.

[절감 항목]
야간 온콜 호출 감소: 80% 자동화 시 월 N건 × 호출당 비용
MTTR 단축: 45분 → 15분 (엔지니어 시간 절감)
포스트모템 작성 시간: 2시간 → 30분
토일 자동화: 주 5~10시간 절감

구체적인 숫자는 팀마다 다르지만, ROI 계산의 틀은 이거다.

월 절감액 = (야간 호출 감소 건수 × 건당 비용)
         + (장애 건수 × MTTR 단축 시간 × 엔지니어 시급)
         + (토일 감소 시간 × 엔지니어 시급)
 
투자 회수 기간 = 초기 투자 / 월 절감액

시니어 엔지니어의 야간 온콜 한 번에 드는 실질 비용(수당 + 다음 날 생산성 저하)이 10~20만원이라고 하면, 월 3~4건의 야간 호출만 줄여도 경로 A의 월 비용은 커버된다.

점진적 도입 — Shadow Mode부터

한 번에 프로덕션에 넣으면 안 된다. 단계를 밟아야 한다.

• Phase 1: Shadow Mode (1~2개월). 기존 운영은 그대로 두고, AI는 옆에서 관찰만 한다. 알림이 오면 AI가 분석 결과를 Slack 별도 채널에 올린다. 실제 대응은 사람이 하고, 사후에 "AI가 맞았는가?"를 비교한다.

이 기간에 축적하는 데이터가 중요하다. AI의 정탐률, 오탐률, 환각 발생 빈도를 측정한다. 이 수치가 Phase 2로 넘어갈 수 있는지 판단하는 근거가 된다.

• Phase 2: 비핵심 시스템 (2~3개월). 개발 서버, 스테이징 환경에서 AI 자동 대응을 시작한다. Read-Only → Human-in-the-Loop. Low 위험 작업(로그 정리, 캐시 클리어)부터 자동 실행한다. 사고 나도 프로덕션에 영향이 없는 범위에서 경험을 쌓는다.
• Phase 3: 핵심 시스템 확대 (3~6개월). 프로덕션에 적용한다. 충분한 신뢰가 확보된 Runbook만 자동 실행한다. Medium 위험 작업까지 범위를 넓힌다. 24/7 자동 감시 + 야간 자동 대응을 시작한다.

성과 측정 — "잘 되고 있는지" 어떻게 아는가

AI를 도입했으면 효과를 측정할 수 있어야 한다. 측정 없으면 개선도 없고, 경영진 설득도 못 한다.

핵심 지표 4가지.

Shadow Mode에서의 측정이 핵심이다. AI가 "이건 장애다"라고 판단한 것과 실제 엔지니어가 판단한 것을 비교한다. 일치율이 70%를 넘으면 Phase 2로 갈 수 있다.

LLM의 응답 품질도 시간에 따라 변할 수 있다. 경로 A에서 Anthropic이 모델을 업데이트하면 응답 패턴이 바뀔 수 있고, 경로 B에서 새 모델로 교체하면 성능이 달라진다. 모델 업데이트 전후의 정탐률/환각률을 비교하는 프로세스를 만들어둬야 한다.

Grafana에 AI 시스템 전용 대시보드를 만드는 것도 좋다. API 호출 횟수, 응답 시간, 판정 결과 분포, 에스컬레이션 비율을 모니터링한다. AI 시스템 자체를 모니터링하는 거다.

업계 현실 — AI를 도입했는데 토일이 늘었다

여기서 한 가지 불편한 현실을 짚고 넘어가야 한다.

2025년 Catchpoint SRE Report에 따르면, AI에 투자했는데 운영 토일이 25%에서 30%로 오히려 증가했다. 5년 만의 첫 상승이다. Harness 보고서도 개발자 92%가 "AI 도구가 배포 실패의 영향 범위를 늘렸다"고 응답했다.

원인은 명확하다. AI 자체가 새로운 관리 대상이 된 거다. 새로운 도구를 모니터링해야 하고, 새로운 알림을 확인해야 하고, AI가 실수하면 그것도 처리해야 한다. AI를 "제대로" 도입하지 않으면 오히려 복잡도만 올라간다.

이 시리즈에서 Shadow Mode, 점진적 도입, 성과 측정을 강조하는 이유가 이거다. AI를 도입하는 것과 AI로 실제 효과를 보는 것 사이에는 "점진적 도입 전략"이라는 다리가 필요하다.

SRE 엔지니어의 역할 변화

마지막으로 이 이야기를 하고 싶다.

AI가 SRE 업무의 80%를 자동화하면, 엔지니어는 뭘 하게 되나? 불필요해지는 건가?

그렇지 않다. 역할이 바뀌는 거다.

Before (Level 0):
  엔지니어 = 장애 감지 + 분석 + 실행 + 보고
 
After (Level 2~3):
  AI = 감지 + 1차 분석 + 반복 작업 실행 + 보고 초안
  엔지니어 = AI 설계 + 프롬프트 튜닝 + 복잡한 판단 + AI 감독

"시스템을 직접 고치는 사람"에서 "AI가 시스템을 잘 고치도록 설계하는 사람"으로 바뀐다.

기존 역량이 쓸모없어지는 게 아니다. Linux, 네트워크, 모니터링을 모르면 프롬프트를 제대로 짤 수 없다. "로그에서 뭘 봐야 하는지"를 아는 사람만이 "LLM에게 뭘 봐야 하는지"를 가르칠 수 있다. 10년의 운영 경험이 프롬프트 한 줄에 녹아든다.

거기에 새로운 역량이 얹어진다. 프롬프트 엔지니어링, Agent 아키텍처 설계, 환각 탐지, RAG 파이프라인 구축. 이건 기존 SRE 역량 위에서만 의미가 있는 것들이다. AI만 아는 사람이 SRE를 하기는 어렵다. SRE를 아는 사람이 AI를 쓰는 게 맞다.

시리즈를 마치며

1편에서 새벽 3시 전화로 시작했다. 8편의 끝에서 돌아보면, 이 시리즈가 말하고 싶었던 건 결국 하나다.

반복적인 고통을 줄일 수 있다.

모든 장애를 AI가 해결해주겠다는 게 아니다. 하지만 새벽 3시에 디스크 풀 때문에 일어나는 일은 줄일 수 있다. 하루 200건의 알림을 일일이 확인하는 건 LLM이 대신할 수 있다. 포스트모템을 빈 페이지에서 쓰는 건 초안을 만들어줄 수 있다.

Level 0에서 Level 2~3으로 가는 여정이 쉽지는 않다. Shadow Mode부터 시작해서, 신뢰를 쌓고, 조금씩 범위를 넓혀가야 한다. 하지만 방향은 분명하다. 그리고 이 방향으로 가는 데 필요한 아키텍처와 판단 기준을, 이 시리즈에서 다뤘다.

시작은 작게 하면 된다. LLM에게 로그 하나를 넣어서 분석시키는 것. 그것만으로도 Level 1이다.