devops | noops

DevOps와 NoOps의 개념, 문화, 도구 그리고 시너지

DevOps와 NoOps의 개념과 차이, 개발·운영 협업 문화, 자동화 도구, 관련 기술 영역을 정리하고 두 패러다임이 어떻게 소프트웨어 딜리버리를 변화시키는지 살펴봅니다.

Mimul
MimulNovember 17, 2011 · 12 min read · Last Updated:

클라우드가 활성화되면서 해외 IT 계의 기사에서 “DevOps”, “NoOps”라는 용어를 볼 기회가 늘고 있다. 이제는 단순한 용어에 그칠 것이 아니라, 신속하고 자동화된 개발 및 운영, 소프트웨어 품질과 관련된 새로운 무브먼트로 인식해야 할 것 같다.

이 글에서는 DevOps와 NoOps의 정의부터 시작해, 두 패러다임을 뒷받침하는 문화와 도구, 관련 기술 영역, 그리고 두 개념의 관계를 정리한다.

DevOps(DevOps = Dev + Ops)란?

DevOps 용어는 Opscode의 CEO인 Jesse Robbins에 의해 처음 불려졌다고 한다. 위키피디아의 정의를 살펴보면 다음과 같다.

“DevOps” is an emerging set of principles, methods and practices for communication, collaboration and integration between software development (application/software engineering) and IT operations (systems administration/infrastructure) professionals. It has developed in response to the emerging understanding of the interdependence and importance of both the development and operations disciplines in meeting an organization’s goal of rapidly producing software products and services.

DevOps는 개발 부문, 운영 부문, 품질 관리 부서 사이의 통합·커뮤니케이션·협업을 위한 일련의 메서드 및 시스템이다. 적기에 소프트웨어 제품이나 서비스를 출시하려는 조직의 목표에 부합하려면 개발과 운영이 상호 의존해야 한다는 의미다.

DevOps는 왜 개발과 운영을 통합하려 하는가?

부득이한 경우에만 릴리스를 한꺼번에 진행하면, 그사이에 쌓인 변화로 인해 시스템 위험이 커진다. 반대로 작은 릴리스를 자주 반복하면 변화의 폭이 좁아지므로 위험도 줄어든다. 빈번한 릴리스를 위해 개발 부서와 운영 부서가 협력해야 한다는 생각이 DevOps의 근저에 흐른다.

개발 부서에서 새로운 기능 추가를 요구할 때 운영 부서가 시스템 안정성을 이유로 반영을 거부하는 일이 생긴다. 이런 보이지 않는 대립 속에서 비즈니스 쪽 임원이 새로운 기능 실현을 설득하면 울며 겨자 먹기로 반영되기도 한다. 장애를 중시하는 임원이 많을수록 개발과 운영 부서는 더욱 안정적 운영에 집중할 수밖에 없는 구조가 된다.

하지만 비즈니스는 항상 새로운 기능과 기존 기능의 변화를 지속적으로 요구한다. 이것이 시스템 장애의 원인으로 작용한다. DevOps는 이 문제를 문화와 도구로 극복하는 방법을 찾는다. 개발에서 운영까지를 하나의 통합된 프로세스로 묶고, 툴과 시스템을 표준화·통합하여 협업의 효율을 높이며, 코드 통합·테스트·릴리스 과정을 자동화하는 환경을 구축하는 것이다.

시너지를 낼 수 있는 문화

  • 개발과 운영 각자의 가치를 인정하고 개발자·운영자를 존중하는 문화
  • 실패를 감싸주는 포용력
  • 실무에 집중할 수 있는 환경 제공
  • 자유롭게 토론할 수 있는 채널 확보
  • 비즈니스 협업과 참여를 개발 초기 단계부터 투입

도구 관점의 Best Practices

  • 자동화된 빌드와 릴리스를 한 번에 수행하라.
  • 자동화된 인프라스트럭처 및 시스템 프로비저닝을 갖춰라.
  • DevOps 팀 간에 일관된 도구를 사용하라.
  • 설정 코드는 애플리케이션 코드와 분리하라.
  • 라이프사이클 전반에 걸쳐 비기능적 운영 요소에 관심을 가져라.
  • 공유 가능한 버전 관리 도구를 도입하라.
  • 감사 시 릴리스를 추적할 수 있어야 한다(요구사항에서 운영까지).
  • 버전 관리되는 SDLC와 같은 모델화된 수명 주기를 갖춰라.
  • Ops 툴도 동일한 SDLC 아래 관리하라.
  • 자동화 코드 역시 코드이므로 자체 SDLC로 통제하고 소프트웨어처럼 릴리스하라.
  • 측정 지표를 관리하고 팀 간에 공유하라.

DevOps에서 활용도 높은 언어

The Most Important Languages For DevOps 아티클에 따르면 인기 순으로 Bash(or POSIX shell), SQL, Perl, JavaScript(Node.js), PHP, Ruby, Java, Python 순이라고 한다. 최근 Docker, Kubernetes가 보편화되면서 Go의 활용도도 높아졌다. Chef/Puppet은 중요하지만 Ruby를 배워야 하는 진입 장벽 때문에 순위가 낮게 나타난다. 개인적인 경험을 바탕으로 한 아티클이므로 참고 용도로만 활용하기 바란다.

NoOps(No + Ops)란?

Forrester Research의 애널리스트 Mike Gualtieri가 쓴 I Don’t Want DevOps. I Want NoOps에서 그는 클라우드 환경이 성숙하면 운영 부서 자체가 불필요해진다(NoOps)고 주장했다.

NoOps means that application developers will never have to speak with an operations professional again. NoOps will achieve this nirvana, by using cloud infrastructure-as-a-service and platform-as-a-service to get the resources they need when they need them.

개발자는 운영 부서와 이야기할 필요가 없어지고, IaaS와 PaaS를 통해 필요한 자원을 필요한 때에 바로 확보할 수 있다는 것이다. 그러나 IaaS와 PaaS만으로 모든 배포 프로세스가 해결된다는 것은 지나친 낙관이다. 다양한 플랫폼과 비즈니스 요구가 존재하기 때문에 이를 단순화하는 데는 무리가 있다.

2011년 4월 Forrester는 Augment DevOps with NoOps 보고서를 통해 가까운 미래에 일부 기업에서 클라우드 의존도가 높아지고 빌드·테스트·배포 작업이 자동화되면서 결국 NoOps에 이를 것으로 예측했다. 클라우드 시대에는 주문형 인프라, Self Provisioning, 유연한 애플리케이션 아키텍처 덕분에 협업 릴리스의 필요성이 줄어들고, 협업 중심의 DevOps가 NoOps로 진화한다는 것이다.

이후 ReadWriteWeb은 From DevOps to NoOps: 10 Cloud Services You Should Be Using에서 NoOps로 가기 위한 인프라스트럭처 도구들을 소개했다.

GigaOM에서 AppFog CEO Lucas Carlson은 Why 2013 is the year of ‘NoOps’ for programmers라는 인포그래픽을 통해 2013년을 “프로그래머 NoOps의 해”로 예측했다. 컴퓨팅 모델이 1990년대 데이터 센터에서 2000년대 가상화·IaaS(AWS)로 진화하면서 신흥 기업의 컴퓨팅 비용이 기하급수적으로 감소하고 생산성이 급증하는 양상이 나타났다. 2011년에는 SysOps 관리가 체계화되면서 Chef, Puppet 같은 표준 라이브러리를 통한 자동화가 급속도로 증가했다.

Carlson은 개발자의 60%가 프로그래밍에, 40%가 운영(미들웨어·네트워크·가상화 하드웨어 관리·프로비저닝·보안)에 시간을 쓰고 있다고 언급했다. Netflix도 Ops, DevOps and PaaS (NoOps) at Netflix 포스팅을 통해 Linux 기반 AMI(아마존 머신 이미지) 구축, Artifactory를 활용한 빌드 자동화 등 NoOps로 향하는 과정을 구체적으로 기술했다.

NoOps는 말 그대로 운영 업무 자체를 제거하는 것이 목표이지, 개발자나 운영자를 없애는 것이 아니다. 또한 아웃소싱으로 흘러갈 수 있는 위험도 있으므로, DevOps 역량 자체도 조직의 자산이라는 관점을 잃지 않아야 한다.

DevOps, NoOps와 관련된 기술 영역

영역영역영역
BuildContinuous IntegrationDependency Management
PackagingRepositoryAuthentication/Authorization
Content DistributionSchema ManagementMonitoring
Service ManagementCode CoverageIDE
Version Control SystemUnit TestingServer Virtualization
System ConfigurationDocumentationChange Management
Process OrchestrationTest AutomationConfiguration Management
Provisioning

마치며

DevOps와 NoOps는 운영 분야의 은총알이 아니다. 개발자와 운영자 각자의 영역에서 협업을 통해 운영 효율성을 높이고, 제품 품질을 안정적으로 유지하며, 비즈니스 가치를 높이는 데 본질이 있다. DevOps가 문화와 협업을 통해 사람 간의 경계를 허무는 것이라면, NoOps는 자동화와 플랫폼을 통해 반복 작업 자체를 없애는 방향이다. 두 개념은 대립이 아니라 진화의 방향이다.

참조


Mimul

Written byMimul
Mimul is a programmer, technologist, exercise enthusiast and more.
Connect