TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 43 READS

'빨리 배포하라'는 신앙에 대하여 — 속도는 목표가 아니라 결과라는 어느 고참 엔지니어의 반론

'빨리 배포하라'는 신앙에 대하여 — 속도는 목표가 아니라 결과라는 어느 고참 엔지니어의 반론
SOURCE IMAGE · HACKER NEWS
'빨리 배포하라'는 신앙에 대하여 — 속도는 목표가 아니라 결과라는 어느 고참 엔지니어의 반론

"빨리 배포하라, 빨리 실패하라, 빨리 움직여라." 어느 순간부터 소프트웨어 업계에서 속도는 측정 지표가 아니라 도덕적 미덕이 됐어요. 여기에 의문을 제기하면 마치 이단 취급을 받죠. 25년 경력의 스태프 엔지니어가 쓴 에세이 "The Religion of Speed(속도라는 종교)"는 바로 이 지점을 정면으로 파고드는 글인데요. 단순한 "옛날이 좋았지" 류의 푸념이 아니라, 속도 숭배가 어떻게 만들어졌고 무엇을 망가뜨리는지 차분하게 짚고 있어서 소개해요.

저자는 이 종교의 계보를 이렇게 추적해요. 페이스북의 "move fast and break things" 시대가 있었고, 린 스타트업의 만들고-측정하고-배우는 루프가 있었고, 최근에는 몇 초 만에 수천 줄을 만들어내는 AI 코딩 어시스턴트가 등장했죠. 파도가 올 때마다 속도는 더 신성해졌어요. 그 결과 지금 많은 팀이 "얼마나 빨리 배포하는지"는 열심히 측정하면서, 정작 배포한 게 제대로 동작하는지, 유지보수가 가능한지, 애초에 만들었어야 하는 물건인지는 모르는 상태가 됐다는 거예요.

속도는 대리 지표였는데, 목표로 둔갑했어요

원래 개발 속도(velocity)는 '학습 속도'의 대리 지표였어요. 아이디어가 맞는지 얼마나 빨리 검증하느냐를 근사하려던 거죠. 그런데 조직들이 이걸 굿하트의 법칙대로 망가뜨렸어요. 굿하트의 법칙이 뭐냐면, "지표가 목표가 되는 순간 좋은 지표이기를 멈춘다"는 거예요. 스토리 포인트는 부풀려지고, PR은 지표 채우기 좋게 잘게 쪼개지고, '배포됨'의 정의는 "사용자에게 실제로 동작함"이 아니라 "머지됨"으로 슬쩍 바뀌죠.

더 무서운 건 속도의 비용이 속도를 측정하는 시간 단위에서는 보이지 않는다는 점이에요. 재작업, 장애 대응 부담, 신규 입사자 온보딩 시간, 아키텍처 부패 같은 것들은 몇 분기 뒤에야 청구서로 날아오는데, 그때쯤이면 스프린트 회고에서는 이미 승리를 선언한 뒤거든요. 저자는 DORA 연구(구글이 주도한 소프트웨어 전달 성과 연구)도 인용하는데, 핵심은 엘리트 팀이 빠르면서 '동시에' 안정적이라는 결과예요. 문제는 대부분의 조직이 '빠름'만 베끼고, 그 빠름을 가능하게 하는 규율 — 테스트, 리뷰, 관측 가능성 — 은 건너뛴다는 거죠.

AI는 이 불에 기름을 붓고 있어요

이 에세이에서 가장 많이 회자될 문장은 아마 이거예요. "우리는 타이핑을 빠르게 만들었지만, 타이핑은 애초에 병목이 아니었다. 병목은 이해이고, 이해에는 지름길이 없다." 팀들이 자신이 완전히 이해하지 못한 생성 코드를 대량으로 머지하면서, 전례 없는 속도로 '이해 부채(comprehension debt)'를 쌓고 있다는 진단이에요. 기술 부채는 그래도 그 코드를 아는 사람이 어딘가에 있는데, 이해 부채는 그 코드를 아는 사람이 아예 없는 상태라는 점에서 더 고약하죠.

흥미로운 건 저자가 "그러니까 천천히 가자"는 결론으로 가지 않는다는 거예요. 느림을 낭만화하는 것도 명확하게 거부해요. 이 글의 진짜 주장은 이거예요. 속도는 입력이 아니라 출력이다. 좋은 아키텍처, 좋은 테스트, 좋은 도구, 그리고 시스템을 이해하는 사람들이 갖춰지면 빠른 배포는 자연스럽게 따라오는 결과라는 거죠. 그 조건들을 만들지 않고 속도 자체를 쫓는 건, 형식만 흉내 내면 결과가 따라올 거라 믿는 카고 컬트라는 거예요.

마무리로 저자는 "얼마나 빨리 배포하고 있는가?"라는 질문을 두 가지로 바꾸자고 제안해요. "우리가 틀렸다는 걸 얼마나 빨리 알 수 있는가?" 그리고 "마음을 바꾸는 데 비용이 얼마나 드는가?" 이 두 질문이 velocity가 원래 재려던 것을 부작용 없이 전부 담는다는 거죠.

한국 개발 문화에도 시사하는 바가 커요. 스프린트 벨로시티나 배포 횟수를 KPI로 잡는 조직이 많고, 요즘은 AI 도구 도입률 자체가 평가 지표가 되기도 하잖아요. 이 글의 프레임을 빌리면 다음 회고에서 던질 질문이 달라져요. "이번 분기에 우리가 틀렸다는 걸 알아차리는 데 며칠 걸렸나?", "방향을 바꾸는 데 얼마나 아팠나?" 같은 질문이요.

한 줄 정리: 속도를 직접 쫓지 말고, 속도가 자연스럽게 나오는 조건을 만들자. 여러분 팀은 배포 속도와 되돌리는 비용 중 어느 쪽을 측정하고 있나요?


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://graybeard.ing/the-religion-of-speed/
SHARE
처리 중...