요약
AI가 장애 대응을 대신할수록 SRE는 정작 중요한 장애를 다룰 실력을 잃습니다.
관측 도구 업체 시그노즈의 엘리자베스가 쓴 글입니다. 저자는 SRE(서비스 안정 운영을 맡는 엔지니어)가 AI로 대체되느냐보다, 일상적인 장애 대응을 AI에 맡기면서 실력이 줄어드는 문제가 더 현실적이라고 봅니다.
왜 중요한가
- AI가 쉬운 장애를 처리할수록 사람은 연습 없이 가장 어려운 장애만 맡게 됩니다.
- 작업이 쉬워지고 성과도 좋아 보여서, 실력이 줄어드는 것을 본인이 알아채기 어렵습니다.
- 주니어 SRE는 기초를 익힐 기회를 얻지 못해, 다음 세대를 키우는 경로 자체가 끊길 수 있습니다.
핵심 내용
- 리잔 베인브리지는 1983년에 자동화가 늘수록 드문 실패 때 사람이 더 중요해지지만 연습 기회는 줄어든다고 지적했습니다.
- 한 연구에서는 AI 보조에 익숙해진 내시경 전문의의 용종 발견율이 AI 없이 검사할 때 28%에서 22%로 떨어졌습니다.
- 로그 읽기, 가설 세우기, 시스템 구조 파악을 AI에 넘기면 각각은 효율적으로 보여도 전문성은 속이 빕니다.
- 저자는 AI가 풀 수 있는 장애 일부를 사람의 연습용으로 남겨 두자고 제안합니다.
- 사람이 AI의 권고를 승인만 하지 말고 AI와 함께 문제를 직접 풀어야 집중력이 유지된다고 합니다.
HN 반응
- 일부 이용자는 수동 비행을 의무화한 항공 업계를 좋은 본보기로 꼽았지만, 모든 소프트웨어에 그만한 비용을 들일 필요는 없다는 반론도 나왔습니다.
- 시스템 이해를 AI에 맡긴 팀은 결제 오류 같은 사고를 고치지 못한다는 우려와, 쉬운 장애 연습은 필요 없고 기술의 재배치일 뿐이라는 주장이 맞섰습니다.
아주 좋은 예입니다. 항공은 배울 점이 많은 업계입니다. 사람이 실수하지 않게 하는 방법을 이미 많이 알아냈죠. 시스템은 점점 복잡해지고 자동화가 점점 더 많은 일을 가져가는 와중에도요.
치명적인 실수를 0으로 만들고 싶다면 항공은 좋은 예입니다. 그렇게 하는 방법이 있고, 그만큼의 비용도 따릅니다.
마찬가지로 얼랭(Erlang)은 핫 리로드와 관측 가능성 등을 갖춘 고가용성 시스템을 운영하는 좋은 예입니다. 이쪽에도 비용이 듭니다.
모든 프로젝트에 같은 특성이 필요한 건 아닐 겁니다. 저는 일부 시스템이 예정된 점검이나 예정에 없던 점검으로 멈추는 것쯤은 괜찮다고 봅니다. 1년에 한 번 쓰는 어떤 정부 포털은 새벽 3시부터 5시까지, 그리고 낮 12시 이후에 다시 접속이 안 되는 것을 제가 허락해 준 셈이었습니다.
문제는 사람들이 트위터에 들어가서 "코드를 읽을 필요가 없다" 같은 말을 하는 "사상가"와 "인플루언서"의 글을 본다는 점입니다. 그들은 소프트웨어가 너무 결함투성이거나 믿을 수 없게 되면 구독을 해지하거나 그보다 더한 일을 할 고객을 둔 시스템에서 일하지 않습니다.
고객의 고객에게 대규모 청구 오류를 몇 번만 내면, 그들은 지인 CTO들에게 당신 회사를 욕하고 계약을 끊을 겁니다. 스트라이프가 매주 한 번씩 세 번에 한 건꼴로 이중 청구를 하는데, 이제 아무도 시스템이 어떻게 돌아가는지 이해하지 못해서 두 달을 허우적대도 못 고친다고 상상해 보세요. 그 시점에서 끝입니다. 브랜드 가치가 전부 사라집니다.
그건 사실이 아닙니다.
윗글의 주장은 IC가 아니라 사람 관리자나 리더를 제외하고 본다면 타당하다고 생각합니다. 그런 사람들의 말을 제외하는 것도 타당하다고 봅니다. 매일 현장에서 일하는 사람이 아니니까요. 회사에 가장 좋은 전략적 논점은 있을지 몰라도, 실무자와 업계에 가장 좋은 방향은 아닐 수 있습니다.
한 명만 대 보세요. 정확성을 요구하는 진짜 고객이 있는 시스템에서 본인이 직접 일하면서(같은 회사 사람이 아니라 본인이요) 트위터에서 그런 얘기를 퍼뜨리는 개발자를 한 명이라도 보여 주세요.
엔지니어, 특히 (대개 규제 산업에 속하는) 금융 거래를 처리하는 소프트웨어를 만드는 엔지니어들이 불변 조건을 담은 적합성 테스트를 어떻게 짜는지 모르기라도 한다는 듯이 말씀하시네요.
이 모든 테스트 코드를 책임감 있게 짜면서, 트위터에서는 프로덕션 코드를 아무도 읽을 필요가 없다고 큰소리치는 사람이 대체 누구입니까?
테스트 코드는 AI가 작성하고 검토하니, 사람이 들여다볼 필요가 없습니다.
그러니까 그게 바로 이 글에서 말하는 "숙련도 저하"고, 돈을 다루는 회사에는 그게 우려스러운 일 아닌가요?
사람이 만든 미션 크리티컬 시스템이 유지보수와 확장 면에서 악몽이 되는 걸 봤고, 또 최첨단 AI 코딩 에이전트가 문제가 생겼을 때 엉뚱한 문제를 자신 있게 빠르게 고치거나 조금 틀린 방식으로 고치는 것도 봤습니다. 그래서 이 대규모 숙련도 저하가 다 괜찮을 거라는 데는 여전히 회의적입니다.
물론 코드를 안 보고 있으면 누가 소리를 지르기 전까지는 망할, 알 턱이 없죠...
저는 이 글의 전제 몇 가지에 동의하지 않습니다. 장애 조사를 사람이 주도하는 일은 앞으로 없을 겁니다. 어려운 장애에 대처하려고 쉬운 장애로 훈련할 필요도 없습니다. 쉬운 장애로 훈련시키고 싶다 해도, AI 덕분에 실제와 똑같은 문제를 어느 때보다 쉽게 만들어 낼 수 있으니 실전 경험은 필요 없어집니다. 또 이걸 숙련도 저하라고 부르는 것에도 동의하지 않습니다. 실제로 필요한 쪽으로 기술을 재배분하는 것일 뿐이니까요.
현실 세계는 튼튼합니다. 돈을 다루는 코드에 버그가 있어도 괜찮습니다. 세상이 끝나는 것도 아니고, AI는 사람보다 버그 발생률을 낮출 수 있을 겁니다.
맞는 말입니다. 세상은 계속 굴러갑니다. 하지만 코드에 신경 쓰지 않은 사업체는 번 돈보다 더 많은 돈을 잃게 됩니다. 고객에게 보상해야 하거나 고객을 잃게 될 테니까요. 그렇게 해서 세상이 튼튼함을 유지하는 겁니다.
사업체는 다른 사업체와 경쟁합니다. 손으로 짠 코드가 더 우월하다면 그런 사업체가 이길 겁니다.
AI가 짠 형편없는 테스트를 본 적이 있습니다. 그 코드도 확인해야 합니다. 코드는 전부 확인해야 해요.
AI가 태워 버린 신뢰의 양이 어마어마합니다.
한때 유능하다고 생각했던 기업과 사람들을 이제는 믿지 못하겠어요.
비전이 있다고 생각했던 리더들이 눈앞의 단기 이익 때문에 미래를 내던지는 걸 지켜보고 있습니다.
우린 대체 어떻게 된 걸까요?
저한테도 가장 눈이 번쩍 뜨인 일 중 하나였어요. 진지하고 똑똑하다고 여겼던 사람들이 "코드를 읽을 필요 없다"는 AI 망상에 완전히 빠져 버렸거든요.
어쩌면 이건 더 깊은 무언가, 곧 프로그래밍을 하나의 학문으로 좋아하고 코드를 이해하는 걸 즐기는 사람과, 프로그래밍을 목적을 위한 수단으로만 보는 사람 사이의 성향 차이를 드러내는 건지도 모릅니다.
프로덕션 데이터를 잃지 않는 것, 침해당하지 않는 것도 우리가 실수를 0으로 만들려고 애쓰는 일입니다.
사회가 항공 안전에 쓸 수 있는 돈에는 한계가 있습니다. 물론 아주 중요한 일이라 꽤 많이 쓰긴 하지만요. 사이버 보안 팀은 큰 제약 속에서 일해야 합니다. 비용을 직접 계속 늘리거나, (제품 팀이 빠르게 움직이지 못하게 막는 식으로) 간접적으로 돈을 잃는 것은 대부분의 회사에서 분명히 목표가 아니니까요. 그래서 우리가 실수를 0으로 만들려고 애쓰는 건 맞지만, 대부분의 회사는 다른 이익을 얻는 대신 이런 일이 벌어질 위험을 0이 아닌 수준으로 더 떠안을 의향이 있습니다.
항공도 같은 제약 안에서 일합니다. 새 시스템 개발은 아주 느린 게 맞습니다. 하지만 일상 운영은 대단히 빠르게 돌아가는데도 인상적일 만큼 안전합니다. 항공기 엔진을 몇 시간 만에 교체하면서도 의미 있는 실수가 나올 확률은 아주 낮습니다.
그렇긴 한데, 그 비용이 얼마입니까? 개선을 얼마나 빨리 내놓느냐도 문제지만, 소재와 선택한 공정에도 웃돈이 붙습니다. 항공은 생명과 건강이 대체 불가능하니 그만한 가치가 있겠죠. 하지만 예를 들어 제 채팅 기록이나 사진의 가치는 분명 유한하고 꽤 낮습니다. 손상되거나 유출되거나 최악의 경우 사라진다면 좀 속이 쓰리겠지만요. 그래도 저는 보호 장치에 세후 월 실수령액의 0.4% 정도를 쓰는 게 적당하다고 결론 내렸는데, 연간 청구서가 날아올 때마다 정말 그 정도로 가치를 두는 게 맞나 하는 의문이 점점 커집니다.
"그렇긴 한데, 그 비용이 얼마입니까?"
적절하고 필요한 만큼의 비용입니다.
비용이 덜 드는 새 엔진 설계나 엔진 교체 절차가 실패한다면, 비행기가 아예 없는 것보다 나쁩니다. 싸지만 실패한다면 필요 없습니다. 싼 게 아니었습니다. 비싼 것보다 더 나쁜 겁니다.
극단적인 이분법으로 말하는 게 아닙니다. 물론 비용이 무한하면 실패가 무한한 것만큼 쓸모없지만, 무한을 이야기할 이유는 없습니다.
그 비용이 얼마냐고요? 어느 정도입니다. 어느 정도는 든다는 거죠.
이건 안전 관련 절차의 비용과 그 절차가 줄여 주는 위험의 비용을 어떻게 계산하느냐는 문제를 다루지 못합니다("어느 정도"라고 말하는 것보다 훨씬 어려운 일이죠). 구매자가 그 "어느 정도"가 얼마인지 실제로 알 수 있어야 하는데도요.
또 바로 윗글의 요점도 다루지 않았습니다. 항공에서는 나쁜 결과가 인명 안전으로나 금전적으로나 파급력이 아주 커서 실수를 용납하는 수준이 훨씬 낮다는 점 말입니다.
홍보용 웹사이트의 사이버 보안과 비교해 보세요. "보안 사고"에서 "누군가 죽는다"까지 가려면 훨씬 더 큰 비약이 필요합니다. (게다가 사이버 보안 쪽 사람들은 "비용이 들긴 하는데, 너무 비싸지 않으면 사시겠죠" 같은 말을 받아들이지 않을 겁니다.)
민간 항공 업계에서는 계산이 아주 쉽습니다. 사망자 0명이 허용 기준입니다. 자동차 제조사의 리콜 계산과는 다릅니다(영화 파이트 클럽에서 유명하게 언급됐죠. 소송 비용이 리콜 비용보다 적으면 리콜하지 않는다는 얘기요). 항공 업계는 강력한 규제 덕분에 다르게 만들어졌습니다.
그 정도로 안전하게 만들 _가치_가 있느냐고 물을 수도 있습니다. 하지만 우리는 그렇게 묻지 않습니다. 그냥 그만큼 안전하게 만듭니다.
민간 항공에서는 대체로 그럴 가치가 있다고 여겨지지만, 사이버 보안에서는 (비용이 드는 만큼 드는) 이 정도의 안전 수준이 대체로 그럴 만한 가치가 없을 거라는 주장도 충분히 성립한다고 생각합니다.
소프트웨어가 물리 세계를 점점 더 많이 매개하게 되면, 우리도 적어도 금융만큼은 규제를 받게 될 거고, 어쩌면 항공만큼 받을 수도 있습니다.
진짜 문제는 그 전에 피해가 얼마나 생기느냐뿐입니다.
실수를 0으로 만들려고만 하지 말고, 침해가 났을 때의 피해 범위를 줄이고 시스템을 더 견고하게 만들 수도 있습니다. 침해가 얼마나 심각한지, 얼마나 잘 복구할 수 있는지도 결과의 일부입니다. 침해 0건이 아니면 안 된다는 식으로만 보는 건, 침해를 줄이는 게 중요하긴 해도 별로 도움이 되지 않습니다.
이건 다른 얘기가 아닙니다. 쓰는 기법 중 하나일 뿐이고, 이것도 결국 사람이 자기가 만드는 시스템을 이해해야 합니다. 시스템에 대한 이해를 AI에 맡기는 팀은 어떻게 포장하든 실패할 겁니다.
그게 "실수하지 않는 것"과 같은 말 아닌가요? 피해 범위를 줄일 수 있었는데 안 했다면, 그것 자체가 큰 실수 아닙니까?
코드 중에는 충분히 신중하게 쓰이지 않은 게 분명히 많습니다. 비밀번호를 평문으로 저장하는 사례도 세상에 널려 있고요.
아니요, 실수는 일어나게 마련이고 완벽한 사람은 없다는 걸 인정하는 겁니다. 피해 범위를 줄이는 일에서도 실수는 합니다. 실제 폭발이 났을 때 방폭문이 닫히지 않거나 생각한 대로 작동하지 않을 때도 있으니까요.
핵심은 다층 방어입니다. 스위스 치즈 모델이죠.
맞는데, 그건 시스템을 관찰하고 이해하는 능력이 병목입니다. 그리고 바로 그 능력이 AI 도구를 아무 생각 없이 쓰면서 줄어들고 있는 거고요.