존중과 신뢰, DevOps 공학의 학문

Source: DevOps.com

DevOps는 도구를 설치하고 파이프라인을 자동화하며 배포 빈도를 높이는 것 이상에 더 큰 목적을 지속적으로 가지고 있었습니다. 이러한 요소들은 중요합니다. 저는 커리어의 대부분을 조직들이 이러한 것을 원활하게 운영하도록 돕는 데 투자했습니다.

하지만 DevOps의 더 깊은 목적은 복잡한 사회기술 시스템을 통해 가치 흐름을 개선하는 것입니다. 이 시스템은 도구, 플랫폼, 파이프라인, 환경, 테스트, 제어 및 운영을 포함합니다. 또한 사람, 리더십 행동, 의사결정 권한, 책임, 학습, 두려움, 자신감 및 신뢰도 포함됩니다.

기술적 측면은 비교적 눈에 띕니다. 실패한 빌드는 보입니다. 깨진 배포는 보입니다. 프로덕션 인시던트는 보입니다.

인간 측면은 대체로 조용히 실패합니다. 사람들은 입을 닫습니다. 팀은 허가를 기다립니다. 아키텍처는 사적으로 논쟁합니다. 보안팀이 늦게 도착합니다. 운영팀은 방어적입니다. 리더는 더 많은 현황을 요구합니다. 엔지니어들은 안전하게 말할 수 있는 진실과 문제가 되는 진실을 배웁니다.

조직은 계속 운영되고, 대시보드는 여전히 보기 좋게 보일 수 있지만 실제 전달 시스템은 느리고 더 깨지기 쉬워집니다.

존중과 신뢰는 DevOps 대화에 자리 잡아야 할 부분이며, 이들은 자주 부드러운 가치로 취급되어, 이는 많은 조직이 이를 충분히 엔지니어링하지 않는 주요 이유 중 하나입니다. 실제 운영 환경에서는 존중과 신뢰는 시스템 특성과 같이 행동합니다. 이들은 결정이 빠르게 이동하는 방식, 위험이 조기에 드러나는 방식, 팀이 자신의 작업을 얼마나 솔직하게 점검하는지, 사람들이 약한 가정을 도전하는 안전성, 그리고 책임을 회피하기 위해 소모되는 노력을 모두 영향을 미칩니다.

존중과 신뢰가 건강할 때 DevOps 실천은 자유롭게 작동합니다. 그들이 악화되면 DevOps 실천은 의례가 됩니다. 파이프라인은 여전히 존재하고, 백로그는 정리될 수 있으며, 인시던트 리뷰도 일정대로 잡힐 수 있습니다. 신뢰의 흐름은 이미 손상되었습니다.

저는 초기 제조 기업에서 엔지니어링 부사장으로 입사하면서 이 교훈을 실질적인 방식으로 배웠습니다. 저는 톰이라고 부르겠습니다. 톰을 통해 보고받던 다섯 개의 제품 엔지니어링 팀을 이끌도록 고용되었습니다. 시작부터 이상한 느낌이 들었습니다. 회사는 이미 톰이 통제하고 있던 동일한 팀들을 이끌라고 원했습니다. 저는 회사가 성장 계획과 톰을 위한 다른 계획을 가지고 있다고 들었습니다. 이는 타당해 보였지만 실제 운영 상황은 여전히 명확하지 않았습니다.

인터뷰에서는 대부분의 임원들이 리더십, 조직, 전달 및 성장 관련 통찰력 있는 질문을 던졌습니다. 톰의 질문은 달랐습니다. 그는 대부분 기술 세부 사항에 집중했으며, 이는 제가 수행하게 될 고위 리더십 역할에 부적절하게 느껴졌습니다. 나중에 엔지니어링 매니저와 주력 엔지니어와 대화하면서 동일한 패턴을 확인했습니다. 그들은 제 기술적 의견을 시험하는 데 더 관심이 있었으며, 제가 어떻게 리드하고 방향을 제시하며 매니저를 개발하고 전달을 개선할지를 이해하려 하지 않았습니다.

이것은 공학 조직이 엔지니어링 리더십보다 기술적 통제를 더 존중하도록 배웠다는 것을 의미했습니다. 리더십은 부드럽고 허무한 것으로 여겨지고, 실제 기술 결정 작업에 둘러싼 따뜻한 포장물로 인식되었습니다. 그러나 성과 증거는 그 믿음을 지지하지 않았습니다. 많은 흥미로운 엔지니어링 작업이 진행 중이었지만 제품은 일정에 맞추어 생산에 도달하지 못했고 품질 목표도 놓치고 있었습니다.

제가 입사한 후에 더 깊은 문제가 명명되었습니다. 다섯 개의 제품 팀은 소규모 결정을 톰에게 많이 의존하게 되었습니다. 사람들은 톰을 기다렸습니다. 톰이 작업을 검토할 때 종종 수정이 요구되었습니다. 몇 가지 변화는 유용했을 수 있습니다. 많은 변화들은 톰의 승낙 없이 진행하면 위험이 따른다는 더 큰 패턴의 일부가 되었습니다. 시간이 지나면서 그의 비판은 두려움을 만들었습니다. 엔지니어들은 톰의 방향이 잘못되었거나 과도하게 설계된 경우에도 의견을 말하지 않았습니다. 그들은 존경받지 않는다고 느꼈고, 그의 결정을 신뢰하지 않았습니다.

이와 같은 상태를 저는 현재 Human Debt이라고 부릅니다. Technical Debt는 엔지니어링 조직에 익숙한 개념입니다. 기술적 단축, 설계 지연, 약한 테스트, 취약한 아키텍처, 유지보수 소홀은 시스템을 변경하기 어렵게 만들어 Human Debt가 축적되는 원인입니다. Human Debt는 해결되지 않은 신뢰 위반과 문화적 단축이 Menschen을 참여시키기 어렵게 만들 때 축적됩니다. 이는 주저함, 침묵, 위험 회피, 수동적인 준수 및 소유감 상실로 나타납니다.

Human Debt와 Technical Debt는 종종 함께 성장합니다. 이 조직에서는 지연된 결정과 과도한 통제가 재작업을 초래했고, 두려움이 개방성을 감소시켰으며, 신뢰 부족이 엣지에서 판단을 늦췄습니다. 엔지니어들은 전문성을 발휘하기보다 승인을 기다렸습니다. 인간 시스템이 복잡해지면서 기술적 결정도 더 복잡해졌습니다. 배송 실패는 일정 미달과 품질 문제로 나타났고, 더 깊은 실패는 낮은 존중과 낮은 신뢰였습니다.

제가 입사한 후 톰은 한 명만 있는 연구 역할로 전보되었습니다. 제 주요 책임은 조직의 전달 능력을 복구하는 것이었습니다. 저는 다섯 개의 팀을 실제 결과에 대한 책임이 있는 제품 팀으로 다루어 이를 달성했습니다. 팀들은 명확한 목표, 의사결정 권한, 그리고 자신의 판단을 사용하도록 신뢰를 필요로 했습니다. 제 역할은 방향을 제시하고 장애물을 제거하며 자원을 제공하고 성취를 인정하는 것이었습니다. 모든 기술 세부 사항에 개입하는 것을 피했습니다.那是 다른 사람이 자리를 차지하면서 동일한 병목을 재구성할 것이기 때문입니다.

이 변화는 인내가 필요했습니다. 기다림에 익숙해진 사람들은 새로운 리더가 권한을 주었다고 해서 즉시 자율적으로 변하지 않습니다. 그들은 새로운 시스템을 테스트하고, 누군가가 반대했을 때 일어나는 일을 관찰하며, 리더가 실수를 벌벌하게 하는지 아니면 배우는지를 주시합니다. 또한 존중이 진정으로 존재하는지, 단지 관리 용어의 일부인지를 듣습니다.

저는 매니저와 엔지니어가 의견을 말하고 가정을 의심하며 가능한 한 단순화하고 자신의 책임 영역 내에서 결정을 내리게 격려했습니다. 저는 성취를 중심으로 목표와 보상을 설정했고, 엔지니어링 리더십은 모든 기술 세부 사항에 가장 강한 의견을 갖는 행위가 아니라는 점을 명확히 했습니다. 리더십은 역량 있는 사람들이 최선을 다할 수 있도록 환경을 조성하는 작업입니다.

1년 이내에 조직은 잘 수행되었습니다. 다섯 개의 제품 팀 모두 새로운 제품을 배송했고, 전달과 품질이 개선되었으며, Human Debt가 감소했습니다. 사람들은 다시 존경받는 느낌을 받아 Human Debt가 줄었고, 기술 부채도 팀들이 무한히 승인에 대한 재작업 없이 책임감 있는 엔지니어링 결정을 내릴 수 있게 되면서 감소했습니다. 결과는 명확한 목표, 자율성, 피드백, 책임감, 그리고 인정을 통해서 나왔습니다.

그 경험은 저의 DevOps에 대한 생각을 형성했습니다. 가시적인 전달 시스템과 인간 전달 시스템은 분리될 수 없습니다. DevOps 가치 스트림은 시스템을 충분히 신뢰하여 현실을 드러내거나, 시스템으로부터 보호하기 위해 숨김으로써 이를 수행하는 사람들에 의해 전달됩니다. 파이프라인은 아티팩트의 이동을 자동화할 수 있지만, 두려움을 보완할 수는 없습니다.

존중은 이 인간 건축의 기반이며, 스트레스 하에서도 사람들을 정렬하는 구조적 무결성을 제공합니다. 존중은 검토 방식, 갈등 처리, 결정 설명, 그리고 작업에 가장 가까운 사람들에게 대한 대우에서 보입니다. 존경받는 엔지니어링 조직은 여전히 어려운 대화를 나눕니다. 여전히 약한 설계를 배격하고, 잘못된 가정을 수정하며 품질을 insiste합니다. 차이점은 수정이 개인적 경시로 느껴지는 것이 아니라 공유 책임의 일부로 인식된다는 것입니다.

신뢰는 컨트롤 플레인으로 작용하여 결정 흐름, 위험 수용 방식, 그리고 조건이 변할 때 팀이 적응하는 방식을 형성합니다. 저신뢰 조직에서는 통제가 증가하고 승인이 늘어납니다. Ticketing