DevOps 실시간 수업과 인증 준비 과정에서 빠지지 않고 나오는 질문이 하나 있다는 것을 알았습니다. 그래서 오늘은 이 질문에 답하는 짧은 글을 쓰기로 했습니다. ‘DevOps와 Scrum에는 어떤 차이가 있나요?’ 바로 ‘DevOps와 Scrum 비교’입니다.
International DevOps Certification Academy™의 인사이트
DevOps와 Scrum의 주요 차이점 6가지는 무엇인가요? (DevOps와 Scrum 비교)
오늘은 그중 주요 차이점 6가지를 설명하겠습니다. 시작해 봅시다!
차이점 1: DevOps에서는 각 반복 주기(스프린트)가 끝날 때 코드를 프로덕션에 배포합니다. Scrum의 목표는 각 반복 주기가 끝날 때 제공 가능한 코드를 준비하는 데 그칩니다.
이것은 Scrum 프레임워크의 큰 단점이자 여러 조직에서 Scrum이 실패하는 가장 중요한 이유 중 하나로, 첫째 이유일 수도 있습니다. 반복 주기가 끝날 때 코드를 배포하지 않으면 보통 스테이징 서버에 저장하거나, 더 나쁘게는 소프트웨어 엔지니어링을 대개 잘 모르는 프로젝트 책임자가 프로덕션 배포 시점을 정할 때까지 코드 버전 관리(CVS) 시스템에 방치합니다. 프로덕션 배포를 6개월에 한 번 하는 대형 은행과 통신사를 알고 있습니다. 농담처럼 들리지만 사실입니다. 이런 일괄 배포는 프로덕션 시스템에 우선순위와 심각도가 가장 높은 인시던트를 많이 일으키고, 직원 사기를 떨어뜨리고, 이력서를 갱신하는 직원 수를 늘립니다. 자기 실패를 정당화할 희생양을 찾는 비기술 인력의 책임 전가와 내부 갈등은 언급하지 않아도 그렇습니다.
차이점 2: DevOps에서는 지속적 소프트웨어 제공의 전제 조건인 테스트 자동화와 지속적 소프트웨어 통합이 개발 실무에 깊이 자리 잡습니다. Scrum에서는 소프트웨어 제공을 나중에 고려하고, 개발에 전혀 관여하지 않는 사람이 제공을 계획하고 운영합니다.
이 역시 Scrum 프레임워크의 가장 중요한 약점 중 하나입니다. Scrum 프로세스 자체는 소프트웨어 제공 실무에 거의 또는 전혀 기여하지 않습니다. DevOps에서는 팀이 클릭 한 번으로 프로덕션에 배포할 수 있도록 소프트웨어 제공 파이프라인, 테스트 자동화, 프로덕션 아키텍처를 갖추는 것이 필수입니다. Scrum 소프트웨어 제공 프로세스는 1986년부터 있었으며, Hirotaka Takeuchi와 Ikujiro Nonaka가 Harvard Business Review의 ‘New Product Development Game’이라는 글에서 처음 소개했습니다. Scrum이 처음 등장한 지 30년이 넘은 지금, 팀이 소프트웨어를 제공하는 방법은 크게 개선되었습니다. 이제 DevOps는 Scrum이 지금까지 답하지 못한 질문에 답을 제시합니다.
차이점 3: DevOps에서는 조직에 비즈니스 가치를 창출하는 제품과 서비스를 중심으로 프로젝트를 진행합니다. Scrum은 비즈니스 성과에 기여할 만큼 성숙하지 않습니다.
DevOps는 엔지니어링 팀을 일을 해내는 지적인 단위로 봅니다. 팀은 작동하는 소프트웨어 제품 및 서비스를 제공해 고객을 돕고 조직에 수익을 창출합니다. 안타깝게도 Scrum은 구성원에게 비즈니스 성숙도에 관해 가르치지 않습니다. 매일 스탠드업을 할 때 방에서 앉아 있으면 안 된다는 식의 ‘의심할 수 없는’ 의식이 보기에는 그럴듯하지만, 높은 훈련과 보수를 받는 엔지니어가 유치원에 있는 듯 행동하고 Scrum Master가 유치원 교사처럼 행동한다고 느낀다면, Scrum이 엔지니어를 전문가로 성장시키지 않기 때문입니다. DevOps에서는 경험과 지식 수준에 관계없이 엔지니어링 조직의 모든 사람이 전문가답게 행동해 비즈니스 가치를 창출합니다. 따라서 일일 스탠드업에서 앉아도 되는지 같은 터무니없는 주제로 불필요하고 무의미한 논의를 할 필요가 없습니다. DevOps에서는 브레인스토밍을 통해 사업에 더 많은 수익을 가져다줄 최선의 소프트웨어 솔루션을 찾고 개선하는 데 힘을 씁니다!
차이점 4: DevOps에서는 모든 엔지니어가 서비스 품질(소프트웨어 품질)과 운영의 우수성에 관심을 둡니다. Scrum에서는 소프트웨어 품질 보증과 운영이 다른 사람의 일입니다.
대부분의 Scrum 팀에서는 외부 테스터가 소프트웨어 품질 보증을 전담합니다. 소프트웨어 배포와 운영은 시스템 관리자가 맡습니다. Scrum 팀이 제공 품질과 소프트웨어의 실제 프로덕션 운영 과정에서 분리된 것이 Scrum을 도입한 여러 조직이 어려움을 겪는 중요한 이유이기도 합니다. DevOps에서 품질 보증은 소프트웨어 엔지니어링 조직 모두의 공동 책임입니다. 뛰어난 DevOps 풀스택 소프트웨어 엔지니어는 구상 단계부터 수명 주기 종료까지 제공, 보안, 안정성, 성능, 유지보수 가능성, 운영 및 기타 모든 비기능적 측면을 주시합니다. 소프트웨어를 개발하고 품질을 보장하고 운영하는 데 필요한 역량을 하나로 모은 DevOps 팀은 성공할 준비를 갖추고 조직에 뛰어난 비즈니스 성과를 만들어 냅니다.
차이점 5: DevOps는 품질과 지속적 제공 가능성을 확보하기 위한 소프트웨어 아키텍처 설계에 도움을 줍니다. Scrum은 적절한 아키텍처로 소프트웨어를 구축하는 일을 지원하지 않습니다.
Scrum은 엔지니어링 팀이 올바른 아키텍처의 방향과 비전을 세우도록 지원하거나 안내하지 않습니다. 다시 기억하세요! Hirotaka Takeuchi와 Ikujiro Nonaka가 Scrum을 소개한 지 30년이 넘었습니다. DevOps에서 제품, 서비스 및 마이크로서비스 API는 아키텍처 안에서 느슨하게 결합되어야 합니다. 각 DevOps 팀은 그 아키텍처의 한 부분만 책임지고, 소프트웨어를 독립적으로 설계하고 개발하고 배포할 수 있습니다. 배포 파이프라인에 내장된 조기 경보는 코드 체크인으로 생길 수 있는 부작용을 DevOps 팀에 자동으로 신속히 알려야 합니다.
차이점 6: DevOps는 뛰어난 비즈니스 성과를 위해 엔드투엔드 소프트웨어 엔지니어링 조직에 초점을 둡니다. Scrum은 소프트웨어 개발자만 살핍니다.
Scrum은 5~9명인 소규모 개발팀에 초점을 좁힙니다. 10명이 안 되느냐고 물으면 Scrum 이론은 안 된다고 할 것입니다. 이유는요? 알 수 없습니다! 어쨌든 소프트웨어 엔지니어링을 이렇게 좁게 보면 Scrum이 조직과 맞지 않는 경우가 많습니다. Scrum 팀이 전문 조직에 어떻게 자리 잡고 가치를 창출해야 하는지 Scrum이 답을 주지 않기 때문입니다. DevOps는 제품과 서비스 중심 팀을 만들 것을 제안합니다. 이러한 팀은 독립적이고 교차 기능을 갖추며 자율적이고 자립할 수 있고, 대개 규모가 작습니다. 아키텍처와 상세 설계, 코딩, 테스트, 실험, 배포, 운영 및 유지보수 등 특정 제품이나 서비스의 소프트웨어 엔지니어링 수명 주기 전체를 책임집니다. 일시적인 프로젝트 팀은 여기에 해당하지 않습니다. 그렇습니다. 제대로 읽으셨습니다. 만든 사람보다 소프트웨어를 더 잘 운영하고 유지할 사람이 있을까요? 당연히 없습니다. 따라서 Amazon과 Netflix의 가장 성공적인 DevOps 팀이 제품과 서비스를 릴리스한 뒤에도 손을 떼지 않는 것은 놀랍지 않습니다. 자체 프로덕션 시스템에서 소프트웨어의 운영과 유지보수도 맡습니다.
이러한 차이를 읽고 나면 DevOps가 왜 차세대 애자일 방식으로 떠오르는지 명확히 알 수 있을 것입니다!
몇 년 안에 DevOps가 Scrum을 포괄하는 방식으로 널리 받아들여질 것입니다. Google, Amazon, Facebook, Etsy, Netflix 같은 대규모 조직과 여러 기업이 이미 DevOps를 도입했기 때문입니다.
곧 어디서나 쓰이게 된다는 뜻입니다!
International DevOps Certification Academy™는 필요한 모든 것을 제공하여 DevOps를 편하게 배우고 인증 시험에 합격하도록 돕습니다! 질문이 있으시면 언제나 저와 팀이 도와드리겠습니다!
International DevOps Certification Academy™ 방문하기 >>
추신: 잠시 솔직해집시다! 요즘은 블로그 글을 읽는 사람이 많지 않다는 것을 알고 있습니다. 하지만 몇 사람이 글을 읽고 한두 가지라도 배운다면 전 세계 DevOps 커뮤니티를 돕는 사명을 이룬 것으로 생각하기에, 시간을 내어 여러분을 위한 글을 계속 씁니다.
여러분을 위해 글을 작성한 저희의 노력에 응원을 보내 주세요! 여기까지 읽으셨고 이 글이 유용했다면, 아래에 후기를 남기고 주변 사람들과 공유해 주세요!
미리 감사드립니다! :)
