본 글은 AI가 SRE(Site Reliability Engineering) 직무를 대체하기보다 오히려 숙련도를 떨어뜨릴 수 있다는 우려를 제기합니다. 저자는 복잡한 시스템 장애 대응에 필요한 깊은 이해와 디버깅 직관은 직접적인 경험을 통해서만 얻을 수 있다고 주장합니다. 현재 AI 에이전트가 특정 작업에서는 인간을 능가하지만, 전체 시스템의 구조적 '이해'는 여전히 개발자의 몫임을 강조합니다.
핵심 포인트
AI는 SRE를 대체하기보다 숙련도 저하를 유발할 위험이 있다.
복잡한 장애 대응 직관은 직접적인 경험과 가설 검증을 통해 기른다.
SRE는 시스템 전반의 깊은 이해가 필수적이며, AI는 이 '이해' 자체를 갖지 못한다.
AI 에이전트는 AWS CLI 사용 등 특정 운영 작업에서 인간보다 빠르다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
“자동조종이 충분히 가능해도 FAA가 수동 비행 시간을 요구하듯, SRE 팀도 AI가 처리할 수 있는 장애 일부를 사람의 훈련 기회로 지정할 수 있다”는 비유가 좋음. 항공업계는 복잡성이 커지고 자동화가 업무를 가져가는 와중에도 인간의 실수를 줄이는 방법을 많이 알아냈기에 배울 만함.
치명적 실수 제로가 목표라면 항공업계가 좋은 본보기지만, 거기에는 비용이 따름. Erlang으로 핫 리로드와 관측 가능성을 갖춘 고가용성 시스템을 운영하는 데도 비용이 드는 것과 같음.
모든 프로젝트에 같은 특성이 필요한 것은 아님. 일 년에 한 번 쓰는 정부 포털이라면 새벽 3~5시나 정오 이후에 계획·비계획 점검으로 잠시 중단돼도 괜찮음.
조종사처럼 SRE도 숙련도를 유지하려면 연간 최소 시뮬레이터 훈련 시간을 채워야 할 것임.
항공을 인간의 절차로 안전을 확보하는 만능 비유로 그만 우려먹었으면 함. 계기비행 자격이 있는 자가용 조종사인데, 실제로는 위에서부터 조종사 1인 운항을 강하게 추진하고 있음. 신형 제트기는 여객기까지도 아직 그렇게 인증받지 않았을 뿐, 이를 염두에 두고 설계됨.
항공은 법적 책임에 대비해야 하는 의무가 지대 추구를 뒷받침한다는 점에서 다름. 소프트웨어에도 같은 유인 구조가 있는지는 모르겠음. 결국 다른 취미를 찾아야 할지도 모름.
“새롭고 복잡한 연쇄 장애인 3단계 장애만 사람이 맡으면 대응 직관을 어디서 기르느냐”는데, AI 이전에는 어떻게 했을까? 복잡한 운영 환경 디버깅을 많이 해봤지만, 이런 장애는 늘 처음 보는 문제를 바닥부터 풀어야 했음.
내가 기른 직관은 끈기 있게 여러 가설을 검증하거나 기각하는 능력임. 3단계 장애의 직관은 결국 3단계 장애를 직접 다뤄야 기를 수 있다고 봄.
스타트업에서 프로그래밍부터 배포, DB, 클라우드, 네트워크까지 다루는데, AI 에이전트의 컴퓨터 활용 능력은 이제 인간을 넘어섰다고 느낌. AWS CLI를 Claude만큼 잘 쓰는 것은 내게 불가능할 것 같음.
AWS를 뒤지고 로그와 라우팅 테이블, DB 데이터를 직접 대조하는 대신 Claude에 읽기 전용 권한을 주면, 나보다 10배 빠르게 해결하고 전달용 상세 보고서까지 작성함. 가끔 헛소리도 하지만 계속 좋아지고 있음.
그래도 실력 퇴화는 현실임. 그 때문에 다시 채용 면접에 나서는 것이 꽤 두렵고, 앞으로 어떻게 될지 모르겠음.
SRE는 언제나 시스템을 이해하는 일이었음. 데이터 흐름, 병목, 로그, 애플리케이션 구조, 사용자 기능, 장애 지점, SLI와 SLO를 이해하고, 피해 완화부터 점진적 성능 저하, 재시작, 복구, 재생성, 확장까지 알아야 함. AI가 생성한 애플리케이션에는 그런 이해가 없음. 단호하게 그렇게 봄.
지난 10년 동안 그 모든 것을 이해하는 수석 아키텍트나 개발자를 별로 만나지 못했음. 기업은 반나절 공부하고 해당 분야를 익혔다는 분야별 전문가를 좋아함. 스타트업은 다를지 몰라도, 비교적 큰 기업을 상대하는 컨설팅 업계에서는 정말 웃기는 수준임.
Pi, Mac, 조명, Google 스피커, 맞춤형 ESP32 보드를 연결하는 시스템을 많이 만드는데, 각각의 기능과 통신 방식을 이해해 통합하는 일은 여전히 내 몫임.
프롬프트 하나로 바로 운영 환경에 내보내는 경우라면 몰라도, 법무·설계·QA 등 사람의 승인이 필요한 요소가 많아 아직 거기까지 가지 못했다고 봄. AI는 이해를 없애기보다 이해해야 할 추상화 수준을 높여 줌.
이해가 필요하다는 데는 동의하지만, 필요한 세부 사항은 경력과 추상화 수준에 따라 달라짐. SRE도 초급부터 Fellow급까지 있음.
여러 팀·조직·회사가 운영하는 수백~수천 개 서비스에 관여하는 Fellow에게 각 구성 요소의 세부 구현이나 시작 방식까지 알기를 기대하지는 않음. 작은 범위나 하위 구성 요소를 다루는 주니어가 오히려 그런 세부 사항을 직접 다룰 가능성이 큼.
SRE라는 직무명도, 제로금리 정책 시기에 겪어야 했던 DevOps 열풍도 별로였음. 제대로 하는 개발자라면 자신이 만든 시스템의 온콜을 맡아야 함.
DevOps 자체는 합리적인 발상이었지만 실제 구현은 드물었음. 개발자와 별도로 DevOps 전담 조직이 있었다면, 정의상 DevOps를 하고 있던 것이 아님.
Google의 SRE는 원래 신뢰성을 위한 인프라 구축이 목적이었고, 베어메탈 LAMP와 DNS 부하 분산이 흔하던 시절에 시작됨. 상태 확인과 장애 조치를 갖춘 부하 분산, 무중단 업데이트 등을 전담하는 조직은 충분히 합리적임.
이런 문제가 기성 소프트웨어로 대부분 해결된 뒤에는 SRE가 정책과 강제로 신뢰성을 확보하는 관료 조직이 되거나, 남의 코드를 배포하고 장애 호출을 받는 역할이 됨.
회사도 대가를 부담해야 하므로 월금 917시 외에는 아예 연락이 닿지 않는 편을 선호함. 그렇지 않으면 회사는 너무 쉽게 24시간 온콜을 받아들이는 사람들을 착취함. 근무 외 시간에 연락되지 않는다고 경영진에게 시달리지 않으려면, 나 역시 시스템을 최대한 잘 만들 동기가 생김.
회사에는 “개발자에게 전화하기”가 아닌 제대로 된 장애 대응 계획이 필요함. 대안이 개발자 착취가 아니라 고객 서비스 중단이 되면, 지원과 테스트에 놀랄 만큼 신경 쓰게 됨.
자신이 만든 시스템의 온콜을 맡는 것이 바로 DevOps임. 엔지니어에게 자기 시스템의 장애 대응을 맡기면 AI 에이전트가 만든 코드를 검토하고 동작을 이해하게 하는 데도 효과가 큼.
ZIRP는 무슨 뜻인가? 익숙하지 않은 약어임.
사람들이 기술 전문가나 기술 총괄이라는 새로운 진로로 향하는 것 같음. 목표와 피드백에 맞춰 적절한 순간에 올바른 질문을 던지고, 필요한 곳에 주의를 집중시키는 역할임.
공학 업무에서 질문하고 방향을 잡는 일이 차지하는 비중을 너무 과소평가함. 자기 자신을 제외한 AI 사용자를 상상할 때는 호기심도 탐구심도 없는 바이브 코더를 떠올리고, 자신과 같은 고생을 해야만 질문하고 호기심을 유지할 수 있다고 여김. 그래야 세상에 자신이 계속 필요하다는 결론이 나기 때문임.
하지만 전문 프로그래머가 되기 전 자신과 똑같은 호기심과 탐구심을 가진 바이브 코더를 상상하면 됨. 이제는 작동 원리를 이해하려고 소프트웨어 경력을 처음부터 쌓을 필요 없이, 바로 질문할 수 있다는 차이뿐임.
내 기준으로는 그 일이 원래부터 가장 가치 있는 부분이었음. 다만 다른 업무도 제대로 해내기가 상당히 어려워서, 그 부분만 전문으로 삼아 경력을 쌓을 수 있었던 것임.
이것이 꼭 AI 때문인지는 모르겠음. 운영 성숙도가 다양한 회사에서 일했는데, 오래된 SRE 조직 중에는 이미 대부분 3단계 장애 위주로 대응하는 곳도 있었음.
한 조직은 자동 복구와 같은 원인의 반복 호출을 적극 자동화하는 문화 덕에 불필요한 호출을 거의 잡았음. 내가 받은 호출은 대부분 새롭거나 드문 장애였고, 살펴볼 일이 예외적인 장애뿐이라 시스템의 고장 방식에 대한 직관을 기르는 데 훨씬 오래 걸렸음.
직장에서 Claude를 쓰는데, 여러 관측 신호를 연관 짓는 단순한 작업은 보통의 SRE보다 빠름. 하지만 SRE처럼 일하게 하려면 회사 맥락을 반영한 실행 환경을 만드는 데 상당한 노력이 필요함.
결국 도구이므로 제대로 활용하려면 자신의 지식도 쌓아야 함. 그렇지 않으면 무딘 도구일 뿐이며, 역량이 부족하면 도구가 무엇이든 마찬가지임.
클러스터 전체 장애를 분석한다면, 시스템이 이미 수집하는 관측 데이터 외에 어떤 맥락이 필요한가?
설정이 정말 그렇게 복잡한가? 기본형이라면 원하는 터미널 코딩 에이전트에서 모든 것을 CLI로 다룰 수 있게 하고, 경보에 연결해 한쪽에서 실행해 두면 되지 않나? CLI 환경은 이미 대부분 갖춰져 있을 것 같음.
며칠 전 AI로 인한 숙련도 저하를 살펴봤는데 좋은 징후는 없었음. 그래도 매주 한 시간 코딩하기, LeetCode 문제 풀기, 병합 전에 에이전트에게 퀴즈를 내게 하기처럼 의식적으로 할 수 있는 일은 있음. 마지막 방법은 Notion에서 가져옴.
나도 같은 불안이 계속 마음에 걸림. 이 주제를 다룬다는 Eric C So의 The Collision을 읽기 시작했고, 아직 다 읽지는 못했지만 지금까지는 괜찮아 보임.
이대로 가면 10년은커녕 몇 년 뒤 코드를 작성하거나 이해조차 못 하게 될 수 있다는 생각이 우울함. 경제적 효용이 줄더라도, 이론상 막을 수 있는 기술 상실은 여전히 씁쓸함. 동시에 무언가를 만드는 데 깊은 무기력함을 느끼며, 자발적으로 할 수 있는 것은 Zachtronics 게임 정도가 한계임. 다른 사람들은 어떻게 생각하고 대처하는지 듣고 싶음.
단순 바이브 코딩과 신뢰할 만한 AI 활용의 차이는 사전에 작성하는 명세와 사후 테스트임. 최종 목표만 입력하고 실행되면 받아들이는 방식은 AI가 방향을 정하게 만듦. 이는 빠른 출시, 애자일, 일일 회의, 페어 프로그래밍에 익숙한 개발자들이 기존 동료를 에이전트로 바꾸는 것과 비슷하며, 바로 그 점이 실수임.
반대로 전통적인 공학처럼 명세·설계도·테스트를 먼저 생각하면 사람이 에이전트를 통제함. 쓸 라이브러리와 제외할 라이브러리, 방법론까지 명세로 정하고 에이전트는 구문 작성과 테스트를 돕게 하면 됨. AI가 구문을 인간보다 잘 작성한다는 사실을 받아들이고, 개발자보다 엔지니어의 사고방식으로 옮겨가야 함.
내 프로젝트는 두 달째 명세와 설계도를 만드는 중이며, 미래 기능까지 정의한 파일이 1,000개가 넘지만 코드는 아직 한 줄도 작성하지 않았음. 나중에 에이전트가 이를 바탕으로 필요한 코드와 테스트를 생성하게 할 계획임.
반대표를 받겠지만, 경력 15년 차인 내게 매주 코딩이나 LeetCode 연습을 하라는 것은 사양하고 싶음. 일상적인 코딩은 3~4년 전에 매력을 잃었고, 이제 목적을 이루는 수단일 뿐임. 나에게 AI는 적절한 시기에 등장했다고 느낌.