AI SRE라는 게 있습니다. 알람을 받아 조사하고, 가설을 세우고, 텔레메트리를 뒤지고, 최근 배포와 장애 신호를 엮고, 수정까지 직접 넣습니다. 새벽 용량 문제 정도는 사람을 깨우지 않고 처리합니다.
평균 복구 시간이 내려갑니다. 온콜 피로도 줄어듭니다. 좋은 일입니다.
Sylvain Kalache의 글은 여기서 한 걸음 더 갑니다. 그 새벽 알람들이 사실은 훈련장이었다면?
정형 장애는 안전한 연습이었다
반복되는 장애는 대응자가 시스템의 정상 동작과 고장 방식을 비교적 안전하게 체득하는 기회이기도 합니다. 새벽 세 시에 로그를 뒤지는 일은 괴롭지만, 그 과정에서 이 시스템이 어떻게 생겼는지가 몸에 남습니다.
그걸 자동화로 덜어내면 어떻게 될까요. 사람에게는 AI가 못 푸는 것만 남습니다. 전례 없고 어려운 장애. 그런데 그걸 넘겨받는 엔지니어는 예전보다 실전 경험이 적은 상태입니다.
그래서 복구 시간이 양극화됩니다. 대부분은 빨라지지만, 복잡한 장애에서는 감각을 잃은 대응자가 원인을 못 짚어 오히려 훨씬 길어질 수 있습니다.
1983년에 이미 나온 얘기입니다
이 글의 중심에 43년 된 논문이 있습니다. 인간공학 연구자 Lisanne Bainbridge의 The Ironies of Automation(1983).
요지가 세 줄입니다.
- 자동화는 운용자가 일상 업무를 연습할 기회를 줄인다
- 새롭고 비정상적인 상황에 대한 책임은 여전히 사람에게 남는다
- 따라서 운용자는 자동화 이전보다 더 숙련되고 더 많이 훈련받아야 한다
세 번째가 핵심입니다. 자동화를 넣으면 사람이 덜 알아도 된다는 게 아니라, 더 알아야 한다는 겁니다.
항공은 이걸 제도로 풀었다
원문이 드는 비교 대상이 항공입니다.
현대 터빈 엔진의 비행 중 정지는 엔진 비행 10만 시간당 1회 미만입니다. 상업용 조종사가 시뮬레이터 밖에서는 평생 한 번도 못 겪을 수 있습니다.
그런데 겪으면 이렇게 됩니다. TransAsia 235편은 이륙 직후 오른쪽 엔진 프로펠러가 자동 페더링됐습니다. 기체는 왼쪽 엔진만으로도 날 수 있게 설계돼 있었는데, 승무원이 문제를 잘못 판단했습니다. 첫 경고로부터 117초 만에 실속해 추락했습니다.
그래서 항공사는 시뮬레이터에서 희귀 비상 상황을 반복합니다. 미국 FAA 규정은 기장이 6개월마다 이륙 중 엔진 고장을 포함한 반복 훈련이나 기량 심사를 이수하도록 정하고 있습니다.
선의가 아니라 규정입니다. 이 차이를 기억해둘 필요가 있습니다.
AI의 설명을 읽는 건 연습이 아니다
AI를 훈련 도구로 쓸 수도 있습니다. 에이전트가 무슨 절차를 밟았는지, 어떤 신호를 봤는지, 진단 근거가 뭔지 물어볼 수 있습니다.
원문은 그걸로 부족하다고 봅니다. 비유가 하나 나옵니다. 세리나 윌리엄스 경기를 보면 일부는 배우지만, 테니스는 코트에 서봐야 는다.
Dropbox 사례도 인용됩니다. 채용한 졸업생들의 문제 해결 경험이 여전히 부족하다고 판단해서, 고장난 인프라를 진단하고 복구하는 프로젝트를 교육 과정에 추가했다는 겁니다.
그래서 저자가 붙인 이름이 이해의 부채(comprehension debt) 입니다. 시스템이 실제로 동작하는 방식과 대응자의 이해 수준 사이에 쌓이는 격차.
처방과, 그 처방을 파는 사람
원문의 결론은 자동화를 줄이자가 아닙니다. 연습을 온콜 준비 절차에 집어넣자입니다.
익숙하지 않은 장애를 직접 처리해볼 것, 압박 상황에서 판단하는 능력을 연습할 것, SEV0에 필요한 조율과 커뮤니케이션을 반복 훈련할 것. 테이블탑 훈련과 카오스 엔지니어링은 예전부터 있었지만 LLM 시대에 중요도가 올라간다는 겁니다.
Bainbridge도 같은 걸 권했습니다. 운용자에게 주기적으로 직접 제어권을 주고, 시뮬레이션을 활용하라고.
여기서 짚고 갈 게 있습니다. 저자는 장애관리 회사 Rootly 소속이고, 글에 나오는 시뮬레이션 제품은 Rootly가 Uptime Labs와 함께 만든 것입니다. 모의 이커머스 장애에서 엔지니어가 인시던트 커맨더를 맡고, 옵저버빌리티 도구로 원인을 조사하고, Slack에서 LLM으로 구현된 CEO·고객지원 이해관계자와 대응을 조율하는 구성입니다.
설계 자체는 그럴듯합니다. 다만 문제를 제기한 사람이 해법을 파는 사람이라는 건 알고 읽어야 합니다.
댓글이 더 날카롭습니다
Hacker News 토론에서 몇 개만.
“아무도 안 할 거다.” AI 이전에도 백업 복구, 재해 복구, 잘 안 쓰는 런북, 무중단 시크릿 로테이션을 실제로 연습하는 회사는 드물었다는 지적. 경영진은 이런 지루한 운영 업무보다 새 인프라와 대시보드와 우상향 지표를 원합니다. 조종사가 훈련받는 건 정부가 면허 조건으로 강제하기 때문이라는 겁니다. 그래서 SRE도 전문 자격 제도를 지지하고 면허 조건으로 만들어야 한다는 주장으로 이어집니다. 모든 사업자에게 같은 비용을 강제하지 않으면 경쟁 속에서 결국 생략된다는 논리입니다.
비유 자체에 대한 반박. 항공은 실패가 대참사고 운항 중인 시스템이 그 자리에서 바뀌지 않습니다. SRE에 같은 훈련을 시켜도 효율적 대응은 가르치지만 고유한 근본 원인을 고치는 법은 못 가르칩니다. 조종사에게 비행 중 엔진 고장 대응과 엔진 디버깅·재설계를 동시에 훈련시키는 격이라는 겁니다. 훈련에 쓸 1분을 코드베이스 개선에 쓰는 게 낫다는 반론.
반대 경험담. Claude가 인프라 작업에서 오히려 매우 꼼꼼해서, 문서가 낡았는지 부정확한지 확인하려고 소프트웨어 고고학까지 한다는 것. 검증 비용이 내려가서 자기도 10배쯤 꼼꼼해졌고 이제는 백업도 정기적으로 시험한다는 얘기입니다. 문제는 AI 이전에 이런 원리를 안 배운 신입이 필요성을 모른 채 에이전트를 잘못 이끄는 데 있다고 봅니다.
유사 증언. 팀에 정확한 해법을 정리해서 넘겼는데도 Claude에 3일을 던지고 접근법조차 못 찾더라는 것. 전통적인 방식으로 추적했으면 30분이면 찾았을 한 줄짜리 코드였다고 합니다.
프레임 전환. 중심 개념이 자동화가 아니라 사이보그여야 한다는 의견. 자동화에서는 사람이 수동적 운용자로 전락하지만, 사이보그 모델에서는 기계를 배치하고 기계까지 포함한 세계를 사람이 장악합니다. 연관해서 “Automation should be like Iron Man, not like Ultron”을 찾아볼 만하다는 첨언이 붙습니다.
그리고 회의론. AI 능력이 계속 오르면 AI가 못 푸는 장애는 아무리 훈련해도 사람도 못 풀 거라는 것. 1년 반 전에는 감각 유지를 위해 가끔 손으로 코드를 쓴다는 말이 있었는데 이제 거의 안 들린다고 합니다.
혼자 굴리는 시스템에 대보면
팀도 온콜도 없는 개인 자동화에 이 글이 적용될까 싶었는데, 오히려 더 직접적이었습니다.
원문: https://www.sylvainkalache.com/blog/ai-handles-incidents-engineers-lose-touch-with-their-systems
요약·토론: https://news.hada.io/topic?id=33263