Skip to content
Published on

나를 믿지 말고 시스템을 믿기 — 실수하지 않는 비결

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

들어가며 — 또 깜빡했다

배포 직전이었습니다. 스테이징에서는 멀쩡하던 기능이 프로덕션에서 터졌습니다. 원인은 허무했습니다. 환경 변수 하나를 프로덕션 설정에 넣지 않은 것이었습니다. 분명히 기억하고 있었습니다. "아, 그거 나중에 꼭 넣어야지." 그 "나중에"가 영영 오지 않았을 뿐입니다.

그날 저는 스스로에게 화가 났습니다. "왜 이렇게 덤벙대지? 다음엔 진짜 정신 차리자." 그런데 한 달 뒤, 거의 똑같은 실수를 또 했습니다. 변수만 달랐을 뿐입니다.

처음엔 더 노력하면 된다고 믿었습니다. 포스트잇을 붙이고, 알림을 맞추고, 머릿속으로 몇 번이고 되뇌었습니다. 그런데도 결정적인 순간에 그 항목은 의식에서 미끄러져 나갔습니다. 노력의 양이 부족했던 게 아니라, 노력으로 메우려는 시도 자체가 잘못된 접근이었습니다.

세 번째쯤 되었을 때 저는 중요한 사실을 받아들였습니다. 문제는 제 정신력이 아니었습니다. 문제는 제가 제 기억과 의지를 신뢰하는 시스템 위에서 일하고 있었다는 것이었습니다. 그날 이후 제 좌우명이 하나 생겼습니다.

나를 믿지 말고, 시스템을 믿어라.

이 글은 자책을 멈추고 구조를 바꾸자는 이야기입니다. 추상적인 다짐이 아니라, 실제로 손에 잡히는 체크리스트와 자동화와 루틴에 대한 이야기입니다.

인간의 기억과 의지는 불완전하다

먼저 불편한 진실을 인정하고 시작하겠습니다. 우리의 머리는 믿을 만한 저장장치가 아닙니다.

심리학자 조지 밀러(George Miller)는 1956년 논문 "The Magical Number Seven, Plus or Minus Two"에서, 사람이 한 번에 의식적으로 다룰 수 있는 정보 덩어리가 대략 7개 안팎이라고 정리했습니다. 이후 연구들은 그 숫자를 더 낮춰서, 실제 작업기억의 용량은 4개 정도라고 봅니다. 즉 우리가 동시에 "잊지 말아야지" 하고 붙들 수 있는 항목은 손가락으로 꼽을 정도라는 뜻입니다.

의지력도 마찬가지입니다. 의지력이 한정된 자원처럼 소모된다는 "자아 고갈(ego depletion)" 가설은 최근 재현성 논쟁이 있어 통째로 믿기는 어렵지만, 한 가지는 분명합니다. 피곤하고, 배고프고, 마감에 쫓기고, 동시에 세 가지 일을 저글링하는 상태에서 우리의 판단은 평소만 못합니다. 하필 실수는 바로 그런 순간에 일어납니다.

게다가 우리의 기억은 단지 약한 게 아니라 적극적으로 우리를 속입니다. 분명히 했다고 믿었는데 안 한 일, 안 했다고 믿었는데 두 번 한 일이 생깁니다. 기억은 녹화 영상이 아니라 매번 새로 재구성되는 이야기에 가깝기 때문입니다. "내가 분명 기억하니까 괜찮아"라는 문장이 가장 위험한 이유가 여기 있습니다.

여기서 중요한 전환이 있습니다. 실수를 "나는 왜 이 모양일까"라는 인격의 문제로 보면 해결책은 "더 노력하기"밖에 없습니다. 그런데 더 노력하기는 지속 가능하지 않습니다. 반면 실수를 "내 환경 설계의 문제"로 보면, 해결책은 "환경을 고치기"가 됩니다. 그리고 환경은 한 번 고쳐두면 계속 작동합니다.

체크리스트라는 가장 단순한 혁명

이 주제에서 빼놓을 수 없는 책이 아툴 가완디(Atul Gawande)의 『체크 마니페스토(The Checklist Manifesto)』(2009)입니다. 가완디는 외과의사입니다. 세계에서 가장 훈련을 많이 받은 전문가 집단 중 하나죠. 그런데 그가 발견한 것은, 그렇게 똑똑하고 숙련된 사람들조차 단순한 단계를 빼먹어서 사고를 낸다는 사실이었습니다.

세계보건기구(WHO)와 함께 진행한 연구에서, 수술실에 단 19개 항목짜리 체크리스트를 도입한 것만으로 여러 병원에서 수술 후 합병증과 사망률이 의미 있게 줄었습니다. "환자 이름을 다시 확인했는가", "항생제를 투여했는가" 같은, 너무 당연해서 오히려 빠뜨리기 쉬운 항목들이었습니다.

체크리스트가 강력한 이유는 역설적입니다. 그것이 전문가의 능력을 의심하기 때문입니다. 아무리 베테랑이라도 인간은 빠뜨립니다. 체크리스트는 "당신이 못 미더워서"가 아니라 "인간이 원래 그렇기 때문에" 존재합니다.

항공 산업은 이 교훈을 가장 먼저 받아들였습니다. 조종사는 이륙 전, 착륙 전, 비상 상황에 따라 정해진 체크리스트를 소리 내어 읽고 확인합니다. 수만 시간을 비행한 기장도 예외가 아닙니다. 그들은 자기 기억을 믿지 않습니다. 그래서 안전합니다.

개발에서 이 원리는 그대로 적용됩니다. 배포 체크리스트, 코드 리뷰 체크리스트, 장애 대응 런북 — 전부 같은 철학의 산물입니다.

여기서 한 가지 사례를 들겠습니다. 제가 한때 속했던 팀은 배포할 때마다 누군가 한 명이 "이번엔 뭘 확인해야 하지"를 머릿속으로 떠올리며 진행했습니다. 그 사람의 컨디션이 좋으면 무사했고, 피곤하면 사고가 났습니다. 즉 우리의 안정성은 그날 그 사람의 정신 상태에 달려 있었습니다. 너무 위태로운 구조였습니다.

우리는 그 위태로움을 단 한 장의 문서로 바꿨습니다. 그동안 일어난 배포 사고를 전부 모아, 각각을 "이걸 막았으려면 무엇을 확인했어야 했나"로 번역해 체크 항목으로 적었습니다. 처음엔 일곱 줄이었고, 사고가 날 때마다 한 줄씩 늘었습니다. 그러자 신기한 일이 일어났습니다. 같은 종류의 사고가 두 번 일어나지 않았습니다. 한 번 겪은 실수는 체크리스트에 박제되어, 다시는 우리를 놀라게 하지 못했습니다.

이것이 체크리스트의 두 번째 힘입니다. 그것은 단지 빠뜨림을 막는 도구가 아니라, 조직이 실수로부터 배운 것을 영구히 저장하는 기억 장치입니다. 사람은 떠나고 기억은 흐려지지만, 잘 관리된 체크리스트는 팀이 지금까지 겪은 모든 아픔을 압축해 다음 사람에게 건네줍니다.

배포 전 체크리스트 (예시)
[ ] 마이그레이션 스크립트가 롤백 가능한가
[ ] 환경 변수 신규 항목을 프로덕션에 추가했는가
[ ] 기능 플래그 기본값을 확인했는가
[ ] 모니터링/알람이 배포 후에도 유효한가
[ ] 롤백 절차를 한 줄로 적을 수 있는가

이 다섯 줄이 그날의 저를 구해줬을 겁니다.

나를 믿기보다 시스템을 믿기

"시스템을 믿어라"는 말이 자기 비하처럼 들릴 수 있습니다. 하지만 정확히는 그 반대입니다. 시스템을 믿는 사람은 자기 에너지를 진짜 중요한 곳에 쓸 수 있습니다.

생각해 봅시다. 매번 "배포할 때 뭘 확인해야 하더라"를 머릿속에서 다시 떠올리는 사람은, 그 인지 자원을 매번 같은 곳에 낭비합니다. 반면 체크리스트가 그 일을 대신해 주는 사람은, 같은 에너지를 "이 설계가 6개월 뒤에도 버틸까" 같은 진짜 어려운 문제에 쓸 수 있습니다.

저는 이것을 "결정의 외주화"라고 부릅니다. 한 번 잘 결정해 두면, 그 결정을 매번 다시 내리지 않아도 됩니다.

  • 아침에 무엇을 먹을지 매번 고민하지 않기 위해 정해진 메뉴를 둔다.
  • 커밋 메시지 형식을 매번 고민하지 않기 위해 컨벤션을 정한다.
  • 회의록을 어떻게 남길지 매번 고민하지 않기 위해 템플릿을 둔다.

이렇게 자잘한 결정을 시스템에 넘기면, 머리는 가벼워지고 실수는 줄어듭니다. 자유는 선택지가 많은 상태가 아니라, 중요하지 않은 선택을 하지 않아도 되는 상태입니다.

한 가지 균형은 짚고 가겠습니다. "시스템을 믿어라"가 "생각을 멈춰라"는 뜻은 아닙니다. 시스템은 정상적이고 반복적인 상황을 위한 것입니다. 예외적이고 새로운 상황에서는 여전히 사람의 판단이 필요합니다. 좋은 시스템은 반복되는 90퍼센트를 자동으로 처리해서, 사람이 진짜 어려운 10퍼센트에 집중하게 해 줍니다.

왜 우리는 시스템을 거부하는가

여기까지 읽고 고개를 끄덕이면서도, 막상 체크리스트를 안 쓰는 사람이 많습니다. 저도 한참 그랬습니다. 왜일까요? 몇 가지 심리적 저항이 있습니다.

자존심. "이런 단순한 걸 적어둬야 한다고? 내가 그 정도는 기억하지." 체크리스트를 쓰는 건 내가 못 미덥다는 인정처럼 느껴집니다. 하지만 앞서 봤듯, 세계 최고의 외과의와 조종사가 체크리스트를 씁니다. 시스템을 쓰는 건 약함의 표시가 아니라 프로의 표시입니다.

과신. 우리는 자기 기억력을 실제보다 훨씬 좋게 평가합니다. 심리학에서 말하는 "과신 편향"입니다. "이번엔 안 잊을 것 같다"는 느낌은 거의 항상 틀립니다. 지난 열 번을 잊었으면서도, 우리는 매번 이번만큼은 기억할 거라 믿습니다.

즉각적 비용. 시스템을 만드는 데는 지금 당장 시간이 듭니다. 반면 그 보상은 미래의, 일어나지 않은 실수를 막는 형태로 옵니다. 보이지 않는 보상을 위해 보이는 비용을 치르는 건 인간이 본능적으로 싫어하는 일입니다.

이 저항들을 이기는 방법은 의지가 아니라 경험입니다. 시스템 하나가 실제로 나를 한 번 구해주는 경험을 하면, 그다음부터는 자존심이 아니라 안도감이 시스템을 찾게 됩니다. 그러니 작게 하나만 시작해서, 그 효과를 직접 맛보는 것이 가장 빠른 설득입니다.

흥미롭게도, 시스템에 익숙해진 사람일수록 자기 머리를 덜 믿습니다. 그런데 역설적으로, 그래서 더 자유롭고 더 대담해집니다. 안전벨트를 믿는 운전자가 더 멀리 갈 수 있는 것과 같습니다. 떨어질 걱정을 시스템에 맡긴 사람은, 그 에너지를 더 높이 올라가는 데 씁니다. 자기 기억을 붙들고 전전긍긍하지 않으니, 진짜 어려운 문제와 정면으로 마주할 여유가 생기는 것입니다.

작업기억 비우기 — 머릿속을 외부화하라

데이비드 앨런(David Allen)의 『끝도 없는 일 깔끔하게 해치우기(Getting Things Done)』(2001)에는 이런 통찰이 있습니다. "당신의 머리는 아이디어를 떠올리는 곳이지, 아이디어를 보관하는 곳이 아니다."

머릿속에 "이거 해야 하는데"가 떠다니면, 그 항목은 두 가지 비용을 발생시킵니다. 첫째, 잊어버릴 위험. 둘째, 잊지 않으려고 계속 붙들고 있는 데 드는 인지 부담. 심리학에서 자이가르닉 효과(Zeigarnik effect)라고 부르는, 미완성 과제가 자꾸 의식에 떠오르는 현상이 바로 이 두 번째 비용입니다.

해결책은 단순합니다. 머릿속에 있는 것을 전부 밖으로 꺼내 놓는 것입니다. 신뢰할 수 있는 한 곳에 적어 두면, 뇌는 "이건 저기 안전하게 적혀 있으니 더 이상 붙들고 있지 않아도 돼"라고 안심합니다.

저의 실천 방식은 이렇습니다.

  • 떠오르는 모든 할 일은 5초 안에 한 곳(인박스)에 적는다. 분류는 나중에 한다.
  • 코드를 보다가 "이거 나중에 고쳐야지" 싶으면 즉시 TODO 주석이나 이슈로 남긴다. 머릿속에 두지 않는다.
  • 하루를 마칠 때 머릿속에 남은 것을 전부 비워서 내일 목록에 적는다. 그래야 퇴근 후에 일 생각이 따라오지 않는다.

핵심은 "신뢰할 수 있는 한 곳"입니다. 메모가 여기저기 흩어지면 그 시스템 자체를 믿지 못하게 되고, 결국 다시 머릿속에 의존하게 됩니다. 시스템은 신뢰받을 때만 작동합니다.

자동화 — 사람이 절대 하지 말아야 할 일

체크리스트보다 한 단계 위에 자동화가 있습니다. 체크리스트는 사람이 빠뜨리지 않도록 돕지만, 자동화는 사람이 아예 손대지 않게 합니다. 사람이 손대지 않으면 사람의 실수도 없습니다.

판단 기준은 간단합니다. 반복되고, 규칙이 명확하고, 실수가 치명적인 일은 자동화의 1순위 후보입니다.

  • 코드 포맷팅은 사람이 신경 쓰지 않습니다. 저장 시 자동 포맷터(포매터)가 처리합니다.
  • 린트와 테스트는 사람이 기억해서 돌리지 않습니다. 커밋 훅과 CI가 강제합니다.
  • 배포는 사람이 손으로 명령어를 치지 않습니다. 파이프라인이 같은 절차를 매번 똑같이 실행합니다.

아래는 작은 예시입니다. 커밋 전에 테스트가 통과하지 않으면 아예 커밋을 막는 훅입니다.

#!/bin/sh
# .git/hooks/pre-commit
# 테스트가 실패하면 커밋을 거부한다

npm test --silent
if [ $? -ne 0 ]; then
  echo "테스트 실패. 커밋을 중단합니다."
  exit 1
fi

이런 훅이 있으면, "테스트 돌리는 걸 깜빡했네"라는 문장은 불가능해집니다. 시스템이 그것을 허용하지 않기 때문입니다.

자동화에는 한 가지 미묘한 균형이 있습니다. 자동화한 것은 보이지 않게 되어, 잘 작동하는 동안에는 그 존재조차 잊힙니다. 그러다 어느 날 조용히 고장 나면, 아무도 눈치채지 못한 채 한참을 흘러갈 수 있습니다. 그래서 좋은 자동화에는 "이게 아직 잘 돌고 있는가"를 알려주는 또 다른 장치가 함께 있어야 합니다. 자동화는 만들고 잊는 게 아니라, 만들고 지켜보는 것입니다.

자동화의 진짜 가치는 시간 절약이 아니라 일관성입니다. 사람은 컨디션에 따라 결과가 흔들리지만, 잘 만든 스크립트는 천 번을 실행해도 천 번 같은 결과를 냅니다. 신뢰할 수 있다는 것, 그것이 자동화의 본질입니다.

신뢰의 사다리 — 시스템에는 단계가 있다

지금까지 체크리스트, 외부화, 자동화를 이야기했습니다. 이것들은 사실 같은 사다리의 서로 다른 칸입니다. 실수를 막는 강도가 점점 세지는 순서로 정리해 보면 이렇습니다.

신뢰의 사다리 (아래로 갈수록 실수가 어려워진다)
1단계  기억하기      → 가장 약함. 잊으면 끝.
2단계  메모하기      → 적어두면 잊지 않는다. 단 봐야 한다.
3단계  체크리스트    → 빠뜨리면 눈에 띈다. 단 사람이 읽어야 한다.
4단계  자동 알림     → 시스템이 먼저 알려준다.
5단계  강제 검증     → 조건을 안 맞추면 진행이 막힌다.
6단계  완전 자동화   → 사람이 손댈 일이 아예 없다.

이 사다리가 주는 통찰은 분명합니다. 같은 실수라도, 그것을 막는 시스템의 단계는 고를 수 있다는 것입니다. 사소한 실수라면 메모(2단계)면 충분합니다. 그런데 한 번 일어나면 치명적인 실수라면, 5단계나 6단계까지 올라가야 합니다.

그날의 환경 변수 실수를 다시 봅시다. 저는 "다음엔 기억해야지"(1단계)에 머물렀습니다. 그래서 또 터졌습니다. 만약 "필수 변수가 없으면 배포가 멈춘다"(5단계)로 올렸다면, 그 실수는 다시는 일어날 수 없었을 것입니다.

판단의 핵심은 비용과 위험의 균형입니다. 위로 올라갈수록 막는 힘은 세지지만 만드는 비용도 듭니다. 자주 일어나고 치명적인 실수일수록 높은 칸에, 드물고 사소한 실수는 낮은 칸에 두는 것이 합리적입니다. 모든 것을 6단계로 만들 필요는 없습니다. 그건 과한 프로세스의 함정이니까요.

미적으로 아름답게 — 가까이서도 멀리서도 멋지게

여기서 조금 다른 이야기를 하겠습니다. 시스템은 단지 기능만 하면 되는 게 아니라, 아름다워야 합니다. 이건 취향의 문제가 아니라 실용의 문제입니다.

스티브 잡스가 즐겨 인용한 일화가 있습니다. 그의 아버지는 가구를 만들 때 보이지 않는 뒷면까지 정성껏 마감했다고 합니다. "아무도 안 보는데?"라는 물음에 아버지는 "내가 안다"고 답했다지요. 보이지 않는 부분의 완성도가 결국 전체의 완성도를 만든다는 이야기입니다.

좋은 시스템에는 두 가지 미학이 있습니다.

멀리서 봤을 때의 아름다움 — 전체 구조가 한눈에 들어오는가. 디렉터리 구조, 모듈 경계, 데이터 흐름이 깔끔한가. 처음 보는 사람이 30초 안에 "아, 이렇게 돌아가는구나"를 이해할 수 있는가.

가까이서 봤을 때의 아름다움 — 한 줄 한 줄이 깔끔한가. 변수 이름이 정직한가. 주석이 거짓말을 하지 않는가. 들여쓰기와 줄바꿈이 일관적인가.

왜 이게 실수와 관련이 있을까요? 어수선한 시스템은 실수를 숨깁니다. 잘 정돈된 시스템에서는 이상한 것이 눈에 띕니다. 깨끗한 책상 위에 놓인 얼룩은 바로 보이지만, 어질러진 책상 위에서는 보이지 않는 것과 같습니다. 정돈은 결벽이 아니라, 이상 징후를 빨리 발견하기 위한 안전장치입니다.

[멀리서 본 아름다움]            [가까이서 본 아름다움]
+----------------+             함수 하나가 한 가지 일만 한다
|  명확한 경계    |             이름이 의도를 그대로 말한다
|  단방향 흐름    |   +-->      매직 넘버 대신 상수
|  적은 의존성    |             주석은 "왜"를 설명한다
+----------------+             일관된 포맷

아름답게 정리하는 데 드는 시간은 비용이 아니라 투자입니다. 6개월 뒤의 나, 혹은 옆자리 동료가 그 시스템을 다시 읽을 때 그 투자는 이자까지 붙어 돌아옵니다.

루틴과 템플릿 — 매번 새로 시작하지 않기

시스템의 또 다른 얼굴은 루틴과 템플릿입니다. 루틴은 시간의 시스템이고, 템플릿은 형식의 시스템입니다.

루틴은 "언제 무엇을 할지"를 미리 정해 둡니다. 매일 아침 같은 시간에 코드 리뷰를 본다거나, 금요일 오후에 한 주를 회고한다거나. 정해진 루틴이 있으면 "언제 할까"를 매번 결정하지 않아도 됩니다. 그 결정은 이미 내려져 있습니다.

템플릿은 "어떤 형식으로 할지"를 미리 정해 둡니다.

  • 회의록 템플릿: 안건, 결정 사항, 액션 아이템, 담당자, 기한.
  • 이슈 템플릿: 재현 절차, 기대 동작, 실제 동작, 환경.
  • 회고 템플릿: 잘된 것, 아쉬운 것, 다음에 시도할 것.

템플릿이 있으면 "어떤 항목을 적어야 했더라"를 떠올릴 필요가 없습니다. 빈칸을 채우기만 하면 됩니다. 빠뜨림이 구조적으로 어려워집니다.

저는 글을 쓸 때도 템플릿을 씁니다. 들어가며, 개념, 본론, 함정, 마치며. 백지에서 시작하면 막막하지만, 빈칸이 있으면 채우면 됩니다. 시작의 마찰을 없애는 것, 그것이 템플릿의 숨은 힘입니다.

환경 설계 — 옳은 일을 쉽게, 틀린 일을 어렵게

시스템의 가장 깊은 형태는 "환경 자체를 바꾸는 것"입니다. 의지로 옳은 일을 하게 만드는 대신, 옳은 일을 가장 쉬운 길로 만들어 그쪽으로 자연스럽게 흘러가게 하는 것입니다.

행동경제학자 리처드 세일러와 캐스 선스타인은 『넛지(Nudge)』(2008)에서 이 아이디어를 정리했습니다. 사람은 대개 가장 저항이 적은 경로를 택합니다. 그렇다면 옳은 선택을 가장 저항 없는 경로로 설계하면, 의지를 쓰지 않고도 옳은 선택이 일어납니다.

이것을 실수 방지에 적용하면 두 방향이 됩니다.

옳은 일을 쉽게 만들기. 자주 해야 하는 좋은 행동의 마찰을 없앱니다. 테스트를 자주 돌려야 한다면, 한 글자 명령어나 단축키로 돌아가게 만듭니다. 마찰이 크면 사람은 결국 안 합니다.

틀린 일을 어렵게 만들기. 위험한 행동에는 일부러 마찰을 더합니다. 프로덕션 데이터베이스에 직접 명령을 날리는 일은 한 단계 더 확인을 거치게 합니다. 위험한 길이 너무 매끄러우면 언젠가 미끄러집니다.

환경 설계의 두 방향
옳은 일  →  마찰을 줄인다  →  자연스럽게 자주 한다
틀린 일  →  마찰을 늘린다  →  실수로 하기 어려워진다

핵심 전환은 이것입니다. 실수를 막으려고 "조심하자"고 다짐하는 대신, "이 실수가 일어나기 어려운 환경"을 만드는 것입니다. 의지는 매번 새로 끌어내야 하는 자원이지만, 환경은 한 번 설계하면 매일 자동으로 작동합니다. 의지보다 설계가 언제나 이깁니다.

작은 예를 들어보겠습니다. 자정 넘어 코딩하면 실수가 잦다는 걸 알았다면, "밤에 조심하자"가 아니라 "자정에 자동으로 빌드 서버 접근을 잠그는" 환경을 만드는 게 시스템적 해법입니다. 사람을 믿지 않고, 환경이 대신 지켜주게 하는 것입니다.

이 원리는 일상에도 그대로 옮겨집니다. 야식을 줄이고 싶다면 의지로 참는 대신 집에 과자를 두지 않습니다. 아침에 운동하고 싶다면 전날 밤 운동복을 머리맡에 꺼내 둡니다. 환경이 옳은 선택을 가장 가까운 곳에 놓아주면, 의지는 거의 필요 없어집니다. 우리가 통제할 수 없는 건 미래의 내 의지지만, 통제할 수 있는 건 지금 이 순간의 환경입니다. 그러니 미래의 나를 위해, 지금의 내가 환경을 설계해 두는 것입니다.

과한 프로세스 경계하기 — 시스템의 함정

여기서 반드시 균형을 잡아야 합니다. 시스템은 좋은 것이지만, 시스템이 목적이 되는 순간 독이 됩니다.

흔한 함정들입니다.

프로세스를 위한 프로세스. 아무도 읽지 않는 30단계짜리 체크리스트, 형식만 채우는 회의록, 통과를 위한 통과 의례. 이런 것들은 안전을 주지 않으면서 시간만 잡아먹습니다. 체크리스트는 짧고 진짜 위험한 항목만 담아야 효과가 있습니다. 가완디도 강조했습니다. 좋은 체크리스트는 모든 것을 적는 것이 아니라, 빠뜨리기 쉬운 핵심만 적는 것이라고.

살아 있지 않은 시스템. 현실은 변하는데 문서는 그대로인 경우입니다. 6개월 전 절차서를 그대로 따라 하다가 더 큰 사고가 납니다. 시스템에는 "이게 아직 유효한가"를 점검하는 또 다른 시스템이 필요합니다.

자율성을 죽이는 시스템. 모든 것을 규칙으로 묶으면 사람은 생각을 멈춥니다. 좋은 시스템은 사람을 로봇으로 만들지 않고, 사람이 더 가치 있는 판단에 집중하도록 돕습니다.

판단 기준 하나를 제안합니다. "이 프로세스가 없으면 어떤 실수가 일어나는가?" 이 질문에 구체적으로 답할 수 없다면, 그 프로세스는 아마 없어도 됩니다.

시스템을 만드는 사람이 되자

마지막으로 한 단계 위의 이야기를 하겠습니다. 시스템을 잘 따르는 사람을 넘어, 시스템을 만드는 사람이 되는 것입니다.

같은 실수를 두 번 했다면, 그건 의지의 문제가 아니라 시스템의 부재입니다. 세 번째에는 화를 내는 대신 이렇게 물어야 합니다. "이 실수가 구조적으로 불가능해지려면 무엇을 바꿔야 하지?"

  • 환경 변수를 또 빠뜨렸다면, 빠진 변수가 있으면 배포가 멈추도록 검증을 추가한다.
  • 같은 질문을 동료에게 세 번째 받았다면, 그 답을 문서로 남기고 링크를 보낸다.
  • 매번 같은 설정을 손으로 한다면, 스크립트로 만든다.

이것이 진짜 레버리지입니다. 한 번의 노력으로 미래의 수많은 실수를 막는 것. 좋은 엔지니어와 위대한 엔지니어의 차이는 실수를 안 하는 데 있지 않습니다. 같은 실수가 다시는 일어나지 않도록 시스템을 고치는 데 있습니다.

그리고 이건 개발에만 해당하는 이야기가 아닙니다. 자꾸 약속을 깜빡한다면 캘린더 알림이라는 시스템을, 운동을 미룬다면 정해진 시간이라는 시스템을, 돈을 못 모은다면 자동 이체라는 시스템을 만들면 됩니다. 의지로 버티는 대신, 구조가 대신 버티게 하는 것입니다.

반복 가능한 프로세스 — 한 번의 성공을 영원히 재생하기

한 번 잘한 일을 다음에도 똑같이 잘하려면 어떻게 해야 할까요? 기억에 의존하면 다음엔 흐려집니다. 답은 반복 가능한 프로세스로 만드는 것입니다.

좋은 프로세스는 "운이 좋아서 잘된 일"을 "언제나 잘되는 일"로 바꿉니다. 한 번의 성공을 녹음해 두고, 필요할 때마다 그대로 재생하는 것입니다.

저는 이걸 "성공을 코드화한다"고 표현합니다. 어떤 일이 잘 풀렸을 때, 그 순간 멈춰서 묻습니다. "이게 왜 잘됐지? 다음에도 똑같이 하려면 무엇을 적어둬야 하지?" 그리고 그 답을 절차로 남깁니다.

한 번의 성공을 프로세스로 만드는 과정
1. 잘된 일이 끝난 직후, 기억이 생생할 때 멈춘다
2. "무엇을, 어떤 순서로, 왜" 했는지 적는다
3. 다음에 같은 일이 오면 그 절차를 따라 한다
4. 따라 하다 막히는 곳을 발견하면 절차를 고친다
5. 절차가 충분히 안정되면 자동화를 검토한다

반복 가능한 프로세스의 진짜 힘은 "재현성"입니다. 과학 실험이 신뢰받는 이유가 누구나 같은 절차로 같은 결과를 낼 수 있어서이듯, 좋은 프로세스는 오늘의 내가 한 일을 6개월 뒤의 나도, 처음 합류한 동료도 똑같이 해낼 수 있게 합니다. 개인의 능력에 갇혀 있던 지식이 팀의 자산이 되는 순간입니다.

여기에 한 가지 미묘함이 있습니다. 프로세스는 "발견"되는 것이지 "발명"되는 것이 아닙니다. 책상에 앉아 완벽한 절차를 상상으로 만들려 하면 현실과 어긋납니다. 실제로 일을 하면서, 막히는 지점마다 절차를 조금씩 다듬어 나가는 것이 옳습니다. 프로세스는 살아 있는 문서입니다.

대화 예시 — 자책에서 시스템으로

추상적인 이야기를 구체적인 장면으로 바꿔보겠습니다. 두 가지 대화를 비교해 봅시다.

자책하는 대화

동료: 또 그 변수 빠뜨려서 배포 터졌어요.
나:   아, 죄송해요. 제가 정신을 안 차렸네요.
동료: 다음엔 좀 더 신경 써주세요.
나:   네, 다음엔 진짜 조심하겠습니다.
(한 달 뒤, 같은 일이 반복된다)

이 대화의 결론은 "더 신경 쓰기"입니다. 그런데 신경은 흔들리고, 그래서 한 달 뒤 같은 일이 또 일어납니다. 사과는 진심이었지만, 구조는 하나도 바뀌지 않았습니다.

시스템으로 바꾸는 대화

동료: 또 그 변수 빠뜨려서 배포 터졌어요.
나:   이게 벌써 세 번째네요. 신경 쓰는 걸로는 안 되겠어요.
동료: 그럼 어떻게 하죠?
나:   배포 전에 필수 변수가 다 있는지 검사하는 스크립트를
      파이프라인에 넣을게요. 빠지면 배포가 아예 멈추도록요.
동료: 좋네요. 그럼 사람이 기억할 필요가 없겠어요.
나:   네. 다음부터 이 실수는 구조적으로 불가능해집니다.

두 대화의 차이는 태도가 아니라 결론에 있습니다. 첫 번째는 사람을 고치려 하고, 두 번째는 시스템을 고칩니다. 사람은 또 잊겠지만, 시스템은 잊지 않습니다.

핵심은 화살을 자기 인격이 아니라 환경으로 돌리는 것입니다. "내가 부족해서"가 아니라 "이 실수가 가능한 구조라서"라고 말할 때, 비로소 진짜 해결이 시작됩니다.

실천 — 오늘 당장 할 수 있는 것

이론은 충분합니다. 작게 시작합시다.

  1. 가장 자주 하는 실수 하나를 적는다. 최근 두 번 이상 반복한 것이면 좋습니다.
  2. 그 실수를 막을 한 줄짜리 체크 항목을 만든다. 거창할 필요 없습니다.
  3. 그 항목을 눈에 보이는 곳에 둔다. 머릿속이 아니라 문서, 템플릿, 또는 자동화에.
  4. 일주일 뒤 점검한다. 효과가 있으면 유지하고, 없으면 버립니다.

시스템은 한 번에 완성되지 않습니다. 작은 체크 항목 하나에서 시작해, 실수를 만날 때마다 조금씩 자라납니다. 그 과정 자체가 카이젠입니다.

체크리스트 — 이 글의 시스템 만들기

마지막으로, 이 글의 내용을 그대로 시스템으로 만든 체크리스트를 남깁니다.

나를 믿지 말고 시스템을 믿기 — 자가 점검
[ ] 같은 실수를 두 번 이상 했는가? → 시스템을 의심하라
[ ] 머릿속에 "잊지 말아야지"가 떠다니는가? → 밖으로 적어라
[ ] 반복·규칙적·치명적인 작업을 손으로 하는가? → 자동화하라
[ ] 배포·리뷰·대응에 체크리스트가 있는가?
[ ] 그 체크리스트는 짧고 핵심만 담았는가?
[ ] 시스템 구조가 멀리서도 가까이서도 깔끔한가?
[ ] 회의·이슈·회고에 템플릿이 있는가?
[ ] 프로세스가 목적이 되어버린 곳은 없는가?
[ ] 오래된 문서를 점검하는 또 다른 시스템이 있는가?
[ ] 나는 시스템을 따르는 사람인가, 만드는 사람인가?

기억하세요. 의지는 흔들리고, 기억은 새고, 컨디션은 변합니다. 변하지 않는 것은 잘 만들어 둔 시스템뿐입니다. 그러니 오늘도, 나를 믿지 말고 시스템을 믿읍시다. 그게 결국 가장 나를 아끼는 방법입니다.

마치며 — 나를 아끼는 가장 단단한 방법

이 글은 결국 한 문장으로 줄어듭니다. 실수는 인격의 문제가 아니라 설계의 문제다.

이 관점은 우리를 자유롭게 합니다. 자책은 에너지를 갉아먹지만 아무것도 고치지 못합니다. 반면 설계의 눈으로 실수를 보면, 모든 실수는 개선의 단서가 됩니다. "나는 왜 이럴까"가 "무엇을 바꾸면 이게 안 일어날까"로 바뀌는 순간, 우리는 피해자에서 설계자가 됩니다.

물론 시스템이 만능은 아닙니다. 새로운 상황, 창의가 필요한 문제, 사람 사이의 미묘한 판단 앞에서는 여전히 우리 자신이 나서야 합니다. 시스템의 목적은 우리를 대체하는 게 아니라, 반복되는 짐을 대신 져서 우리가 진짜 중요한 일에 온 힘을 쓰게 하는 것입니다.

그러니 나를 믿지 말라는 말은 사실 나를 아끼라는 말입니다. 흔들리는 의지에 매일 나를 맡기는 대신, 잘 만든 구조에 나를 기대게 하는 것. 그것이 미래의 나에게 줄 수 있는 가장 단단한 선물입니다. 오늘 작은 체크 항목 하나, 작은 자동화 하나를 만들어 두세요. 6개월 뒤의 당신이 분명 고마워할 것입니다.

그리고 한 가지만 더. 완벽한 시스템을 한 번에 만들려 하지 마세요. 시스템도 결국 사람이 만드는 것이라, 처음엔 어설프고 빈틈이 많습니다. 괜찮습니다. 중요한 건 시작하는 것, 그리고 실수를 만날 때마다 한 줄씩 고쳐 나가는 것입니다. 그렇게 시스템은 나와 함께 자라고, 어느새 나보다 훨씬 더 믿음직한 동료가 되어 있을 것입니다.

참고 자료

Discuss on Twitter • View on GitHub