---
title: "속도 숭배가 팀을 망치는 방식"
published: 2026-07-30T23:43:22.000Z
canonical: https://jeff.news/article/5302
---
# 속도 숭배가 팀을 망치는 방식

이 글은 ‘빠르게 움직인다’는 말이 실무 판단을 대체하는 조직 문화를 비판한다. 진짜 속도는 맥락과 제약이 정리된 뒤에 나오는 실행력이고, 생각을 건너뛴 움직임은 결국 재작업과 운영 부채로 돌아온다는 주장이다.

- 글의 핵심은 단순함. ‘빠르게 움직임’이 어느 순간 실용적 선택이 아니라 도덕적 우월감처럼 취급되기 시작했다는 것임
  - 빨리 출시하면 야심 있는 팀이고, 조심하면 겁먹은 팀처럼 보이는 분위기
  - 잠깐 멈춰서 생각하자고 하면 추진력을 막는 사람 취급받는 분위기

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

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

- 소프트웨어 업계에서 특히 이 문제가 잘 보이는 이유는 망가진 결과가 눈에 띄기 쉬워서임
  - 하지만 저자는 운영, 관리, 채용, 물류, 고객지원, 제품 개발에서도 같은 일이 반복된다고 말함
  - 이해해야 하는 구간을 뛰어넘고, 나중에 수습에 10배 시간을 쓰는 패턴임

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

- 이런 선택이 쌓이면 조직 전체가 불신받는 시스템이 됨
  - 아무도 믿지 않는 시스템
  - 아무도 이해하지 못하는 프로세스
  - 아무도 원하지 않는 회의
  - 아무도 믿지 않는 대시보드
  - 임시 우회로가 어느새 비즈니스의 하중을 받는 구조

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

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

- 속도는 책임을 흐리게 만들 때 특히 매력적임
  - 결정을 흐릿하게 놔둘 수 있음
  - 디테일에 대한 책임을 나중으로 미룰 수 있음
  - 결국 그 디테일이 누군가의 긴급 상황이 되면, 또다시 답은 “더 빨리”가 됨

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

- 결론은 꽤 개발팀스럽게 들림. 먼저 이해하고, 그다음 결정하고, 그 뒤에 움직이라는 것
  - 순서가 뒤집히면 언젠가 비용 청구서가 옴
  - 그 청구서는 깨진 시스템일 수도 있고, 번아웃된 팀일 수도 있고, 조용히 떠난 고객일 수도 있고, 몇 년짜리 운영 흉터일 수도 있음

- ‘속도 숭배’가 오래 살아남는 이유는 변명으로 쓰기 좋기 때문임
  - 시장이 너무 빠르다, 고객이 너무 급하다, 팀이 너무 작다, 예산이 부족하다, 기회가 닫힌다 같은 말은 가끔 사실임
  - 하지만 종종 그 말들은 움직이기 전에 이해하는 더 어렵고 느린 일을 피하려는 핑계가 됨

## 핵심 포인트

- 속도 자체가 성과의 증거처럼 취급되면서 나쁜 일이 보호받는다고 지적함
- 진짜 속도는 요구사항, 제약, 의사결정이 명확할 때 나온다고 봄
- 이해를 건너뛴 조직은 시스템, 프로세스, 회의, 대시보드, 우회로가 전부 불신받는 상태가 됨
- 느리게 하자는 글이 아니라, 이해하고 결정한 뒤 제대로 움직이자는 주장임

## 인사이트

개발팀에서 ‘일단 빨리’는 꽤 자주 ‘아무도 결정 안 했지만 누군가 해결하겠지’의 다른 말이 됨. 이 글은 기술 깊이보다 조직 운영 쪽 글이지만, 레거시와 번아웃이 어디서 시작되는지 설명하는 데는 꽤 직격이다.