#데브옵스 | Explore Tumblr posts and blogs

pignose-barn · 6 years ago

Text

다가오는 추상화의 위기 (The Looming Abstraction Crisis) 번역글

이 글은 operator++ 블로그의 The Looming Abstraction Crisis 아티클을 번역하였습니다. 역자 업데이트: 원문 블로그 링크가 깨져있습니다. 블로그 메인 링크도 접속이 안되는 것으로 미루어보아 블로그를 이전했거나 내렸을 가능성이 있습니다. 추후 원문 링크를 발견하면 업데이트 해두겠습니다.

역자의 말

번역되는 단어 중에 Higher-level language는 고수준 언어와 고급 언어 둘중 고민을 했으나 의미상 오해의 소지가 있더라도 많이 쓰이는 고급 언어로 표현하였습니다. (뭐 오해하면 양쪽 단어 다 오해할 가능성이 있다고 판단하였습니다.)

아티클 본문

예전에, 그 때의 그 날로 되돌아가보자면 — `프로그래밍 언어` 라는 것이 존재하지 않았습니다. 당시 프로그래밍은 하드웨어 위에서 조작해야 했던 때였습니다. xkcd 유머 (역자: xkcd는 미국 랜들 먼로가 NASA를 그만두고 그린 웹툰입니다, 공대생 만화라고 보시면 됩니다)에서 다루는 `A Magnetised Needle and a Steady Hand`는 그다지 과장된 얘기도 아니었다고 할 수 있겠네요, 하드 디스크가 여전히 비실용적인 것 빼고는요. 그 당시 천공카드 (Punch Card)는 흔한 입력매체였습니다.

<그 당시에는 컴퓨에 무언가를 입력할 때 카드에 구멍을 뚫어서 사용하는 천공카드가 있었습니다.>

(천공카드도 없었을 시절에는 컴퓨터에게 명령을 내리려면 하드웨어 레벨에서 조작 따위를 했어야 했습니다. 심지어 플러그보드를 사용했던 세대보다 더 예전으로 거슬러 올라가면 우리가 다루고 있는 것이 컴퓨터라는 것을 알고있음에도, 무엇을 다루고 있는지조차 정확하지 않을 수준까지 갑니다.)

물론 이런 종류의 프로그래밍은 굉장히 어려웠고 지루했으며 오류도 자주 발생했습니다. 텍스트 기반 어셈블러는 천공카드 시대에서도 존재해 왔기에 적어도 프로그래머들에게 읽을 수 있는 무언가가 있긴 했었죠—제 말은 읽을 수 있던(아마도 사람이 이해할 수 있는...) 최소한의 뭔가를 제공하긴 했었다는 것이죠. 그렇다곤 해도 개발 환경은 여전히 하드웨어와 1:1 대응이 필요했습니다. 그 당시 진정한 혁명이라 할 수 있는 1957년 포트란(Fortran), 1958년 알골(ALGOL), 1964년 베이직(BASIC), 1968년 파스칼(Pascal)이 등장했었고, 마침내 1972년에 C라고 불리는 언어가 등장했습니다. 마지막으로 등장했던 C는 정말... 진정한 혁명이었습니다.

C는 최초의 고급 언어(Higher-level language)까지는 아니었지만, 오늘날 사용하는 3세대 언어 중에는 거의 유일한 언어라고 볼 수 있습니다. C가 성공할 수 있었던 비밀은 어셈블리 언어로 작업되었던 운영체제를 대체할 수 있도록 디자인 되었기 때문입니다. 그렇기 때문에 몇가지 안되는 기본 구조로 어느정도 ��은 수준의 하드웨어 인터페이스를 구성할 수 있도록(어셈블리 코드로 쉽게 변경할 수 있는 구조) 제공되었으며 복잡한 구성을 추상화 할 수 있는 기능또한 제공되었습니다. 제가 숫자에 대해서 자세히 알지 못하고 또 그것을 추정하는 방법도 잘 모르지만, 오늘날에 돌아가는 99.999%의 대부분 코드들이 첫번째로 C, 두번째로는 C로부터 파생된 언어들 (예를들어 C++) 세번째로 그렇게 파생되었던 언어들로 부터 탄생한 가상머신(VM)에서 돌아가는 언어들로 구성되어있다고 생각합니다.

C는 훌륭한 언어임에는 틀림없지만 결국에는 어렵고 지루하며 자주 에러를 발생시킨다고 여겨지게 되었습니다. 그리고 또 누군가 그 위에 추상화 계층을 얹기 시작하였습니다. 그렇게 1985년에 C++이 등장하게 됩니다. C++은 이런 배경에서 탄생한 언어 중에서는 선두이고 어쩌면 가장 단순한 언어일 것입니다. C++은 프로그래머에게 객체지향 구문을 제공하는 C언어의 파생 언어입니다. [Update: 일부 사람들은 이 주장에 대해 여전히 논쟁을 하고 있지만, 중요한건 적어도 이 언어가 그렇게 시작되었다는 것입니다.] C++은 C 언어가 하는 것처럼 동일한 기계어로 컴파일을 할 수 있고(적어도 이론상으로는) 상당히 엄격하게 C로도 컴파일 할 수 있습니다. 실제로 초기 C++ 컴파일러는 이렇게 동작되었습니다. 물론 지금의 C++은 더 이상 이러한 방식으로 동작하는 유일한 언어는 아닙니다. 소위 `시스템 프로그래밍 언어`라고 불리는 고급 언어(C보다 더 고 수준의 언어)의 범주에 속하는 언어들은 최근 C++ 표준의 막장 행보로 인해 과도기를 경험했었고 그로인해 사람들은 결국 이런 계열의 언어 또한 어렵고 지루하게 느끼기 시작했습니다.

성능이 중요한 응용 프로그램 (정확하게 말하자면 성능이 불충분한 장비에서 돌아가는 것들이요—사람들이 체감하거나 말거나 성능은 항상 중요합니다)에서 C++은 이런 환경에서 최고존엄처럼 사용됩니다. 오늘날, 어쩌면 현시대에서 최고라 불릴 수 있는 대체 시스템 언어 러스트(Rust)도 있다고는 하지만 그렇다고 C++이 어디론가 사라지거나 하는건 아닙니다. (적어도 Rust가 C++ 호환 기능보다 좋은 무언가를 제공할 때 까지는 C++은 남아있을 것입니다. 그리고 C++이 다른 언어에 대체된다고 해도, 그 대체 과정은 상당히 천천히 이루어질 것이고 대체되었다고 해도 절대 C++이 사라지거나 하진 않을 것입니다.) 대부분의 사용자 프로그램은 (게임을 제외하고, 아니, 심지어 게임마저도...) 장비가 매우 빨라 성능이 거의 고려되진 않습니다. 모바일 앱 개발 방식은 마케팅과 나태함을 바탕으로 하고 있으며 최근 가시적인 성능의 변화들은 시장성 갖는다고 보기가 어렵습니다.

결과적으로 가상머신(VM)에서 돌아가는 추상화된 언어들이 폭발적으로 늘어나고있고 (제 개인적인 의견이지만) 또한 동시에, 지속 불가능할 수 없는 수준으로 성장했습니다. 베이직(BASIC)을 이렇게 성장 추세에 있는 언어로 치지 않는다면, 1995년에 자바(JAVA)가 이 계열에서 먼저 시작되었다고 할 수 있습니다. 자바의 개념은 간단하고 훌륭했습니다: 자바가 컴파일 하는 해석문(이 경우 바이트 코드(bytecode))은 OS와 하드웨어의 세부사항을 추상화 하였고 개발자는 모든 고객들에게 결과물인 `바이너리(binary)`를 제공할 수 있었습니다. 운영체제 레벨에서 추상화를 통해 보안이 향상되었지만, 네트워크를 통해 넘어온 신뢰성 없는 코드를 실행할 수 있기 때문에 어쩌면 마냥 좋다고 볼 수는 없었지만요.

물론 단점은 성능이었습니다. 1995년대에 비해서는 지금은 더 나아졌다고는 하지만 그래도 여전히 이클립스(Eclipse)를 여는 것은 그닥 달갑지 않습니다. (자바 기반의 커맨드라인 도구들은 더합니다, JVM의 경우 엄청 느리지는 않지만 시작하기까지 시간과 정신의 방에 갇혀있어야 합니다.)

그렇다고 해서 자바가 C++과 비교했을때 추상화 측면에서 그다지 눈에띄게 좋아진 것도 아닙니다. 물론 여러 플랫폼에 대한 독립성 지원은 훌륭하지만 C++에서도 모던 크로스 플랫폼 라이브러리와 데브옵스(DevOps) 툴을 사용하면 플랫폼 의존성의 (미미한)비용은 거의 제로에 가깝게 변합니다. 그렇다고 자바로 개발하는 것이 쉬운편도 아닙니다. 또 메모리 관리가 훨씬 자동적인 것도 아닙니다 (자바에 동적으로 증가하는 배열은 어디에 있나요?) 타이핑은 C보다 강력하다 할 수 있습니다. (자바에서 클래스를 자체적으로 캐스팅하려고 할 때 오류를 받아볼 수 있습니다!). 여전히 자바는 거지같은 null 포인터(네! C에서 개발자 모두가 고통 받는 그것이요!)를 가지고 있습니다. 앞서 말했듯이 보안은 거진 20년동안 유닉스에 있었던 것에 비하면 들어보지도 못했던 `바이트 코드`를 제공하기 때문에 나아졌다 할 수는 있겠지만 여전히 소름돋도록 비효율적입니다. (즉, 네트워크 전반에 신뢰할 수 없고, 유효성이 보장되지도 않으며 또 그 네트워크 전체에서 보이지 않는 경우도 자주 있습니다.)

자바 쇠퇴하고 나서, 그 결과가 오래동안 쌓아온 네이티브 표준으로 돌아가는 것이 아니었습니다. 되려 더 높은 고급 언어로 몰리기 시작했습니다. 자바와 관련이 없는 자바스크립트(Javascript)가 1995년에 공개된거죠. 하지만 자바스크립트는 애플이 플래시를 아이폰에 넣지 않기로 결정하기 전까지, 거진 10년 반 동안 별 다른 성과없이 지진부진하였습니다. 자바스크립트가 ��을 보지 못한 그 동안 이른바 `Web 2.0`이라고 부르는 플러그인을 대체하는 표준 등이 개발에 제동을 걸었습니다. 모던 웹앱은 어떠한 의미로는 자바의 문제들을 막았습니다. 완전한 크로스 플랫폼을 지원했고, 쉽게 배포가 가능했으며 사용자의 시스템에 접근을 어느정도 막을 수 있었습니다. 설령 사용자가 접근을 원한다고 하더라도 말이죠. 최종적으로 이런 방식이 개발을 쉽게해주었습니다. 자바스크립트를 언어 관점에서 보자면 실수가 발생하기 쉬운 언어입니다. (물론 실수가 발생하지 않는 것보다 올바르게 작성하는 것이 더 어렵지만, 이제 사람들은 올바른지는 여부는 신경 쓰지도 않습니다) `진정한 프로그래밍`과는 별도로 마크업 언어로 UI를 디자인 (특히 테마를 지정)하는 것이 실질적인 이점이라 볼 수 있는 언어입니다.

지금에서는 웹앱이 크롬 OS(Chrome OS)와 일렉트론(Electron)이라는 산물을 남겼습니다. 또한 자바스크립트는 노드(Node.js)를 통해 서버 프로그래밍에서도 사용할 수 있게 되었고요. 이것이 오늘날의 모던 웹의 방향입니다. 우리가 좋아하건 아니건 말입니다(그리고 좋건 싫건 논쟁이 있고요). 그렇다고해서 비판을하지 말자는 것은 아닙니다: 생각해봅시다 여러분이 브라우저만 돌아가도록 만든 상용 운영체제를 가지고 있다고 가정할 때, 과연 가벼운 운영체제를 사용하고 있다고 생각하나요? 아니면 말 그대로 미쳐날뛰는 브라우저를 가지고 있다고 생각하나요?

<데스크탑 환경의 어플리케이션도 웹 프론트엔드 개발자들이 진입할 수 있게 해준 일렉트론>

크롬(Chrome)을 운영체제(OS)라고 부르는 것도 과장이 아닙니다. 코드 라인으로 보면 크롬은 리눅스 커널과 거의 동급의 크기를 자랑합니다. 마치 리눅스 커널처럼 OpenGL, VR, MIDI와 같은 모든 종류의 하드웨어를 위한 API를 가지고 있습니다. 또한 SQLite 임베디드 copy, 메모리 관리, 자체적인 테스크 매니저와 같은기능을 탑재하고 있습니다. macOS 버전에서는 심지어 Xbox 360 컨트롤러용 사용자 영역의 USB 드라이버가 포함되어 있습니다. (제가 작성했었기 때문에 그게 거기 있는 걸 알아요. 미안해요.) 슬랙(Slack)에는 제가 작성한 Xbox 컨트롤러를 위한 코드들이 포함되어 있나요? 슬랙 팀은 혹시 알고 있나요? 혹시 아시는 분 있나요?

어쩌면 크롬은 대부분의 리눅스 배포판보다 우수한 운영체제라고 부를 수 있을 겁니다—적어도 개발자들은 그렇게 부를 겁니다. 크롬은 대부분의 운영체제 API를 유난히 짜증스럽게 만드는 특유의 레거시의 산물이나 특징이 전혀 없습니다. 더군다나 이러한 API들은 표준을 기반으로 하고 있었기에 개발자들로 하여금 부수적인 추가 작업 없이도 사용자는 자유롭게 여러 브라우저를 선택할 수 있습니다. 사용자 어플리케이션을 위한 개발 플랫폼으로서 웹은 최고의 선택이 될 수 있습니다. 물론 많은 사람들이 웹으로 넘어가고 있는 이유이기도 하고요.

문제는 모든 것이 자바스크립트에서 동작하고 보이는 것입니다. 고작 10일만에 설계된 언어에서요. 이렇게 짧은 시간에 설계되었다고 해서 자바스크립트로 좋은 코드를 작성하는 것은 쉬운일이 아닙니다. 엄밀하게 말하자면 수용가능한(acceptable) 자바스크립트 코드를 작성하는 것은 쉽기 때문에, 좋은 코드 작성이 어렵게 된 것이지요 (역자: 에러가 안나는(수용가능한) 코드는 작성하기 쉬운데, 에러가 안난다고 좋은 코드는 아니기 때문에 어렵다고 하고있습니다). 인터프리터 관점에서는 수용가능한 문법(acceptable )은 수용가능한 것이 아닙니다. 자바스크립트를 단지 1할만 알더라도 어느정도 돌아가는 코드를 작성할 수 있습니다. (그리고 여러분이 만약 제대로 된 1할을 배웠다면 더 좋은 코드를 작성하겠죠) 하지만 인터프리터는 잘 작성된 코드와 안 좋은 코드, 심지어 망가진 코드도 다룰 수 있어야 합니다. 때로는 처절하리 만큼 망가진 코드가 들어와도 말입니다. 이것들이 의미하는 바는 (a) 추상화의 비용은 기하급수적으로 늘어나고 있고, (b) 이런 비용을 줄이는 것은 정말로 큰 과제가 되었다는 것입니다.

<같은 V8이라도 그 구조의 복잡성은 너무나도 다를 것입니다 - 그림 출처 위키피디아>

앞서 말씀드린 문제들을 해결하지 못한 것은 아닙니다. 오늘날에 가장 유명한, 어쩌면 가장 빠른 자바스크립트 엔진은 구글의 V8입니다. V8 엔진은 크롬에서도 사용되고 있습니다(아시다시피 노드와 일렉트론도 이 엔진을 기반으로 합니다). 이 엔진 이름은 의심의 여지도 없이 고성능 자동차 엔진을 연상시키지만, 만약 V8이 진짜 자동차 엔진이라고 불리기 의도했었다면, 아이러니하게도 절대로 V8이 될 수 없을 겁니다. (역자: 이 엔진이 자동차 엔진 V8로 비유하기에는 너무.. 너무 무거워졌다는 의미를 내포합니다) 만약 당신이 중요하게 보는 것이 복잡성과 유지 보수 비용이라면 부가티 베이론(Bugatti Veyron)의 엔진인 `W16`이 될순 있을 듯 합니다. 이 엔진은 16기통 엔진에 4개의 터보 차저를 가지고 있어 마치 대형 트럭에 들어가는 엔진처럼 오일 교환 비용이 21,000 달러에 육박합니다. 아마도 구글 V8 엔진을 사용하는 것은 170만 달러짜리 슈퍼카로 심부름을 하는 것과 완전히 똑같지는 않겠지만 연비(혹은 메모리 사용율)가 굉장히 나쁜 차량을 몰고 있는 것과는 같습니다. 적어도 이 경우에 누군가 기름을 교체하고 있습니다 (역자: 메모리, CPU 성능은 계속 향상되고 있다는 의미입니다).

하지만 기름 (그리고 부가티)가 무료로 제공된다면 어떨까요, 우리는 매일 부가티를 몰고 기름을 사용하겠죠. 이 상황이 일반적인 무어의 법칙의 상황이라 볼 수 있습니다. 성능이나 자원 상태가 10% 가량 향상되더라도(대규모 프로젝트에서는 별반 차이가 없습니다) 3개월 뒤에는 거의 사용하지 않아 시장에서 버려집니다. 따라서 건전한 비즈니스 결정에서는 최적화를 포기하고 여러분의 소프트웨어 스택에 그냥 쓰레기를 계속 쌓아올리게 됩니다. 무어의 법칙은 아래의 그래프에서 보이는 것(리눅스 커널의 코드 라인)으로부터 우리를 지켜내 주었습니다.

youtube

코드 양이 지금도 폭발적으로 증가하고 있지만 우리가 사용하고 있는 프로세서의 속도가 훨씬 빠른 속도로 증가하고 있기 때문에 코드 양의 증가는 더 이상 중요하지 않게 되었습니다. 그렇다곤 하지만 무어의 법칙은 영원히 유지될 수 없고, 이젠 더 이상 그런 것은 변명거리조차 되지 못합니다. 양자제한 효과로 인하여 트랜지스터 사이즈의 한계는 이미 우리 코 앞으로 들이닥쳤습니다. 그렇기에 앞으로 더 빠르고 좋은 프로세서를 만들기 위해서는 새로운 기술이 필요한 상태이며, 프로세서의 처리능력(적어도 가격 대비)은 상당히 오랜기간 정체된 상태로 있게 될 것입니다—적어도 무어의 법칙이 통했던 시대에 비하면 말입니다. 지금 이 순간 프로세서 사양이 정체로 다가오게 된다면(2021년 쯤으로 예상합니다) 폭발적이었던 코드 양의 증가가 점점 그에맞는 사양이 따라오지 못해 위험해지는 시기가 올 것입니다. 또한 무어의 법칙은 컴퓨터를 더 빠르게 그리고 저렴하게 만들 수 있었습니다. 예전에는 PC도 가질 수 없었던 사람들이 지금에 와서는 최소한 스마트 폰은 가지고 있으며 사용하고 디바이스도 굉장히 다양해졌습니다. 이러한 두가지의 변화들에 의해 앞으로는 서서히 다가오는 위기를 맞이하게 될 것입니다. 따라서 `계획적구식화(planned obsolescence)` (역자: 새 제품이 나올 때 쯤에 이전 시리즈의 제품에 고의적으로 성능을 느리게 만들거나 구식이라는 이미지를 심어주어 대체 수요를 늘리는 등의 정책을 말합니다)는 곧 붕괴하고 불타오를 것입니다. 그렇게 추상화의 위기가 찾아오고 모든 것이 붕괴한다면 당신은 어디에 있으실건가요?

당신이 �� 개발자라고 한다면 달리말해 준비되지 않았다고 할 수 있습니다. 그 이유는 오늘날의 웹 개발 트랜드는 간단한 코드나 더 적은 추상화 레이어로 흘러가고 있지 않기 때문입니다. 물론 여기에도 몇가지 재밌는 예외사항이 있긴 합니다. 이에반해 대부분의 웹 응용 프로그램은 더 많은 추상 레이어를 덧대고 복잡해져 거대한 프레임워크로 구축되고 그렇게 덧대진 웹 응용 프로그램은 여러분의 4개의 터보 차저를 가진 W16 위에(역자: 아까 언급한 크롬을 말한겁니다) 올라가게 됩니다. 사람들은 30분 안에 앱을 만들 수 있기를 원하고 프레임워크를 사용하면 실제로 그렇게 할 수도 있습니다. 하지만 말입니다 따라오는 성능 단점들은 제외한다 치더라도 이게 정말 올바른 소프트웨어 개발이라고 불릴 수 있을까요?

물론 웹 프레임워크 비유가 그렇게 많은 성능에 있어 단점을 가져오지는 않습니다. 웹에서 코드를 실행하고자 한다면 코드를 그때그때 다운로드 해야 하기 때문에 심지어는 CPU 사용률도 이제 더 이상 (커다란) 문제는 아니게 되었습니다. 리액트(React) 앱은 개발자가 코딩을 시작하기도 전에 무려 79,905라인의 자바스트립트 코드를 필요로합니다. 좋습니다. 아무래도 리액트는 공평하지 않은 예시일 수 있습니다—페이스북 제품이니깐요. 페이스북은 앞서언급한 것과 유사한 문제들을 가지고있기로 알려져 있습니다. 그렇다곤 해도 리액트는 굉장히 유명합니다, 그 말은 즉슨 로드 될 때마다 80,000 라인의 코드를 다운로드하는 수 많은 리액트 네이티브 베이스 앱들이 지천에 널려있습니다. (위에서 언급한 기사에서 말하는 통계를 바탕으로 알 수 있는 충격적인 사실은, iOS 버전의 페이스북 앱이 18,000개의 Objective-C 클래스를 포함하고 있고 이것이 리액트가 동작하는 직접적인 결과를 의미합니다. 특히 리액트 네이티브(React Native)로 알려진이 저품질의 야매 프로젝트에서요. 하지만 이건 원 주제와 관련이 없는 이야기입니다) 다른 프레임워크는 조금 더 나을지도 모르지만 얼마나 더 나을까요? 심지어 제이쿼리(jQuery) 마저도 86 킬로바이트의 크기를 자랑합니다: 최근에는 더 작아졌겠지만 여전히 배보다 배꼽이 큰 경우가 많습니다.

아 그리고 우리가 엄청난 크기의 프레임워크를 논하고 있을 때 그게 엄청난 양의 자바스크립트 코드라는 것을 명심하세요—그 프레임워크는 또 약 백만 라인 가까이 되는 크기의 VM 위에서 실행되고, 또 그건 크기가 무려 수천만 라인에 도달하는 OS가 실행시게 됩니다. 물론 모든 자바스크립트 코드들이 각각 한줄씩 전부 실행되는 것은 아닙니다—어쩌면 수많은 코드들이 전혀 실행되지 않을 수 도 있습니다—하지만 고작 작은 기능을 만드는데 수 많은 코드를 토해냅니다. 80,000 라인의 자바스크립트 코드와 같은 기능을 C로는 몇 줄로 대체 가능할까요? 해답을 듣고 싶으세요? 어쩌면 더 중요한 것은 얼마나 ��은 라인이—아, C 대신 C++ 이라고 가정하고 생각해봅시다—간단한 UI 마크업 언어와 C++ API를 사용하여 어느정도 React.js와 동등한 앱을 만들 수 있을까요? 어쩌면 80,000 라인보다 더 많이 필요할 수도 있습니다—어쩌면요.

(리액트에서 할 수 있는 모든 것들을 소화해낼 수 있는데도 그 단순함은 잘 알려지지 않은 큐티(Qt)는 대략 470,000 라인의 C++ 언어로 구성되어 있습니다—이는 리액트의 80,000 라인보다 6배 가까이 많은 양에 육박하지만 V8 엔진의 크기에 비해서는 1/4 정도의 크기이며 크롬보다는 20배 가까이 작습니다.)

그렇다고 해도 여전히, 주사위는 던져졌습니다. 사람들이 다시 저급언어로 앱 개발을 하면 좋겠지만 그럴 것 같지는 않아보이네요. 대신 어쩌면—아마도 어쩌면— 90년대, 심지어 2010년으로 거슬러 올라가지는 못하더라도 쓸모없는 코드들이 기하급수적으로 늘어나기 직전, 한발짝 물러설 수 있는 방법이 있을 것 같습니다.

우리가 가장 먼저 해야할 것은 웹 프레임워크 문화 최악의 국면을 되돌리는 것입니다. 솔직히 말하면, 앱을 라이브 환경에서 실시간으로 빌드하거나, 심지어 이를 24시간 안에 할 수 있는 능력들은 득보다 실이 많은 쓸데없는 눈속임입니다. 구글 엔지니어는 30분의 대화 속에서도 실제로 전달가능한 제품을 만들 수 있다고 생각할 만큼 어리석지는 않겠지만, 여러 개발자들 속에서 이런 컨셉을 시연해야하는 것은 어쨋거나 나의 책임감을 미치도록 건드립니다. 제 말은, 아 제발요—어디선가 페이스북 직원이 보고있을지도 모른다고요. 거대한 테크 회사들이 그들의 정교한 커스텀 솔루션들을 오픈 소스로 제공하는 것과 그것들을 지루한 대학생들을 상대로 어떤 유행이나 돈 욕심으로 마케팅을 하는건 엄연히 다릅니다. 저는 잘못 만들어진 것들을 누군가 처음부터 다시 만들 수 있다고는 말하지 않을 것입니다. (꼭 그래야 하는 건 아닙니다) 하지만 모든 프로그래머가 그런식으로 생각하게 된다면 세계의 소프트웨어 품질의 평균이 어떻게 변할 것이라고 생각하시나요?

그 다음으로는 OS와 브라우저 벤더사들은 그들의 API를 개선시킬 필요가 있습니다. 예를들어 제이쿼리는 일반��으로 모던 웹 표준입니다.—이런 API는 표준 DOM API와 철처하게 경쟁을 벌여왔습니다. 그리고 그건, 음, 좋진 않아요. 브라우저 제작사들은 (적어도 핵심 부분들은) 분명한 조치를 취하고 제이쿼리를 브라우저 내에 포함시킬 필요가 있습니다, 자바스크립트를 대신하여 자연스럽게 실행시키기 위한 수많은 공통 코드들을 허용하여 말 그대로 수십억개의 페이지 로드에서 페이지 각각 86 킬로바이트를 줄일 수 있습니다. 데스크탑에서 동작하는 서드파티들도 똑같이 적용할 수 있습니다—제이쿼리 처럼 분명한 예시는 없지만 SDL과 같이 예시는 분명히 있습니다. (이건 기본적으로 Boost에 대응되는 C++ 표준화 도구입니다. $(...) 셀렉터는이제 대부분의 브라우저에서 제이쿼리 없이도 사용할 수 있게 되었습니다. 따라서 이것이 시작이라 볼 수 있겠네요.)

세번째로는, 최소한 현재 형태를 유지하며 자바스크립트를 떼어내야 합니다. 대부분의 경우 자바스크립트는 구진 것이 분명하기 때문에 결코 새로운 아이디어가 아니지만, 최근에서야 이를 시작하기 위해 필요한 도구들을 만들었습니다. 웹 어셈블리(WebAssembly) 마침내 네이티브 레벨에서 지원되고 있으며-자바스크립트를 대체할 수 있도록 모든 브라우저 안에서 서포트되고 있습니다—다음 단계는 웹 어셈블리를 기본 대상으로 하도록 옮기는 것이며, 아마도 최종적으로는 유일한 선택이 될 것입니다. 최소한의 사이드 이펙트만으로 이 작업을 하려면 자바스크립트를 웹 어셈블리(WASM)로 컴파일하는 방법이 필요합니다. 결코 쉬운 작업은 아닙니다—아까전의 `W16` 문제로 돌아갑시다. 그럼에도 불구하고, 기존 자바스크립트 엔진은 자바스크립트를 컴파일 하므로 코드를 즉시 실행하는 대신 디스크에 덤프하는 것 (아마도 LLVM 바이트 코드로) 은 그렇게 어렵지 않습니다. 어셈블리 스크립트(AssemblyScript)는 이미 타입스크립트(Typescript)를 (자바스크립트에 동적 타이핑을 추가한 마이크로소프트가 만든 확장형 언어) 웹 어셈블리로 컴파일 할 수 있습니다. 거의 다왔습니다. 하지만 웹 어셈블리는 현재 너무나도 효율적으로 샌드박스화 되어 있기에 웹 어셈블리–자바스크립트 인터페이스는 거의 대부분 재설계되어야 할 것입니다.

마지막으로, 하드웨어와 사용자들이 실제로 소프트웨어를 작성하는 지점 사이의 모든 쓰레기들을 치워야합니다. 게리 베른하르트(Gary Bernhardt)의 유명한 이야기 중 `자바스크립트의 탄생과 죽음` (유머스럽게 `야마스크립트(YavaScript)`라고 발음합니다)는 풍자적으로 커널을 웹 어셈블리 VM으로 대체할 것을 제안했습니다. 실제로 이 아이디어는 시도 되었지만 아마 너무 멀리 갔었던 듯 합니다. 그렇다곤 해도 충분히 현실적인 아이디어로도 사용될 수 있을거라 생각합니다. 개발 윈도우 매니저와 전체 화면 데스크탑 `쉘(shell)`을 보이지 않는 브라우저의 윈도우로 대체하고, 가상 프레임 버퍼(Virtual frame buffers)와 GL 컨텍스트를 레거시 응용 프로그램과 게임에 제공하는 것입니다. 이게 오버헤드처럼 들릴 수도 있겠지만 실제로는 생각보다 더 적은 비용으로 끝나게 됩니다: 당신의 새로운 브라우저는 <iframe>이라고 볼 수 있습니다. 따라서 모든 것이 일렉트론 앱이라고 칭할 수도 있습니다. (실제로, 일렉트론 쉘은 그 자체로 그런 프로젝트의 좋은 출발점이라고 볼 수 있습니다.) 더 이상 각 응용 프로그램마다 별도의 랜더링 툴킷을 실행 시킬 필요가 없게 됩니다. 모든 것은 표준에따라 작성되고 하나의 공용 랜더러에 의해 랜더링 되며 50%의 여러분의 메모리 사용량이 그냥 사라집니다. 공통 표준은 현재 웹에서 사용되고 있는 것들처럼 될 필요조차 없습니다, 물론 웹 표준이 필요한 무수한 이유가 있고 그것이 없어져야할 이유는 극히 적다고 봅니다.

제가 제시한 새로운 세계도 결국 완벽하진 않습니다. 만약 수 많은 C++ 개발자들이 겁에 질리더라도 이해합니다. 지옥, 그것이 저를 두렵게 만듭니다(C/C++ 개발자). 하지만 1972년 핵심 소프트웨어에서 부터 겹겹이 쌓아올린 거대한 양파에서 살고 있는 우리 세계보다는 두렵지는 않습니다. 오늘날 우리가 소프트웨어 스택에 쌓아올린 각각의 연속된 껍데기들은 적색거성과 같이 부풀어 오를 것이고 조만간 초신성이 되어버릴 것입니다. 소프트웨어에서 필요한 것은 개발자가 간단한 API를 사용하여 보안이 허용하는 한 하드웨어에 가깝도록 응용 프로그램을 구성할 수 있는 시스템 수준으로1972년에 있던 것에서 그 이상 이하도 아니거나 더 적을 것입니다. 우리가 가진 문제는 실제로 하드웨어 가까이에서 실행되는 시스템이 1972년 기술로서 구축되었지만 실제로는 그 이후 제대로 다루어지지 않았습니다. 성능을 잡아먹는 추상화 계층 위에 덮히고 또 덮히고 또 덮힌 껍데기—그리고 그 결과들—오직 예측과 예방만이 가능해 왔었습니다. 그리고 이제는 고칠 수 있기를 바랍니다.

#excerpt

3 notes · View notes

kivol-blog · 7 years ago

Text

테크 스타트업의 CTO로 아직 안망하기 - 6. 에필로그

테크 스타트업의 CTO로 아직 안망하기 - 0. 서문 테크 스타트업의 CTO로 아직 안망하기 - 1. 두 번째 팀원 테크 스타트업의 CTO로 아직 안망하기 - 2. 착한 아이 컴플렉스 테크 스타트업의 CTO로 아직 안망하기 - 3. 지속가능한 개발팀 테크 스타트업의 CTO로 아직 안망하기 - 4. 성장통 테크 스타트업의 CTO로 아직 안망하기 - 5. 평가의 딜레마 테크 스타트업의 CTO로 아직 안망하기 - 6. 에필로그

0. 이 글을 준비하면서 CTO에 관한 많은 글을 찾아보았는데 공통점이 없던 것은 아니었다. CTO는 결국 '기술'을 책임지는 자리라는 것. 다만 이 시리즈에서는 스타트업의 초기에서부터 지금까지의 성장과정을 이야기하려 했기 때문에, 결국 비기술적인 관리와 '사람'에 대한 이야기가 오히려 더 많을 수밖에 없었던 것 같다. '개발팀의 수장이면서 가장 기술적으로 큰 책임과 권한을 지는 자리'가, 엔지니어링 팀이 15~20명 규모가 될 때까지 내가 생각해온 CTO의 정의였다.

1. 사실 이러한 역할이 지속가능하기 어렵다는 생각은 예전부터 해왔다. 일단 나에게 주어진 할 일이 너무 많다는 것이 문제였고, 나 자신이 딱히 대단히 탁월한 관리자의 자질을 가지고있는 것 같지 않다는 점도 문제였다. (엔지니어링쪽은 그래도 그보다는 좀 낫다고 생각한다.) 어느 순간부터 프로덕트의 지나치게 디테일한 부분에 신경을 덜 쓰기 시작했고, 시니어 엔지니어들에게 해당 부분을 위임할 수 있었다. 그러다 보니 내가 하는 업무 중 관리를 제외한 엔지니어링쪽의 실무가 자연스럽게 한가지로 수렴하고 있는 것이 보였다. 그것은 데브옵스였다.

2. 의외로 상당히 오랜 시간동안 우리 서비스는 모니터링도 페일오버도 오토 스케일링도 제대로 설정되어있지 않았다. 또한 디플로이 역시 서버에 직접 들어가서 git pull을 하고 서버를 다시 띄우는 방식이었다. 이랬던 이유는 결국 그런 프로세스에 신경을 쓸 사람이 CTO 뿐이지만 그 자신이 실무에 너무 매몰되어있었기 때문이었다. 마침 코어 라이브러리에 대한 설계 정리가 끝났고 네트워크와 VPN도 얼추 정리가 된 시점이었고, 나는 그 때 비로소 하나의 파이프라인으로 된 CI 프로세스를 준비하기 시작했다. 리포에 푸시를 하면 빌드서버가 테스트를 거친 뒤 도커 이미지를 생성하고 그것을 즉석 생성된 클라우드 서버에 올리는 방식을 제시했다.

3. 파편화되어 돌아가고 있던 기존 서비스들에 이 프로세스를 공통 적용하는 것은 생각보다 지난한 과정이었다. 기존에 돌아가고 있던, 또 중간에 치고 들어오는 서비스 일정과의 충돌 문제도 있었고 파트너사의 이상한 방화벽이나 네트워크 정책과 같은 문제도 있었다. 레거시의 정리도 필요했다. 서버 인스턴스 한 대만을 쓰던 구조를 도커와 여러 대의 인스턴스를 쓰는 구조로 바꾸기 위해서는 로깅이나 세션처리, 캐싱 등 고려해야 할 점이 의외로 많았다. 결국 모든 것이 끝나기까지는 1년 가까이의 시간이 걸렸고, 이 과정에서 깨달은 것이 하나 있었다.

4. 그것은 프로덕트가 어떻게 분화하고 무엇을 만들게 되든 그 과정에 필요한 공통적인 것들은 결국 CTO가 챙겨야만 한다는 것이었다. 그 공통적인 것이 기술스택일수도, 개발 플로우나 프로세스일수도 있다. 중요한 것은 한 엔지니어링 팀에 그런 시스템을 잡아주는 일이 필요하고 그것을 CTO가 해야 한다는 점이다. 만약 그것을 처음에 알았더라면 훨씬 더 편했을까? 나는 그렇다고 생각한다. 첫 프로덕트가 나오기까지는 약간의 시간이 더 걸렸을지 몰라도 그 시간투자를 회수하는 것은 굉장히 빨랐으리라 생각한다. 물론 그러한 공통적인 시스템을 제대로 만들 역량이 회사 초기의 나에게 있었는지는 의문스럽지만.

5. 이렇게 데브옵스 프로세스를 갖춰놓고 나니 그 다음 스텝이 명확해지기 시작했다. 이러한 시스템에 더해 엔지니어링 조직, 회사 전체가 공통적으로 의존하게 될 기술을 생산할 사람들이 있어야 한다는 생각이 들었다. 이 일을 하는 사람들은 프로덕트에 너무 깊게 발을 담그지 않아야 한다. 이를 위해서는 제품과 독립된 별개의 조직이 필요했다. 나는 경영진 회의에서 연구조직의 설립을 제안했고, 나는 이러한 업무에 전념하기 위해 나머지 프로덕트 엔지니어링 조직을 관리하고 이끌 사람이 필요하다고 이야기했다. 이 제안은 받아들여졌다. 엔지니어링 조직으로서의 우리 회사의 개발팀은 이제 또 다른 진화를 준비하고 있다.

6. 이제 이 글도 결론을 낼 때가 온 것 같다. 나는 CTO가 무엇을 하는 역할이냐 하는 오랜 질문에 대해 이렇게 대답하기로 결심했다: "기술 스택의 큰 줄기를 결정하고, 그것의 Best Practice를 찾아 제시하고, 전체적인 개발 플로우와 프로세스를 정립하고, 최대한 그것을 자동화하여 모두의 시간을 절약할 수 있게 하는 포지션. 그리고 더 나아가 제품과 회사에 도움이 될 수 있는 새로운 기술적 비전을 제시하는 사람"

7. 내가 CTO라는 직함을 달고 있는 동안에는 계속 이러한 역할 하에서 방향을 고민하고자 한다. 이러한 가정 하에서 내가 지난 6년간 잘해왔는지를 생각해 보았으나 너무 부끄러워서 생각하는 것을 이내 그만두었다. 그래도 위안인건 최근으로 올수록 나아지고 있는 것 같기는 하다는 점이다. 그래도 이 정도면 어디가서 CTO로든 엔지니어로든 굶어죽지는 않을 것 같으니 다행이다. 글의 앞부분에서 '어디 가서도 1인분을 하는 개발자'를 키우는 것이 목표였다고 이야기한 적 있는데, 과연 나는 1인분은 하는 CTO일까?

8. 사실 그래도 나름 오랫동안 긴 글을 쓴지라 뭐라도 임팩트 있게 마무리를 하고 싶은데 잘 떠오르지 않는다. 아마 이 문장이 그대로 올라간다면 결국 떠올리지 못한 것으로 하고 이 글을 마칠까 한다. 지금까지 긴 글 읽어주신 모든 분들께 진심으로 깊은 감사를 드립니다. 진짜 진심이에요!

(끝)

PS. 현재 Knowre 개발팀에는 주니어 웹 개발자와 제품 엔지니어링을 총괄 매니징할 디렉터 포지션이 오픈되어 있습니다. 주니어 안드로이드 개발자 포지션은 마감되었고, 다른 포지션들도 마감이 임박해올 수 있으니 혹시 관심있으신 분들께서는 다음의 링크를 참조해 주세요!

제품 엔지니어링 디렉터: https://www.wanted.co.kr/wd/5802 주니어 웹 개발자: https://www.wanted.co.kr/wd/3244

[레퍼런스: 이 글을 쓰기 위해 읽었던 많은 글 중 한국어로 된 일부] http://www.zdnet.co.kr/column/column_view.asp?artice_id=20140630075815 https://www.slideshare.net/lqez/ss-36301654 https://brunch.co.kr/@leehosung/40 https://minorblend.com/cto-vs-vp-engineering-4a36124c098c http://woowabros.github.io/woowabros/2017/05/15/woowa_techcamp.html

4 notes · View notes