2020.11.27

데브옵스를 성공적으로 확장하는 기업의 3가지 특징

Scott Carey | InfoWorld
데브옵스 여정에서 앞서 나가는 기업은 셀프 서비스 내부 플랫폼과 자동화된 변경 관리 프로세스, 통합 보안을 활용한다는 조사 결과가 나왔다. 퍼펫(Puppet)과 서클CI(CircleCI)가 전 세계 3만 5,000명 이상의 기술 전문가를 대상으로 데브옵스와 애자일 프랙티스의 지속적인 채택에 대해 조사한 결과다. 이 ‘2020년 데브옵스 현황’ 공동 보고서에 따르면, 가장 성숙하고 성과가 좋은 기업에는 3가지 특징이 있었다. 바로 내부 플랫폼 활용과 효과적인 변경 관리 프로세스 수립, 긴밀한 보안 통합이다. 하나씩 살펴보자.
 
ⓒ Florian Olivo / Nathan Dumlao / Modified by IDG Comm.https://unsplash.com/photos/mNLymMqX7iE (CC0)
 

내부 플랫폼 구축

내부 플랫폼은 기업에 강력한 제품 중심의 팀이 있고, 각 팀이 제품이나 서비스의 엔드투엔드 제공을 담당할 때 나타난다. 이 내부 플랫폼은 보통 인프라와 테스트 환경, 배포 파이프라인, API, 도구, 지식, 거버넌스, 지원을 자체적으로 조달하는 원스톱 상점 등으로 구성된다. 이 내부 플랫폼을 담당하는 팀은 일반적으로 비즈니스 요구사항을 수집하고, 제품 로드맵을 제공하며, 새로운 사용자를 돕는다.

애플리케이션 개발팀은 내부 플랫폼을 사용해 표준화된 방식으로 앱을 구축, 배포, 실행할 수 있다. 하지만 AWS나 애저, 구글 클라우드 플랫폼, IBM/레드햇, VM웨어 같은 업체가 판매하는 PaaS(Platform as a Service)와는 다르다.

다른 훌륭한 아이디어와 마찬가지로, 수백 개의 제품 및 서비스 그리고 각각 고유한 프로세스와 기술 스택을 제공하는 다양한 팀이 있는 매우 복잡한 기업에 데브옵스를 적용하면 완전히 실패하는 경우가 종종 있다. 보고서에 따르면, 데브옵스가 종종 더는 확장하지 못하는 한 가지 이유는 기업이 추구해야 할 결과에 대해 잘못된 인센티브를 제공하고 책임감이나 주체 의식 부족을 야기하는 방식으로 구조화돼있기 때문으로 나타났다.
 

엔터프라이즈 데브옵스의 당면과제

엔터프라이즈 데브옵스에 공통된 문제를 야기하는 것이 바로 표준화의 부족이다. 보고서는 특히 다음의 3가지를 지적했다.
 
  • 거버넌스는 비용이 많이 들고, 관리하기가 거의 불가능하다.
  • (팀별로) 개별적인 스택은 기업 전체에 공유되는 지식을 줄인다.
  • 많은 제품팀이 실제로 전체 인프라와 애플리케이션 스택을 운영할 수 있는 기술이나 전문지식이 없다.

개발자 경험을 염두에 두고 플랫폼을 구축하면 데브옵스 프랙티스를 표준화하고, 전반적으로 업무와 비용을 줄일 수 있다. 이 플랫폼을 통해 자체 조달과 구성, 관리가 가능해지고, 각 팀은 중앙 통제 역할을 하는 팀이 인프라를 준비할 때까지 기다릴 필요 없이 각자의 제품에 집중할 수 있다.

보고서는 "개발자 경험과 흐름에 집중해야 한다. ‘공감’이 중요한 기술이라는 점은 아무리 강조해도 지나치지 않다. 공감이란 누군가의 입장을 이해한다는 뜻이며, 사용자에 대한 공감 없이 좋은 제품을 만드는 것은 불가능하다”라고 강조했다.

내부 플랫폼 구축은 데브옵스 현황 설문조사 응답자 사이에서 점점 인기를 얻고 있는 항목이다. 응답자 63%가 하나 이상의 자체 조달 내부 플랫폼을 보유하고 있다고 답했다. 이 중 60%는 2~4개의 인터널 플랫폼을 보유한 것으로 나타났다. 인터널 플랫폼이 있다고 답한 응답자 중 거의 1/3이 26~50%의 (팀 내부) 개발자가 하나 이상의 내부 플랫폼을 사용한다고 답했다.

이처럼 플랫폼이 확산하는 이유는 성공하는 데브옵스 실무자를 보면, 특정 팀 또는 퍼블릭 클라우드처럼 특정 유형을 위한 플랫폼을 구축해 소규모로 시작한 후 여기서 확장하는 방식을 활용하기 때문이다. 이런 방식은 팀에 필요한 것이 무엇인지에 대한 광범위한 가정에 기초해 플랫폼을 구축하는 방식보다 훨씬 합리적이다. '만들어 두면, 알아서 사용하게 된다'는 명제는 실패하기 마련이다.

더 주목해야 할 점은 보고서에서 가장 데브옵스가 성숙했다고 정의한 기업의 내부 플랫폼 사용률이다. 중간 수준의 기업보다 거의 두 배, 낮은 수준의 기업보다 6배 더 높은 것으로 나타났다.
 

변경 관리 표준화

아직 내부 플랫폼 구축을 위해 노력하는 기업이라면 효과적인 변경 관리에서 시작하는 것이 좋다. 워터폴(Waterfall) 방식의 프로젝트와 대규모 소프트웨어 배포로부터 마이크로서비스 및 더 빠르고 정기적인 배포 주기로의 매크로 전환으로 인해 데브옵스가 확산할 수 있었고, 팀은 끊임없는 변화를 수용해야 한다. 이런 상황에서 변경 관리 프로세스를 일관되게 만드는 것은 엔터프라이즈급 데브옵스에서 가장 어려운 부분 중 하나다. 또한 더 많은 소프트웨어를 더 자주 배포하려는 모든 사람에게 중요한 차별화 요소이기도 하다.

설문 응답자들은 효과적인 변경 관리에 대한 가장 큰 장벽으로 불완전한 테스트 범위를 꼽았다. 그다음으로 확립된 조직적 사고방식과 긴밀하게 연결된 애플리케이션 아키텍처가 뒤를 이었다. 기업은 변경 관리와 배포 관리, 감사, 규정 준수 관리팀 간의 사일로를 제거하고, 효과적인 피드백 순환과정을 만들고, 진행 상황을 추적해야 변경 관리 프로세스를 개선할 수 있다.

변경 관리에 성공하고 있는지는 변경 실패율과 배포 빈도, 승인에 대한 효율성 수준, 비즈니스에 허용되는 위험 수준과 같은 핵심 지표를 추적해 측정할 수 있다. 보고서에 따르면, 가장 효과적인 변경 관리 프로세스는 팀이 다음을 이행할 때 구축할 수 있다.
 
  • 높은 수준의 테스트 및 배포 자동화
  • 높은 수준의 자동화된 위험 완화
  • 덜 엄격하고 훨씬 덜 수동적인 승인 프로세스
  • 코드에서 변경 사항 작성
  • 직원이 변경 관리에 더 많은 영향을 미칠 수 있도록 허용
  • 데브옵스 프로세스와 문화

요컨대, 자동화가 증가하면 변경 관리에 대한 신뢰가 생긴다. 보고서는 매우 높은 수준으로 정통적인 승인 절차를 따르는 기업이 낮은 수준의 기업보다 변경 관리 프로세서에서 비효율성이 9배 더 높다는 것을 발견했다. 자동화된 변경 관리의 범위는 2차 검토, 즉 자동화가 없는 단계에서 시작해, 기본적으로 제공되는 위험 평가와 즉각적인 진행 기능을 갖춘 완전 자동화된 배포 및 테스트의 이상적인 단계까지 아우른다.
 

보안 통합에 집중

마지막으로, 보고서는 보안 통합에 초점을 맞췄다. 더 높은 수준의 보안 통합을 달성한 기업이 더 높은 단계의 데브옵스로 발전할 가능성이 크다고 결론 내렸다.

특히 보안 통합을 통해 완전히 다른 접근 방식, 즉 팀 간 협업을 개선하고 배포팀이 보안 문제를 자율적으로 예방, 발견, 해결할 수 있다. 팀 간의 지식 사일로를 허물고 보안을 개선하기 위해 협력하면 보안 문제에 대한 전반적인 인식을 높여, 모든 사람이, 심지어 보안 팀 외부 사람까지도, 보안 보호를 위해 알려진 패턴을 채택할 가능성이 커진다.

보고서는 ‘보안을 소프트웨어 배포 프로세스에 완전히 통합하는 능력’과 ‘중요한 취약점을 신속하게 해결하는 기업의 능력’ 간에 강한 상관관계가 있다는 것도 확인했다. 구체적으로, (조사 대상 중) 완전한 보안 통합을 갖춘 기업 중 45%가 하루 만에 중요한 취약점을 해결할 수 있다고 보고한 반면, 낮은 수준의 보안 통합을 한 기업은 단 25%만이 가능하다고 답했다. editor@itworld.co.kr



2020.11.27

데브옵스를 성공적으로 확장하는 기업의 3가지 특징

Scott Carey | InfoWorld
데브옵스 여정에서 앞서 나가는 기업은 셀프 서비스 내부 플랫폼과 자동화된 변경 관리 프로세스, 통합 보안을 활용한다는 조사 결과가 나왔다. 퍼펫(Puppet)과 서클CI(CircleCI)가 전 세계 3만 5,000명 이상의 기술 전문가를 대상으로 데브옵스와 애자일 프랙티스의 지속적인 채택에 대해 조사한 결과다. 이 ‘2020년 데브옵스 현황’ 공동 보고서에 따르면, 가장 성숙하고 성과가 좋은 기업에는 3가지 특징이 있었다. 바로 내부 플랫폼 활용과 효과적인 변경 관리 프로세스 수립, 긴밀한 보안 통합이다. 하나씩 살펴보자.
 
ⓒ Florian Olivo / Nathan Dumlao / Modified by IDG Comm.https://unsplash.com/photos/mNLymMqX7iE (CC0)
 

내부 플랫폼 구축

내부 플랫폼은 기업에 강력한 제품 중심의 팀이 있고, 각 팀이 제품이나 서비스의 엔드투엔드 제공을 담당할 때 나타난다. 이 내부 플랫폼은 보통 인프라와 테스트 환경, 배포 파이프라인, API, 도구, 지식, 거버넌스, 지원을 자체적으로 조달하는 원스톱 상점 등으로 구성된다. 이 내부 플랫폼을 담당하는 팀은 일반적으로 비즈니스 요구사항을 수집하고, 제품 로드맵을 제공하며, 새로운 사용자를 돕는다.

애플리케이션 개발팀은 내부 플랫폼을 사용해 표준화된 방식으로 앱을 구축, 배포, 실행할 수 있다. 하지만 AWS나 애저, 구글 클라우드 플랫폼, IBM/레드햇, VM웨어 같은 업체가 판매하는 PaaS(Platform as a Service)와는 다르다.

다른 훌륭한 아이디어와 마찬가지로, 수백 개의 제품 및 서비스 그리고 각각 고유한 프로세스와 기술 스택을 제공하는 다양한 팀이 있는 매우 복잡한 기업에 데브옵스를 적용하면 완전히 실패하는 경우가 종종 있다. 보고서에 따르면, 데브옵스가 종종 더는 확장하지 못하는 한 가지 이유는 기업이 추구해야 할 결과에 대해 잘못된 인센티브를 제공하고 책임감이나 주체 의식 부족을 야기하는 방식으로 구조화돼있기 때문으로 나타났다.
 

엔터프라이즈 데브옵스의 당면과제

엔터프라이즈 데브옵스에 공통된 문제를 야기하는 것이 바로 표준화의 부족이다. 보고서는 특히 다음의 3가지를 지적했다.
 
  • 거버넌스는 비용이 많이 들고, 관리하기가 거의 불가능하다.
  • (팀별로) 개별적인 스택은 기업 전체에 공유되는 지식을 줄인다.
  • 많은 제품팀이 실제로 전체 인프라와 애플리케이션 스택을 운영할 수 있는 기술이나 전문지식이 없다.

개발자 경험을 염두에 두고 플랫폼을 구축하면 데브옵스 프랙티스를 표준화하고, 전반적으로 업무와 비용을 줄일 수 있다. 이 플랫폼을 통해 자체 조달과 구성, 관리가 가능해지고, 각 팀은 중앙 통제 역할을 하는 팀이 인프라를 준비할 때까지 기다릴 필요 없이 각자의 제품에 집중할 수 있다.

보고서는 "개발자 경험과 흐름에 집중해야 한다. ‘공감’이 중요한 기술이라는 점은 아무리 강조해도 지나치지 않다. 공감이란 누군가의 입장을 이해한다는 뜻이며, 사용자에 대한 공감 없이 좋은 제품을 만드는 것은 불가능하다”라고 강조했다.

내부 플랫폼 구축은 데브옵스 현황 설문조사 응답자 사이에서 점점 인기를 얻고 있는 항목이다. 응답자 63%가 하나 이상의 자체 조달 내부 플랫폼을 보유하고 있다고 답했다. 이 중 60%는 2~4개의 인터널 플랫폼을 보유한 것으로 나타났다. 인터널 플랫폼이 있다고 답한 응답자 중 거의 1/3이 26~50%의 (팀 내부) 개발자가 하나 이상의 내부 플랫폼을 사용한다고 답했다.

이처럼 플랫폼이 확산하는 이유는 성공하는 데브옵스 실무자를 보면, 특정 팀 또는 퍼블릭 클라우드처럼 특정 유형을 위한 플랫폼을 구축해 소규모로 시작한 후 여기서 확장하는 방식을 활용하기 때문이다. 이런 방식은 팀에 필요한 것이 무엇인지에 대한 광범위한 가정에 기초해 플랫폼을 구축하는 방식보다 훨씬 합리적이다. '만들어 두면, 알아서 사용하게 된다'는 명제는 실패하기 마련이다.

더 주목해야 할 점은 보고서에서 가장 데브옵스가 성숙했다고 정의한 기업의 내부 플랫폼 사용률이다. 중간 수준의 기업보다 거의 두 배, 낮은 수준의 기업보다 6배 더 높은 것으로 나타났다.
 

변경 관리 표준화

아직 내부 플랫폼 구축을 위해 노력하는 기업이라면 효과적인 변경 관리에서 시작하는 것이 좋다. 워터폴(Waterfall) 방식의 프로젝트와 대규모 소프트웨어 배포로부터 마이크로서비스 및 더 빠르고 정기적인 배포 주기로의 매크로 전환으로 인해 데브옵스가 확산할 수 있었고, 팀은 끊임없는 변화를 수용해야 한다. 이런 상황에서 변경 관리 프로세스를 일관되게 만드는 것은 엔터프라이즈급 데브옵스에서 가장 어려운 부분 중 하나다. 또한 더 많은 소프트웨어를 더 자주 배포하려는 모든 사람에게 중요한 차별화 요소이기도 하다.

설문 응답자들은 효과적인 변경 관리에 대한 가장 큰 장벽으로 불완전한 테스트 범위를 꼽았다. 그다음으로 확립된 조직적 사고방식과 긴밀하게 연결된 애플리케이션 아키텍처가 뒤를 이었다. 기업은 변경 관리와 배포 관리, 감사, 규정 준수 관리팀 간의 사일로를 제거하고, 효과적인 피드백 순환과정을 만들고, 진행 상황을 추적해야 변경 관리 프로세스를 개선할 수 있다.

변경 관리에 성공하고 있는지는 변경 실패율과 배포 빈도, 승인에 대한 효율성 수준, 비즈니스에 허용되는 위험 수준과 같은 핵심 지표를 추적해 측정할 수 있다. 보고서에 따르면, 가장 효과적인 변경 관리 프로세스는 팀이 다음을 이행할 때 구축할 수 있다.
 
  • 높은 수준의 테스트 및 배포 자동화
  • 높은 수준의 자동화된 위험 완화
  • 덜 엄격하고 훨씬 덜 수동적인 승인 프로세스
  • 코드에서 변경 사항 작성
  • 직원이 변경 관리에 더 많은 영향을 미칠 수 있도록 허용
  • 데브옵스 프로세스와 문화

요컨대, 자동화가 증가하면 변경 관리에 대한 신뢰가 생긴다. 보고서는 매우 높은 수준으로 정통적인 승인 절차를 따르는 기업이 낮은 수준의 기업보다 변경 관리 프로세서에서 비효율성이 9배 더 높다는 것을 발견했다. 자동화된 변경 관리의 범위는 2차 검토, 즉 자동화가 없는 단계에서 시작해, 기본적으로 제공되는 위험 평가와 즉각적인 진행 기능을 갖춘 완전 자동화된 배포 및 테스트의 이상적인 단계까지 아우른다.
 

보안 통합에 집중

마지막으로, 보고서는 보안 통합에 초점을 맞췄다. 더 높은 수준의 보안 통합을 달성한 기업이 더 높은 단계의 데브옵스로 발전할 가능성이 크다고 결론 내렸다.

특히 보안 통합을 통해 완전히 다른 접근 방식, 즉 팀 간 협업을 개선하고 배포팀이 보안 문제를 자율적으로 예방, 발견, 해결할 수 있다. 팀 간의 지식 사일로를 허물고 보안을 개선하기 위해 협력하면 보안 문제에 대한 전반적인 인식을 높여, 모든 사람이, 심지어 보안 팀 외부 사람까지도, 보안 보호를 위해 알려진 패턴을 채택할 가능성이 커진다.

보고서는 ‘보안을 소프트웨어 배포 프로세스에 완전히 통합하는 능력’과 ‘중요한 취약점을 신속하게 해결하는 기업의 능력’ 간에 강한 상관관계가 있다는 것도 확인했다. 구체적으로, (조사 대상 중) 완전한 보안 통합을 갖춘 기업 중 45%가 하루 만에 중요한 취약점을 해결할 수 있다고 보고한 반면, 낮은 수준의 보안 통합을 한 기업은 단 25%만이 가능하다고 답했다. editor@itworld.co.kr

X