2017.03.31

데브옵스의 성공 이후, 프로젝트의 중앙 IT 이전 전략

BrandPost Sponsored by HPE
Cameron Laird | HPE


데브옵스(DevOps)와 중앙 IT의 협력은 양쪽 모두에게 이익을 가져다 줍니다.

퍼블릭 클라우드 상에서 구축된 성공적인 데브옵스 프로젝트에 대해 생각해봅시다. 이제 그 프로젝트를 중앙 IT로 옮길 때입니다. 그러기 위해서는 무엇이 필요할까요? 관련되는 것은 무엇일까요?

이런 질문이 중요한 만큼, 답변도 간단하지만은 않습니다. 데브옵스 프로젝트와 접근방식의 인기 상승으로 데브옵스 자체의 의미는 다소 흐려졌습니다. 그 어떤 간단한 설명도 데브옵스라는 이름으로 지금 벌어지고 있는 모든 것을 담을 수는 없습니다.

데브옵스의 주요 주제
이 개요는 명확한 공식보다는 데브옵스의 3가지 중심 주제, 프로젝트를 중앙 IT로 옮겨야 하는 5가지 주요 이유, 그런 이전 작업에서 발생할 가능성이 있는 4가지 특정 긴장관계, 그리고 이런 긴장관계를 완화시키기 위한 방안을 규명합니다. 그 후 특정 조직 내부에서 특정 프로젝트에 대한 적용은 독자들의 몫입니다.

데브옵스에는 광범위한 관행이 있고 기술과 밀접한 관계를 맺고 있지만, 중앙 IT로의 이전은 다음 3가지 가정에 초점을 맞춰야 합니다.

- 클라우드는 컴퓨팅에 있어 고향이라 할 수 있습니다.

- 지속적인 개선은 개발과 유지보수에 대한 기본 모드입니다.

- 개발자는 고객 경험에 책임이 있습니다.

예측할 수 있는 함정
다음 원칙은 타당해 보일 수 있지만, 의도하지 않은 결과를 수반할 수 있습니다. 예를 들면, 데브옵스는 개발 도구를 사용해서 운영 프랙티스를 능률화 하는 동시에, 사일로를 무너뜨리고 운영 통찰력을 가진 개발 표준을 알려주기 위해 선의의 노력으로 시작되었습니다. 2017년, 데브옵스 실무자는 특정 기술이나 공학적 습관의 한계를 넘어 최종 사용자 경험, 서비스 유연성, 그리고 시장 민첩성을 향상시키는 폭넓은 시각에 자부심을 가지고 있습니다.

데브옵스가 제공할 것은 많지만, 단순히 전통적인 IT를 대체할 수는 없습니다. 가장 좋은 의도를 가진 데브옵스 전문가들도 때로는 레거시 서비스에 대한 액세스 보호, 비즈니스 연속성 요구사항, 조직전반에 대한 ID(Identity) 관리, 비용 효과성 등 일반적인 IT 책임사항을 처리하기 위해 필요한 심도 있는 전문성이 없을 수 있습니다.

데브옵스 이전은 섀도우 IT(Shadow IT)와 흥미로운 대조를 이루기도 합니다. 부서가 자사의 중앙 IT 대신에 일반 공급업체들로부터 구매하는, 일명 섀도우 IT는 잘 알려진 피할 수 없는 비즈니스 현실입니다. 데브옵스 프로젝트는 섀도우 IT에서 흔히 볼 수 있는 끔찍한 기술적 부채를 야기할 가능성이 훨씬 더 적다는 점에서 통상적인 섀도우 IT와 다릅니다. 스프레드시트 함수로 작성된 그래픽, 공유된 암호, 기이한 백업 방식, 등등이 그 예입니다. 그렇지만 예산, 보안, 데이터, 그리고 관리가 중앙 IT의 외부에 있다는 점에서는 개별적인 데브옵스 프로젝트가 섀도우 IT와 같다고 할 수 있습니다.

데브옵스는 지속적인 개선을 강조합니다. 이 강조는–지속적인 배포, 지속적인 통합 등에 의해 지지되는– 더 가끔씩 발생하는 IT 전통과 대조됩니다. 애자일하고, 지속적인 개선 스타일을 폭포수(Waterfall) 또는 준 폭포수 관리 접근방식과 통합할 수 있는 쉬운 솔루션은 존재하지 않습니다. 이 대립은 스타일 면에서의 한 긴장관계이며, 여기에 대한 해결방안은 이 개요의 범주에서 벗어나므로 다루지 않습니다. 당면과제인 이전을 위해, 공유된 비즈니스 목표에 주목하십시오. 애자일과 폭포수 방법론에 대한 세련된 종합 논의는 다음 기회에 알아보겠습니다.

데브옵스 프로젝트의 이전에 대한 모든 계획은 명확한 비즈니스 요구사항과 목표를 필요로 합니다. 비즈니스 요구사항은 기술적인 대응표라기보다는 중요한 지침에 더 가깝습니다. IT 책임자는 이전 프로젝트를 다음과 같이 옮길 수 있다고 생각할 수도 있습니다. Cloud::IAM->on-premises::ActiveDirectory. 이런 번역은 부차적입니다. 이 예에서 중요한 점은, 조직이 수천 개의 다른 기존 서비스에서 이미 의존하고 있을 수도 있는 ID 관리와 한 프로젝트의 ID 관리를 통합한다는 것입니다.

이런 비즈니스 요구사항들은 클라우드에서 벗어나기보다는, 긍정적인 목표로 방향도 설정돼야 할 것입니다. 높은 수준에서 보면, 데브옵스에서 IT로의 이전에 대한 일반적인 비즈니스 요구사항에는 다음과 같은 것들이 포함됩니다.

- 레거시 서비스와의 통합

- 오프 프레미스(Off-premises) 컴퓨팅의 위험으로부터 격리

- 기존 백업, 재해 복구, 그리고 비즈니스 연속성 프랙티스와의 통합

- 컴플라이언스(Compliance)와 거버넌스(Governance) 고려사항

- 비용 통제

명확하고 명문화 된 비즈니스 요구사항은 이전 프로젝트의 성공에 매우 중요합니다. 이런 요구사항에는 양 측 모두에서의 메트릭스(Metrics: 측정치)가 포함될 것이라는 점에 유의하십시오. 어떤 것은 데브옵스에 더 관련이 많고 어떤 것은 중앙 IT에 관련이 많아 보일 것입니다. 일반적인 프로젝트는 한 가지 종류의 구동에 한 달에 6만 5,000 달러를 절약하는 동시에 초당 최대 3,000 건의 요청을 처리할 수 있는 능력을 유지하는 것이 목표일 수 있습니다. 프로젝트에 정의되는 요구사항으로 데브옵스 프로세스 또는 중앙 IT 지원을 일환으로 전달되는 대상에 대한 책임 소재를 명확히 해야 합니다.

긴장관계에 창의성을 더하십시오
이런 종류의 이전은 흔히 클라우드에 대한 착각을 한 채로 시작됩니다. 데브옵스 실무자들은 클라우드가 가져다 주는 모든 이익에 대해 적절한 가치를 부여하지만, 때로는 똑 같은 이익이 온 프레미스(On-premises) 상황에서는 불가능하다고 순진하게 믿고 있습니다. 그렇다면, 토론의 출발점은 프라이빗 클라우드일 것입니다. 중앙 IT는 프라이빗 클라우드에 가격을 매기고 기존 데브옵스 프로젝트를 최소한의 기술 변경만으로 온프레미스로 이전함으로써 기준선을 설정할 수 있습니다.

이상적으로, 이런 접근방식은 클라우드를 이데올로기 전장에서 배제시킬 수 있을 것입니다. 기준선으로서 프라이빗 클라우드에 대한 명확한 비전을 가지면, 다른 모든 대안들은 데브옵스와 중앙 IT가 함께 건설적으로 고려하고 분석할 수 있는 구현상의 세부사항이 되어버립니다.

데브옵스와 중앙 IT 간의 또 다른 전형적인 관점 차이는 시간, 서비스 범위, 그리고 개발 스타일의 확장과 관련이 있습니다. 데브옵스는 종종 워크로드가 다중 인스턴스 – 가상 서버, 마이크로서비스, 등등 –에 의해서 처리된다고 확신하고 있습니다. 중앙 IT는 흔히 필요사항의 크기를 현실적으로 가늠하는데 더 많은 경험을 가지고 있습니다. 중앙 IT는 몇몇 서비스들–심지어는 업무에 중요한 서비스들까지도–은 단일한 아키텍처 또는 별다른 확장성이 없는 아키텍처 상에서 구동할 수 있을 정도로 가볍다는 것도 알고 있습니다. 앞으로 나아갈 최선의 방법은 앞에서 강조한 비즈니스 요구사항을 강조하고 구현 팀이 자신들이 믿을 수 있는 기술로 그런 요구사항들을 충족합니다.

앞의 두 가지와 필연적으로 연관된 데브옵스와 중앙 IT 간의 세 번째 공통적인 긴장관계는 데브옵스 전문가들이 흔히 자신들을 더 기술적으로 세련되고 빠르게 움직이고 있다고 평가하고 있다는 점입니다. 데브옵스는 IT가 레거시 자산을 억지로 떠맡고 있으며 비교적 최신의 것을 배우는데 흥미를 가지고 있지 않다고 보고 있습니다.

양 측 모두를 요구사항에 초점을 맞추고 공통적인 메트릭스를 사용하도록 강제함으로써 이런 갈등을 회피할 수 있습니다. 이전 요구사항 충족에 대한 공통적인 목표의 추구는 데브옵스와 IT가 협업하도록 부추깁니다. 이상적으로는 양 측 모두가 솔루션에 기여합니다. 이는 데브옵스가 프로젝트를 빼앗긴다는 것에서 데브옵스와 IT가 중요한 목표를 충족시키기 위해 함께 일한다는 것으로 논조를 바꿉니다.

마지막으로, 전통적인 데브옵스 문화는 너무나 계산적으로 “트랜잭션 지향적”이어서 종종 영속적인 데이터의 가치를 과소평가하고 있습니다. IT는 일반적으로 데이터를 장기적인 자산으로 소중하게 여기는 데이터 관리 관점에 더 많은 경험을 가지고 있습니다. 데이터 관리는 데브옵스뿐 아니라 시스템 관리, 네트워크 관리, 하드웨어, 보안, 사용자 경험, 그리고 IT가 일반적으로 교묘하게 처리하고 있는 다른 모든 영역에서도 뚜렷이 구별되는 전문성입니다. IT는 데브옵스 기여자와 데브옵스 실무자들이 무시했을 수도 있는 영속성 그리고 데이터의 다른 장점을 옹호할 수 있는 데이터 관리자를 짝 지우기 위해 세심히 살펴야 합니다.

건설적인 협업이 핵심입니다
클라우드는 단지 또 다른 컴퓨팅 중심지이고 구현 세부사항일 뿐입니다. 부서가 이 점을 이해하고, 클라우드와 그리고 클라우드에 누가, 무엇이 있는지에 대한 논쟁에서 벗어나게 하십시오. 비즈니스 목표와 요구사항을 강력하게 표현하고, 그들의 측정치와 보정치를 홍보하십시오.

구현 팀이 데브옵스와 IT 실무자 그리고 관점을 통합시킬 때, 이전을 억울해하면서 따르는 대신, 건설적으로 협업할 수 있습니다. 성공적인 이전이라면 앤서블이나 파워셸(PowerShell) 중 한 가지를 선택할 수도 있습니다(아니면, 또 다른 차원에서, NGINX 대 IIS(Internet Information Services)). 중요한 것은 팀이 전체로서 그러한 기술적인 선택사항을 결정하고 시험하기 위한 공통적인 프로세스를 확보한다는 것입니다. 개발과 운영 간의 협력, 그리고 비용산정에 있어서의 IT의 장점, 데이터 관리, 비즈니스 연속성, 그리고 컴플라이언스에 대해 데브옵스의 폭넓은 관점을 최대한 활용하십시오.

데브옵스에서 중앙 IT로 이동하기 : 리더를 위한 교훈

- IT 역할들 간의 경쟁이 아닙니다; 필요하다면 경쟁 당사자간 협력(coopetition)이라고 여기십시오.

- 중요한 것은 비즈니스입니다. 프로세스나 서비스의 최종 위치가 아니라, 최종 결과가 목표입니다.

- 각각의 그룹은 개선된 비즈니스 프로세스란 목표를 가지고, 자사 핵심 역량에 주력해야 합니다.


2017.03.31

데브옵스의 성공 이후, 프로젝트의 중앙 IT 이전 전략

BrandPost Sponsored by HPE
Cameron Laird | HPE


데브옵스(DevOps)와 중앙 IT의 협력은 양쪽 모두에게 이익을 가져다 줍니다.

퍼블릭 클라우드 상에서 구축된 성공적인 데브옵스 프로젝트에 대해 생각해봅시다. 이제 그 프로젝트를 중앙 IT로 옮길 때입니다. 그러기 위해서는 무엇이 필요할까요? 관련되는 것은 무엇일까요?

이런 질문이 중요한 만큼, 답변도 간단하지만은 않습니다. 데브옵스 프로젝트와 접근방식의 인기 상승으로 데브옵스 자체의 의미는 다소 흐려졌습니다. 그 어떤 간단한 설명도 데브옵스라는 이름으로 지금 벌어지고 있는 모든 것을 담을 수는 없습니다.

데브옵스의 주요 주제
이 개요는 명확한 공식보다는 데브옵스의 3가지 중심 주제, 프로젝트를 중앙 IT로 옮겨야 하는 5가지 주요 이유, 그런 이전 작업에서 발생할 가능성이 있는 4가지 특정 긴장관계, 그리고 이런 긴장관계를 완화시키기 위한 방안을 규명합니다. 그 후 특정 조직 내부에서 특정 프로젝트에 대한 적용은 독자들의 몫입니다.

데브옵스에는 광범위한 관행이 있고 기술과 밀접한 관계를 맺고 있지만, 중앙 IT로의 이전은 다음 3가지 가정에 초점을 맞춰야 합니다.

- 클라우드는 컴퓨팅에 있어 고향이라 할 수 있습니다.

- 지속적인 개선은 개발과 유지보수에 대한 기본 모드입니다.

- 개발자는 고객 경험에 책임이 있습니다.

예측할 수 있는 함정
다음 원칙은 타당해 보일 수 있지만, 의도하지 않은 결과를 수반할 수 있습니다. 예를 들면, 데브옵스는 개발 도구를 사용해서 운영 프랙티스를 능률화 하는 동시에, 사일로를 무너뜨리고 운영 통찰력을 가진 개발 표준을 알려주기 위해 선의의 노력으로 시작되었습니다. 2017년, 데브옵스 실무자는 특정 기술이나 공학적 습관의 한계를 넘어 최종 사용자 경험, 서비스 유연성, 그리고 시장 민첩성을 향상시키는 폭넓은 시각에 자부심을 가지고 있습니다.

데브옵스가 제공할 것은 많지만, 단순히 전통적인 IT를 대체할 수는 없습니다. 가장 좋은 의도를 가진 데브옵스 전문가들도 때로는 레거시 서비스에 대한 액세스 보호, 비즈니스 연속성 요구사항, 조직전반에 대한 ID(Identity) 관리, 비용 효과성 등 일반적인 IT 책임사항을 처리하기 위해 필요한 심도 있는 전문성이 없을 수 있습니다.

데브옵스 이전은 섀도우 IT(Shadow IT)와 흥미로운 대조를 이루기도 합니다. 부서가 자사의 중앙 IT 대신에 일반 공급업체들로부터 구매하는, 일명 섀도우 IT는 잘 알려진 피할 수 없는 비즈니스 현실입니다. 데브옵스 프로젝트는 섀도우 IT에서 흔히 볼 수 있는 끔찍한 기술적 부채를 야기할 가능성이 훨씬 더 적다는 점에서 통상적인 섀도우 IT와 다릅니다. 스프레드시트 함수로 작성된 그래픽, 공유된 암호, 기이한 백업 방식, 등등이 그 예입니다. 그렇지만 예산, 보안, 데이터, 그리고 관리가 중앙 IT의 외부에 있다는 점에서는 개별적인 데브옵스 프로젝트가 섀도우 IT와 같다고 할 수 있습니다.

데브옵스는 지속적인 개선을 강조합니다. 이 강조는–지속적인 배포, 지속적인 통합 등에 의해 지지되는– 더 가끔씩 발생하는 IT 전통과 대조됩니다. 애자일하고, 지속적인 개선 스타일을 폭포수(Waterfall) 또는 준 폭포수 관리 접근방식과 통합할 수 있는 쉬운 솔루션은 존재하지 않습니다. 이 대립은 스타일 면에서의 한 긴장관계이며, 여기에 대한 해결방안은 이 개요의 범주에서 벗어나므로 다루지 않습니다. 당면과제인 이전을 위해, 공유된 비즈니스 목표에 주목하십시오. 애자일과 폭포수 방법론에 대한 세련된 종합 논의는 다음 기회에 알아보겠습니다.

데브옵스 프로젝트의 이전에 대한 모든 계획은 명확한 비즈니스 요구사항과 목표를 필요로 합니다. 비즈니스 요구사항은 기술적인 대응표라기보다는 중요한 지침에 더 가깝습니다. IT 책임자는 이전 프로젝트를 다음과 같이 옮길 수 있다고 생각할 수도 있습니다. Cloud::IAM->on-premises::ActiveDirectory. 이런 번역은 부차적입니다. 이 예에서 중요한 점은, 조직이 수천 개의 다른 기존 서비스에서 이미 의존하고 있을 수도 있는 ID 관리와 한 프로젝트의 ID 관리를 통합한다는 것입니다.

이런 비즈니스 요구사항들은 클라우드에서 벗어나기보다는, 긍정적인 목표로 방향도 설정돼야 할 것입니다. 높은 수준에서 보면, 데브옵스에서 IT로의 이전에 대한 일반적인 비즈니스 요구사항에는 다음과 같은 것들이 포함됩니다.

- 레거시 서비스와의 통합

- 오프 프레미스(Off-premises) 컴퓨팅의 위험으로부터 격리

- 기존 백업, 재해 복구, 그리고 비즈니스 연속성 프랙티스와의 통합

- 컴플라이언스(Compliance)와 거버넌스(Governance) 고려사항

- 비용 통제

명확하고 명문화 된 비즈니스 요구사항은 이전 프로젝트의 성공에 매우 중요합니다. 이런 요구사항에는 양 측 모두에서의 메트릭스(Metrics: 측정치)가 포함될 것이라는 점에 유의하십시오. 어떤 것은 데브옵스에 더 관련이 많고 어떤 것은 중앙 IT에 관련이 많아 보일 것입니다. 일반적인 프로젝트는 한 가지 종류의 구동에 한 달에 6만 5,000 달러를 절약하는 동시에 초당 최대 3,000 건의 요청을 처리할 수 있는 능력을 유지하는 것이 목표일 수 있습니다. 프로젝트에 정의되는 요구사항으로 데브옵스 프로세스 또는 중앙 IT 지원을 일환으로 전달되는 대상에 대한 책임 소재를 명확히 해야 합니다.

긴장관계에 창의성을 더하십시오
이런 종류의 이전은 흔히 클라우드에 대한 착각을 한 채로 시작됩니다. 데브옵스 실무자들은 클라우드가 가져다 주는 모든 이익에 대해 적절한 가치를 부여하지만, 때로는 똑 같은 이익이 온 프레미스(On-premises) 상황에서는 불가능하다고 순진하게 믿고 있습니다. 그렇다면, 토론의 출발점은 프라이빗 클라우드일 것입니다. 중앙 IT는 프라이빗 클라우드에 가격을 매기고 기존 데브옵스 프로젝트를 최소한의 기술 변경만으로 온프레미스로 이전함으로써 기준선을 설정할 수 있습니다.

이상적으로, 이런 접근방식은 클라우드를 이데올로기 전장에서 배제시킬 수 있을 것입니다. 기준선으로서 프라이빗 클라우드에 대한 명확한 비전을 가지면, 다른 모든 대안들은 데브옵스와 중앙 IT가 함께 건설적으로 고려하고 분석할 수 있는 구현상의 세부사항이 되어버립니다.

데브옵스와 중앙 IT 간의 또 다른 전형적인 관점 차이는 시간, 서비스 범위, 그리고 개발 스타일의 확장과 관련이 있습니다. 데브옵스는 종종 워크로드가 다중 인스턴스 – 가상 서버, 마이크로서비스, 등등 –에 의해서 처리된다고 확신하고 있습니다. 중앙 IT는 흔히 필요사항의 크기를 현실적으로 가늠하는데 더 많은 경험을 가지고 있습니다. 중앙 IT는 몇몇 서비스들–심지어는 업무에 중요한 서비스들까지도–은 단일한 아키텍처 또는 별다른 확장성이 없는 아키텍처 상에서 구동할 수 있을 정도로 가볍다는 것도 알고 있습니다. 앞으로 나아갈 최선의 방법은 앞에서 강조한 비즈니스 요구사항을 강조하고 구현 팀이 자신들이 믿을 수 있는 기술로 그런 요구사항들을 충족합니다.

앞의 두 가지와 필연적으로 연관된 데브옵스와 중앙 IT 간의 세 번째 공통적인 긴장관계는 데브옵스 전문가들이 흔히 자신들을 더 기술적으로 세련되고 빠르게 움직이고 있다고 평가하고 있다는 점입니다. 데브옵스는 IT가 레거시 자산을 억지로 떠맡고 있으며 비교적 최신의 것을 배우는데 흥미를 가지고 있지 않다고 보고 있습니다.

양 측 모두를 요구사항에 초점을 맞추고 공통적인 메트릭스를 사용하도록 강제함으로써 이런 갈등을 회피할 수 있습니다. 이전 요구사항 충족에 대한 공통적인 목표의 추구는 데브옵스와 IT가 협업하도록 부추깁니다. 이상적으로는 양 측 모두가 솔루션에 기여합니다. 이는 데브옵스가 프로젝트를 빼앗긴다는 것에서 데브옵스와 IT가 중요한 목표를 충족시키기 위해 함께 일한다는 것으로 논조를 바꿉니다.

마지막으로, 전통적인 데브옵스 문화는 너무나 계산적으로 “트랜잭션 지향적”이어서 종종 영속적인 데이터의 가치를 과소평가하고 있습니다. IT는 일반적으로 데이터를 장기적인 자산으로 소중하게 여기는 데이터 관리 관점에 더 많은 경험을 가지고 있습니다. 데이터 관리는 데브옵스뿐 아니라 시스템 관리, 네트워크 관리, 하드웨어, 보안, 사용자 경험, 그리고 IT가 일반적으로 교묘하게 처리하고 있는 다른 모든 영역에서도 뚜렷이 구별되는 전문성입니다. IT는 데브옵스 기여자와 데브옵스 실무자들이 무시했을 수도 있는 영속성 그리고 데이터의 다른 장점을 옹호할 수 있는 데이터 관리자를 짝 지우기 위해 세심히 살펴야 합니다.

건설적인 협업이 핵심입니다
클라우드는 단지 또 다른 컴퓨팅 중심지이고 구현 세부사항일 뿐입니다. 부서가 이 점을 이해하고, 클라우드와 그리고 클라우드에 누가, 무엇이 있는지에 대한 논쟁에서 벗어나게 하십시오. 비즈니스 목표와 요구사항을 강력하게 표현하고, 그들의 측정치와 보정치를 홍보하십시오.

구현 팀이 데브옵스와 IT 실무자 그리고 관점을 통합시킬 때, 이전을 억울해하면서 따르는 대신, 건설적으로 협업할 수 있습니다. 성공적인 이전이라면 앤서블이나 파워셸(PowerShell) 중 한 가지를 선택할 수도 있습니다(아니면, 또 다른 차원에서, NGINX 대 IIS(Internet Information Services)). 중요한 것은 팀이 전체로서 그러한 기술적인 선택사항을 결정하고 시험하기 위한 공통적인 프로세스를 확보한다는 것입니다. 개발과 운영 간의 협력, 그리고 비용산정에 있어서의 IT의 장점, 데이터 관리, 비즈니스 연속성, 그리고 컴플라이언스에 대해 데브옵스의 폭넓은 관점을 최대한 활용하십시오.

데브옵스에서 중앙 IT로 이동하기 : 리더를 위한 교훈

- IT 역할들 간의 경쟁이 아닙니다; 필요하다면 경쟁 당사자간 협력(coopetition)이라고 여기십시오.

- 중요한 것은 비즈니스입니다. 프로세스나 서비스의 최종 위치가 아니라, 최종 결과가 목표입니다.

- 각각의 그룹은 개선된 비즈니스 프로세스란 목표를 가지고, 자사 핵심 역량에 주력해야 합니다.


X