▲

나는 스포트라이트를 무시하는 스태프 엔지니어다

 (lalitm.com)
1P by GN⁺ 5일전 | ★ favorite | 댓글 1개
  • 대형 기술기업의 제품 중심 문화가 단기성과와 가시성을 중시하는 반면, 인프라·개발자 도구 분야에서는 지속성과 시스템 관리가 핵심 가치로 작동함
  • 글쓴이는 구글에서 개발자 도구와 인프라 팀에 속해 있으며, 경영진의 주목보다 엔지니어 고객의 신뢰와 효율성을 우선시함
  • 장기적인 시스템 관리(stewardship) 를 통해 축적된 맥락과 경험이 Bigtrace 같은 대규모 프로젝트의 혁신으로 이어짐
  • 단기적 주목을 좇는 대신 신뢰와 기술적 영향력을 자산으로 삼아, 필요할 때 “아니오”라고 말할 수 있는 정치적 자본을 확보함
  • 기술 산업의 빠른 순환 속에서도, 깊이와 지속성에 기반한 커리어 경로가 존재하며 이는 장기적 영향력을 창출하는 대안적 모델임

서로 다른 세계에서의 엔지니어링

  • 제품 팀은 외부 고객을 대상으로 하며 매출·활성 사용자 수(MAU) 등 단기 지표로 성과를 평가
    • 이 환경에서는 경영진의 관심을 받기 위해 민첩성과 가시성(spotlight) 이 필수
  • 반면 인프라·개발자 도구 팀은 내부 엔지니어를 고객으로 삼고, 제품의 성능·디버깅을 지원하는 도구와 시스템을 구축
    • 경영진의 관심이 적고, PM 채용이 어려운 구조로 인해 엔지니어 중심의 하향식이 아닌 상향식(bottom-up) 운영 형태
    • 팀은 스스로 가장 큰 영향을 줄 수 있는 문제를 정의하고 해결하며, 경영진은 그 영향도를 검증하는 역할

관리(stewardship)의 복리 효과

  • 제품 환경에서는 속도가 핵심 통화이지만, 인프라 환경에서는 맥락(context) 이 핵심 자산
    • 엔지니어를 교체 가능한 자원으로 취급하면 맥락이 사라지고, 시스템의 암묵지 손실 발생
  • 장기적 관리가 가져오는 첫 번째 이익은 패턴 인식을 통한 효율성
    • 오랜 기간 한 도메인에 머물면 새로운 요청이 과거 사례와 연결되어 빠른 문제 해결 가능
  • 두 번째 이익은 시스템적 혁신
    • 장기 관찰을 통해서만 드러나는 문제를 해결할 수 있으며, 그 결과물이 Bigtrace
      • 2023년 초, 구글 내 여러 팀이 성능 추적 데이터(테라바이트~페타바이트 규모) 를 처리하지 못하는 문제를 관찰
      • 1년간 프로토타입 연구와 피드백 수집을 거쳐 2024년 초 Bigtrace 구축
      • 현재 월 20억 건 이상의 트레이스를 처리하며 100명 이상의 엔지니어가 사용
    • 만약 단기 프로젝트 이동을 선택했다면 Bigtrace는 존재하지 않았을 것

“아니오”의 힘

  • 가시성 높은 프로젝트는 자원과 주목을 얻지만, 동시에 정치적 변동성과 품질 저하 위험을 동반
  • 장기적 관리로 쌓은 신뢰 자본은 스포트라이트의 유혹을 거절할 수 있는 힘 제공
    • 예: AI 열풍 속에서도 Perfetto에 LLM을 통합하라는 요구를 받았으나, 정확성(precision) 을 핵심 가치로 삼아 신중히 대응
    • 커널 디버깅 등에서는 정확한 타임스탬프가 필수이며, 환각(hallucination)을 허용할 수 없음
    • 단, “영원한 거절”이 아니라 “올바르게 구현될 때까지 보류”의 태도 유지

영향력의 대체 통화

  • 스포트라이트를 벗어나면 경영진 가시성은 줄지만, 기술적 신뢰와 효용성이라는 다른 통화 획득
  • Shadow Hierarchy(그림자 위계)
    • 인프라 조직에서는 자신의 상사보다 고객 조직의 상사에게 인정받는 것이 중요
    • 예: Pixel 팀이 “Perfetto 없이는 디버깅 불가”라고 말하면, 그 영향이 경영진 라인을 타고 전달
    • 이는 정치가 아닌 기술적 신뢰 기반의 옹호로, 승진 평가에서도 강력한 증거로 작용
  • Utility Ledger(효용 장부)
    • Utility: 버그 수정 시 도구가 사용되면 순수한 효용성 입증
    • Criticality: 주요 제품 팀의 성공과 직접 연결
    • Ubiquity: 여러 조직이 동일한 트레이스를 공유하며 협업
    • Scale: 페타바이트급 데이터 처리로 아키텍처의 견고함 증명
    • 이러한 지표 결합은 조직 개편에도 흔들리지 않는 지속적 영향력 확보

스태프 엔지니어의 유형과 선택

  • Will Larson의 『Staff Engineer』에 따르면 스태프 엔지니어는 Solver/Right Hand와 Architect/Tech Lead 등 여러 유형 존재
    • 전자는 경영진의 의지를 실행하는 문제 해결자, 후자는 특정 도메인의 장기적 소유자
  • 글쓴이는 후자에 속하며, 깊은 기술 맥락과 장기적 책임을 중시
  • 이 접근은 수익성 있는 대기업 환경에서만 가능한 경우가 많으며, 운과 선택이 모두 작용
    • 좋은 팀을 만나는 것은 운이지만, 오랜 기간 머무르며 관리자로 성장하는 것은 선택
    • 이런 팀들은 외부에서 주목받지 않지만, 지속적 미션과 안정된 엔지니어링 문화를 유지

결론

  • 기술 산업은 “빠르게 움직이라”는 구호를 강조하지만, 깊이와 인내의 경로도 존재
  • 스포트라이트를 좇지 않아도 의미 있고 영향력 있는 커리어를 구축 가능
  • 오랜 시간 문제 공간에 머물며 지속 가능한 시스템을 만드는 것이야말로 가장 야심찬 선택임
▲
GN⁺ 5일전  [-]
Hacker News 의견

  • 25년 넘게 일하면서 배운 건, 자신의 이야기와 성과를 직접 소유하지 않으면 누군가가 대신 가져간다는 점임
    특히 대기업에서는 인기가 많은 사람이 공을 가로채는 경우가 많음
    굳이 스포트라이트를 받을 필요는 없지만, 기록을 남기는 것이 중요함
    내부 문서나 외부 발표를 통해 자신의 기여를 명확히 남겨야 함

    • 이런 일은 미국 기업뿐 아니라 모든 조직에서 비슷하게 일어남
      인기가 없으면 야구팀에서도 벤치에 앉게 되고, 대학원 입학이나 ML 커뮤니티에서도 마찬가지임
      세상은 일종의 인기 경쟁 시스템처럼 돌아감
    • 이런 정치적인 구조 때문에 나는 회사 생활에서 벗어나려 함
      단순히 일하고 보상받는 구조가 아니라 자기 홍보가 필수라면, 차라리 내 일을 직접 소유하고 통제하는 게 낫다고 생각함
    • 하지만 모든 커리어가 스포트라이트 프로젝트로 만들어지는 건 아님
      나는 회사 내에서 신뢰가 가장 중요한 통화라고 생각함
      오랜 시간 여러 성공적인 프로젝트에 관여하면 결국 리더십이 그 공통점을 알아봄
      승진은 느리지만, 평판과 네트워크가 쌓이면서 안정적인 성장으로 이어짐
    • FAANG에서는 일정 단계 이후 ‘rest & vest’ 상태가 되면 이런 문제를 신경 쓰지 않게 됨
      이미 충분히 벌었기 때문에 크레딧에 관심이 없음
    • 나도 몇 번은 실력보다 좋은 관계 덕분에 기회를 얻었고, 반대로 관계가 나빠서 손해 본 적도 있음
      지금은 균형이 맞지만 대부분은 그렇지 못한 듯함

  • 이 글은 정말 잘 쓴 글임
    “정치가 싫다”는 뉘앙스에만 집중하지 말고, Infra와 DevEx의 정치적 구조를 이해해야 함
    나는 Slack에서 5년간 인프라 PM으로 일했는데, 제품 런치 프로세스를 4년 차에야 배웠음
    내부 고객(제품 엔지니어)의 성공을 돕는 게 핵심이었고, ‘Shadow Hierarchy’ 피드백이 승진의 관건이었음
    이런 내부 성공을 최적화하면 안정성과 커리어 모두에서 보상이 따름
    단, 비즈니스의 본질을 무시하는 치트코드는 아님

    • 중간 규모 회사에서도 이런 내부 정치와 피드백 구조는 동일하게 작동함

  • 글쓴이는 제품 엔지니어링과 인프라 엔지니어링의 평가 차이를 잘 짚었음
    다만 Google이라는 특수한 환경에 기반한 일반화가 다소 순진하게 느껴짐
    시장 상황이나 리더십의 우선순위가 바뀌면, 자신이 쌓은 가치도 재정의해야 함

    • 원문 작성자는 그 점을 인지하고 있었음
      자신의 글이 보편적 성공 가이드가 아님을 강조했고, 다른 환경에서는 다른 전략이 필요하다고 밝힘
    • 또 다른 독자는 “그런 지적은 이미 글 말미에 다뤄졌다”며 나이브하지 않다고 반박함

  • 대기업에서는 인기 투표식 평가가 흔함
    “커뮤니티 리더십” 같은 모호한 기준으로 평가받는 경우가 많음
    하지만 조용히 좋은 일을 하고, 다른 사람을 돕는 게 진짜 가치라고 생각함

    • VC식 ‘추상적 가치’와 MBA식 ‘ROI 집착’ 사이에서 균형을 잡는 게 어렵다고 느낌
    • 눈에 띄지 않는 깊은 기술 작업은 종종 과소평가되고, 잘못 다루면 시스템 전체가 무너질 위험이 있음
    • 요즘은 코드 품질을 평가할 수 없는 관리자가 많아, 결국 인기도로 평가가 이뤄짐
      엔지니어는 탄탄한 코드와 자기 홍보 중 하나를 선택해야 하는 딜레마에 놓임
    • 과거엔 문제를 해결했을 때만 칭찬받고, 꾸준한 성과는 당연시되었음
      결국 적절한 인센티브 설계가 조직 운영의 핵심임

  • 25년 커리어 중 대부분 2년마다 회사를 옮겼지만, 지금 회사에서는 4년째 근무 중임
    내부 플랫폼을 구축하며 실제 고객 문제를 해결하고 있고, 정치와 무관하게 이게 나를 매일 움직이게 함

    • 이런 바텀업 성공은 드물지만, 한 번 일어나면 엄청난 에너지를 줌

  • 인프라와 툴링 엔지니어로서 오랜 기간 한 팀에 있었는데, 이 글의 내용이 현실과 잘 맞음
    가끔 쉬운 성과도 있지만, 대부분은 차분하고 만족스러운 일상적인 기술 작업임

  • 나도 제품팀보다 인프라팀에서 일하는 걸 선호함
    리더십의 변덕에서 자유롭고, 기술적 완성도에 집중할 수 있음
    현재 중견기업에서 조용히 다른 팀의 인프라를 개선하는 일을 즐기고 있음

  • 이런 글로 자신의 가치를 방어해야 하는 상황 자체가 좋은 신호는 아님
    물론 자기 홍보와 카리스마가 승진에 유리하지만, 세상을 더 나쁘게 만들면서까지 그럴 필요는 없음
    Wozniak처럼 묵묵히 일하는 사람도 필요함

  • 글쓴이가 스포트라이트를 피할 수 있었던 건 이미 Staff Engineer이기 때문임
    스타트업 시절엔 신뢰를 얻었기에 굳이 자신을 드러낼 필요가 없었지만, BigTech에서는 정치가 심했음
    나는 단기 목표로 돈을 벌고 떠날 생각이었지만, 후배 인턴이 인정받게 도와주는 일이 더 어려웠음
    지금은 내 프로젝트 자체가 가시성을 주기 때문에 굳이 홍보하지 않아도 됨

    • 하지만 다른 사람은 이에 동의하지 않음
      Google에서 L3 시절부터 스포트라이트를 쫓지 않고도 동료 엔지니어들과의 공유와 협업으로 충분히 인정받았다고 함

  • 충분한 자본(사회적이든 금전적이든) 을 확보하면 3년간 버틸 수 있고, 2년 차에 성과가 나면 초반의 시행착오는 잊히게 됨
    문제는 틀렸을 때의 리스크임

    • 또 다른 리스크는, 큰 문제를 미리 막았을 때 아무도 그 가치를 몰라주는 경우임
      버그 없는 릴리스를 위해 노력해도, 결국 야근해서 문제를 해결한 사람만 칭찬받는 현실이 있음
    • 하지만 고객과 충분히 대화하고 시장 맥락을 이해하면 리스크를 줄일 수 있음
      물론 운도 한몫하지만, 준비된 사람에게 기회가 온다고 믿음
답변달기