최근에 가장 많이 하는 커리어적 고민이라고 하면 시니어 엔지니어로서 next step이 무엇인가에 고민인데, 그 고민에 대해 얘기하기 앞서, 대충 실리콘밸리 엔지니어 직급 / 역할에 대해 짧게나마 이야기해보려고 한다.
미국에서 이 직급 시스템을 커리어 레더 (career ladder) 라고 표현한다. 직역하면 커리어 ‘사다리’인데 보면 꼭 타고 올라가고싶게 하니 사다리란 표현이 정확한것 같기도 하다. 실리콘 밸리에서 엔지이어링 레더는 회사마다 약간의 차이는 있지만 꽤나 이미 표준화된 시스템이다. 구글이 실리콘밸리의 스타트업, 엔지니어링 문화에 시초인 만큼 (그리고 페이스북이 이어받아 완성(?)시킨 느낌이 있다), 대부분의 회사 레더 시스템 또한 구글의 것을 바탕으로 만들어졌다.
위에 표는 levels.fyi 라고 이 동네에선 유명한 compensation 관련 data를 모아둔 웹사이트인데, 회사마다 직군/레벨에 따른 평균 연봉을 비교할 수 있게 해준다. 그리고 그 데이터를 바탕으로 각 회사의 레벨이 다른 회사에 어느 레벨과 비슷한지도 보여주는데, 보다시피, 대부분 회사가 타이틀과 숫자만 살짝 다르지, 구글의 시스템과 거의 똑같은 것을 알 수 있다.
그럼, 각 레벨에 대해 좀 더 알아보자면...
(참고로 여기서 얘기하는 레더는 people managing을 하지 않고 개발이 주업무인 개발자 (a.k.a. individual contributor) 들의 커리어 레더이다. Manager들은 아예 다른 레더에서 다른 기준으로 평가 받고 승진을 해나간다.)
L3, 주니어 엔지니어, 대졸 신입
대졸 신입 엔지니어면 다 이 레벨에서 시작하게 된다. 이 레벨에서 회사가 기대하는 바는 그냥 빨리 배워서 코딩을 열심히 잘하는 엔지니어가 되는 것이다. 일단 작은 버그를 고치는 것부터 시작해서 결국에는 혼자 프로젝트 안에 feature 하나를 처음부터 끝까지 잘 해내는 게 이 레벨의 역할이다.
주니어 엔지니어들은 일단 사수, 매니저가 시키는 대로 열심히만 하면 된다. 모르면 열심히 다른 사람들한테 물어보고, 남이 쓰는 코드 많이 보면서 배우는 게 중요하다. 그래서 주니어 엔지니어들에게는 어떤 멘토가 걸리는지가 정말 중요한 것 같다. 세 살 때 버릇이 여든까지 가는 것처럼, 나도 처음 보고 배운 멘토들의 코딩 방식, 그들에게 받은 feedback이 나의 엔지니어링 철학(?)에 큰 영향을 주었다.
다음 레벨로 승진하기 위해서는 L3는 그냥 열심히 코딩을 하는 게 첫 번째고, 슬슬 경험이 쌓이기 시작하면 design doc을 쓰는 능력을 습득하면 된다.
🤖 From ChatGPT: 엔지니어링 디자인 문서는 프로젝트나 제품의 설계 및 개발 계획을 상세히 기록한 문서입니다. 이 문서는 엔지니어링 팀이 프로젝트를 진행하는 동안 필요한 정보와 지침을 제공하며, 다른 팀과의 협력을 원활하게 하기 위해 사용됩니다.
그렇게 코딩과 design doc을 찍어낼 수 있는 수준이 되면 이제 다음 레벨 (L4)로 넘어갈 준비가 된 것이다. 참고로 L3에게 또 중요한 점이 ‘성장의 속도’인데 L3 중에 더 돋보이고 싶으면 빨리 배우는 모습을 보여주면 된다. 실제로 많은 회사가 L3에게 시간제한을 두기도 하는데, 예를 들어 2, 3년 안에 다음 레벨로 승진을 못 하는 엔지니어들은 내보내는 경우도 있다.
L4, 미드레벨 엔지니어
이 레벨 엔지니어들은 회사의 코딩머신이라고 보면 된다. 소프트웨어 회사들의 코드 반 이상은 이 레벨 엔지니어들이 쓴 거라고 해도 과언이 아닐 것이다. L3들이 feature 단위의 일을 한다면 L4부터는 프로젝트를 하나 맡아서 처음부터 끝까지 끌고 가는 역할을 한다.
팀에서 L4 엔지니어들을 볼 때면, 웬만한 프로젝트는 혼자 믿고 맡길 수 있는 엔지니어들이라고 생각한다. 개인적으로도 구글에서 L4로 승진했을 때가 기억에 남는데, 처음으로 ‘실리콘밸리에서 엔지니어로 먹고 살 수는 있겠구나…’ 라는 생각이 들었었다. 대학교 때 전공도 늦게 정하고 해서 항상 엔지니어로서 조금 뒤처진다는 생각이 있었는데, 그것을 깨준 인증마크 같은 느낌이었다.
4에서 5로 승진하기 위해서는 점점 더 크고 중요한 프로젝트를 찾아서 맡아야 한다. 혼자 하는 프로젝트에서 시작해서 결국 주니어 엔지니어 한두 명을 리드 할 수 있는 정도의 프로젝트까지 맡을 수 있어야 한다. 3에서 4보다는 훨씬 어렵지만, 그래도 열심히 해서 팀에서 인정받고, 좋은 프로젝트를 배정받을 수 있는 정도가 되면 충분히 승진할 기회가 있을 것이다. 보다시피 4에서 5가 많은 사람에게 중요한 점프이기 때문에 회사에서 가장 열심히 하는 사람들도 5를 바라보고 있는 레벨4 엔지니어들이다.
L5. 시니어 엔지니어
L3들이 작은 feature들을 개발하고, L4들이 그거보단 조금 더 큰 프로젝트를 맡는다면, L5는 이제 팀 단위 프로젝트를 맡아서 이끌어야 한다. 리더쉽에서 필요로 하는 프로젝트를 맡아서, 테크니컬 디렉션을 잡고, 팀 엔지니어들에게 프로젝트를 쪼개서 분담하는 역할을 한다. 큰 회사에서는 이제 실제 코딩보다 design doc을 쓰는데 더 공을 많이 들이는 레벨이기도 하다. 코딩 외에도 팀 내 주니어 엔지니어 멘토링도 해야 하고 팀 미팅도 이끌고, 매니저를 도와서 팀에 진정한 리더 같은 역할을 하는 경우가 많다 (물론 그냥 조용히 코딩만 열심히 하는 시니어 엔지니어들도 있다).
그리고 시니어 엔지니어가 되면 몇 가지 특별한 점이 있다.
일단 많은 회사에서 시니어 레벨부터는 ‘성장’에 대한 pressure가 없어진다. 이것을 terminal level이라고도 하는데 원하면 그냥 평생 똑같은 일을 하면서 시니어 엔지니어로 먹고 살 수 있다는 것이다.
원하면 엔지니어링 매니저 트랙으로 바꿀 수도 있다. 물론 원한다고 바로 되는 것은 아니고 회사에 적당한 자리가 났을 때 매니저가 될 수 있는 레벨이 됐다는 것이다. (참고로 여기서 이야기하는 레벨은 Individual Contributor, 대부분의 회사가 매니저 career ladder는 따로
성장에 대한 pressure가 없는 만큼 더 이상 그냥 열심히 한다고 승진할 수 있는 게 아니다. 올라갈수록 승진도 exponentially 더 어려워진다.
그래서 그런지 나를 포함해 내 또래 시니어 엔지니어들이 다들 비슷한 고민을 하고 있다.
현재 회사에서 더 달려서 그다음 승진을 바라볼 것이지 (하지만 말했다시피, 더 이상 열심히만 해서는 안 되는 수준에 왔다. 그리고 스태프 엔지니어를 찍어도 도돌이표처럼 결국 똑같은 고민을 마주한다)
만약 주니어 때부터 계속 있었던 회사라면 이직을 할지 (3~4년 한군데서 일하면 지칠 때도 됐다)
매니저가 될 기회를 노릴지 (매니저가 커리어적으로 더 나은 선택인지 아닌지도 불확실하다)
아니면 그냥 평범하게 워라밸 챙기면서 앞으로 쭉 시니어 엔지니어로 남을지 (더 이상 먹고 살 걱정은 없겠지만 평생 실리콘밸리의 ‘중산층’으로 살 것인가)
나쁜 선택은 없지만 그래도 무엇인가 선택을 해야되는 기로에 서있다.
L6. 스태프 (staff) 엔지니어
만약 마음을 강하게 먹고 다시 달려서 L6까지 왔다면 충분히 박수받을 만한 자격이 있다고 본다. 스태프 엔지니어가 되려면 시니어 엔지니어로서 적어도 몇 년간 잘해서 회사 혹은 속한 org(부서)에서 인정도 받고, 각 팀이 어떻게 돌아가는지 충분히 이해도 하고, 팀에 의미 있는 결과까지 (예를 들어 user 수를 훨씬 늘렸다거나, 돈을 많이 버는 feature 만들었거나) 가져왔어야 한다. 한마디로 하자면, 회사에서 “좀 잘나가는 친구들”이다.
L5까지는 주로 팀 내에서 활약하고 자기가 맡은 프로젝트같이 개인의 성공이 더 중요했다면 L6부터는 진짜 자신의 팀을 위해 일을 해야 한다. 이제부턴 팀의 성적이 자신의 성적과 연결된다고 보면 될 것이다. 스태프 엔지니어에도 여러 종류가 있긴 하지만 (이것을 staff archetype 이라고 한다. 관심있으면 이 글을 참고), 공통적으로 해야 하는 일이 팀의 성공을 위해 여러 프로젝트를 manage하고, 계속 다른 팀들과 협업해서 새로운 기회를 찾고 더 큰 impact를 끌어내야 한다. 이 레벨부터는 자신이 영향을 끼치는 엔지니어의 숫자가 훨씬 더 늘어나게 되는데 그런만큼 정치력이 기술적인 능력만큼이나 중요한 시점이 된다.
L7+. 시니어 스태프 (senior staff) 엔지니어, 그 이상
여기서부터는 이제 천상계 엔지니어라고 봐도 될것이다. 일단 엔지니어링 부서가 어느정도 크지 않으면 이 레벨 자체가 존재하지 않을 수도 있고, FAANG급에서도 흔하게 보이는 인물은 아니다. 예를들어 나의 마지막 구글팀이 디렉터 (진짜 임원 밑에 대략 엔지니어가 50명 정도 있던 부서였는데, L7은 한명도 없었던것으로 기억한다.
연봉도 천상계급이고 (샐러리, 보너스, 스톡을 다 합하면 10억 근처) 하는일도 팀이 아니라 한 부서, 아니면 회사 단위의 일을 하게 된다. 물론 여기까지 온 사람들은 대부분 굵직한 업적을 하나씩 남겼기 때문에, 존재만으로도 도움이 되는 경우가 많다.
여기가 IC 엔지니어로서 도달할 수 있는 최고 레벨이다. 물론 예외도 있다. 구글에 IC level이 10까지 있는데, 이게 Jeff Dean이라는 레전더리한 인물을 위해 만들어진 레벨이다. 또 다른 예로, 내가 구글에 있었을때 스탠포드 컴공과 교수님이 엔지니어로 등록된적이 있었는데 (그분이 계시던 스타트업이 구글에 팔렸었다), L9으로 시스템에 올라와 있었다. L7 이상은, Industry에 한 획을 그을 정도의 사람이라면 가능한 것 같다 😅
직급에 숫자 레벨까지 붙이니, 꼭 무슨 포켓못 게임같은 느낌이 들게 만드는데 실제로 많은 엔지니어들이 게임처럼 접근하기도 한다. 사실 구글을 나온 이유 중 하나가 이 ‘레더 타기 게임’이 싫어서였는데 돌아보면 어느 크기의 회사에 가던, 이 커리어 레더는 피할 수 없는 게임이기도 했다. 이제 사다리를 막 타기 시작했다면 이왕 피할 수 없는 게임, 즐기면서 더 잘해보라고 해주고 싶다.
시니어에서 평생 머무르는데 돈은 더 받고 싶어요
안녕하세요! 궁금한 점이 있는데 혹시 여쭤봐도 될까요? 미국에서는 시키는 일 한다고 승진 시켜주지 않고 본인이 매니저한테 어필해야 한다고 알고있는데 사실인가요? 사실이라면 주니어 개발자가 들어가자마자 승진 얘기 하는 걸 안좋게 보일까요? 팀에서 성과를 내고 나서 말해야 하는 지 궁금해요 블로그 잘 챙겨보고 있는 학생입니다 항상 좋은 좋은 정보 감사합니다