2025년 11월 20일·3분
래리 엘리슨과 오라클: 데이터베이스, 락인, 그리고 엔터프라이즈 영업
오라클과 래리 엘리슨이 데이터베이스, 전환 비용, 라이선스, 엔터프라이즈 영업 규율을 통해 어떻게 지속적인 수익 구조를 만들었는지를 알기 쉽게 정리한 글.
오라클과 래리 엘리슨이 데이터베이스, 전환 비용, 라이선스, 엔터프라이즈 영업 규율을 통해 어떻게 지속적인 수익 구조를 만들었는지를 알기 쉽게 정리한 글.
래리 엘리슨의 지속적 부 공식은 이렇게 요약할 수 있다: 미션 크리티컬한 데이터베이스를 판매하고, 다년 계약으로 묶고, 전환보다 그대로 있는 것이 더 안전하게 느껴지도록 만드는 엔터프라이즈 영업 조직을 구축하라.
이 글은 오라클이 어떻게 대체하기 어려운 존재가 되었는지를 설명하는 비즈니스 이야기다—데이터베이스 내부 구조에 대한 깊은 기술 튜토리얼이 아니다. SQL 옵티마이저가 어떻게 동작하는지 몰라도 오라클이 수십 년간 현금 창출 엔진이 된 이유를 이해하는 데는 문제가 없다.
“지속적”이라고 해서 고객들이 매 갱신을 사랑했다는 뜻은 아니다. 대신 오라클은 매출이 반복되는 쪽으로 포지셔닝했다.
지속성은 다음으로 드러난다:
데이터베이스가 청구, 재고, HR, 거래 시스템 아래에 깔려 있으면 단순한 IT 도구가 아니다. 의존성이 되고, 의존성은 끈끈하다.
1) 기본으로서의 데이터베이스. 오라클은 가장 가치 있는 운영 데이터가 담긴 “시스템 오브 레코드” 층에 집중했다.
2) 락인(때로는 우연히 생긴). 단순히 기술적 호환성만이 아니라 수년간 쌓인 프로세스, 통합, 교육, 벤더 고유 기능이 누적된다.
3) 엔터프라이즈 영업. 오라클은 소비자용 앱처럼 획득하지 않았다. 조달 주기, 경영진 관계, 관계를 연장하도록 설계된 계약으로 이겼다.
이들 기둥은 복리 효과를 만들었다: 각 신규 계약은 단발성 판매가 아니라 향후 여러 차례 지불 가능성을 높였다.
래리 엘리슨은 처음부터 소프트웨어 유명인은 아니었다. 초기 경력은 프로그래밍 업무와 대규모 조직이 실제로 기술을 어떻게 구매하는지—느리게, 신중하게, 안정적이라고 보이는 벤더를 선호하는지—배우는 실무적 경험의 조합이었다.
오라클은 1977년(Software Development Laboratories로) 시작하면서 명확한 가설을 가졌다: 소프트웨어에서 가장 큰 돈은 커스텀 일회성 시스템이 아니라 대기관에 인프라를 파는 데서 나온다. 엘리슨과 공동 창업자들은 취미용이나 소비자 시장을 쫓기보다 급여, 재고, 청구, 회계 등을 운영해야 하는 기업과 정부 기관을 목표로 삼았다.
그 시절 컴퓨팅은 메인프레임과 중앙집중식 데이터가 지배했다. 클라이언트-서버 구성이 등장하더라도 대기업 내부의 기본 가정은 시스템이 신뢰할 수 있고, 감사 가능하며, 수년간 지원되어야 한다는 것이었다.
그 환경은 표준 구성 요소가 될 수 있는 소프트웨어에 보상을 줬다—IT 팀이 그 위에 구축할 수 있는 무언가. 데이터베이스는 완벽하게 맞아떨어졌다: 많은 애플리케이션 아래에 깔리고, 중요한 데이터를 건드리며, 지속적인 유지보수와 지원을 정당화했다.
엔터프라이즈 고객은 개인처럼 구매하지 않는다. 위원회, 조달 절차, 다년 계획을 통해 구매한다. 이는 벤더로 하여금 다음을 강조하게 만든다:
또한 재무 프로파일을 바꾼다. 단일 대형 계약으로 수년간의 제품 작업을 지원할 수 있지만, 관계 기반의 영업 모션이 필요하다—증거, 관계, 위험 완화에 근거한 영업.
오라클의 초기 베팅은 단순했다: 엔터프라이즈 운영의 핵심 자리를 차지하면 단순히 소프트웨어를 파는 것이 아니라 업데이트, 지원, 업그레이드를 통해 지속성을 판매하게 된다. 조직은 의존도가 커질수록 계속 비용을 지불한다.
데이터베이스는 회사의 시스템 오브 레코드다: “공식적 진실”이 위치하는 곳. 고객 계정, 청구서, 재고 수량, 급여 항목, 배송 상태—이것들은 단순한 파일이 아니다. 기업이 돈을 벌고, 규제를 준수하며, 일상적으로 운영하기 위해 의존하는 사실들이다.
엔터프라이즈가 더 많은 소프트웨어(ERP, CRM, 청구, 공급망)를 구축할수록 애플리케이션들은 점점 동일한 기저의 진실을 공유했다. 데이터베이스가 사용할 수 없으면 그 레코드를 읽고 쓰는 애플리케이션은 일을 못한다. 이는 데이터베이스를 단순한 IT 부품이 아닌 핵심 의존성으로 만든다.
데이터베이스는 애플리케이션이 그것을 중심으로 작성되기 때문에 끈끈해진다. 시간이 지나면 다음이 쌓인다:
전환은 스프레드시트를 바꾸는 것과 다르다. 대량의 데이터를 마이그레이션하고, 기록을 보존하고, 핵심 워크플로를 재테스트하며, 종종 애플리케이션 일부를 다시 작성해야 한다. 새 옵션이 더 싸더라도 프로젝트 리스크가 절감액을 초과할 수 있다.
미션 크리티컬 시스템에 대해 두려운 것은 "이번주 조금 느려지는 것"이 아니다. 주문 처리 중단을 일으키거나 조정, 환불, 규제 문제를 초래하는 데이터 손실이다.
하루의 장애 비용이 수백만 달러에 달하거나 신뢰를 훼손할 수 있을 때, 구매자는 보수적으로 변한다. “안정적으로 동작한다”가 “새롭고 유망하다”보다 우선한다.
IT 부서는 안정성으로 평가받는다. 이는 과거에 모든 실패 모드를 본 경력이 있는 성숙한 도구와 지원팀을 가진 벤더로 향하게 한다.
일단 그 결정이 내려지면 데이터베이스는 스택의 닻(anchor)이 되어—애플리케이션, 프로세스, 예산을 그 궤도로 끌어들인다.
관계형 데이터베이스는 고객, 청구서, 배송 등 비즈니스 데이터를 표(스프레드시트처럼)에 저장하는 방식이다. 파일을 뒤지는 대신 “30일 이상 미지급된 모든 청구서를 보여줘” 같은 질문을 빠르고 일관되게 할 수 있다.
SQL(구조화 질의 언어)은 관계형 데이터베이스와 대화하는 공통 언어다. SQL이 널리 교육되고 지원되므로 데이터베이스 제품이 교체 가능하다고 가정하기 쉽다.
하지만 실제 회사에서 중요한 것은 시스템이 SQL을 이해하느냐만이 아니다. 차별화는 그 주변의 모든 것에서 드러난다: 데이터베이스가 높은 부하에서 어떻게 동작하는지, 충돌 후 어떻게 복구하는지, 백업이 어떻게 작동하는지, 권한 관리 방식, 팀이 성능을 모니터링하고 튜닝하는 방법 등.
오라클은 ‘SQL을 팔지’ 않았다. 오라클은 미션 크리티컬 시스템이 계속 동작할 것이라는 약속을 팔았다.
경쟁사가 기능을 맞췄다 해도, 데이터베이스를 표준으로 삼는 결정은 팀, 예산, 수년에 걸친 운영적 습관으로 퍼진다. 데이터베이스가 리포팅, 통합, 준수의 중심이 되면 “충분히 좋음” 기술로는 이기기 어렵다.
시장 지배력은 보통 제품 품질, 리스크 관리, 영업 실행의 조합을 반영한다—하나의 킬러 기능만으로 설명되지 않는다.
오라클은 개발자가 신용카드로 결제하기를 기다리며 이기지 않았다. 그들은 대기업이 실제로 어떻게 구매하는지를 배웠다: 느리게, 신중하게, 많은 사람이 참여하는 방식으로.
엔터프라이즈 조달은 팀 스포츠다. 전형적인 딜은 IT 리더, 보안, 재무, 법무, 해당 시스템을 소유할 사업 부서를 끌어들인다. 이는 긴 타임라인, 공식 요건, 내부 정치가 따른다.
오라클은 개념 증명(POC), 레퍼런스 고객, 자세한 호환성 주장을 통해 이 현실에 기댔다. POC는 단순한 기술 테스트가 아니라 후원자가 방 안의 모든 사람에게 구매를 정당화하도록 돕는 방식이다.
오라클은 클래식한 계정 기반 판매를 구축했다: 전담 영업 담당자, 명명된 계정, 정기적인 분기별 비즈니스 리뷰—“ABM”이 유행하기 훨씬 전부터.
목표는 첫 계약만이 아니었다; 다음 프로젝트, 그다음 프로젝트의 기본 데이터베이스 선택지가 되는 것이었다. CIO나 DBA 팀과의 신뢰는 예산, 조직 개편, 단기 제품 불만족을 견딜 수 있다.
지원 계약, 인증(DBA, 개발자), 시스템 통합 업체는 모멘텀을 만든다. 한 회사가 숙련된 인력을 교육하고 승인된 아키텍처를 갖추고 오라클을 잘 아는 파트너를 두면 벤더 변경은 위험을 높이는 일처럼 느껴진다.
파트너는 RFP에 추천되는 항목, 사용 가능한 기술 스택, 어떤 플랫폼이 "안전"으로 간주되는지를 좌우한다.
갱신은 새로운 로고 획득보다 더 중요할 수 있다. 오라클이 핵심 시스템에 깊게 박히면 연간 갱신은 신규 평가가 아니라 비즈니스 연속성 결정이다. 그때 가격 책정, 감사 조건, 계약 구조가 제품 기능만큼 행동을 형성한다.
(그 레버리지의 메커니즘은 /blog/how-lock-in-works 를 보라.)
벤더 락인은 악의가 필요 없다. 단순히 벤더 제품에 대한 의존성이 커지고 시간이 지남에 따라 전환 비용이 증가하는 현상이다. 데이터베이스 같은 핵심 시스템의 경우, 데이터베이스가 애플리케이션, 리포팅, 보안, 일상 운영 아래에 있기 때문에 그 결합력이 강해진다.
기술적 락인은 시스템이 쉽게 복제되지 않는 기능에 의존할 때 발생한다. 데이터베이스에서는 종종 독점 기능(특수 SQL 확장, 성능 힌트, 클러스터링 방식), 벤더별 툴링, 애플리케이션·미들웨어와의 깊은 통합으로 드러난다.
실제 배포는 저장 프로시저, 트리거, 백업 스크립트, 모니터링 에이전트, 커스텀 커넥터를 축적한다. 스택의 많은 부분이 한 데이터베이스에 맞춰져 있을수록 깔끔한 마이그레이션은 더 어렵다.
운영적 락인은 사람과 프로세스의 문제다. 팀은 특정 플랫폼에 대한 교육을 받고, 특정 인증 경로를 가진 관리자를 채용하며, 장애 조치, 업그레이드 실행 방법, '정상' 성능이 무엇인지에 대한 런북을 만든다.
시간이 지나면서 컴플라이언스와 감사 문서도 특정 데이터베이스에 특화된다: 접근 통제, 암호화 설정, 보존 정책, 사고 대응 단계 등. 벤더를 바꾸려면 직원 재교육, 절차 재작성, 통제 재검증이 필요하다.
계약적 락인은 전환 비용을 달력 현실로 만든다. 다년 기간, 번들 지원 구조, 갱신 주기, 엔터프라이즈 전체 계약은 "다음 분기에 바꾸자"는 선택을 비현실적으로 만들 수 있다.
지원은 큰 레버다: 중요한 시스템이 패치와 보안 지침을 위해 벤더 지원에 의존하면 떠나기는 새로운 운영 리스크를 떠안는 것처럼 느껴진다—특히 계약에 엄격한 사용 정의와 부분 마이그레이션을 복잡하게 만드는 벌칙이 포함된 경우.
“지속적(durable)”이라는 표현은 고객이 매번 갱신을 즐겼다는 뜻이 아니다. 대신 오라클의 수익 구조가 반복되는 경향을 갖도록 설계되었다는 의미다.
오라클의 경우, 지속성은 다음에서 기인했다:
데이터베이스는 청구, 급여, 재고, 거래, 규제 보고 등 비즈니스 운영을 뒷받침하는 시스템보다 아래에 위치한다.
데이터베이스가 **시스템 오브 레코드(system of record)**가 되면, 중단이나 데이터 손실은 운영 및 규제상 치명적 위험을 초래한다. 그래서 구매자는 새롭고 유망한 기술보다 안정성과 검증된 지원을 우선시한다.
그렇지 않다. SQL은 표준이지만 기업은 '문법'을 사는 것이 아니라 결과를 산다: 가동 시간, 복구, 부하 상황에서 성능, 보안 통제, 툴링, 그리고 지원.
두 제품이 모두 SQL을 지원해도 다음 항목들에서 크게 달라질 수 있다:
시간이 지나면서 전환 비용이 누적된다.
일반적인 원천은:
대안이 더 저렴해도 마이그레이션 위험이 절감액을 초과할 수 있다.
오라클은 위원회에 판매했고 긴 구매 주기를 전제로 계정을 장기 관계로 관리했다.
전형적인 전술은 다음을 포함했다:
여기서 영향력이 가장 큰 시점이기 때문이다.
데이터베이스가 핵심 운영을 지원하면 갱신은 비즈니스 연속성 결정이 되어, 새로 구매할지 여부를 묻는 상황이 아니다. 이는 대화를 "우리가 안전하게 바꿀 수 있나?"로 바꾸는데, 이것은 훨씬 더 어렵다.
또한 갱신 시점에서 가격, 감사 조항, 지원 정책이 큰 영향을 미친다.
세 층이 서로를 강화한다:
원하면 메커니즘을 자세히 보려면 포스트의 /blog/how-lock-in-works 를 참고하라.
오라클 라이선스는 흔히 여러 '계량기'를 사용하며, 성장하면 그중 적어도 하나가 커지는 경향이 있다.
일반적 레버는:
실무적 위험은 복잡성이 총소유비용을 예측하기 어렵게 하고, 의도치 않게 계약 위반으로 흘러갈 여지를 만든다는 점이다.
감사(또는 라이선스 검토)는 계약 조건에 따라 사용량이 구매한 것과 일치하는지 확인하는 절차다.
실무적으로, 이는 다음을 만들 수 있다:
위험을 줄이려면 배포를 추적하고, 가상화·DR·개발/테스트 등 메트릭 정의를 이해하며, 명확한 내부 사용 보고를 유지하라.
자동으로 약화되지는 않는다—클라우드는 락인의 모양을 바꾸지만 없애지는 않는다.
관리형 데이터베이스는 운영 부담을 줄여주지만 여전히 주의해야 할 점이 있다:
많은 기업이 수년간 온프레미스 오라클과 클라우드 서비스를 혼합해 운영하며, 탈출 옵션을 현실적으로 유지하려 한다.