Close

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는 한 팀이 하는 일이 아니며 모든 팀이 함께하는 일이라는 것을 알고 있습니다.

자동화


자동화를 사용하면 반복적인 수동 업무를 없애고, 반복 가능한 프로세스와 안정적인 시스템을 만들 수 있습니다.

자동화 빌드, 테스트, 배포 및 프로비저닝은 이러한 단계를 갖추고 있지 않은 팀이 일반적으로 시작해야 하는 과정입니다. 모두에게 도움이 되는 시스템을 구축하는 것보다 개발자, 테스터 및 운영자가 협력해야 하는 것이 더 중요한 이유는 무엇입니까?

자동화를 처음 접하는 팀은 보통 지속적 배포로 시작합니다. 지속적 배포란 대부분 클라우드 기반 인프라로 촉진된 자동화 테스트를 통해 각 코드 변경 사항을 실행한 다음, 빌드를 패키징하고, 자동화된 배포를 사용하여 환경을 통해 추진하는 과정입니다.

그 이유가 무엇일까요? 컴퓨터는 사람보다 더 엄격하고 충실하게 테스트를 실행하기 때문입니다. 이러한 테스트는 버그와 보안 결함을 더 빨리 찾아냅니다. 또한, 자동화된 배포는 IT/Ops 팀에 환경 간 드리프트를 알리므로 릴리스 시기에 발생할 수 있는 예상치 못한 문제를 줄여줍니다.

DevOps의 또 다른 장점은 "코드로 된 구성"입니다. 개발자는 더 안정적이며 유지하기 쉽기 때문에 모듈식, 구성 가능한 애플리케이션을 만들기 위해 노력합니다. 이와 동일한 개념은 이러한 애플리케이션이 클라우드에 있든지 기업의 자체 네트워크에 있든지와 관계없이 호스팅하는 인프라로 확장될 수 있습니다.

DevOps 세계에서 자동화 유형이 '코드로 된 구성' 및 "지속적 배포"만 있는 것은 아니지만, 이 두 가지 유형은 개발 및 운영 사이의 장벽을 허무는 데 도움이 되므로 특별히 언급할 가치가 있습니다. 또한, DevOps에서 자동화 배포를 사용하여 철저한 테스트를 거친 코드를 똑같이 프로비저닝된 환경에 전송하면 '내 컴퓨터에서는 작동합니'라는 말은 무의미해집니다.


소프트웨어의 맥락에서 "린"이란 보통 가치가 낮은 활동을 없애고 빠르고 적극적이며 애자일하게 움직인다는 의미입니다. DevOps와 가장 관련 있는 개념은 지속적인 개선과 실패 인정으로, 실험적인 사고 방식의 토대를 마련합니다.

DevOps 사고 방식을 가지면 어디서든 지속적인 개선 기회를 포착할 수 있습니다. 팀의 프로세스를 개선할 수 있는 주기적인 회고와 같이 일부 기회는 명백합니다. 그러나 그 외에 제품을 처음 사용하는 사용자를 대상으로 각기 다른 온보딩 접근 방식을 사용하는 A/B 테스트 등은 기회를 포착하기 어렵습니다.

Atlassian에는 지속적 개선을 주요 아이디어로 만들어 주는 애자일 개발 방법론이 있습니다. 애자일 방법론을 가장 먼저 도입했던 사람은 고객이 현재 가지고 있는 단순한 제품이 6개월 후에 고객이 갖게 될 완벽한 제품보다 더 가치 있음을 증명했습니다. 제품이 계속해서 개선된다면 고객은 떠나지 않습니다.

한편, 실패는 피할 수 없습니다. 따라서 여러분의 팀이 실패를 받아들이고 문제를 복구하여 이를 통해 교훈을 얻도록 해야 합니다. 누군가는 이런 과정을 '단단해지는 과정'이라고도 합니다. Atlassian은 가끔이라도 실패하지 않는다는 것은 그만큼 충분히 노력하지 않았음을 의미한다고 생각합니다.

DevOps의 컨텍스트에서 실패는 처벌받아야 하는 범죄가 아닙니다. 팀은 언젠가는 반드시 문제가 생길 것이라고 가정하므로 빠른 탐지 및 복구가 가능하도록 빌드합니다. 사후 검토는 코드를 잘못 작성한 팀원을 찾는 것보다 프로세스의 어디가 잘못되었으며 어떻게 프로세스를 강화할 수 있는지에 집중합니다. 왜 그럴까요? 그 이유는 바로 지속적 개선과 실패가 밀접하게 관련되어 있기 때문입니다.

측정


데이터가 없으면 지속적인 개선을 위한 노력이 실제 개선으로 이어진다고 증명하기가 어렵습니다. 다행히도, 사용자가 제품을 사용한 시간, 블로그 게시물이 판매로 이어졌는지 여부, 중요한 알림이 로그에 자주 등장하는지 등 성능을 측정하는 도구 및 기술이 많이 있습니다.

무엇이든 측정할 수 있다고 해서 모든 것을 측정해야 하는 것은 아닙니다. 애자일 개발 방법에 따라 다음 기본사항을 확인해 보세요.

개발에서 배포에 이르기까지 얼마의 시간이 소요되었나요?

버그 또는 장애가 얼마나 자주 반복됩니까?

시스템 장애 발생 후 복구하는 데 시간이 얼마나 소요됩니까?

현재 여러분의 제품을 사용 중인 사용자는 몇 명입니까?

이번 주에 등록/해지한 사용자는 몇 명입니까?

기초가 탄탄하면 기능 사용, 고객 경험 및 SLA(서비스 수준 계약)와 관련된 복잡한 메트릭을 더 쉽게 포착할 수 있습니다. 이렇게 얻게 되는 정보는 로드맵을 작성하고 다음 계획을 세부적으로 세울 때 도움이 됩니다.

이러한 유용한 데이터는 모두 여러분의 팀이 결정을 내리는 데 도움을 주지만, 다른 팀 특히 다른 부서의 팀과 공유될 때 더 강력한 힘을 발휘합니다. 예를 들어, 여러분의 마케팅 팀에서는 판매할 수 있는 새롭고 눈부신 기능을 원하지만, 여러분은 제품의 기술적 부채로 인해 상당한 고객 이탈을 겪고 있는 것을 볼 수 있습니다. 로드맵에 도움이 되는 사용자 데이터를 제공하면 비록 기능이 부족하고 수정할 사항은 많더라도 이해 관계자의 합의와 동의를 얻기 쉬워집니다.

공유


모든 팀을 성과가 높은 DevOps 팀으로 바꿔주는 마술 지팡이가 있다면 좋겠지만, DevOps 혁신에는 관행, 문화적인 철학 및 도구가 모두 함께 필요합니다. 그러나 지금까지 살펴본 것과 같이 개발 및 운영 사일로를 허무는 것은 그만한 가치가 있습니다. 신뢰도가 높아지고, 소프트웨어 릴리스가 빨라지고, 배포가 더 안정적이게 되며 팀과 고객 간의 피드백 루프가 개선됩니다.

DevOps를 수용하는 데는 많은 노력이 필요합니다. 그러나 올바른 사고 방식, 노력 및 도구가 주어지면 조직은 DevOps 혁신을 이뤄 상당한 이점을 얻을 수 있습니다.

개발팀과 운영팀 간의 오랜 마찰은 대부분 공유하는 부분이 부족하여 발생합니다. Atlassian은 책임과 성공을 공유하면 이러한 차이를 좁히는 데 큰 도움이 될 것이라고 생각합니다. 개발자는 운영팀의 큰 부담 중 하나인 페이저(오늘날 비유적으로 사용되는 단어. 인시던트 알림)를 도와 즉각적으로 환심을 얻을 수 있습니다. DevOps는 애플리케이션을 만든 팀원들이 애플리케이션의 제공과 실행에도 참여해야 한다는 아이디어를 중요시합니다.

결론...


이 아이디어에서 팀 전반의 직접적인 접근 방식을 유도하는 "직접 빌드 및 직접 운영"이라는 표현이 생겨났습니다. 이것은 개발자를 고용하여 단순히 훌륭한 운영을 해주기 바라는 것이 아니라, 개발자 및 운영자가 애플리케이션 라이프사이클 전반에서 함께한다는 것을 의미합니다. 또한 보고서에 따르면 동료 평가를 거친 코드와 제품이 더 나은 제공 및 성능을 가져오는 유일한 검토라는 사실이 밝혀졌습니다. 실제로 외부 검토자의 경우 검토를 전혀 수행하지 않는 것과 비교하여 효과가 크게 다르지 않았습니다.

DevOps를 활용하는 팀은 대개 역할을 돌아가며 맡으며, 개발자가 최종 사용자가 발견한 이슈를 해결하면서 이와 동시에 프로덕션 문제를 해결합니다. 이 팀원은 고객이 보고한 긴급한 이슈에 대응하며, 필요한 경우 패치를 만들고, 고객이 보고한 결함의 백로그에 대해 작업합니다. "지원하는 개발자"는 애플리케이션이 실제로 사용되는 방법에 대해 자세히 알게 됩니다. 또한, 운영팀을 적극적으로 지원함으로써 개발팀은 신뢰와 상호 존중을 형성합니다.

Ian Buchanan
Ian Buchanan

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

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


이 기사 공유
다음 주제

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

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

DevOps 일러스트레이션

DevOps 커뮤니티

DevOps 일러스트레이션

DevOps 학습 경로

맵 일러스트레이션

무료로 사용해보기

DevOps 뉴스레터 신청

Thank you for signing up