메뉴

목차

예전에는 소프트웨어 개발 프로세스가 간단(소프트웨어 개발이 단순했다는 의미가 아니다.)했다. 개발 환경과 프로덕션 환경간의 연동방식이나 워크플로우를 많이 필요로하지 않았다. 두 개의 환경이 연결되는 유일한 워크플로우는 수동배포 정도 였을 것이다. 이 워크플로우에서는 시스템 관리자가 물리적 서버를 관리하고 배포 업무도 수행했다. 배포가 좀 복잡해지면서 쉘 스크립트 등을 이용해서 개별적으로 배포 시스템을 만들어서 사용하기도 했다. 클라우드가 등장하고 시스템이 복잡해지면서 배포에 대한 수요가 늘어나자 이것만으로는 힘들어져서 Chef, Ansible, Puppet와 같은 형상/배포 관리 툴들이 등장하기 시작한다.

오늘날은 인터넷 서비스는 "기능을 신속하게 출시하고, 새로운 기능을 실험하고, 기능을 신속히 배포, 실시간 패치, 프로덕션 시스템 전체를 모니터링, 대규모 네트워크 트래픽을 처리해야 하는 특징이 있다.

DevOps이러한 요구사항에 대한 솔류션을 제공하기 위한 일련의 관행 및 프로세스의 도입이다. DevOps는 워크플로우를 자동화하고, 개발에서 배포, 운영까지의 간격을 압축해서 시장에 빠르게 대응하는 시스템의 구축에 도움을 준다.

많은 회사들이 DevOps의 필요성을 깨닫고 있으며 이를 도입하려고 하는데, 보통 별도의 DevOps 조직 혹은 DevOps 엔지니어를 고용한다. 따라서 모든 개발자에게 DevOps 기술이 필수 사항인 것은 아니다. 하지만 DevOps 개념을 배우면 프로그래밍 기술의 향상과 소프트웨어 개발 경력의 향상에 도움이 된다.

이 문서는 개발자로서 DevOps를 학습하는 것이 프로그래밍 기술 향상에 어떤 도움을 주는지를 설명한다.

자동화

작업은 무한히(엄청나게) 효율적이 될 수 있다. 손으로 작업하는 것과 삽으로 하는 것, 포크레인으로 작업하는 것은 엄청난 차이일 것이다. 동일한 툴을 사용한다고 가정할 경우, 작업 프로세스에 따른 차이도 엄청나다. 어떤 업무를 수행할 때, 조직을 구성하고 작업 프로세스를 개발하고 프로세스의 수행을 지원할 툴 선택을 가장 먼저 하는 것은 그럴만한 이유가 있는 것이다.

게으른 개발자가 되어라는 이야기는 그래서 나온다. 땀에 절어서 10시간 일할 생각을 하기 전에 적당한 툴을 이용하고 개발 프로세스를 개선하여 4시간만에 일을 끝내라라는 것이다. 힘들게 일을 한다는 것은 문제가 생겼거나, 문제가 생길 조짐이라는 것이다.

DevOps는 다른 분야에서의 작업 효율화 과정과 다른 측면있다. 삽질을 예로 들자면, 작업을 효율화하기 위해서 포크레인을 사용하려면 준비하는데에만 상당한 비용과 시간이 들어가는데 비해 DevOps는 그 보다 훨씬 더 적은 비용과 시간으로 업무를 효율화 할 수 있다.

오늘날 소프트웨어 개발팀은 DevOps 프로세스를 통해서, 릴리즈 정보, 배포, 모니터링/관제/추적의 전 과정을 자동화 한다. 그 뿐만 아니라 이 과정에 보안과 품질, 비즈니스를 내재화 한다. BizDevOps, DevSecOps라는 DevOps 확장이 생기는 이유다. DevOps를 배우면 시간을 효율적으로 사용할 수 있고, 품질을 관리 할 수 있으며, 동일한 작업을 여러 번 수행할 필요가 없다.

개발자는 GitHub action, GitLab, CodeCommit, CodePipeLine 등 다양한 소프트웨어를 이용해서 CICD 환경을 구축 할 수 있다. 이렇게 구축된 CICD 환경은 개발, 테스트, 프러덕트 환경으로 릴리즈된다.

여러분이 주니어를 벗어났다면, 같은 팀원, 인프라팀과 협업을 해야 한다면, 팀 혹은 프로젝트를 리딩해야 한다면 자동화 기술은 많은 도움이 될 것이다.

문제 해결 능력의 향상

코딩은 주어진 문제를 해결하기 위한 과정이며, DevOps는 주어진 문제를 해결하는 더 나은 방법을 제공한다. 개발자는 문제 해결을 더 쉽게 하기 위한 다양한 서비스, 스크립트, 프로세스를 사용해야 한다. 로컬과 원격에서 작동하는 테스트 환경, 독립적인 테스트 환경, 외부 API의 호출, API 문서의 호스팅, 릴리즈 정보를 생성하기 위한 스크립트를 작성해야 할 수 있다.

생각에 대한 생각을 하는 것을 메타인지라고 한다면, DevOps는 문제 해결을 쉽게하기 위한 문제 해결 능력을 키운다. 문제를 해결하는 두 가지 이상의 방법이 있고, 당신이 어떤 생각을 하든 그 보더 더 나은 솔류션을 찾을 수 있을 것이다.

전체 소프트웨어 시스템의 이해

코더와 프로그래머라는 분류를 싫어하는 사람들이 있는 것은 알고 있다. 하지만 어떤 일이든 간에 문제(업)를 대하는 태도, 노력, 시간에 있어서 차이가 발생하기 마련이고 소프트웨어라고 해서 예외는 아니다. 일반적으로 코더는 내부적인 학습, 회의적인 시각이 없이 주어진 사양에 대한 코드만을 작성하는 경향이 있다. 한편 프로그래머는 내부를 이해하고 시스템 씽킹(system thinking)을 하며, 시스템을 계획하고 탐색, 연구, 설계, 운영/유지/보수까지를 고민한다. 그리고 대부분의 개발자들은 소프트웨어 시스템의 외부와 내부를 이해하고 학습하여 프로그래머가 되기위해 노력한다.

DevOps는 인프라 관리와 시스템의 유지/보수와 관련된 작업만을 수행하는 것이 아니다. DevOps는 고객을 이해하고 고객에게 고품질의 안전한 소프트웨어 제품을 제공하기 위한 개발과 인프라를 효과적으로 통합하기 위한 일체의 활동이다.

때문에 DevOps 활동은 서비스의 계획, 통합, 테스트, 배포, 릴리즈, 유지/관리, 모니터링등 소프트웨어 시스템의 모든 생애주기를 다룬다. 개발자는 DevOps를 학습하면서 소프트웨어 시스템을 배울 수 있다. 이런 단계를 이해하고 나면, 보다 쉽게 제품의 큰 그림을 이해 할 수 있다. 프로젝트 관리자, 프로덕트 오너와 같이 소프트웨어 시스템을 관리/조율하는 커리어 패스를 생각하고 있다면 DevOps는 반드시 거쳐가야할 코스라 할 수 있다.

DevOps를 위한 프로그래밍 기술 준비

1993년 TINA-C(Telecommunications Information Networking Architecture Consortium)은 소프트웨어 개발과 통신 서비스 운영을 결합한 서비스 라이프사이클 모델을 정의한다.

2009년 devopsday라는 이름의 첫번째 회의가 벨기에 겐트에서 개최더았다. 이 회의에는 컨설턴트, 프로젝트 매니저, 애자일 실무자의 참여하에 설립되었으며, 다른 나라로 확산되기 시작한다. 2012년 Puppet의 DevOps 상태 보고서의 구상과 발표, 2014년 연간 DevOps 보고서가 발간되면서 DevOps는 소프트웨어 생태계에 넓게 확산이 되기 시작한다.

특히 클라우드컴퓨팅 저변이 확대되면서, 오늘날 대부분의 스타트업은 클라우드 first, DevOps first 접근 방식으로 소프트웨어 아키텍처를 정의한다. 또한 레거시(주로 온프레미스 모놀리식)을 소유한 많은 회사들이 DevOps의 지원하에 클라우드 환경으로 마이그레이션 하고 있다. 2020년 부터는 은행, 보험과 같은 기업들이 디지털 전환의 일환으로 DevOps와 클라우드로 레거시를 마이그레이션 하고 있다.

가장 보수적이라 할 수 있는 금융산업이 DevOps를 채택하면서, 프로그래밍 기술에서 DevOps가 차지하는 비중이 높아지고 있다. 기업들이 DevOps 엔지니어를 고용하고 있으며, 프로그래머와 협업하여서 DevOps first 방식으로 소프트웨어 제품을 설계, 구축, 코딩하고 있다.

DevSecOps

DevOps는 일반적으로 고품질의 소프트웨어를 고객에게 제공하는 것을 목표로 한다.

고품질의 소프트웨어를 제공하기 위해서는 비즈니스 기획 부터 개발, 보안, 운영, 조직구조, 문화가 모두가 통합되어야 한다. DevOps가 성공을 거두면서 개발과 운영외의 것들을 통합하려는 시도는 당연히 이루어졌고 그 결과 DevSecOps, BizDevOps 등의 활동이 만들어지게된다.

DevSecOps는 DevOps에 Security를 결합한 활동이다.

DevOps 이전에 개발과 운영이 서로 분리되어 있었던 것과 마찬가지로 보안 역시 개발, 운영과는 분리되어 있었다. 개발과 운영이 통합되어가는 와중에도 보안은 여전히 분리되어 있었는데, 보안은 개발/운영과 긴장관계를 유지해야 한다고 생각 했기 때문이다. 실제로도 보안 조직은 다른 조직과 지속적인 긴장관계를 유지하는게 일반적이다. 보안은 개발 파이프라인의 마지막 단계에서 실행되는 역할로 인식되어 왔다.

보안이 개발 파이프라인과 결합되지 않고 최종단계에서 적용되면서, 보안결함이 제품 출시의 최종 단계에서 식별할 수 있게 된다. 어떤 보안 결함은 초기 기획단계에서 부터 누적되기 때문에, 기획과 설계를 수정해야 하는 리스크를 가지고 있다. 이쯤에서는 시간이 부족하기 때문에 여러 가지 문제를 내포하고 서비스를 출시하거나, 출시일을 늦추게 된다.

DevSecOps에서는 서비스 기획 단계부터 정보보안, 개발, 운영팀이 서로 협업하여 보안 취약점이 조기에 드러나게 함으로써, 기획의 수정, 코드의 재개발 등을 최소화하고 더 안전한 제품을 출시 할 수 있다.

BizDevOps

BizDevOps는 DevOps 2.0 이라고도 한다. 개발자, 운영 조직 그리고 비즈니스 팀이 함께 협력하여, 사용자의 요구사항에 더 빠르게 대응하고 궁긍적으로 수익이 극대화되도록 장려하는 활동(소프트웨어 개발 접근 방식)이다.

목표는 DevSecOps와 동일하다. 과거에는 개발팀, 운영팀과 비즈니스/기획 팀이 서로 분리해서 운영했다. 비즈니스팀은 팀 자체의 KPI를 검토하고, 이를 개발팀에 넘기면 개발팀은 코딩을 하고, 코드가 완성되면 운영팀에 넘겨서 출시 후 관리업무를 수행했다. BizDevOp는 이들 조직간의 벽을 허물어서 효과적인 협업이 가능하도록 하는 것을 목표로 한다.

BizDevOps를 위한 중요한 기술은 실시간 모니터링과 분석이다. 이제 기업은 애플리케이션 성능 모니터링 시스템, 각종 데이터 처리 툴의 도움을 받아서, 최종 사용자의 행동에 대한 데이터를 즉시 수집하고 분석 할 수 있게 됐다. 이전에는 고객의 세부정보에 접근 할 수 없었으나 지금은 가능하다. 이제 비즈니스 목표는 개발, 배포와 통합되어서 작은 기능까지 추적할 수 있게 됐다.

데이터를 즉시 확인할 수 있게 되면서, 애플리케이션을 더 빠르게 개선하고 더 빠르게 릴리즈할 수 있게 됐다. 더 빠른 개선, 더 빠른 릴리즈는 더 빠른 테스트, 자동화된 QA 시스템이 필요하다. DevOps 활동을 통해서 개발, 테스트, QA가 자동화 되었다면, 비교적 수월하게 BizDevOps를 정착시킬 수 있다.

BizDevOps를 적용하는 일부 조직들은 BizDevOps 팀에 보안 및 규정 준수 관리팀, 테스트, 품질들을 함께 포함하기도 한다. 그렇다고 BizDevSecQAOps와 같은 이름을 사용 할 수는 없어서 BizDevOps를 주로 사용한다. BizDevOps 는 아래와 같은 프로세스를 가진다.

 BizDevOps Process

정리

DevOps는 프로그래밍 프로덕트를 이해하고 프로그래밍 기술을 향상시키는데 도움이 된다. 수동 릴리즈, 수동 테스트, 수동 사용자 피드백의 시대는 저물고 있다. 빠르게 변화하는 소프트웨어 개발 환경에 적응하기 위해서는 모든 것을 자동화해야 한다. 팀과 함께 DevOps 원칙을 구현해보자.

GitHub, GitLab 등을 이용해서 애플리케이션의 릴리즈 정보를 생성하고, 자동으로 Java, Javascript, Go, Python 애플리케이션을 전개해보자. 조금 더 나아가서 클라우드에 올리고, 컨테이너화 해서 ECS 혹은 EKS(Kubernetes)로 배포하자. 이를 통해서 얼마나 많은 시간을 절약할 수 있으며, 얼마나 많은 새로운 기술들을 배울 수 있는지 확인해보자.

참고