마이크로소프트의 EEE(Embrace, Extend, Extinguish) 전략

마이크로소프트의 EEE(Embrace, Extend, Extinguish) 전략

마이크로소프트의 Embrace, Extend, Extinguish(EEE)는 1990년대 시장 지배 전략이다. 새 표준을 끌어안는 시늉을 한 뒤(Embrace), 독자 확장으로 표준을 분열시키고(Extend), 점유율을 무기로 원래 표준을 소멸시킨다(Extinguish). 1998년 반독점 재판에서 인텔 부사장 맥기디가 마리츠의 1995년 발언을 인용해 공식화되었다.
세 사례가 입증한다. Java 사건에서 J/Direct로 "Write Once, Run Anywhere"를 깨뜨렸고, 인터넷 익스플로러 사건에서 ActiveX로 웹 표준을 분열시켜 넷스케이프를 소멸시켰으며, Kerberos 사건에서 PAC 데이터로 유닉스 호환을 끊었다.
각 단계가 합법적으로 보이고 시간이 분산되어 있어 전체 패턴은 사후에야 드러난다. 친구의 얼굴을 한 협력자가 표준을 끌어안을 때, 그 안에 흡수의 의도가 숨어 있을 수 있다는 인식이 가장 깊은 방어다.

I. 개념의 자리

용어의 기원

Embrace, Extend, Extinguish는 1990년대 마이크로소프트의 시장 지배 전략을 가리키는 3단어 슬로건이다. 직역하면 "포용하고, 확장하고, 소멸시킨다"가 된다.

이 표현이 무게를 갖는 이유는 외부 비판자가 붙인 명칭이 아니라 마이크로소프트 임직원의 발언에서 출발한 표현이라는 점이다. 출처를 정확히 짚으면 두 단계가 있다. 먼저 "embrace and extend"라는 2단계 표현이 1994년 마이크로소프트 엔지니어 J Allard의 내부 메모 "Windows: The Next Killer Application on the Internet"에 변형된 형태(embrace, extend then innovate)로 등장했고, 빌 게이츠의 발언과 1996년 뉴욕타임스 기사에서도 회자되었다. 그 다음 "extinguish"가 덧붙은 3단계 표현은 1998년 미국 법무부 대 마이크로소프트 반독점 재판에서 인텔 부사장 스티븐 맥기디(Steven McGeady)의 증언을 통해 공식화되었다. 맥기디는 1995년 인텔과의 회의에서 마이크로소프트 부사장 폴 마리츠(Paul Maritz)가 넷스케이프와 Java, 인터넷에 대한 마이크로소프트의 전략을 설명하며 이러한 의도를 드러냈다고 증언했다. 마리츠가 정확히 "embrace, extend, extinguish" 세 단어를 그대로 사용했는지에 대해서는 해석의 여지가 있으나, 그 의도를 표현한 슬로건으로 이 3단어가 공식 기록에 자리잡았다. 검사 측은 이를 마이크로소프트의 반경쟁적 의도를 입증하는 핵심 증거로 활용했다.

세 단어가 모두 E로 시작하는 두운법(alliteration)이 인상적이어서 그 자체로 강력한 슬로건이 되었다. 줄여서 EEE라고도 불린다.

3단계의 메커니즘

1단계 Embrace는 새로 등장한 기술 표준이나 프로토콜을 자기 제품에 적극 통합하는 단계다. 표면적으로는 개방형 표준의 지지자로 보인다. 사용자에게 호환성을 약속한다. 이 단계에서 마이크로소프트는 어떤 적대적 행위도 하지 않는다. 표준의 보급에 기여하는 것처럼 보인다. 표준을 만든 원래 개발자나 단체에게는 거대 기업의 지지가 반갑게 느껴진다.

2단계 Extend는 자기 제품에 그 표준의 독자적 확장 기능을 추가하는 단계다. 표면적 명분은 사용자 편의 향상 또는 기능 개선이다. 그러나 이 확장 기능은 표준에 포함되지 않은, 마이크로소프트 제품에서만 작동하는 기능이다. 사용자가 이 확장 기능을 쓰기 시작하면 마이크로소프트 제품으로 만든 파일이나 데이터가 표준만 지원하는 다른 제품에서 제대로 작동하지 않는다. 책임이 다른 제품으로 전가된다. 시장 점유율의 비대칭이 결정적으로 작동한다. 마이크로소프트가 90%의 데스크톱을 장악하고 있으면, 마이크로소프트가 만든 확장 기능이 사실상 새로운 표준이 된다.

3단계 Extinguish는 원래 표준이 시장에서 밀려나는 단계다. 사용자는 마이크로소프트의 확장 기능에 익숙해져 다른 제품을 쓸 수 없게 된다. 표준을 만든 원래 개발자나 단체는 영향력을 잃는다. 마이크로소프트의 확장 기능이 사실상의 새 표준(de facto standard)으로 자리잡는다. 이 시점에 마이크로소프트는 원래 표준에 대한 지원을 줄이거나 종료한다. 경쟁 제품은 시장에서 사라지거나 주변부로 밀려난다.

II. Java 사건 (1995~2001)

배경: Java라는 위협

1995년 썬마이크로시스템즈가 Java를 발표했다. 당시 컴퓨터 산업의 가장 큰 문제는 운영체제마다 프로그램을 따로 만들어야 한다는 것이었다. 윈도우용 프로그램은 매킨토시에서 작동하지 않았고, 매킨토시용 프로그램은 유닉스에서 작동하지 않았다.

Java의 혁신은 이 문제를 해결한 것이었다. Java로 프로그램을 한 번만 작성하면, 어떤 운영체제든 Java 가상머신(JVM)만 깔려 있으면 그 프로그램이 똑같이 작동했다. 슬로건이 "Write Once, Run Anywhere"였다.

이게 마이크로소프트에 결정적 위협이었던 이유는 분명했다. 당시 마이크로소프트의 수익 핵심은 윈도우와 그 위의 오피스였다. 사람들이 윈도우를 사는 가장 큰 이유는 윈도우용 프로그램이 가장 많기 때문이었다. Java가 성공해서 모든 프로그램이 운영체제와 무관하게 돌아간다면, 윈도우의 독점적 지위는 무너진다.

빌 게이츠와 마이크로소프트 임원진이 이 위협을 정확히 인식했다는 사실은 반독점 재판에서 공개된 내부 문서들에 잘 기록되어 있다. 게이츠 자신이 1995년 5월 "The Internet Tidal Wave" 메모에서 인터넷에 최고 수준의 중요도를 부여한다고 선언했고, 마리츠는 1995년 6월 넷스케이프가 "Java API의 중요한 배포 매개체"라고 표현했다. 1997년 1월 마이크로소프트 내부 프레젠테이션에서는 "Java/JFC를 우리의 주된 위협으로 본다면, 넷스케이프가 그 주된 배포 매개체"라는 표현이 등장했다. 마이크로소프트 임원진이 Java와 넷스케이프를 결합된 위협으로 인식했다는 것이 일관된 기록이다.

Embrace: 끌어안기

마이크로소프트는 Java를 정면으로 거부하지 않았다. 1996년 3월 썬과 라이선스 계약을 맺고 Java를 윈도우에 통합하기로 했다. 인터넷 익스플로러에 Java 가상머신을 기본 탑재했다.

발표 당시 표면적 메시지는 분명했다. 마이크로소프트는 Java를 적극 지원하며, 윈도우는 Java를 위한 최고의 플랫폼이 될 것이라는 약속이었다. 자바 개발자 컨퍼런스에서 마이크로소프트 임원들이 무대에 올라 Java에 대한 헌신을 약속했다. 시장은 환영했다. 거대 기업의 지지가 Java 보급에 결정적이라고 본 것이다.

이 시점에 썬과 자바 개발자 커뮤니티는 마이크로소프트를 동맹으로 받아들였다. 함정은 그 다음 단계에서 시작된다.

Extend: 확장으로 분열시키기

마이크로소프트는 자기만의 Java 도구를 만들기 시작했다. Visual J++라는 개발 환경을 출시했고, 윈도우 전용 Java 확장 기능들을 추가했다.

가장 결정적인 것이 J/Direct였다. 이 기능은 Java 프로그램이 윈도우의 시스템 기능을 직접 호출할 수 있게 했다. 표면적 명분은 성능 향상과 윈도우 통합이었다. 그러나 이 기능을 사용한 Java 프로그램은 윈도우에서만 작동했다. 매킨토시나 유닉스의 Java 가상머신은 J/Direct 호출을 처리할 수 없었다.

또 하나가 AFC(Application Foundation Classes)였다. Java 표준에는 사용자 인터페이스를 만드는 AWT와 Swing이라는 표준 라이브러리가 있었다. 마이크로소프트는 이를 사용하지 말고 자기가 만든 AFC를 쓰라고 권장했다. AFC는 윈도우에서만 작동했다.

마이크로소프트의 Java 가상머신은 또 미묘하게 표준과 달랐다. 표준 Java가 명시한 특정 메서드를 누락하거나, 표준에 없는 메서드를 추가했다. 일반 개발자는 이 차이를 인식하기 어려웠다.

이 모든 확장 기능을 마이크로소프트는 강력하게 홍보했다. 윈도우용 Java 책과 강좌가 J/Direct와 AFC를 가르쳤다. 개발자 컨퍼런스에서 마이크로소프트는 더 빠르고 더 강력한 Java라며 자기 확장 기능을 시연했다. 신입 Java 개발자들이 이 확장 기능을 표준 Java로 오해하기 시작했다.

함정의 작동

문제는 시장 점유율에서 발생했다. 윈도우 시장 점유율이 90%가 넘었기 때문에 윈도우용 Java 개발자가 절대 다수였다. 그들이 J/Direct와 AFC를 사용해 만든 프로그램은 다른 운영체제의 Java 가상머신에서 제대로 작동하지 않았다.

매킨토시 사용자가 그 프로그램을 실행하면 오류가 났다. 표면적으로는 매킨토시 Java가 호환성이 떨어진다고 보였다. 실제로는 마이크로소프트가 표준에 없는 기능을 추가한 것이 원인이었다. 그러나 일반 사용자와 개발자는 이 사실을 알 수 없었다. Java의 핵심 약속인 "Write Once, Run Anywhere"가 깨졌다.

썬은 1997년 10월 8일 마이크로소프트를 계약 위반과 상표권 침해 등으로 제소했다. 라이선스 계약에서 마이크로소프트는 Java 표준을 충실히 구현하기로 약속했는데, 독자 확장으로 표준을 분열시켰다는 것이 핵심 주장이었다.

Extinguish: 소멸과 결과

1998년 11월 미국 연방지방법원 로널드 화이트(Ronald H. Whyte) 판사가 일부 가처분 판결에서 썬의 손을 들어줬다. 마이크로소프트에 90일 안에 썬의 Java Native Interface(JNI)를 지원하고 마이크로소프트 전용 키워드를 기본값에서 끄도록 명령했다. 그러나 그 시점에 이미 큰 피해가 발생했다. 윈도우 Java 시장에서 J/Direct와 AFC 기반 프로그램이 광범위하게 작성되어 있었다.

소송이 길어지는 동안 또 다른 일이 일어났다. 마이크로소프트가 .NET 프레임워크와 C# 언어를 개발하기 시작했다. 이건 Java를 대체할 마이크로소프트 독자 플랫폼이었다. 2000년 .NET을 공식 발표하면서 마이크로소프트는 사실상 Java에서 손을 떼는 방향으로 갔다.

2001년 1월 23일 썬과 마이크로소프트가 합의했다. 마이크로소프트는 2천만 달러를 지불하고, 1996년에 체결되었던 Java 라이선스 계약은 종료되었다. 그 대신 마이크로소프트는 기존 Java 1.1.4 기반 제품과 베타 단계의 제품을 7년 동안 계속 출시할 수 있는 권리를 부여받았다. 표면적으로는 썬의 승리였다.

그러나 진짜 결과는 그게 아니었다. 데스크톱 응용 프로그램 시장에서 Java는 결정적 모멘텀을 잃었다. 개발자들은 이미 .NET과 C#으로 이동하기 시작했다. Java는 서버 사이드와 안드로이드(나중에 등장)에서 살아남았지만, 마이크로소프트가 처음 두려워했던 시나리오, 즉 Java 기반 데스크톱 프로그램이 윈도우를 무력화하는 미래는 영원히 사라졌다.

EEE 전략이 완벽하게 작동한 사례다. 마이크로소프트는 1996년 Java를 끌어안았고, 1996년부터 1998년까지 확장으로 표준을 분열시켰으며, 1998년부터 2001년까지 자기 대안(.NET)을 만들면서 Java 위협을 소멸시켰다.

III. 인터넷 익스플로러와 웹 표준 (1995~2008)

배경: 넷스케이프의 위협

1994년 넷스케이프 커뮤니케이션즈가 설립되었다. 그들이 만든 넷스케이프 네비게이터 브라우저는 1995년 시장의 80%를 장악했다.

당시 넷스케이프의 야망은 단순한 브라우저가 아니었다. 창업자 마크 앤드리슨이 공개적으로 한 말이 있다. 브라우저가 운영체제를 무관한 부품으로 만들 것이라는 선언이었다. 운영체제 위에서 돌아가는 모든 응용 프로그램이 브라우저 안으로 옮겨가면, 윈도우든 매킨토시든 상관없어진다. 사용자는 웹만 있으면 모든 일을 할 수 있다.

이게 Java와 결합되면 더 강력해진다. 넷스케이프는 Java를 자기 브라우저에 깊이 통합했다. 웹 브라우저 안에서 Java 프로그램이 운영체제와 무관하게 돌아가는 미래가 그려졌다.

빌 게이츠는 이 위협을 자기 회고에서 인터넷 해일(Internet Tidal Wave)이라고 불렀다. 1995년 그가 임직원에게 보낸 메모의 제목이다. 마이크로소프트는 인터넷에 모든 자원을 집중하기로 결정했다.

Embrace: 표준 채택과 무료 배포

마이크로소프트는 자기 브라우저인 인터넷 익스플로러를 개발했다. 1995년 8월 IE 1.0이 윈도우 95 플러스팩의 일부로 출시되었다. 1996년 IE 3.0이 나오면서 본격적인 경쟁이 시작되었다.

이 단계에서 마이크로소프트의 메시지는 일관되었다. 우리는 웹 표준을 지원한다는 선언이었다. W3C(World Wide Web Consortium)의 HTML 표준을 채택하고, CSS 표준을 지원하며, JavaScript를 포함시켰다. 표준화 단체에 마이크로소프트 직원들이 참여해 적극적으로 활동했다.

표면적으로는 모범적인 표준 채택자였다. 웹 개발자들에게 이제 두 브라우저(넷스케이프와 IE) 모두 같은 표준을 지원한다는 메시지가 전달되었다.

여기에 결정적 장치가 있었다. IE를 무료로 배포한 것이다. 넷스케이프 네비게이터는 유료였지만(나중에 무료화), IE는 처음부터 무료였고 윈도우에 기본 탑재되었다. 윈도우를 산 모든 사람의 컴퓨터에 IE가 자동으로 깔렸다.

Extend: 독자 확장으로 표준 분열시키기

마이크로소프트는 표준에 없는 독자 기능을 IE에 추가하기 시작했다.

ActiveX가 가장 대표적이었다. 이건 웹 페이지 안에서 윈도우 프로그램의 기능을 직접 호출할 수 있게 하는 기술이었다. 표면적 명분은 더 풍부한 웹 경험이었다. 그러나 ActiveX는 윈도우에서만 작동했다. 매킨토시나 리눅스 사용자가 ActiveX를 사용한 웹사이트에 들어가면 페이지가 제대로 보이지 않았다.

VBScript도 마찬가지였다. 표준 JavaScript 대신 마이크로소프트가 만든 비주얼 베이직 기반 스크립트 언어였다. IE에서만 작동했다.

JScript는 마이크로소프트 버전의 JavaScript였다. 표준 JavaScript와 미묘하게 다른 동작을 했다. 일부 함수는 다른 결과를 내고, 일부 메서드는 IE에만 존재했다.

CSS 구현도 표준과 어긋났다. 박스 모델(box model)이라는 핵심 개념을 IE는 표준과 다르게 구현했다. 같은 CSS 코드가 IE에서는 한 방식으로, 넷스케이프에서는 다른 방식으로 표시되었다.

이 모든 비표준 기능을 마이크로소프트는 강력하게 마케팅했다. IE에서 더 잘 작동하는 웹이라는 메시지가 퍼졌다. 윈도우에 기본 탑재된 무료 브라우저였기 때문에 IE 사용자가 빠르게 늘었다. 1998년 IE 점유율이 50%를 넘어섰다.

결정적 압박: 웹 개발자의 선택

웹 개발자가 어느 표준에 맞춰 웹사이트를 만들지 선택해야 했다. 두 가지 옵션이 있었다.

첫째, 양쪽 모두에서 작동하도록 만든다. 이건 비용이 두 배 든다. 표준 기능만 쓰고, IE와 넷스케이프의 차이를 일일이 회피하는 코드를 작성해야 한다.

둘째, 점유율이 높은 쪽에 맞춘다. 사용자의 90%가 IE라면, IE에서만 잘 작동해도 충분하다. 비용도 절반이다.

대부분의 웹 개발자가 두 번째를 선택했다. 1990년대 후반부터 2000년대 초반까지 "이 사이트는 인터넷 익스플로러에 최적화되어 있습니다(Best viewed with Internet Explorer)"라는 문구가 인터넷의 표준 풍경이 되었다. 넷스케이프로 그런 사이트에 접속하면 페이지가 깨지거나 일부 기능이 작동하지 않았다.

이 과정에서 사용자가 넷스케이프는 호환성이 떨어진다고 인식했다. 실제로는 웹사이트가 IE 전용 기능을 쓴 것이 원인이었지만, 책임이 넷스케이프로 전가되었다. 사용자들이 IE로 이동했다.

Extinguish: 소멸과 그 이후

1998년 넷스케이프는 자신의 한계를 인식했다. AOL이 넷스케이프를 인수했지만 시장 점유율 하락을 막지 못했다. 2002년 넷스케이프 점유율은 5% 이하로 떨어졌다. 2008년 AOL은 넷스케이프 개발을 완전히 중단했다.

그 사이 IE 점유율은 2002년에 95%를 넘었다. 사실상 독점이었다. 이 시점에 마이크로소프트는 두 가지 결정적 일을 했다.

첫째, IE 개발을 거의 멈췄다. 2001년 IE 6이 출시된 후 5년간 새 버전이 나오지 않았다. 마이크로소프트는 경쟁자가 없는 시장에서 더 이상 혁신할 동기가 없었다. 웹 개발자와 사용자는 IE 6의 결함과 보안 문제를 5년간 견뎌야 했다.

둘째, ActiveX와 IE 전용 기능들이 사실상의 웹 표준이 되었다. 기업 내부 시스템들이 IE 6에서만 작동하도록 만들어졌다. 한국의 인터넷 뱅킹, 정부 사이트, 공인인증서 시스템 등이 ActiveX 기반으로 구축되었다. 한국에서 공인인증서 의무 사용이 폐지된 것이 2015년 3월이고, 공인인증서 제도 자체가 폐지된 것이 2020년 12월이었다. 2000년대 초반 도입부터 따지면 약 20년에 이르는 종속이었다.

원래의 W3C 웹 표준은 변두리로 밀려났다. W3C가 만든 진정한 개방 표준이 다시 살아나기까지 파이어폭스(2004), 사파리(2003), 크롬(2008)이 차례로 등장하고 마이크로소프트의 반독점 패소가 누적되어야 했다. 진짜 웹 표준의 복원은 2010년대에 들어서야 가능했다.

이게 EEE 전략의 가장 영향력 있는 사례다. 마이크로소프트는 1995년 웹 표준을 끌어안았고, 1996년부터 2001년까지 ActiveX 같은 독자 확장으로 표준을 분열시켰으며, 2002년부터 2008년까지 시장을 독점하고 진정한 표준을 사실상 소멸시켰다.

IV. Kerberos 사건 (1999~2000)

배경: Kerberos가 무엇인가

Kerberos는 1980년대 MIT가 만든 네트워크 인증 프로토콜이다. 회사 내부 네트워크에서 사용자가 한 번 로그인하면, 다른 서버나 서비스에 추가 로그인 없이 접근할 수 있게 하는 기술이다.

1990년대 후반 기업 IT 환경에서 Kerberos는 사실상 표준이었다. 유닉스 서버, 메인프레임, 네트워크 장비들이 모두 Kerberos를 지원했다. MIT가 만든 표준이 공개되어 있었기 때문에 어떤 회사 제품이든 표준을 따르면 서로 통신할 수 있었다.

Embrace: 표준의 공식 채택

마이크로소프트가 윈도우 2000을 개발하면서 Kerberos를 채택하기로 했다. 윈도우 NT 4.0까지는 마이크로소프트 독자 인증 방식인 NTLM을 사용했는데, 이게 보안과 확장성에 한계가 있었다. 기업 시장에서 마이크로소프트 서버가 다른 시스템과 통신해야 했기 때문에 표준 채택이 불가피했다.

1999년 마이크로소프트는 윈도우 2000이 Kerberos를 완전히 지원한다고 발표했다. IT 업계는 환영했다. 윈도우 서버와 유닉스 서버가 같은 인증 시스템으로 통합되면 기업 IT가 훨씬 단순해진다.

Extend: 비공개 확장의 삽입

윈도우 2000이 출시되었을 때 마이크로소프트의 Kerberos 구현에 한 가지 특이한 점이 있었다. 표준 Kerberos의 Authorization Data 필드 안에 마이크로소프트가 독자적으로 정의한 PAC(Privilege Attribute Certificate, 권한 속성 인증서)이라는 데이터 구조를 채워 넣은 것이다. Authorization Data 필드 자체는 표준 Kerberos에도 존재했지만, 그 안에 무엇을 담을지는 구현하는 쪽이 정의할 수 있었다. 마이크로소프트는 그 빈자리를 자기 형식으로 채웠다.

PAC의 표면적 기능은 사용자의 그룹 멤버십과 권한 정보를 인증 토큰에 함께 담는 것이었다. 마이크로소프트는 이것이 윈도우 도메인 구조의 효율을 위한 확장이라고 설명했다.

문제는 이 PAC 데이터 구조의 명세를 공개하지 않은 것이었다. 다른 회사의 Kerberos 구현은 PAC를 처리할 방법이 없었다. 윈도우 2000 서버가 보낸 Kerberos 인증 정보를 유닉스 서버가 받으면, 그 안의 PAC를 해석하지 못했다.

결과적으로 윈도우 2000과 유닉스 시스템 간 Kerberos 통합이 제대로 작동하지 않았다. 기업이 윈도우 서버를 도입하면 기존 유닉스 시스템과의 호환성 문제가 발생했다.

함정의 작동과 거짓 공개

기업 IT 관리자가 마주한 선택은 이러했다. 첫째, 윈도우 서버를 포기하고 유닉스 시스템에 그대로 머문다. 둘째, 모든 서버를 윈도우로 통일한다. 셋째, 두 시스템을 운영하면서 복잡한 호환성 문제를 해결한다.

마이크로소프트의 영업이 강력하게 작동했다. 윈도우 2000이 모든 인증 문제를 해결한다는 메시지였다. 그러나 그 해결은 모든 시스템을 윈도우로 통일할 때만 작동했다. 기업들이 점차 윈도우 서버로 이동하기 시작했다.

오픈소스 진영이 항의했다. 마이크로소프트가 PAC 명세를 공개해야 한다고 요구했다. 마이크로소프트는 처음에는 거부했다. 2000년 5월 마이크로소프트가 마침내 이 명세를 공개했는데, 한 가지 특이한 조건이 있었다. 명세를 다운로드하려면 Windows 실행 파일(.exe)을 실행하고 클릭스루 라이선스에 동의해야 했다. 라이선스에는 "이 명세는 마이크로소프트의 비밀 정보이자 영업비밀이며, 이를 받은 자는 다른 사람에게 공개할 수 없고 자기 자신의 비밀 정보를 보호하는 수준의 보안 조치를 취해야 한다"는 조항이 있었다.

이건 거의 코미디였다. 명세를 공개하면서 그 내용을 영업비밀로 취급하라고 요구한 것이다. 오픈소스 개발자는 이 라이선스에 동의하면 자기들이 만드는 자유 소프트웨어에 그 정보를 사용할 수 없게 된다. 사실상 공개가 아니었다. 슬래시닷이 이 모순을 폭로했고, 마이크로소프트는 슬래시닷에 라이선스 위반 게시물 삭제를 요구해 또 한 차례 논란을 빚었다.

Extinguish: 인증 시장의 재편

Kerberos 사례는 Java나 IE만큼 극적인 결말은 없다. 그러나 그 효과는 작지 않았다. 1990년대 말까지 기업 인증 시스템에서 다양했던 생태계가 2000년대 초반 윈도우 액티브 디렉터리 중심으로 통합되었다. 마이크로소프트가 의도한 기업 인증 시장 장악이 상당 부분 달성되었다.

표준 Kerberos는 살아남았지만 기업 시장에서는 윈도우 액티브 디렉터리가 사실상의 표준이 되었다. 이건 마이크로소프트가 표준을 끌어안고 그 안에 자기 비공개 확장을 심어서 시장을 자기 쪽으로 이동시킨 전형적 사례다.

V. 세 사례의 공통 구조

세 사례를 나란히 놓으면 같은 패턴이 보인다.

먼저 잠재적 위협이 등장한다. Java는 운영체제 독립을 약속했고, 넷스케이프는 브라우저로 운영체제를 무력화하려 했고, Kerberos는 기업 인증 시장에서 마이크로소프트 독자 방식의 대안이었다.

마이크로소프트는 정면 대결을 피했다. 그 위협을 끌어안고 자기 제품에 통합했다. 이 단계에서 위협의 주인은 거대 기업의 지지를 환영했다.

마이크로소프트는 자기 제품 안에서 그 표준을 미묘하게 변형시켰다. J/Direct, ActiveX, PAC 데이터 구조는 모두 같은 성격이다. 표준에 없는 독자 기능을 추가하고, 그것이 자기 제품에서만 작동하게 했다.

시장 점유율이 비대칭이었기 때문에 마이크로소프트 버전이 사실상의 새 표준이 되었다. 원래 표준에 충실한 경쟁 제품들은 호환성이 떨어지는 제품으로 인식되었다.

원래 표준의 주인은 시장에서 밀려났다. 썬은 Java로 데스크톱 시장을 장악하지 못했고, 넷스케이프는 사라졌으며, MIT의 Kerberos는 기업 인증 시장에서 변두리가 되었다.

각 단계가 길게 분산되어 있었다는 점이 중요하다. Java 사건은 1996년부터 2001년까지 5년, IE 사건은 1995년부터 2008년까지 13년, Kerberos 사건은 1999년부터 2000년대 중반까지 진행되었다. 이 긴 시간 동안 한 단계씩 보면 각각 정당화할 수 있는 사업 결정처럼 보였다. 전체를 묶어서 봐야만 그것이 한 전략의 단계별 실행이었음이 드러난다.

이게 EEE가 무서운 이유다. 시간이 분산되어 있고, 각 단계가 합법적이며, 결과적으로 시장 지배가 영구화된다.

VI. 전략의 본질

EEE의 본질은 표준을 만드는 자가 아니라 표준을 변형하는 자가 되는 것이다. 새로운 표준이 등장하면 그것을 처음부터 거부하지 않는다. 받아들이는 척하면서 그 안에서 자기 영향력을 키운다. 어느 순간 자기가 표준이 된다.

이 3단계 전략이 강력한 이유는 각 단계가 개별적으로는 합법적이고 심지어 친소비자적으로 보이기 때문이다. 1단계 Embrace는 개방형 표준에 대한 지지로 환영받는다. 2단계 Extend는 혁신과 기능 개선으로 정당화된다. 3단계 Extinguish는 시장 선택의 결과로 설명된다. 어느 한 단계도 그 자체로는 반독점법 위반이라고 입증하기 어렵다. 그러나 세 단계가 결합되어 작동할 때 그 효과는 시장 지배의 영구화다.

또 하나의 정교함은 시간 분산이다. Embrace에서 Extinguish까지 보통 3년에서 7년이 걸린다. 이 긴 시간 동안 사용자, 개발자, 규제 당국 모두가 그 전체 패턴을 인식하기 어렵다. 한 단계씩 보면 각각 별개의 사건처럼 보인다.

깊은 자리에 있는 것은 직접 파괴가 아니라 흡수를 통한 파괴라는 점이다. 적을 정면에서 공격하면 평판 손상과 반독점 규제의 위험이 크다. 적을 끌어안은 뒤 안에서 변형시키면 그 위험이 거의 없다. 표면적으로는 협력의 외피를 쓰고 있기 때문이다.

VII. 현대적 변형

EEE는 1990년대 마이크로소프트의 전략으로 명명되었지만 그 본질은 현재의 빅테크 기업들에서 더 정교하게 작동한다.

구글이 안드로이드를 통해 오픈소스 운영체제 생태계를 포용한 뒤 구글 플레이 서비스라는 독자 계층을 확장해 사실상의 종속 구조를 만든 것도 같은 패턴이다. 페이스북이 인스타그램의 핵심 기능을 자기 플랫폼으로 흡수하고, 스냅챗의 스토리 기능을 모방해 확장한 것도 비슷하다. 아마존이 자기 마켓플레이스에 입점한 셀러의 데이터를 분석해 동일 제품을 PB 상품으로 출시하는 행태도 본질적으로 같은 구조다.

따라서 EEE는 단순히 한 회사의 한 시대의 전략이 아니라 거대 플랫폼이 새로운 표준이나 신규 진입자를 흡수하는 보편적 패턴의 이름이라고 볼 수 있다.

대기업의 스타트업 흡수에도 같은 구조가 작동한다. 합작법인 함정이 가장 직접적인 변형이다. 스타트업의 기술과 시장을 전략적 파트너십으로 받아들이고(Embrace), 합작법인 안에서 대기업의 자원과 영향력을 확장하며(Extend), 결국 원래 스타트업을 껍데기로 만든다(Extinguish). 듀딜리전스를 통한 기술 유출도 같은 구조다. 투자 검토라는 명분으로 받아들이고, NDA의 빈틈을 통해 본체 사업부로 정보를 확장시키고, 유사 제품을 출시해 원래 스타트업의 시장을 소멸시킨다.

VIII. 종합적 통찰

EEE는 1955년 코수가-시걸의 양파 코너링 사건과 본질적으로 같은 구조다. 그들도 양파 시장을 정면으로 공격하지 않았다. 시장에 참여해 가장 큰 보유자가 되었다(Embrace). 그러나 자기 손에 든 막대한 물량을 시장 가격을 조작하는 도구로 변환했다(Extend). 마지막으로 그 물량을 한꺼번에 풀어 시장 자체를 무너뜨렸다(Extinguish). 양쪽에서 돈을 거두었다.

마키아벨리가 「군주론」에서 말한 한 구절이 정확히 이 자리에 적용된다. "사람들은 두려운 상대보다 사랑하는 상대를 해칠 때 덜 망설인다." 적이 사랑의 얼굴, 협력의 얼굴, 표준 채택자의 얼굴로 다가올 때 우리는 방어를 푼다. 그 풀린 방어 사이로 흡수가 시작되고, 흡수가 완료된 뒤에야 그것이 공격이었음을 깨닫는다.

한비자가 「세난(說難)」에서 남긴 한 구절도 여기 연결된다. "용은 부드러운 짐승이라 길들여 탈 수 있다. 그러나 그 목 아래 한 자 정도 거꾸로 난 비늘이 있어, 사람이 그것을 건드리면 반드시 죽인다(夫龍之爲蟲也 柔可狎而騎也 然其喉下有逆鱗徑尺 若人有嬰之者 則必殺人)."

Embrace는 부드러움이고, Extend는 가까이 다가가는 것이고, Extinguish는 역린이 발동하는 순간이다. 용을 길들였다고 믿는 자가 가장 먼저 잡아먹힌다.

EEE 전략에서 벗어나는 가장 깊은 자리는 인식이다. 거대 기업이 우리 표준을, 우리 기술을, 우리 시장을 끌어안는다고 할 때 그것이 보호가 아니라 흡수의 시작일 수 있다는 인식. 그 인식이 있는 자만이 텀시트의 호환성 조항을 의심하고, 라이선스 계약의 확장 권한을 좁히며, 표준의 통제권을 끝까지 자기 손에 둔다.

표준을 만든 자가 표준을 지키지 못하면, 표준을 변형한 자가 결국 표준이 된다. 이게 마이크로소프트가 1990년대에 보여준 가장 깊은 가르침이다.