2주 전, Ethereum 커뮤니티의 최대 축제이자 개발자 컨퍼런스인 Devcon5에 다녀왔다. 2017년의 Devcon3 이후 2년 만이다. 블록체인 업계의 최대 행사이자 사실상 이쪽 판에서 몇 안 되는 제대로 된 개발자 컨퍼런스(...)인 만큼 다양한 주제의 논의들이 오갔지만, 역시나 가장 화두가 된 주제는 (애초에 이더리움 컨퍼런스니) Ethereum 2.0에 관한 것이었다. Ethereum 2.0은 단순히 기술적인 측면에서의 아키텍처적인 개선뿐만이 아니라, 이더리움과 블록체인을 바라보는 전반적인 관점에서의 전면적인 변화를 의미하기 때문이다. Proof-of-Stake (Casper)로의 이행 하나만 보아도, 그 자체로도 하나의 업계(Staking & Validation Pool)와 관련된 서비스들 (Staking-related DeFi)가 통째로 생겨났을 만큼 그 파장과 영향력은 실로 어마어마한 수준이다.

Devcon5 Opening Ceremony

대다수의 사람들이 (직접적인 돈이 걸려있는) PoS 전환과 DeFi 관련 논의들에만 집중하고 있기는 하지만, Ethereum 2.0은 단순히 그런 수준의 변화에 한정되지는 않는다. 내부적인 아키텍처를 들여다보면, 1.0과 완전히 다른 체인이라 불러도 무방할 만큼 큰 변화를 동반하고 있기 때문이다. 샤딩 등의 "표면적인" 확장성 변동들을 제외하고서라도, WebAssembly (ewasm)으로의 전환과 같은 DApp 런타임의 변동은 이더리움이 단순히 하나의 블록체인이나 암호화폐가 아니라, 완전히 새로운 개념의 확장 가능한 플랫폼을 지향하고 있다는 것을 명확히 보여주고 있다. Ethereum 2.0으로의 전환은 곧 소프트웨어 플랫폼, 즉 실행 환경의 변화를 의미한다는 뜻이다.

하지만 플랫폼과 실행 환경의 변화에는 항상 피할 수 없는 숙명이 뒤따른다. 바로 기술적 레거시다. 이 주제와 관련해 EDCON 즈음 작성한 지난번 글에서도 언급한 바 있으나, 인스트럭션셋과 런타임을 전환한다는 것은 단순히 비즈니스 레벨에서 해결될 수 있는 플랫폼 전략상의 문제가 아니다. WASM이 모두가 동등한 미래라는 명확한 비전을 제시하고 있고 실제 프로덕트로 보여주고 있는 것은 분명한 사실이다. 하지만, 인스트럭션셋 전환에 필연적으로 따라오는 기술부채와 레거시블록체인의 immutability와 결합되면 기술부채가 블록체인이 살아있는 한 계속해서 따라오고, 그것이 신규 개발자 풀의 유입을 지속적으로 막아 생태계 성장을 방해하는 최악의 결과를 초래할 수 있다는 것은 이미 이전에도 여러 번 강조한 바 있다.

비개발자 출신의 결정권자들은 기술부채와 레거시가 플랫폼 상의 전략에 얼마나 큰 영향을 미치는지 잘 이해하지 못하는 경우가 많다. 항상 돈에 쫓겨야 하는 비즈니스적인 입장에서는 최대한 빠르게 프로덕트를 시장에 내놓아 평가를 받고, 재빠르게 투자금을 회수하는 것이 기술부채 같은 "공돌이 갈아넣으면 충분히 해결될 수 있는 기술적 문제들"보다 훨씬 우선순위가 높을 수밖에 없기 때문이다.직접 공돌이 갈아넣어보고 슈퍼갑에게 갈림당하기도 한 입장에서 이해 못 하는 바는 아니나, 기술부채는 - 특히 플랫폼과 직접적으로 관계된 것이라면 - 절대 개발자들의 노동만으로 해결되는 수준의 문제가 아니다. 조직 내부에서만 사용되는 코드베이스의 경우라면 기술부채는 후임 개발자들을 고통에 빠트리는 수준에서 끝나지만, 하나의 플랫폼과 관계된 것들 (ISA, Runtime, API 등등)에 기술부채가 누적되면 해당 플랫폼의 생태계 구성에 큰 악영향을 미칠 수밖에 없다. 플랫폼 생태계를 구동하는 핵심은 결국 외부 개발자들인데, 독립 개발자들은 절대 기술부채가 넘쳐나는 플랫폼을 우선적으로 선택하지 않기 때문이다. 이유야 단순하다. 개발하기 고통스러우니까.

그래서, 이번 글에서는 기술 부채에 대한 전략의 차이가 구체적으로 우리가 사용하는 플랫폼에 어떻게 영향을 미쳤는지, 그리고 시장의 판도를 어떻게 바꾸었는지 간단하게 톺아보고자 한다. 무작정 기술부채에 매달려 일하지 말라는 뜻이 아니라, 플랫폼 전략에 기술적 요소들이 반영되지 않으면 초래될 수 있는 결과에 대해 살펴보자는 취지다.

Apple versus Microsoft

이 두 기업은 PC 시장에서의 영원한 라이벌이다. 애플은 세계 최초로 PC라는 개념을 대중화한 기업이며, 마이크로소프트는 BASIC이라는 최초의 고수준 (High-Level) 프로그래밍 언어 및 인터페이스를 판매하기 시작한 것에서 출발했다. 이때까지만 해도 마이크로소프트에게 애플은 BASIC 등의 자사 소프트웨어를 납품하는 여러 PC 제조사 중 한 곳일 뿐이었다.

최초로 대중화된 PC인 애플2가 1977년 출시되고 얼마 지나지 않은 1981년, PC 시장의 판도를 완전히 뒤흔들어놓은 제품이 등장했으니 바로 기존 메인프레임 시장의 절대 강자 (60%가 넘는 시장점유율을 자랑했다) 인 IBM이 PC 시장에 뛰어든 것이었다. "프로젝트 체스"라 불린 이 프로젝트는 (모든 것을 인하우스로 개발할 능력이 충분히 있었음에도 불구하고) 생태계 확보를 위해 최대한 이미 검증된 외부 개발사의 실리콘과 소프트웨어를 사용하기로 결정된 상황이었다.

이미 프로젝트 체스를 위해 마이크로소프트로부터 BASIC을 공급받기로 한 IBM은 자사의 PC에 쓰일 OS를 공급할 기업을 찾기 시작했는데, 이들이 처음 고려한 솔루션은 디지털리서치라는 기업이 개발한 CP/M이라는 OS였다. 그도 그럴 것이 CP/M은 당시 PC 시장에서 사실상 거의 유일하게 "운영체제"라는 이름을 붙여줄 만한 가치가 있는 소프트웨어였기 때문에 이는 당연한 선택이었는데, 당시 소프트웨어 시장에서 OS 비슷한 것은 Disk I/O 기능이 있는 BASIC (BASIC 코드만을 통해 PC를 조작했다고 생각하면 쉽다) 이나 각 PC 제조사가 만든 독자 OS 정도였으니 말 다했다. 다만 석연치 않은 이유로 인해 IBM은 CP/M을 공급받지 않기로 결정했고, 대신 이미 BASIC 공급 계약을 맺은 마이크로소프트를 찾아가 IBM PC에 탑재될 OS를 기한 내에 공급할 수 있겠냐고 물었다.

물론 이 당시 마이크로소프트는 반쯤 취미(...)로 BASIC을 펀치카드에 찍어 돌려팔던 허접한 스타트업이었기에, (IBM PC에 탑재될) 인텔 8086 칩에 호환되는 OS는커녕 기초적인 OS 개발 경험조차 없었다. 그럼에도 빌 게이츠는 (여러 가지 빽을 통해) IBM과의 계약을 따냈고, 이제 IBM이라는 거대 기업이 내놓을 최초의 PC에 탑재될 OS를 1년도 남지 않은 시간 동안 개발해야 하는 상황에 놓이게 되었다. 하지만 빌 게이츠는 실제 OS 개발 따위는 하지 않았고 (...) BASIC을 팔아 번 돈으로 시에틀컴퓨터라는 회사가 개발한 86-DOS (Quick and Dirty Operating System의 약자인 QDOS라고도 불렸다) 에 대한 모든 권리를 $75,000에 인수함과 동시에 86-DOS의 수석 개발자인 팀 패터슨을 영입했다. IBM PC가 출시되기 3개월 전인 1981년 5월의 일이었다.

이후 고작 3개월 만에 마이크로소프트는 86-DOS를 MS-DOS로 리브랜딩하고, 몇 가지 손질 작업을 거쳐 IBM에게 납품했다. IBM은 이것을 PC-DOS 1.0으로서 자사의 PC와 함께 제공하기에 이른다. 이것이 전설적인 MS-DOS의 시작이었다.

최초의 MS-DOS는 기본적인 하드웨어 추상화 기능을 제공해, OEM들이 자신의 하드웨어에 맞는 드라이버나 하드웨어 등을 직접 추가해 커스텀한 MS-DOS를 소비자에게 제공할 수 있도록 했다. 8086 호환 PC라면 MS-DOS용 응용프로그램을 모두 구동할 수 있도록 한 것이다. 그럼에도 불구하고 기존의 다른 PC 아키텍처는 모두 IBM PC 아키텍처에 잠식당해 사라지고 IBM PC가 사실상 업계의 표준으로 자리잡았는데, 다름이 아니라 게임 등 고성능을 요구하는 프로그램들은 (당시 하드웨어 성능의 한계로) 하드웨어 추상화를 적용할 경우 지나치게 느려졌기 때문에 단일 PC 아키텍처 전용으로 제작되는 경우가 잦았기 때문이다. 이러한 상황에서 IBM이 자사의 PC 아키텍처를 누구나 사용할 수 있도록 개방하면서, PC OEM들과 소프트웨어 개발자들 모두 IBM PC에 맞추어 PC와 소프트웨어를 각각 개발하기 시작했다. 따라서, 얼마 지나지 않아 "PC"라 하면 인텔의 8086 호환 칩과 MS-DOS를 탑재한 IBM 아키텍처 호환 PC를 가리키는 말이 되어버린 것이다. 현재 x86 프로세서를 탑재한 모든 PC는 IBM 호환 PC이다.

물론 빌 게이츠에게 뒤통수를 세게 얻어맞은 애플과 스티브 잡스도 가만히 있지는 않았다. 이들은 기존의 애플2 라인업을 재정비함과 동시에, 새로운 PC 모델들을 개발하기 시작했다. 애플2 이후의 시도들인 애플3와 리사는 값비싼 가격과 낮은 성능, 떨어지는 시스템 안정성 덕에 처참히 실패했고, 스티브 잡스는 이를 만회하기 위해 1984년 처음부터 (워즈니악이 아닌) 자신이 개발을 지휘한 최초의 PC인 매킨토시를 내놓는다. 본래 매킨토시 프로젝트는 저가형 PC를 개발하기 위한 프로젝트였으나, 잡스가 프로젝트의 통제권을 잡은 이후 애플의 넥스트 플래그십 PC 모델로 자리잡게 된다 (GUI를 최초로 대중화). 이것이 현재까지 이어져 내려오는 Mac 브랜드의 시작이다.

최초의 매킨토시(128K)를 발표하는 스티브 잡스, 1984년.

매킨토시의 마우스와 GUI를 보고 자극을 받은 빌 게이츠는 재빠르게 자체 GUI 인터페이스 개발에 착수하고, 그 결과물이 바로 1985년 출시된 Windows이다. Windows는 (OS까지 한 패키지로 묶여있어 OS에 특별한 이름조차 없던 매킨토시와는 달리) 본래 MS-DOS 위에서 구동되는 프로그램으로 출발했다. 따라서 GUI를 사용하기 위해 완전히 새로운 PC를 구입해야만 했던 애플 진영과는 달리, 이미 널려있는 IBM 호환 PC에서 프로그램 하나만 추가로 구입하면 곧바로 GUI를 사용할 수 있게 해 준 것이다.

최초의 Windows인 1.0은 전반적인 UX가 처참했던 탓에 그리 좋은 평가를 받지 못했지만, 80286/80386에서 도입된 보호 모드를 지원하기 시작한 Windows 3.0부터는 (특히 OEM PC들에 선탑재되어) 미친 듯이 팔리기 시작해 90년대에 들어서 사실상 PC 시장 전체를 독점하기에 이른다. Windows 전용으로 제작된 GUI 프로그램들이 MS-DOS 위에서 곧바로 구동되는 프로그램들보다 더 안정적으로 구동되기 시작한 것도 이때부터다 (DOS 프로그램과는 달리 Windows API의 메모리 보호가 적용되므로). 아예 MS-DOS 시스템 전체를 컴포넌트로서 내장하고 하나의 "OS"로서 출시된 최초의 Windows인 Windows 95가 출시되자 마이크로소프트는 단독으로 PC 시장 전체를 좌지우지할 정도의 영향력을 가지게 되었다.

Windows 3.1 - 기나긴 Microsoft 독재의 시작

반면 애플은 그 동안 뭘 했냐? 스티브 잡스를 쫓아내고 기존 매킨토시 고객층(주로 예술, 출판, 그래픽 등 직군이나 애플 팬층)에게서 어떻게 하면 최대한의 수요를 뽑아낼지에만 골몰하고 있었다. 기술 측면에서의 개선은 사실상 거의 없는 수준이었다. 예를 들어, Windows 95가 이미 32비트 프로그램들에 한해 preemptive multitasking (OS가 자원을 "선점"한 순으로 자동으로 멀티태스킹을 관리해주는 것. 현대 OS에서 사용되는 방식의 멀티태스킹) 을 지원할 동안 Classic Mac OS (1984년 오리지널 매킨토시의 OS에 기반을 둔 Mac OS. Mac OS 9 이하 버전) 는 단 한 번도 온전한 preemptive multitasking을 지원한 적이 없었다. 대신 (Windows 3.1 이하 버전의 16비트 프로그램에서 사용되던) cooperative multitasking, 즉 응용 프로그램이 명시적으로 자원을 할당 해제하고 OS로 돌려주어야만 멀티태스킹이 가능한 방식을 사용했는데, 이것과 제대로 된 메모리 보호조차 갖추어지지 않았다는 것까지 합쳐져... 한 프로그램이 hang/resource deadlock 등의 이유로 제대로 메모리나 프로세서 우선순위 할당 해제를 해주지 못했다면, 다른 모든 프로그램이 전혀 실행될 수 없어 시스템 전체가 뻗어버리는 (...) 일이 부지기수였다. 그나마 cooperative multitasking은 1991년의 System 7 이전까지 MultiFinder라는 매우 걸리적거리는 "선택 확장프로그램"으로 남아있었으며 그 이전까지는 한 번에 단 하나의 응용프로그램만 실행할 수 있었다. 이런 상황인데 훨씬 뛰어난 윈도우 머신을 사용하지 않고 매킨토시를 고집하던 사람들이야말로 진정한 골수 애플 팬이라 불러줄 만하다.

1984년의 오리지널 매킨토시 시스템. 그 당시의 엔지니어들은 128K의 RAM 용량을 가진 오리지널 매킨토시용으로 고안된 운영 체제가 무려 15년이 넘는 세월 동안 별 변화 없이 유지되리라고 상상이나 했을지 모르겠다. (...)

참고로, Classic Mac OS에서의 온전한 preemptive multitasking은 결국 영원히 구현되지 못했다. Mac OS 9에 제한적인 preemptive multitasking이 추가되기는 했지만 단순 API 수준이었고, Mac OS X Leopard 이전까지의 Classic Mode (Classic Mac OS 호환 모드) 또한 Windows 95처럼 Classic Mac OS 프로그램에 대해서만 제한적인 cooperative multitasking을 사용했다. 대신 메인 Mac OS X 시스템과는 격리되어 있었기 때문에, 한 응용프로그램이 뻗으면 Classic Environment만 정지되었고 나머지 시스템에는 영향을 미치지 않았다는 점을 다행으로 생각해야 할 지경이었으니 말 다 했다.

레거시 문제의 등장: 어떻게 Next Level로 나아갈 것인가

마이크로소프트가 Windows 3.x과 Windows 9x 시리즈의 연다른 성공으로 사실상 PC 시장 전체를 독점하고, 애플이 답 없는 삽질만 반복하며 끝없이 추락하는 동안 이 두 회사에게는 공통된 고민이 하나 있었다. 바로 기술 레거시였다.

먼저, 마이크로소프트의 경우 어마어마한 시장 점유율을 MS-DOS라는 하나의 운영 체제에 사실상 전적으로 의존하고 있는 실정이었다. 물론 회사가 급격히 성장하며 크게 개선되기는 했으나, MS-DOS는 본래 IBM의 납품 기한을 맞추기 위해서 마감 3개월 전 급히  "사 온" 물건이었다는 점을 다시 상기해보자. MS-DOS는 당시의 기준으로 절대 뒤떨어지는 OS는 아니었으나, 이미 메인프레임 시스템에서 오랜 시간 검증된 유닉스나 POSIX 기반 OS는 언젠가 DOS 기반 운영 체제(Windows 포함)의 직위를 위협하게 될 것이 너무도 뻔한 상황이었다. 유닉스는 이미 다중 사용자와 고급 네트워킹, 검증된 멀티태스킹과 메모리 관리, 체계적인 권한 모델을 통한 보안, 시스템 안정성 등의 월등한 이점을 갖고 있었고 MS-DOS보다 훨씬 앞선 기술을 품고 있는 운영 체제였다. 이뿐만이 아니라, 당시로서는 CISC 아키텍처인 x86보다 RISC 아키텍처 기반 프로세서들이 대세가 될 것으로 생각되었기 때문에 (물론 레거시 문제로 인해 우리는 아직까지도 x86 프로세서를 사용하고 있다) OS가 ISA에 상관없이 범용으로 쉽게 포팅될 수 있도록 구성하는 것이 필요했다. 유닉스는 이러한 면에서도 상당한 이점을 가지고 있었다.

따라서, 빌 게이츠는 "유닉스 킬러"의 필요성을 인지하고 IBM과 공동 개발 중이던  OS인 OS/2 기반의 새로운 운영 체제 개발에 착수했다. 이 OS는 유닉스의 API 표준인 POSIX와 호환되어야 했고, ISA 독립성을 갖추어야 했으며, 유닉스 같은 체계적인 권한모델과 다중 사용자, 멀티태스킹, 그리고 네트워킹 기능 등을 갖추어야 했다. 해당 기능들은 IBM과의 파트너십 아래 OS/2 브랜딩 하에서 구현되고 있었으나, IBM 측은 마이크로소프트가 Windows 3.x 시리즈를 통해 계속해서 자체 플랫폼을 구축하는 것을 원하지 않고 있었다. IBM은 마이크로소프트가 전적으로 OS/2의 개발에 매진하길 바랐으나, 정작 마이크로소프트는 그럴 생각이 없었다 (왜 굳이 남 좋은 일을 하겠는가?). 이뿐만이 아니라, OS/2로 인해 Windows 플랫폼의 미래가 불확실해지면서 소비자들까지 혼란스러워하기 시작했다. 현재 사용할 Windows 3.x 기반 PC를 구매해야 할지, 혹은 미래를 위해 OS/2 플랫폼을 수용해야 할지조차 알 수 없는 상황이었던 것이다. 거기다 두 OS는 내부적으로는 많이 닮았지만, API 단에서 호환되지 않았기 때문에 OS/2가 주류가 된다면 사실상 Windows는 버려진 플랫폼이 되는 것이나 다름없었다. Windows용 응용 프로그램을 더 이상 사용할 수 없게 된다는 의미이다.

따라서 마이크로소프트는 IBM과의 OS 공동개발 계약을 파기하고, 그 동안 개발한 부분들을 완전히 새로운 프로젝트로 편입시키기로 결정하기에 이른다. 다만, 마이크로소프트는 OS/2와는 달리 기존 Windows 프로그램과의 하위 호환성을 유지하기 위해 API 단을 기존 Windows 3.x에 포함된 Win16 API의 32비트 확장인 Win32로 유지하기로 결정한다. 당시로서는 매우 합리적인 선택이었겠지만, 이는 현재까지도 Windows 플랫폼의 발목을 잡는 중대한 요인 중 하나가 되었다.

이렇게 개발된 마이크로소프트의 새로운 OS가 바로 1991년 출시된 Windows NT다. Windows NT는사실상 완전히 새롭게 작성된 현대적 커널 위에, 다수의 API 레이어를 지원하는 서브시스템을 지원하는 방식으로 설계되었다. 문제는 사실상 다른 서브시스템조차 거의 항상 Win32 서브시스템을 참조하도록 설계되었다는 점이다 (POSIX 서브시스템 포함). 이는 기존 Windows 응용 프로그램과의 하위호환을 위한 조치였으나, 마찬가지로 이 때의 선택이 현재까지 Windows 플랫폼을 괴롭히고 있는 중이다.

Windows NT는 본래 서버 및 워크스테이션용으로 개발된 OS이지만, Windows 2000 이후 모든 Windows 버전은 이 Windows NT 커널을 기반으로 개발되어 있다.

최초의 Windows NT 릴리즈인 Windows NT 3.1의 아키텍처 다이어그램. 사실상 거의 모든 서브시스템이 Win32 (Windows API) 서브시스템을 참조하고 있다. Win32 API를 제외한 다른 모든 서브시스템들은 얼마 지나지 않아 모두 제거된다.

마이크로소프트가 Windows NT로 MS-DOS의 레거시에서 벗어날 준비를 하고 있는 동안, 애플은 여전히 삽질을 지속하고 있었다. 현대적인 OS 기반을 갖춘 마이크로소프트와는 달리, 애플의 Mac OS는 여전히 매우 불안정할 뿐더러 90년대에 와서도 기본적인 메모리 보호나 멀티태스킹조차 제대로 지원하지 못하고 있었기 때문이다. Mac OS는 본래 싱글 유저/싱글 쓰레딩 구조를 가정하고 설계되었기 때문에, 이 구조에 멀티태스킹을 추가하기 위해서는 사실상 거의 모든 코드를 재작성해야만 했다. 문제는 이렇게 될 경우 기존 매킨토시 하드웨어에서 도저히 사용할 수 없을 정도로 OS가 느려질 것이라는 점이었다. 레거시로 인해 플랫폼 전체가 망할 상황에 처한 것이다.

예컨대, 클래식 Mac OS에서 그래픽을 담당하는 QuickDraw의 경우 재진입성 (reentrancy)의 개념을 고려하지 않아도 되었다 (멀티태스킹을 고려하지 않았으므로). 따라서 프로그램의 state가 변화하더라도 내부적으로 state 전환들을 관리해도 무방하다. 심지어 QuickDraw 서비스가 아닌, 각 프로그램이 독자적으로 state를 내부적으로 관리해도 된다. 문제는 이렇게 될 경우, 멀티태스킹 구현 시 OS 스케줄러에 의해 실행이 중간에 중단될 시 그 사이 state의 변화를 별도로 기록해줄 수 없다. 따라서 QuickDraw 서비스가 같이 중단될 것이고, 해당 서비스가 자원을 명시적으로 반환하도록 설계되지 않았기 때문에 시스템 전체가 자원 관리 실패로 같이 중단된다. 이러한 일을 방지하기 위해서는 이런 식으로 구성된 모든 OS 컴포넌트를 다시 작성해야만 했으나, 그렇게 된다면 상기와 같이 single-threaded 가정으로 인해 얻은 성능을 포기해야만 하므로 기존 매킨토시 하드웨어를 사용하지 못할 것을 각오해야만 했다.

따라서 애플은 "블루 박스"라는 컨테이너에 재진입성이 고려되지 않은 기존 매킨토시 프로그램들을 몰아넣고, 그 외부의 요소들을 새로운 마이크로커널과 멀티태스킹 모델 위에서 구현하고자 했다. 사실상 Windows NT의 모델을 그대로 따라간 것인데, 이 프로젝트의 이름은 프로젝트 코플랜드(Copland)다. 다만 코플랜드는 상술했듯 멀티태스킹 도입으로 인한 성능 제약 문제를 도저히 풀어내지 못했고, 결국 1996년 개발 중단을 선언한다. 대신 코플랜드를 위해 개발된 요소들은 이후 기존 Classic Mac OS 아키텍처 상의 Mac OS 8과 9에 점진적으로 포팅되었다.

이렇게 되자 애플은 매킨토시 플랫폼을 살리기 위해 외부에서 OS를 구입해야만 하는 상황에 놓이게 되었다. Sun 마이크로시스템즈의 Solaris, Be의 Be OS, 심지어 마이크로소프트의 Windows NT(...)까지 고려했었으나 당시 애플의 CEO였던 길 아멜리오는 전혀 뜻밖의 결정을 내린다. 마찬가지로 거의 망하기 일보직전이던 스티브 잡스의 두 번째 기업, NeXT를 인수하기로 한 것이다. 당시로서는 다소 황당한 결정이었으나, 결과론적으로만 보았을 때 이는 신의 한 수가 되었다. 왜 그랬는지 좀 더 살펴보자.

(분량 조절 실패로 인해(...) 2편으로 이어집니다)