24  기술에 베팅하기

지금까지 집중할 분야를 찾고 정하는 방법, 그리고 언제 전문화하고 언제 범용화해야 하는지에 대해 이야기했습니다. 이 두 가지 행동은 모두 암묵적으로 특정 기술에 거는 일을 수반합니다. 이를 위한 다양한 접근 방식에 대해 이야기해 봅시다.

24.1 어떤 것에도 베팅하지 않기

“세상을 혐오스러운 시각으로 바라본다고 해서 당신이 더 우월한 것은 아닙니다.” - 프랑수아르네 드 샤토브리앙

먼저 비관론자들이라는 음울한 망령에 대해 이야기해야 합니다. 하방 위험을 줄이는 훌륭한 방법은 그냥 아무런 위험도 감수하지 않는 것입니다. 이런 말은 냉소적인 개발자들에게서 자주 듣게 됩니다. 이들은 특정 기술이 과대평가되었다는 점에 대해서는 옳은 경우가 많지만, 자신이 얼마나 관심이 없는지를 모두가 확실히 알도록 하는 데에도 무척 열심입니다.

물론 이것은 그다지 좋은 퍼스널 브랜드가 아니지만, 더 중요한 것은 제가 늘 “고장 난 시계도 하루에 두 번은 맞는다”라는 격언을 떠올린다는 점입니다. 그렇습니다, 기술 트렌드는 순환하며 낡은 것이 다시 새것이 되는 경우도 많지만, 기술이 결코 발전하지 않는다는 말은 객관적으로 사실이 아닙니다.

비관론자들은 기술을 끝없이 똑딱거리며 흔들리기만 할 뿐 어디로도 나아가지 않는 진자로 봅니다. 현실은 오히려 산을 오르는 등반가의 여정에 가깝습니다. 굽이굽이 이어지는 지그재그 길에서 왼쪽으로 꺾었다가 오른쪽으로 돌고, 때로는 미끄러지거나 막다른 길에 부딪히기도 하지만, 언제나 위로 오르려고 애씁니다.

Cynics vs Builders

조지 버나드 쇼의 말을 빌려 표현하자면 다음과 같습니다:

냉소적인 개발자는 기술이 결코 변하지 않는다고 생각합니다. 낙관적인 개발자는 기술을 바꾸려는 시도를 끈질기게 이어 갑니다. 그러므로 모든 진보는 낙관적인 개발자에게 달려 있습니다.

기술 선택에서 보수적인 태도를 취하는 것은 누구에게나 주어진 권리입니다. 하지만 결과를 이미 아는 상태에서 판단하는 사람들은 미래를 만들어 가려는 사람들의 노력을 결코 폄하해서는 안 됩니다. 그들이 실제로 노력을 꺾는 데 성공할 수도 있기 때문입니다.

성공이 이미 명백해진 뒤에 그 성공을 소급해서 설명하는 것으로도 우리는 아무것도 배우지 못합니다. 인간은 사후적으로 인과관계를 끼워 맞추는 데 능숙합니다. 지나치게 능숙합니다. 잘못된 교훈을 끌어내고, 기존의 편향을 확인하고, 증거가 없다는 것을 부재의 증거로 받아들이기가 너무나 쉽습니다. 세상의 진정한 근본 규칙을 배우는 과학적 방법은 (사후 확신의 도움 없이) 사전에 가설을 세운 다음, 그 이론을 검증하는 것입니다.

더 건설적인 접근법은 — 여전히 새로운 기술에 베팅하지 않으면서 — 그저 과거의 교훈을 제시하는 것입니다. 역사에서 배우지 않는 사람은 역사를 반복할 수밖에 없다는 말은 사실입니다.

24.2 데이터 기반 투자

위험을 피하는 또 다른 방법은 판단을 보류하고, 그 대신 객관적인 데이터에 근거하여 베팅 결정을 내리려고 하는 것입니다. 개발 분야에는 공허한 지표가 넘쳐납니다. GitHub 스타, npm 다운로드 수, Hacker News 추천 수, 트위터 언급 수 같은 것들입니다. 심지어 이러한 지표를 추적하는 훌륭한 자동화 도구도 있습니다. 일반 오픈 소스 분야에서는 the Changelog와 Mikeal Rogers의 일간 뉴스레터가 그 두 가지 예입니다. 프로그래머 설문 조사는 거시적인 트렌드 데이터를 얻을 수 있는 또 다른 원천입니다. 예를 들어 언어에 관해서는 Tiobe Index, GitHub Octoverse, StackOverflow 설문 조사가 있고, 특정 생태계에 관해서는 npm 설문 조사나 State of JavaScript 설문 조사가 있습니다. 기술 분야 밖에서는 투자자들이 새로운 트렌드에 뒤늦게라도 합류하기 위해 ExplodingTopics나 RedditList 같은 추적 도구를 자주 사용합니다.

이런 지표도 나쁘지는 않지만, 모두 우리가 실제로 중요하게 여기는 것, 즉 그 기술이 우리의 필요에 얼마나 유용한가를 불완전하게 대신할 뿐입니다. 일반적으로 데이터를 얻기 쉬울수록 그 가치는 낮습니다. 우리가 인기를 신경 쓰는 것은 그것이 여러분의 선택에 따르는 위험을 줄여 주는 한에서입니다. 버그가 발견될 가능성이 높고, 문서가 충실할 가능성이 높으며, 부족한 부분을 메워 줄 서드파티 라이브러리를 구할 수 있기 때문입니다. 정말 큰 기술이라면 일자리도 있을 가능성이 높습니다. 하지만 개발 역량이 커지고 선호가 뚜렷해질수록, 다른 사람들이 무엇을 좋아하는지는 우리에게 점점 덜 중요해집니다.

참고: 더 깊이 있는 논의는 충분히 좋은 것이 최고보다 낫다(장 16)를 참조하십시오!

24.3 일찍 올라타는 법

기술자로서 여러분은 얼리 어답터로서든, 초기 다수층이나 후기 다수층의 일원으로서든, 제프리 무어가 말한 “캐즘”의 어느 한쪽에 서 있는 자신을 자주 발견하게 될 것입니다(자세한 설명은 장 28의 전략적 인식을 참고하십시오). 기술에 일찍 베팅하는 것이 커리어에 가져다주는 이점과 위험은 잘 알려져 있지만, 얼마나 일찍 뛰어들어야 하는지, 그리고 스택의 어느 부분에서 위험을 감수해야 하는지는 논의해 볼 만합니다.

24.3.1 리스크 관리

기술에 베팅할 때 여러분의 주된 임무는 더 나은 소프트웨어를 작성하는 데 도움이 되는 새로운 기술을 익히면서도 전반적인 기술 리스크를 관리하는 것입니다. 기술은 목적을 위한 수단입니다. 궁극적인 최종 목표를 위태롭게 할 수 있는 베팅은 피하도록 노력해야 합니다. 목표가 취업이라면 감수할 수 있는 리스크는 상당히 낮습니다. 목표로 하는 회사들이 이미 사용하는 기술에 대한 전문성을 쌓는 데만 집중하십시오. 고용이 안정되어 있거나 이미 익숙한 스택이 있다면, 도구 모음을 넓히는 데 더 큰 리스크를 감수할 수 있습니다. 정말로 최첨단인 무언가를 하려고 한다면, 검증되지 않은 온갖 새로운 접근 방식을 반드시 시도해 보아야 합니다.

Thoughtbot과 Echobind는 제가 “혁신 크레딧(Inno-vation Credits)”에 비유하는 좋은 접근 방식을 가지고 있습니다. 규칙은 기본적으로, 클라이언트 프로젝트의 스택을 고를 때 새로운 기술은 한두 가지만 골라 사용할 수 있고 나머지는 모두 익숙한 기술이어야 한다는 것입니다. 이들은 심지어 일주일에 하루를 “투자 시간”으로 배정하고, 일이 잘못될 경우에 대비해 견적에 지연 시간을 반영하기까지 합니다. 같은 수준까지 할 필요는 없지만, 어느 정도의 탐색 시간을 배정하는 것은 훌륭한 생각입니다.

24.3.2 무엇이 부족한지 파악하십시오

무언가를 만들고 자신의 스택에 익숙해지면서, 생산성이 충분히 발휘되지 못하는 지점이 어디인지 유념해야 합니다. 여러분이 들어 본 최고의 개발자 중 일부는 “헛소리에 대한 낮은 인내심”을 가졌기에 이름을 알렸습니다. 그 덕분에 그들은 도구, 라이브러리, 언어를 만들었고, 이후 그것으로 유명해졌습니다. 알고 보면 많은 개발자가 여러분과 같은 불만을 품고 있지만, 더 나은 방법을 상상하지 못하거나 기술의 한계를 우회하며 일하는 것을 개의치 않기 때문에 아무것도 하지 않습니다.

“헛소리에 대한 내성”이 생기지 않도록 스스로를 예방하는 한 가지 방법은 가끔씩 다른 개발자 생태계 쪽을 건너다보는 것입니다. 풀스택 JavaScript를 하고 있다면 Rails를 살펴보십시오. Rails를 하고 있다면 Laravel을 살펴보십시오. React Native를 하고 있다면 Flutter를 살펴보십시오. 그 밖에도 마찬가지입니다. 똑같거나 더 나쁜 것도 많이 보게 되겠지만, 이따금 그 커뮤니티에서는 당연하게 여기는데 여러분에게는 정말 놀라운 무언가를 발견하게 될 것입니다. 그것이 바로 여러분이 훔쳐 와야 할 아이디어이거나, 여러분의 스택에도 요구하기 시작해야 할 기준입니다.

저는 이것을 “노출 요법”이라고 부릅니다. 이는 두 번째 시스템 증후군을 깔끔하게 뒤집은 것과 같습니다. 갈아타기 위해 무언가를 평가하는 것이 아닙니다. 현재 상태에 너무 안주하지 않도록, 바깥세상에서 무엇이 가능한지에 마음을 여는 것입니다. 컨퍼런스와 YouTube 채널은 다른 생태계를 접하기에 아주 좋은 방법입니다. 세부 사항에 매몰되지 않고도 높은 수준에서 아이디어를 이해하려 해 보고 그 효과를 관찰할 수 있기 때문입니다.

계속해서 반복적으로 부딪히는 문제들의 목록을 만들어 두십시오. UI 엔지니어링에 대한 목록은 여기 있습니다. 해결책은 왔다가 사라지지만, 문제는 언제나 남습니다.

무엇을 찾고 있는지 알면 소음을 걸러 내고 새로운 해결책을 평가하기가 더 쉬워집니다. 자신의 세계에 무엇이 빠져 있는지에 대한 감각을 길러 두면, 끊임없이 쏟아지는 새 프로젝트와 출시 소식을 훑어보면서 새로운 기술이 자신의 작업 흐름에 어떻게 들어맞을 수 있을지 패턴을 맞춰 보기가 훨씬 쉬워집니다.

24.3.3 평가

프로젝트를 오늘날의 모습만으로 판단하지 않도록 주의하십시오. 일찍 시작했다면 거의 항상 문제가 있기 마련입니다. 문서가 형편없거나, 버그투성이이거나, 기능이 빠져 있을 수도 있습니다. 이 때문에 현재 존재하는 대안들보다 열등해 보일 것입니다. 하지만 여러분이 찾아야 할 것은 그것이 아닙니다. 여러분이 찾아야 할 것은 핵심 아이디어, 즉 그것이 다르게 하는 점이며, 나머지는 모두 고칠 수 있다고 가정했을 때(실제로 고칠 수 있습니다) 그것이 여러분의 세계를 얼마나 판도를 바꿀 만큼 변화시킬지입니다.

Andreesen Horowitz의 Ben Horowitz는 이를 이렇게 즐겨 설명합니다. 새로운 기술은 대개 단 한 가지를 제외한 모든 면에서 기존 대안보다 열등합니다. 그는 이 말을 주로 암호화폐에 적용하지만, NoSQL이나 React, 또는 기술 분야의 다른 어떤 큰 흐름에 대해서도 쉽게 같은 주장을 할 수 있습니다. Thomas Kuhn은 과학혁명의 구조에서 거의 모든 중요한 과학적 돌파구가 먼저 전통, 낡은 사고방식, 낡은 패러다임과의 단절에서 시작된다는 것을 보여 줍니다. 그래서 우리는 이를 때때로 패러다임 전환이라고 부릅니다.

또한 기술적으로 우월한 프로젝트가 “승리”하지 못하는 경우가 많다는 점도 알아 두어야 합니다. 때로는 우월한 특성이 너무 많은 변화를 요구하는 반면, “덜 우월한” 프로젝트는 호환성을 위해 기술적 장점을 일부 양보하기 때문입니다. 경제는 혁명보다 진화에 보상합니다. 이런 일은 VHS 대 Betamax에서부터 React + Redux + TypeScript 대 Elm에 이르기까지 기술의 역사에서 거듭 반복됩니다. 물론 개인 프로젝트에서는 누가 “승리”하는지 신경 쓸 필요가 없지만(장 16에서 논의했듯이), 커리어나 투자 목적으로 말 그대로 승자에 베팅하려는 경우라면 이야기가 달라집니다.

24.3.4 모든 파도를 타려 하지 마십시오

신중하게 위험을 관리하고, 선택하고, 평가한 뒤에도 여전히 모든 새로운 것을 따라잡으려는 사람이 많습니다. 이것이 말 그대로 여러분의 유일한 직업이 아니라면 이렇게 하지 마십시오. 번아웃으로 가는 지름길입니다. 그 기술이 여러분의 투자를 가치 있게 만들어 줄 더 오래 지속되는 메가트렌드(장 29)에 어떻게 들어맞는지에 대한 투자 논지를 갖추도록 하십시오.

Shop Talk Show의 Dave Rupert는 이에 대해 훌륭한 비유를 들었습니다:

“서핑할 때 모든 파도마다 패들링을 하면 그냥 녹초가 되어 버립니다… 솔직히 말해 몸은 다치고 숨은 차고 위험하기까지 합니다. 말 그대로 물에 빠져 죽을 수도 있기 때문입니다. 서핑을 잘하는 사람들을 보십시오. 그들은 그저 힘들이지 않고 패들링해서 나갑니다. 그들은 그렇게 하는 법을 터득했습니다. 그들은 큰 파도가 올 때까지 저 바깥에 앉아 기다립니다. 그들은 큰 파도를 찾는 법을 압니다. 그러고는 이렇게 말합니다. ‘그래, 저 큰 파도를 타야지. 저 큰 파도는 내 시간을 들일 가치가 있으니까.’ 그들은 에너지를 낭비하지 않습니다. 모든 에너지를 좋은 서핑에 쏟습니다.”

24.3.5 사람

비중 있게 따져 보아야 할 또 다른 요소는 프로젝트를 이끄는 사람들입니다. 프로젝트 메인테이너가 고품질 프로젝트를 운영해 온 실적이 있다면, 그 즉시 관심도를 한 단계 끌어올릴 만합니다. 물론 유명한 메인테이너라면 이미 그들의 모든 작업에 이러한 후광 효과가 따라붙어 있을 것입니다. 하지만 덜 알려진 메인테이너에게도 주목해야 합니다. 그들은 스포트라이트를 많이 받지는 않지만, 여러분이 의존하는 양질의 오픈 소스와 도구를 꾸준히 내놓는 사람들입니다.

새 프로젝트에 초기부터 참여하는 사람에 관해서라면, 여러분은 손에 비장의 카드를 쥐고 있습니다. 바로 여러분 자신입니다. 단순히 수동적인 사용자로 머무르지 않고 메인테이너나 기여자로서 적극적으로 참여하기로 하면, 그 기술의 방향과 잠재적 성장성에 영향을 미칠 힘을 얻게 됩니다. 초기야말로 여러분의 커리어를 어떤 기술에 묶어 두고 그 기술이 성장하는 만큼 함께 성장할 수 있는 최적의 시기입니다. 이는 사실상 그 기술에 대한 커리어 콜 옵션을 사는 것이며, 지분을 보유하는 것보다도 더 낫습니다. 일이 잘 풀리면, 여러분의 참여와 기여가 커리어에 도움이 됩니다. Jessie Frazelle의 커리어는 Docker와 함께, Charity Majors는 MongoDB와 함께, Ryan Florence는 React와 함께, Kelsey Hightower는 Kubernetes와 함께 성장했습니다. 이들 중 누구도 프로젝트를 처음 만든 사람은 아니었습니다. 모두 아직 초기일 때 합류하기로 결정했을 뿐이며, 그 기여의 보상을 거두었습니다.

“미래를 예측하는 가장 좋은 방법은 미래를 창조하는 것입니다.” - 데니스 가보르

기술에 베팅할 때 기술 그 자체만이 전부가 아니라는 사실은 그리 놀랍지 않을 것입니다. 기술은 지극히 인간적인 사람들이 초인적인 노력을 기울인 결과로 탄생하며, 기술에 베팅하는 것은 사실상 사람에게 베팅하는 것과 거의 같습니다.

이러한 관점에서 이제 프로젝트 가치라는 주제를 살펴보겠습니다.

24.4 가치의 가치

가치가 운명을 결정합니다.

저는 Joyent의 CTO인 Bryan Cantrill을 통해 이 아이디어를 처음 접했습니다. 다음은 소프트웨어 플랫폼 가치의 몇 가지 예입니다.

• 회복탄력성
• 속도
• 상호 운용성
• 단순성
• 보안
• 유지보수성
• 성능
• 호환성
• 가용성

기술을 만드는 일은 끊임없이 트레이드오프를 거듭하는 일입니다. 이것들은 모두 바람직한 가치이고, 우리는 당연히 이 모든 특성을 달성하고 싶어 하지만, 하나를 위해 다른 하나를 희생해야 할 때 우리의 결정은 우리가 실제로 무엇을 중시하는지를 드러냅니다. 예를 들어, “인터넷 아키텍처”는 보안과 성능보다 가용성과 단순성을 중시합니다. 가치를 명시해 두는 것만으로는 충분히 좋지 않습니다. 정말로 중요한 것은 반복된 행동으로 증명되는 가치입니다. 소프트웨어 프로젝트를 운영하는 사람들은 모든 결정을 통해 그 프로젝트가 표방하는 가치에 표를 던집니다.

운이 좋으면 커뮤니티 리더들이 자신들의 가치를 실제로 문서에 적어 두기도 합니다. 공개된 C++의 목표와 우선순위에는 단 여섯 개의 목표와 네 개의 비목표만 나열되어 있습니다. 그렇다 하더라도 표방하는 가치는 이야기의 절반에 불과하며, 나머지 99%는 행동이 말해 줍니다.

커뮤니티의 가치관에 근본적으로 동의하지 않는다면, 내려진 결정과 취해진 행동, 나아가 공개적인 소통 방식에도 점점 더 동의하지 못하게 될 것입니다. 이런 것들은 기반 기술보다도 더 중요할 수 있습니다. 업계 행사에 가거나 클라이언트와 고객을 맡게 되면 결국 커뮤니티 사람들과 상대해야 하는데, 같은 가치관을 공유한다면 이 일을 훨씬 더 즐길 수 있을 것입니다. 기술이 작업 흐름에서 차지하는 비중이 클수록 가치관도 더 잘 맞아야 합니다. 앞으로의 개발 방향부터 테스트 스위트 품질과 시맨틱 버저닝의 세세한 부분에 이르기까지 모든 것에 영향을 미치기 때문입니다(무엇을 버그로 보느냐가 주관적이기 때문에 버저닝도 주관적입니다).

이것이 Angular 팀의 대규모 이탈, TJ Holowaychuk의 Node.js 이탈, Guido van Rossum의 Python 리더십 사임 같은 일이 일어나는 이유입니다. 가치관의 충돌은 바로잡기가 가장 어렵기 때문에, 어떤 기술이 여러분에게 맞지 않게 되는 궁극적인 이유가 됩니다. 그러므로 어떤 기술에 베팅할 때는 그 기술이 무엇을 중시하는지 최대한 명확히 파악하고, 참여하면서 긍정적인 가치관을 형성하는 데 기여하는 것이 좋습니다.