DevOps란 무엇인가요?

기존 소프트웨어 개발 모델에서는 개발자가 새로운 기능, 제품, 버그 수정 등을 위해 대량의 코드를 작성한 다음, 보통 자동화된 티켓팅 시스템을 통해 운영팀에 작업을 전달하여 구축합니다. 운영팀은 이 요청을 대기열에 접수하고 코드를 테스트한 후 프로덕션에 사용할 수 있도록 준비하는데, 이 과정은 며칠, 몇 주 또는 몇 달이 걸릴 수 있습니다. 이러한 기존 모델에서는 구축 중에 문제가 발생하면 팀에서 개발자에게 티켓을 보내 무엇을 수정해야 하는지 알려줍니다. 결국 이 문제가 해결되고 나면 워크로드가 프로덕션으로 푸시됩니다.

이 모델은 소프트웨어 배포를 길고 단편적인 프로세스로 만듭니다. 개발자는 종종 운영을 장애물로 인식하여 프로젝트 일정을 늦추는 반면, 운영팀은 개발 문제가 발생하는 장소처럼 느껴집니다.

DevOps는 전체 소프트웨어 배포 프로세스 전반에 걸쳐 개발 팀과 운영 팀을 통합하여 문제를 조기에 발견 및 해결하고, 테스트 및 구축을 자동화하며, 출시 시간을 단축함으로써 이러한 문제를 해결합니다.

DevOps가 무엇인지 더 잘 이해하기 위해 먼저 DevOps가 아닌 것을 이해해 보겠습니다.

 

DevOps는 아닙니다.

  • 개발팀과 운영팀의 조합입니다: 여전히 두 개의 팀이 있으며, 소통하고 협업하는 방식으로 운영됩니다.
  • 별도의 팀이 있습니다: "DevOps 엔지니어"라는 것은 존재하지 않습니다. 일부 기업에서는 DevOps 문화로 전환할 때 파일럿으로 DevOps 팀을 지정할 수 있지만, DevOps는 전체 소프트웨어 배포 수명 주기 동안 개발자, 테스터 및 운영 담당자가 협력하는 문화를 의미합니다.
  • 도구 또는 도구 세트입니다: DevOps 모델과 잘 작동하거나 DevOps 문화를 촉진하는 데 도움이 되는 도구가 있긴 하지만 DevOps는 궁극적으로 도구가 아니라 전략입니다.
  • 자동화: 자동화는 DevOps 문화에 매우 중요하지만, 자동화만으로는 DevOps를 정의할 수 없습니다.

 

DevOps 정의

개발자가 방대한 기능 세트를 코딩한 후 무턱대고 운영팀에 넘겨 구축하는 대신 DevOps 모델에서는 개발자가 지속적인 테스트를 위해 소량의 코드를 제공하는 경우가 많습니다. 티켓팅 시스템을 통해 문제와 요청을 전달하는 대신 개발팀과 운영팀이 정기적으로 만나 분석을 공유하고 프로젝트를 엔드투엔드로 공동 소유합니다.

 

CI/CD 파이프라인

DevOps는 지속적 통합 및 지속적 배포(또는 지속적 구축)의 주기로, CI/CD 파이프라인이라고도합니다. CI/CD 파이프라인은 개발팀과 운영팀을 통합하여 인프라 및 워크플로를 자동화하고 애플리케이션 성능을 지속적으로 측정함으로써 생산성을 향상시킵니다. 다음과 같이 보입니다:

 

CI/CD 파이프라인의 단계 및 DevOps 워크플로
그림 1: CI/CD 파이프라인의 단계 및 DevOps 워크플로
  • 지속적인 통합을 위해서는 개발자가 자동화된 테스트를 위해 하루에 여러 번 코드 리포지토리에 코드를 통합해야 합니다. 각 체크인은 자동화된 빌드를 통해 확인되므로 팀에서 문제를 조기에 발견할 수 있습니다.
  • 지속적 배포와 혼동하지 마세요. 지속적 배포는 CI 파이프라인이 자동화되어 있지만 프로덕션에서 구현되기 전에 수동 기술 점검을 거쳐야 한다는 것을 의미합니다.
  • 지속적구축은 지속적 배포를 한 단계 더 발전시킵니다. 수동 검사 대신 자동화된 테스트를 통과한 코드가 자동으로 구축되어 고객이 새로운 기능을 즉시 이용할 수 있습니다.

 

DevOps 및 보안

DevOps의 한 가지 문제점은 보안이 종종 허점을 드러낸다는 점입니다. 개발자는 빠르게 움직이고 워크플로가 자동화됩니다. 보안은 별도의 팀이며 개발자는 보안 확인 및 요청을 위해 속도를 늦추고 싶지 않습니다. 그 결과 많은 개발자가 적절한 보안 채널을 거치지 않고 구축을 진행하며, 필연적으로 해로운 보안 실수를 저지르게 됩니다.

 

이를 해결하기 위해 조직에서는 DevSecOps를도입하고 있습니다. DevSecOps는 개발자와 IT 팀이 소프트웨어 배포 전반에 걸쳐 따로따로 일하는 것이 아니라 긴밀하게 협력해야 한다는 DevOps의 개념을 보안으로 확장하여 전체 CI/CD 파이프라인에 자동화된 검사를 통합합니다. 이렇게 하면 보안이 외부의 힘처럼 보이는 문제를 해결하고 개발자가 데이터 보안을 손상시키지 않으면서도 속도를 유지할 수 있습니다.

 

DevOps FAQ

코드형 인프라(IaC)는 기계 판독이 가능한 정의 파일을 통해 IT 인프라를 관리하고 프로비저닝하는 것을 포함합니다. Terraform 및 AWS CloudFormation과 같은 IaC 플랫폼은 인프라 설정을 자동화하여 일관되고 반복 가능한 구축이 가능하도록 지원합니다. 인프라를 소프트웨어로 취급함으로써 조직은 인프라 변경에 버전 제어, 테스트 및 지속적인 통합 관행을 적용하여 민첩성과 안정성을 향상시킬 수 있습니다.
지속적 통합(CI)은 개발자가 코드 변경 사항을 중앙 리포지토리에 자주 병합하여 자동화된 빌드 및 테스트를 트리거하는 개발 관행입니다. CI는 통합 오류를 최대한 빠르게 감지하여 소프트웨어 품질을 향상하고 새로운 업데이트를 제공하는 시간을 단축합니다. 이는 프로덕션 환경에 애플리케이션을 지속적으로 배포하기 위한 기반을 형성합니다.
지속적 배포(CD)는 빌드 단계 이후 모든 코드 변경 사항을 테스트 또는 프로덕션 환경에 자동으로 구축하여 지속적 통합을 확장합니다. CD를 사용하면 개발자는 코드를 항상 구축 가능한 상태로 유지하여 최종 사용자에게 보다 원활하고 신속하게 제공할 수 있습니다. 개발과 운영 간의 격차를 해소하여 보다 민첩하고 대응력이 뛰어난 소프트웨어 수명 주기를 촉진합니다.
지속적인 구축은 수동 개입 없이 검증된 변경 사항을 프로덕션에 자동으로 릴리스하는 것입니다. 이는 생산 파이프라인의 모든 단계를 통과하는 모든 변경 사항을 고객에게 릴리스하는 지속적 배포를 넘어서는 단계입니다. 이러한 관행은 피드백 루프를 가속화하고 릴리스 프로세스의 효율성과 안정성을 향상시킵니다.
자동화는 미리 정의된 명령을 실행하여 사람의 개입 없이 작업을 관리하는 방식으로 작동합니다. 클라우드 보안에서 자동화 도구는 정책을 구축하고, 취약성을 검사하고, 위협에 대응하여 보안 운영을 간소화합니다. 스크립트 및 워크플로를 사용하여 클라우드 API와 상호 작용하여 리소스를 프로비저닝하고 규정 준수를 시행하며 복잡한 프로세스를 효율적으로 오케스트레이션합니다.
구성 관리는 시스템을 원하는 일관된 상태로 유지하는 것을 말합니다. 소프트웨어 및 하드웨어의 변경 사항과 구성을 추적하여 이동 및 무단 변경을 방지합니다. Ansible, Puppet, Chef와 같은 도구는 IT 환경 전반에서 구성 변경을 자동화하여 시스템이 정확하고 균일하게 구성되도록 보장합니다.
오케스트레이션은 여러 시스템과 서비스에서 복잡한 작업과 워크플로 관리를 자동화합니다. 자동화된 작업을 일관된 프로세스로 조정하여 상호 의존성을 관리하고 작업 순서를 지정합니다. 클라우드 환경에서 Kubernetes와 같은 오케스트레이션 도구는 컨테이너화된 애플리케이션을 관리하고 구축, 확장, 네트워크를 처리하여 리소스 활용을 최적화하고 애플리케이션 성능을 유지합니다.
마이크로서비스는 애플리케이션이 잘 정의된 API를 통해 통신하는 소규모의 독립적인 서비스로 구성되는 디자인 접근 방식입니다. 각 서비스는 단일 비즈니스 기능에 초점을 맞추고, 자체 프로세스를 실행하며, 독립적으로 구축할 수 있습니다. 이 아키텍처는 확장성을 향상하고 개발 주기를 단축하며 결함 격리를 개선합니다.
모니터링과 로깅은 클라우드 환경에서 운영 성능과 보안을 유지하는 데 매우 중요합니다. 모니터링은 인프라, 애플리케이션, 서비스에 대한 실시간 가시성을 제공하여 시스템 상태와 성능을 사전에 관리할 수 있도록 합니다. 로깅은 문제 해결, 포렌식 분석, 규정 준수 감사에 필수적인 이벤트와 데이터 포인트를 기록합니다. 이 두 가지를 함께 사용하면 인시던트를 신속하게 탐지하고 대응하여 지속적인 가용성과 보안을 보장할 수 있습니다.
버전 관리 시스템은 코드, 문서 또는 기타 정보 집합의 변경 사항을 추적하고 관리합니다. 개발 팀 간의 협업을 촉진하고 변경 내역을 유지하며 필요한 경우 이전 버전으로 되돌릴 수 있습니다. 버전 관리는 코드베이스를 관리하고, 충돌을 줄이고, 구축이 일관되고 추적 가능하도록 하는 데 있어 기본이 됩니다.
일반적인 구축 전략에는 두 개의 동일한 환경을 병렬로 실행하여 하나는 라이브 환경으로 사용하고 다른 하나는 새 버전을 호스팅하는 블루-그린 구축이 포함됩니다. Canary 릴리스는 대규모 구축 전에 소수의 사용자에게 점진적으로 변경 사항을 적용합니다. 롤링 업데이트는 이전 버전의 인스턴스를 새 버전으로 점진적으로 교체하여 다운타임과 위험을 줄입니다.
컨테이너화는 애플리케이션과 해당 종속성을 모든 컴퓨팅 환경에서 실행할 수 있는 컨테이너로 캡슐화합니다. 이 접근 방식은 가상 머신에 대한 가벼운 대안을 제공하여 개발, 테스트 및 프로덕션 환경 전반에서 효율성과 일관성을 제공합니다. 컨테이너화는 애플리케이션을 기본 인프라로부터 분리하여 애플리케이션의 구축, 확장, 관리를 간소화합니다.
Docker는 컨테이너를 사용하여 애플리케이션을 생성, 구축 및 실행하는 데 사용됩니다. 이를 통해 개발자는 모든 종속성이 있는 애플리케이션을 표준화된 단위로 패키지화할 수 있습니다. Docker는 컨테이너 이미지 구축, 컨테이너 오케스트레이션, 확장, 네트워크 등 컨테이너의 수명 주기를 관리할 수 있는 도구와 플랫폼을 제공합니다.
컨테이너화된 애플리케이션을 오케스트레이션하여 구축, 확장 및 운영을 관리합니다. 애플리케이션의 원하는 상태가 클라우드 환경의 실제 상태와 일치하는지 확인합니다. Kubernetes는 로드 밸런싱을 자동화하고, 애플리케이션 상태를 모니터링하며, 실패하거나 응답하지 않는 컨테이너를 다시 시작하거나 교체하여 자가 복구 기능을 제공합니다. 또한 서비스 검색을 처리하고 구성 및 민감한 정보를 비밀로 관리할 수 있습니다.
빌드 파이프라인은 코드 컴파일, 테스트 실행, 소프트웨어 구축을 위한 일련의 자동화된 프로세스로 구성됩니다. 버전 관리에서 코드 검색부터 시작하여 실행 파일 빌드, 자동화된 테스트 실행, 다양한 환경에의 구축으로 이어집니다. 파이프라인은 각 단계에서 피드백을 제공하여 코드 품질을 보장하고 개발에서 프로덕션에 이르는 과정을 간소화하도록 설계되었습니다.
테스트 자동화를 통해 소프트웨어 기능, 보안 및 성능의 검증을 가속화할 수 있습니다. 수작업 없이도 반복적이고 광범위한 테스트가 가능하므로 일관성과 적용 범위가 향상됩니다. 자동화된 테스트는 여러 환경과 기기에서 동시에 실행할 수 있으므로 개발자에게 빠른 피드백을 제공하고 새 릴리스의 출시 시간을 단축할 수 있습니다.
코드 리포지토리는 코드 및 관련 파일을 저장하는 위치로, 버전 관리와 협업을 용이하게 합니다. 코드베이스의 변경 사항을 저장, 추적 및 관리하기 위한 중앙 허브 역할을 합니다. 리포지토리는 브랜칭 및 병합을 지원하므로 개발자는 변경 사항을 메인 코드에 통합하기 전에 격리된 환경에서 기능, 수정 또는 실험 작업을 할 수 있습니다.
릴리스 관리에는 다양한 단계와 환경에서 소프트웨어 빌드를 계획, 예약 및 제어하는 것이 포함됩니다. 여기에는 릴리스 파이프라인 관리, 이해관계자와의 조정, 릴리스 기준 준수 보장, 프로덕션에 소프트웨어 구축이 포함됩니다. 이 프로세스는 서비스 중단을 최소화하면서 새로운 기능과 수정 사항을 안정적이고 효율적으로 제공하는 것을 목표로 합니다.
애자일 방법론은 반복적인 개발, 고객 협업, 변화에 대한 대응을 강조합니다. 소규모의 점진적 릴리스, 지속적인 피드백, 적응형 계획을 옹호합니다. 애자일 원칙은 부서 간 팀 협업, 지속 가능한 개발 속도, 성찰적 관행을 통해 프로세스와 제품을 지속적으로 개선하도록 장려합니다.
서버리스 아키텍처를 통해 개발자는 서버 인프라를 관리하지 않고도 애플리케이션을 빌드하고 실행할 수 있습니다. 서버를 추상화하여 개발자는 코드 작성에만 집중할 수 있습니다. 클라우드 공급자는 실행 환경을 관리하여 리소스 할당을 동적으로 관리합니다. 서버리스 아키텍처는 수요에 따라 자동으로 대규모로 확장되며, 사용자는 사용한 컴퓨팅 시간만큼만 비용을 지불합니다.
성능 튜닝에는 응답 시간, 처리량, 리소스 사용량 등의 성능 지표를 개선하기 위해 시스템 설정과 코드를 최적화하는 작업이 포함됩니다. 애플리케이션을 프로파일링하고 모니터링하여 병목 현상을 파악한 다음, 구성을 조정하고 코드를 최적화하며 효율적인 리소스 할당을 통해 전반적인 시스템 효율성을 향상시켜야 합니다.
서비스 중단 없이 장애를 처리하고 복구할 수 있는 내결함성 시스템 설계를 통해 복원력과 안정성을 보장합니다. 이중화, 장애 조치 메커니즘, 재해 복구 절차의 정기적인 테스트, 실시간 모니터링을 구현하면 시스템 아키텍처를 견고하게 구축할 수 있습니다. 이러한 관행은 시스템 스트레스나 예기치 않은 문제에도 일관된 성능과 가용성을 유지하는 데 도움이 됩니다.