지난 4년간 구글에서 소프트웨어 개발자로 일했다. 2월 1일, 퇴사했다. 크리스마스 선물을 사주지 않았기 때문이다.

물론, 사실은 그보다 조금 더 복잡하다.

처음 2년

입사 2년 차, 나는 구글이 정말 좋았다.

연례 직원 설문조사에서 5년 후에도 구글에 있을 것 같냐고 물었을 때, 고민할 필요도 없었다.

당연히 5년 후에도 구글에 있을 거라고 생각했다. 세계 최고의 엔지니어들에 둘러싸여, 세계에서 가장 앞선 개발 도구를 쓰며, 세상에서 가장 공짜인 음식을 먹고 있었으니까.

가장 최근에 받은 성과 평가는 “기대를 크게 상회(Strongly Exceeds Expectations)”였다. 이대로만 가면 곧 다음 단계인 시니어 소프트웨어 엔지니어로 승진할 수 있었다. 얼마나 멋진 타이틀인가! 앞으로 커리어 내내 이렇게 말할 수 있을 것 같았다. “네, 저는 시니어 소프트웨어 엔지니어였습니다. 그것도 구글에서요.” 사람들은 분명 감탄할 터였다.

매니저는 승진이 멀지 않았다고 확신시켜 줬다. 나는 이미 시니어 레벨의 역량을 갖췄고, 승진 위원회에 그것을 증명할 적절한 프로젝트만 있으면 된다고 했다.

매니저가 승진을 결정하지 않는다고?

그렇다. 구글에서 매니저는 자기 팀원을 승진시킬 수 없다. 투표권조차 없다.

대신 승진 결정은 상위 레벨의 소프트웨어 엔지니어와 매니저로 구성된 소규모 위원회가 내린다. 당신의 승진을 결정하는 그날 처음 당신의 이름을 들어보는 사람들이다.

승진을 신청하려면 ‘승진 패킷(promo packet)’을 만들어야 한다. 동료들의 추천서, 자신이 작성한 설계 문서, 그리고 왜 자신의 성과가 승진할 만한지를 설명하는 짧은 에세이들을 모은 것이다.

승진 위원회는 당신의 패킷을 다른 몇 명의 패킷과 함께 검토하고, 하루를 꼬박 써서 누가 승진하고 누가 탈락할지를 결정한다.

입사 후 2년간의 허니문 기간에는 이 시스템이 훌륭하게 들렸다. 당연히 내 운명은 한 번도 만난 적 없는 신비한 위원회의 손에 맡겨져야 한다고 생각했다. 그들은 편애나 정치에 물들지 않을 것이고, 그런 것을 뛰어넘어 나의 고품질 코드와 날카로운 엔지니어링 결정을 알아봐 줄 거라고 믿었다.

현실은 그렇지 않다

첫 승진 패킷을 만들기 전까지는 이 과정이 실제로 어떻게 굴러가는지 깊이 생각해 본 적이 없었다.

내 머릿속에서 승진 위원회는 전지전능하고 공정한 존재였다. 매일 옳은 문제를 골라 해결하고, 코드베이스를 개선하며, 팀이 효율적으로 일하도록 돕기만 하면 위원회가 마법처럼 그것을 알아채고 보상해 줄 거라고 생각했다.

놀랍지 않게도, 현실은 그렇게 돌아가지 않는다. 그 사실을 깨닫는 데 2년이 걸렸다.

순진하게 일하던 시절

그때까지 나의 주된 업무는 레거시 데이터 파이프라인이었다. 수년간 유지보수 모드로 방치되어 있었는데, 부하가 늘면서 파이프라인이 버티지 못하고 있었다. 조용히 죽어버리거나 잘못된 결과를 내놓는 일이 잦았고, 최초 설계 문서 이후 제대로 된 문서가 없어 장애 원인을 파악하는 데만 며칠이 걸리곤 했다.

나는 자부심을 가지고 애정을 담아 파이프라인을 되살렸다. 수십 개의 버그를 고치고 재발을 막기 위해 자동화된 테스트를 작성했다. 죽은 코드거나 최신 라이브러리로 대체할 수 있는 코드 수천 줄을 삭제했다. 파이프라인을 파악하는 대로 문서화해서, 지식이 내 머릿속에만 고립되지 않고 팀원 모두가 공유할 수 있게 했다.

문제는, 승진 시점이 되어서야 알게 됐지만, 이 모든 일이 수치로 증명되지 않았다는 점이었다. 내가 한 일이 구글에 긍정적인 영향을 줬다는 걸 증명할 방법이 없었다.

지표가 없으면 한 일도 없는 셈이다

파이프라인은 기록하는 지표 자체가 많지 않았고, 있던 지표마저 상황이 악화된 것처럼 보이게 했다. 내가 버그를 찾아내면서 전체 버그 수는 오히려 늘어났다. 파이프라인 실패 횟수도 늘었는데, 잘못된 데이터를 조용히 흘려보내던 기존 방식 대신 이상 징후가 있으면 즉시 실패하도록 바꿨기 때문이다. 장애를 복구하는 데 드는 개발자 시간은 대폭 줄였지만, 개발자 시간을 측정하는 지표는 없었다.

다른 업무들도 서류상으로는 별로 인상적이지 않았다. 몇 차례나 내 프로젝트를 몇 주, 심지어 몇 달씩 미뤄두고 출시가 위태로운 동료를 도왔다. 팀을 위해서는 옳은 결정이었지만, 승진 패킷에서는 초라해 보였다. 승진 위원회의 눈에 동료의 프로젝트는 여러 개발자의 협업을 필요로 하는 크고 중요한 일이었다. 그 동료가 나를 꾀어 도움을 받았다면, 그건 그의 뛰어난 리더십을 증명하는 사례가 된다. 나는 하는 일이 하찮아서 언제든 미뤄둘 수 있는, 생각 없는 졸개에 불과했다.

첫 승진 패킷을 제출했고, 결과는 우려했던 그대로였다. 승진 위원회는 내가 기술적 복잡성을 다룰 수 있다는 것을 증명하지 못했으며, 구글에 어떤 임팩트를 줬는지 알 수 없다고 했다.

탈락에서 배운 것

탈락은 뼈아픈 타격이었지만, 낙담하지는 않았다. 나는 이미 레벨 이상의 성과를 내고 있다고 느꼈고, 승진 위원회가 그걸 보지 못했을 뿐이라고 생각했다. 해결 가능한 문제였다.

처음 2년간은 너무 순진했다고 결론 내렸다. 내가 하는 일이 기록으로 남도록 사전에 충분히 계획하지 않았던 것이다. 이제 프로세스를 이해했으니, 같은 좋은 일을 하되 기록을 더 잘 남기면 된다고 생각했다.

예를 들어, 팀은 오탐으로 인한 이메일 알림에 시달리고 있었다. 예전의 나라면 그냥 알림을 고쳤을 것이다. 하지만 이제는 이 일이 승진 패킷에 드러나려면 먼저 지표를 세팅해 알림 빈도에 대한 과거 기록을 남겨야 한다는 걸 알았다. 승진 심사 때면 알림이 감소하는 인상적인 그래프를 보여줄 수 있을 테니까.

얼마 지나지 않아 승진을 위한 프로젝트처럼 보이는 일을 맡게 됐다. 당시에도 지금도 구글에서 가장 뜨거운 분야인 머신러닝에 크게 의존하는 프로젝트였다. 수백 명의 작업자가 수작업으로 하던 일을 자동화하는 것이어서 구글에 미치는 임팩트가 명확하고 객관적이었다. 게다가 프로젝트 전반에 걸쳐 주니어 개발자를 이끌어야 했는데, 이는 보통 승진 위원회에서 좋은 점수를 받는 요소였다.

크리스마스 선물로 정신이 번쩍 들다

몇 달 뒤, 구글은 전 직원에게 호화로운 연말 선물을 주던 오랜 전통을 중단하며 화제가 됐다. 대신 그 예산으로 자선으로 포장한 광고 소외계층 학생들을 위한 크롬북을 샀다.

얼마 지나지 않아 두 직원 사이의 이런 대화를 목격했다.

직원 A: 당신은 사실상 여전히 선물을 받고 있는 셈이에요. 이런 비용 절감은 구글 주가 가치를 올리니까요. 받은 주식 보조금을 팔아서 원하는 선물을 사면 되죠.

직원 B: 아내에게 크리스마스 선물을 안 사주는 대신, 통장 잔액으로 원하는 걸 사라고 하면 어떨까요?

직원 A: 당신은 구글과 비즈니스 관계예요. 아내에게 하듯 구글이 선물로 당신을 “설레게” 해주길 기대한다면 관계를 잘못 이해하고 있는 거예요.

잠깐. 나도 구글과 비즈니스 관계에 있는 거였다.

2년 반이 지나서야 이걸 깨달았다는 게 이상하게 들릴지도 모르지만, 구글은 조직 내에 공동체 의식을 만드는 데 아주 능숙하다. 우리가 단순한 직원이 아니라 구글 그 자체라고 느끼게 만든다.

그 대화 덕분에 나는 구글이 아니라는 걸 깨달았다. 나는 구글에 서비스를 제공하고 그 대가로 돈을 받는 사람일 뿐이다.

그렇다면 구글과 나의 관계가 서로의 이익을 위해 존재하는 비즈니스 관계라면, 왜 나는 내 이익이 아니라 구글의 이익만을 위한 일들에 시간을 쓰고 있었던 걸까? 승진 위원회가 버그 수정이나 팀 지원 업무에 보상을 주지 않는데, 왜 나는 그런 일을 하고 있었던 걸까?

승진에 최적화하기

첫 승진 탈락은 내게 잘못된 교훈을 줬다. 같은 일을 계속하되 승진 위원회 눈에 잘 보이도록 포장하면 된다고 생각했다. 정반대로 해야 했다. 승진 위원회가 원하는 것이 뭔지 파악하고, 그 일만 해야 했던 것이다.

나는 새로운 전략을 세웠다. 어떤 일을 시작하기 전에 그 일이 승진에 도움이 될지 스스로에게 물었다. 답이 ‘아니오’라면 하지 않았다.

코드에 대한 기준도 “이 코드를 향후 5년간 유지보수할 수 있을까?”에서 “승진할 때까지만 버티면 될까?”로 낮아졌다. 프로젝트 출시를 위협하는 버그가 아니면 등록하지도, 고치지도 않았다. 유지보수 업무에서는 어떻게든 빠져나왔다. 캠퍼스 리크루팅 행사 자원봉사도 그만뒀고, 주 1~2회 하던 면접도 아예 하지 않게 됐다.

그러다 프로젝트가 취소됐다

우선순위가 바뀌었다. 경영진은 내 프로젝트를 인도의 자매 팀에 넘겼다. 대신 그 팀의 프로젝트 하나를 우리가 맡게 됐다. 문서 하나 없는 시스템이었고, 지원이 중단된 인프라 위에 만들어졌지만, 그럼에도 프로덕션에서 핵심적인 컴포넌트였다. 나는 자매 팀 코드와 얽힌 부분을 풀어내고, 프로덕션에서 계속 돌리면서 성능 지표를 맞추는 동시에 새로운 프레임워크로 마이그레이션하는 일을 맡았다.

승진 관점에서 보면 이는 몇 달의 후퇴였다. 취소된 프로젝트에서는 아무것도 릴리스하지 못했기 때문에 두 달간의 작업이 무의미해졌다. 새로 맡은 시스템을 파악하는 데만 몇 주가 걸릴 것이고, 운영을 유지하는 단순 작업에 또 몇 주를 더 잃을 가능성이 컸다.

나는 지금 뭘 하고 있는 걸까?

6개월 만에 세 번째로 매니저가 프로젝트 중간에 나를 다른 일로 재배치한 것이었다. 매번 그는 내 업무 성과와는 무관하며, 상위 경영진의 전략이나 팀 인력 변화 때문이라고 설명했다.

이때 나는 한 걸음 물러서서 상황을 큰 그림에서 바라봤다. 매니저도, 그 위의 매니저도, 승진 위원회도 잊자. 나와 구글, 단 둘로만 단순화하면 어떨까? 우리의 “비즈니스 관계”에서는 무슨 일이 벌어지고 있었던 걸까?

구글은 프로젝트를 완수하는 걸 보기 전까지는 내 업무를 평가할 수 없다고 계속 말하고 있었다. 한편 나는 구글이 자꾸 프로젝트를 중간에 끊고 새로운 일을 배정하는 바람에 어떤 프로젝트도 끝낼 수 없는 상황이었다.

이 구도는 터무니없게 느껴졌다.

내 커리어는 인생에서 단 한 시간 나를 생각하는, 계속 바뀌는 익명의 위원회에 의해 좌우되고 있었다. 내가 전혀 관여할 수 없는 경영진의 결정이 수개월간의 커리어 진전을 순식간에 지워버리고 있었다.

무엇보다 최악인 건, 내 일에 자부심을 느끼지 못한다는 점이었다. “이 어려운 문제를 어떻게 해결할까?”가 아니라 “이 문제를 승진을 위해 어떻게 어려워 보이게 만들까?”를 고민하고 있었다. 그게 너무 싫었다.

설령 승진을 한다 해도 그다음은 어떨까? 통념에 따르면 승진은 할수록 기하급수적으로 어려워진다. 커리어를 계속 발전시키려면 규모가 더 크고 더 많은 파트너 팀과의 협업이 필요한 프로젝트를 맡아야 한다. 하지만 그건 곧 내 통제 밖의 요인으로 프로젝트가 실패할 가능성이 더 커지고, 내 인생의 수개월, 수년이 허비될 수 있다는 뜻이기도 했다.

대안은 없을까?

이 무렵 나는 Indie Hackers를 알게 됐다.

소규모 소프트웨어 비즈니스의 창업자들을 위한 온라인 커뮤니티다. ‘소규모’에 방점이 있다. 이들은 제2의 저커버그를 꿈꾸는 사람들이 아니라, 생계를 유지할 만큼 적당하고 수익성 있는 비즈니스를 만들고 싶어 하는 사람들이었다.

나는 항상 내 소프트웨어 회사를 차리는 데 관심이 있었지만, 실리콘밸리식 스타트업 경로밖에 몰랐다. 소프트웨어 창업자란 대부분의 시간을 투자 유치에 쓰고, 남은 시간은 다음 100만 사용자를 어떻게 끌어모을지 걱정하는 사람이라고 생각했다.

Indie Hackers는 매력적인 대안을 제시했다. 대부분의 멤버는 자비로, 혹은 본업과 병행하는 사이드 프로젝트로 비즈니스를 만들었다. 투자자에게 보고할 필요도 없었고, 익명의 위원회 앞에서 자신을 증명할 필요도 없었다.

물론 단점도 있었다. 수입은 덜 안정적이고, 파국적인 리스크도 더 많았다. 구글에서 내가 1,000만 달러의 손실을 초래하는 실수를 저질러도 아무런 불이익이 없었을 것이다. 포스트모템을 작성하라는 요청을 받고, 모두가 배움의 기회라며 축하해 줬을 것이다. 하지만 이들 창업자 대부분에게 1,000만 달러짜리 실수는 비즈니스의 끝이자 평생 갚아야 할 빚을 의미했다.

Indie Hackers의 창업자들이 나를 사로잡은 이유는 그들이 주도권을 쥐고 있었기 때문이다. 비즈니스가 대박이 나든 수년간 정체되든, 결정은 그들이 내렸다. 구글에서는 내 프로젝트는 물론이고, 커리어 성장이나 팀의 방향조차 내가 통제하고 있다는 느낌이 들지 않았다.

몇 달간 고민한 끝에 마침내 결심했다. Indie Hacker가 되기로.

떠나기 전 마지막 한 가지

구글에서 아직 매듭짓지 못한 일이 남아 있었다. 3년을 승진에 투자했는데 아무 성과 없이 떠나는 건 싫었다. 재신청까지 몇 달밖에 남지 않았기에 마지막으로 한 번 더 도전해 보기로 했다.

성과 평가 기간이 끝나기 6주 전, 내 프로젝트가 또 취소됐다.

정확히는 팀 전체가 취소된 것이었다. 구글에서는 이런 일이 흔해 이를 일컫는 완곡한 표현까지 있었다. ‘디프래그(defrag)’였다. 경영진은 우리 팀의 프로젝트들을 인도의 자매 팀으로 이관했고, 팀원 모두 회사 내 다른 영역에서 다시 시작해야 했다.

그래도 승진을 신청했다. 몇 주 뒤 매니저가 결과를 알려줬다. 성과 평가는 최고 등급인 “Superb”였다. 매 사이클마다 약 5%의 직원에게만 주어지는 점수였다. 승진 위원회는 지난 6개월간 내가 분명히 시니어 레벨의 업무를 보여줬다고 언급했다. 공교롭지 않게도, 그 6개월은 내가 승진에 최적화해 일하던 기간이었다.

하지만 6개월은 충분한 기간이 아니라고 판단했으니… 다음 기회에.

매니저는 같은 수준의 성과를 6개월만 더 유지하면 승진 가능성이 높다고 했다. 유혹되지 않았다고 하면 거짓말이지만, 그 시점에서 나는 지난 2년간 “6개월 후면 승진 가능성이 높다”는 말을 계속 들어오고 있었다.

떠날 때가 됐다.

앞으로의 계획은?

구글을 그만뒀다고 하면 사람들은 내가 뭔가 기발한 스타트업 아이디어가 있어서 그런 줄 안다. 구글 소프트웨어 엔지니어처럼 편한 직장을 그만두는 건 바보나 하는 짓이니까.

하지만 나는 정말 아이디어 하나 없는 바보다.

내 계획은 몇 달씩 여러 프로젝트를 시도해 보면서 뭔가 가능성이 보이는 게 있는지 찾아보는 것이다. 예를 들면 다음과 같다.

• KetoHub를 계속 다듬어 수익화할 수 있는지 시험해 보기
• 내가 자주 글을 써온 분산 스토리지 기술인 Sia를 기반으로 비즈니스 만들기
• 글쓰기에 더 많은 시간을 투자하고, 이를 통해 수익을 낼 방법 찾기

구글은 일하기 좋은 곳이었고, 그곳에서 귀중한 기술들을 많이 배웠다. 아직 배울 것이 더 많아 떠나는 것이 쉽지 않았지만, 구글 같은 회사는 언제든 다시 있을 것이다. 하지만 내 회사를 시작할 자유가 언제나 주어지는 것은 아니기에, 이 길이 나를 어디로 데려갈지 기대된다.

업데이트

• 업데이트 (2019년 2월 1일): 1인 개발자로 보낸 첫 1년
• 업데이트 (2020년 1월 31일): 1인 개발자로 보낸 두 번째 해
• 업데이트 (2021년 2월 1일): 1인 개발자로 보낸 세 번째 해
• 업데이트 (2022년 2월 1일): 부트스트랩 창업자로 보낸 네 번째 해
• 업데이트 (2023년 2월 10일): 부트스트랩 창업자로 보낸 다섯 번째 해
• 업데이트 (2024년 2월 10일): 부트스트랩 창업자로 보낸 여섯 번째 해

일러스트: Loraine Yow