Close

DevOps 문화란 무엇입니까?

DevOps 문화가 사용자, 프로세스 및 도구를 더 고객의 통합된 초점에 정렬할 수 있게 하는 방법입니다.

Headshot of Tom Hall
Tom Hall

DevOps 애드보케이트 및 실행자


협업

DevOps는 조직 변화에 대한 민첩한 접근 방식으로, 전통적으로 사일로화된 팀 간에 연결하고 공동 작업을 촉진하는 새로운 프로세스를 구축하려고 합니다. DevOps는 새로운 도구와 애자일 엔지니어링 관행을 통해 가능하지만, 이것만으로는 DevOps의 이점을 얻기에 부족합니다. 올바른 사고 방식, 관행 및 문화가 없다면 DevOps의 모든 약속을 실현하기 어렵습니다.

성공적인 DevOps 구현의 가장 중요한 요소는 사용자와 문화입니다.
- Atlassian 2020년 DevOps 트렌드 설문조사

DevOps 문화란 무엇입니까?


본질적으로 DevOps 문화에는 개발 및 유지 관리하는 제품에 대한 개발 및 운영 팀 간의 긴밀한 공동 작업과 공동 책임이 포함됩니다. 이것은 회사에서 사용자, 프로세스 및 도구를 고객의 더 통합된 초점에 정렬할수 있게 합니다.

여기에는 제품의 전체 수명 주기에 대한 책임을 지는 여러 분야 팀을 양성하는 것이 포함됩니다. DevOps 팀은 자율적으로 일하며 운영 요구 사항의 중요성을 아키텍처, 설계 및 개발과 동일한 수준으로 높이는 소프트웨어 엔지니어링 문화, 워크플로 및 도구 집합을 수용합니다. 개발자가 직접 구축하고 실행하면 개발자가 사용자 요구 사항을 더 잘 이해하여 사용자에게 더 가까이 다가갈 수 있습니다. 운영 팀이 개발 프로세스에 더 많이 관여하면 더 나은 제품에 대한 유지 관리 요구 사항과 고객 요구 사항을 추가할 수 있습니다.

DevOps 문화의 중심에는 전통적으로 사일로에서 일했던 팀 간의 향상된 투명성, 커뮤니케이션 및 공동 작업이 있습니다. 그러나 이 팀들이 더 가까워지려면 중요한 문화적 변화가 일어나야 합니다. DevOps는 특히 팀 자율성, 빠른 피드백, 높은 공감과 신뢰, 팀 간 공동 작업을 통해 지속적인 학습과 지속적인 개선을 강조하는 조직적인 문화의 변화입니다.

Mindful thinking logo
관련 자료

고객 우선의 사고 방식 수용

Trophy logo
관련 자료

DevOps의 이점 알아보기

DevOps entails shared responsibilities. Development and operations staff should both be responsible for the success or failure of a product. Developers are expected to do more than just build and hand off to operations — they are expected to share the responsibility of overseeing a product through the entire course of its lifetime, adopting a "you build it, you run it" mentality. They test and operate software and collaborate more with QA and IT Ops. When they understand the challenges faced by operations, they are more likely to simplify deployment and maintenance. Likewise, when operations understand the system’s business goals, they can work with developers to help define the operational needs of a system and adopt automation tools.

DevOps의 또다른 중요한 측면은 자율적인 팀입니다. 개발 및 운영 팀이 효과적으로 공동 작업하려면 번거롭고 긴 승인 프로세스 없이 의사 결정을 내리고 변경 사항을 구현해야 합니다. 여기에는 팀에 신뢰를 주고 실패에 대한 두려움이 없는 환경을 만드는 것이 포함됩니다. 이런 팀은 고객에게 가해지는 각 위험 수준에 대해 더 쉽고 빠르게 의사 결정을 내릴 수 있는 올바른 프로세스와 도구를 갖추고 있어야 합니다.

예를 들어 일반적인 개발 워크플로에서는 코드 변경 사항을 배포하기 위해 여러 팀의 여러 기여자가 참여해야 할 수 있습니다. 개발자는 코드를 변경하여 소스 제어 리포지토리로 푸시하고, 빌드 엔지니어는 코드를 만들어 테스트 환경에 배포하고, 제품 소유자는 이슈 추적 도구에서 작업 상태를 업데이트합니다. 자율적인 팀은 이 프로세스를 자동화하는 도구를 활용하므로 새 코드를 푸시하면 테스트 환경에 새 기능을 만들고 배포할 수 있으며 이슈 추적 도구는 자동으로 업데이트됩니다.

예를 들어, 한 팀이 새로운 DNS 엔트리와 같이 사소한 인프라 변경을 위해 별도의 운영 팀을 통해 티켓을 열어야 하는 등의 요구 사항으로 인해 어려움을 겪습니다. 몇 초 만에 완료할 수 있는 작업에 며칠 또는 몇 주가 소요됩니다. 자율적인 팀은 알맞은 스킬과 경험을 가진 담당자를 팀에 두거나 셀프 서비스 도구에 액세스하여 변경 사항을 직접 구현할 수 있습니다.

DevOps 팀 문화는 통합된 개발 및 운영 팀의 지속적인 개선에 도움이 되는 빠른 피드백을 중요하게 생각합니다. 개발 및 운영 팀이 단절된 사일로에 있는 환경에서는 프로덕션 환경에서 애플리케이션 소프트웨어의 성능 및 안정성에 대한 피드백이 개발 팀에 전달되는 속도가 느리거나 아예 전달되지 못할 수도 있습니다. DevOps는 애플리케이션 모니터링 및 보고 전략을 설계하고 구현하는 데 필요한 운영 담당자 간의 공동 작업을 요구하여 개발자가 애플리케이션 코드를 빠르게 반복하고 개선하는 데 필요한 피드백을 신속하게 얻도록 지원합니다. 예를 들어, 충분한 기능을 갖춘 지속적 통합 도구를 사용하면 새로운 코드 푸시를 자동으로 빌드하고 테스트할 수 있으며 코드 품질에 대한 즉각적인 피드백을 개발자에게 제공할 수 있습니다.

자동화는 뛰어난 공동 작업을 가능하게 하고 리소스를 확보해 주므로 DevOps 문화에 꼭 필요합니다. 소프트웨어 개발 팀과 IT 팀 간의 프로세스를 자동화하고 통합하면 소프트웨어를 더 빠르고 안정적으로 만들고 테스트하고 릴리스할 수 있습니다.

What are the benefits of DevOps culture?


The most obvious and impactful benefit of embracing a DevOps culture is streamlined, frequent, and high-quality software releases. This not only increases company performance, but also employee satisfaction.

A DevOps culture fosters high levels of trust and collaboration, results in higher quality decision making, and even higher levels of job satisfaction, according to the book “Accelerate: Building and Scaling High Performing Technology Organizations.”

Embracing a DevOps culture is key to building a high-performing engineering organization without sacrificing employee contentment. It’s a win-win. For an engineer there is nothing like the feeling of frequently and easily deploying and running stable, high-performing software that makes its users happy, and for executives the improved business outcomes are a hit.

What are the challenges?


Fully embracing a DevOps culture usually requires individuals and teams to make significant changes to how they work, and therefore requires buy-in at the highest levels of the organization.

A grassroots effort can be, and often is, an important starting point for getting management and executive-level buy-in for a DevOps transformation. Often the most compelling argument in favor of broader DevOps adoption is when a few individuals or small teams adopt a DevOps approach and begin demonstrating success.

The high levels of autonomy and trust that are typical in a DevOps culture can be difficult to cultivate if there is a history of conflict between any of the individuals or teams involved. The more siloed the teams were before attempting to adopt a DevOps approach, the harder it will be to build connections.

Change is hard. Even in environments where there is a high level of harmony between the existing individuals and teams, if the benefits of change aren't clearly articulated and understood, it can be difficult to drive acceptance and willingness to put in the work.

Understandably, organizations with a strong engineering mindset often jump immediately to tools and technologies to solve business challenges. Yes, there are tools and technologies that can help your organization transition to a DevOps approach. But changing tools and technologies without changing the culture is often called “cargo-cult DevOps” since it changes the facade without addressing the weakness in the foundation.

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 - a cultural shift that yields results


Developers have been chasing the dream of delivering software more frequently, with less effort, and fewer bugs for decades. Now, the tools and practices to make this a reality are finally here.

Atlassian found that organizations practicing DevOps say they ship higher quality deliverables (61%), with increased deployment frequency and faster time to market (49%). And it’s not just organizations who reap the benefits, practitioners say they’ve learned new skills (78%) and received a raise (48%).

Cultivating a DevOps culture can be challenging, but the rewards in increased satisfaction for developers, managers, and customers alike are worth it.

Are you looking to improve your DevOps culture? Start with the Service Team Health Monitor. Also, practice communicating, collaborating, and brainstorming with colleagues with the Top 4 Plays for Building a DevOps Culture.

Tom Hall
Tom Hall

Tom Hall은 DevOps 애드보케이트이며 실행자이며, 열렬한 독서가이며, 아마추어 피아니스트입니다.
지난 20년 동안의 업적에는 Novell, EMC, VMware 및 AWS의 인증이 포함됩니다. 그는 2016년에 애틀랜타에서, 그 이후로는 텍사스 오스틴에서 DevOpsDays를 조직했습니다.


이 기사 공유

여러분께 도움을 드릴 자료를 추천합니다.

이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.

DevOps 일러스트레이션

DevOps 커뮤니티

DevOps 일러스트레이션

시뮬레이션 워크숍

맵 일러스트레이션

무료로 사용해보기

DevOps 뉴스레터 신청

Thank you for signing up