클라우드 컴퓨팅이 민첩성을 제공하지만, 그렇다고 그 자체가 자동으로 기업을 민첩하게 해준다는 의미는 아니다. 비즈니스 민첩성을 구현하려면, 애플리케이션 개발 주기 설계부터 설치, 관리 방법 전부를 다시 생각해야 한다.

최근 필자는 클라우드 컴퓨팅이 어떻게 적절한 민첩성을 가능하게 하는지에 대해 논의했었다. 처음에는 자동 제공 및 손쉬운 확장성 덕분에 기업들이 인프라의 민첩성을 경험할 수 있다.

하지만 인프라가 민첩하다고 해서 애플리케이션이 민첩할 것이라고 생각하는 것은 착각이다 (즉, 애플리케이션을 더욱 신속하게 생산에 투입하거나 이런 애플리케이션이 규모 면에서 손쉽게 성장 또는 축소될 수 있도록 하는 것을 말한다). 사실, 클라우드 환경에서 애플리케이션을 호스팅하면 민첩한 만능 애플리케이션이 될 것이라고 생각하는 IT 직원들이 적지 않다.

이는 사실이 아니다. 클라우드 인프라가 필요한 것은 사실이지만 전반적인 애플리케이션 민첩성을 달성하기에 충분하지는 않다. 애플리케이션 민첩성을 달성하기 위해서는 애플리케이션의 생애주기를 중심으로 그 조직 및 프로세스와 함께 애플리케이션 자체를 설계, 설치, 관리하는 방법과 관련된 기타 여러 가지 조건을 수립해야 한다.

오늘은 비즈니스 민첩성을 달성하기 위해 클라우드 인프라로 전환하는 것과 관련해 바뀌어야 하는 5가지 요소에 관해 알아보도록 하자.

 

1. 애자일 개발: 비즈니스 민첩성의 현실화

애자일 개발은 산업계에서 너무 잘 수립돼 있어서 민첩성을 추구하는 기관에게는 당연한 것처럼 보인다. 하지만 많은 IT부서들이 개발 주기에서 애자일 개발 활동을 아직 이행하지 않았거나 이를 이행하기 위해 여전히 노력하고 있다.

애자일 개발은 일련의 구체적인 활동보다는 하나의 개념에 가깝지만, 이 용어의 가장 공통적인 특징은 주기가 짧고, 작고 점진적인 기능을 공개하며, 애플리케이션 스폰서/기능 정의자/개발팀 간 지속적으로 상호작용하는 점이라 할 수 있다. 이 덕분에 연장된 개발 사이클이 끝날 때 사용할 수 없거나 원하지 않는 것을 제공하는 긴 '빅 뱅' 개발 일정을 방지할 수 있다. 하지만 애자일 개발이 없다면 비즈니스 민첩성에 대한 꿈은 그저 한낱 꿈에 지나지 않을 것이다.
 

2. 부서간의 지나친 경쟁이 낳은 사일로(Silo): 사일로는 농장으로

부서들간의 수동적 프로세스는 비즈니스 민첩성에 치명적이다. 안타깝게도 많은 기업들이 인프라와 마찬가지로 프로세스를 자동화해야 한다는 것을 인식하지 못하고 있다. 프로세스가 최적화되지 않으면 개발의 속도와 애플리케이션 제공의 속도 사이에 불일치가 발생한다.

일부 부서들은 연속적 통합(점진적 애플리케이션 기능 향상의 지속적인 통합으로 수립된 애자일 개발 활동)과 간헐적 배치(업데이트된 애플리케이션의 생산 투입 빈도 감소)의 철학을 제시하고 있다. 이런 접근방식이 반드시 나쁜 것은 아니지만, 이것을 기관의 사일로와 수동적 프로세스에 대한 이론적 설명으로 제시한다면 괜찮은 해결책이라 볼 수 없다.

웹 기반의 기업을 이끄는 경험은 빈번한 업데이트 제공이 간헐적인 대규모 코드 제공보다 훨씬 성공적이면서 덜 파괴적이라는 점이다. 많은 IT 부서들은 이전의 인프라 요건을 충족시키도록 설계된 기관의 구조가 애자일 개발과 배치에 적합하지 않다는 문제점에 봉착하고 있다. 특히 내부 활동과 일치시키기 위해 애플리케이션 배치를 다시 수행하게 되는 수동 프로세스는 도움이 되지 않는다. 매번 시간이 소요되고 오류의 위험이 발생한다.

 

3. 공통 상용제품 : 한 주방에 요리사가 여럿

사일로 접근방식의 문제점 중 하나는 각 그룹이 저마다의 상용제품을 만들어 사용한다는 점이다. 개발자들은 아마존 웹 서비스(Amazon Web Services) 가상머신과 때로는 지텁 & 젠킨스(Github and Jenkins)를 사용한다. QA는 코드를 뽑아내고 자체적인 툴을 사용해 이를 다시 구성한다. 이것을 운영부에 넘기면 자동화된 사용설명서 툴에서 코드가 다시 정의된다. 애플리케이션이 생산 단계에 돌입하면 수동 추적 방식을 사용하는 변화관리 위원회를 통해 흐름을 바꾸고, 이런 추적방법은 직접적인 구성의 변화로 이어지는 문제로 귀결된다.

이런 다양한 상용제품이 존재할 때, IT 버전의 의원성(iatrogenesis)에서 모든 것을 영원히 끝낼 수 없으며 끊임없는 오류에 시달릴 것임은 의심의 여지가 없다. 모든 그룹이 일관되게 사용하는 한 버전의 코드가 존재하지 않는다면 혼란이 야기될 것이다.

 

4. 일관된 툴: 드라이버 하나로 충분

코드에 대한 수동 개입과 관련된 끊임없는 문제점은 각 그룹이 자체 툴을 사용할 때 더욱 악화될 뿐이다. 이렇게 각 그룹이 선택할 툴로 관리할 수 있도록 애플리케이션을 다시 변환하면 혼란과 오류가 야기될 수 밖에 없다. 더 나은 해결책: 복수의 작업그룹이 공유할 수 있는 단일한 툴 세트를 찾는다. 쉐프(Chef) 또는 퍼펫(Puppet)은 지트허브(GitHub)와 함께 애플리케이션의 생애주기 동안 사용할 수 있는 툴을 위한 좋은 선택이라 할 수 있다.

 

5. 제한적 실행을 통한 점진적 애플리케이션 변화

애플리케이션 배치 모델을 애자일 개발 모델, 즉, 적은 양의 점진적 기능을 자주 공개하는 모델과 일치시키는 것이 맞다. 많은 기업들은 코드를 생산단계로 돌입시키는 간접비가 너무 높기 때문에 많은 기능상 변화를 하나의 업데이트로 묶는다. 이 때문에 업데이트의 일부가 실패하는 문제가 발생했을 때 어떤 부분이 문제가 되는지 찾아내기가 어렵다.

더 나은 방법이 있다. 빈번한 공개로 인한 문제를 해결한 후에 소규모 업데이트를 진행하면 된다. 이것과 관련된 위험은 조건적 표현을 통해 기능적 코드를 노출함으로써 최소화할 수 있다. 즉, "DISPLAY NEW FEATURE A" 매크로가 환경 변수로 설정되어 있을 때 새로운 기능 A를 표시하면 된다. 이를 통해 해당 기능을 전체적인 컴퓨팅 풀의 하위 요소에서만 노출할 수 있으며, 기능에서 문제가 발견되면 해당 기능을 손쉽게 정지할 수 있다.

클라우드 컴퓨팅의 가능성을 완전히 실현하는 것은 인프라의 민첩성을 애플리케이션 민첩성과 연계했을 경우에만 가능하다. 애플리케이션 라이프사이클의 자동화된 최적화에 실패하면 시장에 더욱 빨리 진출하겠다는 IT부서의 꿈이 무산될 수 밖에 없다.