인지적 부채 - AI가 장애를 처리할수록 엔지니어는 시스템 감각을 잃는다

https://www.sylvainkalache.com/blog/ai-handles-incidents-engineers-lose-touch-with-their-systems

2026.9.4
[AI handles incidents, engineers lose touch with their systems]

이 글은 AI 자동화가 시스템 장애를 해결할수록 엔지니어가 실무 감각을 잃게 되는 '자동화의 역설'을 경고하며 이를 해결할 방안을 제시합니다. 저자는 일상적인 문제를 AI가 처리함에 따라 사람이 숙련도를 쌓을 기회가 사라지고, 결국 기술이 해결하지 못하는 복잡한 위기 상황에서 대응 능력이 저하되는 이해력 부채가 발생한다고 지적합니다. 항공 산업의 훈련 방식을 예로 들어, 엔지니어 역시 AI가 제공하는 단순 설명을 넘어 직접적인 실습과 모의 훈련을 통해 시스템에 대한 통찰력을 유지해야 한다고 주장합니다. 결론적으로 AI 시대의 엔지니어링 팀은 기술에만 의존하기보다 시뮬레이션을 통해 인적 대응 역량을 강화하는 데 더욱 집중해야 한다는 것이 핵심입니다.

 

 

「AI가 장애를 처리할수록, 엔지니어는 시스템과 멀어진다」 챕터별 분석

핵심은 “AI를 쓰지 말자”가 아니라, “장애 대응 자동화와 인간의 대응 역량 유지 체계를 함께 설계하자”입니다. 저자는 일상적인 장애를 AI에 맡기면 운영 부담은 줄지만, 사람이 시스템을 이해하고 진단 능력을 기르는 기회도 줄어든다고 경고합니다.[1]

원문은 도입부와 5개 본문 챕터로 구성되어 있습니다. 아래에서는 원문의 주장과 근거를 먼저 설명하고, 별도로 분석·한계·실무 적용을 구분합니다.

 

0. 도입부 — 자가복구의 실현과 새로운 위험

원문 내용

Sylvain Kalache는 2012년 LinkedIn의 SRE로 근무할 당시, 스스로 복구하고 이전 장애에서 학습하는 시스템을 설계했지만 당시에는 프로토타입에 머물렀다고 회고합니다. 이제 AI 도구는 알림 검토, 가설 수립, 텔레메트리 조회, 최근 배포와의 연관 분석, 수정 실행까지 수행할 수 있다는 것이 저자의 설명입니다.[1]

그러나 저자는 다음의 역설을 제기합니다.

일상적인 장애를 AI가 더 잘 해결할수록 인간은 대응 경험을 덜 쌓고, AI가 풀지 못하는 모호하고 심각한 장애에서는 준비가 부족한 상태로 투입될 수 있다.[1]

분석

이 글이 문제 삼는 것은 단순한 작업 자동화가 아니라 경험을 통한 학습 경로의 자동화입니다.

기존에는 장애 대응 업무가 두 가지 기능을 동시에 수행했습니다.

• 운영 기능: 서비스 복구
• 학습 기능: 시스템의 정상·비정상 동작에 대한 이해 축적

AI가 첫 번째 기능을 대체한다고 해서 두 번째 기능까지 자동으로 보존되는 것은 아닙니다.

분석적 해석: 도입 효과를 “사람이 처리한 장애 건수가 줄었다”로만 평가하면, 같은 변화가 운영 효율 향상인지 대응 역량 약화인지 구분하기 어렵습니다.

근거의 한계

도입부는 저자의 경험과 기술 변화에 대한 서술입니다. 특정 AI 도구의 자율복구 성공률이나 인간의 숙련도 감소를 측정한 결과는 제시하지 않습니다. 따라서 “이미 모든 조직에서 역량 저하가 발생했다”는 실증적 결론으로 읽어서는 안 됩니다.

 

1. Automation leaves humans with the hardest incidents

자동화는 인간에게 가장 어려운 장애를 남긴다

① 핵심 주장

저자는 야간의 단순 용량 문제처럼 반복적인 장애를 AI가 처리하는 것은 분명 유익하다고 인정합니다. 다만 이런 장애는 엔지니어가 비교적 안전하게 시스템의 동작과 실패 양상을 익히는 기회이기도 합니다.[1]

이를 자동화하면 인간에게는 다음과 같은 장애가 남습니다.

• 처음 보는 장애
• 원인이 모호한 장애
• 기존 해결 방식이 통하지 않는 장애

즉, 연습 기회는 줄고, 직접 대응해야 할 문제의 난도는 높아지는 구조입니다.[1]

② 근거 — Bainbridge의 ‘자동화의 아이러니’

저자는 Lisanne Bainbridge의 1983년 논문 Ironies of Automation을 인용합니다.[1]

원 논문에서도 자동화 이후 인간은 시스템 감시와 비정상 상황의 인계를 담당하지만, 사용하지 않는 수동 제어 능력은 저하될 수 있고, 진단에 필요한 지식도 사용과 피드백을 통해 발전한다고 설명합니다. 특히 자동화에서 수동 제어로 전환하는 순간에는 오히려 평상시보다 높은 숙련도가 필요할 수 있다고 지적합니다.[2]

③ 중요한 전망 — 평균 MTTR과 복잡한 장애의 복구시간

저자는 AI 덕분에 대부분의 장애에 대한 평균 MTTR은 낮아지지만, 복잡한 장애의 해결시간은 크게 늘어날 수 있다고 예측합니다.[1]

여기서 구분할 점은 다음과 같습니다.

항목	원문에서의 성격
자동화가 반복 업무의 경험 기회를 줄인다는 문제	기존 인간요인 연구를 바탕으로 한 주장
AI 도입 후 대부분의 장애 MTTR 감소	저자의 전망
복잡한 장애의 해결시간 증가	저자의 전망
증가 폭·발생 시점·조직별 차이	원문에 측정값 없음

④ 분석 및 실무 시사점

분석적 해석: 전체 평균 복구시간이 좋아졌다는 사실만으로 중대 장애 대응 능력까지 좋아졌다고 판단할 수 없습니다.

따라서 AI 운영 성과를 평가할 때는 다음 항목을 분리하는 것이 적절합니다.

• 반복 장애와 신규 장애
• AI 단독 해결과 인간 인계
• 심각도별 복구시간
• 인계 이후 인간이 상황을 파악하는 시간
• 잘못된 조치와 재발 여부

[보완 필요] AI 도입 성과지표에 ‘인간 인계 이후의 대응 성능’을 포함할 필요가 있습니다. 이는 원문에 제시된 정량 지표가 아니라, 글의 문제의식을 운영 평가체계로 확장한 제안입니다.

 

2. Aviation trains pilots for rare failures

항공업은 드문 실패에 대비해 조종사를 훈련한다

① 핵심 주장

저자는 항공업을 비교 사례로 사용합니다. 자동화가 비행의 상당 부분을 담당하더라도 조종사는 엔진 고장, 계기 이상, 이륙 중단, 실속과 같은 비정상 상황에 대한 책임을 유지합니다.[1]

이처럼 실제 경험이 드문 사건에서는 현장 경험만으로 숙련도를 유지하기 어렵기 때문에 시뮬레이터 훈련이 필요하다는 논리입니다.

② 원문에서 제시한 사례와 수치

원문은 다음 내용을 소개합니다.

• 현대 터빈 엔진의 비행 중 정지 빈도가 엔진 비행시간 10만 시간당 1회 미만이라는 설명
• TransAsia Airways Flight 235에서 오른쪽 엔진의 프로펠러가 자동 페더링된 뒤 승무원이 문제를 잘못 식별했고, 첫 경고 후 117초 만에 실속·추락했다는 사례
• 미국 FAA 규정상 기장이 6개월 주기의 훈련 또는 숙련도 점검을 받는다는 설명[1]

검증 범위: 엔진 고장 빈도와 사고의 117초 수치는 이번 분석에서는 원문 인용으로 취급하며, 별도 사고조사보고서나 통계자료까지 독립 검증한 것은 아닙니다.

③ FAA 규정 확인

확인한 14 CFR §121.441(a)(1)은 해당 규정의 적용을 받는 기장에 대해 다음을 요구합니다.

• 이전 12개월 이내 해당 항공기 유형의 숙련도 점검
• 추가로 이전 6개월 이내 숙련도 점검 또는 승인된 전비행 시뮬레이터(FFS) 훈련 과정 이수[3]

따라서 원문의 “6개월마다 훈련 또는 점검”은 핵심 취지를 전달하지만, 이를 모든 조종사에게 동일하게 적용되는 일반 규정으로 확대해서는 안 됩니다.

④ 분석 — 옮겨야 할 것은 훈련 주기가 아니라 설계 원리

항공과 소프트웨어 운영은 시스템 변화 속도, 실패 양상, 시뮬레이션 환경 등에서 차이가 있습니다. 따라서 소프트웨어 조직에 항공의 훈련 주기를 그대로 적용하는 것은 근거가 부족합니다.

그럼에도 다음 원리는 유효한 운영 설계 관점입니다.

드물지만 영향이 큰 사건에 대한 준비도를 실제 사건의 발생 빈도에 맡기지 않는다.

실무 적용 제안: 정기 훈련뿐 아니라 아키텍처 변경, 핵심 담당자 교체, 자동복구 범위 확대 시점에 대응 훈련을 연계하는 방식이 적절합니다.

 

3. The software industry needs incident simulators

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

① 원문 내용

저자는 자신이 근무하는 장애 관리 기업 Rootly가 Uptime Labs와 협력하여 Rootly Academy를 운영한다고 소개합니다.[1]

설명된 훈련은 다음과 같습니다.

• 전자상거래 서비스 장애를 모의 환경에서 재현
• 엔지니어가 장애 대응 지휘자, 즉 Incident Commander 역할 수행
• 관측 도구를 사용해 원인 조사
• Slack에서 LLM 기반 이해관계자와 소통
• CEO와 고객지원 조직의 요구에 대응하면서 복구 활동 조정[1]

② 핵심 분석 — 기술 진단만으로는 대응 역량을 설명할 수 없다

이 챕터에서 중요한 점은 훈련 대상이 로그 분석이나 복구 명령 실행에 한정되지 않는다는 것입니다.

역량	훈련에서 다루는 내용
기술 진단	불완전한 정보에서 원인 가설 수립
대응 지휘	역할 배분과 대응 활동 조직화
커뮤니케이션	경영진·고객지원에 상황 설명
판단	시간 압박 속에서 다음 행동 선택

저자는 이러한 조사·소통·조정·대응 실행 능력을 함께 연습해야 한다고 강조합니다.[1]

분석적 해석: 실무에서 필요한 것은 ‘정답을 찾는 능력’뿐 아니라, 정답이 아직 없을 때 조직이 어떻게 움직일지를 결정하는 능력입니다.

③ 근거의 한계 — 제품 소개와 효과 검증은 다르다

이 챕터는 저자가 소속된 기업의 서비스를 소개하는 부분입니다. 원문에는 다음 결과가 제시되지 않습니다.

• 훈련 참여자 수와 비교집단
• 훈련 전후 대응시간
• 실제 장애에서의 성과 변화
• 학습효과의 유지 기간
• 비용 대비 효과

따라서 “훈련 구성이 문제의식에 부합한다”와 “그 훈련의 효과가 검증됐다”는 별개의 판단입니다.

[확인 필요] 도입 검토 시에는 몰입감이나 사용자 만족도 외에, AI 없이 수행하는 대응 평가와 실제 서비스로의 학습 전이 여부를 확인해야 합니다.

 

4. AI can also help preserve these skills

AI는 대응 역량을 유지하는 도구로도 활용할 수 있다

① 핵심 주장

저자는 AI가 수행한 단계, 검토한 신호, 진단의 근거를 설명하도록 요청하면 학습에 도움이 될 수 있다고 봅니다. 그러나 설명을 듣거나 관찰하는 것은 직접 연습하는 것을 대체하지 못한다고 강조합니다.[1]

이를 테니스 경기 관람과 직접 경기하는 것의 차이에 비유합니다.

② 교육 경험에서 나온 근거

저자는 실습 중심 소프트웨어 교육기관을 운영했던 경험을 소개합니다. Dropbox가 채용한 졸업생들의 문제 해결 경험이 부족하다고 피드백하자, 고장 난 인프라를 제공하고 학생이 직접 진단·수리하는 프로젝트를 만들었다고 설명합니다.[1]

이는 현장 경험에 기반한 사례이지, 실습교육과 설명식 교육의 효과를 정량 비교한 통제실험은 아닙니다.

③ 분석 — ‘설명 가능성’과 ‘대응 가능성’의 차이

구분	AI 설명을 읽는 학습	직접 수행하는 학습
가설 수립	이미 제시된 가설을 이해	스스로 후보를 생성
증거 선택	AI가 고른 신호를 확인	무엇을 조회할지 결정
오류 처리	정리된 결론을 읽음	틀린 가설을 수정
시간 압박	제한적	훈련 조건에 따라 재현 가능
판단 책임	주로 AI의 판단을 검토	자신의 행동을 결정

분석적 해석: AI의 보고서를 잘 이해하는 사람과 AI가 없는 상황에서 시스템을 복구할 수 있는 사람은 동일하지 않을 수 있습니다.

또한 학습용 설명에서는 AI의 사후 설명만을 정답으로 삼기보다, 실제 조회 기록·변경 기록·복구 결과와 연결해 확인하도록 설계하는 것이 바람직합니다. 이는 원문을 확장한 권고입니다.

④ 적용 제안 — AI를 정답 제공자보다 코치로 사용

학습 목적이라면 다음 순서가 적절합니다.

1. 엔지니어가 먼저 원인 가설과 다음 조회 대상을 제시

1. AI가 정답 대신 반례나 추가 질문 제공

1. 엔지니어가 진단·복구 조치 수행

1. 실제 증거와 결과를 확인

1. 종료 후 AI와 함께 판단 과정을 복기

이 방식의 목적은 AI 활용을 줄이는 것이 아니라, 인간이 수행해야 할 사고 과정을 보존하는 것입니다.

 

5. Incident simulation should become part of on-call readiness

장애 대응 시뮬레이션을 온콜 준비도의 일부로 편입해야 한다

① 핵심 개념 — Comprehension debt

저자는 LLM이 더 많은 일을 수행할수록 조직에 comprehension debt, 즉 시스템이 실제로 작동하는 방식과 대응자가 이를 이해하는 수준 사이의 격차가 누적될 수 있다고 설명합니다.[1]

여기서는 이를 ‘시스템 이해 부채’로 해석할 수 있습니다.

• 기술부채가 시스템의 변경·유지 비용과 관련된 문제라면,
• 시스템 이해 부채는 장애 시 진단·판단에 필요한 이해가 부족해지는 문제로 볼 수 있습니다.

이 비교는 분석적 설명이며, 원문이 두 부채의 관계를 정식 모델로 제시한 것은 아닙니다.

② 원문의 권고

저자는 엔지니어가 정기적으로 다음 활동을 수행해야 한다고 주장합니다.

• 담당 시스템과 직접 상호작용
• 익숙하지 않은 실패 대응
• 압박 상황에서의 업무 수행
• SEV0 수준 대응의 조정·커뮤니케이션 연습
• 테이블톱 훈련과 카오스 엔지니어링 활용[1]

③ 원 논문을 확인하면 드러나는 추가 한계

Bainbridge는 실제 조작 기회나 시뮬레이터를 통해 능력을 유지하는 방안을 제시하면서도, 알려지지 않은 실패를 모두 시뮬레이션할 수는 없다고 지적합니다. 따라서 특정 장애의 정답만 반복 훈련하기보다 일반적인 문제 해결 전략을 가르쳐야 한다고 설명합니다.[2]

이 부분은 중요한 보완점입니다.

장애 시뮬레이션은 모든 미래 장애를 미리 경험하게 하는 장치가 아니라, 처음 보는 장애에 접근하는 방법을 연습하는 장치입니다.

④ 분석 — 인간을 최종 안전장치로 두려면 인계 가능성을 입증해야 한다

원 논문은 자동화된 시스템의 현재 상태를 이해하는 데 시간이 필요하며, 매우 빠른 실패에서는 인간의 즉각적인 개입을 기대하는 대신 신뢰할 수 있는 자동 대응이 필요할 수 있다고도 설명합니다.[2]

따라서 “AI가 실패하면 사람이 처리한다”는 운영 원칙만으로는 충분하지 않습니다.

실무 적용 제안:

• 사람이 인계받을 수 있는 시간적 여유가 있는가?
• AI가 어떤 조치를 이미 수행했는지 알 수 있는가?
• 원시 로그와 실제 상태에 직접 접근할 수 있는가?
• 자동화를 중지하고 롤백할 권한이 있는가?
• AI 자체나 관측 도구가 장애를 일으켜도 대응할 수 있는가?

훈련과 함께 인계 정보·접근권한·안전 정지·복구 경로를 설계해야 한다는 의미입니다.

 

6. 글 전체의 논증과 평가

논증 구조

• AI가 반복 장애를 처리
• ↓
• 인간의 직접 대응·학습 기회 감소
• ↓
• 시스템 이해와 숙련도 약화 가능성
• ↓
• AI가 해결하지 못하는 어려운 장애를 인간이 인계
• ↓
• 준비가 부족한 상태에서 고난도 판단 요구
• ↓
• 실습·시뮬레이션을 온콜 준비도 체계에 편입

이 흐름은 원문을 종합한 것이며, 각 단계의 발생률이나 효과 크기가 측정된 인과모형은 아닙니다.

강점과 한계

평가 항목	분석
문제 정의	자동화의 편익뿐 아니라 학습 기회의 소실을 짚는다는 점에서 유용
이론적 기반	Bainbridge의 자동화·수동 인계 문제와 연결되며, 원 논문에서도 취지를 확인할 수 있음
해결 방향	수동 관찰보다 직접 수행, 기술 대응뿐 아니라 지휘·소통 훈련을 강조
실증성	AI 도입 이후 숙련도와 복잡한 장애의 복구시간 변화를 측정한 자료는 없음
이해관계	저자가 소속된 Rootly의 교육 서비스를 사례로 제시하므로 효과 주장과 제품 소개를 구분할 필요
완결성	훈련의 필요성은 잘 설명하지만, 자동화 실패 시의 권한·정보·안전 경계는 상세히 다루지 않음

종합 판단: 이 글은 검증된 성과보고서라기보다, 기존 인간요인 연구를 AI 기반 장애 대응에 적용한 운영 설계 경고와 훈련 방향 제안으로 읽는 것이 적절합니다.

 

출처

[1] Sylvain Kalache — AI handles incidents, engineers lose touch with their systems
[2] Lisanne Bainbridge — Ironies of Automation, Automatica 19(6), 775–779, 1983 원문 PDF
[3] 14 CFR §121.441 — Proficiency checks, Cornell LII 수록 규정