AI가 SRE를 대체하는 게 아니라 실력을 퇴화시킨다는 1983년 '자동화의 역설' 재조명
- 1983년 인지심리학자 Lisanne Bainbridge의 논문 Ironies of Automation을 근거로, 자동화가 늘수록 인간은 실패 순간에 더 결정적이면서도 연습 기회를 잃어 그 순간에 더 취약해진다는 역설을 AI SRE 논쟁에 그대로 적용함
- 핵심 질문은 AI가 사고 대응의 95%를 처리하게 될 때 남은 5%를 다루는 실무 능력이 오히려 퇴화하는지이며, 저자는 이를 산업 자동화 시대에 근육 기억을 잃은 예외 처리와 같은 패턴으로 봄
- 알림 노이즈 감소와 지능형 그룹화, 런북 실행, 로그 패턴 탐지와 이상 플래그, 과거 장애 데이터 기반 원인 추천, pod 재시작이나 과부하 서비스 스케일업 같은 자동 복구는 이미 AI로 상당 부분 자동화됨
- 다음 목표로는 메트릭, 로그, 트레이스 다중 신호 상관, 부분적으로 이해된 실패의 자율 근본 원인 분석, 사용자 영향 전 예측 장애 탐지, 변경 위험 평가와 자동 롤백이 제시됨
- PagerDuty의 계층 모델에서는 알려진 원인과 알려진 수정이 있는 Tier 1 장애가 완전 자동화 대상이 되고, Tier 2 이하로 갈수록 사람이 개입하는 구조임
Hacker News 의견들
AI 디스킬링 영상 몇 개 파봤는데 좋은 신호가 하나도 없더라. 매주 코딩 한 시간 정하고 릿코드 한 문제 풀고, 머지 전에 에이전트가 나한테 퀴즈 내게 하는 식으로 버티는 중임.
15년차인데 그건 좀 아니지. 일상 코딩의 매력은 3~4년 전에 사라졌고 이제는 목적을 위한 수단일 뿐임. 나한테는 AI가 딱 맞는 타이밍이었음.
'The Collision' 읽는 중인데 몇 년 뒤엔 코드를 이해조차 못 하게 될 거라는 생각이 우울함. 지금은 Zachtronics 게임이 내적 동기를 밀어붙일 수 있는 한계임.
진짜 차이는 스펙과 테스트임. 스펙 먼저 쓰고 테스트를 짜면 에이전트를 내가 통제하고, 반대로 프롬프트로 끝을 던지면 에이전트가 나를 끌고 감.
메트릭, 로그, 트레이스 다중 신호 상관과 자율 근본 원인 분석은 AI가 SRE 워크플로에서 이미 꽤 잘함. 변경 위험 평가도 절반 정도는 함.
Claude 켜놓고 2시간 동안 디버깅한 걸 봤는데 Claude 없이 보면 눈에 보이는 문제였음. Claude가 죽는 날 우리도 같이 죽는 거임.
최악은 장애 한복판에서 개발자 둘이 Claude 출력물을 주고받는 거임. 자기 머리를 안 씀.
이제 회사가 Enterprise LLM 접근만 끊어도 사실상 해고가 가능해진 셈임.
월급만 제때 나오면 난 상관 없음. 수동공격적으로 나와도 좋음.
난 LLM 회사가 접근을 끊거나 돈이 떨어져서 망하면 우리 회사 전체가 끝날 수 있다는 게 더 무서움.
SRE는 원래 형편없는 직무 이름이었고 ZIRP 시절 DevOps도 마찬가지였음. 진짜는 자기가 만든 시스템의 온콜을 서는 사람임.
DevOps는 합리적인 아이디어였는데 실제로 그렇게 굴러간 경우는 드물었음. 개발자와 별도로 'DevOps 팀'이 있으면 정의상 DevOps가 아님.
구글 SRE는 개발자와 붙어서 시스템을 설계하고 만듦. 대부분 SWE 레더에 있고 버그도 직접 고치고 스케일도 직접 함. 릴리스 속도를 조절하거나 바이너리 아키텍처를 못 바꾸면 SRE가 아님.
SRE는 인프라, 플랫폼 엔지니어링으로 밀려나는 중이고 그건 그냥 테라폼 쓰는 쿠버네티스 관리자 일이 됨.
오프더셸프 소프트웨어로 로드밸런싱이나 무중단 배포가 해결되면서 SRE는 정책과 규제로 신뢰성을 지키는 관료제가 되거나, 남의 코드 배포하고 페이저만 들고 있는 일이 됐음.
난 회사가 피부에 와닿아야 해서 업무 시간 외엔 연락이 아예 안 닿는 걸 선호함. 대신 회사가 '개발자 호출' 말고 제대로 된 대응 계획을 갖추게 만들거든. 고객 장애가 대안이 되면 지원과 테스트에 훨씬 신경 씀.