02 · AI가 장애를 해결할 때 SRE는 어디서 경험을 쌓나

AI가 복구를 앞당겼다면, 사람이 그 원인과 조치를 이해했는지도 따로 확인해야 합니다. 속도만으로는 알 수 없습니다. 이 글은 AI가 제시한 근거를 직접 확인하고, 해결 과정을 자신의 말로 설명하는 연습을 업무에 남기자고 제안합니다.

관측성 도구를 만드는 SigNoz의 Elizabeth는 2026-02-28에 쓴 AI Isn’t Replacing SREs. It’s Deskilling Them.에서 그 연습이 사라질 위험을 제기했습니다. “AI가 장애 대응의 95%를 처리한다면, 사람은 중요한 나머지 5%를 해결하는 데 더 서툴러질까?”라는 질문입니다. 95%와 5%는 측정한 자동화 비율이 아닌 가정입니다.

GeekNews와 Hacker News에서는 숙련을 잃는다는 경험담뿐 아니라, 예전 기술을 모두 보존할 이유는 없다는 반론도 나왔습니다. 소프트웨어로 서비스의 신뢰성을 높이는 SRE의 기본 개념과 책임 범위는 앞 글에서 다뤘습니다. 이번 논쟁에서는 그 일을 수행할 판단력을 어디서 배우고 유지할지가 쟁점입니다.

손으로 쓰는 기술과 원인을 판단하는 기술

무엇을 덜 하게 됐다는 사실만으로 숙련의 손실을 판단할 수는 없습니다. Hacker News의 한 댓글은 Terraform이 인프라 설정을 자동화했을 때도 예전 기술 일부가 덜 필요해졌다며, AI가 처리할 수 있는 일을 굳이 손으로 되풀이할 이유가 없다고 주장했습니다. Docker가 시스템 관리 방식을 바꾼 일도 비슷한 변화로 거론됐습니다.

이에 달린 답글은 사내 모듈을 호출할 줄만 알고, 그 아래에 어떤 인프라가 만들어지는지 모르는 SRE의 사례를 들었습니다. 이 글은 여기서 반복적인 설정 문법과 인프라를 이해하는 능력을 구분합니다. 문법 작성을 도구에 맡기는 일과, 도구가 만든 결과를 설명하지 못하는 일은 따로 살펴야 합니다.

계산기 비유를 둘러싼 논쟁도 같은 차이를 짚었습니다. 필산을 계산기에 맡기듯 AI에 세부 작업을 맡기면 더 큰 문제를 풀 수 있다는 의견에, 나눗셈 절차를 외우지 않는 것과 나눗셈의 의미를 모르는 것은 다르다는 반론이 붙었습니다. 계산기와 달리 AI의 답에는 오류가 섞일 수 있다는 지적도 있었습니다.

이 글은 SRE가 담당 시스템에서 내려야 할 판단을 기준으로 필요한 이해의 범위를 살펴봅니다. 데이터가 어디로 흐르는지, 지연이 늘면 어느 지점을 의심할지, 복구 조치가 다른 서비스에 어떤 영향을 줄지 알아야 AI의 제안을 평가할 수 있습니다. 필요한 이해의 깊이는 담당 범위와 역할에 따라 다를 수 있습니다. Hacker News에서도 수백~수천 개 서비스를 책임지는 사람이 모든 구성요소의 내부 구현을 같은 깊이로 알 수는 없다며, 담당 범위와 역할을 고려해야 한다는 의견이 나왔습니다.

질문을 잘 만들고, 결과를 전달하며, 환각을 찾아내고, 유용한 정보와 잡음을 구분하는 능력이 새롭게 자란다는 댓글도 있었습니다. 여기에 붙은 반론은 그런 판단에도 배경지식이 필요하다는 것이었습니다. 직접 시스템을 다뤄야 AI의 오류를 알아보는 데 필요한 지식이 쌓인다는 지적입니다.

사람에게 어려운 장애만 남긴다면

Elizabeth의 우려는 판단력을 배우는 경로에 있습니다. AI가 익숙한 문제를 처리하고 사람은 처음 보는 장애에만 개입한다면, 그 어려운 판단을 준비할 경험이 부족해질 수 있다는 주장입니다.

뉴스레터는 경보를 묶어 잡음을 줄이거나 로그에서 이상 징후를 찾는 일, 알려진 장애의 대응 절차를 실행하는 일을 자동화가 많이 진행된 영역으로 꼽습니다. 중단된 파드를 다시 시작하고 부하가 높은 서비스의 자원을 늘리는 작업도 포함됩니다. 메트릭·로그·트레이스를 함께 분석하거나 변경 위험을 판단해 자동으로 롤백하는 일은 다음 목표로 제시했습니다.

뉴스레터가 소개한 PagerDuty의 역할 구분에서는 장애가 낯설고 복잡할수록 사람이 대응을 이끕니다. 아래 표는 그 분담을 보여 주며, 모든 제품이나 조직에서 이 수준의 자동화가 가능하다는 뜻은 아닙니다.

Elizabeth는 Tier 3에 필요한 직관이 수년간의 직접 장애 대응과 반복으로 쌓인 패턴 인식에서 자란다고 봅니다. 이 글은 비슷한 증상을 반복해서 살피고, 예상이 빗나간 이유를 찾고, 시스템의 실제 동작을 익히는 일을 이런 경험의 일부로 봅니다. SRE가 어려운 장애만 맡는다고 그 경험까지 생기지는 않는다는 문제 제기입니다.

이 논의의 바탕에는 Lisanne Bainbridge의 1983년 논문 Ironies of Automation이 있습니다. 자동화된 공정에서도 예외는 사람이 처리해야 하지만, 자동화가 잘 작동할수록 사람은 개입을 연습하기 어려워집니다. Elizabeth는 평소에는 감시하다가 드물고 어려운 상황에서 능숙하게 대응해야 하는 이 역설을 AI와 SRE의 관계에 적용했습니다.

경험자에게 뉴스레터가 경고하는 위험은 디스킬링(deskilling), 곧 이미 익힌 능력을 쓰지 않아 잃는 현상입니다. 로그 요약을 받아 원본을 덜 읽고, 원인 제안을 받아 스스로 가설을 세우지 않고, 의존 관계 설명을 받아 시스템을 직접 따라가 보지 않는 편의가 쌓이면 판단에 필요한 감각도 약해질 수 있다고 봅니다.

주니어는 출발점이 다릅니다. 뉴스레터는 능력을 처음부터 익힐 기회를 얻지 못하는 상황을 네버스킬링(never-skilling)이라고 부릅니다. 이 문제가 개인의 능력을 넘어 다음 세대의 SRE를 길러 내는 일에 영향을 미치며, 훈련 경로 자체가 무너져 저절로 회복되지 않는다고 주장합니다. 이 글은 해결된 장애 보고서를 읽는 것과 직접 문제를 푸는 일을 서로 다른 학습 경험으로 봅니다. Hacker News에서도 AI의 출력을 검토하는 시니어는 주니어 시절의 훈련과 멘토링을 거쳐 성장했다며, 그 과정을 없앤 뒤에도 숙련된 사람을 계속 구할 수 있겠느냐는 우려가 나왔습니다.

의료 연구는 SRE의 숙련을 측정하지 않았다

의료 연구의 측정 결과와 토론에 나온 숙련 저하의 체감은 구분해야 합니다. 개발부터 배포, 데이터베이스, 네트워크까지 맡는 한 Hacker News 작성자는 Claude에 읽기 전용 접근 권한을 주면 자신보다 훨씬 빨리 원인을 찾고 보고서까지 작성한다고 했습니다. 그러면서 직접 문제를 푸는 능력이 줄어드는 듯해 다시 면접을 볼 생각이 두렵다고 덧붙였습니다. 생산성 향상과 불안을 함께 전한 개인의 경험입니다.

뉴스레터는 다른 분야의 연구도 근거로 들었습니다. 여기서는 무엇을 측정했는지 구분해야 합니다.

2025년 대장내시경 연구는 폴란드의 네 개 의료기관에서 AI 도입 전후에 AI 없이 시행한 검사를 비교했습니다. 선종 발견률은 28.4%에서 22.4%로 낮아졌습니다. 후향적 관찰연구였으며, 연구진도 선택편향과 다른 요인의 영향을 한계로 밝혔습니다. 이 글에서는 이를 AI 때문에 숙련이 떨어졌다는 인과관계의 확정이나 SRE의 숙련 저하를 직접 입증한 결과로 읽지 않습니다. 추가로 조사할 만한 변화가 관찰됐다는 범위에서 받아들입니다.

항공 사례에는 원문의 표현을 바로잡을 부분도 있습니다. Elizabeth는 FAA가 수동 비행 시간을 늘리도록 의무화했다고 썼지만, FAA의 비행 경로 관리 지침은 적절한 상황에서 수동 비행을 허용하고 장려하도록 권고합니다. 권고와 의무 규정은 다릅니다.

이 자료들은 자동화 이후에도 개입 능력을 연습할 이유를 생각하게 합니다. AI를 쓰는 SRE의 실력이 반드시 떨어진다는 결론까지 뒷받침하지는 않습니다. 이 글의 실무 제안도 그 구분에서 출발합니다. 복구가 빨라졌는지와 사람이 무엇을 이해하게 됐는지를 따로 확인하자는 것입니다.

Claude가 무엇을 보고 답했는지도 확인하기

Hacker News에서 신호 간 상관관계 파악 같은 단순한 작업에서는 Claude가 평균적인 SRE보다 빠르다고 본 작성자도 회사의 환경에서 쓸 만하게 만드는 데 상당한 노력이 들었다고 했습니다. 여러 신호를 빠르게 연결하는 능력과, 회사의 맥락을 반영해 도구와 정보를 제공하는 일은 별개의 과제였다고 설명했습니다.

터미널 에이전트에 기존 명령줄 도구를 연결하면 기본적인 구성을 만들 수 있는데, 설정이 그렇게 복잡한지 묻는 질문도 나왔습니다. 이에 달린 답글은 문서와 실제 동작이 다르거나 에이전트가 모르는 계층에서 장애가 나면, AI가 경보를 잘못 해석해 엉뚱한 원인을 짚는 일이 자주 있었다고 전했습니다. 별도의 스레드에서는 관측 데이터 외에 어떤 맥락이 필요한지 묻는 질문에 코드베이스와 설계 문서, 외부 서비스의 상태가 필요하다는 답글이 달렸습니다.

실패 경험도 있었습니다. 한 작성자는 팀원들이 AI와 두 시간 동안 디버깅했지만, 직접 살펴봤다면 쉽게 찾았을 원인이었다고 전했습니다. 앞서 나온 성공 경험과 이 사례는 모델 성능을 비교한 실험이 아닙니다. 이 글에서는 서로 다른 평가를 이해하려면 AI가 접근한 정보, 시스템의 복잡성, 사람이 결과를 확인한 방식까지 함께 봐야 한다고 해석합니다.

SigNoz도 이 맥락에서 제품 방향을 설명합니다. 메트릭·로그·트레이스의 데이터 계층을 직접 다룬다는 점을 강점으로 내세우며, 먼저 사람이 통제하는 AI 어시스턴트를 제공한 뒤 신뢰가 쌓이면 정해진 범위 안에서 자율성을 넓히겠다고 밝혔습니다. 이는 벤더가 제시한 설계 방향입니다. 해당 제품이 숙련 저하를 막는 효과를 입증했다는 뜻은 아닙니다.

원본을 열고, 자신의 말로 설명하는 연습

Elizabeth는 AI를 적극적으로 쓰면서 사람이 문제 해결에 참여할 기회를 남기자고 제안합니다. AI의 권고를 승인하는 일과, 근거를 살피며 함께 문제를 푸는 일을 구분한 제안입니다.

GeekNews의 한 이용자는 원본 하나를 직접 여는 습관을 들였다고 전했습니다. AI가 확인했다고 보고해 넘어갔는데, 실제로는 원본을 보지 않은 적이 있었다고 합니다. 그 뒤로는 결과가 맞아 보여도 원본 하나는 직접 연다는 경험입니다. 승인만 하는 자리로 밀려나지 않으려고 일부러 남겨 둔 “손일”이라고 표현했습니다. 개발 분야의 사례는 아니지만, 결과를 승인하기 전에 근거를 확인하는 행동이 무엇인지 보여 줍니다.

Hacker News에는 코딩 에이전트를 쓰는 인턴에게 해결책의 작동 원리를 계속 설명하게 했다는 경험도 올라왔습니다. 처음에는 답하지 못하던 인턴들이 질문을 반복해서 받자 설명을 준비하기 시작했다고 합니다. 작성자는 이런 문답이 시행착오와 디버깅으로 얻는 깊이에는 못 미친다고 봤습니다. 그래도 완성된 결과를 이해했는지 확인하는 연습으로 제안했습니다. 작성자는 숙련의 퇴화가 이해를 생산성과 맞바꾼 선택의 결과이며 피할 수 있다고 봤습니다.

장애 대응 자체를 연습하는 사례도 있습니다. GeekNews가 옮긴 Hacker News 의견에 등장하는 Wheel of Misfortune은 운영에 쓰지 않는 환경에 장애나 버그를 만들고, 진행자가 담당자를 뽑아 함께 수동으로 해결하는 훈련입니다. 이를 소개한 작성자는 Claude가 Postgres 잠금 대기열 적체의 원인을 찾는 데 도움을 줬다는 경험도 전했습니다. 직접 대응을 연습하면서 AI의 도움도 유용하게 썼다는 사례입니다.

아래는 토론에 나온 제안들을 이 글에서 재구성한 비운영 환경의 훈련 예시입니다.

이 예시는 결과만 승인할 때 놓치기 쉬운 이해의 빈틈을 확인하려는 구성이며, 실제 장애에 이 순서를 강제해 복구를 늦추자는 절차는 아닙니다.

훈련할 시간과 시스템을 바꿀 권한

뉴스레터는 AI가 처리할 수 있는 일도 일부는 사람이 연습하도록 남기는 방안을 “의도적 비효율”이라고 부릅니다. 빠른 처리의 일부를 포기하더라도 장기적으로 숙련을 유지하자는 제안입니다. Hacker News에서는 그 비용을 누가 부담할지 물었습니다.

AI가 몇 분 만에 해결할 장애를 사람이 오래 추적하면 고객에게 영향을 주는 시간이 늘어날 수 있다는 지적입니다. 항공의 수동 조종과 소프트웨어의 장애 대응을 그대로 비교하기 어렵다는 반론도 여기서 나왔습니다. 다른 댓글에서는 서비스마다 요구되는 가용성이 다른 만큼 같은 훈련 방식과 비용을 모든 팀에 요구하기 어렵다는 의견이 나왔습니다.

이 글이 제안하는 적용 방식은 복구와 학습의 시간을 나누는 것입니다. 실제 장애에서는 고객 영향을 줄이는 데 집중하고, 이후 비운영 환경에서 같은 문제를 다시 풀거나 대응 과정을 설명해 보는 방식입니다. 준비와 참여에도 시간이 듭니다. 훈련을 하기로 했다면 그 시간을 업무 안에서 확보하는 결정까지 필요합니다.

조직의 유인을 지적한 댓글도 같은 문제를 짚었습니다. 당장의 처리 속도만 평가하면 연습에 시간을 쓰기 어렵고, 사고가 적을수록 대비 비용의 효과를 설명하기도 어렵다는 주장입니다. 이 글에서는 이런 조건에서 학습을 개인의 열의에만 맡기면 밀린 업무에 따라 연습도 뒤로 밀릴 수 있다고 봅니다.

시간과 함께 살펴볼 대상은 SRE의 역할과 권한입니다. Hacker News에서 Google SRE를 설명한 댓글은 개발자와 함께 설계하고, 버그를 고치며, 확장성과 회복력을 개선하는 역할을 강조했습니다. 다른 댓글에서는 SRE가 남의 코드를 배포하고 호출을 받는 역할로 변했다는 비판이 나왔습니다. 개발자가 자신이 만든 서비스를 직접 운영해야 한다는 의견에는 복잡한 인프라와 신뢰성 문제에 별도의 전문성이 필요하다는 반론도 있었으며, 이 글은 SRE라는 이름 아래 맡는 일이 다르면 유지할 숙련도 달라진다고 봅니다. 이 글은 시스템을 이해하라는 요구에, 그 이해를 코드와 설계의 변경으로 이어 갈 권한도 포함돼야 한다고 봅니다.

자신이 만든 시스템의 온콜을 맡는 일이 AI가 작성한 코드를 검토하고 작동 원리를 이해하는 데도 효과가 크다는 의견 역시 있었습니다. 이와 별개로 개발자에게 언제든 전화하는 방식만으로 장애 대응을 해결해서는 안 된다는 의견도 있었습니다. 운영 결과를 이해하고 책임질 기회를 남기는 일에는 회사가 대응 체계를 마련하고 부담을 나누는 일도 포함됩니다.

참고 자료

• AI Isn’t Replacing SREs. It’s Deskilling Them. — SigNoz: Elizabeth의 숙련 저하 문제 제기와 대응 제안
• GeekNews 토픽과 댓글, Hacker News 토론: 실무 경험과 반론. GeekNews 이용자의 경험과 해당 토픽이 옮긴 Hacker News 의견을 본문에서 구분
• Ironies of Automation — Lisanne Bainbridge, 1983: 자동화된 공정에서 사람에게 남는 감시·개입·훈련의 문제
• Endoscopist deskilling risk after exposure to artificial intelligence in colonoscopy, 2025: AI 도입 전후의 비보조 검사 결과를 비교한 후향적 관찰연구
• Flightpath Management, AC 120-123 — FAA: 수동 비행과 자동화 관리 지침