37  사이드 프로젝트

사이드 프로젝트가 이 업계에서 성공하는 데 꼭 필요한 것은 아니지만, 학습과 경력 개발에 엄청난 이점을 제공합니다. 가능하다면 꾸준히 출시하는 사이드 프로젝트를 한두 개 가지고 있기를 강력히 권합니다.

37.1 왜 사이드 프로젝트를 해야 합니까?

더 잘 배웁니다. 모든 사이드 프로젝트는 배운 것을 적용하는 한 형태입니다. 이론으로 배운 것을 실제로 사용해 보려고 할 때 얼마나 많은 것을 배우게 되는지 놀라울 정도입니다. 자신의 이해에 어떤 빈틈이 있는지 금방 발견하게 됩니다. 무엇이 사실이고 무엇이 마케팅용 헛소리인지 알게 됩니다. 똑똑하게 들린다고 해서 모두가 자기가 하는 말을 제대로 알고 있는 것은 아니라는 사실도 알게 됩니다. 그리고 물론 사용한 것은 훨씬 더 잘 기억합니다.

망가뜨려도 되는 장난감. Apprenticeship Patterns라는 책이 사이드 프로젝트를 이렇게 바라보는 관점을 널리 알렸습니다. 많은 소프트웨어 개발자는 실패의 대가가 큰 환경에서 일합니다. 하지만 경험은 실패 위에 쌓입니다. 뛰어난 진보는 큰 위험을 안전하게 감수할 수 있을 때에만 이룰 수 있습니다. 업무 외적으로 더 작은 프로젝트를 진행하면, 평소와 같은 대가를 치르지 않고도 실험하고 실수해 볼 수 있습니다. 망가뜨려도 되는 장난감이 있으면 Hello World 단계를 더 빨리 넘어설 수 있습니다. 새로운 라이브러리나 프레임워크처럼 무언가를 하는 새로운 방법을 접했을 때, 그것을 사이드 프로젝트에 넣어 보고 여러분이 잘 아는, 간단하지 않은 사용 사례에서 어떤 느낌인지 확인해 볼 수 있습니다. 동료가 특정 기술에 대한 의견을 물어 올 때, 더 이상 문서나 마케팅에 기대어 판단하지 않고, 실제로 “진짜” 무언가에 사용해 본 경험에서 나오는 어느 정도의 권위를 내세울 수 있습니다.

예시: Kent C. Dodds와 Adam Rackis는 둘 다 책장 앱(Kent의 앱, Adam의 앱)을 망가뜨려도 되는 장난감으로 유지하고 있습니다. 열성적인 독서가들에게는 뭔가 특별한 점이 있는 것이 분명합니다! 새 언어를 배우는 중이라면, 정적 사이트 생성기를 만드는 것은 필요한 기능이 아주 많기 때문에 훌륭한 사이드 프로젝트가 된다고 Vincent Prouillet은 말합니다.

새로운 것 프로토타이핑하기. 꼭 앱만 만들어야 하는 것은 아닙니다. 나만의 X를 밑바닥부터 만들어 보거나, 이미 사용하고 있는 무언가의 “라이트” 버전을 만들어 볼 수도 있습니다. 사람들은 자신이 주로 쓰는 앱이나 도구의 “라이트 버전”을 만들면서 아주 많은 것을 배우고, 결국 그것을 실제 업무에 적용하게 되는 경우가 많습니다. Dominic Gannaway가 Inferno.js로 그랬고(지금 그는 React 코어 팀에 있습니다), Zack Argyle은 사내 해커톤에서 Pinterest PWA를 만들고 CEO를 설득해 실제 Pinterest 사이트를 PWA로 전환했습니다(지금 그는 React Native 팀을 이끌고 있습니다). Google은 한때 20% 규칙으로 유명했는데, 이 규칙에서 Gmail, Chromecast, AdSense(수십억 달러의 가치를 지닌) 같은 놀라운 사이드 프로젝트가 탄생했습니다.

출시를 연습하십시오. 출시는 코딩과는 완전히 다른 분야입니다. 직장에서 코드를 출시할 때, 여러분은 출시판 범퍼 볼링을 하고 있는 셈입니다. 시스템은 여러분이 최대한 실패하지 않도록 짜여 있습니다. 주변에는 무엇을 할지, 언제 할지, 어떻게 마케팅할지, 예산이 얼마인지, 무엇을 하지 말아야 할지 결정하도록 도와주는 동료와 상사가 있습니다. 여러분이 출시하면 동료들은 관심을 기울일 수밖에 없습니다. 현실에서는 이 중 어느 것도 사실이 아닙니다. 사이드 프로젝트를 할 때 여러분은 코드를 의미 있게 만들어 주는, 코딩의 코드 외적인 모든 측면을 연습하게 됩니다. 바로 의사 결정, 우선순위 설정, 마케팅, 문서화입니다. 언젠가 스타트업 창업을 꿈꾼다면, 이 기술들에 생계를 의존하기 시작하기 전에 미리 연습해 두어야 합니다. 시니어로 성장하고자 하는 주니어 엔지니어라면, 모두가 시니어 엔지니어의 핵심 자질로 꼽는 몇 안 되는 것 중 하나가 독립적으로 실행하는 능력이라는 점을 이해하십시오. 원하는 직책에 걸맞게 행동하십시오.

허락 없이 하는 성장. 사이드 프로젝트의 또 다른 장점은 아무도 안 된다고 말할 수 없다는 것입니다. 회사 기밀을 유출하지만 않는다면, 대개 원하는 무엇이든 작업할 수 있습니다. 회사의 직급 체계는 아무리 좋은 의도로 만들어졌더라도, 평균적인 엔지니어에 대한 이론적 기대치에 맞춰져 있어 여러분의 경력 성장에 상한선을 둔다는 위험이 있습니다. 하지만 여러분은 평균적인 엔지니어가 아닙니다. 세상에, 여러분은 여가 시간에 이 책을 읽고 있지 않습니까! 직장에서 저평가되고 있다고 느끼거나 인위적으로 제약받고 있다고 느낀다면, 사이드 프로젝트는 여러분의 멋진 역량을 마음껏 펼쳐 보일 수 있는 배출구가 됩니다. 프로젝트를 비밀로 할 필요는 없습니다. 여러분을 지지해 주는 매니저라면 여러분이 날개를 펴려 한다는 것을 알아줄 뿐만 아니라, 적극적으로 격려하고 자원도 지원해 줄 것입니다. 여러분이 성장하는 것을 두려워하는 매니저라면 애초에 여러분의 매니저가 되어서는 안 됩니다. 이는 자연스럽게 다음 이야기로 이어집니다….

이력서 강화. 사이드 프로젝트가 입사 지원의 필수 요건이 되어서는 절대 안 되지만, 독립적으로 일할 수 있고 기술에 대한 열정과 호기심이 있다는 것을 보여 주는 데 대개 도움이 됩니다. 현재 직장에서는 그럴 만한 이유가 있어 레거시 기술을 다루고 있을 수도 있지만, 더 새로운 기술 스택을 다루는 곳으로 이직하고 싶은데 그 스택에 대한 경험이 없다면, 일하고 싶은 스택으로 간단하지 않은 무언가를 만들어 봤음을 보여 주는 사이드 프로젝트가 이력서의 구원투수가 될 수 있습니다. 물론 어떤 사람들은 이를 지나치게 밀어붙여 이력서 주도 개발(Resume Driven Development)을 하기도 합니다. 실제로는 이것이 실제 개발자들의 행태라기보다는 심술궂은 Reddit 트롤들의 비난인 경우가 더 많다고 생각합니다. 정보 보안 분야에서 경력을 쌓고자 한다면, BugCrowd와 HackerOne에서 버그 바운티를 받는 것은 훌륭한 이력서 항목이 됩니다.

생산성을 높이십시오. 사이드 프로젝트는 업무 효율을 높여 주는 개발 도구가 될 수도 있습니다. 이런 사이드 프로젝트가 많은 경우 가장 좋은 종류입니다. 가장 많이 배우게 되는 사이드 프로젝트는 직접 사용하는 사이드 프로젝트이기 때문이며, 게다가 업무에서 귀중한 시간도 아껴 줍니다. 하루에 50번씩 하는 일부터 한 달에 한 번만 하는 일까지, 여러분이 하는 모든 범위의 작업을 폭넓게 떠올려 보십시오. xkcd의 랜들 먼로(Randall Munroe)는 작업 자동화에 얼마나 많은 시간을 투자해야 하는지를 계산한 훌륭한 표를 만들었습니다:

시간을 들일 가치가 있을까? XKCD 1205

사용자 공감. 사이드 프로젝트를 하다 보면 회사 제품을 쓰는 최종 사용자의 입장이 되어 보는 경우가 많습니다. 직원이라면 보통 무료로 써 볼 수 있습니다. 제품을 직접 만들고 있으니 그 제품을 속속들이 안다고 생각할지도 모릅니다. 실제로 사용자로서 써 보기 전까지는 말입니다. 갑자기 모든 버그 리포트가 현실이 됩니다. 갑자기 잘못된 설계 결정이 중요해집니다. 갑자기 문서와 좋은 문구가 귀찮은 일이 아니라 결정적으로 중요한 일이 됩니다.

돈 벌기. 사이드 프로젝트가 돈을 벌어 준다면 갑자기 선택지가 생깁니다. 피터 레벨스(Pieter Levels) 수준의 인디 해커까지 될 필요는 없지만, 부업으로 얻는 약간의 패시브 인컴은 결코 손해가 아닙니다. 그러나 테일러 오트웰(Taylor Otwell), 마이크 퍼햄(Mike Perham), 안 로르(Anne Laure) 같은 개발자들처럼 예상외로 잘 풀린다면, 이제 여러분의 업사이드에는 한계가 없습니다. 미카엘 조(Mikael Cho)는 결국 사업 전체를 자신의 사이드 프로젝트인 Unsplash로 전환했습니다. 일을 할 때 여러분은 자신의 시간을 빌려주는 것입니다. 사이드 프로젝트를 할 때 여러분은 지분을 소유합니다. 부자들은 지분을 소유합니다. 부자들처럼 하십시오. 여러분의 프로젝트는 다음 직무를 협상할 때 좋은 BATNA(자세한 내용은 협상 장, 장 31을 참고하십시오) 역할도 합니다.

돈을 벌 가능성이 있는 프로젝트에 대해 짧게 덧붙이겠습니다. IP 양도에 주의하십시오. 대부분의 개발자는 “직무 발명 계약”에 서명하는데, 그 내용은 “개인 시간에 무엇을 하든 상관하지 않는다”부터 “회사가 24시간 내내 당신을 소유한다”까지 다양하며, 어느 관할권에 있느냐에 따라 법적 효력이 없는 경우도 여러 가지입니다. 부정적인 결과는 해고(Reilly Chase에게는 결국 잘된 일이었지만요 - 선택지가 있다는 것은 언제나 좋은 일입니다!)부터 회사가 여러분의 프로젝트를 자기 소유라고 주장하는 경우(!)까지 다양합니다. 허용되는 경계가 어디까지인지 명확히 하려고 노력하십시오. 관리자에게 프로젝트를 비밀로 하지 않으면 이 일이 더 쉬워집니다. 상식적인 규칙이 적용됩니다. 고용주의 제품과 직접 경쟁하거나 그 제품을 베끼지 마십시오. 근무 시간 중에 작업해야 한다면 명시적인 허락을 받으십시오. 회사 장비를 사용해 프로젝트를 만들지 마십시오(나중에 생길 수 있는 논란을 피하기 위해서입니다).

생산적인 재미. 단지 재미있다는 이유만으로도 무언가를 할 수 있다는 사실을 잊지 마십시오. 그보다 더 나은 이유는 필요하지 않습니다. 하지만 수동적인 재미(편히 기대앉아 Netflix를 보거나 책을 읽는 것)와 생산적인 재미(만들고, 실험하고, 실패하는 것)는 다릅니다. 대부분의 사람들은 소비:창작 비율이 극도로 불균형합니다. 재미있는 사이드 프로젝트로 이를 바로잡으십시오!

37.2 코드와 삶의 균형

번아웃을 경계하십시오. 직장에서도 코딩하고 재미로도 코딩한다면, 양쪽 끝에서 촛불을 태우고 있는 셈입니다. 심지가 길다면 괜찮습니다. 다만 당신에게도 며칠쯤은 쉬는 날이 필요하다는 사실만은 인정하십시오. 당신은 짧은 단거리 경주를 하는 것이 아니라 커리어를 쌓아 가고 있습니다. 그리고 건강과 가족, 친구를 대가로 치른다면 커리어에서 뛰어난 성과를 거두는 것은 무의미할 수 있습니다.

여러분은 개발자이지만, 개발자 그 이상의 존재이기도 합니다. 사이드 프로젝트가 꼭 코드를 더 작성하는 일일 필요는 없습니다. 코드와 인접한 일일 수도 있고, 코드와 전혀 상관없는 일일 수도 있습니다. 그래도 앞서 열거한 이점 중 상당수를 여전히 누릴 수 있습니다.

37.3 프로젝트 아이디어

생각해 볼 만한 프로젝트 아이디어 몇 가지를 소개합니다:

• 자신만의 오픈 소스 라이브러리를 만드십시오. 위험 부담이 적기 때문에 개발자들이 흔히 선택하는 방법입니다. 하지만 보상도 적은 경우가 많습니다. 대개 보수를 받지 못하는 일이며 유지 보수 부담도 따릅니다. 하지만 커뮤니티에 기여하는 동시에 업무 생산성을 높이거나 컨퍼런스 및 네트워킹 기회를 얻는 데 도움이 될 수 있습니다. 기존 오픈 소스 앱을 클론하는 것도 방법이라는 점을 잊지 마십시오! (장 10)
• 지식을 오픈 소스하십시오. 자세한 내용은 장 13에서 확인하십시오!
• 지역 밋업/커뮤니티/비영리 단체에 기여하십시오. 여러분의 귀중한 기술은 다른 사람들이 필요로 하지만 직접 만들 수 없는 프로젝트를 돕는 데 요긴하게 쓰일 수 있습니다. 많은 개발자가 자기 밴드의 사이트를 만들면서 웹 개발을 시작했습니다. 누구에게나 사이트는 필요합니다!
• 포트폴리오나 블로그를 만드십시오. 포트폴리오나 블로그도 하나의 프로젝트입니다. 매년 조금씩 시간을 들여 온라인 프로필이 최신 기술과 관심사를 반영하도록 업데이트되어 있는지 확인하십시오. 자세한 내용은 자신을 마케팅하기(장 39)를 참고하십시오. 다른 형태의 콘텐츠도 흥미롭습니다. 팟캐스트, 뉴스레터, 라이브 스트리밍, YouTube 채널을 운영하는 것도 좋지만, 이런 활동은 더 많은 노력과 더 큰 헌신이 필요하다는 점을 알아 두십시오.
• 강의하기. 콘텐츠 제작으로 첫 수익을 내고 싶다면 Egghead, Frontend Masters, Pluralsight, LinkedIn Learning 같은 플랫폼보다 더 좋은 출발점은 없습니다. 이런 플랫폼은 첫 강의를 녹화하는 데 필요한 자원을 제공하고, 기존 사용자층에게 강의를 홍보해 주며, 결제도 처리해 줍니다. 여러분은 매력적인 콘텐츠를 만들기만 하면 됩니다.
• 책 쓰기. 특별히 모험을 해 보고 싶고 블로그나 다른 콘텐츠가 좋은 성과를 거두었다면, 첫 책을 써서 판매하는 일에 도전해 볼 수도 있습니다. 지금 여러분이 보고 계신 것이 바로 그런 사이드 프로젝트의 결과물입니다!
• 클로즈드 소스 사이드 허슬. 돈을 벌기 위해 앱을 만들고 운영할 수도 있습니다. 이는 기본적으로 본격적인 사이드 허슬이며, 반복 고객이 생기기 때문에 가장 높은 수준의 책임과 지원이 따릅니다. 아이디어를 얻으려면 Ideaswatch를 살펴보거나, 그냥 직장에서 해결할 문제를 찾아볼 수도 있습니다. Dylan Feltus는 자신의 회사에 기능 요청 추적 도구가 필요하다는 것을 알아차리고 NextPlease.io를 만들었으며, 이제는 그의 회사 CEO가 자랑스러운 고객이 되었습니다.

37.4 프로젝트 조언

작게 시작하고 잘게 나누십시오. 사람들이 사이드 프로젝트를 할 때 저지르는 가장 큰 실수는 너무 크게 시작하는 것입니다. 한 가지 일을 더 잘 해내는 무언가를 만들기보다는, 세상에서 보이는 100가지 문제를 모두 해결하는 거대한 프로젝트를 만들려고 합니다. 프로젝트 범위가 터무니없이 커지도록 내버려 두면, 결국 프로젝트를 끝낼 수 없게 됩니다. 이런 일을 너무 여러 번 반복하면, 여러분 자신이 문제라고, 즉 여러분이 프로젝트를 끝내지 못하는 유형의 사람이라고 생각하기 시작합니다. 그 지경에 이르지 않도록 하십시오. 야크 털 깎기를 경계하고 프로젝트의 범위를 철저하게 지키십시오. 여러분의 오픈 소스 라이브러리가 조금 형편없어도 괜찮습니다.

제약을 정하십시오. 스콧 영(Scott Young)은 MIT의 4년제 컴퓨터 과학 커리큘럼 전체를 하나도 빼먹지 않고 1년 만에 마치기로 결심했습니다. 다음은 그를 유명하게 만든 MIT 챌린지를 그가 어떻게 설명하는지입니다:

좋은 경험칙은 프로젝트에 적어도 세 가지 제약, 즉 범위, 내용, 사명이 있어야 한다는 것입니다. 범위란 프로젝트를 일정한 기간이나 명확하게 정의된 규모로만 제한하는 것을 뜻합니다. 내용이란 실제로 무엇을 할 것인지를 뜻합니다. 저는 MIT 챌린지에서 시험과 프로그래밍을 선택했지만, 다른 것(예를 들어 연구 프로젝트)을 선택할 수도 있었습니다. 사명이란 프로젝트가 무엇을 지향하는지를 좁게 정하는 것으로, 이렇게 하면 일이 커지기 시작할 때 더 쉽게 덜어 낼 수 있습니다.

그러한 유용한 제약 중 하나는 프로젝트가 새로운 제품을 출시하기 위한 것인지, 아니면 새로운 기술을 배우기 위한 것인지를 미리 정해 두는 것입니다. 둘 다 하려고 하지 마십시오. 시간 제한을 두고 이 프로젝트만을 위한 시간을 따로 내는 방법도 있습니다. Ben Orenstein은 사이드 프로젝트를 일주일짜리 짧은 “코드케이션(Codecation)” 기간에만 했고, 이를 통해 독립하여 자력으로 운영하는 스타트업을 창업할 기술과 자신감을 얻었습니다. 하지만 프로젝트를 이미 아는 것으로만 한정하지 마십시오. 필요할 때마다 그때그때 배워야 하는 상황을 연습해 보는 것도 좋습니다. 안전지대 안에만 머문다면 결코 진정으로 성장할 수 없습니다.

꾸준함과 추진력이 가장 중요합니다. 너무 오래 내버려 둔 프로젝트는 먼지가 쌓이고 결국 죽습니다. 일주일 동안 손대지 않은 프로젝트를 보며 다음 주에 다시 하겠다고 말하기는 쉽습니다. 그러다 한 달이 지납니다. 그러다 일 년이 지납니다. 어기지 않을 정기적인 약속을 정해 두면 이 프로젝트가 앞으로 나아가고 있다는 것을 스스로 확인할 수 있고, 다른 사람들도 그것을 볼 수 있어 계속 여러분을 응원해도 된다는 것을 알게 됩니다. 친구들이 근황을 물어볼 때 “어, 아직 별다른 진전이 없어”라는 어색한 대답 대신 긍정적인 소식을 전할 수 있을 것입니다.

종료일을 정하십시오. 끝없이 늘어지는 프로젝트는 미완성 상태라는 이유로 죄책감을 불러일으킵니다. 끝이 보이지 않으면 재미로 하는 일이라도 이상하게 의욕이 꺾일 수 있습니다. 매듭을 짓고 다음으로 넘어갈 수 있으면 책임감에서 벗어나 다음 일에 착수할 수 있습니다. “충분히 좋음”의 기준을 미리 정하고, 그 지점에 도달했을 때 범위가 늘어나지 않도록 하십시오.

프로젝트를 출시하고 마무리 짓게 만드는 훌륭한 “강제 장치” 중 하나는 가까운 시일 내에 열리는 밋업이나 다른 행사에서 라이브 데모나 발표를 하기로 약속하는 것입니다. 모든 사람이 이런 종류의 압박에 잘 반응하는 것은 아닙니다! 하지만 저처럼 만성적으로 일을 미루는 사람에게는 효과가 있습니다.

“마감은 고정, 범위는 협상 가능”은 제품 관리에서 가장 과소평가된 패턴임이 틀림없습니다. 이것이 바로 출시의 비결입니다. - Ryan Singer

여러 칸에 체크하기. 우선순위 정하기에 관한 Sarah Drasner의 시대를 초월한 글에서 그녀는 여러 목표를 한 번에 달성하는 데 도움이 되는지를 기준으로 프로젝트를 고르라고 권합니다. 커뮤니티, 멘토링, 돈, 개인적 성취감처럼 네 가지 관심 영역이 있다면, 그중 두 가지 이상이 겹치는 지점에 있는 프로젝트를 고를 때 투자한 시간 대비 더 큰 효과를 얻을 수 있습니다. 여러분이 사용할 수 있는 네 가지를 소개합니다:

• 프로젝트가 개인적으로 이익이 됩니다(돈, 인맥 등)
• 자신이 즐기거나 설렘을 느끼는 프로젝트입니다
• 프로젝트가 여러분이 사랑하는/아끼는 사람들에게 도움이 됩니다(더 넓은 커뮤니티일 수도 있습니다)
• 프로젝트에 이전 취미/관심사(예: 금융, 소설, 게임, 영화)에서 쌓은 제 도메인 지식이 녹아듭니다

제가 내린 최고의 프로젝트 선택들을 떠올려 보면, 저는 실패하더라도 이기는 것을 생각하는 편입니다. 즉, 저는 그 프로젝트가 끝난 뒤에도 그것을 뛰어넘어 지속될 수 있는 기술과 관계를 얼마나 쌓을 수 있는지를 기준으로 프로젝트를 고릅니다. - 팀 페리스

37.5 더 많은 영감

다음은 사람들이 실제로 완성해 내놓았고 여러분도 해 볼 수 있는, 인생을 바꾼 사이드 프로젝트들입니다:

• Jennifer Dewalt는 코딩을 배우면서 180일 동안 180개의 사이트를 만들어 공개했고, 지금은 YCombinator의 투자를 받은 스타트업의 기술 공동 창업자입니다.
• Jessica Hische는 2009년 9월부터 매일 하루에 드롭 캡 하나씩을 공개하며 디자인을 연습했습니다.
• Niklas Göke는 2016년부터 매일 책 요약을 하나씩 쓰며 엄청난 독자층을 쌓았습니다.
• 케이시 나이스탯(Casey Neistat)은 550일 동안 매일 브이로그를 올렸고 “인터넷에서 가장 유명한 셀럽 중 한 명”이 되었습니다.
• Kate Bingaman은 2006년부터 2014년까지 매일 자신이 구매한 물건을 그리며 일러스트레이션을 연습했습니다.
• Michelle Poler는 100일 동안 자신의 두려움에 맞서며 두려움을 극복하기로 결심했습니다. 이것이 그녀의 동기 부여 강연가 경력의 출발점이 되었습니다. Jia Jiang은 거절을 대상으로 같은 일을 했습니다.
• 메건 게브하트는 자신이 무엇을 하고 싶은지 정할 수 없었기에, 1년 동안 매주 다른 사람과 커피 한 잔을 마시기로 했습니다.
• Pieter Levels와 Shooting Unicorns 듀오는 모두 12개월 동안 12개의 프로젝트를 하기로 했지만, 둘 다 끝까지 완수하지는 못했습니다. 크게 성공한 프로젝트를 찾아 그것이 본업이 되었기 때문입니다.
• 이 책은 2020년 4월 10일부터 6월 1일까지 매일 2,000~4,000단어씩 써서 출간했습니다.

물론 Slack(실패한 MMORPG에서 파생됨)부터 Apple(한 Atari 직원의 사이드 프로젝트)에 이르기까지, 사이드 프로젝트에서 회사 전체가 탄생한 경우도 있습니다.