CALMS 프레임워크

DevOps 여정에서 역량을 평가하고 진행 상황을 측정하세요.

Ian Buchanan

수석 솔루션 엔지니어

CALMS는 기업의 DevOps 프로세스 채택에 대한 역량을 평가하는 프레임워크이며, DevOps 변환 과정에서 성공을 측정하는 방법이기도 합니다. "DevOps 핸드북"의 공동 저자인 Jez Humble이 만든 용어로 문화(Culture), 자동화(Automation), 린(Lean), 측정(Measurement) 및 공유(Sharing)의 약자입니다.


DevOps는 단순한 프로세스나 개발에 대해 다르게 접근하는 방식이 아니라 문화적인 변화입니다. 그리고 DevOps 문화의 주요 부분은 협업입니다.

이 세상의 모든 도구와 자동화 시스템은 개발 및 IT/Ops 전문가가 협력하지 않는다면 쓸모가 없습니다. DevOps는 도구의 문제를 해결하는 것이 아니라, 사람의 문제를 해결하기 때문입니다.

DevOps를 진화된 애자일 팀이라고 생각하세요. 다른 점이 있다면 이제 운영이 기본적으로 포함된다는 것입니다. 제품 중심의 팀을 구축하여 기능 기반 팀을 대체하는 것은 올바른 선택입니다. 여기에는 개발, QA, 제품 관리, 설계, 운영, 프로젝트 관리 및 장기적으로 진행되는 제품에 필요한 기타 스킬셋도 포함되어 있습니다. 한 팀에서 모든 작업을 수행하거나 “DevOps 전문가”를 고용하는 것보다는, 원활하게 협업할 수 있는 제품 기반 팀을 가지는 것이 더 중요합니다.

공통 목표를 공유하고 이러한 목표를 함께 달성하는 계획을 세우는 것처럼 협업을 조성하는 몇 가지 요소가 있습니다. 일부 회사에서는 제품 기반 팀으로 빠른 전환이 과도게 그리고 너무 빠르게 일어납니다. 그러니 더 세분화된 단계로 나눠야 합니다. 개발 팀은 운영 팀에서 적합한 팀원이 스프린트 계획 수립 세션, 일일 스탠드업 미팅, 스프린트 데모에 참여하도록 초대할 수 있으며 반드시 그렇게 해야 합니다. 운영 팀은 주요 개발자를 미팅에 초대할 수 있습니다. 서로의 작업, 아이디어 및 노력을 지속적으로 파악할 수 있는 애자일하고도 유기적인 방법입니다.

관련 자료

DevOps의 이점 알아보기

관련 자료

DevOps 문화 구축

도전 과제, 심지어는 긴급 상황은 DevOps 문화를 효과적으로 테스트합니다. 개발팀, 운영팀, 고객 애드보케이트가 팀으로서 함께 모여 문제를 해결합니까? 인시던트 사후 검토는 잘못을 따지기보다 결과를 개선하는 데 집중합니까? 답변이 '예'라면 조직이 DevOps 문화를 수용하고 있다는 것입니다.

대부분의 성공적인 회사는 모든 부서와 모든 조직 체계에 DevOps 문화를 적용하고 있습니다. 이렇게 광범위한 규모에서 'DevOps'라는 용어는 의미의 폭이 너무 좁아 더 이상 필요하지 않은 경우가 많습니다. 이러한 회사에서는 열린 커뮤니케이션 채널을 갖추고 정기적으로 대화를 진행하며, 고객 만족은 제품 관리 팀과 개발 팀 모두의 책임이라고 생각합니다. 즉, DevOps는 한 팀이 하는 일이 아니며 모든 팀이 함께하는 일이라는 것을 알고 있습니다.


Automation helps eliminate repetitive manual work, yields repeatable processes, and creates reliable systems.

Build, test, deploy, and provisioning automation are typical starting points for teams who don’t have them in place already. And hey: what better reason for developers, testers, and operators to work together than building systems to benefit everyone?

Teams new to automation usually start with continuous delivery: the practice of running each code change through a gauntlet of automated tests — often facilitated by cloud-based infrastructure — then packaging up builds and promoting them through environments using automated deployments.

Why? Computers execute tests more rigorously and faithfully than humans. These tests catch bugs and security flaws sooner. And automated deployments alert IT/Ops about drift between environments, which reduces surprises when it’s time to release.

Another major contribution of DevOps is “configuration as code.” Developers strive to create modular, composable applications because they are more reliable and maintainable. That same thinking can be extended to the infrastructure that hosts them, whether it lives in the cloud or on the company's own network.

“Configuration as code” and “continuous delivery” aren’t the only types of automation seen in the DevOps world, but they’re worth special mention because they help break down the wall between development and operations. And when DevOps uses automated deploys to send thoroughly tested code to identically provisioned environments, “works on my machine!” becomes irrelevant.

When we hear “lean” in the context of software, we usually think about eliminating low-value activities and moving quickly — being scrappy and agile. Even more relevant for DevOps are the concepts of continuous improvement and embracing failure — which lay the foundation of an experimental mindset.

A DevOps mindset recognizes opportunities for continuous improvement everywhere. Some are obvious, like holding regular retrospectives so your team’s processes can improve. Others are subtle, like A/B testing different on-boarding approaches for new users of your product.

We have agile development to thank for making continuous improvement a mainstream idea. Early adopters of the agile methodology proved that a simple product in the hands of customers today is more valuable than a perfect product in the hands of customers six months from now. If the product is improved continuously, customers will stick around.

And guess what: failure is inevitable. So you might as well set up your team to absorb it, recover, and learn from it (some call this “being anti-fragile”). At Atlassian, we believe that if you’re not failing once in a while, you’re not trying hard enough.

In the context of DevOps, failure is not a punishable offense. Teams assume that things are bound to go pear-shaped at some point, so they build for fast detection and rapid recovery. Postmortems focus on where processes fell down and how to strengthen them — not on which team member messed up the code. Why? Because continuous improvement and failure go hand in hand.


It’s hard to prove your continuous improvement efforts actually improve anything without data. Fortunately, there are loads of tools and technologies for measuring performance, like how much time users spend with your product, whether that blog post generated any sales, or how often critical alerts pop up in your logs.

Although you can measure just about anything, that doesn’t mean you have to (or should) measure everything. Take a page from agile development and start with the basics:

How long did it take to go from development to deployment?

How often do recurring bugs or failures happen?

How long does it take to recover after a system failure?

How many people are using your product right now?

How many users did you gain / lose this week?

With a solid foundation in place, it’s easier to capture sophisticated metrics around feature usage, customer journeys, and service level agreements (SLAs). The information you get comes in handy when it’s time for road mapping and spec’ing out your next big move.

All this juicy data will help your team make decisions, but it’s even more powerful when shared with other teams — especially teams in other departments. For example, your marketing team wants shiny new features they can sell. But meanwhile, you’re seeing high customer churn because the product is awash in technical debt. Providing user data that supports your roadmap — even if it’s light on features and heavy on fixes — makes it easier to build consensus and get buy-in from stakeholders.


As much as we wished that there was a magic wand to transform all teams into high-performing DevOps teams, DevOps transformations require a blend of practices, cultural philosophies, and tools. But like you’ve read, the benefits to breaking down the Development and Operations siloes are well worth it — increased trust, faster software releases, more reliable deployments, and a better feedback loop between teams and customers.

Embracing DevOps is no small task. Yet given the right mindset, effort, and tools, an organization can undergo a DevOps transformation that yields significant benefits.

The long-standing friction between development and operations teams is largely due to a lack of common ground. We believe that sharing responsibility and success goes a long way toward bridging that divide. Developers can win instant goodwill by helping to carry one of operations’ biggest burdens: the pager (a figurative construct these days). DevOps is big on the idea that the same people who build an application should be involved in shipping and running it.

In conclusion…

Out of this idea comes the phrase, "you built it, you run it," which fosters a hands-on approach accross teams. This doesn’t mean that you hire developers and simply expect them to be excellent operators as well. It means that developers and operators pair with each other throughout the application’s lifecycle. Moreover, reports have shown that peer-reviewed code and products are the only review that results in better delivery and performance; in fact, external reviewers were no more effective that conducting no review at all.

Teams that embrace DevOps often have a rotating role whereby developers address issues caught by end users while, at the same, troubleshooting production problems. This person responds to urgent customer-reported issues, creating patches when necessary, and works through the backlog of customer-reported defects. The “developer on support” learns a lot about how the application is used in the wild. And by being highly available to the operations team, the development teams build trust and mutual respect.

Ian Buchanan
Ian Buchanan

Ian Buchanan은 Atlassian 의 DevOps 수석 솔루션 엔지니어로, 보다 향상된 지속적 통합 및 지속적 배포를 위해 새롭게 부상하는 DevOps 커뮤니티를 비롯해 Jira, Bitbucket 및 Bamboo 애플리케이션에 중점을 두고 있습니다. Ian은 Java와 .NET 모두에 대한 폭넓은 경험을 보유하고 있으며 대규모 엔터프라이즈에서 린 및 애자일 관행의 챔피언으로 알려져 있습니다.

경력 기간 동안 그는 수명 주기의 모든 단계에서 엔터프라이즈 소프트웨어 개발 도구를 성공적으로 관리했습니다. Ian은 생산성 개선과 탁월한 품질, 향상된 고객 만족으로 조직 차원의 프로세스를 개선했습니다. 그는 스스로 방향을 지정하고 체계화하는 조직을 중시하는 다국적 애자일 팀을 구성했습니다. 강연하거나 코딩을 하지 않을 때에 Ian은 파서, 메타 프로그래밍 및 도메인 지정 언어에 대한 열정에 빠져 있을 것입니다.

이 기사 공유
다음 주제

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

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

DevOps 일러스트레이션

DevOps 커뮤니티

DevOps 일러스트레이션

시뮬레이션 워크샵

맵 일러스트레이션

무료로 사용해보기

DevOps 뉴스레터 신청

Thank you for signing up