DevOps 이해

‘DevOps’는 ‘development(개발)’와 ‘operations(운영)’가 합쳐진 단어이지만, 단순히 각각의 용어를 결합한 것 이상의 포괄적인 아이디어와 방식을 나타냅니다. DevOps에는 보안, 협업 방식, 데이터 분석을 비롯해 기타 여러 요소가 포함됩니다. 그렇다면 DevOps가 구체적으로 무엇을 의미하는 것일까요?

DevOps는 새로운 소프트웨어 기능, 개선 요청 또는 버그 수정 등 하나의 아이디어가 개발에서 배포에 이르는 프로세스의 속도를 높임으로써 더 빨리 프로덕션 환경에 전달되어 사용자에게 가치를 전달하도록 합니다. 이러한 접근 방식을 적용하려면 개발 팀과 운영 팀이 자주 커뮤니케이션하고 팀원들과 공감하면서 업무에 접근해야 합니다. 확장성과 유연한 프로비저닝도 필요합니다. DevOps를 확립하면 셀프 서비스와 자동화를 통해 다양한 이점과 경쟁력을 얻을 수 있습니다. 대개 표준 개발 환경에서 코딩 작업을 하는 개발자는 IT 운영 담당자와 긴밀하게 협력하여 소프트웨어 빌드, 테스트, 출시 속도를 가속화할 수 있습니다.

이는 곧 코드 변경도 더 빈번해지고 인프라도 보다 역동적으로 사용해야 한다는 의미입니다. 전통적인 관리 전략은 이러한 종류의 요구를 충족할 수 없으므로, 경쟁력을 강화하려면 몇 가지 변화가 필요합니다.

DevOps는 아이디어 개발에서 배포에 이르는 프로세스를 가속화합니다. 그 중심에서 DevOps는 애플리케이션 라이프사이클 전반에서 일상적인 운영 태스크 자동화와 환경 표준화를 사용합니다. 컨테이너는 표준화된 환경을 제공할 수 있으나 이를 관리하기 위해서는 모든 인프라에 대한 지원 및 빌트인 자동화를 제공하는 플랫폼이 필요합니다. Red Hat OpenShift 4는 DevOps 이니셔티브를 지원하기 위한 엔터프라이즈급 쿠버네티스 플랫폼입니다.

DevOps는 오픈소스 원칙에 부합하는 협업 문화와 투명한 애자일 접근 방식을 활용합니다. 5일 동안 진행되는 마스터 강의인 DevOps Culture and Practice Enablement(DO500)에서 DevOps와 애자일 가치가 서로 어떻게 밀접한 관련을 맺고 있는지 자세히 살펴볼 수 있습니다.

오픈소스 소프트웨어 프로젝트의 문화는 DevOps 문화를 구축하기 위한 청사진으로 볼 수 있습니다. 자유로운 정보 공유는 오픈소스 커뮤니티에서의 협업에 대한 기본적인 접근 방식입니다. 이를 통해 의사 결정 과정에서 투명성을 높이거나, 실패에 대한 두려움을 없앰으로써 실험적인 프로젝트를 권장하거나, 신뢰와 협업을 장려하는 보상 시스템을 구현하는 등의 기업 문화의 변화를 이끌어낼 수 있습니다. 많은 조직에서 이러한 유형의 이니셔티브를 지원하기 위한 디지털 트랜스포메이션 컨설팅 서비스를 찾고 있습니다.

올바른 리더십과 인센티브 프로그램을 제공하면 개발 및 운영 팀이 열린 문화를 적극적으로 조성하는 데 도움이 될 수 있습니다. 그러나 이 문화가 조직 전체에 확산될 때 DevOps의 효과가 가장 크게 나타납니다. DevOps라는 명칭은 개발과 운영을 지칭하지만 DevOps는 모두를 위한 것입니다.

Red Hat의 기업 문화는 개방성과 투명성을 기반으로 하며 25년 이상 동안 성공적으로 지속되고 있습니다. 고객이 개방적인 접근 방식을 채택하여 DevOps의 구현을 통해 성과를 획득하도록 지원합니다.

현대적인 애플리케이션을 개발하려면 과거의 접근 방식과는 다른 프로세스가 필요합니다. 소프트웨어 개발에 애자일 접근 방식을 적용하는 많은 팀들이 가장 먼저 고려하는 사항이 바로 DevOps입니다. 실제로, ‘신속하고 지속적인 소프트웨어 제공을 통한 고객 만족’은 애자일 선언문(Agile Manifesto)의 12가지 원칙 중 첫 번째 원칙입니다. 이는 CI/CD(지속적인 통합 및 연속 배포)가 DevOps 팀에 매우 중요한 이유이기도 합니다.

그러나 개발 및 운영 프로세스를 변경하는 것만으로는 충분하지 않습니다. 소프트웨어 제공 방식을 실질적으로 최적화할 수 있도록 고안된 시스템을 적용해야 합니다. 이는 DevOps가 개발 작업을 요청하는 사업부와 최종 사용자를 지원하는 그룹에 변화를 가져온다는 의미입니다. 무엇보다도 최종 사용자가 비즈니스에 지속적으로 피드백을 제공하는 것이 중요합니다.

현재 작업 수행 방식을 넘어서는 프로세스 변경이 필요함에 따라, 수행하는 작업도 변경될 수밖에 없습니다. DevOps는 기존의 동일한 모놀리식 소프트웨어의 개발을 가속화하는 것뿐 아니라 이러한 지속적인 개발 흐름에 더욱 적합한 새로운 종류의 소프트웨어를 개발하는 것과 관련이 있습니다.

이런 이유로 DevOps 팀이 마이크로서비스 아키텍처를 사용하여 소프트웨어를 구축하고 API로 이러한 서비스를 함께 연결하는 경우가 많습니다. DevOps 팀이 각각의 기능을 더 작은 단위로 구축함으로써 서비스를 보다 신속하게 제공 가능하므로 이러한 서비스와 API가 관리되는 방식에 중점을 두고 이 모두를 통합할 수 있는 애자일 통합과 같은 전략을 수립해야 합니다.

이러한 변화는 많은 노력을 필요로하지만 적절한 기술을 사용한다면 지금 바로 시작할 수 있습니다. 자동화를 활용한다면 프로세스를 가속화할 수 있으며, 최종적으로는 DevOps 워크로드를 클라우드로 마이그레이션할 수 있습니다. IDC 연구¹ 결과에 따르면 IT 리더의 85%가 DevOps 전략에 있어 자동화가 매우 중요하다고 말합니다. 그 이유는 자동화를 도입할 경우 DevOps에 수반되는 지속적인 코드 변경을 인프라가 견딜 수 있기 때문입니다. 또한 환경을 손쉽게 지속적으로 확장할 수 있다는 장점도 있습니다. 자동화는 반복적인 작업이나 단순 작업의 부담을 경감함으로써 기업의 우수한 인력이 가장 중요한 업무에 집중할 수 있는 환경을 조성합니다.

Red Hat 전문가가 고객이 조직 차원에서 더 효율적으로 기존 애플리케이션을 현대화하고 새로운 애플리케이션을 구축하는 데 필요한 사례와 툴을 개발하고 문화를 조성하도록 지원합니다.

프로세스를 지원하는 툴을 선택하는 것은 DevOps 성공의 열쇠입니다. 운영 팀이 빠른 개발 주기와 속도를 맞추려면 상당히 유연한 플랫폼을 사용하고 개발 팀이 코드를 다루는 방식과 마찬가지로 인프라를 다뤄야 합니다. 수동 배포는 속도가 느리며 오류가 발생할 가능성이 있습니다.

자동화를 통해 플랫폼 프로비저닝과 배포를 간소화할 수 있습니다. 사이트 신뢰성 엔지니어링(SRE)은 수동 운영 태스크를 가져와서 소프트웨어 및 자동화를 사용해 관리합니다. SRE 접근 방식을 사용하면 DevOps 팀의 목표를 달성하기가 더 쉬워집니다.

컨테이너를 사용하면 개발, 테스트, 프로덕션 환경 사이에서 애플리케이션을 보다 쉽게 이동할 수 있습니다. 또한 개발자는 컨테이너를 사용하여 애플리케이션과 실행에 필요한 모든 요소(애플리케이션 파일, 런타임 환경, 종속 라이브러리 및 설정)를 패키징하고 분리할 수 있습니다.

DevOps 접근 방식은 Linux® 컨테이너와 긴밀히 연계되며, 개발 팀은 이를 통해 클라우드 네이티브 개발 방식에 필요한 기반 기술을 얻게 됩니다. 컨테이너는 개발, 배포, 통합, 자동화를 위한 통합 환경을 지원합니다.

또한 쿠버네티스는 Linux 컨테이너 운영을 자동화할 수 있는 현대적인 방법입니다. 쿠버네티스를 활용하면 퍼블릭, 프라이빗 또는 하이브리드 클라우드 전반에서 Linux 컨테이너를 실행 중인 클러스터를 손쉽게 효율적으로 관리할 수 있습니다.

컨테이너 내외부에서 모두 Red Hat® Enterprise Linux 및 Red Hat OpenShift®와 같은 신뢰할 수 있는 플랫폼을 선택하면 가장 필요한 순간에 실패 없이 확장과 자동화를 수행할 수 있습니다. 적절한 플랫폼을 보유한 기업은 DevOps 문화와 프로세스 변경에 따르는 장점을 최대한 누릴 수 있게 됩니다.

DevOps 구현의 주요 성과는 지속적인 통합 및 지속적인 배포(CI/CD) 파이프라인입니다 . CI/CD를 통해 고객에 대한 애플리케이션 제공 주기를 단축하고 인적 개입을 최소화하여 소프트웨어의 품질을 검증할 수 있습니다.

특히, CI/CD는 애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화와 지속적인 모니터링을 제공하여, 신속하게 문제 및 결함을 식별하고 수정합니다. 이러한 구축 사례를 일반적으로 “CI/CD 파이프라인“이라 부르며 개발 및 운영 팀의 애자일 방식 협력을 통해 지원됩니다.

앞에서 언급했듯이 DevOps는 단순히 개발 및 운영 팀에 관한 것이 아닙니다. DevOps 접근 방식을 최대한 활용하기 위해서는 보안이 애플리케이션의 라이프사이클에서 어떤 역할을 하는지 고려해야 합니다. 즉, 계획 단계에서부터 핵심 보안에 대해 생각해야 합니다. 이는 또한 DevOps 워크플로우의 속도가 저하되지 않도록 일부 보안 기능을 자동화해야 한다는 의미이기도 합니다. 보안 기능을 통합할 수 있는 올바른 툴을 선택하면 DevOps 보안 목표 달성을 지원할 수 있습니다.

그러나 효과적인 DevOps 보안을 위해서는 단순히 새로운 툴만으로는 부족합니다. 보안 팀의 작업을 통합하기 위해서는 DevOps의 문화적 변화를 기반으로 DevOps 보안을 구축해야 합니다. DevOps는 개발과 운영 간의 격차를 해소하여 프로세스를 가속화하고 있지만 비효율적인 보안 계획으로 인해 프로세스 가속화로 인한 이점을 누리지 못할 수 있습니다.

보안은 별도의 팀의 독자적인 책임으로 간주되어 개발의 마지막 단계에만 적용되는 것이었습니다. 하지만 협업을 중시하는 DevOps 프레임워크에서 보안은 초기 단계부터 통합되어 공동의 책임이 됩니다.