TL;DR — 매일 새벽 데이터를 모아주던 자동화가 어느 날 멈췄어요. 그런데 다행히도 그 자동화는 "조용히 반쪽만 일하는" 대신 "확실하게 죽고 크게 소리치도록" 만들어져 있었습니다. 다음 날 아침, 알림 하나로 바로 알아챘어요. 시스템을 만들 때 성공보다 실패하는 방식을 먼저 설계해야 하는 이유에 대한 이야기입니다.

작은 사업을 혼자 꾸리다 보면, 사람이 매일 반복하기 싫은 일들을 기계에게 넘기게 됩니다. 저한테는 그중 하나가 "매일 새벽에 지표를 긁어모아 한 장짜리 요약으로 만드는 일"이었어요. 자고 일어나면 어제까지의 숫자가 정리돼 있는 거죠. 편했습니다.

그런데 어느 날 아침, 그 요약이 안 와 있었어요.

편의가 함정이 됐던 순간

원인은 허무할 만큼 단순했습니다.

며칠 전에 제가 그 자동화에 새 기능을 하나 얹었어요. 그러면서 설치 단계를 "조금 더 엄격한" 방식으로 바꿨습니다. 더 정확하고, 더 재현 가능한 방식이라고 알려진 명령이었죠. 좋은 선택처럼 보였어요.

문제는, 그 엄격한 방식이 어떤 파일 하나가 반드시 있어야만 동작한다는 점이었습니다. 그리고 그 파일은 제 저장소에 올라가 있지 않았어요. 제 컴퓨터에서 돌릴 때는 있었지만, 새벽에 혼자 돌아가는 무인 환경에는 없었던 거죠.

낮에 제 손으로 돌릴 때는 멀쩡했습니다. 그래서 "잘 된다"고 믿고 넘어갔어요. 진짜 시험대는 아무도 안 보는 새벽 첫 실행이었는데 말이죠. 그날 새벽, 그 명령은 파일이 없다며 즉시 멈췄고, 뒤에 이어질 모든 작업이 통째로 취소됐습니다.

교훈 하나. 더 엄격한 도구는 더 많은 전제를 요구한다. 편의라고 생각하고 바꾼 것이, 사실은 새로운 조건을 조용히 하나 더 건 거였어요.

그런데 살린 건, '잘 죽는 방식'이었습니다

여기까지만 보면 그냥 흔한 실수담입니다. 제가 이 이야기를 굳이 꺼내는 이유는 그다음이에요.

그 자동화는 실패할 때 조용히 넘어가지 않도록 만들어져 있었습니다. 파일이 없으면, 절반이라도 만들어서 슬쩍 내놓는 게 아니라 — 그냥 확실하게 멈추고, 실패했다는 알림을 저한테 쏘도록요.

그래서 다음 날 아침, 저는 알림 하나를 보고 5초 만에 상황을 파악했어요. "아, 새벽 작업이 죽었구나. 원인은 그 설치 단계겠구나." 실제로 그랬고, 고치는 데는 한 줄이면 충분했습니다.

만약 반대였다면 어땠을까요. 이게 진짜 무서운 시나리오예요.

그 자동화가 "똑똑하게" 만들어져서, 데이터를 못 긁어오면 어제 것을 그냥 다시 보여주는 식이었다고 해봅시다. 화면은 멀쩡해 보입니다. 요약도 와 있고요. 저는 아무것도 모른 채, 며칠 동안 어제·그제·그끄제의 똑같은 숫자를 "오늘의 최신 지표"라고 믿고 의사결정을 했을 겁니다. 그게 훨씬 더 큰 사고예요. 멈춘 자동화보다, 멈춘 걸 숨기는 자동화가 위험합니다.

무음 강등은, 거짓말과 같습니다

저는 이걸 "무음 강등"이라고 불러요. 시스템이 원래 하던 일을 못 하게 됐는데, 티 안 나게 한 단계 낮은 상태로 슬그머니 내려앉는 것.

무음 강등은 사용자에게 친절해 보이지만, 사실은 거짓말입니다. "괜찮아요"라고 말하면서 안 괜찮은 상태를 감추는 거니까요. 특히 혼자 일하는 사람에게는 치명적이에요. 저를 대신해 봐줄 동료가 없거든요. 시스템이 스스로 소리쳐주지 않으면, 아무도 안 알려줍니다.

그래서 저는 요즘 뭔가를 자동화할 때 순서를 바꿨습니다. "이게 잘 되면 뭘 하지?"보다 "이게 망가지면 어떻게 알지?"를 먼저 정해요.

  • 실패는 크게. 조용히 넘어가느니 확실히 멈추고 알린다. 반쪽짜리 성공보다 명확한 실패가 낫다.
  • 낡은 걸 새것처럼 내놓지 않는다. 데이터가 오래됐으면, 오래됐다고 화면에 그대로 쓴다. 감추지 않는다.
  • 진짜 시험은 아무도 안 보는 새벽에 온다. 내 손으로 돌려서 잘 되는 건 증명이 아니다. 무인 환경에서 한 번 돌아봐야 진짜다.

살아있는 시스템은, 자기 상처를 말합니다

결국 좋은 시스템은 안 아픈 시스템이 아니에요. 혼자 굴러가는 것들은 언젠가 반드시 어딘가 고장 납니다. 그건 못 막아요.

차이는 고장을 어떻게 말하느냐에서 갈립니다. 아픈 걸 숨기고 멀쩡한 척하는 시스템은, 믿을수록 위험해집니다. 반대로 "나 지금 여기가 고장 났어요"라고 정직하게 소리치는 시스템은, 고장이 나도 신뢰가 유지돼요. 어디가 문제인지 아니까, 고칠 수 있으니까.

그날 새벽에 죽었던 그 자동화는, 다음 날 한 줄 고치고 다시 살아났습니다. 그리고 저는 그게 죽었었다는 사실을 부끄러워하지 않아요. 오히려 제대로 죽어준 게 고마웠습니다. 조용히 반쪽으로 살아있었다면, 며칠 뒤에 훨씬 크게 무너졌을 테니까요.

여러분이 만든 것 중에, 지금 조용히 반쪽만 일하고 있는 게 혹시 있진 않나요? 그게 잘 되고 있다고 어떻게 확신하세요? 망가지면, 여러분은 어떻게 알게 되나요?

저는 요즘 그 질문을 자주 합니다.