DevOps와 개발자

Contents

예전에는 소프트웨어 개발 프로세스가 간단(소프트웨어 개발이 단순했다는 의미가 아니다.)했다. 개발 환경과 프로덕션 환경간의 연동방식이나 워크플로우를 많이 필요로하지 않았다. 두 개의 환경이 연결되는 유일한 워크플로우는 수동배포 정도 였을 것이다. 이 워크플로우에서는 시스템 관리자가 물리적 서버를 관리하고 배포 업무도 수행했다. 배포가 좀 복잡해지면서 쉘 스크립트 등을 이용해서 개별적으로 배포 시스템을 만들어서 사용하기도 했다. 클라우드가 등장하고 시스템이 복잡해지면서 배포에 대한 수요가 늘어나자 이것만으로는 힘들어져서 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는 반드시 거쳐가야할 코스라 할 수 있다.

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 방식으로 소프트웨어 제품을 설계, 구축, 코딩하고 있다.

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

...계속

• https://levelup.gitconnected.com/how-to-improve-your-programming-skills-by-learning-devops-73071b9ea507