DevOps 문화권 살펴보기

• 7분

DevOps는 성공을 위해 성장과 지속적인 학습 태도가 필요하므로 문화권은 DevOps의 필수 요소입니다. 리더십 지원은 성공의 핵심 요소 중 하나입니다.

DevOps 문화권이 어떤 것인지 알아보기 전에 DevOps를 채택하는 조직의 기능에서 문화권의 역할을 살펴보겠습니다. Gartner에 따르면

문화적 저항 및 낮은 수준의 프로세스 분야는 DevOps 이니셔티브 달성에 상당수 실패합니다.

Phoenix Project and DevOps Handbook의 저자 Gene Kim은 다음과 같이 말합니다.

DevOps는 도전 과제가 가득한 여정이며, 단순히 잘못된 기술 또는 잘못된 프로세스로 인해 문제가 발생하는 경우는 거의 없습니다. 사실, 가장 어려운 장애물은 문화적 문제인 경우가 많습니다. 그리고 문화권이 잘못되는 경우 다른 모든 항목이 옳아도 불만, 추가 비용 및 오류가 발생할 수 있습니다.

문화권이란 무엇인가요?

Microsoft의 목적에서 문화권이란 집단의 사회적 유산입니다. 집단 구성원 간의 상호 작용과 구성원 및 환경 간의 상호 작용에서 발생하는 문제를 처리한 역사 속에서 발견하고, 개발하고, 발명한 응답의 패턴입니다.

문화권은 다음을 결정합니다.

• 허용되는 것과 허용되지 않는 것을 정합니다.
• 중요한 것과 중요하지 않은 것을 정합니다.
• 올바른 것과 잘못된 것을 정합니다.
• 실행 가능한 것과 실행 불가능한 것을 정합니다.
• 고용하고 해고하고 승진시킬 사람을 정합니다.

DevOps 이니셔티브가 실패하는 이유는 무엇일까요?

Gartner 연구에 따르면 2023년까지 DevOps 이니셔티브의 90%가 리더십이 사용하는 관리 접근 방식의 제한으로 인해 실패할 것으로 예상됩니다.

“휴게실에 맥주”를 둔다고 창의적으로 일하는 사람에게 동기를 부여할 수 있는 것이 아닙니다. 창의적인 사람들에게 동기를 부여하기 위해서는 전문성, 자율성, 목적성이 필요합니다.

Microsoft의 성공에서 가장 중요한 부분이 무엇인지 물어보는 질문에 대한 대답이 비전, 전략, 실행일까요? Microsoft CEO인 Satya Nadella는 이 세 가지 모두 중요하지만 결국 목적과 성장을 지향하는 마음가짐이라고 대답했습니다.

DevOps 마음가짐의 12가지 예

다음은 DevOps 마음가짐의 12가지 예입니다. 리더십 마음가짐, 고객 중심, 간결한 사고방식, 시스템적 사고, 낭비 제거, 제약 조건 이론, 맞춤 및 자율성, 시프트 레프트 테스팅, 보안 마음가짐, 가설 기반 개발, 라이브 사이트, 활동이 아닌 결과를 측정하는 마음가짐입니다.

리더십 마음가짐

Gartner는 다음과 같은 사항을 권장합니다.

• 기술적인 역량보다는 DevOps 이니셔티브를 진행하는 데 필요한 특정 동작 특성에 우선 순위를 두고 혁신적인 리더를 파악합니다.
• 실패를 학습 기회로 수용하여 혁신적인 리더를 성장시킵니다.
• 리더가 결과론적인 비판을 받지 않고 결정을 내릴 수 있게 하고 명확한 목표 및 주요 메트릭을 제공하여 혁신적인 리더를 관리합니다.

DevOps는 혁신이므로 인프라 및 운영(I&O) 리더는 비전이 있고 적응력이 뛰어나며 동기와 역량을 갖추고 책임감이 있는 후보자를 파악해야 합니다.

고객 중심 마음가짐

고객 중심이란 무엇을 의미할까요?

• 고객의 소리를 듣고 고객과 커뮤니케이션
• 무엇이 중요한지 측정
• 프로덕션에서의 마이너스 지표 수용
• 빌드, 측정, 학습
• 정상적인 배포를 위해 기능 전환 사용
• 광범위하지만 신중한 데이터 수집

간결한 사고방식

가치: 간결한 사고방식은 고객이 제품 및 서비스에 부여하는 가치를 상세히 이해하는 데서 시작합니다. 조직은 최고 수준의 수익성에서 고객이 기대하는 가치를 제공할 수 있도록 낭비를 제거하는 데 주력합니다.

가치 스트림은 원재료에서 고객의 제품 사용, 최종적인 폐기에 이르기까지 제품의 전체 수명 주기를 포함합니다. 간결성의 최종 목표인 낭비 제거를 위해 가치 스트림을 정확하고 완벽하게 이해해야 합니다.

흐름: 흐름을 이해하는 것은 낭비 제거에 필수적입니다. 언제든지 가치 스트림이 멈추면 낭비가 필연적으로 뒤따릅니다. 간결한 흐름의 제조 원칙은 프로덕션 프로세스의 중단 없이 가치 체인을 만들고 각 작업이 다른 작업과 서로 조화를 이루게 합니다.

풀: 간결한 풀의 원칙을 통해 예정보다 빠르게 생산되는 것이 없도록 함으로써 흐름을 보장할 수 있습니다. 예정보다 빨리 생산하면 생산 중인 제품의 인벤토리를 증가시키고 동기화된 흐름이 중단됩니다. 예측 및 일정을 기반으로 작업을 진행하는 기존의 미국식 제조 방식을 사용하는 대신, 풀 접근 방식은 고객이 주문할 때까지 아무것도 수행하지 않도록 합니다.

완벽: 간결한 실무자는 완벽하기 위해 노력합니다. 완벽한 프로세스를 향해 계속 나아가려면 지속적인 개선을 통해 품질 문제 및 프로덕션 낭비의 근본 원인을 해결해야 합니다. 완벽함에 대한 끊임없는 추구는 경쟁자보다 해당 접근 방식의 사용자가 더 심층적으로 분석하고, 더 많은 것을 측정하고, 더 자주 변경하게 하는 원동력입니다.

시스템적 사고 마음가짐

시스템적 사고 마음가짐은 특정 업무 또는 부서 사일로의 성과가 아닌 전체 시스템의 성능을 강조합니다.

IT에서 지원하는 모든 비즈니스 가치 스트림에 집중합니다. 즉, 비즈니스 또는 IT에서 요구 사항을 파악하고, 요구 사항이 개발 과정에서 구현되고, IT 작업으로 전환되어 해당 가치가 고객에게 서비스로 전달될 때 가치 스트림이 시작됩니다.

낭비 제거 마음가짐

간결한 마음가짐은 고객에게 가치가 없는 7가지의 치명적인 낭비를 파악하고 제거하는 데 중점을 둡니다.

• 부분적으로 완료된 작업
• 추가 프로세스
• 추가 기능
• 작업 전환
• 대기 중
• 동작
• 결함

제약 조건 이론 고려

제약 조건 이론은 처리량을 제한하는 제약 조건(또는 병목 상태)을 파악하고 제거하는 방법론입니다. 실제로 목표 달성을 방해하는 가장 중요한 요소를 확인하는 것부터 시작합니다. 더 이상 제한되지 않을 때까지 해당 요소를 최소화하기 위해 노력합니다.

맞춤 및 자율성의 균형을 이루는 마음가짐

맞춤과 자율성 간에 균형을 유지해야 합니다. 너무 맞추려고만 하면 혁신이 줄어들고, 동기 부여 및 협업 감소로 이어집니다. 자율성을 지나치게 강조하면 과도한 혼란, 혼동 및 충돌로 이어지며 동시에 일관성이 떨어집니다.

시프트 레프트 테스팅 마음가짐

시프트 레프트 테스팅은 테스트 프로세스를 개발 주기 초기 지점으로 옮겨 소프트웨어 테스트 속도를 높이고 개발을 지원하기 위해 사용되는 접근 방식입니다. 시프트 레프트란 타임라인에서 테스트를 왼쪽으로 옮긴다는 의미입니다. 시프트 레프트 테스팅은 품질을 높이고 이슈를 초기에 파악하여 재작업 낭비를 줄이는 데 도움이 됩니다.

시프트 레프트 테스팅은 개발 주기 후반까지 대기하는 기존 테스트 모델이 개발 병목 상태를 유발할 수 있으므로 이를 방지하고 개발 속도를 높이기 위한 더 나은 모델로 고안되었습니다.

보안 마음가짐

보안 마음가짐을 지니려면 팀은 다음을 수행해야 합니다.

• 인식을 높입니다.
• 원칙을 정의합니다.
• 원칙을 따릅니다.

가설 기반 개발 마음가짐

간결한 제품 접근 방식을 사용하여 더 짧은 주기로 개발하고, 가설 기반 개발을 통해 고객에게 피드백을 받고 데이터를 기반으로 결정을 내리는 작은 실험을 만들 수 있습니다.

가설 기반 개발 접근 방식은 다음과 같습니다.

• 근거 없이 사실로 받아들여진 것에 대한 가정에서 시작합니다.
• 테스트할 가정을 명확히 합니다.
• 실험 및 테스트를 수행합니다.
• 결과의 지표인 증거를 검토합니다.

라이브 사이트 마음가짐

DevOps 팀의 경우, 프로덕션 같은 장소가 없습니다. DevOps 팀의 모든 일은 고객의 경험을 개선하는 것입니다.

안정적인 고성능 사이트를 만들려면 지속적인 운영 모범 사례를 규칙적이고 지속적인 방식으로 적용하여 사이트 상태를 유지해야 합니다.

라이브 사이트 문화권의 핵심 요소는 다음과 같습니다.

• 고객이 불만을 느끼기 전에 탐지
• 데이터 기반
• 근본 원인을 핵심으로 삼음
• 코드로 구성
• 유지하기 위해 자동화
• 열린 사고방식 및 학습

활동이 아닌 결과를 측정하는 마음가짐

사람을 측정하는 방식은 사람의 행동 방식을 바꿉니다. 코드 줄, 팀 번다운(burndown), 발견된 버그 수가 아닌 사용량, 개발속도, 라이브 사이트 상태를 측정해야 합니다.