일상 장애가 직관을 기르는 통로였다 - 자동화가 남기는 이해 부채와 인시던트 시뮬레이터

일상 장애가 직관을 기르는 통로였다

TL;DR

• 출발점이 자기 프로토타입의 실현인데 2012년 링크드인 SRE 시절 스스로 치유하고 이전 장애로부터 배우는 시스템을 설계했으나 프로토타입으로 남았고 이것이 이제 현실이 되었다는 것이다. 도구의 범위도 제시된다. 경보 점검과 가설 수립, 텔레메트리 질의, 배포 연관, 수정 구현까지 하는데 그것을 보는 것이 아무리 좋아도 큰 우려가 하나 있으니 우리가 시스템과의 감각을 잃고 있다는 것이다.
• 문제의 구조가 역설로 정리되는데 이 도구들이 일상 장애를 해결하는 데 더 좋아질수록 인간 대응자는 연습을 덜 하게 되고, 자동화가 풀 수 없는 모호한 고심각도 장애가 들어오면 대응 엔지니어들이 곤란해진다는 것이다. 이유가 명시된다. 일상 장애는 대응자가 자기 시스템이 어떻게 동작하고 실패하는지에 대한 직관을 안전하게 기르는 통로이기도 하기 때문이다.
• 이론적 근거가 1983년 논문에서 오는데 인간 요인 연구자 리산 베인브리지가 자동화의 아이러니라는 유명한 논문에서 이 역설을 서술했고, 자동화가 조작자들이 일상 업무를 연습할 기회를 줄이면서도 새롭고 비정상적인 상황에 대한 책임은 그들에게 남긴다는 것이다. 그래서 결론이 뒤집힌다. 따라서 조작자들은 자동화 이전보다 더 숙련되어야 하고 훈련도 더 많이 받아야 한다는 것이다.
• 예측이 두 방향으로 갈리는데 앞으로 몇 년간 AI 보조 장애 대응 덕분에 대부분 장애의 평균 복구 시간은 내려갈 것이지만 복잡한 장애의 해결 시간은 치솟을 것이고, 그 이유는 장애 대응자들이 자기 시스템과의 감각을 잃고 조사에 애를 먹기 때문이라는 것이다.
• 처방이 항공에서 오는데 현대 터빈 엔진은 엔진 비행시간 10만 시간당 한 번 미만의 공중 정지를 겪을 정도로 드물어 상업 조종사가 시뮬레이터 밖에서 한 번도 경험하지 않고 커리어 전체를 마칠 수 있다는 것이다. 그럼에도 미국 FAA 규정에 따라 기장은 이륙 중 엔진 고장 같은 시나리오를 포함해 6개월마다 재훈련이나 숙련도 점검을 완료해야 하며, 소프트웨어 업계에도 장애 시뮬레이터가 필요하다.

Source

AI handles incidents, engineers lose touch with their systems — Sylvain Kalache(Rootly AI Labs lead 겸 DevRel, 전 LinkedIn SRE, Holberton School 공동창업자), 2026년 9월 4일

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

Knowledge

14년 전 프로토타입이 현실이 되었다

글은 자기 이력에서 시작한다. 2012년 링크드인에서 SRE였을 때 스스로 치유하고 이전 장애로부터 배울 수 있는 시스템을 설계했다는 것이다. 그런데 당시의 한계가 밝혀진다. AI 능력이 오늘 우리가 가진 것과 전혀 근처에도 없었고 그것은 프로토타입으로 남았다는 것이다. 그리고 현재가 대비된다. 그러나 이것이 이제 현실이라는 것이다.

도구의 능력이 열거된다. 이 도구들은 모든 것을 하는데, 경보를 점검하고 가설을 세우고 텔레메트리를 질의하고 최근 배포들을 연관 짓고 심지어 수정을 직접 구현하기까지 한다는 것이다. 그런데 우려가 제시된다. 그것을 보는 것을 아무리 좋아하더라도 큰 우려가 하나 있으며 우리가 우리 시스템과의 감각을 잃고 있다는 것이다. 문제의 구조는 인과로 제시된다. 이 도구들이 일상 장애를 해결하는 데 더 좋아질수록 인간 대응자들은 연습을 덜 하게 되고 자동화가 풀 수 없는 모호하고 고심각도인 장애가 들어오면 대응하는 엔지니어들이 곤란해질 것이라는 것이다.

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

도구의 성격이 먼저 인정된다. 이 AI 보조 장애 대응 도구들은 더 흔하게는 AI SRE라고 불리는데 여러 면에서 환상적이라는 것이며 다만 자신이 특별히 좋아하지 않는 용어라는 유보가 붙는다. 마법처럼 느껴지는 순간도 제시된다. 밤중에 일상 장애를 처리해서 용량 문제 때문에 깨어나지 않아도 될 때 특히 마법처럼 느껴진다는 것이다. 그런데 문제가 지목된다. 일상 장애는 대응자들이 자기 시스템이 어떻게 동작하고 어떻게 실패하는지에 대한 직관을 안전하게 기르는 방법이기도 하다는 것이다. 그래서 결과가 명확해진다. AI가 풀 수 없는 어렵고 전에 본 적 없는 장애에 부딪히면, 엔지니어들이 이전에 가졌을 것보다 더 적은 연습을 가진 채로 인수해야 할 것이라는 것이다.

이론적 근거가 제시된다. 인간 요인 연구자 리산 베인브리지가 1983년의 유명한 논문 자동화의 아이러니에서 이 역설을 서술했으며 내용이 인용된다. 자동화가 조작자들이 일상 업무를 연습할 기회를 줄이는 한편 새롭고 비정상적인 상황에 대한 책임은 그들에게 남긴다고 설명했다는 것이다. 그리고 그의 논증이 결론을 뒤집는다. 따라서 조작자들은 자동화 이전보다 더 숙련되어야 하고 훈련도 더 많이 받아야 한다고 주장했다는 것이다. 자기 예측도 제시된다. 앞으로 몇 년간 AI 보조 장애 대응 덕분에 대부분 장애의 평균 복구 시간은 내려갈 것이지만 복잡한 장애에 대해서는 해결 시간이 치솟을 것이라는 것이다. 이유가 명시된다. 장애 대응자들이 자기 시스템과의 감각을 잃고 조사하는 데 애를 먹기 때문이라는 것이다.

항공은 드문 고장을 위해 조종사를 훈련한다

영감의 원천으로 항공 산업을 볼 수 있다고 제시되며 역할 분담이 서술된다. 비행기 자동화가 비행의 많은 부분을 처리하지만 조종사들은 자동화가 관리할 수 없는 상황들에 대한 책임을 계속 지는데, 엔진 고장과 신뢰할 수 없는 계기, 이륙 중단, 실속, 그리고 다른 비정상 조건들이라는 것이다. 빈도는 수치로 제시된다. 이 사건들은 극도로 드물어서 현대 터빈 엔진은 엔진 비행시간 10만 시간당 한 번 미만의 공중 정지를 겪는다는 것이다. 그리고 그 의미가 환산된다. 다시 말해 상업 조종사가 시뮬레이터 밖에서 한 번도 경험하지 않고 커리어 전체를 마칠 수 있을 만큼 드물다는 것이다. 그러나 요구는 절대적이라고 지적된다. 고장이 일어나면 조종사들은 빠르고 정확하게 반응해야 한다는 것이다.

사례가 제시된다. 트랜스아시아 항공 235편에서 이륙 직후 오른쪽 엔진의 프로펠러가 자동으로 페더링되었고 설계상의 여유가 언급된다. 그 항공기는 왼쪽 엔진으로 비행을 계속하도록 설계되어 있었다는 것이다. 그런데 판단이 틀렸다고 서술된다. 승무원이 문제를 잘못 식별했으며 항공기는 첫 경고로부터 단 117초 뒤에 실속해 추락했다는 것이다. 훈련 체계도 제시된다. 항공사 조종사들은 드문 비상 상황을 예행연습하려고 정기적으로 시뮬레이터로 돌아가며 미국 FAA 규정에 따라 기장은 이륙 중 엔진 고장 같은 시나리오를 포함해 6개월마다 재훈련이나 숙련도 점검을 완료해야 한다는 것이다. 그리고 소프트웨어로 넘어온다. 대부분의 소프트웨어 장애가 생명을 위협하지는 않지만 그것이 우리 기예를 완성하지 않을 이유는 아니며 문제를 만든 그 기술이 그것을 닫는 데도 도움이 될 수 있다는 것이다.

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

자기 회사의 사례가 제시된다. 장애 관리 회사인 Rootly에서 일하는데 Uptime Labs와 협력해 현실적인 장애 시뮬레이션을 통해 이 발상을 적용했다는 것이다. 구성이 서술된다. 엔지니어들이 시뮬레이션된 전자상거래 장애 동안 장애 지휘관의 자리에 앉고 관측성 도구를 쓰면서 슬랙에서 LLM으로 구동되는 이해관계자들과 조율한다는 것이다. 효과도 서술된다. 결과가 실제처럼 느껴지는데, 무엇이 잘못되고 있는지 조사해야 하는 동시에 대응을 조직된 상태로 유지하고 CEO와 고객 지원을 상대해야 한다는 것이다. 연습되는 기술이 열거된다. 장애 동안 중요한 기술들을 연습하게 되는데 불완전한 정보에서 의미를 만드는 것, 명료하게 소통하는 것, 사람들을 조율하는 것, 그리고 실제로 대응을 운영하는 것이라는 것이다.

AI를 트레이너로 쓰는 것의 한계

가능성이 먼저 제시된다. 그런데 AI를 트레이너로 쓰는 것은 어떤가라는 것이며 방법도 구체적이다. 대응자들이 에이전트에게 자신이 취한 단계들과 검토한 신호들, 진단 뒤의 증거를 설명해 달라고 요청할 수 있다는 것이다. 그런데 한계가 못 박힌다. 설명과 관찰은 연습의 대체물이 아니라는 것이다. 비유도 제시된다. 세리나 윌리엄스가 경기하는 것을 보고 몇 가지를 배울 수는 있겠지만 테니스는 코트에 나가야만 배우며 장애 대응도 다르지 않다는 것이다.

자기 경력이 근거로 붙는다. 진보 교육, 즉 하면서 배우기를 중심으로 소프트웨어 엔지니어링 학교를 만드는 데 커리어의 5년 넘게를 썼으며 대면이었지만 교사가 없었고 학생들은 강의를 듣는 대신 프로젝트로 작업했다는 것이다. 구체적인 개입 사례도 제시된다. 드롭박스가 자기들이 채용한 졸업생들이 여전히 문제 해결에 너무 경험이 없다고 말했을 때, 학생들에게 망가진 인프라를 주고 진단해서 고치도록 요구하는 프로젝트를 만들었다는 것이다. 그리고 결론이 제시된다. 대부분의 실습 기술에 대해 실습 교육이 수동적 교습을 크게 이긴다고 믿는다는 것이다.

이해 부채라는 개념

새 개념이 제시된다. LLM이 우리 일을 더 많이 하게 되면서 엔지니어링 팀들은 이해 부채를 쌓을 위험이 있는데, 시스템이 어떻게 동작하는지와 대응자들이 그것을 얼마나 잘 이해하는지 사이의 커지는 격차라는 것이다. 권고가 열거된다. 엔지니어들은 자기가 지켜보는 시스템과 정기적으로 상호작용해야 하고 익숙하지 않은 고장을 처리해야 하고 압박 아래에서 일하는 것을 연습해야 하고 SEV0 동안 요구되는 조율과 소통을 예행연습해야 한다는 것이다. 기존 관행도 언급된다. 탁상 훈련과 카오스 엔지니어링은 전혀 새로운 것이 아니지만 연습이 LLM 시대에는 훨씬 더 중요해졌다는 것이다. 베인브리지도 다시 호출된다. 연구자 베인브리지는 조작자들에게 정기적인 실습 통제권을 주고 기술이 쇠퇴하는 것을 막기 위해 시뮬레이션을 쓰라고 권고했다는 것이다.

그리고 글의 마지막 문장이 아이러니를 압축한다. 그것이 자동화의 아이러니이며 자동화가 더 성공적일수록 인간은 그것이 실패하는 순간에 덜 준비되어 있을 수 있다는 것이다.

더 생각해보기

• 일상 장애가 직관을 기르는 통로였다면, 그 통로를 자동화하면서 대체 통로를 만들지 않은 것은 누구의 판단 실패인가.
• 평균 복구 시간은 내려가고 복잡한 장애의 해결 시간은 치솟는다는 예측은 어떤 지표로 조기에 확인할 수 있는가.
• 1983년 논문의 진단이 지금 그대로 적용된다면, 그동안 이 문제가 왜 해결되지 않았는가.
• 10만 시간에 한 번인 사건을 6개월마다 훈련하는 항공의 비용 구조는 소프트웨어 조직이 감당할 수 있는가.
• 117초라는 시간은 소프트웨어 장애에서 어떤 대응 시간 목표로 번역되는가.
• LLM으로 구동되는 이해관계자와의 조율 연습은 실제 CEO와 고객 지원을 상대하는 것과 어디까지 같은가.
• 설명과 관찰이 연습의 대체물이 아니라면, AI가 자기 진단 근거를 설명하는 기능의 실제 용도는 무엇인가.
• 이해 부채는 기술 부채처럼 측정하고 상환 계획을 세울 수 있는 종류의 부채인가.
• 카오스 엔지니어링이 이미 있었는데도 부족했다면, 장애 시뮬레이터는 무엇을 다르게 하는가.
• AI SRE라는 용어를 좋아하지 않는다는 유보는 도구의 위치를 어떻게 다시 규정하려는 것인가.