회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
여러분은 데브옵스(DevOps)가 무엇인지 알고 계시나요? 데브옵스는 프로젝트의 수명주기 전반에 걸쳐서 발생할 수 있는 특정한 문제와 어려움들을 효과적으로 해결하면서 전 세계 많은 조직들에서 도입되고 있는데요. 이런 과정을 지원하는데 필요한 도구와 기술, 프로세스들은 각 조직에게 가장 효과가 좋은 것이 무엇인지에 따라서 아주 많이 다를 수 있습니다. 즉, 우리는 데브옵스 기법을 받아들일 것인지가 아니라, 그것을 어떻게 하면 가장 잘 구현해서 비즈니스의 가치를 최대로 키워낼 수 있는지에 대해서 고민을 해야 하는 것이죠.
이번 글에서 위시켓은 데브옵스가 무엇인지, 그리고 그것이 제공하는 장점들을 최대한 활용하기 위해서 따라야 하는 기법들에 대해서 알아보는 시간을 갖도록 하겠습니다.
소프트웨어 개발의 3대 요소는 사람, 프로세스, 도구입니다. 데브옵스 문화를 받아들일 때는, 3대 요소가 현재의 요구 사항에 맞게 적절하게 조정되어야 합니다. 조직에서 소프트웨어 개발 수명주기(Software Development Life Cycle, SDLC)를 최소화할 수 있는 프로세스 그리고 적절한 도구와 테크놀로지를 갖춘 인프라는 데브옵스를 매끄럽게 구현할 수 있도록 도와줍니다. 그 안에서는 공동의 목표를 공유하고 공동의 명분을 향해 기여하는 공동체의 분위기가 있어야 하는데요. 이를 위해 경영진은 모든 팀들이 정보를 제대로 공유하고 있도록 노력해야 합니다.
이상적인 시나리오대로라면, 조직에는 실행공동체(Communities of Practie, Cop)가 있습니다. 이러한 역할 기반의 커뮤니티는 팀들 사이의 지식 공유 및 탐구에 기여할 것으로 기대할 수 있죠. 결국 데브옵스는 다른 부서들과 함께 하는 것이기에, 이 주제를 다루는 조직에서는 팀원들로 하여금 회사 안에서 다양한 역할을 수행하면서 고도로 생산적인 환경을 구축하기 위해 서로 간의 실천 기법과 경험을 공유하도록 유도합니다.
코드의 품질을 뛰어나게 만들기 위해서는, 정기적인 테스트가 필요합니다. 테스트 자동화는 SDLC의 속도를 높여주고, 개발자들이 작업을 하면서 문제를 해결할 수 있도록 해주죠. 데브옵스를 받아들인 팀에서는 본격적인 생산 과정에 들어가기 전에 결함을 감지하고, 수정하기 위해서 더 자주, 더 일찍 테스트 해야만 합니다. 자동화를 통해 더 많은 테스트를 수행할 수 있으며, 수동으로 테스트하는 것보다 시간을 절약할 수 있습니다.
미들웨어(middleware) 환경설정에 대한 테스트, 네트워크 및 데이터베이스 변화, 자동화된 부하(load), 단위, 회귀 테스트(regression test) 등에 대한 주기적인 검사 같은 모든 테스트들이 SDLC 최적화에 기여합니다. 소프트웨어 개발 수명주기의 흐름을 유지하면서 테스트를 자동화하게 되면, 검증을 거친 코드가 데브옵스의 파이프라인을 따라서 자동적으로 개선되거나 또는 뒤늦게 결함이 발견되는 것을 방지할 수 있습니다.
데브옵스의 파이프라인 과정에서 일반적으로 사용되는 도구들은 다양하게 존재하는데, 대표적으로는 젠킨스(Jenkins), 스플렁크(Splunk), 테라폼(Terraform), 나기오스(Nagios), 그라파나(Grafana), 프로메테우스(Prometheus) 등이 있습니다. 따라서 데브옵스로 전환할 때는 중앙 집중화되고, 연합된 인프라가 균형을 잘 맞출 수 있도록 관리 시스템이 특별히 구현되어야 합니다.
이런 도구들을 구성하는 가장 좋은 방식은 먼저 IT 작업 방식을 중앙 집중화하거나, 또는 프로비저닝(권한설정)이나 보안 또는 실제 애플리케이션의 배치를 중앙에서 수행하는 겁니다. 이를 통해서 프로비저닝, 보안, 연결성과 관련하여 사람들이 조직되어 있는 독립적인 개발자 중심의 데브옵스 모델로 전환할 수 있고, 보다 쉽게 접근할 수 있으며, 중앙 집권화된 소스 저장소를 갖춘 API 기반의 방식으로 소프트웨어를 개발할 수 있습니다.
보다 빈번하게 배포를 하기 위해서는 일주일 단위로 애자일 스프린트(agile sprint)를 해보는 게 좋습니다. 그렇게 하면 어떤 팀이 다른 팀보다 더 자주 배포해야 할지 결정하는 것이 수월해질 겁니다. 배포의 빈도는 중요한 측정 수치이기 때문에 정기적인 성과 검토를 향해서 나아가는 이러한 단계는 데브옵스를 받아들이고자 하는 조직에서 반드시 수행돼야 합니다. 이 모든 과정을 통해서 조직은 지속적인 배포를 효과적으로 결국 배포자동화를 효율적으로 받아들이고, 프로세스를 자동화하는 방법에 대해 심도 있게 논의할 수 있습니다.
배포의 안정성은 지속적인 배포가 제대로 이뤄지고 있는지를 가늠하는 지표이며, 지정된 저장소가 얼마나 성공적인지, 그리고 코드 생성, 버전 관리, 테스트, 배포, 배포 이후의 절차와 같은 배포의 허위 프로세스들이 과연 제대로 제어되고 있는지에 대해서 팀에게 정보를 알려줍니다. 팀에서 배포 프로세스를 최적화해야 하는 대상을 분명하게 파악할 수 있도록, 대시보드 위에 빌드(build)를 시각화하는 것을 도와줄 수도 있죠.
효율적인 모니터링 도구는 컨테이너 환경, 클라우드 환경 그리고 온프레미스 환경에서 모두 동일하게 잘 대처할 수 있습니다. 또한 향후의 업그레이드나 프로젝트에 대한 계획을 적절하게 수립할 수 있고, 그에 따라서 리소스를 관리할 수 있게 해줍니다. 가장 많이 쓰이는 모니터링 도구들로는 센수(Sensu), 프로메테우스(Prometheus), 나기오스(Nagios) 등이 있습니다.
또한 슬랙(Slack)이나 페이저듀티(PagerDuty), 서비스나우(ServiceNow)와 같은 데브옵스 알림 도구가 있는데, 이들은 팀에서 대응해야 하는 이슈가 발생했을 때 그에 대한 중요한 정보를 제공해 줍니다. 인플럭스디비(InfluxDB), 스플렁크(Splunk), 아마존웹서비스(AWS)와 같은 도구들은 메트릭스(metrics) 스토리지 시스템(storage system)으로서, 수집된 데이터를 종합해서 학습하는 데 도움을 주게 됩니다.
마지막으로, 사용자 설정 가능한 대시보드에 연동되어 정렬된 데이터를 보여줄 수 있는 데브옵스 시각화 도구의 활용을 고려하는 것도 좋은 생각입니다. 견고한 모니터링 환경을 조성하기 위한 목적으로 데브옵스 도구들을 합리적으로 사용한다면, 팀의 기능이 확장되고, 팀원들이 담당하는 제품이나 서비스의 품질과 가치를 개선할 수 있습니다.
따라서 코드를 다시 마스터 브랜치(master branch)에 일찍 병합함으로써, 통합에 따르는 오버헤드(overhead)를 줄일 수 있죠. 이 방법은 협업도 개선되고, 코드의 상태에 따른 빠른 피드백 루프(feedback loop)가 가능하게 만듭니다. 지속적인 통합을 실천하는 개발 부서는 코드 변경으로 인해서 기존의 기능이나 테스트가 중단되지 않았음을 확인하기 위해서 자동화된 테스트를 구성해야 할 겁니다.
IT 아키텍처에서의 이러한 변화는 소프트웨어 개발 부서와 운영 부서가 함께 일하는 방식도 변화시킬 겁니다. 보다 많은 운영 및 관리 업무를 서버리스 제공업체가 처리하게 된다면, 데브옵스의 역할은 인프라 관리가 아닌 앱을 구축하고 배포하는 업무에 보다 집중할 수 있도록 발전하겠죠. 개발(데브, Dev)과 운영(옵스, Ops)이 통합된 서버리스 아키텍처는 데브옵스 프로세스를 단순화해서, 팀에 있어서의 많은 문제들을 줄여줄 수 있습니다.
데브옵스 전환의 주된 목적은 모든 회사에서 동일합니다. 즉, 생산성과 효율성에 긍정적인 영향을 미치고, 소프트웨어의 품질을 개선하며, 궁극적으로 최대한 빠르게 가치를 전달하는 것이죠. 데브옵스와 관련된 전문가를 만나보고 싶다면 위시켓을 이용해보세요! 여러분이 원하는 개발 프로젝트를 등록해주시면, 견적/포트폴리오/ 프로젝트 분석, 제안 내용을 한 번에 받아보실 수 있습니다.
좋아요
댓글
공유
공유
5.7K
