2019.04.04

블로그 | 클라우드 애플리케이션 마이그레이션 실패를 선언해야 할 때

David Linthicum | InfoWorld
실리콘 밸리에서 요즘 한창 잘 나가는 용어 중 하나는 “빨리 실패하기”이다. 이는 먹혀들지 않는 것이 무엇인지 파악해서 되는 것으로 옮겨갈 수 있다는 것을 의미한다. 이 말은 많은 경우 확실한 조언이다.

하지만 일부 기업 IT 부서에서 실패는 당사자를 조직에서 쫓아낼 수도 있다. 이 때문에 많은 IT 전문가가 어떤 대가를 치르더라도 실패하지 않으려고 한다. 아니면 최소한 실패를 선언하지 않는다. 심지어 그대로 사용하기에는 너무 많은 비용이 들고 비즈니스에 영향을 미칠 수도 있는 효과적이지 못한 시스템을 다루느라 수백만 달러가 들어가는 것도 감수할 정도이다.
 
ⓒFlorencia Potter (CC0)

클라우드에서는 언제 실패를 선언해야 하는지를 알아야 한다. 재기동 버튼을 눌러 마이그레이션을 다시 시작해야 한다.

현재 기업이 진행하고 있는 여러 클라우드 마이그레이션 프로젝트를 살펴보면, 최소한 20%는 큰 어려움에 직면해 있을 것이라고 본다. 명백한 실패로 이어질 수도 있는 이런 곤경에 처하는 원인은 다양하지만, 크게 다음의 세 가지로 나눌 수 있다.

- 리프트 앤 시프트 방식이 먹혀들지 않는다.
- 데이터 통합을 나중으로 미뤘다.
- 컴플라이언스나 보안 문제를 해결하지 않았다.

애플리케이션 마이그레이션의 가장 큰 문제는 애플리케이션이 온프레미스 환경의 플랫폼 A(4코어 리눅스라고 하자)에서 돌아가면, 같은 구성을 사용해 퍼블릭 클라우드 상에서 가상 플랫폼을 프로비저닝해도 돌아가야 한다는 잘못된 믿음이다. 종종 그렇게 돌아가지 않는다.

이런 가정의 결과로 IT 조직은 아직 퍼블릭 클라우드로 이전하지 않은 시스템과의 커뮤니케이션 관련 문제에 빠지거나 클라우드 요금이 예상보다 세 배나 더 나오는 사태를 맞이하게 된다. 이유는 이들 리프트 앤 시프트 애플리케이션을 클라우드 플랫폼이나 기능, 비용에 맞춰 최적화하지 않은 것이다. 네이티브 클라우드 기능을 사용하지도 않기 때문에 클라우드로 이전해서 얻는 가치는 가시권 밖으로 나가버린다. 비용이 더 많이 들지도 모른다.

나머지 두 가지 문제, 즉 데이터 통합과 컴플라이언스 및 보안은 명백한 실패의 원인이 되는 경우가 그리 흔하지 않지만, 여전히 큰 문제이다.

마이그레이션 전에 데이터 통합을 고려하지 않으면, 문제를 발견했을 때는 이미 아무 것도 할 수 없는 상태가 된다. 많은 경우, 온프레미스 시스템과 클라우드 간의 지연은 바로 잡을 수 없다. 이럴 때는 프로젝트 실패를 선언하고 애플리케이션을 데이터센터로 다시 가져와야 한다.

컴플라이언스와 보안 문제는 종종 클라우드에서 애플리케이션과 데이터베이스에 체계의 변경을 요구한다. 이 때문에 많은 사전 준비를 필요로 한다. 최악의 경우, 컴플라이언스와 보안의 실패로 인해 프로젝트를 다시 시작해야 한다.

실패는 클라우드 마이그레이션의 일부라는 것을 인정하는 것이 중요하다. 결국 대부분 조직은 여전히 학습 중이다. 그러니 실수를 예상하고 실패라는 사실을 마이그레이션 작업에 포함시키는 것이 좋다. 물론 이와 함께 실패로부터 배워서 프랙티스와 툴과 기술을 계속 개선해야 한다.  editor@itworld.co.kr



2019.04.04

블로그 | 클라우드 애플리케이션 마이그레이션 실패를 선언해야 할 때

David Linthicum | InfoWorld
실리콘 밸리에서 요즘 한창 잘 나가는 용어 중 하나는 “빨리 실패하기”이다. 이는 먹혀들지 않는 것이 무엇인지 파악해서 되는 것으로 옮겨갈 수 있다는 것을 의미한다. 이 말은 많은 경우 확실한 조언이다.

하지만 일부 기업 IT 부서에서 실패는 당사자를 조직에서 쫓아낼 수도 있다. 이 때문에 많은 IT 전문가가 어떤 대가를 치르더라도 실패하지 않으려고 한다. 아니면 최소한 실패를 선언하지 않는다. 심지어 그대로 사용하기에는 너무 많은 비용이 들고 비즈니스에 영향을 미칠 수도 있는 효과적이지 못한 시스템을 다루느라 수백만 달러가 들어가는 것도 감수할 정도이다.
 
ⓒFlorencia Potter (CC0)

클라우드에서는 언제 실패를 선언해야 하는지를 알아야 한다. 재기동 버튼을 눌러 마이그레이션을 다시 시작해야 한다.

현재 기업이 진행하고 있는 여러 클라우드 마이그레이션 프로젝트를 살펴보면, 최소한 20%는 큰 어려움에 직면해 있을 것이라고 본다. 명백한 실패로 이어질 수도 있는 이런 곤경에 처하는 원인은 다양하지만, 크게 다음의 세 가지로 나눌 수 있다.

- 리프트 앤 시프트 방식이 먹혀들지 않는다.
- 데이터 통합을 나중으로 미뤘다.
- 컴플라이언스나 보안 문제를 해결하지 않았다.

애플리케이션 마이그레이션의 가장 큰 문제는 애플리케이션이 온프레미스 환경의 플랫폼 A(4코어 리눅스라고 하자)에서 돌아가면, 같은 구성을 사용해 퍼블릭 클라우드 상에서 가상 플랫폼을 프로비저닝해도 돌아가야 한다는 잘못된 믿음이다. 종종 그렇게 돌아가지 않는다.

이런 가정의 결과로 IT 조직은 아직 퍼블릭 클라우드로 이전하지 않은 시스템과의 커뮤니케이션 관련 문제에 빠지거나 클라우드 요금이 예상보다 세 배나 더 나오는 사태를 맞이하게 된다. 이유는 이들 리프트 앤 시프트 애플리케이션을 클라우드 플랫폼이나 기능, 비용에 맞춰 최적화하지 않은 것이다. 네이티브 클라우드 기능을 사용하지도 않기 때문에 클라우드로 이전해서 얻는 가치는 가시권 밖으로 나가버린다. 비용이 더 많이 들지도 모른다.

나머지 두 가지 문제, 즉 데이터 통합과 컴플라이언스 및 보안은 명백한 실패의 원인이 되는 경우가 그리 흔하지 않지만, 여전히 큰 문제이다.

마이그레이션 전에 데이터 통합을 고려하지 않으면, 문제를 발견했을 때는 이미 아무 것도 할 수 없는 상태가 된다. 많은 경우, 온프레미스 시스템과 클라우드 간의 지연은 바로 잡을 수 없다. 이럴 때는 프로젝트 실패를 선언하고 애플리케이션을 데이터센터로 다시 가져와야 한다.

컴플라이언스와 보안 문제는 종종 클라우드에서 애플리케이션과 데이터베이스에 체계의 변경을 요구한다. 이 때문에 많은 사전 준비를 필요로 한다. 최악의 경우, 컴플라이언스와 보안의 실패로 인해 프로젝트를 다시 시작해야 한다.

실패는 클라우드 마이그레이션의 일부라는 것을 인정하는 것이 중요하다. 결국 대부분 조직은 여전히 학습 중이다. 그러니 실수를 예상하고 실패라는 사실을 마이그레이션 작업에 포함시키는 것이 좋다. 물론 이와 함께 실패로부터 배워서 프랙티스와 툴과 기술을 계속 개선해야 한다.  editor@itworld.co.kr

X