2014.02.14

데브옵스로 클라우드 ALM을 가속화하는 법

Bernard Golden | CIO

과거에는 인프라스트럭처 도입과 애플리케이션 업데이트가 모두 느렸다. 그러나 클라우드 컴퓨팅으로 인해 이제 인프라 배치는 몇 분만에 끝난다. 즉 이제는 애플리케이션 라이프사이클을 가속화해야 하는 시기다. 여기에 데브옵스가 일조할 수 있다. 그러나 문화적 변화를 넘어서 실제 지속적 배치를 달성할 수 있을 때 가능한 이야기다.

지난 기사에서 밝혔듯이 클라우드 컴퓨팅을 통해 애플리케이션에 엄청난 변화가 있을 것이다. 해당 기사에서 필자는 애플리케이션 아키텍처의 향상된 확장 및 부하 가변성, 더 높은 성능 기대, 클라우드 컴퓨팅에 의한 가격 변동 등을 위한 클라우드 컴퓨팅이 직면하고 있는 기술적 변화에 초점을 맞추었다.

-> 칼럼 | 클라우드 애플리케이션 설계 패러다임

하지만 필자가 다루지 않은 부분도 있었다. 클라우드 컴퓨팅이 뒤바뀌고 있다는 또 다른 전통적인 애플리케이션에 관한 가정이었다. 그것은 바로 애플리케이션 라이프사이클에 관한 것이었다. 구체적으로 말해 클라우드는 훨씬 빠른 애플리케이션 관리 리듬을 필요로 하며, 이 때문에 IT 기관에 변화의 바람이 불 것이다.

겉보기에는 클라우드 컴퓨팅의 잠재력이 IT 부문과 프로세스를 바꿀 만한 이유가 분명해 보이지 않을 수 있다. 하지만 클라우드 컴퓨팅이 제공하는 기술적 역량의 핵심적 기초인 자동화를 위해서는 애플리케이션 라이프사이클을 가속화해야 한다.

클라우드 컴퓨팅은 인프라가 아니라 조직에 책임을 맡기고 있다
과거, 즉 클라우드 컴퓨팅 이전 시기에는 애플리케이션 기능 생성과 출시가 늦다고 해서 문제될 것이 없었다. 기본적인 자원 인프라 프로세스에 엄청난 마찰이 있었기 때문에 애플리케이션의 기능을 신속하게 향상시키고 생산 환경을 자주 바꾸는 것은 상상도 못했다.

인프라를 확보, 설치, 구성하는데 너무 오래 걸렸기 때문에 속도가 느린 애플리케이션 개발 및 배치는 IT가 직면하고 있는 문제로 여겨지지 않았다. 다시 말해서 인프라 문제가 애플리케이션 문제보다 극심했다.

그러나 클라우드 컴퓨팅이 자동화되면서 이 모든 인프라 마찰이 사라져 버렸다. 오늘날, 새로운 컴퓨팅 자원은 수 분 만에 확보할 수 있으며 과거 새로운 인프라 자원을 확보하기 위해 소요되던 수 주(또는 수 개월)의 시간에 비하면 비약적으로 단축되었다. 이제는 지루한 인프라 준비 기간의 대부분은 인프라 자원 자체가 아니라 기관의 프로세스에 의해 발생하고 있다.

이와 동시에 디지털 정보가 점차 주류 비즈니스 서비스로 통합되면서 비즈니스의 운영부분에 있어서 애플리케이션을 더욱 신속하게 사용할 수 있는 필요성이 대두됐다.

인프라 마찰이 사라짐에 따라 주된 장애물은 이제 애플리케이션 라이프사이클 자체가 되었다. 그 결과, 클라우드 컴퓨팅에 의한 앞으로의 혼란은 애플리케이션 개발과 배치 프로세스에서 발생할 것으로 예상할 수 있다. 쉽게 말해서 IT는 반드시 애플리케이션 라이프사이클을 더욱 빠르게 해야 한다.

여기에서 데브옵스(DevOps)의 역할이 중요하다. "개발(Development)"과 "운영(Operation)"의 합성어인 데브옵스는 이전에 개별적으로 존재하던 기관과 프로세스의 융합을 상징한다. 그 비전은 융합된 프로세스를 통해 애플리케이션 업데이트를 가속화하여 수 주(또는 수 개월) 대신에 수 시간 또는 수 일 만에 변경사항을 제공할 수 있는 최적화되고 통합된 기관을 지향한다.

하지만 이런 마법 같은 데브옵스의 효과가 어떻게 실현될 수 있을까?

문화적 변화가 필요하긴 하지만 충분하지는 않다
종종 문화적 변화가 해결책으로 언급되곤 한다. 개발자 및 시스템 관리자들이 한 팀으로써 협력하도록 할 수 있다면 협력을 향상시켜 애플리케이션 라이프사이클을 가속화할 수 있을 것이라는 기대다.

그러나 필자는 이런 접근방식을 그다지 선호하지 않는다. 물론 개발과 운영 사이의 마찰은 비일비재하며 같은 팀에 소속된다면 분명 개인적인 관계는 향상될 것이다. 이런 접근방식은 협력을 증진시키고 서로를 비난하는 행위를 줄여 현재의 상태를 점진적으로 향상시킬 수도 있을 것이다. 하지만 개인적인 상호작용이 개선된다고 해서 애플리케이션 기능 공개 사이클이 가속화된다는 보장은 없다.

경우에 따라서 점진적인 개선으로는 불충분하다. 기업들이 기능 공개를 20% 가속화한다고 해서 현재 직면하고 있는 디지털 비즈니스 환경의 미래에 성공할 수는 없는 노릇이다. 고작해야 21일짜리 프로젝트를 18일로 단축하거나 6개월짜리 프로젝트를 5개월 수준으로 단축할 수 있을 뿐이다. 오늘날의 기업들은 200% 이상의 속도 증가를 필요로 하고 있다.

즉 문화에 관한 주장은 어불성설이라는 것이다. 정작 문제가 있는 것은 프로세스인데, 프로세스가 아닌 사람에 초점을 두고 있는 것이다. 또한 프로세스는 애플리케이션 라이프사이클 전반에 걸쳐 빨라져야 한다.




2014.02.14

데브옵스로 클라우드 ALM을 가속화하는 법

Bernard Golden | CIO

과거에는 인프라스트럭처 도입과 애플리케이션 업데이트가 모두 느렸다. 그러나 클라우드 컴퓨팅으로 인해 이제 인프라 배치는 몇 분만에 끝난다. 즉 이제는 애플리케이션 라이프사이클을 가속화해야 하는 시기다. 여기에 데브옵스가 일조할 수 있다. 그러나 문화적 변화를 넘어서 실제 지속적 배치를 달성할 수 있을 때 가능한 이야기다.

지난 기사에서 밝혔듯이 클라우드 컴퓨팅을 통해 애플리케이션에 엄청난 변화가 있을 것이다. 해당 기사에서 필자는 애플리케이션 아키텍처의 향상된 확장 및 부하 가변성, 더 높은 성능 기대, 클라우드 컴퓨팅에 의한 가격 변동 등을 위한 클라우드 컴퓨팅이 직면하고 있는 기술적 변화에 초점을 맞추었다.

-> 칼럼 | 클라우드 애플리케이션 설계 패러다임

하지만 필자가 다루지 않은 부분도 있었다. 클라우드 컴퓨팅이 뒤바뀌고 있다는 또 다른 전통적인 애플리케이션에 관한 가정이었다. 그것은 바로 애플리케이션 라이프사이클에 관한 것이었다. 구체적으로 말해 클라우드는 훨씬 빠른 애플리케이션 관리 리듬을 필요로 하며, 이 때문에 IT 기관에 변화의 바람이 불 것이다.

겉보기에는 클라우드 컴퓨팅의 잠재력이 IT 부문과 프로세스를 바꿀 만한 이유가 분명해 보이지 않을 수 있다. 하지만 클라우드 컴퓨팅이 제공하는 기술적 역량의 핵심적 기초인 자동화를 위해서는 애플리케이션 라이프사이클을 가속화해야 한다.

클라우드 컴퓨팅은 인프라가 아니라 조직에 책임을 맡기고 있다
과거, 즉 클라우드 컴퓨팅 이전 시기에는 애플리케이션 기능 생성과 출시가 늦다고 해서 문제될 것이 없었다. 기본적인 자원 인프라 프로세스에 엄청난 마찰이 있었기 때문에 애플리케이션의 기능을 신속하게 향상시키고 생산 환경을 자주 바꾸는 것은 상상도 못했다.

인프라를 확보, 설치, 구성하는데 너무 오래 걸렸기 때문에 속도가 느린 애플리케이션 개발 및 배치는 IT가 직면하고 있는 문제로 여겨지지 않았다. 다시 말해서 인프라 문제가 애플리케이션 문제보다 극심했다.

그러나 클라우드 컴퓨팅이 자동화되면서 이 모든 인프라 마찰이 사라져 버렸다. 오늘날, 새로운 컴퓨팅 자원은 수 분 만에 확보할 수 있으며 과거 새로운 인프라 자원을 확보하기 위해 소요되던 수 주(또는 수 개월)의 시간에 비하면 비약적으로 단축되었다. 이제는 지루한 인프라 준비 기간의 대부분은 인프라 자원 자체가 아니라 기관의 프로세스에 의해 발생하고 있다.

이와 동시에 디지털 정보가 점차 주류 비즈니스 서비스로 통합되면서 비즈니스의 운영부분에 있어서 애플리케이션을 더욱 신속하게 사용할 수 있는 필요성이 대두됐다.

인프라 마찰이 사라짐에 따라 주된 장애물은 이제 애플리케이션 라이프사이클 자체가 되었다. 그 결과, 클라우드 컴퓨팅에 의한 앞으로의 혼란은 애플리케이션 개발과 배치 프로세스에서 발생할 것으로 예상할 수 있다. 쉽게 말해서 IT는 반드시 애플리케이션 라이프사이클을 더욱 빠르게 해야 한다.

여기에서 데브옵스(DevOps)의 역할이 중요하다. "개발(Development)"과 "운영(Operation)"의 합성어인 데브옵스는 이전에 개별적으로 존재하던 기관과 프로세스의 융합을 상징한다. 그 비전은 융합된 프로세스를 통해 애플리케이션 업데이트를 가속화하여 수 주(또는 수 개월) 대신에 수 시간 또는 수 일 만에 변경사항을 제공할 수 있는 최적화되고 통합된 기관을 지향한다.

하지만 이런 마법 같은 데브옵스의 효과가 어떻게 실현될 수 있을까?

문화적 변화가 필요하긴 하지만 충분하지는 않다
종종 문화적 변화가 해결책으로 언급되곤 한다. 개발자 및 시스템 관리자들이 한 팀으로써 협력하도록 할 수 있다면 협력을 향상시켜 애플리케이션 라이프사이클을 가속화할 수 있을 것이라는 기대다.

그러나 필자는 이런 접근방식을 그다지 선호하지 않는다. 물론 개발과 운영 사이의 마찰은 비일비재하며 같은 팀에 소속된다면 분명 개인적인 관계는 향상될 것이다. 이런 접근방식은 협력을 증진시키고 서로를 비난하는 행위를 줄여 현재의 상태를 점진적으로 향상시킬 수도 있을 것이다. 하지만 개인적인 상호작용이 개선된다고 해서 애플리케이션 기능 공개 사이클이 가속화된다는 보장은 없다.

경우에 따라서 점진적인 개선으로는 불충분하다. 기업들이 기능 공개를 20% 가속화한다고 해서 현재 직면하고 있는 디지털 비즈니스 환경의 미래에 성공할 수는 없는 노릇이다. 고작해야 21일짜리 프로젝트를 18일로 단축하거나 6개월짜리 프로젝트를 5개월 수준으로 단축할 수 있을 뿐이다. 오늘날의 기업들은 200% 이상의 속도 증가를 필요로 하고 있다.

즉 문화에 관한 주장은 어불성설이라는 것이다. 정작 문제가 있는 것은 프로세스인데, 프로세스가 아닌 사람에 초점을 두고 있는 것이다. 또한 프로세스는 애플리케이션 라이프사이클 전반에 걸쳐 빨라져야 한다.


X