AI가 장애를 해결할수록 엔지니어는 시스템을 잊어간다

새벽 3시.

트래픽이 급증하고 서버의 Capacity가 부족해졌습니다.

예전이라면 PagerDuty가 울리고, 온콜 엔지니어가 잠에서 깨 로그를 확인했을 것입니다.

최근 배포를 살펴보고, 메트릭을 비교하고, 원인을 추측하고, 필요한 조치를 직접 실행합니다.

하지만 이제는 그 일을 AI가 할 수 있습니다.

Alert를 분석하고가설을 세우고Telemetry를 조회하고최근 Deployment와 연관성을 찾고심지어 수정까지 실행합니다.

엔지니어는 깨지 않아도 됩니다.

굉장히 좋은 변화처럼 보입니다.

그런데 전 LinkedIn SRE이자 현재 Rootly에서 AI Reliability 분야를 다루고 있는 Sylvain Kalache는 여기서 반대로 질문합니다.

AI가 장애를 너무 잘 해결하기 시작하면, 엔지니어는 시스템을 얼마나 이해하게 될까?

그가 쓴 글 「AI handles incidents, engineers lose touch with their systems」의 핵심은 바로 여기에 있습니다.

가장 쉬운 장애가 사실 최고의 훈련이었다

우리는 보통 반복적인 장애를 좋지 않은 일이라고 생각합니다.

디스크가 가득 찬다.

메모리가 부족하다.

Capacity가 부족하다.

잘못된 Deployment 때문에 특정 서비스가 오류를 낸다.

익숙한 장애입니다.

Runbook도 있고 해결 방법도 알고 있습니다.

그래서 이런 문제부터 AI에게 넘기는 것이 가장 합리적으로 보입니다.

실제로 그렇습니다.

문제는 이런 평범한 장애들이 엔지니어에게는 훈련장이었다는 것입니다.

운영자는 반복적인 장애를 직접 해결하면서 자연스럽게 배웁니다.

어떤 메트릭이 먼저 움직이는지.

평소 로그는 어떻게 생겼는지.

어떤 서비스와 어떤 서비스가 연결되어 있는지.

어떤 알람은 중요하고 어떤 알람은 Noise인지.

배포 이후 어떤 문제가 자주 생기는지.

문서에는 없는 시스템의 미묘한 특성까지 조금씩 몸으로 익힙니다.

Kalache는 이를 엔지니어가 시스템이 “어떻게 동작하고 어떻게 실패하는지에 대한 직관”을 만드는 과정이라고 설명합니다.

AI가 가장 먼저 없애는 것도 바로 이 경험입니다.

자동화의 역설

이 문제는 사실 AI 시대에 처음 등장한 것이 아닙니다.

1983년 인간공학 연구자 Lisanne Bainbridge는 유명한 논문 「The Ironies of Automation」에서 자동화의 역설을 설명했습니다.

자동화는 사람이 반복적인 작업을 수행할 기회를 줄입니다.

그런데 시스템이 자동화로 해결하지 못하는 새로운 상황이나 비정상적인 상황이 발생하면 결국 사람이 개입해야 합니다.

즉,

자동화가 쉬운 문제를 가져가고사람에게는 가장 어려운 문제만 남깁니다.

하지만 그 어려운 문제를 해결해야 하는 사람은 평소 시스템을 직접 다룰 기회가 줄어들었습니다.

그래서 Bainbridge의 결론은 역설적입니다.

자동화가 증가할수록 운영자는 덜 훈련되어도 되는 것이 아니라,

오히려 이전보다 더 높은 수준의 훈련이 필요합니다.

Kalache가 AI 기반 Incident Response에서 보고 있는 문제도 정확히 이것입니다.

MTTR은 좋아지는데 진짜 어려운 장애는 더 오래 걸릴 수도 있다

AI Incident Response의 KPI를 보면 결과는 좋아질 가능성이 높습니다.

평균 MTTR은 내려갑니다.

많은 Routine Incident가 자동으로 해결되기 때문입니다.

새벽에 엔지니어를 깨우지 않아도 되고,

탐지 → 분석 → 조치 시간이 줄어듭니다.

표면적으로는 Reliability가 좋아진 것처럼 보입니다.

하지만 Kalache는 다른 형태의 문제가 나타날 수 있다고 예상합니다.

평균적인 Incident의 MTTR은 낮아지는 반면,

AI가 해결하지 못하는 Complex Incident의 해결 시간은 오히려 크게 늘어날 수 있다는 것입니다.

AI가 처음 보는 장애.

여러 시스템이 동시에 얽힌 장애.

Telemetry가 불완전한 장애.

원인이 하나가 아닌 장애.

기존 Runbook으로 설명할 수 없는 장애.

그 순간 AI는 Human에게 Escalation합니다.

그런데 Pager를 받은 엔지니어는 최근 몇 달 동안 직접 장애를 조사한 적이 거의 없습니다.

시스템이 어떻게 변했는지도 익숙하지 않습니다.

어떤 Dashboard부터 봐야 할지조차 예전보다 감각이 떨어져 있을 수 있습니다.

가장 어려운 순간에,

가장 연습이 부족한 사람이 투입되는 구조입니다.

항공업계는 오래전부터 이 문제를 알고 있었다

Kalache는 해결책을 찾기 위해 항공업계를 봅니다.

현대 항공기는 상당 부분 자동화되어 있습니다.

정상적인 비행 상황에서 조종사가 모든 것을 직접 제어할 필요는 없습니다.

하지만 자동화가 해결하지 못하는 상황이 있습니다.

Engine FailureUnreliable InstrumentRejected TakeoffStall

이런 사건은 매우 드뭅니다.

글에서 소개한 수치에 따르면 현대 터빈 엔진의 비행 중 정지는 10만 엔진 비행시간당 1회 미만입니다.

상업 조종사는 실제 비행 중 이런 장애를 한 번도 경험하지 않고 커리어를 끝낼 수도 있습니다.

그런데 항공사는

“어차피 거의 발생하지 않으니 훈련하지 않아도 된다”

고 하지 않습니다.

오히려 정반대입니다.

미국 FAA 규정상 기장은 6개월마다 반복 훈련이나 숙련도 검사를 받아야 하고, 이 과정에서 이륙 중 엔진 고장 같은 비정상적인 상황을 시뮬레이터로 연습합니다.

발생 가능성은 낮지만,

발생했을 때 인간의 판단이 결정적이기 때문입니다.

소프트웨어에도 Incident Simulator가 필요하다

그렇다면 SRE와 Platform Engineering 조직에도 비슷한 것이 필요하지 않을까요?

Kalache의 제안은 Incident Simulation을 On-call Readiness의 일부로 만드는 것입니다.

Rootly와 Uptime Labs는 실제로 이런 형태의 Incident Simulation을 만들고 있다고 설명합니다.

엔지니어가 Incident Commander가 됩니다.

가상의 이커머스 서비스에서 장애가 발생합니다.

Observability Tool을 사용해 문제를 조사합니다.

동시에 Slack에서는 LLM으로 구현된 이해관계자들이 메시지를 보냅니다.

CEO가 상황을 묻습니다.

Customer Support가 고객 영향을 확인합니다.

엔지니어는 시스템을 디버깅하면서 동시에 Incident 전체를 운영해야 합니다.

실제 장애 대응에서 필요한 능력은 단순히 로그를 읽는 것만이 아니기 때문입니다.

불완전한 정보에서 상황을 이해하고,

가설을 세우고,

우선순위를 정하고,

사람들을 조율하고,

정확하게 커뮤니케이션해야 합니다.

이것은 Runbook을 읽는 것만으로 익힐 수 없습니다.

AI에게 설명을 듣는 것과 직접 장애를 해결하는 것은 다르다

물론 다른 방법도 있습니다.

AI에게 이렇게 물어볼 수 있습니다.

왜 이 장애라고 판단했는지.

어떤 Signal을 확인했는지.

어떤 Evidence를 근거로 결론을 내렸는지.

왜 이 Fix를 선택했는지.

AI가 수행한 Incident Response 전체를 설명하게 할 수 있습니다.

좋은 학습 방법입니다.

하지만 Kalache는 이것만으로는 충분하지 않다고 지적합니다.

그가 든 비유가 재미있습니다.

Serena Williams의 경기를 아무리 많이 봐도 그것만으로 테니스를 잘할 수는 없습니다.

테니스를 배우려면 결국 코트에 나가야 합니다.

Incident Response도 마찬가지입니다.

관찰과 설명은 이해를 돕지만,

실제 상황에서 가설을 만들고 틀리고 다시 조사하는 경험을 완전히 대체하지는 못합니다.

새로운 기술 부채: Comprehension Debt

이 글에서 특히 흥미로운 표현이 하나 있습니다.

Comprehension Debt.

시스템이 실제로 어떻게 동작하는지와,

운영자가 그 시스템을 얼마나 이해하고 있는지 사이의 격차입니다.

기존에도 우리는 Technical Debt를 관리했습니다.

복잡한 Legacy Code.

낡은 Dependency.

임시로 만든 Architecture.

자동화되지 않은 운영 절차.

그런데 AI 시대에는 또 하나의 부채를 관리해야 할지도 모릅니다.

시스템은 계속 진화하는데 사람의 이해는 따라가지 못하는 상태입니다.

AI가 코드를 작성합니다.

AI가 Deployment를 분석합니다.

AI가 Alert를 Triage합니다.

AI가 Root Cause를 찾습니다.

AI가 Incident까지 해결합니다.

각 단계에서 인간이 시스템과 직접 접촉하는 시간은 줄어듭니다.

그러면 어느 순간 조직에는

시스템을 운영하고 있지만 시스템을 깊게 이해하는 사람은 점점 줄어드는

상황이 생길 수 있습니다.

평소에는 문제가 없습니다.

AI가 대부분 처리하기 때문입니다.

진짜 문제는 AI가 모르는 사건이 발생했을 때 나타납니다.

Chaos Engineering의 의미도 달라진다

Chaos Engineering은 새로운 개념이 아닙니다.

일부러 장애를 만들고 시스템의 복원력을 검증합니다.

Tabletop Exercise 역시 오래전부터 존재합니다.

하지만 LLM과 AI Agent가 운영 업무를 가져가기 시작하면 이런 훈련의 의미가 조금 달라집니다.

과거에는 주로

“시스템이 장애를 견딜 수 있는가?”

를 테스트했다면,

앞으로는

“사람이 여전히 장애를 해결할 수 있는가?”

도 함께 테스트해야 합니다.

예를 들어 이런 훈련이 필요할 수 있습니다.

AI Incident Agent를 의도적으로 끈 상태에서 장애 대응하기.

Runbook에 없는 장애를 해결하기.

Observability 데이터 일부가 없는 상태에서 조사하기.

여러 서비스가 동시에 실패하는 상황 처리하기.

SEV0 상황에서 Incident Commander 역할 수행하기.

Rollback과 Roll-forward 중 하나를 결정하기.

기술적 원인 분석뿐만 아니라 경영진과 고객지원팀에 상황 설명하기.

이것은 장애 테스트인 동시에 사람의 Operational Readiness 테스트입니다.

결국 AI SRE의 목표는 사람을 없애는 것이 아니다

AI Incident Response가 나쁘다는 이야기는 아닙니다.

반대로 Routine Incident를 AI에게 넘기는 것은 상당히 좋은 방향입니다.

새벽마다 Capacity Alarm 때문에 엔지니어를 깨우는 조직이 좋은 조직일 이유도 없습니다.

AI가

Noise를 제거하고Telemetry를 조사하고기존 장애와 비교하고Runbook을 실행하고안전한 Fix를 자동으로 적용하는 것

자체는 분명한 발전입니다.

하지만 자동화의 목표를

“Human을 Incident Response에서 완전히 제거하는 것”

으로 잡으면 다른 문제가 생깁니다.

더 현실적인 목표는

AI가 평범한 장애를 해결하면서도 인간이 시스템에 대한 이해와 문제 해결 능력을 유지하도록 만드는 것

일 가능성이 높습니다.

앞으로 SRE의 KPI에는 하나가 더 필요할지도 모른다

지금까지 Reliability 조직은 이런 수치를 봐왔습니다.

MTTDMTTRAvailabilityError BudgetIncident CountChange Failure Rate

AI가 Incident Response를 담당하기 시작하면 새로운 질문이 필요합니다.

우리 엔지니어들은 이 시스템을 아직 이해하고 있는가?

측정하기 어려운 질문입니다.

하지만 Incident Simulation을 활용하면 어느 정도 확인할 수 있습니다.

AI 도움 없이 Root Cause를 찾는 데 얼마나 걸리는지.

Unknown Incident에서 어떤 가설을 세우는지.

Observability Signal을 얼마나 정확하게 읽는지.

Critical Incident에서 의사결정을 얼마나 잘하는지.

Incident Communication을 제대로 수행하는지.

어쩌면 앞으로 On-call Readiness는 단순히 Pager Rotation에 이름을 올리는 것이 아니라,

정기적인 Incident Simulation을 통과한 사람만 On-call에 참여하는 형태로 발전할 수도 있습니다.

항공업계가 오랫동안 해온 것처럼 말입니다.

자동화의 성공이 인간의 실패를 준비할 수도 있다

AI 시대에 반복적으로 등장하는 역설이 있습니다.

AI가 코드를 더 많이 작성할수록 사람은 코드를 덜 읽게 됩니다.

AI가 시스템을 더 많이 운영할수록 사람은 시스템을 덜 만지게 됩니다.

AI가 Incident를 더 잘 해결할수록 사람은 Incident를 해결할 기회가 줄어듭니다.

그리고 어느 순간

AI가 해결하지 못하는 문제만 인간에게 남습니다.

그런데 바로 그 문제들이 가장 어렵습니다.

그래서 Automation이 발전할수록 인간의 훈련이 덜 필요한 것이 아닙니다.

오히려 반대입니다.

Routine은 AI에게 맡기더라도Rare Failure는 인간이 계속 연습해야 합니다.

Kalache가 마지막에 지적한 자동화의 아이러니도 여기에 있습니다.

자동화가 성공할수록,

우리는 자동화가 실패하는 순간에 더 준비되어 있지 않을 수 있습니다.

AI SRE 시대의 중요한 과제는 그래서 단순히

“얼마나 많은 Incident를 자동화했는가?”

가 아닐지도 모릅니다.

더 중요한 질문은 이것입니다.

“자동화 이후에도 우리 조직에는 시스템을 직접 이해하고, 가장 어려운 장애를 해결할 수 있는 사람이 남아 있는가?”

원문: Sylvain Kalache, AI handles incidents, engineers lose touch with their systems (2026.09.04)