지난 4년간 구글에서 소프트웨어 개발자로 일했다. 2월 1일에 회사를 그만뒀다. 크리스마스 선물을 사주지 않아서다.

뭐, 사실은 그보다 좀 더 복잡한 이야기다.

첫 2년

입사 2년이 지났을 때, 나는 구글을 정말 좋아했다.

매년 하는 직원 설문조사에서 5년 후에도 구글에 있을 것 같냐고 물었을 때, 답은 고민할 것도 없었다.

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

가장 최근 성과 평가 등급은 “Strongly Exceeds Expectations”였다. 이대로만 가면 곧 다음 레벨인 시니어 소프트웨어 엔지니어로 승진할 수 있었다. 얼마나 멋진 타이틀인가! 그 후로는 커리어 내내 “네, 저는 구글에서 시니어 소프트웨어 엔지니어였습니다”라고 말할 수 있을 것이다. 다들 감탄하겠지.

매니저도 승진이 머지않았다고 했다. 이미 시니어 레벨의 역량을 갖추고 있으며, 승진 심사를 통과할 만한 프로젝트 하나만 맡으면 된다고 했다.

매니저가 승진을 시켜주지 않는다고?

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

대신 승진 여부는 당신을 한 번도 본 적 없는 상위 레벨 엔지니어와 매니저들로 구성된 작은 위원회가 결정한다.

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

그러면 승진 위원회가 당신의 패킷을 다른 몇 명과 함께 검토하며 하루 종일 누가 승진하고 누가 탈락할지 결정한다.

입사 후 2년간의 허니문 기간 동안, 이 제도는 내게 아주 훌륭하게 들렸다. 당연히 내 운명은 한 번도 나를 만난 적 없는 신비로운 위원회의 손에 맡겨야지. 그러면 편애나 정치에 물들지 않고, 코드 품질과 현명한 엔지니어링 판단만으로 나를 알아봐 줄 테니까.

사실은 그렇게 돌아가지 않는다

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

내 머릿속에서 승진 위원회는 전지전능하고 공정한 존재였다. 매일 올바른 문제를 골라 해결하고, 코드베이스를 개선하고, 팀이 효율적으로 일하도록 도우면, 승진 위원회가 마법처럼 그걸 알아보고 보상해 줄 거라고 믿었다.

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

순진하게 일하던 시절

그때까지 내 주된 업무는 레거시 데이터 파이프라인이었다. 몇 년간 유지보수 모드로 방치되어 있었는데, 부하가 늘면서 한계에 부딪히고 있었다. 파이프라인은 자주 조용히 죽거나 잘못된 결과를 내보냈다. 원래 설계 문서 이후로는 문서가 전혀 없어서, 장애 원인을 파악하는 데만 며칠이 걸리곤 했다.

나는 그 파이프라인을 자랑스럽게, 애정을 담아 되살려냈다. 수십 개의 버그를 고치고 같은 문제가 재발하지 않도록 자동화된 테스트를 작성했다. 죽은 코드거나 최신 라이브러리로 대체할 수 있는 수천 줄의 코드를 삭제했다. 파이프라인을 이해하는 대로 문서로 남겨, 지식이 내 머릿속에만 갇히지 않고 팀원들과 공유되도록 했다.

그런데 승진 심사 때 알게 된 문제는, 이 모든 일이 수치로 증명되지 않는다는 것이었다. 내가 한 일이 구글에 긍정적인 영향을 줬다는 걸 증명할 방법이 없었다.

수치로 증명되지 않으면 한 일이 아니다

그 파이프라인은 제대로 된 지표를 거의 기록하지 않았다. 있는 지표마저도 상황이 더 나빠진 것처럼 보였다. 내가 버그를 찾아내면서 전체 버그 수는 오히려 늘어났다. 파이프라인 장애도 더 자주 발생한 것처럼 보였는데, 내가 잘못된 데이터를 조용히 흘려보내는 대신 이상이 생기면 바로 실패하도록 만들었기 때문이다. 개발자들이 장애를 복구하는 데 드는 시간을 크게 줄였지만, 개발자 시간을 추적하는 지표는 없었다.

다른 업무도 서류상으로는 별로 좋아 보이지 않았다. 여러 차례 동료의 출시가 위험해졌을 때 내 프로젝트를 몇 주, 심지어 몇 달씩 멈추고 도우러 갔다. 팀을 위해서는 옳은 결정이었지만, 승진 패킷에서는 별로 인상적이지 않았다. 승진 위원회 눈에 그 동료의 프로젝트는 여러 개발자의 협업이 필요한 크고 중요한 일이었다. 그들이 나를 꼬드겨 도움을 받았다면, 그건 그들의 뛰어난 리더십을 증명하는 것이고, 나는 하는 일이 하찮아서 언제든 미뤄둘 수 있는 단순한 잡무 담당 정도로 보일 뿐이었다.

첫 승진 패킷을 제출했고, 결과는 우려한 그대로였다. 승진 위원회는 내가 기술적 복잡성을 다룰 수 있다는 걸 증명하지 못했고, 구글에 미친 영향도 알 수 없다고 했다.

탈락에서 배운 것

탈락은 큰 타격이었지만, 낙담하지 않았다. 내 성과는 레벨에 비해 충분히 높다고 느꼈는데, 승진 위원회가 그걸 보지 못한 것뿐이었다. 해결할 수 있는 문제였다.

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

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

얼마 지나지 않아 승진에 안성맞춤인 프로젝트를 맡게 됐다. 머신러닝에 크게 의존하는 프로젝트였는데, 당시에도 지금도 구글에서 가장 핫한 분야였다. 수백 명의 작업자가 수동으로 하던 일을 자동화하는 프로젝트라 구글에 미치는 영향이 명확하고 객관적이었다. 게다가 프로젝트 전반에 걸쳐 주니어 개발자를 리드해야 해서 보통 승진 심사에서 가점을 받는 일이기도 했다.

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

몇 달 뒤, 구글이 오랫동안 이어온 전통인 직원들에게 주는 호화로운 크리스마스 선물을 중단하고, 그 예산으로 자선으로 포장된 광고 소외계층 학생들에게 줄 크롬북을 샀다는 뉴스가 헤드라인을 장식했다.

그 직후, 나는 두 직원이 나누는 대화를 들었다.

직원 A: 사실상 여전히 선물을 받는 거나 마찬가지야. 이런 비용 절감은 구글 주가를 올리잖아. 스톡 그랜트를 팔아서 원하는 선물을 사면 되지.

직원 B: 내가 아내에게 크리스마스 선물을 안 사줄 테니 통장에 있는 돈으로 원하는 거 사라고 하면 어떨 것 같아?

직원 A: 너와 구글은 비즈니스 관계야. 구글이 아내한테 하듯 선물을 주며 “애정 공세”를 하지 않는다고 서운해한다면, 관계를 잘못 이해하고 있는 거지.

잠깐. 나도 구글과 비즈니스 관계에 있었지.

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

그 대화를 듣고 나는 내가 구글이 아니라는 걸 깨달았다. 나는 구글에 서비스를 제공하고 그 대가로 돈을 받는 것이다.

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

승진에 최적화하기

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

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

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

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

우선순위가 바뀌었다. 경영진은 내 프로젝트를 인도의 자매 팀에 넘겼다. 대신 그 팀의 프로젝트 하나를 우리에게 넘겼다. 문서도 없고 지원이 중단된 인프라 위에 만들어진 시스템이었지만, 여전히 프로덕션에서 핵심적인 컴포넌트였다. 나는 그 시스템을 자매 팀 코드와 분리해 새로운 프레임워크로 옮기면서, 프로덕션에서 계속 돌리고 성능 지표도 맞춰야 했다.

승진만 놓고 보면 몇 달을 뒤로 밀린 셈이었다. 취소된 프로젝트에서는 아무것도 출시하지 못했으니, 쏟아부은 두 달이 허사가 됐다. 새로 맡은 시스템을 파악하는 데만 몇 주가 걸릴 것이고, 운영을 유지하는 잡무에 몇 주를 더 잃을 수도 있었다.

나는 대체 뭘 하고 있는 걸까?

6개월 만에 세 번째로 매니저가 프로젝트 도중에 내 담당을 바꿨다. 그때마다 그는 내 업무 성과와는 무관하며, 상위 경영진의 전략이나 팀 인력 변화 때문이라고 했다.

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

구글은 프로젝트를 완수한 걸 봐야 내 일을 평가할 수 있다고 계속 말했다. 그런데 정작 구글 때문에 프로젝트를 중간에 끊기고 새로운 일을 배정받으니, 나는 어떤 프로젝트도 끝낼 수가 없었다.

이 구도는 너무나 부조리하게 느껴졌다.

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

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

설령 승진한다고 해도 그다음은 어떨까? 통념상 승진은 한 번 할 때마다 기하급수적으로 어려워진다. 커리어를 계속 발전시키려면 더 큰 규모의, 더 많은 협업 팀이 얽힌 프로젝트가 필요했다. 하지만 그건 내 통제 밖의 요인으로 프로젝트가 실패할 가능성이 더 커지고, 내 인생의 몇 달, 몇 년을 허비할 수 있다는 뜻이기도 했다.

대안은 없을까?

그 무렵 Indie Hackers를 알게 됐다.

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

나는 원래 내 소프트웨어 회사를 차리는 데 관심이 있었지만, 실리콘밸리식 스타트업 경로밖에 몰랐다. 소프트웨어 창업자라면 대부분의 시간을 자금 조달에 쓰고, 남은 시간은 다음 백만 명의 사용자를 어떻게 끌어올지 걱정하는 일이라고 생각했다.

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일): 솔로 개발자로 보낸 첫 해
• 업데이트 (2020년 1월 31일): 솔로 개발자로 보낸 두 번째 해
• 업데이트 (2021년 2월 1일): 솔로 개발자로 보낸 세 번째 해
• 업데이트 (2022년 2월 1일): 부트스트랩 창업자로 보낸 네 번째 해
• 업데이트 (2023년 2월 10일): 부트스트랩 창업자로 보낸 다섯 번째 해
• 업데이트 (2024년 2월 10일): 부트스트랩 창업자로 보낸 여섯 번째 해

일러스트: Loraine Yow.