애자일과 DevOps는 어떻게 상호 연관되어 있습니까?

Atlassian의 한쪽 사무실에는 친구들에게 익스트림 프로그래머로 알려지고, 자녀들에게는 LeSS SAFe DAD(영어로, 안전하지 않은 아빠) 애자일로 알려진 인증 스크럼 마스터가 있습니다!

다른 한쪽에는 IaC(Infrastructure as Code)를 지속적으로 배포하는 린 문화라는 기계가 있어서 그의 왼팔의 이름은 Dev(개발)이며 오른팔의 이름은 Ops(운영)인 DevOps입니다!

과장하여 이야기했지만, 이렇게 들으면 애자일과 DevOps가 서로 매우 다른 개념인 것처럼 느껴집니다. 이러한 혼란에 더하여 두 개념에는 각각 용어 및 슬로건이 있음에도 반대되는 정의를 가지고 있는 것 같습니다. 더 오래된 애자일의 의미는 분명하지만 DevOps의 경우 정의가 무수히 많아 좌절하게 됩니다. 정의의 모호함으로 인해 일부 의미는 섞이게 되었습니다.

DevOps와 애자일은 서로 역사적으로 연관성이 있습니다. Patrick DuBois와 Andrew Clay Schafer가 '애자일 인프라'를 주제로 하는 Agile 2008 Conference에서 연관성을 찾으려고 했을 때 DevOps와의 연결고리가 밝혀졌습니다. 이후 Patrick이 'DevOps'라는 용어를 만들었지만, 이 Agile Conference는 DevOps와 연결을 계속해서 존중합니다. 이제 스크럼과 지속적 배포를 자세히 살펴보면서 역사 외의 내용을 심층적으로 들여다보고 애자일과 DevOps의 실제적인 관련성에 대해 생각해 보겠습니다.

몇몇 팀에게 스크럼은 끊임없는 힘든 투쟁을 생산적이며 보람 있는 팀 업무로 바꾸는 열쇠입니다. 다시 말해, 스크럼은 회사 내 정치적 문제와 낭비를 객관성과 집중으로 대체합니다. 스크럼은 신조처럼 받아들여질 수도 있습니다. 비즈니스의 제약 또는 업무 자체로 인해 무언가 다른 것이 필요할 때 애자일 팀은 기본 스크럼 원칙을 활용하여 팀의 절차를 점검하고 더 효과적인 업무가 가능하도록 조정합니다. 이는 스크럼이 소프트웨어 개발 컨텍스트 외로 적용되는 경우 특히 중요합니다.

DevOps 커뮤니티에서 애자일을 경험해 본 팀원은 스크럼이 계획된 업무를 추적하는 데 유용하다는 사실을 인정합니다. 대규모 시스템 변경 릴리스, 데이터 센터 간 이동, 시스템 업그레이드 등 일부 운영 업무는 계획할 수 있습니다. 그러나 성능 급감, 시스템 중단, 보안 침해와 같이 계획되지 않은 운영 업무가 많습니다. 이러한 이벤트에는 즉각적인 대응이 필요합니다. 해당 항목이 백로그에서 또는 다음 스프린트 계획 세션에서 우선순 위가 지정되기를 기다릴 시간이 없습니다. 이러한 이유로 DevOps식 사고방식을 받아들이는 많은 팀은 스크럼을 넘어 칸반까지 고려합니다. 이를 통해 두 가지 업무 유형을 추적하고 두 업무 간의 상호 작용을 이해할 수 있습니다. 또는 Scrumban 또는 Kanplan(백로그가 있는 칸반)이라고 하는 하이브리드 접근 방식을 채택하고 있습니다.

여러 곳에서 스크럼이 널리 채택되는 비결은 주로 어떠한 기술 절차도 규정하지 않는 것일 수 있습니다. 스크럼의 간소한 관리 절차는 팀에 커다란 차이를 만들기도 합니다. 한때 여러 소스에서 우선 순위를 경쟁하던 때도 있었지만, 이제 백로그에 하나의 우선 순위 목록만 있으면 됩니다. 진행 중인 업무가 너무 많아 허덕이던 때도 있었지만, 이제는 나타난 시간에 따라 제약을 받는 계획을 세울 수 있습니다. 이 모든 것이 결합되어 팀은 새로운 수준의 생산성을 갖게 되었습니다. 그러나 팀은 이제 코딩 리뷰, 승인 테스트 자동화, 지속적 통합과 같은 기술 관행이 부족하여 제약을 받을 수 있습니다.

익스트림 프로그래밍과 같은 기타 애자일 프로세스에는 기술 절차를 통해 팀이 지속 가능한 속도를 유지하고 관리팀 및 이해 관계자에게 투명성과 가시성을 제공하는 역량을 지원하는 것과 관련된 강력한 옵션이 있습니다. 몇몇 스크럼 팀은 기술 작업을 백로그에 저장하는 방법에 의지하고 있습니다. 이 방법을 사용하는 경우 스크럼 가이던스 내에서는 문제가 없지만 제품 소유자가 기능에 대해 가지는 편견 등의 현실적인 문제에 즉시 마주하게 됩니다. 제품 소유자가 상당한 기술적인 지식을 보유하지 않은 이상 기술 절차 비용/이점을 평가할 스킬이 없을 수 있습니다. 기술 작업이 운영으로 확장되어 안정성, 성능, 보안을 지원함에 따라 제품 소유자가 이러한 스킬을 갖추기가 더 어려워지고 있습니다.

Atlassian은 운영하는 제품에 각기 다른 2개의 역할이 있는 것이 좋다는 점을 인식했습니다. Atlassian의 제품 소유자는 사용자에게 필요한 기능은 잘 이해하지만, 이러한 기능을 성능, 안정성, 보안 등 기능 외 특성과 비교해 보는 것에는 서툽니다. Atlassian의 일부 SaaS 제품에는 또한 이러한 기능 이외 특성의 우선 순위를 지정하는 서비스 소유자가 있습니다. 이 두 소유자가 '흥정'해야 하는 경우도 가끔 있지만 대부분의 경우 독립된 팀이 이러한 업무를 수행합니다. 이것이 운영팀의 '피드백을 확대'하는 유일한 방법이 아닐 수 있지만, 제품 소유자가 기능에 대해 흔히 가지는 편견을 극복하는 데 도움이 됩니다. '두 소유자' 접근 방식은 DevOps로 향하는 유일한 길은 아닙니다. 중요한 점은 이러한 기능 외 특성을 '기능'으로 이해하고 다른 기능 사용자 스토리처럼 계획 및 우선 순위를 지정할 수 있다는 것입니다.

궁극적으로 스크럼에 관한 이러한 문제는 온전히 스크럼 그 자체만의 문제는 아닙니다. 모든 애자일 방법과 마찬가지로 스크럼에는 회고라고 하는 기본으로 제공되는 '프로세스 개선' 메커니즘이 있습니다. 그러므로 일부 스크럼 팀에서는 DevOps를 영감의 원천으로 활용하고 스크럼 회고를 DevOps를 목표로 정비하고 조정하는 기회로 활용한다고 생각해도 괜찮습니다. 그러나 대부분의 팀에는 외부의 아이디어가 필요한 것이 현실적입니다. DevOps가 업무 중심으로 자리 잡지 않는 한(이를 가르쳐 주지 않는 한), 스크럼을 통해 자연스럽게 생겨나지는 않습니다. 애자일 또는 DevOps 코치와의 협업은 이들에게 소프트웨어 빌드, 테스트, 구축에 대한 자동화 경험이 있지 않은 한 그다지 중요하지 않습니다.

CD(지속적 배포)의 원칙을 제대로 실행한다면 진행 중인 업무를 제한하는 데 도움을 주며, 동시에 배포의 자동화가 제약 조건을 평가하는 데 도움을 줍니다. 이렇게 CD는 소프트웨어팀이 두 가지 중 하나를 선택해야 할 필요 없이 더 자주, 더 높은 품질로 배포할 수 있도록 돕습니다. 그러나 팀에서 스크럼에만 중점을 두는 경우 넓은 의미의 애자일 컨텍스트를 놓칠 수 있으며, 지속적 배포에만 중점을 두는 경우에는 넓은 의미의 DevOps 컨텍스트를 놓칠 수 있습니다.

CD를 실행한다고 해서 비즈니스와 소프트웨어팀 간의 커뮤니케이션 문제가 바로 해결되지는 않습니다. 비즈니스가 1년 단위의 예산 중심의 계획 주기를 가지고 있다면 생산에 힘쓰는 팀의 경우 여전히 비즈니스의 반응을 얻기까지 몇 달을 기다려야 할 수 있습니다. 프로젝트를 취소하거나 더 심한 경우 프로젝트 팀을 두 배로 늘리는 등의 반응이 너무 자주, 단계적으로 발생합니다. (nbsp새로운 팀원이 너무 많이 투입되면 업무에 지장을 받게 되기 때문입니다.)

Agile Fluency Model(애자일 능숙도 모델)에세는 능숙도의 첫 번째 레벨을 '가치에 집중'이라고 하며 팀은 투명성과 정렬에 집중합니다. 이 능숙도가 없으면 CD는 비즈니스에 어떠한 뚜렷한 가치도 창출하지 못하고 그저 끝없이 반복되는 기술 개선 주기로 돌아가기 쉽습니다. 팀은 높은 품질로 빠르게 배포할 수 있지만, 최종 사용자 또는 비즈니스에 낮은 가치가 있는 제품에 대해서 잘하는 것일 수 있습니다. 많은 사용자가 좋은 이야기를 하더라도 가치가 낮은 제품이라는 평가는 대규모 비즈니스 포트폴리오 수준에서만 가능합니다. 이 중요한 능숙도가 없으면 기능에 대한 기술 절차를 평가하기 어렵습니다. 이것은 잦은 배포에 적합한 설계 또는 자동화 테스트가 없는 레거시 코드베이스를 보유하고 있는 팀에게 특히 중요합니다. 레거시 컨텍스트에 따라 CD 변환에는 수년이 걸릴 수 있습니다. 따라서 비즈니스 이점을 입증하는 것이 훨씬 중요합니다.

DevOps는 배포 파이프라인을 자동화하는 것 그 이상입니다. John Allspaw의 말을 빌자면 DevOps는 "개발팀처럼 생각하는 운영팀, 운영팀처럼 생각하는 개발팀"이라고 말합니다. Gene Kim은 이러한 사고방식에 대해 DevOps의 원칙으로서의 세 가지 방법을 설명합니다.

CD(지속적 배포)는 첫 번째 방법에 집중하여 개발에서 운영으로 가는 흐름을 자동화합니다. 자동화는 배포 시스템을 가속화하는 데 확실한 역할을 합니다. 그러나 시스템적 사고에는 자동화만 있는 것이 아닙니다.

두 번째 방법은 '개발자도 페이저를 사용한다'는 점이 특징입니다. 페이저는 일반적으로 사용할 필요가 없을 수 있지만 개발자가 운영 이슈에 관여하게 줍니다. 이를 통해 개발자는 직접 내린 개발 결정의 결과를 이해할 수 있습니다. 페이저는 예를 들어 개발자가 로그 메시지를 더 좋은 위치에 넣도록 만들어 메시지를 더 의미 있게 만들 수 있습니다. 이는 단순히 인식의 문제만은 아닙니다. 개발자는 시스템의 내부적 이해를 문제 해결에 활용하여 더 빠르게 해결 방법을 찾고 구현할 수도 있습니다.

세 번째 방법은 파이프라인을 지나가는 애플리케이션에 변경 사항뿐만 아니라 시스템에서 전체에서 점진적 실험을 해보는 것입니다. 다시 말해, 자동화에 얼마나 시간이 걸리는지 확인하고 점점 강력해지는 인프라를 사용하여 계속 개선해 나가는 것이 비교적 쉽습니다. 역할 또는 조직 간에 업무를 넘기는 것이 어떻게 지연을 초래하게 되는지 이해하는 것이 더 어렵습니다. 이것은 팀이 전체 배포 워크플로우에서 '검사와 적응'을 하며 팀원 간의 협업을 개선할 기회를 찾는 것을 의미합니다. 이런 점과 관련하여 CD에는 적응하고 개선하는 습관이 필요합니다. 만약 팀이 더 효과적으로 업무를 수행할 방법을 성찰하고 다른 부분의 행동을 조정하지 않는다면 CD는 성장하거나 발전하지 못할 것입니다. 팀은 자체적으로 문제를 해결할 권한이 부여되었다고 느껴야 합니다.

스크럼에서 회고를 수행할 때마다 절차와 도구를 개선하는 기회를 얻을 수 있습니다. 그러나 팀이 단기 및 장기 기술 문제를 해결하는 데 이러한 기회를 활용하지 않는 경우에는 제품 소유자가 CD 작업을 백로그에 기록할 때까지 기다려야 하는데, 그런 일은 일어나지 않습니다.

스크럼은 주로 다음과 같은 애자일 원칙에 매핑됩니다. "개발하기에 늦었다 하더라도 요구 사항 변화를 적극적으로 받아들인다. 애자일 프로세스에서는 고객의 경쟁우위를 위해 변화를 활용한다."

지속적 배포는 주로 다음과 같은 애자일 원칙에 매핑됩니다. "우리의 가장 높은 우선순위는 유용한 소프트웨어의 빠른 지속적 배포를 통해 고객을 만족시킨다."

이는 애자일이 스탠드업 및 스프린트 계획과 같은 형식보다 오가는 변화를 받아들이는 것과 더 관련이 있음을 의미합니다. 실제로 애자일 성명에는 기타 10개 원칙 이 있습니다. 해당 원칙 중 몇 가지만 선택하기보다 모든 원칙이 전반적으로 고려되어야 합니다. 이러한 원칙들은 변화에 대한 태도를 나타내며, 이는 애자일 및 DevOps에 모두 공통적으로 적용됩니다.

DevOps 팀원들은 취약한 시스템을 실행하던 중 문제를 겪고 있습니다. 이 시스템은 비즈니스에 있어 매우 중요한 시스템이기 때문에 긴급한 변경이 필요한 상황입니다. 이처럼 변경을 수용하는 애자일 아이디어는 '변경를 위한 변경'이 아닙니다. 개발팀이 이러한 변경의 품질을 책임지는 동시에, 비즈니스 가치를 제공하는 전반적인 능력을 개선하는 것입니다. 이렇게 비즈니스 가치에 집중하는 것은 애자일과 DevOps가 공유하는 또 다른 측면입니다.

마지막으로 애자일과 DevOps 그 자체는 비즈니스 목표가 아니며 목표를 달성을 위해 더 나은 방식을 사용하도록 여러분의 조직에 영감을 줄 수 있는 문화적 운동입니다. 애자일과 DevOps는 대립할 때보다 조합하여 작동할 때 더 효과가 좋습니다. 이 두 가지 개념이 대립하지 않도록 하는 비결은 두 개념의 가치와 이들이 형성된 원칙을 더 깊이 이해하는 것입니다. 빠르고 좁은 의미로 정의하면 사일로화된 사고로 이어집니다. 애자일에는 스크럼만 있는 것이 아니며 DevOps에는 CD만 있는 것이 아니라는 점을 알게 되었으면 이제 강력한 애자일 + DevOps 조합을 시도할 준비가 된 것입니다.