지속적배포(CD)로 이동: DevOps와 NoOps

지난 몇 년간 전체 어플리케이션의 개발 프로세스와 프로덕션에서 어플리케이션이 처리되는 방식에 큰 변화가 있었다. 과거에는 개발팀에서 어플리케이션을 만든 후에 운영팀에 넘겨주면 어플리케이션을 배포하고, 관리하며 계속 실행했다. 그러나 지금은 어플리케이션을 개발하는 사람이 배포에도 참여하고 전체 라이프사이클을 함께 관리할 수 있게 팀을 구성하는 편이 더 효율적이라는 사실을 알게 됐다. 이것은 개발자, 품질 보증, 운영팀이 전체 프로세스를 모두 함께 작업해야 한다는 의미이다. 이런 작업 방식을 DevOps라고 부른다. 

 

 

DevOps의 장점

 

개발자가 운영에서 어플리케이션 실행에 좀 더 많은 시간을 들인다면 사용자가 무엇을 필요로 하는지, 어떠한 문제가 있는 더 잘 이해하게 되고, 운영팀이 어플리케이션을 유지하는 동안 직면하는 문제를 더 잘 알 수 있다. 어플리케이션을 좀 더 신속하게 제공할 수 있으므로 사용자의 피드백을 받아 추가 개발 여부를 검토할 수도 있다. 

 

어플리케이션 버전을 더 자주 릴리즈하려면 배포 프로세스를 간소화해야 한다. 가장 좋은 방법은 개발자가 운영 담당자를 기다리지 않고 직접 어플리케이션을 배포하는 것이다. 그런데 어플리케이션을 배포하려면 데이터 센터의 기본 인프라와 하드웨어가 어떻게 구성되어 있는지 정도는 알고 있어야 한다. 하지만 개발자는 이런 세부 사항을 몰라도 된다. 

 

 

개발자와 시스템 관리자가 최고로 잘할 수 있는 것을 하게 하는 것

 

개발자와 시스템 관리자는 고객이 성공적으로 실행할 수 있는 소프트웨어를 전달한다는 동일한 목표를 달성하기 위해 노력하지만 각자의 목표와 동기는 다르다. 개발자는 새로운 기능을 만들어 사용자 경험을 개선하는 것을 좋아한다. 개발자는 일반적으로 기본 운영체제의 보안 패치나 이와 관련된 모든 것이 최신인지 확인하는 것을 시스템 관리자에게 맡기고 싶어한다. 

 

운영팀은 제품 배포와 운영하는 하드웨어 인프라를 담당하며 시스템 보안, 활용, 개발자의 우선순위가 높지 않은 측면에 신경을 쓴다. 운영 담당자는 모든 어플리케이션 구성 요소의 암묵적 상호 의존성에 대처하기를 원하지 않으며, 기본 운영체제나 인프라를 변경햇을 때 어플리케이션 전체의 동작에 어떠한 영향을 미칠지는 생각하지 않는다. 

 

하드웨어 인프라를 전혀 알 필요 없이 운영팀을 거치지 않고 개발자가 직접 어플리케이션을 배포하는 방식이 가장 이상적이다. 이를 NoOps라고 한다. 물론 이때도 하드웨어 인프라를 관리할 사람은 필요하지만, 실행 중인 어플리케이션의 특성을 꼭 알 필요는 없다. 

 

쿠버네티스가 이 모든 것을 가능하게 해준다. 어플리케이션을 배포하고 실행하는 단일 플랫폼으로써 하드웨어를 추상화하고 노출하므로 개발자는 시스템 관리자의 도움 없이도 어플리케이션을 구성하고 배포할 수 있다. 시스템 관리자는 실제로 하드웨어에서 실행되고 있는 어플리케이션에 대해 모르더라도 기본 인프라를 유지하고 가동하는데 집중할 수 있다.