DevOps에서 CI/CD란?
지속적 통합, 전달 및 배포(이하 CI/CD)는 DevOps 관행입니다. 달리 말하면 DevOps의 이상을 실현하는 기술입니다. 이 용어와 친숙하신 경우 DevOps가 구체적으로 무엇인지 궁금해 하실 수 있습니다. 그리고 애자일 소프트웨어 개발과는 어떤 관련이 있을까요? 소프트웨어 개발 관행이 어떻게 발전했고 애자일과 DevOps가 해결하려는 문제들을 더 폭넓게 이해하면 CI/CD 프로세스에서 더 많은 것을 얻는 데 도움이 됩니다.
애자일이 업계를 바꾼 방식
디지털 혁명 덕분에 다수의 조직(소프트웨어 개발사는 제외)에서 소프트웨어와 IT는 단순한 지원 도구에서 다양한 사업 부문에서 핵심이 되었습니다.
은행, 금융 및 소매를 포함한 여러 산업과 정부, 여행, 엔터테인먼트 등의 분야에서 소프트웨어 개발은 여러 조직의 업무에서 핵심적인 부분이 되고 있습니다. 제품과 서비스는 앱과 온라인 서비스를 통해 액세스 및 지원되고 있으며 통합 컴퓨터 시스템은 원활한 사업에 필수적입니다.
이 추세가 빨라지던 2001년에 소프트웨어 개발사 그룹이 애자일 선언을 작성했습니다. 이 선언은 당시 소프트웨어가 개발되던 방식에서 보여지던 일부 문제에 대한 그룹의 대응이었습니다. 애자일 선언은 소프트웨어 개발의 가치 및 선언을 제시하였으며 이를 실전 적용하는 Scrum과 같은 프레임워크의 기반이 되었습니다.
애자일은 제대로 작동하는 소프트웨어를 개발하는 것에 초점을 맞추어야 하며 효율적으로 소통하고 협업하는 사람들이 그 목표를 달성하는 데 중심적인 역할을 한다는 것을 인지합니다. 애자일 접근법은 소프트웨어가 요구사항이 결정되고 사용자의 필요나 상황이 중대하게 바뀔 수도 있는 수 년 뒤에나 소프트웨어가 전달되는 폭포수 방식의 긴 소요 시간에 대한 해법으로 개발되었으며, 요구사항 변경도 문제 없이 받아 들이는 접근법입니다.
애자일 프레임워크와 방법론은 반복적인 작업, 작동하는 소프트웨어의 작은 부분을 정기적으로 전달, 피드백 수집 및 대응에 대한 적응을 중심으로 합니다. 이는 설계, 개발, 테스트 및 릴리스를 선형적인 단계로 작업하던 폭포수 접근법과는 크게 다릅니다.
DevOps 이해하기
개발 팀들이 애자일 원칙을 수용함으로써 소프트웨어 개발 접근법을 크게 바꾸는 동안 하위 프로세스에서 팀들이 협업을 적게 하는 경향이 있었습니다.
인프라를 관리하고 소프트웨어를 라이브로 배포하는 운영팀과 코드를 작성하는 개발자들과는 전혀 다른 방식이나 언어로 작업하는 것이 드물지 않았습니다.
자신의 팀 내에서는 개발자들이 좀 더 효율적으로 작업할 수 있었지만 빌드가 운영팀에 전달되어 스테이징으로 배포되면 프로세스에 병목이 종종 발생했습니다. 사라진 종속성, 환경 구성 이슈, 개발자의 로컬 시스템에서 재현할 수 없는 버그 등으로 인해 여러 팀이 시간을 낭비하고 누가 책임을 지고 문제를 고쳐야 하는지 논쟁을 했습니다.
이런 일은 종종 폭포수 릴리스 전략과 결부되었습니다. 변경 사항이 점진적으로 개발팀에 의해 전달되었지만, 그 이후에는 변경 사항을 변경사항을 일괄적으로 낮은 빈도수의 큰 릴리스로 전달하였고, 이는 사용자들로부터 빠르게 피드백을 받을 수 없게 하였습니다.
문화 변경
"개발"과 "운영"을 결합하는 용어인 DevOps는 효율적으로 작동하는 소프트웨어를 전달하기 위해 양 팀의 활동을 효율적으로 통합할 필요성을 강조합니다. 따라서 범위는 이러한 기능에 국한되지 않습니다. 소프트웨어 개발과 전달에 포함된 모든 과정은 사용자에게 작동하는 소프트웨어를 전달한다는 목표에 따라 조율되어야 합니다.
DevOps의 중심에는 공통의 책임, 상호 신뢰 및 열린 소통의 문화가 있습니다. 로컬 빌드에서 작동한다고 개발 팀이 작업을 완료 처리하는 것만으로는 충분하지 않습니다. 개발자들이 프로덕션 준비가 된 코드를 전달하려면 릴리스까지의 과정을 볼 수 있어야 합니다. 이는 부서간의 장벽을 허물고 품질 보증팀, 보안 및 인프라팀과 협업하여 프로세스에서 해당 팀의 과정을 이해하는 것을 의미합니다.
DevOps 도구 및 자동화
수동 프로세스로도 팀 간의 긴밀한 협력을 이룰 수 있지만 최대한 많은 작업을 자동화해 주는 도구를 사용하면 훨씬 효율적입니다. 빌드, 테스트 및 배포 절차를 자동화하면 작업이 더욱 빨라지고 이러한 과정의 결과가 더욱 빨리 나오게 됩니다. 품질을 높이고 낭비를 줄이는 데 핵심적인 타이트한 피드백 루프를 가능하게 하는 자동화는 DevOps에서 중심적인 역할을 합니다.
효율적인 프로세스
DevOps는 Lean 생산 원칙이 소프트웨어 개발에 적용되던 시기에 대두되었습니다. Lean은 프로세스의 각 단계에서 낭비를 줄이고, 품질을 높이며 사람을 존중하는 데 집중합니다.
DevOps는 이러한 사고 방식의 대부분을 포함하며 종단간 프로세스를 최적화하고 빠른 피드백 루프로 빌드되고 있는 소프트웨어에 대한 피드백을 최대한 빠르게 제공함으로써 소프트웨어 개발의 효율화를 도모합니다.
여기에는 초기에는 개발 상의 하위 활동을 빠르게 하고 이러한 작업에 기인하는 테스트 실패, 보안 취약점 혹은 빌드 문제와 같은 이슈를 발생하는 대로 최대한 빨리 해결하는 것이 포함됩니다.
사용자에게 소프트웨어를 전달하는 책임을 모두가 공유하기 때문에 지금까지 해왔던 것처럼 "내 컴퓨터에서는 되는데"라며 대응하는 것은 충분하지 않습니다. DevOps 접근법에서 개발자는 소프트웨어가 어떻게 활용되며 어떤 문제가 발생하는지 더 높은 수준의 가시성에서 파악할 수 있기 때문에 문제를 수정하기도 용이합니다.
DevOps를 채택하면 개발팀 이외의 팀에서도 애자일의 이점을 누릴 수 있습니다. 개발자의 작업 속도에 맞추고 작은 단위의 작업을 수행하면 변수가 줄어들므로 문제를 식별하고 분리시키기 쉬워집니다. 이와 유사하게 피드백을 빠르게 생성하면 테스트나 추후에 포기되는 빌드를 스테이징하며 시간을 낭비하는 경우를 피할 수 있습니다. 이는 조직 전체에서 작은 단위로 작업하는 것의 이점을 온전히 누릴 수 있게 합니다.
DevOps 실전 적용
자동화된 CI/CD 파이프라인을 만들면 이러한 DevOps 목표를 실전에 적용할 수 있습니다.
자주 커밋하는 지속적인 통합 관행은 파이프라인 내에서 빠르게 처리되는 작은 배치 사이즈를 권장합니다. 자동화된 빌드 및 테스트 시스템은 수동 프로세스보다 훨씬 빠르게 각 변경 사항을 검증하고 피드백을 제공합니다.
개발자가 작성한 코드에 대한 피드백을 빠르게 제공받는다면 변경 사항의 맥락을 놓칠 가능성이 낮아지므로 효율성이 높아지며 Lean에서 말하는 "흐름"을 유지할 수도 있습니다. 빈번한 자동화 테스팅 또한 버그를 빠르게 발견하고 수정함으로써 그 위에 다른 코드가 작성되는 것을 방지함으로써 품질을 개선하는 데 도움을 줍니다.
프리프로덕션 서버에 대한 배포를 자동화하면 프로세스가 일정해지고 신뢰할 수 있게 되면서 스테이징 환경을 테스트 및 피드백을 위해 더욱 활용할 수 있습니다. 변경사항을 크고 빈도수가 낮은 릴리스로 제공하는 것보다는 작은 변경사항을 프로덕션에 주기적으로 배포하면 조합되어 의도하지 않은 결과를 초래할 변수가 줄어들기 때문에 라이브 환경에서 문제가 발생하는 리스크가 줄어듭니다.
실제로 버그가 발생해도 배치 사이즈가 작기 때문에 버그를 분리하고 수정하는 것이 더욱 빠릅니다. 점진적으로 업데이트를 릴리스하면 사용자들에게 정기적으로 가치를 제공하면서 이런 변경사항에 대한 피드백을 이용해서 다음에 무엇을 만들지에 대한 정보를 얻고 지속적으로 제품을 개선할 수 있습니다.
결론
CI/CD와 DevOps의 일반적인 목표는 품질을 낮추지 않으면서도 가치있는 소프트웨어를 전달하는 과정을 더욱 빠르게 하는 것입니다. DevOps 원칙은 애자일 및 Lean 원칙을 보완하면서도 겹치는 부분도 있습니다. 소프트웨어 개발 과정 전체를 보고 각 단계를 최적화하면 소프트웨어를 더 빨리 전달하고 피드백을 신속하게 얻을 수 있기 때문에 지속적인 개발 및 개선의 사이클이 가능해집니다.