원문: https://tidyfirst.substack.com/p/why-accelerate-deployment?utm_source=profile&utm_medium=reader2
더 자주 배포해야 하는 분명한 이유는 경쟁에서 우위를 점하기 위해서입니다. 기능이 중요하고 더 빨리 출시할 수 있는 일대일 경쟁에서 승리해야 합니다. 상대방이 앞서 나가면 빠르게 따라잡을 수 있습니다. 상대가 뒤처지면 따라잡지 못하게 하면 됩니다. OODA 루프에 대한 비유가 떠오릅니다.
하지만 이러한 경쟁의 예를 찾으려고 노력했지만 최근 사례를 찾기가 어려웠습니다. 워드 프로세서가 기능 목록으로 경쟁하던 시대는 이미 오래 전에 지나갔고, 그 결과 기능의 부풀림과 복잡성만 남았습니다. 최근의 한 가지 예로 Bing 대 Google을 들 수 있습니다. 거기에서도 엄격한 기능 경쟁이 아니라 사용자 행동을 경쟁사보다 더 빨리 파악하기 위한 싸움이 벌어지고 있습니다. 한 쪽은 매주, 다른 쪽은 매월 배포할 수 있다면 유리하겠지만, 여전히 사용자를 가장 잘 이해하는 쪽이 승자가 될 것입니다.
오리건 주에서 근무할 때 동료였던 데이비드 마이어(현재 Cisco의 이사)로부터 배운 교훈은 시스템이 복잡해지면 모든 요소가 다른 모든 요소와 잠재적으로 결합된다는 것입니다. 이는 N^2가 너무 커지지 않도록 시스템을 최대한 단순하게 만들고, 한 번에 하나씩 변경하는 것이 좋다는 것을 시사합니다. 변경 사항이 시스템의 모든 부분에 잠재적으로 영향을 미칠 수 있는 경우 한 번에 두 가지 변경 사항을 도입하는 것이 한 가지 변경 사항을 도입하는 것보다 디버깅하기가 훨씬 더 복잡합니다. 문제가 변경 A였나요? 변경 B? A와 B의 어떤 상호작용 때문인가요? 아니면 그냥 우연이었나요? 한 번에 하나의 변경 사항을 도입하면 유지 관리 비용을 줄일 수 있습니다.
동시에 시스템은 빠르게 성장해야 합니다. 많은 변경이 필요하지만 한 번에 하나의 변경만 도입할 수 있습니다. 상충되는 요구 사항을 조정하는 한 가지 방법은 주기 시간을 줄이는 것입니다. 작고 안전한 단계로 시스템을 변경할 수 있지만 그 단계를 매우 빠르게 수행할 수 있다면 외부에서 볼 때 큰 변화를 일으키는 것처럼 보일 수 있습니다.
IMVU의 티모시 피츠는 이 교훈을 깨닫게 해준 이야기를 들려주었습니다. 그들이 얻은 교훈은 "그 변화로 인해 아무것도 망가질 수 없다"고 스스로에게 말하자마자 바로 실행에 옮겼다는 것입니다. 조금이라도 걱정하지 않았다면 왜 그런 말을 하겠습니까? 배포에 따른 오버헤드를 아주 작게 만들어 배포할 때마다 가치를 창출할 수 있었기 때문입니다. 배포가 잘 되었다면 엔지니어는 자신감을 되찾았고, 배포가 실패했다면 엔지니어는 시스템의 민감성에 대해 무언가를 배웠을 것입니다.
도요타 생산 시스템에서 오노 타이이치는 재고를 강의 물과 비유합니다. 강물의 수위를 낮추면(재고를 줄이면) 이전에 숨겨져 있던 바위를 발견할 수 있고(병목 현상을 파악할 수 있습니다). 배포되지 않은 소프트웨어는 재고입니다. 소규모 배치로 배포하면 소프트웨어 프로세스의 병목 현상을 파악할 수 있습니다.
스타트업은 낭비를 제거해야 할 필요가 있습니다. 스타트업의 기반이 되는 많은 가정이 잘못된 것으로 판명될 가능성이 높기 때문에 대부분의 스타트업은 성공하기 위해 반복을 거듭해야 합니다. 팀이 각 반복을 통해 학습하는 법을 배우고 이러한 반복을 짧고 저렴하게 수행할 수 있다면 기업 전체가 전체적으로 성공할 가능성이 높아집니다. 스타트업은 코드와 고객이 없다는 초기 이점이 있기 때문에 빠른 배포 리듬을 확립하는 것이 비교적 쉽지만, 성장하는 동안 이러한 리듬을 유지하는 것은 어려울 수 있습니다.
배포 주기를 단축해야 한다고 생각한 마지막 이유는 바로 모험입니다. 특히 누군가가 불가능하다고 주장하더라도 빠른 리듬을 확립하는 것은 단순히 재미있고 만족스러운 일입니다. 혁신을 추진하는 데 있어 재미의 역할을 과소평가하지 마세요.
배포를 가속화하는 이유는 경쟁에 대응하고(또는 경쟁에서 앞서 나가고), 안전하게 확장하고, 낭비를 파악하고, 재미를 위해서입니다.