23  스페셜리스트입니까, 제너럴리스트입니까?

먼저 이것부터 짚고 넘어갑시다. 스페셜리스트로든 제너럴리스트로든 크게 성공할 수 있습니다. 다만 상황에 따라 필요한 개발자의 유형이 다를 뿐입니다.

사람들이 정의조차 합의하지 못하는 상황에서는 이 주제를 제대로 논의하기 어렵습니다. 어떤 집단에서는 제너럴리스트처럼 보이는 사람도 그 집단 밖에 있는 다른 모든 사람에게는 스페셜리스트처럼 보입니다. 전문성은 보는 사람의 눈에 달려 있습니다.

마이클 펠프스를 생각해 보십시오. 2008년 올림픽에서 그는 금메달을 8개나 땄습니다. 여덟 개입니다. (이 사람은 얼마나 말도 안 되는지, 기록을 세운 횟수로 기록을 세웠습니다.) 대부분의 평범한 사람들에게 그는 수영 전문가로 보입니다. 예를 들어, 그를 농구 선발 명단에 넣지는 않을 것입니다. 수영 선수들에게 그는 범접할 수 없는 제너럴리스트로 보입니다. 단 7일 만에 자유형, 접영, 혼영 종목에서 여러 거리에 걸쳐 개인전과 계영 세계 기록을 세웠으니까요.

모든 것은 동심원으로 이루어져 있습니다. 무언가를 전문적으로 파고들었다고 느끼는 바로 그 순간, 그 아래로 여러 하위 분야가 부채꼴처럼 펼쳐져 있고 각 분야마다 여러분보다 한참 앞서 있는 사람들이 있다는 사실을 깨닫게 됩니다. 반대로 폭넓게 아우르려 한다면, 위로든 아래로든 옆으로든 나아갈 단계가 언제나 하나 더 남아 있습니다.

알고 보면, 이것은 여러분이 활용할 수 있는 유용한 프랙털입니다.

23.1 레버리지 대 자급자족

우리는 스페셜리스트와 제너럴리스트의 정의가 명확하지 않다는 점을 인정했습니다. 이 논쟁은 비기술적 역량을 포함하느냐 마느냐의 문제로 더욱 혼란스러워지는 경우가 많습니다(대개 제너럴리스트가 되는 것에 찬성하는지 반대하는지에 따라 허수아비로 쓰입니다).

그럼에도 우리는 여전히 몇 가지 유용한 관찰을 시도해 볼 수 있습니다.

전문화와 일반화는 서로 다른 조건에서 빛을 발합니다.

예를 들어, 전 세계 다섯 개 리전에 걸쳐 1밀리초 단위의 지연 시간과 강한 일관성을 갖춘 트랜잭션을 유지하면서 데이터베이스 신뢰성을 파이브 나인(99.999%)으로 유지하는 일을 전문으로 한다면, 여러분의 서비스를 필요로 하는 회사는 아마 전 세계에 100곳도 채 되지 않을 것입니다. 하지만 여러분은 그 회사들에 엄청난 영향을 미칠 것이며, 그 회사들은 여러분에게 어마어마한 금액을 지불할 것입니다. 이는 전문가는 레버리지의 혜택을 받기 때문입니다.

이렇게 하려고 꼭 대기업에 있어야 하는 것은 아닙니다. 많은 Xoogler(전직 Google 직원)가 Google 밖에서 회사를 차려, 사실상 Google 인프라에서 영감을 받은 기술을 대중에게 제공하고 있습니다.

제너럴리스트는 자급자족 능력이 귀할 때 빛을 발합니다. 디자인과 코딩을 모두 할 수 있다면, 수요를 검증할 수 있을 만큼만 버티는 엉성한 MVP를 직접 만들 수 있습니다. 그러면 이를 근거로 진짜 스페셜리스트를 채용하여 조잡한 프로토타입을 고치고 규모에 맞게 구축할 수 있습니다. 아니면 진행하면서 배워 나가며 직접 해낼 수도 있습니다.

이렇게 하기 위해 꼭 악착같은 스타트업에 있어야 하는 것은 아닙니다. 제너럴리스트는 협업 상대와 더 잘 일할 수 있는 능력을 발휘하거나, 사내 정치와 우선순위 다툼이 걸림돌이 될 때 공식 절차를 우회해 직접 해치움으로써, 혹은 둘 다를 통해 대기업 안에서도 일을 해낼 수 있습니다.

23.2 “풀스택” 개발자

많은 제너럴리스트는 사실 제너럴리스트가 아닙니다. 모든 것을 알기란 불가능하기 때문에, 우리는 모두 무언가를 전문으로 합니다. 오랫동안 “풀스택 개발자”라는 용어가 유행했습니다. 이 용어가 유행한 것은 그것이 쓸모 있는 허구였기 때문입니다:

  • 고용주가 비싼 인력 채용을 여러 역할을 해내는 남는 거래(“일석이조!”)로 정당화하는 데 도움이 되었습니다
  • 개발자들이 자신을 더 많은 일을 할 수 있는 사람으로 내세우는 데 도움이 되었습니다
  • 교육자와 부트캠프가 풀스택 교육이 필요하다는 생각을 팔 수 있게 해 주었습니다

물론 실제로는 “풀스택” 개발자란 대개 JavaScript를 조금 배운 백엔드 개발자였습니다:

그림 「A horse with detailed hindquarters that transition into a crude line-drawn front half.」은 저작권자의 별도 허락이 필요하거나 출처가 확인되지 않아 번역판에 싣지 않습니다. 원문 사이트에서 그림 보기

Firebase나 Amplify 같은 몇몇 특화된 Platform as a Service 서비스 덕분에 프런트엔드 개발자도 이 흐름에 뛰어들 수 있게 되었습니다:

그림 「A detailed dragon drawing that abruptly becomes a crude outline halfway through.」은 저작권자의 별도 허락이 필요하거나 출처가 확인되지 않아 번역판에 싣지 않습니다. 원문 사이트에서 그림 보기

물론 이제는 식상한 밈이 되었고, “풀스택 팀”을 채용하는 것처럼 더 깨어 있는 관점도 등장했습니다.

또한 제너럴리스트로서 자신을 마케팅하기가 더 어렵다는 점도 잘 알려져 있습니다. 사람들이 당신을 어떤 범주에 넣어야 할지 모르기 때문입니다. 이는 실제로 당신과 함께 일하게 되었을 때 약속은 과하게 하고 결과는 그에 못 미치는 상황으로 이어지기 쉽습니다.

그러나 두루 유능하다는 데에는 분명한 이점이 있습니다. 소규모 스타트업 팀에 있다면, 한 번도 훈련받지 않은 일까지 폭넓게 맡아 처리하게 될 것이며, 그 덕분에 향후 다른 팀에서도 탐낼 만한 훌륭한 제너럴리스트 인재가 됩니다. 대기업에서도 협업 상대의 언어로 소통할 수 있다면 필요한 것을 더 효과적으로 얻을 수 있습니다. 그리고 “제너럴리스트”라고 해서 모든 영역에서 정확히 똑같은 역량을 갖춰야 한다는 법은 없습니다.

23.3 “T자형”과 “파이(π)형”

업계 전체가 케이크를 먹으면서도 그대로 남겨 두려는 시도, 즉 두 마리 토끼를 다 잡으려는 시도를 멈추지 않을 것입니다. “풀스택”이 신뢰를 잃은 지금, 그 최신 버전이 바로 “T자형” 엔지니어입니다. 이 개념은 Valve가 직원 핸드북에서 처음 정의했습니다:

그림 「T Shaped Engineer」은 저작권자의 별도 허락이 필요하거나 출처가 확인되지 않아 번역판에 싣지 않습니다. 원문 사이트에서 그림 보기

폭과 깊이를 겸비한다는 이 조합은 물론 매력적이지만, 실제로 존재하는 트레이드오프를 전혀 인정하지 않는다는 점에서 편리한 발상이기도 합니다. 여기서 나올 수 있는 허수아비 논증은, 이 정의대로라면 전문가로 여겨지는 사람은 사실상 누구나 T자형이라고 볼 수 있다는 것입니다. 제 역할을 해내기 위해 다른 기본 기술을 익히려 하지 않는 사람이 어디 있겠습니까?

물론 트레이드오프가 존재하지 않는다면, 더 나아가지 못할 이유가 있겠습니까? Scott Adams는 우리가 두 가지 이상의 분야에 아주 능숙해져야 한다고 말합니다. “파이형” 인재가 되십시오! 고맙습니다, Scott!

그림 「Pi-shaped expertise: broad general knowledge supported by two deep specialist areas.」은 저작권자의 별도 허락이 필요하거나 출처가 확인되지 않아 번역판에 싣지 않습니다. 원문 사이트에서 그림 보기

이왕 지어내는 김에 여기서 멈출 이유가 있겠습니까? 차라리 빗 모양(Comb Shaped) 인재가 되십시오!!

그림 「Comb-shaped expertise replaces one specialty with broad knowledge and several deep specialist areas.」은 저작권자의 별도 허락이 필요하거나 출처가 확인되지 않아 번역판에 싣지 않습니다. 원문 사이트에서 그림 보기

이런 사람들이 존재하지 않아서 비꼬는 것이 아닙니다. 그런 사람들은 분명히 존재합니다. 다만 일반적인 조언으로는 도움이 되지 않습니다. 이런 논의는 이러한 이점을 얻기 위해 중요한 무언가를 포기해야 한다는 사실을 편리하게 빼놓거나, 자신이 어떤 형태인지가 우연이라기보다 선택의 문제인 것처럼 말하기 때문입니다. <sarcasm> 단점은 언제나 작고, 장점은 언제나 엄청납니다. 훌륭합니다. 멋진 Medium 글입니다. 인생이 바뀝니다. </sarcasm>

제가 본 것 중 가장 좋은 견해는 아마 Jeff Scott이 제게 보낸 답글일 것입니다:

제 경험상 대부분의 개발자는 배(pear) 모양입니다!

23.4 밖이 아니라 안을 들여다보십시오

근본적으로 우리는 모두 저마다의 불안과 성공에 대한 철학을 안고 살아갑니다. 우리는 강점을 살리는 편이 더 나을까요, 아니면 약점의 빈틈을 메우는 편이 더 나을까요? 더 빠르게 나아가며 한 가지를 잘해야 할까요, 아니면 더 천천히 나아가며 적응력을 길러야 할까요?

맬컴 글래드웰의 아웃라이어는 극단적인 전문화를 주장하며 “1만 시간의 법칙”을 널리 알렸습니다. 그런데 이후 데이비드 엡스타인의 늦깎이 천재들의 비밀은 정반대의 주장을 펼쳤습니다.

세상은 당신이 충분히 좋지 않다고, 당신이 무언가를 놓치고 있다고, 지금 하고 있는 일과 정반대로 해야 한다고 말할 방법을 끊임없이 찾아낼 것입니다. 성공에 이르는 길이 여러 가지라는 사실을 근본적으로 받아들이는 조언은 읽기(그리고 쓰기도!) 어렵습니다. 진짜 논쟁은 세상이 원하는 것이라는 바깥을 향한 논쟁이라기보다, 내가 원하는 것이라는 안을 향한 논쟁입니다.

그 질문에 답할 수 있는 사람은 오직 여러분뿐입니다. 일단 답을 찾고 나면, 제너럴리스트든 스페셜리스트든 빗(comb)형 인재든 그 길에서 성공할 방법을 찾아낼 것이라고 저는 확신합니다. 세상이 원한다고 생각하는 모습에 자신을 억지로 끼워 맞추기보다, 여러분에게 맞도록 여러분의 세상을 만들어 가십시오.

23.5 확신이 없을 때는 전문화하십시오

그래도 원하신다면 처방에 가까운 제안을 하나 드리겠습니다. 확신이 서지 않을 때는 전문화하십시오. 여기에는 몇 가지 이유가 있습니다:

  • 어차피 대부분의 사람은 관심사가 폭넓습니다. 다시 말해, 제너럴리스트가 되어 Just in Case 방식으로 배우는 것이 자연스러운 경향입니다. 따라서 적절한 균형을 이루려면 이러한 편향을 의식적으로 거슬러야 합니다.
  • 전문화를 강요받는 일은 드물지만, 일반화는 반드시 강요받게 됩니다. 전문화는 레버리지가 있을 때 빛을 발하므로, 여러분은 대개 자신의 전문성을 키울 수 있는 자리를 선택하게 될 것입니다. 그러나 작은 스타트업처럼 스스로 모든 것을 해결해야 하는 상황에 내몰리면, 어쨌든 일반화를 강요받게 됩니다.
  • 전문가가 되는 법을 배우는 것은 그 자체로 하나의 기술입니다. 여러 가지 일을 시작하기만 하면 그저 시작하는 데에만 능숙해집니다. 이는 시작하려면 해야 한다고 누구나 아는 일들, 즉 문서를 읽고, 튜토리얼을 따라 하고, 장난감 프로젝트를 만드는 일을 하는 꽤 평범한 과정입니다. 어떤 분야의 전문가가 되면, 전문가가 되는 법도 함께 배우게 됩니다. 첫 번째 더닝 크루거 정점을 밀고 넘어서고, 무지한 중급자의 밑바닥을 겪어 보고, 끝까지 해내어 한 분야에서 상급자가 되는 것이 어떤 느낌인지 알게 됩니다. 이 덕분에 이후의 모든 전문성 습득이 더 쉬워집니다.
  • 전문화는 프랙털입니다. 도메인 지식이 부족하기 때문에, 지금 여러분에게 전문화처럼 보이는 것도 그 도메인을 더 많이 배우고 더 깊이 들어갈수록 전문화처럼 보이지 않을 수 있습니다. 전문가는 좁은 영역에서 번성합니다. 박사 과정 학생들은 학위 논문을 쓸 때 정치 전반이나 주식 시장 전체, 인체 전체를 다루지 않습니다. 대신 특정 연도의 정치 지형, 가치 투자 대 모멘텀 논쟁, 수면이 생산성에 미치는 영향처럼 좁은 주제를 연구합니다. 숙달에는 경계가 필요합니다.

팀 페리스의 말을 빌리자면, 여러분이 우러러보는 개발자 영웅들은 아마 모두 한두 가지 강점을 극대화한 걸어 다니는 결점 덩어리일 것입니다. 여기 Dan Abramov가 정리한 그가 모르는 것들의 목록이 있습니다. 그가 스스로 모른다는 것을 알고 있는 것들입니다.

23.6 겉으로는 스페셜리스트, 속으로는 제너럴리스트?

마지막으로, 제너럴리스트 또는 스페셜리스트로서 자신을 마케팅하기와 관련된 생각을 하나 덧붙이겠습니다. 언제나 자신의 모든 면을 드러낼 필요는 없습니다. 공개적으로는 특정 기술들로 알려지면서, 사적으로는 다른 역량에도 적극적인 관심을 유지하는 것이 엄청나게 도움이 될 수 있습니다.

Cory House는 컨설팅 문의가 15배 증가하는 것을 경험했습니다. 일반적인 컨설팅을 제공하는 대신 React로의 전환을 전문 분야로 삼기로 결정했을 때였습니다.

같은 개발자입니다. 자신을 내세우는 방식만 달랐습니다. 기회는 15배가 되었습니다.