AI가 인시던트를 처리할수록 엔지니어는 시스템과 멀어진다 (Sylvain Kalache)

자동화의 아이러니 — AI 타워가 루틴 장애를 막는 동안 전사의 무기는 녹슬고, 지평선엔 타워가 감당 못 할 폭풍이 온다 AI 자동 방어 ! ! 루틴 장애 AI 방어 타워 · 자동 요격 Z z z 잠든 전사 · 녹스는 무기 (연습 기회 상실) 신형 장애 · 다가오는 폭풍 자동화의 사거리 밖
자동화의 아이러니 — AI 타워가 루틴 장애를 자동 요격하는 동안 전사들은 잠들고 무기는 녹슨다. 지평선엔 타워가 감당 못 할 폭풍(신형 장애)이 다가온다.

원문 정보

AI 시대의 탈숙련(deskilling) 논의를 인시던트 대응(incident response)이라는 구체적 영역으로 좁혀, 항공 산업의 훈련 체계에서 실천적 해법까지 끌어낸 글이라 Articles에 담는다.

한 줄 요약 (TL;DR)

AI 인시던트 대응 도구가 루틴한 장애를 잘 처리할수록 인간 엔지니어는 시스템 감각을 기를 연습 기회를 잃는다 — 그래서 정작 자동화가 감당 못 하는 복잡하고 새로운 장애가 터졌을 때 가장 준비되지 않은 상태가 된다. 해법은 항공 산업처럼 정기적인 인시던트 시뮬레이션 훈련을 on-call 준비 태세의 일부로 만드는 것이다.

왜 이 글을 골랐나

“AI가 실력을 망치는가”라는 논의는 이 위키에서도 여러 번 다뤘다. Nature의 탈숙련 기사 분석이 의사·개발자의 실력 저하를 데이터로 보여줬다면, 이 글은 같은 문제를 운영(operations)이라는 가장 위험한 영역에서 짚는다. 코드 리뷰 실력이 무뎌지는 것과 새벽 3시 SEV0 대응 실력이 무뎌지는 것은 결과의 무게가 다르다.

글의 척추가 되는 인과 사슬과, 그 사슬을 끊는 개입 지점을 한 장으로 요약하면 이렇다.

flowchart TB
    A["AI가 루틴 인시던트를 처리<br/>(평균 MTTR ↓ — 지표상 성공)"] --> B["인간 대응자의<br/>연습 기회 감소"]
    B --> C["시스템 직관·감각 퇴화<br/>(comprehension debt 축적)"]
    C --> D["자동화가 감당 못 하는<br/>복잡·신형 장애 발생"]
    D --> E["준비 안 된 인간이<br/>최악의 순간에 투입"]
    S["정기 인시던트 시뮬레이션 훈련<br/>(항공식 recurrent training)"] -. "사슬을 끊는 개입 —<br/>잃어버린 연습을 제도로 복원" .-> B

특히 이 글이 좋은 점은 1983년 Lisanne Bainbridge의 고전 “Ironies of Automation”이라는 이론적 틀과, 항공 산업이라는 이미 이 문제를 40년 겪고 해법을 제도화한 산업의 사례를 함께 가져온다는 것이다. 문제 제기에서 멈추지 않고 “그래서 무엇을 하라”까지 간다.

핵심 내용

자동화는 가장 어려운 인시던트만 인간에게 남긴다

저자의 출발점은 단순한 관찰이다.

“The better these tools become at resolving routine incidents, the less practice human responders will get.” (이 도구들이 루틴한 인시던트를 잘 해결할수록, 인간 대응자가 얻는 연습 기회는 줄어든다.)

루틴한 인시던트는 사실 안전한 학습 환경이다. 위험 부담이 크지 않은 장애를 반복해서 다루면서 엔지니어는 시스템에 대한 직관을 쌓는다. 그런데 AI가 그 루틴한 일을 가져가면, 인간에게는 비정상적이고 새로운 상황에 대한 책임만 남는다. 저자는 이것이 새로운 문제가 아니라며 Lisanne Bainbridge가 1983년에 정식화한 “Ironies of Automation”을 인용한다.

“Automation reduces operators’ opportunities to practice routine work while leaving them responsible for new and abnormal situations.” (자동화는 운영자가 루틴한 작업을 연습할 기회를 줄이면서도, 새롭고 비정상적인 상황에 대한 책임은 그대로 남긴다.)

여기서 저자는 구체적인 예측을 하나 내놓는다. 평균 MTTR은 내려가겠지만, 복잡한 인시던트의 해결 시간은 오히려 늘어날 것이라는 예측이다. 지표상으로는 개선처럼 보이는 그래프 아래에서 조직의 실전 대응력은 조용히 침식된다.

항공 산업은 ‘드문 실패’를 위해 조종사를 훈련시킨다

항공 유비 — 자동조종 조종석(루틴은 기계가) vs 시뮬레이터 훈련(드문 실패는 인간이 연습한다) 조종석 — 자동조종이 순항을 담당 AUTOPILOT ON ··· 엔진 정지: 10만 비행시간당 1회 미만 실전은 루틴뿐 — 드문 실패를 겪을 기회가 없다 vs 시뮬레이터 — 드문 실패를 반복 훈련 ⚠ ENGINE FIRE STALL · STALL FAA 의무: 6개월마다 반복 시뮬레이터 훈련 실전이 주지 않는 실패를, 훈련이 정기적으로 겪게 한다 비대칭 — 10만 시간당 1회 미만의 실패를 위해, 6개월마다 훈련을 강제한다
항공 유비 — 자동조종이 루틴(순항)을 맡는 조종석과, 엔진 화재·실속 같은 드문 실패를 반복 훈련하는 시뮬레이터의 대비. 드문 실패일수록 훈련은 제도로 강제된다.

소프트웨어보다 먼저 이 역설을 맞닥뜨린 산업이 항공이다. 자동조종이 루틴한 비행을 담당하고 조종사는 예외 상황을 관리한다. 현대 터빈 엔진의 비행 중 정지(shutdown)는 10만 비행시간당 1회 미만 — 즉 조종사 대부분은 실전에서 엔진 정지를 평생 한 번도 겪지 않는다.

그 드문 순간이 왔을 때 무슨 일이 벌어지는가. 저자는 TransAsia Airways 235편 추락 사고를 든다. 승무원이 고장 난 엔진을 잘못 식별했고, 경고가 울린 지 117초 만에 추락했다. 항공 산업의 대응은 훈련의 제도화였다. FAA는 기장에게 6개월마다 반복 시뮬레이터 훈련(recurrent simulator training)을 요구한다. 실전에서 겪을 수 없는 실패를, 시뮬레이터에서 정기적으로 겪게 만드는 것이다.

소프트웨어 산업에도 인시던트 시뮬레이터가 필요하다

저자는 이 모델을 소프트웨어로 옮긴 사례로 Rootly와 Uptime Labs의 파트너십이 만든 인시던트 시뮬레이션을 소개한다. 시뮬레이션은 e-commerce 장애를 조사하고, LLM이 연기하는 이해관계자들과 조율하고, CEO와 고객 지원의 압박을 관리하는 것까지 포함한다. 이런 연습이 기르는 것은 기술 지식만이 아니다 — 불완전한 정보 아래서의 의사결정, 명확한 커뮤니케이션, 조율, 대응 관리 같은, 실제 인시던트에서 가장 무너지기 쉬운 능력들이다.

AI의 설명은 실전 연습을 대체하지 못한다

AI가 조사 단계와 진단 근거를 설명해 주면 학습에 도움이 되지 않을까? 저자는 도움은 되지만 대체는 안 된다고 선을 긋는다.

“You might pick up a few things from watching Serena Williams play, but you only learn tennis by getting on the court.” (Serena Williams의 경기를 보면서 몇 가지 배울 수는 있지만, 테니스는 코트에 서야만 배운다.)

저자는 Holberton School에서의 경험도 근거로 든다. 학생들에게 필요했던 것은 잘 돌아가는 시스템의 관찰이 아니라 직접 고쳐야 하는 망가진 인프라 프로젝트였다.

인시던트 시뮬레이션을 on-call 준비 태세의 일부로

글의 결론은 제도화 요구다. 시스템이 실제로 하는 일과 대응자가 이해하는 것 사이의 간극 — 저자는 이를 “comprehension debt”(이해 부채)라 부른다 — 는 방치하면 계속 쌓인다. 저자의 정기 훈련 권고는 네 가지다: 시스템을 직접 만지는 hands-on 상호작용, 낯선 실패 유형의 처리, 압박 상황에서의 연습, 그리고 SEV0 조율의 리허설. 이는 Bainbridge가 40여 년 전에 내린 처방 — 스킬 퇴화를 막으려면 정기적인 수동 제어와 시뮬레이션이 필요하다 — 과 정확히 같은 결론이다.

“The more successful it becomes, the less prepared humans may be for the moment it fails.” (자동화가 성공할수록, 인간은 그것이 실패하는 순간에 대해 덜 준비된 상태가 된다.)

분석과 인사이트

‘MTTR 개선’이라는 착시를 경계하라

이 글에서 가장 실무적으로 날카로운 대목은 평균 MTTR은 내려가고 복잡한 인시던트의 해결 시간은 올라간다는 예측이라고 본다. 평균 지표만 보는 경영진에게 AI 인시던트 도구 도입은 순수한 성공으로 보고될 것이다. 하지만 분포의 꼬리 — 자동화가 못 푸는 상위 5%의 장애 — 가 길어지고 있다면, 조직은 겉으로 건강해 보이면서 속으로 취약해지는 중이다. 대시보드에 p95/p99 해결 시간과 ‘인간이 개입한 인시던트’의 별도 추적이 없다면 이 침식은 보이지 않는다.

‘comprehension debt’는 부채 계보의 운영 버전이다

이 위키에서 다뤄 온 부채 개념들과 정확히 이어진다. 하용호의 발표가 말한 기술·인지·의도 3대 부채, Fowler의 fragment가 말한 ‘인지적 항복’이 코드를 만드는 쪽의 부채라면, comprehension debt는 시스템을 지키는 쪽의 부채다. 코드는 AI가 짜 주고 장애도 AI가 막아 주는 시스템에서, “이 시스템이 실제로 어떻게 동작하는지 아는 사람”은 채용 공고에도 온보딩 문서에도 없는 채로 사라져 간다. 그리고 이 부채는 다른 부채와 달리 상환 요구가 새벽 3시에, 이자까지 붙어서 온다.

항공 유비의 힘과 한계

항공 유비는 설득력 있지만 한 가지 중요한 차이가 있다. 항공기는 기종이 표준화되어 있어 시뮬레이터가 실기와 거의 같지만, 소프트웨어 시스템은 회사마다, 심지어 팀마다 다르다. 범용 인시던트 시뮬레이션은 커뮤니케이션·조율·압박 대응 같은 이전 가능한 스킬은 잘 길러 주겠지만, “우리 시스템의 어디가 어떻게 무너지는지”라는 시스템 특수적 직관은 결국 자기 인프라 위에서의 game day / chaos engineering으로만 길러진다. 둘은 보완재이지 대체재가 아니다. 또 하나, 이 글이 소개하는 시뮬레이션 사례는 특정 벤더(Rootly, Uptime Labs)의 파트너십이라는 점은 읽을 때 감안할 부분이다 — 다만 도구가 무엇이든 “정기 시뮬레이션을 on-call 요건으로”라는 처방 자체의 타당성은 별개로 성립한다.

이 글이 멈춘 곳: 유인 구조

글이 다루지 않은 질문이 하나 있다. 훈련의 필요성은 알겠는데, 누가 그 시간을 지불하는가? FAA의 6개월 훈련은 규제이기 때문에 지켜진다. 소프트웨어에는 그런 규제가 없고, 분기 로드맵 압박 아래서 시뮬레이션 훈련은 언제나 “다음 스프린트에”로 밀리기 가장 쉬운 항목이다. 결국 이것은 Nature 기사의 결론과 만난다 — 탈숙련은 개인의 의지 문제가 아니라 조직 설계의 문제이고, 훈련이 제도(on-call 로테이션의 요건, 승격 기준, SLA)에 박혀 있지 않으면 일어나지 않는다.

적용 포인트

  • 인시던트 지표를 분해하라. 평균 MTTR만 보지 말고 p95/p99, 그리고 “AI가 자동 해결한 것”과 “인간이 개입한 것”을 분리 추적하라. 복잡 인시던트의 해결 시간이 늘고 있다면 comprehension debt가 쌓이는 신호다.
  • on-call 투입 전 시뮬레이션을 요건으로 만들어라. 새 on-call 멤버는 실전 투입 전에 최소 한 번의 모의 인시던트(game day)를 거치게 하고, 기존 멤버도 항공식으로 주기적 리허설을 돌려라.
  • AI가 해결한 인시던트도 사람이 리플레이하라. AI가 자동 해결한 장애 중 매달 몇 건을 골라, 대응자가 AI의 조사 경로를 따라가며 “내가 처음부터 풀었다면”을 복기하는 시간을 갖는다. 관찰만으로는 부족하지만, 복기는 감각 유지의 최소 비용 수단이다.
  • SEV0 조율을 따로 연습하라. 기술적 디버깅보다 먼저 무너지는 것은 커뮤니케이션이다. 이해관계자 압박·상황 공유·역할 분담을 포함한 리허설을 하라.
  • 낯선 실패를 일부러 만들어라. 잘 아는 장애의 반복이 아니라, chaos engineering으로 팀이 처음 보는 유형의 실패를 주입해 “불완전한 정보 아래서의 의사결정”을 훈련하라.

마무리

이 글의 핵심 문장은 마지막 인용 하나로 요약된다 — 자동화는 성공할수록 인간을 실패의 순간에 덜 준비된 상태로 만든다. Bainbridge가 1983년에 산업 제어 시스템을 보며 쓴 이 역설은, AI 인시던트 대응 도구의 시대에 소프트웨어 운영의 문제로 그대로 돌아왔다. 답도 40년 전과 같다: 실전이 연습 기회를 주지 않는다면, 연습을 제도로 만들어야 한다. 항공 산업은 그것을 규제로 강제해서 해냈고, 소프트웨어 산업은 아직 각 조직의 선택에 맡겨져 있다. AI 도구를 도입하는 결재는 쉽게 나지만, 그 도구가 앗아 가는 연습 기회를 보상하는 훈련의 결재는 잘 나지 않는다 — 이 비대칭을 인식하는 것이 첫걸음이다.

더 읽어보기