AI가 장애를 대신 처리할수록 엔지니어는 시스템을 잊는다

출처: Sylvain Kalache (Rootly AI Labs 리드, 전 LinkedIn SRE)
원문: https://www.sylvainkalache.com/blog/ai-handles-incidents-engineers-lose-touch-with-their-systems
작성자: 팔복소프트-김팔복

한눈에 보기

• 알림 분석부터 원인 추정, 수정 적용까지 해주는 "AI SRE" 도구가 이미 실전에 투입되고 있다.
• 필자는 이 도구가 일상적인 장애를 대신 처리할수록 엔지니어가 시스템에 대한 감각을 잃는다고 경고한다.
• 결과적으로 평균 복구 시간(MTTR)은 내려가지만, AI가 못 푸는 복잡한 장애의 복구 시간은 오히려 늘어날 것이라고 예측한다.
• 이 문제는 1983년 Lisanne Bainbridge의 논문 "The Ironies of Automation"에서 이미 지적된 자동화의 역설이다.
• 해법으로 항공 업계처럼 정기적인 시뮬레이터 훈련을 제안하며, Rootly와 Uptime Labs가 실제로 장애 시뮬레이션을 만들고 있다.
• AI에게 "왜 그렇게 판단했는지" 설명을 듣는 것은 도움이 되지만, 직접 해보는 연습을 대체하지는 못한다.

배경

최근 1~2년 사이 장애 대응 자동화가 빠르게 발전했다. 예전의 자동화가 "CPU 80% 넘으면 인스턴스 추가" 같은 규칙 기반이었다면, 지금의 LLM 기반 도구는 알림을 받고 관련 메트릭과 로그를 직접 조회하고, 최근 배포 이력과 대조해 가설을 세운 뒤, 롤백이나 설정 변경까지 스스로 실행한다. 이 글의 필자는 2012년 LinkedIn에서 자가 치유 시스템 프로토타입을 직접 만들었던 SRE 출신이고, 지금은 장애 관리 서비스 Rootly에서 AI 연구를 이끌고 있다. 즉 자동화를 반대하는 입장이 아니라, 자동화를 가장 적극적으로 만드는 쪽에서 나온 경고라는 점이 이 글의 무게다.

자동화가 사람에게 남기는 것은 가장 어려운 장애뿐이다

필자의 핵심 논리는 단순하다. 엔지니어는 야간에 걸려오는 용량 부족 알림, 디스크 풀, 재시작으로 해결되는 메모리 누수 같은 "뻔한" 장애를 반복해서 겪으면서 시스템이 어떻게 무너지는지 몸으로 배운다. 그런데 AI가 이런 장애를 전부 가져가면 배울 기회가 사라진다. 그리고 AI가 손을 드는 장애는 정의상 전례 없고 모호하며 심각도가 높은 사건이다. 훈련은 줄었는데 맡는 문제는 더 어려워지는 구조다.

이 역설은 새로운 발견이 아니다. 인간공학 연구자 Lisanne Bainbridge가 1983년에 쓴 "The Ironies of Automation"이 정확히 같은 지적을 했다. 자동화는 운영자가 일상 업무를 연습할 기회를 빼앗으면서 비정상 상황에 대한 책임은 그대로 남기므로, 자동화 이후의 운영자는 오히려 더 숙련되고 더 많은 훈련을 받아야 한다는 것이다. 40년 넘은 논문이 LLM 시대의 SRE 조직에 그대로 적용된다.

필자는 이를 근거로 앞으로 몇 년간 대부분 장애의 MTTR은 AI 덕분에 내려가겠지만, 복잡한 장애의 해결 시간은 대응자들이 시스템 감각을 잃어 오히려 치솟을 것이라고 예측한다.

항공 업계는 어떻게 해결했나

원문은 항공 업계를 참고 사례로 든다. 오늘날 비행의 상당 부분은 자동화가 담당하지만, 엔진 고장이나 계기 오작동 같은 비정상 상황은 여전히 조종사 몫이다. 현대 터빈 엔진의 비행 중 정지는 엔진 비행시간 10만 시간당 1건 미만으로, 조종사 한 명이 경력 내내 시뮬레이터 밖에서 한 번도 겪지 않을 수 있는 수준이다.

그럼에도 이런 상황이 닥쳤을 때 잘못 대응하면 결과는 치명적이다. 원문이 인용한 TransAsia Airways 235편 사고에서는 이륙 직후 오른쪽 엔진 프로펠러가 자동으로 페더링됐고, 기체는 왼쪽 엔진만으로 비행할 수 있게 설계돼 있었지만 승무원이 문제를 잘못 판단해 첫 경고 후 117초 만에 실속·추락했다.

그래서 항공 업계는 훈련을 제도화했다. 미국 FAA 규정상 기장은 6개월마다 이륙 중 엔진 고장 같은 시나리오를 포함한 반복 훈련이나 숙련도 점검을 받아야 한다. 필자는 소프트웨어 장애가 생명을 위협하지 않더라도 같은 접근이 필요하다고 본다.

소프트웨어에도 장애 시뮬레이터가 필요하다

필자가 속한 Rootly는 Uptime Labs와 협력해 실제와 유사한 장애 시뮬레이션을 만들었다. 참가자는 가상의 이커머스 서비스 장애에서 인시던트 커맨더 역할을 맡아 관측 도구로 원인을 조사하는 동시에, Slack에서 LLM이 연기하는 CEO나 고객지원팀 같은 이해관계자를 상대한다. 불완전한 정보로 판단하기, 명확하게 소통하기, 사람들을 조율하기 같은 실제 장애 대응에서 중요한 기술을 연습하는 것이 목적이다.

AI를 트레이너로 쓰는 방식도 언급된다. AI 에이전트에게 어떤 단계를 밟았고 어떤 신호를 봤으며 진단의 근거가 무엇인지 설명하게 하는 것이다. 다만 필자는 설명을 듣고 관찰하는 것이 직접 연습을 대신할 수는 없다고 선을 긋는다. 이 주장의 배경에는 필자가 Holberton School이라는 소프트웨어 교육 기관을 공동 창업하며 얻은 경험이 있다. Dropbox가 채용한 졸업생들의 트러블슈팅 경험이 부족하다고 피드백하자, 일부러 망가뜨린 인프라를 학생에게 주고 진단·복구하게 하는 프로젝트를 만들었다는 것이다.

원문은 이 문제를 "comprehension debt(이해 부채)"라는 말로 요약한다. 시스템이 실제로 동작하는 방식과 대응자가 이해하는 수준 사이의 격차가, 기술 부채처럼 조용히 쌓인다는 뜻이다.

기존 방식과의 비교

원문에서 언급한 방법들을 정리하면 다음과 같다. 이 표는 원문에 없는 편집자의 정리다.

팔복소프트 관점

이 글은 국내 환경에서 더 뼈아프게 읽힌다. 국내 대부분의 팀은 전담 SRE 조직 없이 백엔드 개발자가 온콜을 겸하는 구조이고, 그마저도 소수 인원이 돌아가며 맡는다. 이런 팀에 AI SRE 도구가 들어오면 "드디어 밤에 안 깨도 된다"는 효과가 즉각적이라 도입 동기는 충분하다. 문제는 원래도 장애 경험이 얇았던 조직이 남은 경험마저 AI에 넘긴다는 점이다. 이미 SRE가 수십 명인 미국 빅테크보다 국내 스타트업과 중견 SI 조직이 이 역설에 더 취약하다.

또 하나 짚을 점은 원문이 다루지 않은 "AI가 틀리게 고치는" 경우다. 자동 롤백이나 설정 변경을 AI가 잘못 실행했을 때, 그것이 잘못됐다는 사실을 알아채려면 시스템의 정상 상태를 아는 사람이 있어야 한다. 시스템 감각의 상실은 어려운 장애를 못 푸는 문제일 뿐 아니라 AI의 오판을 검증하지 못하는 문제로도 이어진다.

원문이 홍보하는 시뮬레이션 상품을 당장 도입할 필요는 없다. 대신 지금 바로 할 수 있는 것부터 권한다. 첫째, AI 도구가 처리한 장애도 주간 회고에서 사람이 한 번 되짚어 "내가 맡았다면 어디를 봤을까"를 확인한다. 둘째, 스테이징 환경에서 분기에 한 번이라도 특정 서비스를 일부러 죽이고 신입이나 온콜 경험이 적은 사람에게 커맨더를 맡긴다. 이미 쓰고 있는 Grafana, Datadog, 로그 스택과 Slack만 있으면 된다. 셋째, AI 도구의 자동 실행 권한을 처음부터 다 열지 말고 "진단까지만, 실행은 사람 승인"으로 시작해 사람이 판단 과정에 계속 참여하게 한다.

아쉬운 점도 있다. 원문은 문제 제기와 방향 제시에 집중하고 있어, 시뮬레이션이 실제로 대응 역량을 얼마나 올리는지에 대한 데이터는 없다. 항공 업계처럼 규제가 훈련을 강제하지 않는 소프트웨어 업계에서 바쁜 팀이 훈련 시간을 꾸준히 확보할 수 있느냐는 별개의 조직 문제이고, 그 부분은 원문도 답하지 않는다.

정리

AI 장애 대응 도구는 쓰지 않을 이유가 없지만, 그것이 가져가는 것이 알림뿐만 아니라 팀의 학습 기회라는 점을 알고 써야 한다. 기억할 것은 하나다. 자동화가 잘 될수록 사람이 맡을 장애는 더 어려워지므로, 훈련은 줄이는 게 아니라 늘려야 한다. 도구가 처리한 장애를 되짚어보는 습관과 정기적인 모의 장애 훈련은 AI 도구 도입 예산에 함께 포함시켜야 할 항목이다.

• SRE
• 장애대응
• AI에이전트
• 온콜
• 카오스엔지니어링