7  코딩 커리어 너머

우리 업계에서 거의 언급되지 않는 사실 중 하나는 이탈이 매우 많다는 것입니다. 그래서 여전히 주로 코딩으로 생계를 꾸리는 아주 경력 많은 시니어 엔지니어를 보기가 그토록 드문 것입니다. 그들은 단지 드문 것이 아니라, 남아 있는 유일한 사람들이기도 합니다.

때로는 이것이 우리 업계에서 수없이 많이 일어나는 번아웃 사례처럼 “나쁜 이탈”이기도 합니다. 페이스를 조절하십시오. 이 커리어를 오래 이어 갈 생각이라면 마라톤을 단거리 달리기 속도로 뛰어서는 안 됩니다. 번아웃의 증상을 알아차리십시오:

그리고 동료들에게서도 이러한 징후가 보이는지 살펴보십시오. 기술 분야에 종사하는 우리는 소프트웨어와 하드웨어에 문제가 없는지 모니터링하지만, 정작 근본에 있는 웨트웨어(사람)는 잊어버리는 경우가 많습니다.

다행히도 대부분의 사람들은 더 긍정적인 이유로 생계를 위한 코딩을 그만둡니다. 자신에게 더 잘 맞는 일을 찾는 것입니다! 코드가 여러분 세계의 중심이고 지금 당장은 이 말이 불가능한 일처럼 들린다면, 이렇게 생각해 보십시오. 왜 코딩을 하지 않는 사람들이 결정권을 쥐고 있으며, 왜 그들이 여러분에게 돈을 주고 코드를 작성하게 할까요? 그들이 생계를 위해 코딩하지 않음으로써 얻는 가치가 여러분이 생계를 위해 코딩함으로써 얻는 가치보다 분명 더 크기 때문입니다.

여기서는 어느 정도 알고 있는 친구(바로 저입니다!)가 좋은 이탈의 흔한 다섯 가지 경로에 대해 (그 모든 경로를 실제로 직접 겪어 보지는 않았지만) 여러분에게 해 줄 법한 이야기를 간략히 다루겠습니다.

프리랜싱이나 컨설팅은 다루지 않겠습니다. 이들은 코딩 직무에 1인 사업 운영이 조금 더해진 정도라 코딩 직무와 충분히 비슷하기 때문입니다. 하지만 그 길에 관심이 있다면 Nader Dabit의 번창하는 소프트웨어 컨설턴트(The Prosperous Software Consultant), Gerald Weinberg의 컨설팅의 비밀(Secrets of Consulting), Harry Roberts의 컨설턴트를 위한 질문들(Questions for Consultants)을 참고하십시오. 참고할 기준이 필요하다면 Yan Cui가 공개한 그의 컨설팅 수입과 지출을 살펴보십시오. 코딩 능력을 갖춘 사람이 성장해 나갈 수 있는 다른 대안 커리어 경로 목록도 찾아볼 수 있습니다.

이 논의에서는 좋은 점과 함께 나쁜 점도 알려 드리려 합니다. 다시 말해, 100% 좋기만 한 것은 아닙니다. 하지만 어떤 것도 완벽하지는 않습니다. 이것을 “이 길들을 깎아내리는 것”으로 오해하지 마십시오. 이 길들은 많은 사람이 즐기는 훌륭한 커리어 경로임이 분명합니다. 목적은 여느 친구가 그러하듯 잠재적인 단점을 미리 알려 드려서, 여러분이 충분히 알고 뛰어들 수 있도록 하는 것입니다.

이 책의 다른 부분과 마찬가지로, 목표는 100% 정확해지는 것이 아닙니다. 그저 여러분이 이전에 생각해 보지 못했을 고려 사항에 눈을 뜨게 하고, 더 배우거나 자신만의 의견을 형성할 수 있는 방향을 알려 드리려는 것입니다.

저자 노트: 이렇게 범위가 넓은 장을 쓰려면 이처럼 긴 면책 조항을 다는 것이 유일하게 온당한 방법입니다! 쏟아질 불만 폭탄에 대비합니다…

7.1 엔지니어링 관리

코딩 커리어에서 벗어나는 가장 흔한 길은 아마도 엔지니어링 매니저(EM)가 되는 것입니다. 나중에 살펴보겠지만 항상 그런 것은 아닙니다. 그러나 많은 조직에서 EM은 개인 기여자(IC)에 비해 더 많은 돈을 벌고, 더 큰 영향력을 가지며, 회사의 위계와 정보 흐름에서 더 중심적인 위치를 차지하고, 구현 세부 사항을 걱정하는 데 시간을 덜 씁니다.

코딩 커리어의 대부분을 EM에게 보고하며 보내게 되므로, EM이 되는 것을 다음 단계로 여기는 것이 자연스럽게 느껴질 수도 있습니다. 그보다 더 가능성이 높은 것은, 여러분이 탁상공론가처럼 “내가 그 일을 더 잘할 수 있을 텐데!”라는 은근한 의심을 품고 있다는 점입니다.

“내가 책임자였다면 상황이 달라졌을 텐데”라는 생각은 권한이 휘두르기만 하면 무엇이든 고칠 수 있는 전능한 마법 지팡이라는 믿음입니다. - Mark Roddy

회사들은 또한 자연스럽게 최고의 코더를 데려다가 다른 코더들을 책임지는 자리에 앉히고 싶어 합니다. 기업들이 동등한 개인 기여자 커리어 트랙을 만들려고 최선을 다하고 있음에도 불구하고, 좋은 관리자가 부족하다는 사실 때문에 대부분의 조직 인센티브 구조는 어떤 형태로든 피터의 법칙을 부추기게 됩니다.

하지만 엔지니어링에서 엔지니어링 관리로 옮겨 간 적이 있는 사실상 모든 사람의 조언에 귀 기울이십시오. 이것은 엄청난 커리어 전환입니다. 소프트웨어를 개발하던 일에서 피플웨어(Peopleware)를 다루는 일로 넘어가게 됩니다. 이 역할에 맞는 마음가짐을 갖추고 있다면, 이것을 좋은 일로 여기게 될 것입니다! 사람 또한 여러분이 다루는 시스템의 일부입니다!

매니저가 되는 것은 승진이 아닙니다. 평행한 트랙으로 옮겨 가는 수평 이동입니다. 여러 핵심 역량에서 다시 주니어 수준으로 돌아가게 됩니다. - Sarah Mei

엔지니어링 매니저로서:

  • 이제 여러분의 주된 산출물은 코드가 아니라 팀(그리고 더 높이 올라갈수록 팀들로 이루어진 팀)입니다. 따라서 여러분은 채용과 관리에 엄청난 시간을 쓰게 될 것입니다. 위험 부담이 큰 결정적 대화에 쓰는 시간이 기하급수적으로 늘어납니다.
  • 이제 더 이상 일을 해치우려고 임시방편을 대충 엮어 낼 수 없으며, 그 어느 때보다도 프로세스를 따르고 동의를 얻어야 합니다. 진척은 여러분이 익숙했던 것에 비해 빙하처럼 느리게 느껴질 것입니다.
  • 여러분은 기술 표준을 세우는 데 도움을 주지만, 코드를 세세하게 관리하는 것은 피해야 합니다. 이는 매우 미묘한 경계이며, 특히 여러분의 정체성과 자존감이 주로 기술적 전문성에 기반해 왔다면 더욱 그렇습니다. 자기 작업에 “급습해서 똥을 싸 놓고 가는” EM을 좋아하는 사람은 아무도 없습니다. 여러분은 엔지니어들이 스스로 판단하고 스스로 실수하는 것까지 (합리적인 범위 내에서) 믿고 맡겨야 합니다. 그렇게 하려면 다른 사람이 작성한 코드를 일일이 지시하는 것보다, 신뢰할 수 있는 사람을 채용하고 육성하는 것이 더 중요합니다. 궁극적으로는 여러분이 더 높은 자리로 나아갈 수 있도록 자신의 후임자를 육성하는 일도 돕고 싶어질 것입니다.
  • 기밀 정보의 산더미 위에 앉아 있기 때문에, 업무 밖에서조차 친구나 동료에게 완전히 터놓고 지낼 수 없게 됩니다. 사람들은 여러분에게서 자신감과 리더십을 기대하므로, 자신의 의구심과 감정은 조심스럽게 드러내야 합니다.
  • 그 무엇도 완결되거나 완전히 해결되는 법이 없으며, 모든 것이 중요합니다.
  • 중간 관리자로서 여러분에게도 여전히 상사가 있습니다. 여러분은 팀원들의 불만, 꿈, 커리어에 대해 늘 최대한의 책임감을 느끼지만, 여러분 자신의 영향력과 무언가를 바꿀 수 있는 능력은 제한적입니다. 이 사이에서 균형을 잡기란 어려울 수 있습니다.

매니저가 되기로 결정하기 전에 Charity Majors의 매니저가 되지 말아야 할 17가지 이유 목록을 읽어 보고, Nick Caldwell의 “엔지니어링 매니저를 위한 보이트-캄프 테스트”도 해 보십시오. 무엇을 떠맡게 되는지 알고 시작하십시오.

나쁜 점만 있는 것은 아닙니다. 그랬다면 매니저라는 사람들이 아예 없었을 것입니다. 현명한 회사는 뛰어난 개발자를 잃을 위험과 엔지니어링 매니저 인재를 키워야 할 필요성 사이에서 균형을 잡고자 합니다. Facebook 같은 대기업은 임시직 또는 “어소시에이트” EM 직책을 도입할 여력이 있어서, 2년 동안(최소 복무 기간) 매니저 역할을 시험해 볼 수 있고, 결국 맞지 않는다고 판단하더라도 아무런 불이익 없이 엔지니어링 직무로 돌아갈 수 있습니다.

실제로 개인 기여자(Individual Contributor, IC)와 엔지니어링 매니저(Engineering Manager, EM) 역할을 오가는 일은 점점 더 흔해지고 있습니다. 한동안 테이블 반대편에서 사물을 바라보면 더 유능한 시니어 IC가 될 수 있습니다. 엄청난 인기를 끈 Jest 프레임워크의 EM이었고 현재는 React Native의 EM인 Christoph Nakazawa는 다음과 같이 말합니다:

저는 IC에서 EM으로, 다시 IC로, 또다시 EM으로 전환해 왔으며, 매니지먼트를 통해 단순히 IC로서는 배우기 매우 어려운, 더 효과적인 엔지니어링 리더가 되는 법에 관한 교훈을 얻었다고 말할 수 있습니다.

Charity Majors는 이를 엔지니어/매니저 진자라고 부릅니다.

최고의 개인 기여자는 관리직을 경험해 본 사람입니다. 그리고 세계 최고의 기술 리더는 대개 두 가지를 모두 하는 사람입니다. 앞뒤로 오가며 말입니다. 진자처럼 말입니다.

이 게임이 스타트업과 대기업에서 작동하는 방식에는 차이가 있습니다. 대부분의 작은 회사에는 진정한 시니어급 엔지니어가 한 명 이상 필요하지 않은 경우가 많으며, 그래서 이들은 흥미로운 프로젝트를 충분히 맡으려면 컨설팅으로 전향하거나 대기업으로 옮겨야 한다는 사실을 깨닫게 됩니다. 반대로 작은 스타트업에서는 엔지니어링 매니저가 테크 리드를 겸하는 경우가 많아, 코딩과 기술적 의사결정 모두에 상당한 시간을 씁니다. 대기업에서는 이 둘이 완전히 다른 직무이며, 그렇기 때문에 매니지먼트에 관한 조언이 그토록 천차만별인 것입니다.

저는 이 길을 직접 걸어 보지 않았기 때문에, 이 경로에 대해 더 이상 신뢰할 만한 조언을 드릴 수 없습니다. 다행히도 많은 엔지니어링 리더들이 글쓰기를 매우 진지하게 여기므로, 그들의 글을 찾아 읽어 보실 수 있습니다:

물론 읽는 데 너무 많은 시간을 쓰지는 마십시오 :) 직접 겪어 보는 경험을 이길 것은 없습니다.

7.2 제품 관리

엔지니어가 흔히 옮겨 가는 또 다른 “관리”형 직무로는 제품 관리(PM)가 있습니다. 누구를 대상으로 조사하느냐에 따라 다르지만, PM의 24%에서 66%가 이전에 개발자였습니다. PM에게 기술적 배경이 필요한지 아무에게나 물어보면, 질문을 회피하는 “상황에 따라 다르다”는 600단어짜리 답변을 듣게 될 것입니다. 어쨌든 상관없습니다. 여러분은 코딩을 할 줄 알고, 그것이 해가 될 리는 없습니다. 이제 여러분이 할 일은 제품 관리가 자신에게 맞는지 알아내는 것입니다.

코딩만으로 기술 업계에 들어온 사람이라면, 멀리서 볼 때 PM은 불싯 잡(Bullshit Job)의 기묘한 변종처럼 보일 수도 있습니다. 2주에 한 번쯤 나타나서 모두에게 무엇을 할지 지시하고는 사라져서 도대체 무엇을 하는지 알 수 없는 일을 하고, 공들여 색깔별로 정리한 간트 차트가 현실과 어긋나면 화를 내며, 결과물이 출시되면 모든 공을 자기 것으로 가져가기 때문입니다.

농담입니다. PM 직무와 역할의 다양성은, 그런 일이 가능하기나 하다면, EM 역할보다도 훨씬 더 다양합니다. PM은 전통적으로 “제품의 미니 CEO”로 여겨지며, 엔지니어링, 디자인, 비즈니스 사이의 간극을 메우는 일을 맡습니다.

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

제품 관리는 1931년 P&G에서 처음 만들어졌지만, 테크 업계에서 제품 관리라는 현대적 형태가 널리 퍼진 것은 Marissa Mayer 덕분입니다. Yahoo로 가기 전, 그녀가 초창기 Google에서 스타 임원으로 활약하던 시절의 일입니다. 구글은 구글다운(Googley) 인재를 “자체적으로” 매니저로 키우고 싶어 했고, 그래서 2년 과정의 어소시에이트 프로덕트 매니저(APM) 프로그램이 만들어졌습니다. 이 프로그램은 Google Maps를 공동으로 만들고 Facebook의 CTO를 거쳐 현재 Salesforce의 사장을 맡고 있는 Bret Taylor 같은 뛰어난 테크 리더들을 한 세대 전체에 걸쳐 배출했습니다. 에릭 슈미트는 언젠가 APM 출신이 구글을 이끌게 될 것이라고 공개적으로 말한 적도 있습니다(아직 실현되지는 않았습니다. 현 CEO 순다르 피차이는 크롬의 PM을 맡기 전에 컨설턴트였습니다).

이러한 성공을 감안하면, 모든 테크 회사에 어떤 형태로든 PM 직무가 있는 것은 놀라운 일이 아닙니다(Microsoft에서는 이를 “Program Manager”라고 부릅니다). PM 없이 시작해서 결국 PM을 두게 된 회사에서 일해 본 입장에서, 누군가가 제각각인 사람들을 한데 모아 이끌고 앞으로 닥칠 걸림돌과 상호 의존성을 살피고 있다는 것을 알면 정말 안심이 됩니다. 개별 부서는 시야가 좁아지기 쉽고, 자신들의 문제를 다른 부서의 문제보다 더 중요하게 여기는 경향이 있습니다. 처음에는 창업자가 PM 역할을 하지만, 회사가 성장하면서 창업자에게는 다른 할 일이 생기므로, 조만간 “제품을 책임질” 프로덕트 매니저를 채용하거나 승진시켜야 합니다.

개발자를 대상으로 하지 않는 제품(대다수의 제품이 여기에 해당합니다)의 경우, PM은 주요 사용자 대변인이나 도메인 지식 전문가 역할도 맡는 경향이 있습니다. UX/디자인 팀도 사용자 리서치를 수행하지만, 훌륭한 PM은 사용자 페르소나에 관한 모든 것을 압니다. 그들이 어떤 경쟁 제품을 사용하는지, 각 페르소나에게 어떤 마케팅 채널이 가장 효과적인지까지 속속들이 알고 있습니다. 또한 훌륭한 PM은 리서치 결과를 무시해야 할 때를 압니다. 야심 없는 점진적 개선만이 이어지는 세상에서, PM은 회사의 자원을 결집해 아직 존재하지 않는 무언가를 만들어 내는 “비전가” 역할을 할 수 있습니다.

“사람들에게 무엇을 원하는지 물었다면, 그들은 더 빠른 말이라고 답했을 것입니다.” - 모델 T에 대해 헨리 포드가 한 말 (실제로 한 말이 아닐 수도 있음)

또한 PM은 예전에 제품 요구사항 문서(Product Requirements Documents)라는 방대한 설계 명세서를 작성하곤 했습니다. 이 문서는 제품이 어떻게 동작해야 하는지를 세세한 부분까지 모두 기술했습니다(따라서 상당한 양의 사용자 리서치와 엔지니어링 비용에 대한 어느 정도의 감각이 필요했습니다). 그러나 애자일(Agile)과 린(Lean) 개발이 대세인 요즘에는 PRD가 훨씬 간결해졌고 때로는 아예 생략되기도 합니다. 요즘에는 사용자 테스트를 위해 빠르게 MVP를 코딩하거나 목업으로 만들어 낼 수 있는 능력이 훨씬 더 환영받습니다.

PM이 PM답게도, 방금 제가 쓴 모든 단어에는 격렬한 반론이 있습니다. PM들은 자신을 설명하는 온갖 대안 벤 다이어그램을 가지고 있으며, 자신들이 그 무엇의 CEO도 아닌 이유에 관한 Medium 글을 산더미처럼 써 왔습니다. 요즘 선호되는 표현은 PM에게 “모든 책임은 있지만 권한은 전혀 없다”는 것인데, 이를 들으면 PM들이 일을 해내기 위해 얼마나 순전한 매력과 애원에 기대어 버텨야 하는지 궁금해집니다.

실제로는 권한이 거의 없는 또 다른 유형의 “PM”이 있습니다. 바로 프로젝트 매니저입니다. 프로덕트 매니저(때로는 “프로덕트 오너”라고도 부릅니다)는 만들어야 할 제품의 비전을 세우고, 요구사항을 수집하고, 그 우선순위를 정합니다. 반면 프로젝트 매니저는 이 비전에 따라 움직이며 그것이 일정과 예산 안에서 실행되도록 관리합니다. 작은 회사에서는 프로덕트 매니저가 프로젝트 매니저 역할도 겸합니다. 역량이 부족하거나 자원이 부족한 “프로덕트 매니저”는 기능적으로 프로젝트 매니저로 퇴행하게 됩니다. 그것이 살아 있음을 보여 주는 데 필요한 절대적인 최소한이기 때문입니다. 하지만 스프레드시트의 셀을 옮기거나 캘린더 테트리스를 하는 일의 장기적인 가치는 그다지 높지 않습니다.

여기서 개인적인 일화를 하나 소개하겠습니다. 저는 커리어를 바꾸기로 결심하기 전에 1년 동안 비기술직 프로덕트 매니저로 일했습니다. 저희 스타트업에는 개발자가 60명 있었지만, 새로운 제품 기능을 만들기 위해 팀과 함께 일할 때마다 양질의 결과물을 (그것도 적당히 제때) 내놓는 사람은 단 두 명의 개발자뿐이라는 사실을 알게 되었습니다.

60명 중 단 두 명이었습니다.

물론 이것은 명백히 매우 제대로 돌아가지 않는 개발 팀이었지만, 그 결과 웬만큼 유능한 PM이라면 누구나 일을 해내기 위해 이 두 개발자의 시간을 차지하려고 싸웠고, 나머지 개발자들을 상대로는 프로젝트 매니저 노릇을 했습니다. 이 일을 맡았을 때 저는 “미니 CEO”가 된다는 말에 넘어갔지만, 실제로 얻은 것은 자리다툼과 매주 “아직 안 끝났나요?”라고 묻는 통화였습니다. 그런 PM은 되고 싶지 않을 것입니다. 결국 저는 더는 참을 수 없어서 직접 개발자가 되기로 했습니다. PM에서 개발자로 전향하는 경우는 드물지만, 저는 이를 “Team #FineI’llDoItMyself”라고 부르기 시작했습니다. 여러분은 우리와 합류하지 *않기를* 바랍니다!

대다수의 PM에게는 어떤 황당한 아이디어든 “비전”을 앞세워 밀어붙일 수 있는 무제한의 권한도 주어지지 않습니다. 보통은 창업자로부터 어느 정도의 방향 제시가 있고(때로는 지나칠 정도로!), 주요 프로젝트는 이사회 차원에서 합의를 거쳐야 합니다. 다시 말해, 적어도 성공적인 프로젝트를 통해 어느 정도 권한을 얻기 전까지는, 이 일의 일상적인 현실은 “비전 제시”보다는 “일을 해치우는 것”에 훨씬 더 가깝습니다.

전반적으로 PM 일은 여전히 코딩 커리어 이후의 커리어로서 매우 보람 있는 선택이 될 수 있습니다. 창업에 대한 야망이 있거나 엔지니어링 관리보다 훨씬 더 큰 영향력을 원한다면, PM의 길이 최선의 선택입니다. PM은 제품 수준의 OKR(Objectives and Key Results)을 책임지며, 중요한 목표가 걸려 있을 때는 최고 경영진에게 직접 의견을 전할 수 있는 경우가 많습니다. 성과를 귀속시킬 수 있다면, 자기 제품의 손익(Profit & Loss)까지 책임질 수도 있습니다. 자체 P&L을 가진 제품은 마케팅도 직접 운영하는 경우가 많습니다. 이는 매우 전문화된 역량이어서, 대기업에서는 프로덕트 마케팅 매니저와 테크니컬 프로덕트 매니저가 짝을 이루어 일하는 경우가 흔합니다. 고성장 제품 마케팅에 특히 뛰어난 사람들은 그로스 해커라고 불리는데, 이는 Sean Ellis가 만들고 Andrew Chen이 대중화한 용어입니다. 이는 재능 있는 코더라면 탐구해 볼 만한 훌륭한 관련 분야입니다.

참고: PM은 이 책의 전략 섹션에서 다루는 모든 내용에 깊은 관심을 기울여야 합니다!

PM의 길을 고민하는 분들을 위한 추천 읽을거리입니다.

7.3 개발자 관계(Developer Relations)

여러분은 지금 개발자 관계 전문가가 쓴 책을 읽고 있습니다. 여기 담긴 조언의 75%만 따라도 여러분은 개발자 관계 전문가가 되기에 충분한 자격을 갖추게 될 것입니다. 마침 같은 조언의 상당수가 코더의 커리어 중 코딩이 아닌 측면에도 도움이 됩니다(이 책을 쓸 의미가 있었던 유일한 이유도 바로 이것입니다).

그러니 이 책을 읽고 여기 나온 원칙(Principles), 전략(Strategies), 전술(Tactics)을 실천했다면, 여러분은 이미 자격을 갖추었으며 어렵지 않게 그 일자리를 얻을 수 있다고 봐도 됩니다. 이제 우리가 할 일은 여러분이 그 일을 원하는지 알아내는 것입니다.

이 직업을 부르는 이름은 많습니다. 개발자 에반젤리스트(Developer Evangelist), 개발자 관계(Developer Relations), “데브렐로퍼(Devreloper)”, 개발자 애드버킷(Developer Advocate), 개발자 경험 엔지니어(Developer Experience Engineer) 등이 있습니다. 편의상 그냥 “DevRel”이라고 부르겠습니다. 이 이름이 조금 더 낫긴 하지만 “개발자 아보카도(Developer Avocado)”만큼 재미있지는 않습니다. 예상하시겠지만, 직함은 표준화되어 있지 않습니다. 이론상으로는 서로 다른 역할이지만, 현실에서는 모두가 이 역할들을 어설프게 정의된 방식으로 뒤섞어 수행합니다. 직함의 흐름에서 그나마 관찰할 수 있는 것은 “에반젤리스트”는 점점 사라지는 추세이고(“제 제품을 쓰라고 말씀드리는 겁니다”라는 느낌이 너무 강하기 때문입니다), “애드버킷”과 “개발자 경험”은 떠오르는 추세라는 점입니다(사내에서 사용자를 대변하는 역할에 더 집중하거나, 대화를 “양방향 소통”으로 만드는 데 더 집중합니다). 하지만 직함의 변화가 회사가 실제로 만들어 둔 행동 양식이나 인센티브와 밀접하게 맞아떨어지지는 않을 수도 있습니다.

결코 흔한 직업은 아닙니다. 개발자를 대상으로 하는 회사에서나 DevRel을 채용할 이유가 있고, “개발 도구” 회사라 해도 개발자 100명당 DevRel이 1명 정도일 수 있습니다. 하지만 매우 눈에 띄는 직업입니다(이는 경력 중반의 개발자에게 아주 좋은 점입니다). 그래서 개발자로 일하면서도 강연 등을 하는 DevRel 사람들을 많이 보게 되고, 자연스럽게 그 대열에 합류하는 데 관심이 생기게 됩니다.

이 질문은 DevRel의 핵심을 찌릅니다. DevRel은 제품 조직에 속해야 할까요, 마케팅 조직에 속해야 할까요, 아니면 독립해야 할까요? 냉소적인 사람들은 마케팅이라고 말할 것이고, 사용자들은 제품이기를 바랄 것이며, DevRel 담당자들은 DevRel이 독립된 부서로 서기를 원합니다. 실제로 DevRel이 무엇인지는 회사가 실제로 어떻게 운영되는지, 그리고 회사가 자신이 한 말을 얼마나 실천하는지에 달려 있습니다. 누군가를 “개발자 애드버킷(Developer Advocate)”이라고 부르지만, 그 사람이 사실상 모든 시간을 콘텐츠 제작에 쓰고, 사용자 증가를 기준으로 평가받으며, 제품 우선순위 결정에 아무런 의견도 낼 수 없다면, 그 사람은 사용자에게 무언가를 옹호하는 것이 아니라 정말로 사용자를 위해 얼마나 “옹호”하고 있는 것일까요? DevRel 프로그램은 비용이 많이 들고, 이에 대한 ROI를 정당화하는 방법으로 우리가 아는 최선의 방법은 모두 마케팅 지표입니다. 그 결과 관련된 모든 사람의 선의에도 불구하고 DevRel은 마케팅이 되어 버립니다. 측정되는 것이 관리되는 법인데, DevRel은 DevRel을 가장 잘 측정하는 방법에 대해 이제 막 열린 대화를 시작하고 있을 뿐입니다(답이 없을 수도 있습니다). 더 잘 운영되는 DevRel 프로그램은 이를 막기 위해 신중하게 설계하겠지만, 단지 “매우 비싼 제휴 마케터”이거나 이름만 바꾼 “개발자 친화적 마케팅”에 불과한 DevRel도 충분히 많기 때문에 여러분에게 간단히 경고해 둘 가치가 있습니다.

잠재적인 DevRel로서, 이는 여러분이 고려하는 여러 회사에서 조사해야 할 부분이며, 동시에 여러분 자신의 선호가 어디에 있는지도 파악해야 합니다.

좋은 것도 지나치면 문제가 되는 법입니다. 글쓰기와 말하기, 그리고 공개적으로 배우기가 여러분에게 좋다는 말을 들어 왔겠지만, 그것이 전업이 되는 것은 전혀 다른 이야기입니다. 어떤 사람들은 이를 매우 좋아할 것입니다. 회사의 인지도와 함께 자신의 인지도를 높이면서 돈을 받고, 청중과 네트워크를 구축하는 데 매우 중요한 이러한 기술을 연마할 수 있기 때문입니다. 반면 다른 사람들에게는 예전에 재미로 하던 일을 지표, 할당량, 주간 일정이 뒤따르는 직업으로 바꾸는 것이 모든 재미를 앗아 가고, 자신을 “콘텐츠 노역”의 노예로 만들어 버립니다.

사람들이 어떻게 보느냐의 문제도 있습니다. 첫째는 여러분이 이제 돈 받고 홍보하는 사람이 되었다는 시선이고, 둘째는 여러분이 더 이상 “진짜 개발자”가 아니라는 시선입니다. 둘 다 조금은 맞는 말이라서, 맞서기가 가장 어려운 종류의 인식입니다. 진실은 흑백으로 나뉘지 않습니다.

  • 효과적인 DevRel이 되려면 진정한 열정에서 우러나온 옹호를 해야 합니다. 하지만 여러분이 회사 제품을 홍보하는 대가로 돈을 받는 것은 사실이며, 대부분의 고용주는 여러분이 개발자에게 중요한 다른 주제를 다루는 것도 괜찮게 여기지만, 모든 고용주는 회사를 더욱더 홍보하라고 끊임없이 압박할 것입니다. 여러분은 이 압박과 자신의 관심사, 그리고 업계에서의 신뢰도 사이에서 균형을 잡아야 합니다.
  • 공감받는 DevRel이 되려면 여러분이 여전히 실제 개발자들이 마주하는 문제를 해결할 수 있다는 것을 보여 줄 수 있어야 합니다. 하지만 여러분이 더 이상 프로덕션 환경에서 제품을 유지보수하지 않는 것은 사실이며, 발표나 블로그 글에서는 보기 좋지만 테스트, 유지보수, 비용 같은 불편한 현실은 상당 부분 생략한 튜토리얼을 만드는 데 실제로 많은 시간을 쓰게 됩니다(물론 여러분은 자기 회사 제품의 비용도 직접 내지 않으니까요). 여러분은 제품이 프로덕션에 쓸 준비가 되어 있음을 보여 주는 일(어떤 제품에는 이 문제가 없습니다)과 동시에 새로 입문하는 사람들도 쉽게 다가갈 수 있게 만드는 일(모든 제품에 이 문제가 있습니다) 모두에 힘써야 합니다. “콘퍼런스 순회” 중에 다른 DevRel 사람들과만 지나치게 끼리끼리 어울리면서 “실제 개발자들”을 소외시키는 일은 피해야 합니다. 실제 개발자들은 대부분 1년에 콘퍼런스에 한 번 정도만 참석합니다.

출장은 이 일의 큰 부분을 차지했으며, 보통 처음에는 특전으로 시작했다가(와, 올해 40개국을 다녀왔습니다!) 점차 고역이 됩니다(젠장, 아이들과 보내는 시간보다 공항에서 보내는 시간이 더 많습니다). 코로나바이러스 이후의 세상에서는 초점이 온라인 커뮤니티로 완전히 옮겨 갔는데, 이는 환경에는 매우 좋은 일이지만 DevRel 마케팅 예산에도 좋은 일입니다.

쉽다고 말한 사람은 아무도 없습니다. 여기에 DevRel의 장기적인 현실까지 더해 보십시오. DevRel은 막다른 길일 수도 있습니다. DevRel에서 다시 엔지니어링이나 엔지니어링 관리로 전환하기는 어려울 수 있습니다(다른 전환보다 딱히 더 어렵지는 않을 수도 있지만, 단언하기는 어렵습니다). 또한 다른 트랙에는 CTO나 CPO로 가는 명확한 경로가 있는 반면, 지금까지 C 레벨 임원진에는 DevRel 출신이 들어갈 자리가 없습니다.

그럼에도 이 일은 여전히 큰 보람이 있습니다. 이미 즐겨 쓰고 아끼는 도구에 대해 이야기하면서 돈을 받고, 그 즐거움과 지식을 다른 사람들에게 전해 그들이 삶과 일을 더 낫게 만드는 데 쓰도록 하는 것보다 더 좋은 일은 없다고 느껴질 때가 많습니다. 하루 종일 콘텐츠를 만들며 얻은 청중과 인맥은 지금의 직장보다 오래 남아, 다음에 무엇을 하든 성공할 수 있는 발판이 되어 줍니다. 이것의 가치는 아무리 강조해도 지나치지 않습니다. 하지만 더 말하면 자랑처럼 들릴 것 같습니다.

“막다른 커리어”라는 우려에 대해서는 Patrick McKenzie가 이렇게 말합니다:

한 가지 관찰을 말씀드리자면, 제가 아는 모든 개발자 에반젤리스트는 에반젤리스트 일을 그만둔 직후 훨씬 더 좋은 직장으로 옮겨 갑니다. 이는 이른바 빌드 담당자(The Build Guy)처럼 평판이 엇갈리는 다른 엔지니어링 직무에는 해당하지 않습니다. 왜 개발자 에반젤리스트는 더 나은 자리로 올라가는데 빌드 담당자는 그렇지 못할까요? 제 생각에는 에반젤리스트가 말 그대로 수년 동안 수천 명의 사람을 만나 이렇게 보여 주었기 때문입니다. “자, 저는 여러분 앞에서 라이브 코딩을 하면서 동시에 제 고용주에게 큰돈을 벌어다 드리겠습니다. 여러분은 회사를 운영하고 계시고, 엔지니어도 돈도 필요하실 겁니다. 그러니 혹시 모르니까 제 이름을 기억해 두시는 게 좋을 겁니다.”

안타깝게도 저는 이 일을 충분히 오래 하지 않아서, 이를 증명하거나 반증할 만큼의 데이터를 갖고 있지 않습니다. 아마 그런 데이터를 가진 사람은 아무도 없을지도 모릅니다. DevRel이 다른 DevRel 일자리로 옮겨 가는 경우도 꽤 흔하지만, 그것은 여기서 중요한 이야기가 아닙니다. 사용자에게 집중한다는 점이 비슷하기 때문에, DevRel은 기술 제품의 제품 관리와 가까운 친척 관계일 수 있다는 느낌이 듭니다.

회사에 대해 말하거나 글을 쓰는 일을 DevRel만 독점하는 것은 아닙니다. DevRel이 이 역할을 덜 배타적으로 움켜쥘수록 더 좋습니다. 실제로 가장 성공적인 DevRel 프로그램은 사내 엔지니어링 팀이 자신들의 작업과 제품에 대해 자부심을 갖고 목소리를 낼 수 있도록 돕는 훌륭한 파트너가 될 것입니다. 이는 기본적으로 언제나 좋은 결과로 이어집니다. 엔지니어링 팀은 자랑할 기회를 얻고, 청중은 의심할 여지 없이 “진짜” 엔지니어들이 해낸 결코 사소하지 않은 작업을 보게 되며, 고객은 자신이 구매하는 것의 막후를 엿볼 수 있습니다. 심지어 채용도 훨씬 쉬워집니다. Dan Luu는 좋은 기업 엔지니어링 블로그가 어떻게 쓰이는지에 대해 훌륭한 생각을 갖고 있습니다. 사용자층의 참여도가 매우 높은 회사에서는 사용자 그룹과 커뮤니티 밋업도 이러한 역할을 할 수 있습니다. 현실적으로 말하자면, 다른 사람들의 목소리가 전달될 수 있게 하는 것만이 DevRel 인원의 선형적 증가를 넘어 DevRel의 영향력을 확장하는 유일한 방법입니다. 따라서 커뮤니티를 구축하는 능력(Build Community)이야말로 DevRel의 궁극적인 역량입니다.

추천 읽을거리:

7.4 개발자 교육

회사가 자사 제품에 관한 콘텐츠를 만들라고 여러분에게 돈을 주는 대신, 여러분의 청중이 자신을 가르칠 콘텐츠를 만들라고 여러분에게 돈을 내게 하면 어떻겠습니까? 참으로 참신한 아이디어입니다! 이것이 바로 개발자-교육자의 영역입니다. “강사”나 “트레이너”라는 말은 너무 밋밋하게 느껴져서 제가 방금 지어낸 직함입니다.

이미 전업 교육자로 활동하는 사람들에게서 배워 본 적이 있을 테니, 이 일이 무엇인지는 이미 알고 있을 것입니다. DevRel 일과 상당히 비슷하지만, 결과물이 대개 더 상품화되어 있고 제품 마케팅에 큰 비중을 둔다는 점이 다릅니다. 이들은 말 그대로 강좌, 워크숍, 책으로 버는 돈으로 생계를 꾸리기 때문입니다.

개발자 교육은 하드 모드의 DevRel입니다. 그만큼의 위험과 보상이 따릅니다. DevRel로서 버는 돈은 회사의 급여 체계에 의해 제한됩니다. 여러분이 엄청난 성과를 내서 신규 사용자를 3배로 늘리더라도, 그에 비례하는 돈은 한 푼도 받지 못합니다. 하지만 이는 괜찮습니다. 반대로 사용자 수가 목표에 미치지 못하는 상황이 생기더라도 여러분은 (어느 정도) 보호받기 때문입니다. DevRel과 비교했을 때 개발자 교육자가 가진 장점 하나는 모두가 이미 사용하고 있는 기반 기술에 집중할 수 있다는 점입니다. 반면 DevRel의 목적 중 일부는 사람들이 아직 사용하지 않는 독점 제품을 사용해 보게 만드는 것입니다.

개발자 교육자는 양질의 콘텐츠를 만들고 이를 마케팅하는 자신의 능력에 100% 의존합니다. 쥐꼬리만 한 돈을 벌 수도 있고, 실력 있는 개발자 교육자 중 상당수가 그렇듯 수백만 달러를 버는 부자가 될 수도 있습니다. 실력 있는 개발자 교육자라면 여섯 달 동안 강좌 하나를 만들어 50만~100만 달러를 벌고, 남은 시간은 청중을 모으고 다음 강좌의 아이디어를 수집하는 데 쓸 수도 있습니다. 물론 문제는 그것이 성공한 사람들의 이야기라는 점입니다. 그만큼 성공하지 못한 사람들은 관심을 끌기 위해 고군분투하며 수백 시간을 들여 콘텐츠를 만들지만, 한 푼도 벌지 못합니다.

개발자 교육자는 초보자용 콘텐츠를 많이 만들어야 한다는 난제에도 부딪힙니다. 코드를 잘 작성할 수 있다고 해서 그것을 잘 가르칠 수 있는 것은 아닙니다. 게다가 단순히 수학적으로 초보자가 더 많기 때문에 초보자용 콘텐츠는 언제나 고급 콘텐츠보다 훨씬 더 많은 돈을 벌어들이지만, map과 forEach의 차이에 대한 9457번째 설명을 만드는 일은 지적으로 덜 자극적일 수 있습니다. 여러분의 일을 “초보자” 콘텐츠가 아니라 “기초” 콘텐츠를 가르치는 일로 바꾸어 생각할 수도 있지만, 그저 일을 흥미롭게 유지하기 위해서라도 여러분만의 색깔을 입혀야 할 필요성에서 벗어날 수는 없습니다. 지적 관심사를 탐구할 자유가 전혀 없는 것은 아니지만, 시장이 원하는 것을 제공해야 하기 때문에 분명 한계가 있습니다.

개발자 교육자는 대부분 독립적으로 활동하기 때문에, 그들 뒤에는 회사 브랜드나 제품이 없습니다. 그들 자신이 곧 브랜드입니다. 따라서 그들은 마케팅에, 그리고 사실상 소규모 1인 사업을 운영하는 데 수반되는 다른 모든 일에 매우 뛰어나야 합니다. 다음은 David Perell이 정리한 여러 분야의 목록입니다:

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

개발자 교육자가 되기 위해 완전히 독립할 필요는 없습니다. Pluralsight, LinkedIn Learning, Treehouse, Frontend Masters, Egghead.io 같은 수많은 전문 교육 플랫폼이 수익의 상당 부분(~70%?)을 가져가는 대신, 현업 개발자가 강좌를 제작하도록 돕고 마케팅과 결제까지 처리해 줍니다. 콘텐츠 제작이 이 일에서 가장 어려운 부분이므로 이는 한번 시도해 보기에 아주 좋은 방법이며, 전업으로 하지 않기로 결정하더라도 꾸준한 불로 소득원을 만들 수 있는 훌륭한 방법이기도 합니다.

추천 읽을거리:

7.5 창업

마지막으로 창업가라는 범주가 있습니다. 1인 개발자 교육자(Developer Educator) 사업부터 혼자 활동하는 “인디 해커”, 부트스트래핑 또는 인디 스타트업, 본격적인 벤처 투자를 받은 스타트업에 이르기까지 다양합니다. 코딩을 할 줄 아는 사람으로서 여러분은 맨손으로 확장 가능한 큰 가치를 지닌 무언가를 만들어 낼 수 있으며, 이는 참으로 강력한 힘입니다.

대부분의 스타트업이 실패한다는 사실은 잘 알려져 있습니다. 나쁜 아이디어는 존재합니다. 시장의 빈틈을 찾았다 해도, 그 빈틈에는 시장이 없을 수도 있습니다. 사람들이 원하는 것을 만들어야 한다는 것은 알고 있지만, 문제는 사람들이 직접 보기 전까지는 자신이 무엇을 원하는지 모르는 경우가 많다는 점입니다. 사람들에게 물어볼 수도 없습니다. 데이비드 오길비가 일찍이 지적했듯이 “시장 조사의 문제는 사람들이 자신이 느끼는 대로 생각하지 않고, 생각하는 대로 말하지 않으며, 말하는 대로 행동하지 않는다는 것입니다”.

성공하는 사람들조차도 사업을 일구는 동안에는 아무것도 얻지 못하는 길고 궁핍한 시간을 보냅니다. 게일 굿맨(Gail Goodman)은 이를 길고 느린 죽음의 경사로라고 불러 유명해졌습니다. 여러분의 기회비용, 즉 창업자가 되려 하지 않고 시니어 개발자로 일했다면 대신 벌었을 수도 있는 돈은 매우 크며, 수백만 달러에 이를 수도 있습니다. 이것은 스타트업을 시작하지 말아야 할 여러 이유 중 하나입니다(Paul Graham의 답변이 달린 더 긴 목록도 있습니다). 실제로 부자가 되려고 스타트업을 시작해서는 안 되며, 마땅히 존재해야 하지만 아직 존재하지 않는 무언가를 만들어야겠다는 강한 충동을 느끼기 때문에 해야 한다는 말이 자주 나옵니다. 여러분이 옳다면 부자가 되는 것은 부수적인 결과입니다.

이러한 위험을 줄이는 영리한 방법들이 있습니다. 예를 들어 현재 다니는 회사가 여러분의 첫 고객이 되어 준다는 계약을 맺고 퇴사할 수도 있고, 정말 절박해져서 스타트업 자금을 마련하려고 정치 테마 시리얼을 팔 수도 있습니다.

개발자로서 여러분은 어떤 문제든 코드로 해결하려 드는 편향이 있다는 사실을 인정해야 합니다. 그것이 여러분이 잘하고 즐기는 일이기 때문입니다. 그러나 이렇게 하면 고객과 대화하는 어려운 부분, 즉 고객이 무엇을 원하는지 알아내는 일(제품 관리), 고객 앞에 나서는 일(마케팅), 그리고 구매하도록 설득하는 일(영업)을 피하게 됩니다. 창업은 사람 관리부터 제품 관리, 마케팅에 이르기까지 이 장에서 다룬 모든 것의 가장 힘든 부분을 한데 모아 여러분의 전업으로 만들며, 그 위에 여러분은 여전히 코드도 작성해야 한다는 사실을 피할 수 없습니다. 하지만 그만큼 얻는 것도 큽니다.

창업에는 몇 가지 중대한 갈림길이 있습니다. 정답은 대개 두 극단 사이 어딘가에 있습니다.

  • 제품 주도 또는 엔지니어링 주도: 사람들이 원하는 것을 먼저 파악한 다음 그것을 만들 방법을 찾거나, 아니면 여러분이 만들 수 있는 것을 먼저 파악한 다음 사람들이 그것을 원하게 만들 방법을 찾습니다.

  • 벤처 캐피털 대 부트스트래핑: 어떤 사람들은 자신이 추구하는 창업 방식에 대해 극단적인 입장을 취합니다. VC는 악이므로 무슨 일이 있어도 부트스트래핑을 하겠다고 하거나, 인생은 짧으니 모든 것을 걸겠다고 합니다. 이는 현명하지 않아 보입니다. 자금 조달 구조를 기회에 맞추십시오. 네트워크 효과가 있고, 먼저 시장을 선점한 승자가 대부분을 가져가는 기회가 보인다면 그곳에 도달하기 위해 VC(또는 벤처 대출)를 받으십시오. 그렇지 않다면 부트스트래핑하십시오. 어느 쪽이든, 신규 사용자당 수익성이 높을수록 어떤 거래를 하든 더 유리한 경제적 조건을 얻게 됩니다. 과소대표된 소수자 집단에 속한다면, 실리콘밸리의 패턴 매칭 편향에 맞서는 #ANGELS, Backstage Capital, Astia Global 같은 다양성 펀드가 있다는 사실을 잊지 마십시오. 마지막으로, VC와 부트스트래핑의 특성을 결합한 Indie.vc와 Earnest Capital 같은 새로운 하이브리드 모델도 있다는 점에 유의하십시오.

  • B2B vs B2C: 기업에 판매하느냐 소비자에게 판매하느냐는 사업의 경제성에 엄청난 차이를 만들 수 있습니다. 기업은 더 높은 가격을 감당할 수 있고 이탈률도 비교적 낮을 수 있지만(~1%), 그 수가 적고 이들에게 도달하는 데 비용이 더 많이 들 수 있습니다. 소비자는 수가 많고 퍼포먼스 마케팅과 소셜 미디어를 통해 쉽게 도달할 수 있지만, 가격에 매우 민감하며 월 5~10%의 이탈률도 드물지 않습니다. “B2B2C”라는 용어는 마켓플레이스, 플랫폼, 애그리게이터(장 27)에 흔히 쓰입니다. 최근 몇 년 사이 개발자 도구 시장은 개발자에게는 소비자처럼 마케팅하면서도 기업처럼 지출하게 할 수 있다는 깨달음 덕분에 탄력을 받고 있으며 전문 투자도 받고 있습니다. 물론 Zoom 같은 기업은 극히 드물게 B2B든 B2C든 똑같은 매력을 지닙니다.

  • 셀프 서비스 대 엔터프라이즈: B2B 고객은 저마다 다른 방식으로 구매하기를 선호합니다. IBM, Oracle, Salesforce 시절부터 이어져 온 전통적인 소프트웨어 판매 방식은 “하향식(top-down)”입니다. 아주 비싼 정장을 입은 아주 비싼 영업 사원을 고용해 CTO/CEO와의 적절한 미팅 자리에 들어가게 하고, 판매가 성사된 뒤에 회사 전체로 도입을 확산시키는 방식입니다.

    최근 소프트웨어 스타트업의 역사는 이를 완전히 뒤집었습니다. JIRA를 만든 Atlassian은 순전히 “상향식(bottom-up)” 판매만으로 IPO 전까지 13년 동안 외부 투자 없이 자력으로 성장한 것으로 유명합니다. 개인 사용자가 망설임 없이 자기 신용카드로 결제할 수 있는 저렴한 셀프서비스 요금제를 제공한 것입니다. 그렇다고 이들이 기업 대상 판매를 완전히 외면한다는 뜻은 아닙니다. 오히려 “귀사 직원의 절반이 이미 자기 돈을 내고 저희 제품을 쓰고 있습니다. 바로 여기에 서명하시면 대시보드와 추가 기능을 이용하실 수 있습니다”라고 말할 수 있다면, 경영진과의 미팅에서 판매하기가 훨씬 쉬워질 수 있습니다.

    “바텀업”을 지나치게 밀어붙일 수도 있습니다. 어떤 벤더든 철저히 검증해야 할 보안상, 컴플라이언스상의 이유는 충분합니다. 창업자 입장에서 보면, 엔터프라이즈 매출은 대개 훨씬 더 오래 유지되고(이탈이 적고) 마진도 더 높습니다(수익이 더 큽니다). 다행히 “엔터프라이즈 기능”은 비교적 표준화되어 있습니다. 누구나 싱글 사인온(SSO), 온프레미스 소프트웨어, 감사 로그, 팀 관리, SLA 등을 원합니다. 그래서 이를 도와주는 체크리스트는 물론 아예 이것만 다루는 스타트업까지 생겨났을 정도입니다.

  • 제품 대 서비스: 소프트웨어 스타트업의 맥락에서 서비스는 개별 고객 각각의 필요에 맞춘 맞춤형 소프트웨어를 작성하는 것을 의미하고, 제품은 모든 고객이 사용하는 하나의 소프트웨어를 작성하는 것을 의미합니다.

    제품은 확장성이 더 뛰어납니다. 추가하는 모든 기능이 (미래의 고객을 포함한) 모든 고객에게 즉시 유용하기 때문입니다. 반면 서비스는 판매하기가 더 쉽습니다. 각 사용자의 필요를 직접 해결해 주기 때문입니다. 많은 사람들이 제품이 서비스보다 낫다는 생각에 사로잡힙니다. 확장 가능한 일을 하고 싶어 하기 때문입니다(그리고 순수한 서비스 사업은 기본적으로 그 사실을 인정하지 않으려는 컨설팅 업체일 뿐입니다).

    하지만 초기에는 제품부터 시작하는 것이 좋을 수 있습니다. 묘하게도 이것은 VC와 인디 해커 모두가 동의하는 단 하나의 사항입니다. 인디 커뮤니티에서는 이것이 계단식(stairstep) 또는 사다리(ladder) 접근법으로 널리 알려져 있습니다. 그런 다음 제품화된 서비스(Productized Services)로 넘어갈 수 있습니다. VC/YC 커뮤니티에서는 이것을 확장되지 않는 일을 하라(Do Things that Don’t Scale)라고 부릅니다. 요컨대, “Software as a Service(서비스형 소프트웨어)”를 만들기 전에 “Service as a Service(서비스형 서비스)”를 먼저 제공할 수 있습니다.

    서비스를 제공하면 수익이 더 일찍 들어오고, 동시에 고객의 요구에 극도로 민감하게 반응할 수 있습니다. 아무도 원하지 않는 제품을 혼자만의 세계에 빠져 만드는 대신, 자신의 필요를 충족하기 위해 내부적으로 제품을 만들고, 결국 “서비스 파사드(Services Facade)”를 서서히 걷어내어 사용자가 제품을 직접 사용하게 할 수 있습니다. 이 과정은 오랜 시간이 걸릴 수 있으며 완전히 사라지지는 않습니다. 저명한 소프트웨어 스타트업 투자자인 Chetan Puttagunta에 따르면 매출이 6천만 달러일 때 소프트웨어 스타트업 매출의 절반이 서비스에서 나오며, 8억 달러에 이르러도 서비스 매출은 여전히 20%를 차지합니다. 이를 제품은 핵심, 서비스는 껍데기(Product Core, Services Shell)라고 표현할 수 있습니다.

  • 수평적 vs 수직적: 특정한 한 유형의 고객을 위한 “원스톱 숍” 솔루션을 만들 수도 있고, 여러 유형의 고객을 위해 “한 가지를 잘하는” 하나의 솔루션을 만들 수도 있습니다. 고객에 집중하는 편이 개발하기 더 쉽게 느껴지기 때문에 전자로 시작하는 것이 대개 더 쉽지만, 이미 존재하는 여러 것들의 조악한 버전을 만들게 될 위험이 있습니다. 그래도 Joel Spolsky는 “버티컬 소프트웨어는 성공시키기도 돈을 벌기도 훨씬 쉬우며, 첫 스타트업으로 좋은 선택”이라고 주장합니다.

    어느 쪽을 택하든 크게 성공할 수 있습니다. 아마 모두가 동의하는 단 한 가지는 초기에 두 가지를 모두 하려고 하지 말라는 것입니다.

    이 주제를 비롯해 소프트웨어 비즈니스 모델의 다른 측면에 대해 더 알고 싶다면 The Business of Software(장 27)를 참고하십시오.

창업에 관한 최고의 조언은 Indiehackers 커뮤니티와 팟캐스트에서 얻을 수 있습니다. 개발자라면 다른 곳을 찾아볼 필요가 없습니다.