막내가 만든 스크립트가 전사 컴퓨터를 다 꺼버렸다 - sysadmin 사고에서 배우는 권한 설계

'한 명이 회사 전체를 멈춘 날'

레딧의 r/sysadmin 게시판에 올라온 한 글이 인프라 담당자들 사이에서 회자되고 있어요. 신입 직원이 만든 PowerShell 스크립트가 회사의 모든 컴퓨터를 한 번에 셧다운시켜버린 사고 이야기예요. 글쓴이(OP, Original Poster) 본인이 그 신입이고, 자기가 어떻게 일을 저질렀고 무엇을 배웠는지를 솔직하게 풀어놨어요.

사건의 구도는 이래요. 신입은 '비활성 사용자의 PC를 자동으로 종료시켜 전력을 아끼는 스크립트'를 만들라는 업무를 받았어요. 의도는 좋았죠. PowerShell로 Active Directory를 조회해서 대상 PC 목록을 뽑고, 각 PC에 원격 셧다운 명령을 보내는 구조였어요. 문제는 테스트 환경에서 '대상 PC 필터'를 임시로 비활성화하고 테스트했는데, 그 필터를 원래대로 복원하지 않은 채로 프로덕션에 배포해버린 거예요. 결과는 참담했죠. 새벽 작업 시간에 사무실, 지사, 재택 근무자의 PC, 그리고 일부 서버까지 모두 셧다운 명령을 받았어요. 다음 날 아침 직원들이 출근해서 PC가 다 꺼져 있는 상황을 마주했고, 일부 부서는 반나절 동안 일을 못 했대요.

기술적으로 뭐가 잘못됐나

이 사고를 코드 관점에서 뜯어보면 흥미로운 포인트가 여러 개 있어요.

첫째, '테스트용 임시 변경'이 프로덕션으로 새어 나간 클래식한 패턴이에요. 개발하다 보면 if (false) 같은 가드를 잠깐 풀어두고 테스트하잖아요. 그걸 복원 안 하면 그대로 사고로 이어져요. 이걸 막는 방법은 '환경 변수 기반 분기'예요. 예를 들면 PowerShell이라면 if ($env:ENVIRONMENT -eq 'production')로 감싸서, 코드 자체에는 안전장치를 항상 켜둔 상태로 두고 환경에 따라 동작이 달라지게 하는 거죠.

둘째, 블래스트 레이디어스(blast radius, 폭발 반경) 제어가 없었어요. 보안 용어인데, '하나의 실수가 어디까지 영향을 미치는가'를 뜻해요. 좋은 자동화 스크립트는 한 번에 영향을 줄 수 있는 대상의 수를 강제로 제한해요. 예를 들어 Get-ADComputer ... | Select -First 10처럼 처음 10대만 동작하게 하거나, '10대 넘게 종료하려면 관리자 확인이 필요합니다' 같은 휴먼 게이트를 넣는 식이죠. 이 사례에서는 그런 안전장치가 전혀 없어서 1대든 1만 대든 똑같이 실행돼버린 거예요.

셋째, dry-run 모드 부재예요. 인프라 자동화 스크립트는 거의 무조건 -WhatIf 같은 시뮬레이션 모드를 가져야 해요. PowerShell은 내장 매개변수로 -WhatIf를 지원하기 때문에 추가 노력 없이도 '실행했다면 어떤 일이 일어났을지'를 미리 출력할 수 있어요. 이걸 안 쓰고 곧장 진짜 명령을 날린 게 사고의 직접 원인이에요.

넷째, 권한 분리가 안 됐어요. 신입 한 명이 도메인 전역에 셧다운 명령을 보낼 수 있는 권한을 가지고 있었다는 자체가 조직 차원의 문제예요. 보통은 '대상 OU(조직 단위)에 한해서만' 권한을 주거나, 셧다운 같은 위험한 명령은 별도 승인 워크플로를 거치게 해요.

비슷한 사례들 - 이런 사고는 늘 있어왔다

이 사고가 새삼스러운 이유는, 사실 IT 역사에 비슷한 사례가 무수히 많기 때문이에요. 2017년 AWS S3 대규모 장애는 엔지니어가 디버깅 명령을 입력하다가 매개변수 하나를 잘못 써서 의도한 것보다 훨씬 많은 서버를 종료시킨 게 원인이었어요. GitLab은 2017년에 시니어 엔지니어가 새벽에 졸린 상태로 rm -rf를 잘못된 서버에 입력해서 6시간 분량의 프로덕션 데이터를 날렸고요. Knight Capital이라는 금융회사는 잘못된 트레이딩 봇 배포로 45분 만에 4억 4천만 달러를 잃고 회사가 망했어요.

공통점이 보이세요? 사람은 반드시 실수해요. 그래서 좋은 인프라는 '실수를 안 하게 만드는' 게 아니라 '실수해도 회사가 안 망하게 만드는' 방향으로 설계돼요. SRE(Site Reliability Engineering) 문화에서 'blameless postmortem(비난하지 않는 사후 분석)'을 강조하는 이유도 여기 있어요. 사람을 탓하면 다음 사람이 같은 실수를 숨기고, 시스템을 고치면 모두가 안전해지니까요.

한국 개발자에게 - 이건 남 이야기가 아니에요

한국에서도 비슷한 사고가 자주 일어나요. 다만 잘 공개되지 않을 뿐이에요. 회사 정책상 사후 분석을 외부에 못 내거나, 사고 친 사람이 조용히 회사를 나가는 경우가 많아서 그래요. 그런데 이런 사례를 공유하지 않으면 우리 모두가 같은 실수를 반복할 수밖에 없어요.

실무에서 당장 적용할 수 있는 체크리스트를 하나 드릴게요. 인프라/배포/일괄 처리 스크립트를 만들 때는 이 네 가지를 꼭 챙기세요. (1) 환경 변수로 prod/staging 분기를 강제할 것, (2) 영향 범위 상한을 코드에 박아둘 것(예: MAX_TARGETS=100), (3) dry-run 옵션을 반드시 만들고 첫 실행은 무조건 dry-run으로 할 것, (4) 위험한 작업은 두 명 이상의 승인을 거치게 할 것.

그리고 본인이 사고 친 신입이라면, 솔직하게 빨리 보고하세요. 숨기면 두 배로 커져요. 글쓴이도 자기가 즉시 보고하고 복구 작업에 참여한 덕에 해고는 면했다고 해요. 여러분은 '이 정도면 안전하겠지' 하고 넘긴 자동화 스크립트, 혹시 없으세요? 이번 주말에 한 번 점검해볼 가치가 있을지도 몰라요.