26 min read

영국 정부 클라우드 서비스 록인 관리 가이드

Justin Yoo •

이 포스트는 영국 정부에서 제공하는 Managing technical lock-in in the cloud 문서를 번역한 것입니다. 문체가 자연스럽지 않을 경우 댓글로 알려주시면 반영하도록 하겠습니다.

이 가이드는 이 글을 읽는 독자 여러분이 속해 있는 조직이 클라우드 서비스를 도입하거나 사용하는 상황이 오면 좀 더 효과적으로 선택할 수 있는지에 대해 서술합니다.

2019년 12월 17일 발행 – 영국 정부 디지털 서비스 팀

목차

퍼블릭 클라우드를 이용하면 조직은 사용한 리소스만큼만 비용을 지불하므로 인프라를 마련하기 위해 미리 지출할 비용을 줄일 수 있습니다. 이렇게 퍼블릭 클라우드를 사용하면 전통적인 데이터 센터 모델 대비 큰 비용 절감과 효율성을 얻을 수 있습니다.

하지만, 클라우드 서비스가 이런 유연함도 있는 반면에, 특정 클라우드 서비스 공급자가 제공하는 제품과 서비스에 종속되는 위험성도 생기게 마련입니다. 이것을 "록인 (lock-in)" 이라고 부르는데요, 이것은 어떤 형태의 기술이나 클라우드 서비스 제공자에서 다른 기술 혹은 클라우드 서비스 제공자로 바꾸기가 굉장히 어렵고, 시간도 많이 걸리고 게다가 엄청난 비용이 발생하는 현상을 가리킵니다.

일반적으로 "록인"은 피해야 한다고 합니다. 하지만 특정 클라우드 서비스에 "록인"함으로써 얻는 이점도 있습니다. 예를 들어 저장소 라이프사이클을 클라우드 서비스 제공자가 관리해준다면 그 때는 "록인"이 발생하겠죠. 하지만 라이프사이클 관리에 필요한 비용이나 부가작업은 그만큼 줄어듭니다. 이처럼 어느 정도의 "록인"을 인정하면 개발자에게 아래와 같은 이점을 가져다 줍니다:

  • 더 적은 양의 코드를 작성한다
  • 환경 설정에 필요한 시간을 줄인다
  • 좀 더 덜 복잡한 서비스를 만든다

따라서 이러한 클라우드 "록인"이 가져다 주는 이점과 잠재 위험 요소 사이에서 균형을 찾아야 하는데요, 그렇게 함으로써 가치를 최대로 뽑아낼 뿐만 아니라 향후 레거시 기술이 가져올 부담을 줄일 수가 있습니다.

록인의 다양한 형태

일반적으로 두 가지 형태의 "록인"이 존재합니다. 많은 조직에서는 용역 "록인"에 대한 경험이 있습니다. 이러한 "록인"은 주로 장기 계약인 경우가 많고 융통성이 적어 상황이 바뀔 경우에도 서비스 제공자와의 계약 때문에 쉽사리 기술 전략을 변경하지 못합니다.

이런 경우에는 크라운 용역 서비스 계약 관리 기준을 참조해서 아래와 같은 사항을 준수하는지 확인합니다:

디지털 마켓플레이스를 통해 프레임웍을 구매하는 전략은 이러한 용역 계약을 좀 더 용이하게 만들어 줄 수 있습니다.

퍼블릭 클라우드 서비스는 보통 사용한 만큼 지불하는 (pay-as-you-go; PAYG) 형태의 계약이 일반적입니다. 이론적으로 따지자면 이런 형태의 계약은 언제든 클라우드 서비스 이용을 중지할 수 있습니다만, 실제로는 이렇게 하기가 쉽진 않죠. 이를 가리켜 기술적 "록인"이라고 하는데, 이는 주로 아래와 같은 상황에서 발생합니다:

  • 타 클라우드 서비스 제공자는 동일한 서비스를 제공하지 않는다
  • 기술 아키텍처가 특정 방향성으로만 작동하게끔 의존성을 지닌다
  • 특정 클라우드 제품 혹은 서비스 특화된 강력한 통합 서비스에 의존한다
  • 조직내 기술 아키텍처를 담당하는 사람이 없거나 부족하다

기술적 "록인"을 완전히 배제하기는 불가능합니다. 아무리 간단한 서비스라도 기존 아키텍처와 통합해야 할 필요가 있기도 합니다. 이런 경우 초기에 개발을 쉽게 하기 위해서 다각적인 검토 없이 즉각적으로 아키텍처를 결정하고 진행할 수도 있는데요, 이런 경우에는 결과적으로 어쩌면 여러분의 생각보다 좀 더 강한 "록인"을 초래할 수도 있습니다.

일례로 여러분이 개발한 애플리케이션을 온전히 클라우드 서비스 제공자의 오케스트레이션 서비스로 배포하는 방법이, 배포 팀을 신설하고 배포 업무를 담당하게 하는 편보다 훨씬 수월합니다. 배포팀이 특정 상황과 유저에게만 맞게 만들 위험도 없습니다. 하지만 이것은 동시에 클라우드 서비스 제공자에 대한 의존성을 증가시켜 향후 서비스 복잡도가 증가할 때 제약사항이 될 수도 있습니다.

어느 조직이건 퍼블릭 클라우드를 사용하는 득과 실에 대한 다양한 관점을 지니고 있습니다. 따라서 이러한 관점을 이해하기 위해 기술팀과 영업팀이 서로 함께 일하는 방법도 좋습니다. 또한 관리형 퍼블릭 클라우드 서비스를 사용하지 않을 경우 발생하는 관리 비용 혹은 수익에 대한 고려를 해 봐야 합니다.

클라우드 포트폴리오 관찰

시스템 개발을 지속함에 있어서 회수 비용 또는 전환 비용이 기대와 달리 너무 많이 들어가는 시점이 생기게 됩니다. 이런 상황을 조기에 인지할 수 있도록 여러분의 클라우드 포트폴리오를 면밀히 관찰(모니터링)해야 합니다. 이러한 모니터링은 여러분 조직의 클라우드 전략을 담당하는 사람 혹은 부서에서 하는 편이 좋은데요, 기술설계위원회(Technical Design Authority; TDA)와 같은 형태가 그 예가 될 수 있겠습니다.

TDA 혹은 그에 준하는 부서는 조직 전체의 클라우드 서비스에 대한 개괄적인 이해가 있어야 합니다. 이를 통해 클라우드 서비스 제공자와 중복 계약을 방지할 수도 있고, 조직내 부서간 서비스들의 상호운용성도 높일 수 있습니다.

TDA는 또한 어떤 상황에서 조직 내 서비스가 비정상적인 전환 비용이 발생하는지에 대한 기대치를 정하기도 합니다. 예를 들어 클라우드 서비스를 이용할 경우 개발 기간이 좀 더 필요하지만 이를 통해 좀 더 많은 이득이 발생한다는 부분 역시 확인할 수도 있겠지요.

사용자 연구 결과에 따르면 한 부서에서 클라우드 서비스 사용 전략을 조정하는 방법이 조직 전체적으로는 일관성을 높여준다고 합니다. 여기서 TDA와 같은 부서가 이런 패턴을 장려하고 재사용성을 높여줄 수 있습니다. 영국 정부 내각 부서에서 지휘 체계가 작동하는 방식과 비슷하게 내부 확인 절차를 전략적으로 설정할 수도 있습니다.

어떤 식으로든 항상 기술적 "록인"이 발생하긴 하기 때문에, 지속적으로 클라우드 포트폴리오를 관찰하다 보면 이것이 어떻게 여러분 조직에 영향을 미치는지 그리고 필요할 경우 어떤 식으로 조치해야 하는지를 이해하기 쉽게 도와줍니다.

기술적 록인에 대한 이해

기술적 "록인"은 조직마다 다양한 방식으로 영향을 줍니다. 단일 클라우드 전략 혹은 멀티 클라우드 전략인지에 따라 다양한 형태로 클라우드 서비스 제공자에 대한 의존성을 갖기 때문입니다.

어떤 조직에서는 특정 클라우드 서비스 제공자에 집중된 포트폴리오를 구성하면 훨씬 더 이득일 수 있습니다:

  • 긴밀한 통합 서비스를 사용함으로써 향상된 사용자 경험을 제공하는 경우
  • 서비스간 공통의 패턴과 컴포넌트를 재사용하기 쉬울 경우
  • 이미 성숙한 관리 서비스를 통해 보안과 모니터링 서비스를 공유하기 쉬울 경우
  • 전체 조직의 클라우드 사용과 관련한 비용 및 관리 체계가 통합되어 있을 경우

하지만 이런 경우가 다른 조직에서는 한 클라우드 서비스 제공자에게 너무 많은 의존성을 갖게 되므로 받아들이기 힘들 수도 있습니다. 이런 조직에서는 특정 클라우드 서비스 제공자에게 너무 의존성을 갖지 않게끔 하는 다양한 장치를 사용할 수도 있습니다. 하지만, 클라우드 "록인"으로부터 여러분의 조직을 떼어 놓는 것이 굉장한 비용을 요구하기도 하고, 여러분의 기술적인 선택의 폭을 제한할 수도 있다는 것을 알고 있어야 합니다.

예를 들어 여러분의 클라우드 인프라스트럭처를 한 곳에서 다른 곳으로 이전하려고 할 때 이는 심각한 비용과 엔지니어링 관련한 도전에 직면할 수 있습니다. 특정 클라우드 서비스 제공자에서만 제공하는 서비스를 피하기는 굉장히 어렵습니다. 그리고 결국에는 특정 플랫폼에 대해서는 제한적인 기능만을 사용할 수 밖에 없는 상황이 될 수도 있지요.

이런 식으로 굉장히 커스터마이징 된 서비스를 피하려고만 한다면 아마도 여러분의 조직은 아주 기본적인 IaaS 솔루션만 사용해야 할 수도 있습니다. 클라우드 친화적인 (Cloud-native) 서비스는 너무나 많은 기술적인 "록인"이 되어 있다고 보기 때문이지요. 이러한 클라우드 친화적인 서비스를 사용하는데서 나오는 모든 이점을 놓칠 수도 있습니다. 예를 들자면 자동화된 키/시크릿 관리 혹은 통합 모니터링 서비스 등이 엄청난 가치를 가져다 줄 수 있는데도 말이지요.

국가 사이버 보안 센터(National Cyber Security Centre; NCSC)에서는 서버리스 기술을 사용할 때의 이점에 대한 내용을 정리해 놓았습니다. 예를 들자면 서버리스 기술을 사용하면 아래와 같은 이점이 따릅니다:

  • 서비스 패치를 손쉽게 할 수 있다
  • 공통의 사이버 공격을 방해할 수 있다
  • 현대적인 클라우드 플랫폼이 제공하는 보안 방어 능력과 감시 능력을 손쉽게 통합해 줄 수 있다

클라우드 서비스를 이용하면서 생기는 득실관계 균형 잡기

특정 클라우드 서비스가 제공하는 가치와 클라우드 서비스 제공자를 바꿀 가능성에 대한 가치를 서로 비교해 봅시다. 그래프를 이용해서 비교해 보는 방법도 나쁘지 않겠네요.

보통 클라우드 제공자는 동일한 기능을 인하우스(in-house)에서 직접 하기보다 훨씬 더 낮은 가격으로 서비스를 제공합니다. 예를 들어 통합 보안 모니터링이라든가 자동화된 로드 밸런싱 같은 것이지요. 이는 개발자가 좀 더 여러분 조직의 비지니스 가치를 창출하는 작업에 좀 더 집중할 수 있게끔 자유도를 높여줍니다.

아래 그래프는 가치와 이식성에 대한 내용입니다. 여러분의 서비스를 아래 그래프에 위치시켜 보세요. 그러면 "록인"의 위험성을 어느 정도 받아들일만 한지에 대해 빠르고 쉽게 이해할 수 있습니다. 가능한 한 가치와 이식성 모두를 만족시킬 수 있을만큼의 위치에 여러분의 서비스를 위치시키고 싶어할 거예요. 어쩌면 최대 이익을 기대할 경우 이식성을 과감하게 포기할 수도 있겠지요.

위 그래프는 가치와 이식성 스펙트럼의 끝단에서 보이는 전형적인 예를 네 가지 들어봤습니다. 어느 정도나 "록인"을 받아들일만 한 지, 그리고 어떤 종류의 서비스를 스펙트럼의 끝단에서 찾을 수 있을지에 대한 대략의 지표가 될 겁니다.

그래프는 아래의 내용을 가리킵니다:

  • 이 사분면에서 가치도 낮고 이식성도 낮은 서비스는 최대한 피해야 합니다
  • 어떤 경우에서는 이식성이 낮아 "록인"의 가능성이 높지만 많은 가치를 가져다 줄 수 있는데요, 이 때의 "록인"은 아마도 허용될 수 있습니다
  • 대부분의 일반적인 서비스, 복잡도가 낮은 서비스는 주로 사분면의 우측 하단에서 나타납니다
  • 가치도 높고 이식성도 높은 서비스는 찾기 힘들지만, 만약 존재할 경우 엄청난 무언가가 될 수 있습니다.

예를 들어 서버리스 기술 같은 경우를 보죠. 이는 이식성이 낮습니다. 즉 "록인"이 강합니다. 하지만 자동 패치나 배포와 같은 높은 가치를 가져다 주죠. 따라서 굉장히 고려할 만 합니다. 하지만 이렇게 이식성이 낮을 경우, 향후 클라우드 서비스 제공자를 바꾸는 상황에서는 어떤 식으로 할 것인지 반드시 고려해 봐야 합니다.

또다른 예를 들어보자면 복잡한 머신러닝 알고리즘을 미리 설정해 놓은 경우가 있겠네요. 여러분의 조직이 직접 알고리즘을 훈련시키기 위해 머신을 설정하고 배포해야 할 필요가 없다는 점이 아마도 이식성이 낮다는 점보다 훨씬 더 매력적일 수 있습니다.

반면에 특정 유용한 기능 때문에 상대적으로 잘 알려져 있지 않은 저장소 서비스를 선택하는 방법은, 만약 해당 서비스가 표준을 따르지 않는다면 어쩌면 피해야 할 수도 있어요. 다른 유명한 대안이 있는데도 굳이 "록인"을 감수해 가면서 해당 서비스를 사용한다는 접근 방법이 그다지 더 많은 가치를 제공할 가능성이 높지 않기 때문이죠.

전략적인 관점에서 여러분의 조직은 개발팀이 다양한 호스팅 옵션을 평가하는 기준과 더불어 가치와 이식성 중 어디에 우선순위를 두어야 할지에 대한 기준을 제시해야 합니다. 또한 서비스 제공자를 교체할 때 개발팀이 그에 대해 어느 정도나 준비가 되어 있는지에 대해 알고 있어야 합니다.

개발팀이 서비스 제공자 교체에 대한 준비 정도를 평가하기 위해 어떤 조직은 주기적으로 전환 비용 산정을 다시 해 보기도 합니다. 각각의 클라우드 서비스 제공자 환경에서 특정 컴포넌트를 재개발하고 테스트하는데 필요한 비용이죠. 이와 같은 지속적인 재평가는 정확도를 계속해서 확인할 수 있어서 좋습니다.

개별 제품과 서비스 수준에서 호스팅 플랜과 비지니스 사용자 케이스는 (협상에 따른 가격 할인이라든가 이미 소멸된 이점 등을 고려한) 대략의 비용과 기존 호스팅 계약을 종료하는데 필요한 시간 등을 고려해야 합니다.

기술적 록인 관리

만약 여러분이 클라우드 서비스 제공자에 대한 "록인"을 보완하기 위해 좀 더 기술적인 개입을 하기로 결정했다면, 이 접근법은 어떤 배포 절차를 따르는가에 따라 바뀔 수 있습니다.

전략적인 관점에서 단일 클라우드 제공자를 사용하는 조직은 전략이 바뀔 경우, 예를 들어 다른 클라우드 플랫폼으로 서비스를 이전할 경우, 발생할 수 있는 장애상황에 대비한 플랜 B를 수립해야 합니다. 멀티 클라우드 전략을 사용하는 조직은 조직의 개별적인 컴포넌트나 서비스를 어떻게 다른 클라우드로 이전해야 하는지에 대한 계획을 수립하고 정기적으로 이를 테스트해야 합니다.

개별 제품 혹은 서비스를 제공하는 팀은 향후 언젠가는 내 제품/서비스가 다른 클라우드 서비스 제공자로 이전할 수 있다는 전제 아래 의사결정을 해야 합니다.

출구 전략은 클라우드 서비스 제공자를 교체할 때의 영향과 그냥 바꾸지 않고 남아 있을 때의 이득 사이에서 적절한 균형점을 찾아야 합니다. 예를 들어 특정 서비스는 플랫폼을 교체할 때 좀 더 넉넉한 시간을 주는 편이 좋은데, 기존의 통합 서비스가 가져다 주는 가치가 엄청날 수도 있기 때문입니다.

SaaS 쪽으로 넘어가 보면 공개 표준과 형식을 사용하는 서비스나 제품을 선택하는 것이 좋은 예가 될 겁니다. 그렇게 해야지 우리 조직의 데이터에 대한 제어권을 계속 내가 가질 수 있기 때문입니다. 이는 새 환경을 위해 기존 데이터를 추출할 수 있는 선택권이 있다는 말과 같습니다. PaaS와 IaaS 관점에서 보자면 가능한 한 오픈소스를 사용하는 방법이 될 수 있겠구요, 컴포넌트간 커플링을 낮춰서 손쉽게 교체가 가능하도록 개발하는 방법도 하나의 방식이 될 수 있겠습니다. 또한 코드 관점에서의 인프라스트럭처(Infrastructure as Code; IaC) 도구를 사용하면 멀티 클라우드 플랫폼에서도 잘 작동하겠지요.

실제 클라우드 서비스 제공자를 선정한 이후에도 꾸준히 이를 검토해야 하는 활동 역시 필요합니다. 애자일 방법론을 통해 지속적으로 여러분의 호스팅 계약을 검토해서 클라우드 제공자가 투자대비 최고의 가치를 제공하는지 측정해야 합니다. 클라우드 서비스 비용 최적화는 어느 정도나 클라우드 서비스를 효과적으로, 그리고 효율적으로 사용하고 있는지 확신하는데 도움이 됩니다. 그리고 이러한 비용 최적화는 새로운 기술이 나왔을 때 다시 해당 기술이 기존 기술을 교체할 수 있는지 여부를 재검토하는 활동 역시 포함됩니다.

클라우스 서비스 제공자 관리 조직 빌드업

기술적인 "록인"에 대한 일반적인 명분은 주로 기술셋과 지식에 대한 가용성에 있습니다. 만약 여러분의 개발팀이 특정 서비스 제공자에 대해 더 풍부한 경험을 갖고 있다면 단기적으로는 해당 플랫폼을 계속해서 사용하면 훨씬 더 쉬운 선택일 수 있어요.

어떤 클라우드 제공사는 자신의 제품을 사용하는 데 있어 무료 트레이닝 세션을 제공하기도 합니다. 하지만 이는 특정 서비스/제품에 대한 의존성을 높이기도 하지요. 또한 클라우드 제공사는 기업 수준 혹은 커뮤니티 수준의 기술 서포트 서비스를 제공하기도 합니다. 물론 때로 이런 서비스는 고가의 비용을 필요로 합니다.

전략적으로 보자면 단기적인 관점에서 봤을 때 기술적인 요구사항을 충족시킬 수 있는 사람을 고용하면 좋습니다. 하지만 여러분 조직 내의 TDA 라든가 아키텍처 커뮤니티를 통해 좀 더 넓은 시각으로 솔루션을 바라볼 수 있는 지식을 갖춘 사람을 고용해야 합니다. 이렇게 함으로써 향후 클라우드 시장 변화에 따라 좀 더 능동적이고 정확한 의사결정을 할 수 있는 관점을 갖게 됩니다.

개별 제품/서비스 수준에서 보자면 클라우드 솔루션을 선택하고 배포하는 데 필요한 지식을 가진 다재다능한 팀을 빌드업 하면 좋습니다. 다시 말하면 팀을 구성할 때 조달 전문가, 재정 전문가, 기술 전문가 등을 한 팀에 합류시켜 클라우드 서비스에 대한 종합적인 의사결정을 내리게 하고 클라우드 서비스 "록인"에 대한 득실관계를 이해할 수 있게 해야 합니다.

관련 가이드

베타리딩 피드백 주신 여러분 감사 드립니다.