Molly Guard: 서버 날려먹을 뻔한 경험, 다들 한 번쯤 있잖아요

실수 한 번이 장애로 이어지는 세계

서버 운영을 해본 사람이라면 한 번쯤은 등골이 서늘해지는 순간을 경험한 적이 있을 겁니다. SSH로 원격 서버에 접속해 있는 상태에서 무심코 shutdown -h now를 입력하거나, reboot 명령을 날렸다가 "어, 이거 로컬이 아니라 프로덕션 서버였는데?"라고 깨닫는 그 순간 말이죠. 이런 실수를 방지하기 위해 탄생한 것이 바로 Molly Guard라는 개념입니다.

Molly Guard라는 이름의 유래부터 재미있습니다. 원래 이 용어는 하드웨어 세계에서 온 것으로, 중요한 버튼 위에 씌우는 투명한 플라스틱 보호 커버를 뜻합니다. 비행기 조종석에서 미사일 발사 버튼이나 비상 스위치 위에 덮여 있는 그 뚜껑을 떠올리면 됩니다. 이름의 기원에는 여러 설이 있지만, 가장 널리 알려진 이야기는 IBM 프로그래머의 어린 딸 Molly가 메인프레임의 큰 빨간 전원 버튼을 누르는 것을 좋아했고, 결국 버튼 위에 보호 커버를 달게 되었다는 것입니다. "Molly로부터 지켜주는 가드"인 셈이죠.

리눅스 세계의 Molly Guard

이 개념은 리눅스 세계에서 실제 소프트웨어 패키지로 구현되어 있습니다. Debian과 Ubuntu 계열에서 apt install molly-guard 명령 한 줄이면 설치할 수 있는 이 패키지는, shutdown, reboot, halt, poweroff 같은 위험한 명령어를 가로채는 역할을 합니다.

동작 방식은 단순하면서도 효과적입니다. SSH 세션을 통해 원격으로 접속한 상태에서 이런 명령어를 실행하면, molly-guard가 중간에 개입해서 "정말로 이 서버를 종료하시겠습니까? 호스트네임을 직접 입력해주세요"라고 묻습니다. 로컬에서 실행한 것이라면 그냥 통과시키지만, SSH 세션이 감지되면 반드시 서버 호스트네임을 확인용으로 타이핑하게 만드는 것입니다. 이 한 단계의 확인 절차만으로도 "잘못된 터미널 탭에서 명령을 실행하는" 사고를 거의 완벽하게 막을 수 있습니다.

기술적으로 보면, molly-guard는 /etc/molly-guard/ 디렉토리에 쉘 스크립트 형태의 체크 루틴들을 배치하고, 위험 명령어 실행 시 이 스크립트들을 순차적으로 실행하는 구조입니다. SSH 접속 여부는 SSH_CONNECTION 환경 변수를 확인하는 방식으로 판단하며, 필요에 따라 커스텀 체크 스크립트를 추가할 수도 있습니다.

더 넓은 맥락: 실수 방지 엔지니어링

Molly Guard는 소프트웨어 엔지니어링에서 말하는 실수 방지(Poka-yoke) 설계의 좋은 사례입니다. 일본 도요타에서 유래한 포카요케는 "실수가 불가능한 구조를 만들자"는 철학인데, IT 인프라에서도 이런 접근이 곳곳에 적용되어 있습니다.

비슷한 맥락의 도구로는 rm 명령어를 가로채서 확인을 요구하는 safe-rm, Git에서 force push를 방지하는 pre-push hook, AWS에서 실수로 리소스를 삭제하지 못하도록 하는 Termination Protection 등이 있습니다. Kubernetes 환경에서는 kubectl 명령어 실행 시 현재 컨텍스트를 프롬프트에 표시하거나, 프로덕션 클러스터에서 위험한 명령 실행 시 추가 확인을 요구하는 kubeconfirm 같은 도구도 같은 계열입니다.

최근에는 인프라 자동화와 IaC(Infrastructure as Code)가 보편화되면서, terraform destroy나 pulumi destroy 같은 명령어도 비슷한 안전장치를 내장하고 있습니다. Terraform은 destroy 실행 시 "yes"를 직접 입력하게 하고, 프로덕션 환경에는 prevent_destroy 라이프사이클 옵션을 걸어두는 것이 모범 사례로 자리잡았죠.

한국 개발자에게 주는 시사점

실무에서 바로 적용할 수 있는 교훈이 있습니다. 첫째, Debian/Ubuntu 기반 서버를 운영한다면 당장 molly-guard를 설치하세요. 패키지 하나 설치하는 데 10초면 충분하고, 이것이 미래의 장애 하나를 막아줄 수 있습니다. 둘째, 더 중요한 것은 이런 "안전장치" 마인드셋을 팀 문화로 가져가는 것입니다. CI/CD 파이프라인에서 프로덕션 배포 전 수동 승인 단계를 넣거나, 데이터베이스 마이그레이션 스크립트에 드라이런 모드를 기본으로 두는 것 모두 같은 철학입니다.

"사람은 반드시 실수한다"는 전제에서 시스템을 설계하면, 개인의 주의력에 의존하지 않는 안전한 운영 환경을 만들 수 있습니다. Molly Guard가 던지는 메시지는 결국 이겁니다. 위험한 행동에는 의도적인 마찰을 추가하라.

여러분의 팀에서는 어떤 실수 방지 장치를 운영하고 계신가요? 프로덕션 환경에서 등골 서늘했던 경험이 있다면 공유해 주세요.