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

> Clean Markdown view of GeekNews topic #24851. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=24851](https://news.hada.io/topic?id=24851)
- GeekNews Markdown: [https://news.hada.io/topic/24851.md](https://news.hada.io/topic/24851.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-12-05T18:34:10+09:00
- Updated: 2025-12-05T18:34:10+09:00
- Original source: [lalitm.com](https://lalitm.com/software-engineering-outside-the-spotlight/)
- Points: 1
- Comments: 1

## Topic Body

- **대형 기술기업의 제품 중심 문화**가 단기성과와 가시성을 중시하는 반면, 인프라·개발자 도구 분야에서는 **지속성과 시스템 관리**가 핵심 가치로 작동함  
- 글쓴이는 구글에서 **개발자 도구와 인프라 팀**에 속해 있으며, 경영진의 주목보다 **엔지니어 고객의 신뢰와 효율성**을 우선시함  
- 장기적인 **시스템 관리(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** 등 여러 유형 존재  
  - 전자는 경영진의 의지를 실행하는 문제 해결자, 후자는 특정 도메인의 장기적 소유자  
- 글쓴이는 후자에 속하며, **깊은 기술 맥락과 장기적 책임**을 중시  
- 이 접근은 **수익성 있는 대기업 환경**에서만 가능한 경우가 많으며, **운과 선택**이 모두 작용  
  - 좋은 팀을 만나는 것은 운이지만, **오랜 기간 머무르며 관리자로 성장하는 것은 선택**  
  - 이런 팀들은 외부에서 주목받지 않지만, **지속적 미션과 안정된 엔지니어링 문화**를 유지  

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

## Comments



### Comment 47259

- Author: neo
- Created: 2025-12-05T18:34:11+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=46146451) 
- 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년 차에 성과가 나면 초반의 시행착오는 잊히게 됨  
  문제는 **틀렸을 때의 리스크**임  
  - 또 다른 리스크는, 큰 문제를 미리 막았을 때 아무도 그 가치를 몰라주는 경우임  
    버그 없는 릴리스를 위해 노력해도, 결국 **야근해서 문제를 해결한 사람**만 칭찬받는 현실이 있음  
  - 하지만 고객과 충분히 대화하고 시장 맥락을 이해하면 **리스크를 줄일 수 있음**  
    물론 운도 한몫하지만, 준비된 사람에게 기회가 온다고 믿음
