그 빨간 버튼 위 투명 덮개, 이름이 「몰리 가드」였어요

무슨 일이 있었냐면요

혹시 위험한 기계나 비상정지 버튼 위에, 실수로 못 누르게 투명 플라스틱 덮개를 씌워둔 거 본 적 있으세요? 살짝 들어올려야만 누를 수 있는 그 장치 말이에요. 이게 정식 이름이 있는데, 바로 '몰리 가드(Molly Guard)'예요. 이번 글은 이 몰리 가드가 물리 세계뿐 아니라 우리가 만드는 소프트웨어 UI에도 얼마나 다양하게 숨어 있는지를 모아본 흥미로운 이야기예요.

이름이 왜 몰리 가드냐면요

유래가 귀여워요. 옛날 대형 컴퓨터(메인프레임)에는 시스템을 통째로 꺼버리는 '빅 레드 스위치(큰 빨간 버튼)'가 있었거든요. 그런데 한 엔지니어의 어린 딸 몰리가 그 버튼을 눌러서 컴퓨터를 꺼버린 사건이 있었대요. 그래서 다시는 그런 일이 없도록 버튼 위에 덮개를 씌웠고, 그 보호 덮개를 '몰리를 막는 장치', 즉 몰리 가드라고 부르게 된 거예요.

핵심은 이거예요. 정말 중요하고 되돌릴 수 없는 행동은, 한 번 더 손이 가게 만들어서 실수를 막는다. 이 단순한 철학이 디자인의 곳곳에 녹아 있어요.

소프트웨어 속 몰리 가드들

이게 뭐냐면, 우리가 코드 짜면서 매일 쓰는 UI에도 사실 몰리 가드가 잔뜩 들어 있어요. 몇 가지 예를 들어볼게요.

깃허브에서 저장소를 삭제하려고 하면, 그냥 '삭제' 버튼만 누르게 두지 않잖아요? 저장소 이름을 직접 손으로 타이핑해야만 삭제가 되죠. 이게 전형적인 몰리 가드예요. '정말 이거 맞아? 이름까지 칠 정도로 확실해?'라고 한 번 더 묻는 거예요.

또 휴대폰에서 비행기 모드나 중요한 설정을 끌 때 '정말 끄시겠습니까?' 하고 한 번 더 확인하는 팝업, 위험한 명령어를 칠 때 --force 같은 플래그를 일부러 붙이게 만드는 것, AWS 콘솔에서 운영 서버를 종료할 때 보호 장치(termination protection)를 먼저 풀어야 하는 것까지 전부 같은 개념이에요.

포인트는, 이 장치들이 단순히 '한 번 더 클릭'으로 끝나면 사람들은 생각 없이 습관적으로 눌러버린다는 거예요. 그래서 잘 만든 몰리 가드는 사용자가 잠깐 멈춰서 진짜로 생각하게 만드는 약간의 마찰(friction)을 일부러 집어넣어요. 이름을 타이핑하게 하는 게 대표적이죠.

좋은 몰리 가드 vs 짜증나는 몰리 가드

여기서 중요한 균형 감각이 있어요. 모든 버튼에 덮개를 씌우면 사용자는 '확인 피로(confirmation fatigue)'에 빠져요. 매번 뜨는 '정말요?' 팝업을 아무 생각 없이 '예'만 누르게 되는 거죠. 그러면 정작 위험한 순간에도 반사적으로 통과시켜버려서 보호 장치가 무용지물이 돼요.

그래서 좋은 설계는 '되돌릴 수 있느냐'를 기준으로 삼아요. 되돌릴 수 있는 행동(예: 글 임시저장)은 굳이 막지 말고, 차라리 '실행 취소(Undo)' 기능을 주는 게 나아요. 반대로 데이터 영구 삭제처럼 되돌릴 수 없는 행동에만 몰리 가드를 강하게 거는 거죠. 마찰은 아껴 써야 효과가 있다는 얘기예요.

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

우리가 서비스를 만들 때 '에러를 어떻게 처리할까'는 많이 고민하는데, '애초에 사용자가 치명적인 실수를 하지 않게 막는 디자인'은 의외로 소홀히 하기 쉬워요. 몰리 가드라는 개념을 알아두면, 회원 탈퇴·데이터 삭제·결제·배포 같은 위험 지점을 설계할 때 한층 더 신중해질 수 있어요.

특히 운영 도구(어드민)나 인프라 콘솔을 만드는 분들이라면 꼭 챙기세요. 새벽에 졸린 눈으로 운영 DB를 날려본 경험, 한 번쯤 들어보셨죠? 그 비극을 막아주는 게 바로 잘 설계된 몰리 가드예요. UX 용어 하나를 팀과 공유하는 것만으로도 '여기 몰리 가드 하나 달자'는 대화가 가능해지거든요.

마무리

한 줄 정리하면, 되돌릴 수 없는 행동에는 「잠깐 멈춰 생각하게 만드는 마찰」을 의도적으로 넣어라, 이게 몰리 가드의 핵심이에요.

여러분의 서비스엔 어떤 몰리 가드가 있나요? 혹은 '이건 진짜 잘 만들었다' 싶은 확인 장치를 본 적 있다면 댓글로 공유해 주세요!