DevOps 문화란 무엇입니까?
DevOps 문화가 사용자, 프로세스 및 도구를 더 고객의 통합된 초점에 정렬할 수 있게 하는 방법입니다.
Tom Hall
DevOps 애드보케이트 및 실행자
DevOps는 조직 변화에 대한 민첩한 접근 방식으로, 전통적으로 사일로화된 팀 간에 연결하고 공동 작업을 촉진하는 새로운 프로세스를 구축하려고 합니다. DevOps는 새로운 도구와 애자일 엔지니어링 관행을 통해 가능하지만, 이것만으로는 DevOps의 이점을 얻기에 부족합니다. 올바른 사고 방식, 관행 및 문화가 없다면 DevOps의 모든 약속을 실현하기 어렵습니다.
성공적인 DevOps 구현의 가장 중요한 요소는 사용자와 문화입니다.
- Atlassian 2020년 DevOps 트렌드 설문조사
DevOps 문화란 무엇입니까?
본질적으로 DevOps 문화에는 개발 및 유지 관리하는 제품에 대한 개발 및 운영 팀 간의 긴밀한 공동 작업과 공동 책임이 포함됩니다. 이것은 회사에서 사용자, 프로세스 및 도구를 고객의 더 통합된 초점에 정렬할수 있게 합니다.
여기에는 제품의 전체 수명 주기에 대한 책임을 지는 여러 분야 팀을 양성하는 것이 포함됩니다. DevOps 팀은 자율적으로 일하며 운영 요구 사항의 중요성을 아키텍처, 설계 및 개발과 동일한 수준으로 높이는 소프트웨어 엔지니어링 문화, 워크플로 및 도구 집합을 수용합니다. 개발자가 직접 구축하고 실행하면 개발자가 사용자 요구 사항을 더 잘 이해하여 사용자에게 더 가까이 다가갈 수 있습니다. 운영 팀이 개발 프로세스에 더 많이 관여하면 더 나은 제품에 대한 유지 관리 요구 사항과 고객 요구 사항을 추가할 수 있습니다.
DevOps 문화의 중심에는 전통적으로 사일로에서 일했던 팀 간의 향상된 투명성, 커뮤니케이션 및 공동 작업이 있습니다. 그러나 이 팀들이 더 가까워지려면 중요한 문화적 변화가 일어나야 합니다. DevOps는 특히 팀 자율성, 빠른 피드백, 높은 공감과 신뢰, 팀 간 공동 작업을 통해 지속적인 학습과 지속적인 개선을 강조하는 조직적인 문화의 변화입니다.
관련 자료
고객 우선의 사고 방식 수용
관련 자료
DevOps의 이점 알아보기
DevOps에는 공동 책임이 수반됩니다. 개발 및 운영 담당자 모두 제품의 성공 또는 실패에 대한 책임을 져야 합니다. 개발자는 단순히 구축하여 운영 팀에 인계 이상의 일을 해야 하며, "직접 구축하고 직접 운영"한다는 의식을 가지고 제품 수명 주기 전반에서 제품을 감독하는 책임을 공동으로 져야 합니다. 소프트웨어를 테스트 및 운영하고 QA 및 IT 운영 팀과 더 많이 공동 작업합니다. 개발자는 운영 팀이 겪는 어려움을 이해하면 배포 및 유지 관리를 간소화할 가능성이 높아집니다. 마찬가지로, 운영 팀이 시스템의 비즈니스 목표를 이해하면 개발자와 협력하여 시스템의 운영 요구 사항을 정의하고 자동화 도구를 채택할 수 있습니다.
DevOps의 또다른 중요한 측면은 자율적인 팀입니다. 개발 및 운영 팀이 효과적으로 공동 작업하려면 번거롭고 긴 승인 프로세스 없이 의사 결정을 내리고 변경 사항을 구현해야 합니다. 여기에는 팀에 신뢰를 주고 실패에 대한 두려움이 없는 환경을 만드는 것이 포함됩니다. 이런 팀은 고객에게 가해지는 각 위험 수준에 대해 더 쉽고 빠르게 의사 결정을 내릴 수 있는 올바른 프로세스와 도구를 갖추고 있어야 합니다.
예를 들어 일반적인 개발 워크플로에서는 코드 변경 사항을 배포하기 위해 여러 팀의 여러 기여자가 참여해야 할 수 있습니다. 개발자는 코드를 변경하여 소스 제어 리포지토리로 푸시하고, 빌드 엔지니어는 코드를 만들어 테스트 환경에 배포하고, 제품 소유자는 이슈 추적 도구에서 작업 상태를 업데이트합니다. 자율적인 팀은 이 프로세스를 자동화하는 도구를 활용하므로 새 코드를 푸시하면 테스트 환경에 새 기능을 만들고 배포할 수 있으며 이슈 추적 도구는 자동으로 업데이트됩니다.
예를 들어, 한 팀이 새로운 DNS 엔트리와 같이 사소한 인프라 변경을 위해 별도의 운영 팀을 통해 티켓을 열어야 하는 등의 요구 사항으로 인해 어려움을 겪습니다. 몇 초 만에 완료할 수 있는 작업에 며칠 또는 몇 주가 소요됩니다. 자율적인 팀은 알맞은 스킬과 경험을 가진 담당자를 팀에 두거나 셀프 서비스 도구에 액세스하여 변경 사항을 직접 구현할 수 있습니다.
DevOps 팀 문화는 통합된 개발 및 운영 팀의 지속적인 개선에 도움이 되는 빠른 피드백을 중요하게 생각합니다. 개발 및 운영 팀이 단절된 사일로에 있는 환경에서는 프로덕션 환경에서 애플리케이션 소프트웨어의 성능 및 안정성에 대한 피드백이 개발 팀에 전달되는 속도가 느리거나 아예 전달되지 못할 수도 있습니다. DevOps는 애플리케이션 모니터링 및 보고 전략을 설계하고 구현하는 데 필요한 운영 담당자 간의 공동 작업을 요구하여 개발자가 애플리케이션 코드를 빠르게 반복하고 개선하는 데 필요한 피드백을 신속하게 얻도록 지원합니다. 예를 들어, 충분한 기능을 갖춘 지속적 통합 도구를 사용하면 새로운 코드 푸시를 자동으로 빌드하고 테스트할 수 있으며 코드 품질에 대한 즉각적인 피드백을 개발자에게 제공할 수 있습니다.
자동화는 뛰어난 공동 작업을 가능하게 하고 리소스를 확보해 주므로 DevOps 문화에 꼭 필요합니다. 소프트웨어 개발 팀과 IT 팀 간의 프로세스를 자동화하고 통합하면 소프트웨어를 더 빠르고 안정적으로 만들고 테스트하고 릴리스할 수 있습니다.
DevOps 문화의 이점은 무엇입니까?
DevOps 문화를 수용할 때 얻을 수 있는 가장 명백하고 영향력 높은 이점은 높은 품질의 소프트웨어 릴리스가 간소화되고 더 자주 이루어진다는 점입니다. 이것은 회사 실적뿐만 아니라 직원 만족도도 높입니다.
“Accelerate: Building and Scaling High Performing Technology Organizations”라는 책에 따르면 DevOps 문화는 높은 수준의 신뢰와 공동 작업을 촉진하고 더 나은 의사 결정을 내리도록 하며 업무 만족도를 높입니다.
DevOps 문화를 수용하는 것은 직원 만족도를 저해하지 않으면서 높은 성과의 엔지니어링 조직을 구축하는 데 중요합니다. '윈윈'하는 것입니다. 엔지니어에게는 사용자가 만족하는 안정적인 고성능 소프트웨어를 자주 쉽게 배포하고 실행하는 것만큼 뿌듯한 것이 없으며, 경영진에게는 향상된 비즈니스 결과가 큰 장점입니다.
도전 과제는 무엇입니까?
DevOps 문화를 완전히 수용하려면 일반적으로 개인과 팀이 업무 방식을 크게 변경해야 하므로 조직의 최고 수준에서 이 문화를 받아들이는 과정이 필요합니다.
일반 직원의 노력은 DevOps 혁신을 위한 경영진 수준의 승인을 얻기 위한 중요한 출발점이 될 수 있으며, 실제로 그러한 경우가 많습니다. 광범위한 DevOps 채택을 위해 가장 설득력 있는 주장은 많은 경우 소수의 개인 또는 소규모 팀이 DevOps 접근 방식을 채택하여 성공이 나타나기 시작하는 것입니다.
DevOps 문화에서 흔히 볼 수 있는 높은 수준의 자율성과 신뢰는 관련된 개인 또는 팀 간에 갈등이 있었던 경우 실현하기 어려울 수 있습니다. DevOps 접근 방식을 채택하기 전에 팀이 사일로화된 정도가 높을수록 연결을 구축하기는 더 어렵습니다.
변화는 쉽지 않습니다. 기존 개인 및 팀이 높은 수준으로 조화로운 환경에서도, 변화의 이점을 명확하게 표현하고 이해할 수 없으면 변화에 대한 수용과 노력의 의지를 이끌어내기 어려울 수 있습니다.
강력한 엔지니어링 사고 방식을 가진 조직은 비즈니스 과제를 해결하기 위해 즉시 도구와 기술를 시작하기도 합니다. 조직이 DevOps 접근 방식으로 전환하는 데 도움이 되는 도구와 기술도 있지만, 문화를 바꾸지 않고 도구와 기술만을 바꾸면 기초적인 약점을 해결하지 않고 겉만 바꾸는 것이기 때문에 “카고 컬트 DevOps”라고 불리기도 합니다.
DevOps 문화로 전환 시 고려 사항
개방형 커뮤니케이션
DevOps가 해결하고자 하는 가장 근본적인 과제는 서로 다른 조직 단위의 지식, 경험 및 작업의 사일로화를 막는 것입니다. 코드를 작성하는 프로그래머와 코드를 배포하고 유지 관리하는 시스템 관리자가 소통하지 못하면 비효율적일 가능성이 높습니다.
실수할 기회
많은 조직, 팀 및 개인은 실수를 절대로 저지르지 않도록 자신과 서로에게 엄청난 부담을 가하고 있습니다. 실패가 허용되지 않는 경우, 개인이나 팀이 문제를 해결하거나 혁신적인 기능을 개발하기 위해 새로운 접근 방식을 시도할 가능성이 낮습니다.
이 사고 방식은 "평균 복구 시간"(MTTR)보다 "평균 고장 간격"(MTBF)을 더 중요하게 측정했던 과거의 집착에 반영되어 있습니다. MTBF는 "근본 원인" 분석과 같은 도구를 사용하여 고장의 원인을 식별하고 실패가 다시 발생하지 않도록 방지합니다. MTTR은 소프트웨어 애플리케이션을 예측할 수 없는 방식으로 장애가 발생하기 쉬운 복잡한 시스템이라고 보며, 장애가 발생할 경우 신속한 복구에 중점을 둡니다.
“비난을 배제한 회고”는 DevOps 문화에서 흔히 볼 수 있는 기능입니다. 스프린트 또는 프로젝트가 끝날 때 팀이 회의를 통해 잘 진행된 부분과 개선할 부분에 대해 개방적이고 안전한 환경에서 논의할 때 결과를 개선할 수 있습니다.
실패에 대해 비난 없는 견해는 실수가 발생한다는 것을 인정하지만 사용자와 조직 모두 학습, 성장, 개선할 수 있다는 가정 하에 운영되는 성장의 사고 방식을 채택하기 때문에 효과적입니다.
- Jennifer Davis 및 Katherine Daniels의 "Effective DevOps"
새로운 프로세스의 집합
DevOps 문화를 조성하려면 오래된 문제에 대한 새로운 접근 방식을 개발해야 합니다. DevOps에는 프로그래머가 애플리케이션 코드를 작성하여 애플리케이션을 배포 및 운영하는 운영 팀에 전달하는 "사일로화된 프로세스"를 변경하는 작업이 수반됩니다. DevOps 접근 방식에서는 개발 및 운영 팀이 프로젝트의 전체 수명 주기 동안 공동 작업해야 합니다.
지속적 통합 및 지속적 배포(CI/CD)는 일반적으로 DevOps 문화에 필수적인 것으로 여겨집니다. 세 번째 프로세스인 지속적 배포는 Netflix와 같은 대규모 조직에서 수용하여 사용되지만 대부분의 소규모 기업에서는 일반적으로 채택(또는 요구)되지 않습니다. 새로운 기능을 프로덕션 환경에 지속적으로 배포하려면 새 코드를 철저하게 테스트했고 안전하게 배포할 수 있다는(예: 기능 토글 뒤에서) 높은 수준의 신뢰가 필요하기 때문입니다. 따라서 조직에서 하루에 여러 번 배포하지 않는다면 이 접근 방식을 지원하는 프로세스에 투자할 필요는 없을 수도 있습니다.
대부분의 경우 “트렁크 기반 개발”을 조금 변형하면 CI/CD 작업이 대폭 간소화됩니다. 이 모델에서 팀은 오래된 기능 브랜치를 없애고 코드의 “트렁크” 브랜치에 자주 커밋합니다.
트렁크 기반 개발에서 중요한 구성 요소는 포괄적인 자동화 테스트(단위, 통합 및 회귀)입니다. 이를 통해 트렁크 브랜치에 모든 새로운 커밋을 리포지토리에 푸시했을 때 철저히 검사했다고 보장할 수 있습니다.
지속적 통합은 소프트웨어 프로젝트에서 여러 기여자의 코드 변경을 통합하는 작업의 자동화 프로세스입니다. 지속적 통합은 개발 팀을 넘어 조직의 나머지 부분으로 확장됩니다. 예를 들어 제품 팀은 기능 및 수정 사항을 순차적으로 출시할 시기와 담당할 팀원을 조율합니다.
지속적 배포는 엔지니어링 팀과 디자인, 제품, 마케팅과 같은 엔지니어링 이외의 팀을 하나로 묶어 제품을 제공하는 조직적 방법론입니다. CD가 없는 환경은 개발자가 기본 사용자 경험에 대해 QA 팀에 집중하는 “타부서에 전달하면 끝”이라는 행태가 발생하게 합니다. 즉, 리포지토리의 “트렁크” 브랜치가 항상 “배포 가능” 상태라는 의미입니다.
지속적 배포를 사용하면 기능 플래그 뒤에 숨어 있거나, 소수의 고객에게 배포하거나, 쉽게 롤백할 수 있게 만들어서 코드 변경을 프로덕션 환경에 자동으로 배포할 수 있습니다. 이를 통해 팀은 고객 피드백에 대응하고 새로운 기능을 신속하게 배포 및 확인할 수 있으므로 변화하는 시장 및 고객 요구에 더 유연하게 대응할 수 있습니다. 또한 기능을 롤백하기 쉬워 팀은 빌드의 실패에서 방해받지 않을 수 있습니다.
기능 플래그, 기능 토글 또는 다크 배포는 프로덕션 환경에 배포할 때 새 애플리케이션 기능이 나타나거나 작동하지 않도록 하면서 약간의 노력으로 활성화할 수 있는 일반적인 방법입니다. 이 전략은 사용자에게 부정적인 영향을 줄 위험이 거의 없기 때문에 지속적 배포를 지원합니다. 또한 별도의 서버 인스턴스를 실행하고 사용자가 액세스할 수 있는 하나의 서버에만 기능을 릴리스하거나 지역별로 기능을 세그먼트화하여 기능을 사용자 기반의 하위 집합으로 제한하는 것도 흔한 방법입니다.
업데이트된 도구 체인
대부분의 소프트웨어 개발 팀은 적어도 어떤 유형의 버전 제어, 이슈 추적 및 애플리케이션 모니터링 도구를 사용하고 있습니다. 모두 DevOps 문화를 지원하는 데 중요한 도구이지만, 기존 도구 집합에 가장 중요한 추가 기능은 CI/CD를 지원하는 소프트웨어입니다. DevOps 문화에 필요한 피드백을 빠르게 얻을 수 있는 유일한 방법은 커밋을 수행하고, 테스트하고, 배포하는 자동화된 워크플로를 가지는 것입니다.
DevOps - 성과를 내는 문화적 변화
개발자들은 수십 년 동안 더 적은 노력과 더 적은 버그로 소프트웨어를 더 자주 제공하려는 목표를 향해 달려왔습니다. 이제 이 목표를 실현해줄 도구와 관행이 드디어 제공됩니다.
Atlassian은 DevOps를 실행하는 조직이 더 높은 품질의 결과물을 더 빠르게 제공하며(61%) 배포 빈도 및 시장 출시 속도가 증가했다는(49%) 점을 발견했습니다. 또한 조직만 혜택을 누리는 것이 아닙니다. DevOps를 실행하는 팀원들은 새로운 스킬을 배웠고(78%) 연봉이 인상되었다고(48%) 말합니다.
DevOps 문화를 조성하기는 어려울 수 있지만 개발자, 관리자 및 고객 모두의 만족도가 높아진다는 보상은 충분한 가치가 있습니다.
DevOps 문화를 개선하려고 합니까? 서비스 팀 상태 모니터로 시작하세요. 또한 DevOps 문화 구축을 위한 4가지 주요 전략에서 동료들과 커뮤니케이션, 공동 작업 및 브레인스토밍을 연습하세요.
이 기사 공유
다음 주제
여러분께 도움을 드릴 자료를 추천합니다.
이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.
DevOps 커뮤니티
DevOps 학습 경로
