51. 벤더 종속 (Vendor Lock-in)

⚠️ 이 문서는 기업이 특정 클라우드 서비스 제공자(CSP, 예: AWS, Azure, GCP)의 독자적이고 편리한 기술(예: 서버리스, 특화 DB)을 깊숙이 채택하여 쓰다가, 나중에 요금이 인상되거나 서비스 불만이 생겨도 다른 클라우드 벤더로 이사(Migration) 가기 위해 지불해야 하는 전환 비용(Switching Cost)이 너무 막대해져 발이 묶여버리는 함정을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 클라우드의 편리함은 '종속성'이라는 독을 품고 있다. 단순히 가상 서버(IaaS)만 빌려 쓰면 언제든 다른 곳으로 이사 가기 쉽지만, 클라우드 벤더가 제공하는 고도의 관리형 서비스(PaaS, SaaS)를 쓸수록 그 벤더의 포로가 된다.
  2. 가치(위험성): 벤더 종속 상태에 빠지면 클라우드 사업자가 일방적으로 가격을 2배 올리거나 서비스 약관을 변경해도 저항할 방법이 없어 기업의 IT 협상력과 유연성이 심각하게 훼손된다.
  3. 대응 체계: 특정 CSP의 전용 기술 대신 컨테이너(Docker)와 쿠버네티스(K8s) 같은 오픈소스 표준 기술을 사용하여 '어디서든 돌아가는(Portability)' 멀티 클라우드(Multi-Cloud) 아키텍처를 설계하는 것이 핵심 방어막이다.

Ⅰ. 달콤한 유혹: 벤더 종속은 어떻게 시작되는가?

개발자들은 편하다는 이유로 스스로 락인의 길을 걷는다.

  1. IaaS의 자유와 불편함:
    • AWS에서 텅 빈 가상 서버(EC2)만 빌려서 그 위에 직접 MySQL을 깔고 설정하면, 내일 당장 그 DB 백업본을 들고 Azure의 가상 서버로 이사 갈 수 있다 (락인 낮음). 하지만 백업과 패치를 개발자가 직접 해야 하니 귀찮다.
  2. PaaS/서버리스의 달콤함과 함정:
    • AWS가 "DB 백업, 이중화 우리가 다 알아서 해줄게. 넌 쿼리만 날려!"라며 Aurora DB나 DynamoDB를 제안한다.
    • 개발자는 더 편하려고 서버리스 함수인 AWS Lambda로 비즈니스 로직을 짜기 시작한다.
  3. 함정 발동:
    • 3년 뒤 AWS 요금이 부담되어 GCP로 이사 가려 한다. 하지만 DynamoDB의 데이터 구조와 Lambda에 쓰인 코드들은 AWS 전용 문법(SDK)으로 떡칠이 되어 있어 GCP에서 전혀 돌아가지 않는다. 코드를 1부터 100까지 새로 짜야 하는 대참사가 벌어지며 결국 이사를 포기하게 된다.

📢 섹션 요약 비유: 처음에 월세방(IaaS)에 살 때는 이불만 싸서 언제든 다른 방으로 이사 갈 수 있었습니다. 그런데 집주인(CSP)이 최신식 빌트인 맞춤 가전과 음성인식 시스템(PaaS)을 공짜로 깔아주자 거기에 익숙해져 버렸고, 이제는 이사 가려면 그 가전제품 조작법을 처음부터 새로 배워야 해서 억울한 월세를 내며 그냥 눌러앉게 된 상황입니다.

Ⅱ. 벤더 종속을 유발하는 3대 요소

기술, 데이터, 사람 모두가 벤더에 묶인다.

  1. 기술/아키텍처 종속:
    • AWS Kinesis, GCP BigQuery처럼 해당 클라우드에서만 존재하는 독점적이고 폐쇄적인 API와 아키텍처를 깊게 사용한 경우.
  2. 데이터 그래비티 (Data Gravity):
    • 페타바이트(PB) 급의 엄청난 데이터가 이미 한 클라우드(예: AWS S3)에 쌓여버렸을 때. 클라우드는 데이터를 넣을 땐 공짜지만 밖으로 뺄 때(Egress)는 엄청난 네트워크 트래픽 요금을 물리기 때문에, 물리적 비용 때문에 이사를 포기하게 된다.
  3. 인력 스킬 종속 (Skill Lock-in):
    • 사내 엔지니어들이 5년 동안 AWS만 만지다 보니 AWS 전문가가 되었다. Azure나 GCP로 넘어가려면 사내 인력을 재교육하거나 비싼 돈을 주고 새 엔지니어를 뽑아야 한다.

📢 섹션 요약 비유: 애플 생태계에 갇히는 것과 똑같습니다. 아이폰 전용 앱(기술 종속)을 잔뜩 사놨고, 수만 장의 사진이 아이클라우드(데이터 종속)에 묶여있으며, 내 손가락이 이미 아이폰 제스처(스킬 종속)에 적응해 버려서 갤럭시로 넘어가는 것을 포기하는 심리입니다.

Ⅲ. 어떻게 방어할 것인가? (탈출 아키텍처)

모든 클라우드에서 똑같이 숨 쉴 수 있는 공용 우주복을 입어야 한다.

  1. 컨테이너 (Docker)와 쿠버네티스 (K8s):
    • 종속성을 막는 가장 강력하고 완벽한 백신이다.
    • 애플리케이션을 AWS 전용 코드로 짜지 않고 도커 컨테이너(표준 규격 상자) 안에 포장한다. 이 상자는 AWS(EKS), Azure(AKS), 심지어 온프레미스 서버 위에서도 100% 동일하게 돌아가기 때문에 클릭 한 번에 클라우드를 이사할 수 있다.
  2. 오픈소스 (Open Source) 생태계 고집:
    • 클라우드 벤더의 독자적인 큐잉 서비스(AWS SQS) 대신, 어디서나 쓸 수 있는 오픈소스(Apache Kafka)를 설치해 사용한다. 독자적인 Aurora DB 대신 표준 MySQL/PostgreSQL을 고집한다.
  3. 멀티 클라우드 (Multi-Cloud) 전략:
    • 처음부터 웹 서버는 AWS에, 데이터 분석은 GCP에 쪼개어 구성함으로써 특정 벤더가 전체 시스템을 인질로 잡지 못하도록 협상 지렛대(Leverage)를 유지한다.

📢 섹션 요약 비유: 캠핑을 갈 때 펜션(클라우드 벤더)에서 제공하는 냄비와 이불(독점 기술)에 의존하면 다음번엔 다른 펜션으로 놀러 가기 어렵습니다. 아예 내 차에 나만의 튼튼한 텐트와 침낭(컨테이너와 쿠버네티스)을 싣고 다니면, 바다(AWS)든 산(GCP)이든 펜션 시설에 구애받지 않고 어디서나 똑같이 잠을 잘 수 있습니다.