개발/운영 그리고 시스템전문가가 함께 모여 모니터링을 하면서 트래픽증가 예상을 분석하는 모습 - 옵저빌리티


데브옵스를 한문장만 설명하기 어려우며 데브옵스의 등장 역사와 함께 24년 트렌드를 살펴보겠습니다.

IT용어에대한 정의는 모두가 동의할수 없는 내용들이 많으며 데브옵스는 특히 변화하는 기술에 빠르게 대응하는편이며

시대에 따라서도 정의가 다양해지는것 같습니다.


데브옵스의 일반적 의미

데브옵스의 일반적인 정의는 다음과 같이 포괄적으로 표현됩니다.

데브옵스(DevOps)는 '개발(Development)'과 '운영(Operations)'의 합성어로, 소프트웨어 개발의 Agile 방법론을 기반으로 하여 개발과 운영팀 간의 협력과 소통을 강화하여 더 빠르고 안정적으로 제품을 배포하고 운영할 수 있도록 지원하는 문화, 방법론, 그리고 관행을 말합니다.


데브옵스라는 용어가 사용이 시작된 역사를 알기위해서 2001년 17명의  IT쪽리더들의 워크샵에서 선언한  애자일선언부터 거슬러가보겠습니다.

애자일

  1. 프로세스와 도구보다 개인과 상호작용을 더 중요시한다.
  2. 포괄적인 문서보다 작동하는 소프트웨어를 더 중요시한다.
  3. 계약 협상보다 고객과의 협력을 더 중요시한다.
  4. 계획을 따르기보다 변화에 대응하는 것을 더 중요시한다.


애자일의 선언중 실천과제로 변화에 대응하기 위해 지속적 개선  CI/CD가 필요로하게되었습니다. 

이것은 단순하게 자동빌드/자동배포만 하는 기술적인 내용만은 아닙니다.

CI/CD

CI/CD는 Continuous Integration (지속적 통합)과 Continuous Delivery 또는 Continuous Deployment (지속적 전달/배포)의 약자로, 애자일 개발 방법론을 실천하기 위한 중요한 기술적 접근 방식입니다. 이 방식은 소프트웨어 개발 과정을 자동화하여 소프트웨어 개발의 효율성을 높이고, 높은 품질의 소프트웨어를 빠르게 고객에게 전달하는 데 목적이 있습니다.

Continuous Integration (CI)

Continuous Integration (CI)은 개발자가 코드 변경 사항을 주기적으로 (일반적으로 하루에 여러 번) 중앙 코드 저장소에 통합(merge)하는 것을 의미합니다. 이 과정에서 자동화된 빌드와 테스트가 수행되어 코드 변경 사항이 기존 코드와 잘 통합되는지 확인합니다. CI의 주요 목표는 통합 과정에서 발생할 수 있는 문제를 조기에 발견하고 해결하여 소프트웨어의 품질을 유지하는 것입니다.

Continuous Delivery (CD)

Continuous Delivery (CD)는 CI 과정을 한 단계 더 발전시켜, 자동화된 빌드와 테스트를 거쳐 생성된 소프트웨어를 자동으로 스테이징 환경에 배포하는 것을 의미합니다. 이를 통해 소프트웨어가 언제든지 실제 운영 환경에 배포될 준비가 되어 있음을 보장합니다. CD는 배포 준비 과정을 자동화함으로써 배포 과정에서의 오류를 줄이고, 배포 준비 시간을 단축합니다.

Continuous Deployment

Continuous Deployment는 CD의 한 단계 더 진행된 개념으로, 자동화된 테스트를 성공적으로 통과한 코드 변경 사항을 자동으로 실제 운영 환경에 바로 배포하는 과정입니다. 이 접근 방식에서는 수동으로 배포를 승인할 필요가 없어, 변경 사항이 고객에게 더 빠르게 도달할 수 있습니다.


CI/CD는 개발초기부터 배포가되기까지 변화에 대응하기위해 배포주기를 짧게하고 품질도 유지해야하기때문에 우리의 일하는 방식 자체도 변경되어야함을 의미하며

1~3개월 만에 통합배포가 1번뿐이다라고하면 자동배포보다는 준비되고 계획된 배포가 유리할수도 있습니다. 

워터폴주기에서는 배포가 긴주기 였다고하면, 다음과 같은 활동을 통해 최종 사용자에게 프로덕트가 전달가능했으며 충분히 다음과 같은 방식만으로 성공을 하였습니다.


  • 롤백플랜을 꼼꼼하게 계획하고 계획된 배포및 설치과정을 준수
  • 최종단계에서 개발코드 브랜치 통합
    • 최종단계에서 대규모 품질테스트 


오늘날 서비스는 변덕스럽고 예측하기 어렵기때문에 더 짧은 주기의 배포방식이 필요했으며 단순하게 자동배포를 구성하는것만으로  우리가 개발한 프로덕트가 운영에 안전하게 작동될수 있는것은 아닙니다.

긴주기의 개발주기에서 짧은주기의 지속배포가 됨으로 개발사이클은 작은단위로 짧아졌으며 운영은 더 긴밀하게 대응하면서 작동합니다.


CI/CD에 대한오해

CI/CD를 수행하기 위해 다음과같은 우리의 업무변화가 필요하며 CI/CD는 단순하게 배포기술만 자동화하는 것이아니라 

짧은 주기의 지속적 배포를 하기위해   변해해야할 개발문화여정을 함께 이야기합니다.

지속배포(CD)는 자동화및 안정적 배포에 가까울수 있으며 지속통합(CI)은 더 짧은 주기로 통합하기 위해 필요한 개발문화및 기술 그 자체를 이야기합니다. 

  • 배포담당 : 배포과정을 자동화하여 설치과정에서 발생하는 시간을 단축하고 사람의 실수를 방지
  • PM/기획 : 짧은 주기의 지속적 아이디어 발굴및 스케줄관리
  • 개발자 : 작은단위 개발 코드 지속통합 
    • 과거의 dev/staging/master 환경에 따른 머지방식은 통합머지가 되고 난 이후 품질검증이 시작할수 있는 방식으로 워터폴에 적합했습니다. 
      • 하지만 오늘날의 개발코드는 지속머지를 해야하기때문에, 환경을 고려한 복잡한 머지 절차인 gitlabFlow 방식보다 GitHub One Flow 전략이 유행하고 있으며 환경분리는 브랜치가 아닌 태깅방식/실행타임 주입방식등으로 관리할수 있게되었습니다.
    • 개발자는 QA에 품질 의뢰를 하기전 더 짧은 주기의 개발테스트를 충분히 해야하며  유닛테스트까지 요구함을 의미합니다. 
  • QA 
    • 개발팀이 MSA를 도입하기 시작하면서 독립적으로 업데이트가 수행되며  통합배포라는 개념은 점점 사라져가고 있기때문에 통합테스트 보다는 지속적 테스트가 요구되며, 지속에따른 반복 테스트가 늘어남에 따라 이에따른 자동화 테스트툴이 요구되기도 합니다.

데브옵스라는 단어의 첫등장

CI/CD가  빌드/배포 자동화만 하는 기술적인 내용이 아니며 데브옵스또한  CI/CD만 해야하는 것도 아닙니다.

이것을 오해하는 조직이 데브옵스라는 팀을 만들고 배포자동화만 시켰을때 우리는 데브옵스를 잘 수행하고 있다라고 착각을 가질수 있다란점입니다.


CI/CD가 주로 고객에게 잘 전달 하기위해 배포와 관련된 기술중심으로  다룬다고 하면 데브옵스는 CI/CD를 포함 우리가 만든 소프트웨어가 고객에게 전달되고 난 이후 잘 운영되는 여정까지 함께 다룹니다.


DevOps 운동은 2009년 벨기에의 Gent에서 열린 Agile 2009 컨퍼런스에서 Patrick Debois와 Andrew Shafer에 의해 처음으로 소개되었습니다.

이들은 "Agile Infrastructure"라는 세션을 통해 개발과 운영 간의 더 긴밀한 협력의 필요성에 대해 논의하였습니다. 이 후, Patrick Debois는 2009년에 첫 "DevOpsDays" 컨퍼런스를 개최하며 DevOps라는 용어와 개념을 널리 퍼뜨리기 시작했습니다.

DevOps의 핵심 가치는 Culture (문화), Automation (자동화), Measurement (측정), and Sharing (공유)으로 요약될 수 있으며, 이는 CAMS 모델로 알려져 있습니다.

DevOps는 개발과 운영 팀이 더 긴밀하게 협력하여, 더 빠르게, 더 자주, 더 안정적으로 소프트웨어를 배포할 수 있도록 함으로써, 고객에게 더 나은 가치를 제공하는 것을 목표로 합니다.


데브옵스 활동은 애자일의 활동중 일부이며 , 애자일에서 지속개선을 위해 운영과의 소통부분을 놓치고 있던부분을 확장한 개념입니다.

DevOps가 초창기 소개될때  애자일에서 이야기하는 지속개선과  겹치기도하고 별다른 내용이 없는것처럼 보여 참석율이 저조해 초기에는 인기가 없었습니다.

개발/운영간 소통이 안되 최종 소비자가 겪는 문제에 대한  이 세션에서 발표한 상황극이 점점 알려지기 시작하면서  애자일이 강조하는 지속개선이 작동안되는 주요원인으로 운영과의 소통을 소홀히 했던것을 이 분야의 리더들이 인지하면서

이것을 개선하는 활동으로 데브옵스활동이 탄생하게 되었습니다.



DDD는 도메인을 개발해야할 개발자또는 기획자가 도메인전문가와 전혀 소통을 하지 않고 도메인을 만들어내는것에 대한 문제점을 지적 하며 시작된 개념이며

DDD와 데브옵스의 핵심가치역시, 문제를 해결하기 위해 긴밀한 커뮤니케이션이 우선이다란점이 유사하며 문제를 풀어내는 실천과제는 다양할수 있습니다.

  • 개발/기획 ↔  : 도메인전문가 로부터 도메인의 핵심을 파악하고 복잡성을 풀어냄 -DDD
  • 개발↔운영  : 최종 사용자에게 안전하게 제공하고 운영하기위해 긴밀하게 협력해 문제를 개선해나감  - 데브옵스


DevOps는 애자일의 활동중 일부이며 기존 애자일이 놓치고 있던 다음 두가지 부분을 강화해 오늘날의 CI/CD를 성숙시켰습니다.

  • 협업 및 커뮤니케이션: 개발자와 운영 팀이 긴밀하게 협력하여 문제를 해결하는 모습을 보여줍니다.
  • 피드백 루프: 사용자로부터의 피드백이 개발 과정에 신속하게 통합되어 제품 개선을 이끌어내는 과정을 나타냅니다.



다음은 데브옵스가 처음 소개될때 상황극으로 재구성해보았습니다. 

개발과 운영이 협업이 안될때의 장애상황극 

장소: IT 회사의 대형 회의실 

참여자: 개발팀 리더(진호), 시스템팀 리더(혜린), 소프트웨어 운영팀 리더(성민), CIO(은주)

시간: 오후 2시, 장애 발생 후 3시간 경과

은주: "지금부터 장애 상황 회의를 시작하겠습니다. 현재 상황부터 파악해 봅시다."

성민: "지금 우리 시스템이 전반적으로 느려지고, 일부 서비스에서는 접속조차 되지 않는 상황입니다. 고객 불만이 폭주하고 있어요."

진호: "이번 장애는 저희 개발팀에서 최근에 배포한 업데이트와는 무관합니다. 우리는 정상적으로 코드를 테스트하고 배포했습니다."

혜린: "시스템팀에서도 서버 상태는 정상이고, 네트워크에도 문제가 없습니다. 이는 분명 소프트웨어의 문제로 보입니다."

성민: "하지만, 운영팀에서 분석한 바로는 최근 개발팀에서 배포한 업데이트 이후부터 문제가 발생하기 시작했습니다. 아마도 새 기능에 무언가 문제가 있는 것 같아요."

진호: "그런데 왜 바로 문제를 파악하지 못했나요? 운영팀에서 충분히 모니터링하고 있어야 하는 것 아닌가요?"

혜린: "시스템팀은 인프라만 관리할 뿐, 소프트웨어의 세부적인 동작까지 파악하는 것은 우리의 업무 범위를 넘어섭니다. 개발팀과 운영팀에서 좀 더 세심하게 확인해야 합니다."

성민: "사실 운영팀도 모니터링 도구를 통해 문제를 식별하려 했지만, 새로운 업데이트에 대한 충분한 정보를 받지 못했습니다. 개발팀에서 제공해야 할 세부 사항이 부족했어요."

은주: "이렇게 서로 책임을 전가하기만 한다면 문제를 해결할 수 없습니다. 지금 필요한 것은 상호 협력입니다. 각 팀 리더는 자신의 팀에서 할 수 있는 최선의 조치를 시작하고, 이 문제를 어떻게 해결할지 구체적인 방안을 마련해야 합니다."

진호, 혜린, 성민: (동시에) "알겠습니다."

데브옵스의 핵심가치 분석

소개되던 당시 운영이라함은 대부분 클라우드가 없던시절   하드웨어를 관리해야했던  인프라적인 운영이기는 하지만

데브옵스의 출범은 애자일의 핵심가치인 지속적 개선을 위한 걸림돌로   '개발과 운영팀소통' 의 문제를 제기하며

위와같은 상황극을 연출하고 필요한것이 무엇인지? 점진적으로 기술의 변화와함께 발전해 나갔습니다.


오늘날 데브옵스에서 운영의 정의는 시스템운영만으로 사실상 한정하지 않으며 소프트웨어 영역인 서비스 운영도 포함될수 있습니다. 

  • 시스템 운영 : 배포가 되고 서버를 안정적으로 작동시키고 CPU와같은 자원을 주로 모니터링함~
  • 서비스 운영 : 배포가 된이후 최종 사용자에게 잘전달되고 소프트웨어가 문제없이 잘 작동하는지 개발로그를 포함 APM레벨을 측정~


자동배포가 되었다라고 데브옵스의 미션이 완료되는것이 아니라 이 활동의 핵심은 운영되기까지 수동적 절차를 없애고 

고객에게 더 나은 가치를 제공는 그 자체이며  다음은 너무 빠르게 출시한 나머지 운영을 생각하지 못하고 시작된 가상의 서비스이며  다음문제를 해결하지 못한다고 하면

자동배포는 사실상 아무런 의미가 없습니다.


데브옵스 문화가 있다고하면 개발,운영이 협력해 다음과 같은 문제를 먼저 해결해야할것입니다. 

  • 새로운 고객은 우리 소프트웨어를 바로사용하고 싶지만 그 여정이 너무 어렵고 수동절차가 많아 여러명의 운영자가 셋팅을 해야하는 케이스
  • 가입 성공한 고객이  서비스 기능중 일부를 추가로 사용하고 싶지만 개발자가 쿼리지원을 해야지만 사용가능한 케이스 


데브옵스는 CI/CD 성숙도 기업에 따라 해결해야할 우선순위및 문제의 유형이 다를수 있으며 

우리가 개발한것을 잘운영되기 까지 함께 책임지는 문화라고 정리하며


마지막으로 이러한 데브옵스가 자동화및 운영효율화를 위해 채택하고 있는 24년 기술트렌드를 소개하며 마무리해봅니다.


24년 데브옵스 기술트렌드

  • 시스템 아키텍처 고도화
    • 쿠버네티스와 함께 마이크로 서비스 인기지속
    • MLOps - 최근 AI가 부각되면서 Ai 시스템을 잘 활용하는 MLOps가 함께 부각됨 
  • 시스템 운영 최소화
    • 서버운영이 최소화된 서버리스 사용 확대
    • 설치형에서 관리형인 PasS의 이용확대 
    • NoOps - laaS와 Pass를 적극채택한후 운영까지 과정을 자동화를 하여 운영이 축소되거나 운영할필요가 없는 개념입니다. 
      • 초기등장 무시 되었지만 클라우드전환및  AI의 발전및 비용 효율화와 함께 가시권에 들어오고 있습니다.  그래도 운영이 중요한 DevOps의 Next버전이 될수 있습니다.
  • 자동화 / 보안
    • GitOps 성장 - 코드를 통해 배포/인프라를 함께 정의
    • DevSecOps - 보안을 나중에 생각하지말고 처음부터 함께 생각
      • sec는 security의 약자로, 1초로 오인해 1초만에 배포되는 시스템으로 오인 할수 있습니다.
  • 옵저빌리티 - 시스템뿐만아니라 어플리케이션을 포함 운영파악에 필요한 모든것을 모니터링
    • 시스템 모니터링 - 시스템자원의 모니터링
      • 쿠버를 도입하면 시스템이란 개념보다 자원을 효율적으로 배치하기위한 POD 모니터링도 중요해졌습니다.
    • APM - 시스템 모니터링으로 운영문제를 파악하기에는 부족하며 더 디테일한 Application 까지 모니터링합니다.
    • 키바나/대시보드 - 개발로그를 모니터링하고 로그가 의미있으면 서비스 사용현황도 모니터링 할수 있습니다.

추가 아티컬  - 데브옵스 기술중 이제는 필수항목이 되어가는 쿠버(RKE)




  • No labels
Write a comment…