속도 숭배가 팀을 망치는 방식

글의 핵심은 단순함. ‘빠르게 움직임’이 어느 순간 실용적 선택이 아니라 도덕적 우월감처럼 취급되기 시작했다는 것임

• 빨리 출시하면 야심 있는 팀이고, 조심하면 겁먹은 팀처럼 보이는 분위기
• 잠깐 멈춰서 생각하자고 하면 추진력을 막는 사람 취급받는 분위기

저자는 이런 문화가 나쁜 일을 보호한다고 봄

• 결과물이 좋아서가 아니라, 그냥 빠르다는 이유로 정당화됨
• 속도는 판단의 훈련 없이도 “우리가 뭔가 하고 있다”는 느낌을 주는 일종의 조직적 마약처럼 작동함

진짜 속도와 가짜 속도를 구분해야 한다는 게 중요한 포인트임

• 진짜 속도는 일이 이해됐고, 제약이 명확하고, 참여자가 뭘 하는지 알고, 의사결정이 깨끗하게 끝났을 때 나옴
• 가짜 속도는 애매한 요구사항, 반쯤 정한 결정, 확인 안 된 의존성, 빠진 맥락 위에서 굴러감

소프트웨어 업계에서 특히 이 문제가 잘 보이는 이유는 망가진 결과가 눈에 띄기 쉬워서임

• 하지만 저자는 운영, 관리, 채용, 물류, 고객지원, 제품 개발에서도 같은 일이 반복된다고 말함
• 이해해야 하는 구간을 뛰어넘고, 나중에 수습에 10배 시간을 쓰는 패턴임

조직은 그 수습 비용을 이상한 이름으로 포장함

• 처음 급하게 한 일은 ‘빠른 실행’으로 기록됨
• 뒤처리는 ‘예상 못 한 문제’가 되고, 재작업은 ‘반복 개선’이 되고, 혼란은 ‘정렬’이 됨
• 예방 가능했던 실패는 ‘학습’이라는 이름을 달고 넘어감. 아, 너무 익숙함

이런 선택이 쌓이면 조직 전체가 불신받는 시스템이 됨

• 아무도 믿지 않는 시스템
• 아무도 이해하지 못하는 프로세스
• 아무도 원하지 않는 회의
• 아무도 믿지 않는 대시보드
• 임시 우회로가 어느새 비즈니스의 하중을 받는 구조

저자가 말하는 ‘천천히 하자’는 게 일을 질질 끌자는 뜻은 아님

• 6개월 동안 배포 인프라를 직접 만들면서 깊은 척하자는 얘기도 아님
• 핵심은 일을 읽을 수 있는 상태로 만드는 단계를 건너뛰지 말자는 것임

그래서 던져야 하는 질문들이 있음

• 우리가 실제로 만들려는 게 뭔가
• 누가 여기에 의존하나
• 이 가정이 틀리면 뭐가 깨지나
• 이미 아는 건 뭔가
• 모르는 척하는 건 뭔가
• 예전에 어디서 실패했나
• 이게 성공하려면 무엇이 참이어야 하나

속도는 책임을 흐리게 만들 때 특히 매력적임

• 결정을 흐릿하게 놔둘 수 있음
• 디테일에 대한 책임을 나중으로 미룰 수 있음
• 결국 그 디테일이 누군가의 긴급 상황이 되면, 또다시 답은 “더 빨리”가 됨

글은 urgency와 haste를 나눔

• urgency는 시간이 실제로 중요하고, 일이 정말 중요할 때의 긴급함임
• haste는 명확함의 부담 없이 행동했다는 안도감을 얻고 싶을 때 나오는 성급함임

결론은 꽤 개발팀스럽게 들림. 먼저 이해하고, 그다음 결정하고, 그 뒤에 움직이라는 것

• 순서가 뒤집히면 언젠가 비용 청구서가 옴
• 그 청구서는 깨진 시스템일 수도 있고, 번아웃된 팀일 수도 있고, 조용히 떠난 고객일 수도 있고, 몇 년짜리 운영 흉터일 수도 있음

‘속도 숭배’가 오래 살아남는 이유는 변명으로 쓰기 좋기 때문임

• 시장이 너무 빠르다, 고객이 너무 급하다, 팀이 너무 작다, 예산이 부족하다, 기회가 닫힌다 같은 말은 가끔 사실임
• 하지만 종종 그 말들은 움직이기 전에 이해하는 더 어렵고 느린 일을 피하려는 핑계가 됨