기고 | 원격 엔지니어 및 분산 팀을 위한 데브옵스 베스트 프랙티스

그 어느 때보다 데브옵스를 조직에 시도하기 좋은 시점이다. 그러나 데브옵스 엔지니어가 원격으로 애자일 개발자, 품질 보증 엔지니어, 사이트 안정성 엔지니어, 여타 시스템 관리자와 협력할 때 몇 가지 중요한 문제에 부딪힐 수 있다. 원격지의 데브옵스 엔지니어가 알아야 할 베스트 프랙티스를 살펴본다. 
 

첫 번째 문제는 운영 책임이다. 시스템 및 서비스가 안정적으로 운영되는 것을 보장해야 한다. ‘모니터링과 AI옵스의 미래’에 관한 최근의 설문조사에서, 61%의 응답자는 네트워크 운영 센터 및 데브옵스 엔지니어가 시스템 및 애플리케이션 사고에 대응해야 한다고 말했다. 즉 데브옵스 엔지니어는 운영 문제를 해결할 책임을 지니는 것이 일반적이다. 예를 들어, 인프라 규모 조정, 빌드 파이프라인의 장애 처리, 보안 문제에 관한 전문성을 제공해야 한다.

두 번째 문제는 개발 책임이다. 특히, 지속적 통합/지속적 배포(CI/CD) 파이프라인, 코드로서의 인프라(infrastructure as code), 여타 자동화의 개발과 지원이다. 데브옵스 엔지니어가 애자일 개발팀의 일원인 경우라면, 이용자의 의견을 반영해 자동화를 구축하거나 강화하는 경우가 존재할 수 있다. 

다른 경우라면, 데브옵스 엔지니어는 여러 개발 팀을 위해 자동화를 지원하는 공유 서비스 팀의 일원일 수 있다. 접근 방식에 관계없이, CI/CD 및 인프라 자동화를 생성하는 일은 기능 요건, 운영 환경, 컴플라이언스 요소, 보안 태세, 성능 고려사항을 이해하기 위한 협력을 요구한다. 

데브옵스 실무자는 개발 및 운영 책임을 지지만, 데브옵스는 보다 구체적으로 애플리케이션 개발 및 IT 운영 사이의 협업을 가리킨다. 필자의 데브옵스 정의는 협업에 중점을 둔다. 즉, “데브옵스는 문화, 협업 관행, 자동화를 통해 개발 및 운영 팀들을 정렬시켜, 하나의 생각 하에서 고객 경험을 향상시키고, 비즈니스 니즈에 신속히 대응하고, 혁신과 보안 및 운영이 조화를 이루도록 보장하는 것이다.”

데브옵스는 협업을 견인하고 문화를 함양하는 직무 원칙의 확립을 요한다. 데브옵스 엔지니어가 특히 원격으로 또는 분산 팀에서 일한다면 아래의 모범 사례를 눈여겨보는 것이 좋다. 

현재 상황에 적응하라 
첫 번째 중요한 포인트는 팀원이 누구이고 사용하는 협업 툴이 무엇인지 파악하는 것이다. 이는 단순하게 들린다. 그러나 툴이나 협업 관행을 어느 정도 자율적으로 선택할 수 있는 대규모 조직에서는 그렇지 않을 수 있다. 

데브옵스 엔지니어가 개발 업무에서는 한 툴 세트를 사용하고, 운영 문제에 대응하는 데에는 다른 툴 세트를 사용하는 경우라면 한층 더 복잡해진다. 

그러나 원격 엔지니어 및 분산 데브옵스 팀은 이러한 복잡성에 불만을 갖거나 사람들에게 통일된 업무 방식을 강요해서는 안 된다. 데브옵스 협업 및 문화가 성공하려면 원격 엔지니어는 팀이 이미 사용 중인 툴 및 원격 협업 관행을 수용해야 한다. 

다시 말해 CI/CD 파이프라인에 관해 일할 때에는 지라(Jira)에서 이용자 의견을 업데이트하고, 애플리케이션 경보가 있을 대 처웰(Cherwell)에서 티켓에 대응하고, 비즈니스 관계자와 슬랙에서 대화하는 것이다. 팀이 익숙하게 사용 중인 여러 툴을 사용하는 것이 원격 엔지니어에게 결정적이다. 

데브옵스 보고 기능 및 문서화에 투자하라 
데브옵스는 주로 지속 통합, 테스팅, 전개, 인프라, 애플리케이션 모니터링 등 자동화에 초점을 둔다. 책임감 있는 소프트웨어 개발자는 견고하고 안정적인 애플리케이션을 목표로 한다. 데브옵스 엔지니어도 자신이 맡은 자동화에서 그같이 해야 한다.

이들 자동화는 고객을 가지고 있다. 그리고 운영 사고가 있을 것이다. 예를 들어, 애플리케이션 개발자는 CI/CD 파이프라인의 고객이다. 그리고 시스템 IT 운영 부서는 코드로서의 인프라 스크립팅을 위한 고객이다. 두 집단은 빌드가 작동하지 않거나 인프라가 전개되지 않을 때 데브옵스 엔지니어까지 문제를 단계적으로 상승시킬 것이다.

이 단계적 상승은 원격 데브옵스 엔지니어나 분산 팀에게 특히 좋지 않다. 이로 인해 직무 수행에 지장이 발생한다면 모든 사람의 생산성과 협업이 영향을 받는다. 그리고 원격 근무에서는 문제를 해결하기 위해 팀원과 직접 접촉하는 것이 까다롭다.

데브옵스 엔지니어가 다른 엔지니어에게 서비스를 제공할 경우 데브옵스 자동화와 코드를 투명하게 하여 다른 사람도 지원이 가능하도록 할 수 있다. 보고서, 대시보드, 문서를 준비한다면 자동화는 다른 사람에 의해 검토, 진단, 개선될 수 있다. 자동화는 버전 컨트롤에 집중해야 하고, 자체 설명서 및 변화 관리 수단을 가져야 한다. 

또한 강력한 경보, 보고, 로깅도 필요하다. 원격 팀은 상세 경보를 생성하여 팀원이 도움을 요청하지 않고 이를 이해할 수 있도록 해야 한다. 빌드 파이프라인의 보고가 충분하다면 이용자는 무엇이 어디서 왜 고장이 났는지 이해할 수 있을 것이다. 인프라 셋업 및 구성이 코드로 자동화된 경우, 여기에 강력한 오류 체크 및 여타 정보 로깅을 추가한다면 최종 이용자는(엔지니어) 스스로 문제를 진단하고 해결할 수 있다. 

품질 및 보안 상에서 조직을 선도 
분산 팀의 또 다른 문제는 어떤 핵심 기능이 흔히 보거나 접할 수 없는 것인 경우, 다른 사람의 책임일 것이라고 오해하는 것이다. 데브옵스 사람들은 흔히 매우 가시적인 핵심 성과 지표에 집중한다. 예를 들어 전개 횟수, 문제 해결 평균 시간 등이다. 반면 자동화된 테스팅, 선제적 보안 등의 다른 요소는 뒷전이다. 

2020 데브섹옵스 커뮤니티 서베이에서 55%의 응답자가 최소한 1주일에 1회 전개한다고 말했고, 18%는 하루에도 여러 차례 전개한다고 말했다. 그러나 보안의 경우 45%의 응답자가 보안이 중요하기는 하지만 작업할 시간이 없다고 말했다. 

보안만이 유일한 공백이 아니다. 2019년 테스팅 현황 보고서에 따르면 기능 테스트의 50% 이상을 자동화했다고 말한 응답자는 25%에 불과했다.

이러한 공백은 수많은 데브옵스 조직에서 보편적이지만, 데브옵스 엔지니어가 원격으로 또는 분산 팀에서 일할 때 이는 처리하기가 더욱 어려워진다. 투자가 불충분한 기술적 기능에 솔선해서 책임을 지기는 쉽지 않다. 분산 팀이라면 더욱 그러하다.

보안과 품질에서 공백이 크다면 애자일 팀의 데브옵스 엔지니어는 백로그 상의 스파이크를 활용해 시프트-레프트 테스팅 및 CI/CD 보안 통합을 실험해야 한다. 이는 공백에 관심을 갖도록 하고 이를 처리할 책임을 지는 한 방법이다.  


* Isaac Sacolick는 애자일, 데브옵스, 데이터 과학을 다룬 ‘Driving Digital: The Leader’s Guide to Business Transformation through Technology’의 저자다. ciokr@idg.co.kr