스포트라이트와 ‘교체 가능한 인력’ 논리에 휩쓸리지 않고, 장기적인 시스템 소유권과 엔지니어링 도구·인프라에 대한 책임감으로 커리어 임팩트를 쌓는 방법을 다룬 글입니다.
최근에 나는 스태프+ 엔지니어에 대한 Sean Goedecke의 에세이들을 읽고 있다. 그의 글(특히 Software engineering under the spotlight과 It’s Not Your Codebase)은 놀라울 만큼 날카롭고, 빅테크에 있는 누구에게나 아프게 익숙하게 느껴질 것이다.
겉으로 보면 나는 그가 묘사하는 틀에 딱 들어맞는다. 나는 구글의 Senior Staff 엔지니어다. 그런데도, 그의 글을 읽고 나면 알 수 없는 불편함이 계속 남았다. 처음에는 그걸 그냥 냉소 때문이라고 치부했다. 하지만 곰곰이 생각해 보니, 문제는 Sean의 글이 아니라 내가 읽는 방식에 있었다.
Sean은 비관적인 게 아니다. 그는 엔지니어가 대체 가능한 자산으로 취급되고, 우선순위가 분기마다 뒤집히는 세상에서 어떻게 살아남을지 정확하게 묘사하고 있다. 다만 내 일은 전혀 그런 모습이 아니다. 그리고 마음 깊은 곳에서는, 만약 내가 그런 환경에서, 혹은 그가 묘사한 방식대로 일하려 한다면 몇 달 안에 번아웃이 올 거라는 걸 알고 있다.
나는 대신 전혀 다른 길을 따라왔다. 스포트라이트가 아닌 시스템, **대체 가능성이 아닌 ‘지킴이(ste wardship, 주인의식 있는 장기 소유권)’**에 최적화하는 길이다.
우리가 다른 길을 걷게 된 근본적인 이유는, Sean과 내가 완전히 다른 세상, 완전히 다른 법칙이 지배하는 환경에서 일하고 있기 때문이다.
Sean의 이력서를 보면, 그는 주로 외부 고객을 대상으로 제품을 만드는 프로덕트 팀1에서 일해 온 것으로 보인다. 비즈니스 목표는 분기마다 피벗되고, 성공은 매출이나 MAU로 측정된다. 이런 환경에서는 “스포트라이트”에 최적화하는 것이 완전히 합리적이다. 빅테크 규모의 제품 개발은 VP·PM·UX 디자이너들이 각자의 강한 의견을 들고 모여 있는 복잡한 방과 같다. 성공하려면, 지금 임원들이 바로 보고 있는 것에 정확히 맞춰서, 매우 민첩하게 움직여야만 한다.
반면 나는 경력 내내 훨씬 뒤편에서, 개발자 도구와 인프라 팀에서 일해 왔다.
내 팀의 고객은 안드로이드, 크롬, 그리고 구글 전체에 있는 수천 명의 엔지니어들이다2. 구글 제품의 최종 사용자들은 우리가 존재한다는 사실조차 모른다. 우리의 초점은, 개발자들이 제품·성능 지표를 수집하고, 상세한 트레이스를 이용해 문제를 디버깅할 수 있는 도구를 제공하는 데 있다.
이 환경에서, 리더십과 우리의 관계는 전혀 다르다. 우리는 한 번도 “모두가 달려들고 싶어 하는 핫한 프로젝트”가 아니었다. 그래서 임원들이 우리와 일하고 싶어서 싸울 일도 없다. 사실, 우리 팀은 역사적으로 PM을 뽑는 데도 늘 어려움을 겪었다. 구글의 PM 커리어 레더는 화려한 외부 런칭을 장려하는데, 우리는 그런 식의 “승진 포트폴리오”를 제공해 줄 수 없다. 게다가 우리 피드백은 엔지니어들로부터 직접 온다. 그 중간에 PM이 끼면 번역 손실이 생기고, 촘촘하고 고대역폭의 피드백 루프가 느려진다.
이 모든 걸 합치면, 우리 팀은 철저히 “바텀업(bottom-up)”으로 운영된다는 뜻이 된다. 임원들이 “너희는 X를 해야 한다”고 내려보내는 게 아니라, 우리가 스스로 고객에게 가장 큰 임팩트를 줄 수 있는 일이 무엇인지 찾고, 그 기능과 도구들을 만든다. 임원들은 우리를 통해 보다 제품에 가까운 팀들에게 어떤 임팩트를 주고 있는지를 보면서, 우리가 실제로 중요한 문제를 풀고 있는지 검증하는 역할을 한다.
Sean이 묘사한 제품 환경에서는, 목표가 분기마다 바뀌고 기능이 실험적일 때가 많다. 그 속에서 속도(speed) 가 최고의 통화(currency)다. 출시하고, 반복하고, 시장이 변하기 전에 빨리 다음 것으로 넘어가야 한다. 하지만 인프라와 개발자 경험(DevEx)의 세계에서 통화는 맥락(context) 이다.
엔지니어를 대체 가능한 자산으로 다루면 이 맥락은 완전히 파괴된다. 새로운 시각을 얻을 수는 있겠지만, 시스템이 실제로 어떻게 깨지는지에 대한 암묵지(implicit knowledge)는 사라진다. 한 시스템에 장기적으로 머무르는 지킴이(steward) 역할은, 짧은 순환 배치로는 절대 얻을 수 없는 복리 수익을 연다.
첫 번째 복리 효과는 패턴 매칭을 통한 효율성이다. 한 도메인에 수년 동안 머무르면, 새로운 요청은 거의 항상 진짜로 “새로운” 게 아니다. 나는 단지 코드를 디버깅하는 게 아니라, 나의 도구와 수백 개의 다양한 엔지니어링 팀이 만나는 교차점을 디버깅하고 있다. 새로운 팀이 “독특한” 문제를 들고 오면, 종종 과거로 손을 뻗는다. “이 접근은 2021년에 Camera 팀이 시도했는데, 왜 실패했는지, 그리고 실제로 동작하는 아키텍처가 무엇인지 정확히 말해 줄 수 있어요.”
하지만 더 강력한 복리 효과는 시스템 차원의 혁신이다. 매년 팀을 옮기는 식이라면, 당신이 해결할 수 있는 문제는 지금 눈앞에 보이는 급성 버그들로 한정된다. 그런데 어떤 문제들은, 아주 긴 시간 축을 지나야 비로소 그 형태가 드러난다.
최근에 내가 주도한 Bigtrace 프로젝트가 그런 예다. 이 프로젝트는, 내가 문제의 전체 윤곽이 잡힐 때까지 충분히 오래 자리를 지켰기 때문에 등장할 수 있었던 해결책이다.
만약 내가 “대체 가능성에 최적화하라”는 조언을 따랐다면(즉, 2023년에 새로운 프로젝트를 좇아서 팀을 옮겼다면), Bigtrace는 존재하지 않았을 것이다.
대신, 나는 리서치 단계 한가운데서 팀을 떠났을 것이고, 후임자는 똑같은 “잡음” — 불평을 늘어놓는 엔지니어들의 목소리 — 을 들었을 것이다. 하지만 빠진 퍼즐 조각이 무엇인지 알아볼 수 있는 역사적 맥락이 없었기에, Bigtrace 같은 것을 만들어 내기는 훨씬 어려웠을 거라고 생각한다.
“스포트라이트”를 좇아야 한다는 주장 가운데 가장 달콤한 건, 그게 리소스와 임원진의 관심을 보장해 준다는 것이다. 하지만 그 관심은 양날의 검이다.
높은 가시성을 가진 프로젝트는 흔히 매우 불안정하다. 끊임없이 바뀌는 임원진의 취향, 정치적 줄다리기, 그리고 장기적인 품질을 단기 생존을 위해 희생해야 하는 상황에 자주 빠진다. 어떤 엔지니어에게는 이 혼돈을 헤쳐 나가는 과정이 짜릿한 놀이처럼 느껴질 수 있다. 하지만 시스템 안정성을 중시하는 사람에게는 함정처럼 느껴진다.
지킴이 역할(장기 소유권)의 장점은, 다른 종류의 자본을 만들어 낸다는 것이다. 바로 신뢰(trust) 다. 수년 동안 안정적인 도구를 제공해 오면, 스포트라이트가 제품을 위협할 때 그 유혹을 뿌리칠 수 있는 정치적 자본을 얻게 된다.
요즘 스포트라이트는 AI에 맞춰져 있다. 모든 팀이 AI를 넣으라는 압박을 받는다. 우리도 계속 질문을 받았다. “왜 Perfetto에 LLM을 붙이지 않나요?” 만약 내가 가시성에 최적화하고 있었다면, 답은 명확했을 것이다. LLM 래퍼를 만들고, 데모를 경영진에게 보여 주고, “우리는 AI-first입니다”라고 선언하면 된다. 내 커리어에는 손쉬운 승리다.
하지만 시스템의 지킴이로서 나는, Perfetto의 핵심 가치 중 하나가 정밀함(precision) 이라는 걸 알고 있다. 커널 개발자가 레이스 컨디션을 디버깅할 때 필요한 건 정확한 타임스탬프이지, 환각(hallucination)이 아니다. 사용자는 우리가 “X가 문제입니다”라고 말하면, 그게 실제 문제라는 걸 믿는다. 그리고 존재하지도 않는 버그를 일주일 동안 쫓아다니는 일을 하지 않아도 된다고 믿는다.
물론 이걸 지나치게 끌고 가면 안 된다. 회의론이 방해주의(obstructionism)로 변해서는 안 된다. AI에 대해서도, 내 입장은 “영원히 안 돼”가 아니라, “제대로 할 수 있을 때까지는 안 된다”에 가깝다3.
스포트라이트를 좇는 엔지니어라면 이런 접근을 놓쳐 버린 기회라고 볼 수도 있다. 나는 이것을, 우리 제품을 위대하게 만드는 요소 — 사용자 신뢰 — 를 지키는 일로 본다.
엔지니어들이 “스포트라이트”에서 벗어나는 것을 두려워하는 가장 흔한 이유는 커리어 정체에 대한 걱정이다. 논리는 이렇다. “구글 I/O에서 화려한 기능을 런칭하지도 않고, 내 일이 VP의 Top 5 리스트에 올라가 있지도 않은데, 어떻게 Staff+까지 승진하겠어?”
맞다. “임원진의 가시성”이라는 통화는 줄어든다. 하지만 인프라 세계에서는 그 대신, 못지않게 가치 있고 오히려 더 안정적인 두 가지 다른 통화를 얻게 된다.
프로덕트 조직에서는 보통 내 매니저의 매니저를 감동시켜야 한다. 인프라 조직에서는 내 고객들의 매니저들을 감동시켜야 한다.
나는 이를 그림자 위계(Shadow Hierarchy) 라고 부른다. 당신의 VP가 당신 코드의 세세한 부분을 이해할 필요는 없다. 대신, 다른 핵심 조직의 스태프+ 엔지니어들이 당신의 도구를 필요로 하게 만들어야 한다.
Pixel의 Senior Staff 엔지니어가 자기 VP에게 이렇게 말한다고 해 보자. “Perfetto 없이는 다음 Pixel 폰을 디버깅할 수 없습니다.” 이 한 문장은 엄청난 무게를 가진다. 그들의 리포팅 체인을 타고 위로 올라가, Director/VP 레벨에서 옆 조직으로 건너간 뒤, 다시 당신의 매니저 쪽으로 되돌아온다.
이런 종류의 옹호는 강력하다. 정치적이라기보다 기술적이기 때문이다. 그리고 포장하기가 어렵다. 중요한 시스템의 지킴이가 되었을 때, 당신의 승진 패킷에는 회사에서 가장 존경받는 엔지니어들이 남긴 이런 증언이 가득하게 된다. “이 사람의 일이 우리가 성공하는 걸 가능하게 했습니다.”
프로덕트 팀이 일일 활성 사용자 수나 매출 지표를 들여다보고 있을 때, 우리는 엔지니어링 건강(Engineering Health) 을 추적하는 다른 지표를 본다.
중요도(VIP 팀이 꼭 필요로 한다)와 유틸리티(실제로 버그가 고쳐진다)를 결합하면, 임원진의 재조직(reorg)에 거의 영향을 받지 않는 승진 사례가 된다.
“스태프 소프트웨어 엔지니어가 되는 길은 여러 가지”라는 생각은 내가 처음 한 게 아니다. Will Larson은 그의 책 Staff Engineer에서, 스태프+ 엔지니어를 네 가지 뚜렷한 아키타입으로 분류한다.
Sean이 묘사하는 건 Solver(해결사) 나 Right Hand(오른팔) 다. 이들은 임원진의 의지를 수행하는 에이전트로, 불이 난 곳에 투입되었다가 문제가 안정되면 떠나는 유형이다. 내가 이야기하는 건 Architect(아키텍트) 나 Tech Lead(테크 리드) 이다. 특정 도메인의 장기적인 소유권과 깊은 기술 맥락을 기반으로 정의되는 역할이다.
이미 이런 비판이 들리는 듯하다. “넌 그냥 운 좋게 그런 팀을 찾은 거야. 우리 대부분은 그런 사치를 누릴 수 없어.”
이 글 전체에 깔린 조언에는 두 가지 전제가 있다. 첫째, 내가 써 온 전략은 장기 인프라를 유지할 만큼 충분히 수익성이 나는 회사를 전제로 한다. 이런 경로는 보통 스타트업이나 초기 성장 단계 회사에는 존재하지 않는다. 이 글은 빅테크에 최적화된 전략이다.
둘째, 좋은 팀에 합류하는 데에는 분명 운이 따른다. 밖에서 팀과 회사의 문화가 어떤지 정확히 평가하는 건 매우 어렵다. 하지만 팀을 찾는 과정에 운이 작용했다고 해도, 거기에 거의 10년 동안 남아 있기로 한 건 선택이었다.
그리고 적어도 내 경험상, 우리 팀이 특별히 유니크한 것도 아니다. 안드로이드 안에서만 해도, 비슷한 팀을 다섯 개는 바로 떠올릴 수 있다4. 물론 Director가 바뀌거나 VP가 바뀌는 일은 가끔 있지만, 핵심 미션과 엔지니어링 팀은 안정적으로 유지됐다.
이런 팀들이 드물게 느껴지는 이유는, 존재하지 않아서가 아니라, 대부분 무시되기 때문이라고 생각한다. 화려한 제품 런칭처럼 빠르고 눈에 띄는 “승리”를 제공하지도 않고, “반짝이는 멋진 기능들”을 만들지도 않기 때문에, 경쟁자가 상대적으로 적다. “수십억 사용자에게 배포하는 경험”이나 “친구와 가족이 내가 만든 걸 쓰는 걸 보는 즐거움”으로 동기부여되는 사람이라면, 여기서는 그런 만족을 얻기 어렵다. 그게 이 세계에 들어올 때 지불해야 할 입장료다.
하지만 오래 가는 시스템을 만들고 싶고, 외부의 인정 대신 깊은 기술적 소유권을 선택할 의향이 있다면, 그저 커튼 뒤를 들추어 보기만 하면 된다.
테크 업계는 늘 빨리 움직이라고 말한다. 하지만 다른 길도 있다. 그 길에서는, 레버리지가 깊이, 인내, 그리고 다른 사람들이 서 있는 토대를 조용히 쌓아 올리는 만족감에서 나온다.
큰 회사에서 의미 있고 임팩트 있는 커리어를 만들기 위해 꼭 스포트라이트를 쫓을 필요는 없다. 때로는, 가장 야심 찬 선택이란 바로 그 자리에 머무르는 것, 깊이 파고드는 것, 그리고 오래 가는 무언가를 만드는 것이다. Bigtrace처럼, 한 문제 영역을 수년간 붙잡고 앉아 있을 만큼 오래 머물러, 마침내 그걸 제대로 이해하게 될 때 비로소 만들 수 있는 무언가를.
여기서 말하는 프로덕트 팀은 “프론트엔드 팀”을 뜻하는 게 아니다. 백엔드 엔지니어라고 해도, 여전히 최종 사용자에게 직접 서빙되는 무언가의 일부를 만들고 있다면 나는 그걸 프로덕트 팀이라고 부른다.↩︎
이것이 전부는 아니다. Perfetto는 오픈 소스이고, 우리도 외부 개발자들을 신경 쓴다. 다만 그게 우리가 월급을 받는 이유는 아니다. 회사의 관점에서 보면, 우리가 오픈 소스 버그를 고치는 데 쓰는 시간은 “낭비된” 시간이다. 그럼에도 우리가 그 일을 하는 건, 오픈 소스라는 미션을 믿기 때문이다. 이에 대해서는 최근 글인 On Perfetto, Open Source, and Company Priorities에서 더 자세히 이야기했다.↩︎
참고로 말하면, “Perfetto에 AI를 넣자”는 문제에 LLM이 최선의 해법이 아닐 수도 있다. 내 생각에, 뉴럴 네트워크 같은 “구식” 머신러닝 기법들만으로도 얻을 수 있는 가치가 굉장히 크다. 많은 트레이스 분석은 본질적으로 패턴 매칭 문제다. 이건 앞으로 1년 동안 더 깊이 탐구해 보고 싶은 주제다
Android Kernel, Android System Health, Android Runtime, Android Camera HAL, Android Bionic↩︎
이 글이 마음에 들었다면, 구독을 통해 매주 최근 글을 묶은 요약을 받아보거나, RSS를 통해 팔로우할 수 있다.
