AI가 사고 처리 다 맡으면 엔지니어는 시스템을 잊는다

AI가 야간 장애를 대신 처리한다

링크드인 SRE 출신 실뱅 칼라슈는 2012년 스스로 치유하고 학습하는 시스템을 프로토타입으로 만들었다. 당시 AI 역량으로는 상용화되지 않았지만, 지금은 현실이 됐다. 알림을 살펴 가설을 세우고, 텔레메트리를 조회하고, 최근 배포와 연관 짓고, 수정까지 스스로 적용한다. 'AI SRE'라 불리는 이 도구들은 야간 용량 장애 같은 단순 사고를 사람 깨우지 않고 해결한다.

편리함은 분명하다. 하지만 칼라슈는 단순 사고가 엔지니어에게 '안전한 연습장'이었다고 지적한다. 시스템이 어떻게 동작하고 어떻게 망가지는지 체감하는 유일한 기회였다. AI가 이걸 다 가져가면, 처음 보는 복잡한 장애가 터졌을 때 사람은 '감' 없이 맨손으로 덤벼야 한다.

자동화의 아이러니, 1983년에 이미 예고됐다

인간공학 연구자 리산 베인브리지는 1983년 논문 '자동화의 아이러니'에서 이 역설을 짚었다. 자동화는 운영자에게 일상 업무 연습 기회를 줄이면서, 비정상 상황 책임만 남긴다. 따라서 자동화 전보다 더 숙련되고 더 많은 훈련이 필요하다는 결론이다.

칼라슈는 항공 사례를 든다. 현대 터빈 엔진은 10만 비행시간당 1회 미만으로 공중 정지한다. 조종사 평생 실전 경험 못 할 수도 있다. 하지만 투아시아 항공 235편처럼 엔진 경고 117초 만에 추락하는 순간, 조종사는 즉각 정확히 반응해야 한다. 미 FAA 규정상 기장은 6개월마다 시뮬레이터에서 이착륙 엔진 고장 등 비상 상황을 연습한다.

소프트웨어 사고는 목숨이 달리지 않았다. 그래서 훈련을 안 해도 되는 걸까? 칼라슈는 목숨이 안 걸려도 장인 정신은 필요하다고 말한다.

"그냥 AI 써서 고치라"는 현장 증언

해커뉴스 댓글 39개 중 눈에 띄는 건 현장 강요다. "랜덤 엔지니어를 장애 콜에 끌어들여 '그냥 AI 써서 컴포넌트 파악하고 트리아지하고 픽스 짜라'고 했다"는 증언이 있다. AI가 제안한 평범한 수정안을 받아들이거나, '무능해 보인다'는 평가를 감수하거나 양자택일이었다.

또 다른 댓글러는 "군대, 경찰, 소방도 훈련 안 하고 실전만 뛰나"라고 반문했다. 소프트웨어 '엔지니어링'이 실제 엔지니어링과 달라 보이는 이유 중 하나가 반복 훈련 부재라는 지적이다.

본지가 6일 전 다룬 오픈소스 거장들이 AI 기여를 거절하는 진짜 이유에서도 유지보수자들이 **'검토 비용 폭증'**을 이유로 AI 기여를 차단한다고 전했다. 자동화가 만든 결과물을 사람이 검증하는 비용이 더 커지는 구조다.

시뮬레이션으로 '감'을 되찾는 실험

칼라슈가 일하는 루틀리는 업타임랩스와 손잡고 실전 같은 인시던트 시뮬레이션을 만들었다. 엔지니어가 인시던트 커맨더 자리에 앉아 이커머스 장애를 겪는다. 옵저버빌리티 도구를 쓰며 슬랙에서 LLM 기반 이해관계자(CEO, 고객지원)와 조율한다.

정보가 불완전한 상황에서 판단하고, 명확히 소통하고, 사람을 조율하고, 실제로 대응을 이끄는 연습이다. 설명 듣기와 관찰은 실전 대체가 안 된다. 세레나 윌리엄스 경기 봐서 테니스 느는 게 아니듯, 인시던트 대응도 직접 뛰어봐야 는다.

칼라슈는 드롭박스 채용 피드백을 받고 '망가진 인프라 진단·수리' 프로젝트를 만들었다. 체험 교육이 수동 강의를 크게 이긴다는 확신에서다.

AI를 트레이너로 쓸 수 있을까?

대안으로 'AI에게 설명시키기'가 거론된다. 에이전트가 어떤 신호를 봤는지, 무슨 근거로 진단했는지 묻는 방식이다. 하지만 칼라슈는 설명과 관찰이 실전 연습을 대신 못 한다고 선 긋는다.

오히려 **'이해 부채(comprehension debt)'**가 쌓인다. 시스템 실제 동작과 대응자 이해 사이의 간격이 벌어진다. LLMs가 우리 일을 더 많이 할수록 이 빚은 불어난다.

쉽게 풀어보면

자동차 비유로 보자. 차선 유지·급제동·주차까지 자동차가 다 한다. 운전자는 핸들에 손만 얹고 간다. 99% 상황은 문제없다. 그런데 센서 오류로 차가 갑자기 중앙선 넘으려 할 때, 운전자가 3년 동안 실제 운전 연습을 안 했다면 어떻게 반응할까?

소프트웨어도 같다. AI가 밤새 디스크 꽉 찬 알림 처리하고, 메모리 누수 재시작하고, 배포 롤백까지 다 해 준다. 엔지니어는 아침에 '잘 처리됐네' 보고 출근한다. 그런데 어느 날 원인 불명 장애가 터져 AI도 손들고 사람 부르면, 그 엔지니어는 시스템 내부 흐름을 잊어버린 상태에서 헤매게 된다.

항공은 이걸 시뮬레이터로 푼다. 조종사는 6개월마다 '엔진 고장' '계기 불신' '이착륙 중단'을 연습한다. 실전 같은 스트레스 속에서 근육 기억을 유지한다. 소프트웨어 업계는 이제야 '인시던트 시뮬레이터'를 만들기 시작했다. 루틀리·업타임랩스 실험이 그 예다.

나에게 미치는 영향

개발자가 아니어도 이 흐름은 닿아 있다.

서비스 기획·운영자: 장애 발생 시 '엔지니어가 금방 고치겠지' 믿기 어렵다. 초기 대응 매뉴얼(고객 안내 템플릿, 상황 전파 채널, 결정권자 연락망)을 지금 문서화해 두라. 엔지니어 손 기다리는 시간이 길어질 수 있다.
직장인·학생: 'AI가 다 해 주니 나도 몰라도 된다'는 착각 위험하다. 도구 없이 직접 해 보는 경험을 주기적으로 만드라. 엑셀 매크로 없이 수식 짜보기, 챗GPT 없이 초안 써보기, 내비 없이 길 찾기 같은 작은 연습이 '감'을 지킨다.
관리자·의사결정자: AI 도입으로 MTTR(평균 복구 시간)은 줄어도 최악 장애 복구 시간은 길어질 수 있다는 점을 예산·인력 계획에 반영하라. 시뮬레이션 훈련 예산은 '비용'이 아니라 '보험'이다.

남은 쟁점과 관전 포인트

양측 주장이 갈리는 지점은 명확하다.

찬성(도입 가속)	신중(역량 유지)
단순 장애 자동화로 야간 호출·번아웃 감소	일상 대응 경험 상실로 비정상 상황 대응력 저하
MTTR 단축, 비용 절감 입증됨	이해 부채 누적으로 장기적 시스템 장악력 약화
AI 설명 기능으로 지식 이전 가능	설명·관찰은 실전 연습 대체 불가

합의점: AI 도구 자체는 유용하다. 이견: '도구 의존도'를 어디까지 허용할지, 훈련 체계를 어떻게 갖출지다.

앞으로 지켜볼 세 가지.

시뮬레이션 훈련이 정규 교육 과정으로 자리잡을지. 항공처럼 의무화될까.
AI가 '설명'을 넘어 '코칭' 역할까지 할 수 있을지. 루틀리 실험이 단서다.
대형 장애 사례에서 'AI 의존 후 사람 개입 실패' 패턴이 통계로 잡힐지. 아직 공개된 데이터는 없다.

칼라슈 말대로 기술이 문제를 만들었으면 기술로 풀 수도 있다. 단, 사람이 '직접 뛰어보는 장'을 기술이 뺏지 않을 때만 가능하다.