기술이야기 | 브레인즈컴퍼니

메인 페이지로 이동
블로그
기술이야기

블로그

DevOps(1)

양관진 2023.02.07

DevOps(데브옵스)의 정의

오늘날 DevOps는 소프트웨어 개발 및 운영을 위한 모범 사례로 널리 채택돼 인정받고 있으며, 많은 조직의 디지털 트랜스포메이션 전략에서 필수적인 부분이 됐습니다. DevOps는 지속적 통합, 지속적 테스트, 지속적 배포, 컨테이너와 같은 새로운 기술을 받아들여 발전했으며, 많은 조직의 클라우드 컴퓨팅 및 디지털 제품 전략의 중요한 구성 요소가 됐습니다.

그렇다면 DevOps는 무엇일까요?

DevOps는 소프트웨어를 빠르고 효율적으로 제공하기 위해 개발과 운영팀 간의 협업과 커뮤니케이션을 강조하는 소프트웨어 개발 방법론입니다. DevOps의 목표는 협력하는 문화와 부서 간 팀워크를 조성해 개발과 운영 간의 격차를 해소하는 것입니다. DevOps란 소프트웨어 개발(Dev)과 운영(Ops)의 합성어 입니다. 합성된 단어 의미처럼 개발 기능과 운영기능을 합친 것이라고 받아 들일 수 있지만 그렇지 않습니다. 두 기능을 합치는 것보다 중요한 것은 두 기능의 생각의 차이를 극복하고 그 생각의 간격을 줄이는 것입니다.

DevOps는 철학적입니다. 원리만 있고 구체적인 방법은 각자 알아서 찾는 식입니다. 마치 ‘Agile 방법론’, ‘토요타 생산 시스템(TPS)’이나 ‘5S(Sorting, Shine, Set in Order, Sustain, Standardization)’와 비슷합니다. 관련 글 몇 개를 읽어봐도 어떻게 적용할지는 고사하고 무엇을 말하는지도 잘 모를 수 있습니다. DevOps는 소프트웨어를 빠르고 효율적으로 제공하기 위해 개발과 운영팀 간의 협업과 커뮤니케이션을 강조하는 소프트웨어 개발 방법론으로 개발 문화를 만들어가는 철학, 방법론, 기술을 총칭하기 때문입니다. 결국 조직, 서비스, 시장환경, 고객에 따라 각자 나름의 DevOps 방법을 찾아야 한다는 의미입니다.

Origin of DevOps

DevOps(데브옵스) 드보아의 4 area

DevOps는 대규모 소프트웨어를 빠르고 안정적으로 제공하는 데 있어 조직이 직면한 과제에 대한 대응책으로 2000년대 중반부터 개념을 주목 받았으며, 문화적 운동으로 시작했습니다. DevOps 초기에는 개발과 운영 팀 간의 협업과 커뮤니케이션을 개선해야 한다는 인식이 확산됐고, 소프트웨어 배포 파이프라인을 자동화하고 간소화하고자 하는 열망도 커졌습니다.

DevOps가 빠르게 발전하게 된 것은 클라우드 컴퓨팅과 가상화 기술의 등장으로 인프라를 더 쉽고 빠르게 프로비저닝하고 관리할 수 있게 됐다는 것, 그리고 기존의 조직이 수동적이고 시간이 많이 소요되는 프로세스에서 벗어날 수 있게 됐다는 점입니다. 이를 통해 코드형 인프라(infrastructure as code), 구성 관리(Configuration), 지속적 배포와 같은 DevOps의 조건을 채택할 수 있는 기반이 마련됐습니다. 또 다른 중요한 요인은 고객과 기업이 기술과 디지털 제품에 대한 의존도가 높아지면서 더 빠르고 빈번한 소프트웨어 릴리스에 대한 요구가 증가했다는 점입니다. 이로 인해 조직은 소프트웨어를 더 빠르게, 고품질로, 그러면서 더 적은 장애와 서비스 중단을 제공해야 한다는 압박을 받게 됐습니다. DevOps는 개발과 운영 팀 간의 협업, 커뮤니케이션 및 피드백 루프를 개선하고 소프트웨어 배포 파이프라인을 자동화 및 간소화하여 이러한 문제를 해결하는 것을 목표로 합니다.

반대로 DevOps 초창기에는 여러 시행착오도 있었습니다. 가장 큰 어려움 중 하나는 개발과 운영이 서로 다른 프로세스, 도구 및 목표를 가지고 각자 사일로에서 일하는 데 익숙했기 때문에 변화에 대한 문화적 및 조직적 저항이었습니다. 이러한 사일로를 허물고 팀 간의 협업과 커뮤니케이션을 장려하는 것은 조직이 극복해야 할 주요 장애물이었습니다. 또 다른 과제는 DevOps 개념이 아직 진화 중이고 조직에서 다양한 도구, 프로세스 및 방법론을 실험하고 있었기 때문에 표준화 및 Best practice가 부족하다는 것이었습니다. 이로 인해 DevOps를 구현하고 실행하는 방식에 혼란과 불일치가 발생했고, 조직에서 DevOps 이니셔티브의 성공을 비교하고 측정하기가 어려웠습니다. 또 다른 문제는 조직이 자동화 시스템을 구축 및 관리하고, 애플리케이션과 인프라를 모니터링하고, 시스템과 데이터를 보호하는데 돈을 써야 한다는 것이었습니다. 이를 위해서는 시간, 리소스 및 전문 지식이 필요했는데, 특히 소규모 조직에서는 어려운 문제였습니다.

이러한 어려움에도 불구하고 DevOps의 얼리 어답터들은 더 빠르고 빈번하게 소프트웨어를 릴리스 할 수 있고, 더 높은 품질 수준을 유지할 수 있으며, 장애로 인한 서비스 중단 이슈를 줄이는 이점을 얻을 수 있었습니다. 이로 인해 더 많은 조직이 DevOps를 채택하고 필요한 인프라, 도구 및 전문 지식에 투자하게 됐습니다.

DevOps vs Agile methodology

DevOps(데브옵스)와 Agile(애자일) 비교표

DevOps는 또 다른 소프트웨어 개발 방법론인 애자일과 자주 비교됩니다. DevOps와 애자일 모두 소프트웨어를 빠르고 효율적으로 제공하는 것을 목표로 하지만, DevOps는 한 단계 더 나아가 운영까지 개발 프로세스에 통합합니다. 이러한 통합을 통해 개발 팀과 운영 팀 간에 보다 원활한 협업과 빠른 피드백 루프가 가능합니다. DevOps와 애자일은 소프트웨어 개발 및 운영에 대한 서로 다른 두 가지 접근 방식으로, 각자의 목표, 원칙 및 방법론이 있습니다. 접근 방식은 다르지만 몇 가지 유사점이 있으며 서로를 보완할 수도 있다는 것이 중요합니다.

애자일은 개발의 유연성을 확보하고 고객과 협업을 통해, 문제없는 소프트웨어를 신속하게 제공하는 것을 우선하는 소프트웨어 개발 방법론입니다. 애자일은 느리고 경직되어 있으며 개발과 고객 간의 협업이 부족했던 전통적인 워터폴(waterfall) 모델을 개선하고자 하는 열망에서 탄생했습니다. 애자일 방법론에는 스크럼, 칸반, 린 등이 있습니다. 애자일 팀은 소프트웨어 개발에 대한 반복적이고 점진적인 접근 방식을 따르며, 고객에게 조금씩 자주 제품 개선을 제공하는 것을 목표로 합니다. 애자일 팀은 고객의 피드백을 우선시하고 그에 따라 계획과 요구 사항을 조정하며 팀워크, 협업 및 지속적인 개선에 높은 가치를 둡니다.

반면에 DevOps는 소프트웨어 배포 파이프라인을 자동화하고 모든 이해관계자 간의 협업, 커뮤니케이션 및 피드백 루프를 강화해 개발과 운영팀 간의 정보 및 지식 격차를 해소하는 것을 목표로 합니다. DevOps의 목표는 소프트웨어 배포의 속도, 품질 및 안정성을 높이는 동시에 장애 및 중단의 위험을 줄이는 것입니다. DevOps에는 지속적 통합과 지속적 배포(CI/CD), 지속적 배포, 코드형 인프라, 구성 관리(Configuration Management), 모니터링 및 로깅, 보안 및 테스트가 포함됩니다. DevOps 팀은 실험, 학습 및 지속적인 개선 문화를 채택하고 클라우드 컴퓨팅, 컨테이너, 마이크로서비스(MSA) 및 자동화와 같은 최신 기술과 도구를 활용하여 목표를 달성합니다.

요약하자면 애자일은 협업과 유연성을 통해 고객에게 가치를 제공하는 데 중점을 두는 반면, DevOps는 소프트웨어 제공의 속도와 품질을 개선하는 데 중점을 둡니다. 두 접근 방식은 지속적인 개선과 협업의 중요성과 같은 몇 가지 공통 원칙을 공유하지만 목표, 방법론 및 관행이 다릅니다.

실제로 DevOps와 애자일은 서로를 보완하고 함께 협력해 더 나은 결과를 달성할 수 있습니다. 예를 들어, 애자일 팀은 DevOps 실행방안을 채택해 소프트웨어 배포 파이프라인을 자동화하고 운영팀의 피드백 루프를 늘리며 장애 및 서비스 중단의 위험을 줄일 수 있습니다. 반면에 DevOps 팀은 애자일 원칙을 채택해 고객과 더 효과적으로 협업하고, 고객 피드백의 우선순위를 정하고, 더 자주 제품 개선을 제공할 수 있습니다.

결론적으로, 핵심은 DevOps와 애자일의 차이점과 유사점을 이해하고 속도, 품질, 안정성 및 고객 가치 사이에서 적절한 균형을 찾는 것입니다.

Principles of DevOps

DevOps의 핵심 원칙은 다음과 같이 요약할 수 있습니다:

l 협업 및 커뮤니케이션: DevOps는 개발팀과 운영팀 간의 협업과 커뮤니케이션을 촉진하여 사일로를 허물고 업무의 흐름을 개선합니다. 이를 통해 팀은 서로의 요구 사항을 더 잘 이해하고 공동의 목표를 달성하기 위해 협력할 수 있습니다.

l 자동화: 자동화는 프로세스를 간소화하고 수동 오류를 줄이며 효율성을 개선하는 데 도움이 되므로 DevOps의 핵심 요소입니다. 여기에는 자동화된 테스트, 배포 및 인프라 관리가 포함될 수 있습니다.

DevOps(데브옵스) 테스트 자동화 툴

l 지속적 통합 및 지속적 배포(CI/CD): DevOps는 소프트웨어 배포 프로세스를 자동화하기 위해 CI/CD 파이프라인을 사용하는 것을 강조합니다. 이를 통해 팀은 새 소프트웨어 업데이트를 빠르고 안전하게 테스트, 배포 및 릴리스할 수 있습니다.

l 코드형 인프라(IaC): IaC는 인프라를 코드로 관리해 인프라를 더 쉽게 자동화하고 관리할 수 있도록 하는 관행입니다. 이를 통해 인프라의 일관성, 반복성 및 버전 제어를 보장하는 데 도움이 됩니다.

l 모니터링 및 피드백: DevOps는 문제를 신속하게 식별하고 해결하기 위해 시스템 및 애플리케이션 모니터링의 중요성을 강조합니다. 여기에는 로깅, 알림 및 성능 모니터링은 물론 프로세스를 개선하기 위한 팀 간의 정기적인 피드백 루프가 포함됩니다.

l 문화적 변화: DevOps에는 기존의 계층 구조와 사일로를 허물고 팀이 협업과 지속적인 개선에 집중하는 문화적 변화가 필요합니다. 이를 위해서는 팀 간의 공감, 신뢰, 소유권 공유에 중점을 둬야 합니다.

l 린 원칙: DevOps는 린 제조 원칙에서 영감을 얻어 소프트웨어 개발 및 운영에 적용합니다. 여기에는 낭비를 최소화하고, 흐름을 개선하며, 프로세스를 지속적으로 학습하고 개선하는 데 초점을 맞추는 것이 포함됩니다.

l 보안: DevOps는 설계 및 개발부터 배포 및 운영에 이르기까지 소프트웨어 배포 프로세스의 모든 단계에 보안을 통합합니다. 이를 통해 소프트웨어의 보안을 유지하고 관련 규정 및 표준을 준수할 수 있습니다.

DevOps는 이러한 원칙을 준수함으로써 조직이 소프트웨어를 더 빠르고 안정적으로 배포하는 동시에 팀 간의 협업과 커뮤니케이션을 개선하는 데 도움이 됩니다. 이는 결국 고객 만족도 향상, 비용 절감, 경쟁력 강화로 이어질 수 있습니다.

결론적으로 DevOps는 개발과 운영 팀을 하나로 모으고, 프로세스를 자동화하며, 소프트웨어 배포 프로세스를 지속적으로 개선하는 것을 목표로 하는 소프트웨어 배포에 대한 포괄적인 접근 방식입니다. 이러한 원칙을 준수함으로써 조직은 소프트웨어 제품 및 서비스 제공의 효율성, 품질, 속도를 높여 비즈니스 성과를 개선할 수 있습니다.

Best Practice of DevOps, Netflix

DevOps를 성공적으로 구현한 조직의 실제 사례는 무수히 많습니다. 가장 주목할 만한 사례로는 Netflix, Amazon, Etsy 등이 있습니다. 이러한 기업들은 DevOps 실행을 통해 오류를 줄이면서 소프트웨어를 더 빠르게 배포할 수 있었습니다. 넷플릭스의 사례를 살펴 보겠습니다.

넷플릭스는 DevOps를 성공적으로 구현한 기업의 대표적인 예로 꼽힙니다. 넷플릭스는 DevOps를 도입해 고객에게 새로운 기능과 업데이트를 신속하게 제공할 수 있었으며, 이는 넷플릭스의 Key Success factor 였습니다.

넷플릭스는 여러 가지 방법으로 DevOps를 구현했습니다. 핵심 요소 중 하나는 넷플릭스의 클라우드 수용입니다. 클라우드 기술을 활용해 Netflix는 빠르게 증가하는 사용자 기반을 지원할 수 있는 확장성이 뛰어난 인프라를 구축할 수 있었습니다. 이를 통해 변화하는 고객 요구와 시장 상황에 신속하게 대응할 수 있었습니다. 또 다른 핵심 요소는 자동화에 집중했다는 점입니다. 넷플릭스는 많은 소프트웨어 개발 및 제공 프로세스를 자동화해 신속하고 효율적으로 움직일 수 있었습니다.

l 코드 빌드에서 배포를 자동화하는 CI/CD 파이프라인 구축

l IAC(Infrastructure as Code)로 인프라 리소스를 프로비저닝

l 인프라 리소스를 자동으로 추가하거나 제거하는 Auto-Scaling

l 로그 및 메트릭을 수집하고 분석해 빠른 문제해결과 사전 예방을 가능하게 하는 모니터링 및 로깅 자동화

이러한 자동화를 통해 Netflex는 소프트웨어 배포의 속도와 안정성을 높이고 엔지니어가 혁신 및 부가가치 활동에 집중할 수 있는 시간을 확보할 수 있었습니다.

넷플릭스는 또한 개발과 운영 팀 간의 협업과 커뮤니케이션에 중점을 두었습니다. 이러한 협업을 통해 소프트웨어 개발 과정에서 발생할 수 있는 모든 문제를 신속하게 파악하고 해결할 수 있었습니다. 또한 팀들이 더욱 효과적으로 협력하여 고객에게 새로운 기능과 업데이트를 제공할 수 있었습니다.

l 목표 공유, 목표에 대해 공통된 이해를 가지고 있으며 이를 달성하기 위해 협력

l 개발과 운영 팀 간 상호 존중

l 자동화된 프로세스와 도구를 사용, 워크플로 표준화

l 실시간 커뮤니케이션

l 문제 발생 시, 개인을 비난하기보다는 프로세스와 시스템을 개선하는 데 중점

마지막으로 넷플릭스는 문화에 중점을 뒀습니다. 실험과 빠른 반복을 중시하는 문화를 조성해 변화하는 고객 요구와 시장 상황에 빠르게 대응할 수 있었습니다. 이러한 혁신 문화는 넷플릭스가 DevOps를 성공으로 이끈 핵심 요소였습니다.

결론적으로 넷플릭스의 DevOps 성공은 클라우드 수용, 자동화에 대한 집중, 협업과 소통에 대한 강조, 혁신 문화에 대한 헌신 등 여러 요인이 복합적으로 작용한 결과라고 할 수 있습니다. 이러한 요소를 통해 고객에게 새로운 기능과 업데이트를 신속하게 제공할 수 있었으며, 이는 성공의 핵심 요인이 됐습니다.

DevOps Engineer

DevOps(데브옵스) 엔지니어

DevOps 엔지니어는 코딩, 인프라 관리, 시스템 관리 및 DevOps 도구 등 개발 및 운영에 대한 광범위한 지식을 갖춰야 하는 IT 전문가입니다. DevOps 엔지니어는 협업에 더 적합한 환경을 만들기 위해 대인 관계를 위한 커뮤니케이션 스킬을 보유해야 합니다. DevOps 엔지니어는 시스템 아키텍처 및 프로비저닝 뿐만 아니라, 소스 제어 사용, 코드 검토 주고받기, 단위 테스트 작성, 애자일 등 기존 개발자의 도구와 실행에 대한 경험도 있어야 합니다.

DevOps 엔지니어의 R&R

l 자동화: 반복적인 작업을 자동화하여 인적 오류를 줄이고 효율성을 개선합니다. Ansible, Puppet 또는 ITSM과 같은 도구를 사용하여 소프트웨어 및 인프라의 프로비저닝, 구성 및 배포를 자동화합니다.

l 지속적 통합 및 배포: 지속적 통합 및 배포 파이프라인을 설정하고 관리할 책임이 있습니다. 빌드, 테스트 및 배포 프로세스를 자동화하기 위해 Jenkins, Travis CI 또는 CircleCI와 같은 도구를 사용합니다.

l 모니터링 및 로깅: 모니터링 및 로깅 시스템을 설정하고 유지 관리할 책임이 있습니다. SMS, NMS 또는 APM와 같은 도구를 사용하여 시스템 및 애플리케이션의 성능과 상태를 모니터링하고, 로그매니저와 같은 도구를 사용하여 로그를 수집하고 분석합니다.

l 인프라 관리: 소프트웨어 제품을 지원하는 인프라를 설정하고 유지 관리할 책임이 있습니다. 이들은 Terraform, CloudFormation 또는 Ansible과 같은 도구를 사용하여 인프라 리소스의 프로비저닝 및 관리를 자동화합니다.

l 보안: 데브옵스 엔지니어는 소프트웨어와 인프라의 보안을 책임집니다. 시스템과 애플리케이션을 보호하기 위해 SELinux, AppArmor 또는 Seccomp와 같은 도구를 사용하고, 비밀을 관리하기 위해 Vault, Conjur 또는 CyberArk와 같은 도구를 사용합니다.

l 문제 해결: 소프트웨어 개발 및 운영 프로세스 중에 발생하는 문제를 해결하는 일을 담당합니다. 개발자, 운영팀 및 이해관계자와 협력하여 문제를 빠르고 효과적으로 진단하고 해결합니다.

DevOps 엔지니어링

l Scripting 및 Programming: 많은 작업을 자동화하고 소프트웨어 개발 및 운영 프로세스를 지원하는 도구를 구축해야 하므로 스크립팅 및 프로그래밍에 대한 탄탄한 배경 지식이 있어야 합니다.

l Cloud Computing: 많은 기업이 소프트웨어와 인프라를 클라우드로 이전하고 있으므로 클라우드 컴퓨팅에 대한 이해가 높아야 합니다. AWS, Azure 또는 GCP와 같은 클라우드 서비스 및 플랫폼에 익숙해야 하며, 클라우드 컴퓨팅의 보안, 네트워킹 및 스토리지 측면을 이해해야 합니다. 온프레미스 리소스 기업의 경우 데이터 센터의 물리적 서버, 스토리지, 스위치 및 가상화 소프트웨어 관리가 포함될 수 있습니다.

l OS: 다양한 시스템과 애플리케이션을 다루기 때문에 Linux, Unix 및 Windows에 익숙해야 하며 운영 체제의 보안, 네트워킹 및 스토리지 측면을 이해해야 합니다.

l Networking: 데브옵스 엔지니어는 소프트웨어를 지원하는 네트워크 인프라를 설정하고 유지 관리할 책임이 있으므로 네트워킹에 대한 이해도가 높아야 합니다. IP 네트워킹, DNS, DHCP, 라우팅의 기본 사항을 이해해야 합니다.

l 컨테이너화: 컨테이너가 소프트웨어를 패키징하고 배포하는 데 점점 더 널리 사용되고 있으므로 데브옵스 엔지니어는 컨테이너화에 대한 이해가 높아야 합니다. Docker, Kubernetes와 같은 컨테이너화 플랫폼에 익숙해야 합니다.

DevOps is Dead

DevOps의 많은 이점에도 불구하고 DevOps에도 도전 과제가 없는 것은 아닙니다. 가장 큰 도전 과제 중 하나는 변화에 대한 문화적 저항입니다. DevOps는 조직이 소프트웨어 개발 및 배포에 대해 생각하는 방식에 상당한 변화를 요구하는데, 일부 팀에서는 이를 수용하기 어려울 수 있습니다. 또한 DevOps 구현은 복잡하고 시간이 많이 소요될 수 있으며, 인력과 기술 모두에 상당한 투자가 필요합니다.

결론적으로 DevOps는 오늘날의 급변하는 비즈니스 환경에서 소프트웨어를 빠르고 효율적으로 제공하고자 하는 조직에게 매우 중요한 방법론입니다. DevOps에는 고유한 과제가 있지만, DevOps의 이점은 경쟁력을 확보하고자 하는 조직에서 투자할 만한 가치가 충분하다는 것입니다.

Which should not introduce DevOps.

DevOps는 소프트웨어 개발 및 배포에 있어 괜찮은 접근 방식이 됐지만 모든 회사에 적합한 것은 아닙니다. DevOps는 효율성 향상, 출시 시간 단축, 고객 만족도 향상 등 많은 이점을 제공할 수 있지만, DevOps가 최선의 선택이 아닐 수 있는 특정 상황도 있습니다.

l 규제가 심한 산업: 금융, 의료, 정부 등 규제가 심한 산업에 종사하는 기업은 엄격한 규제 요건을 준수해야 하므로 DevOps를 도입하지 못할 수 있습니다. DevOps 실행은 빠른 반복 작업과 잦은 릴리스가 포함되는 경우가 많기 때문에 이러한 산업에 속한 기업은 규정을 준수하기 어려울 수 있습니다.

l 레거시 IT 인프라: DevOps는 자동화에 크게 의존하므로 최신 IT 인프라가 필요합니다. 레거시 IT 인프라를 보유한 기업은 필요한 자동화를 지원하는 데 필요한 기술이나 리소스가 없을 수 있으므로 DevOps 실행을 도입하지 못할 수 있습니다.

l 부서 간 조화 부족: DevOps는 개발과 운영 팀 간의 긴밀한 협업을 필요로 하므로 조직 내 문화적 변화가 필요합니다. 회사의 문화가 협업과 실험 문화에 중점을 두는 등 DevOps 가치와 일치하지 않는다면 DevOps를 구현하는 것이 어렵거나 불가능할 수 있습니다.

l 수직화 조직구조: DevOps는 또한 여러 기능의 팀이 효과적으로 협업할 수 있는 수평적 조직 구조를 필요로 합니다. 회사의 계층 구조가 강하면 여러 수준의 경영진이 의사 결정을 승인해야 할 수 있으므로 DevOps를 구현하기 어려울 수 있습니다.

l 제한된 리소스: DevOps에는 기술, 리소스, 인력에 대한 상당한 투자가 필요합니다. 리소스가 제한된 기업은 필요한 투자를 지원할 예산이나 인력이 부족할 수 있으므로 DevOps를 효과적으로 구현하지 못할 수 있습니다.

결론적으로 DevOps에는 많은 이점이 있지만 모든 회사에 적합하지 않을 수도 있습니다. 규제가 심한 산업에서 운영되거나, 레거시 IT 인프라를 보유하고 있거나, 문화적 조화가 부족하거나, 계층 구조가 강하거나, 리소스가 제한된 기업은 DevOps 관행을 성공적으로 구현하지 못할 수 있습니다. 이러한 경우에는 소프트웨어 개발 및 배포에 대한 다른 접근 방식이 더 적합할 수 있습니다.