나는 “tech” 업계에서 직함(title) 이 거의 임의적이라는 느낌을 받음
“Senior”, “Lead”, “Principal”, “Staff” 같은 호칭은 회사마다 정의가 달라서, 실제로는 조직 구조에 따라 의미가 완전히 달라짐
예를 들어 “Senior Backend Developer”일 때가 “Staff Engineer”일 때보다 더 많은 책임을 맡았던 적도 있음
세 대륙에서, 6명짜리 스타트업부터 1만 명 넘는 대기업까지 일해봤지만, 직함의 기준은 여전히 제각각이었음
맞음. 직함은 회사 내부에서는 일관성 있게 쓰여야 하지만, 회사 간에는 전혀 호환되지 않음
신입들에게 이걸 여러 번 설명해야 했음. “Senior Engineer” 타이틀 때문에 수만 달러를 포기하려는 사람도 있었음
채용할 때는 Microsoft나 Google처럼 공개된 레벨링 시스템이 있는 회사 출신이 아니면 직함은 거의 무시함
“Principal Staff Engineer”나 “CTO” 타이틀을 가진 사람이 실제로는 평균 회사의 시니어 수준에도 못 미치는 경우도 있었음
반대로 “Senior Software Engineer”인데 팀 누구보다 뛰어난 사람도 있었음
대부분의 회사는 보상과 평가를 위해 자체적인 레벨 구조를 가짐
일반적으로는 L1 인턴부터 L10 Fellow까지 이어지는 구조이며, L5(Senior)가 대부분의 엔지니어가 도달 가능한 ‘종착점’ 역할을 함
L6 이상은 특별한 영향력과 제품·비즈니스 임팩트를 요구함
L9~L10은 업계 전체에 영향을 준 사람들로, 예를 들어 MapReduce나 Kubernetes를 만든 수준임
IC(Individual Contributor)에게 직함은 보상과 평가에 직접 연결됨
대기업에서는 Staff와 Senior의 RSU 차이가 크지만, 스타트업에서는 거의 의미가 없음
평가 시즌에는 직함에 따라 평가 기준이 달라지지만, 실제로는 매니저가 곡선을 맞추기 위해 점수를 조정함
VP, Director, C레벨로 가면 조직 간 비교가 가능해지고, 정치적 요소가 커짐
직함은 외부에서 나를 설명하는 가장 상위 비트임
한 회사에 오래 있을 거면 중요하지 않지만, 커리어 이동을 고려한다면 협상 포인트가 됨
나는 “Senior DevSecOps Engineer”라는 타이틀을 직접 협상했음
이 타이틀 덕분에 내가 보안 파이프라인 관리에는 강하지만, 머신러닝 모델 튜닝에는 약하다는 걸 명확히 보여줄 수 있음
예전에 기계·전기 기반의 시스템 엔지니어로 일했는데, 소프트웨어 업계가 같은 타이틀을 가져가면서 혼란이 생겼음
내 역할은 실제 하드웨어와 공압, 전류를 다루는 일이었는데, 이제는 검색하면 전부 Unix나 Python 관련 직무만 나옴
“Unix Server Engineer” 같은 좀 더 구체적인 이름을 썼다면 좋았을 것 같음
엔지니어링 매니저가 되고 싶다면, 단순히 다음 단계로 생각하지 말고 장기적으로 어떤 역할을 원하는지 고민해야 함
매니저는 기술보다 사람 관리와 HR이 핵심이며, Director 이상으로 가면 회의와 정보 정리에 대부분의 시간을 씀
많은 개발자가 Peter Principle(위키 링크)의 희생양이 됨
개발자로 남는 것도 전혀 문제없음. 좋아하는 일을 하면서 버틸 수 있다면 이미 성공한 것임
내 매니저는 평가 시즌 외에는 거의 아무 일도 안 하지만 나보다 연봉이 높고, 팀의 성과를 전부 자기 공으로 돌림
겉보기엔 꽤 쉬운 일처럼 보임
Peter Principle을 처음 알게 됐는데, 1969년에 나온 개념이 아직도 유효하다는 게 놀라움
IC 입장에서 보면, 사람 관리가 그 역할의 가장 명확한 부분인데 그걸 준비 안 한다는 게 이해가 안 됨
나는 휴가 승인이나 슬랙에서 누군가를 혼내는 일은 절대 하고 싶지 않음
내 경험상 Peter Principle보다 Dilbert Principle(위키 링크)이 더 현실적임
Apple에서 매니저로 승진한 사람들이 작성한 끔찍한 코드를 디버깅하면서, 그들이 애초에 잘했던 적이 없다는 걸 깨달음
고위 관리자는 실제 일보다 중요해 보이게 만드는 능력이 중요함
회의 예약하고 슬라이드 만드는 게 실력처럼 보이는 구조임
모두가 “엔지니어링 경험 있는 매니저”를 원하지만, 정작 그 매니저가 되고 싶어 하는 사람은 없음
산업별로 구분하지 않으면 이런 분석은 의미가 없음
“Engineering Manager”는 너무 일반적인 타이틀이라 스타트업, 빅테크, 엔터프라이즈마다 다름
엔터프라이즈에서는 Staff Engineer가 거의 없고, 보통 SWE1/2/3 → Tech Lead → Architect 구조임
반면 테크 기업은 SWE1/2/3 → Staff → Principal 구조를 가짐
매니저는 종종 종착점 역할을 하며, 20년간 같은 포지션에 머무는 경우도 많음
결국 매니저로 가는 건 커리어 전환임
하지만 Staff 이상은 EM과 보상 수준이 비슷하고, 오히려 이직 자유도가 높음
EM은 책임이 크고 근무시간이 길지만 급여 차이는 미미함
프로젝트가 늦어지면 영업팀의 희생양이 되기 쉬워 고용 안정성도 낮음
최근 1년간의 변화가 “엄청나다”는 주장에 동의하지 않음
내 업무는 몇 년 전과 거의 비슷하고, 변화는 점진적임
AI 도구의 발전 속도가 빠르다는 건 예측이지, 이미 필수라는 증거는 아님
“예측”이란 말이 무슨 뜻인지 모르겠음. 단순히 AI 도구를 안 써봤다는 건가?
과대평가되었더라도 생산성 향상이 있다면 이미 워크플로우 변화는 일어나고 있는 것임
그 사람이 업계 경력이 5년 미만일 것 같음
학교에서 바로 온 사람은 아직 배울 게 많아서 변화가 크게 느껴질 수 있음
AI 도구에 대한 담론이 모순적임
“누구나 쉽게 쓸 수 있다”면서도 “지금 안 쓰면 뒤처진다”고 함
어차피 곧 더 좋아질 거라면, 지금 불완전한 버전을 배우는 게 낭비처럼 느껴짐
매니저로 전환하는 것에 대한 논쟁이 있음
기술적 역량보다 사람 관리와 정치력이 중요하며, 이게 맞지 않으면 매니저가 되지 말아야 함
하지만 매니저로 가면 이직 기회가 줄고, 해고 위험이 더 큼
EM은 대체가 쉽고, 프로젝트 실패 시 희생양이 되기 쉬움
반면 IC는 책임을 분산시킬 수 있음
나는 IC에서 매니저로 전환했는데, 두 트랙은 완전히 다름
VP는 Distinguished Engineer와 비슷한 레벨이지만, DE는 업계에서 유명세를 얻어야 함
결국 돈이나 승진보다 무엇을 좋아하느냐가 기준이 되어야 함
AI가 단순 업무를 대체하는 시대에는, 열정을 가진 사람만 남게 될 것임
대부분의 회사에서 매니저는 ‘내부 서클’ 로 여겨지고, 기술자는 단순 노동자로 취급됨
매니저는 더 많은 정보와 회의 접근권을 통해 영향력을 얻음
하지만 실제로는 라인 매니저가 가장 쉽게 교체 가능한 포지션임
나는 주요 프로젝트를 맡을 때 CTO에게 직접 보고하도록 요구했음
이런 구조를 모른다면, 매니저로서의 자질이 부족한 것임
회사의 ‘마피아 구조’ 에 들어가는 셈임
매니저는 깊은 기술 지식이 부족한 대신 정치력과 가시성으로 영향력을 확보함
보상 비교는 동일 조건으로 해야 함
나는 Google과 여러 회사에서 Staff Engineer와 EM을 모두 해봤음
뛰어난 IC는 일부 회사에서 100만 달러 이상 받을 수 있고,
그렇지 않다면 매니저로 가는 게 더 나은 선택일 수 있음
“엔지니어와 매니저는 동등한 트랙”이라는 말은 신화에 가깝음
실제로는 매니저 트랙이 훨씬 승진 기회와 가시성이 많음
큰 조직에서는 내부 네트워크 접근성이 커서 유리함
게다가 실력 없는 매니저가 엔지니어보다 오래 버티는 경우도 많음
“무엇을 하지 말라”는 식의 조언은 위험함
“디트로이트로 가지 마라”, “학계로 가지 마라”, “Google 주식 사지 마라” 같은 말은
결국 상황에 따라 가치가 달라지는 시장의 원리와 같음
인생은 결국 저평가된 가치를 찾는 게임임
남들이 싫어하는 선택이 나에게는 최고의 기회가 될 수도 있음
Hacker News 의견들
나는 “tech” 업계에서 직함(title) 이 거의 임의적이라는 느낌을 받음
“Senior”, “Lead”, “Principal”, “Staff” 같은 호칭은 회사마다 정의가 달라서, 실제로는 조직 구조에 따라 의미가 완전히 달라짐
예를 들어 “Senior Backend Developer”일 때가 “Staff Engineer”일 때보다 더 많은 책임을 맡았던 적도 있음
세 대륙에서, 6명짜리 스타트업부터 1만 명 넘는 대기업까지 일해봤지만, 직함의 기준은 여전히 제각각이었음
신입들에게 이걸 여러 번 설명해야 했음. “Senior Engineer” 타이틀 때문에 수만 달러를 포기하려는 사람도 있었음
채용할 때는 Microsoft나 Google처럼 공개된 레벨링 시스템이 있는 회사 출신이 아니면 직함은 거의 무시함
“Principal Staff Engineer”나 “CTO” 타이틀을 가진 사람이 실제로는 평균 회사의 시니어 수준에도 못 미치는 경우도 있었음
반대로 “Senior Software Engineer”인데 팀 누구보다 뛰어난 사람도 있었음
일반적으로는 L1 인턴부터 L10 Fellow까지 이어지는 구조이며, L5(Senior)가 대부분의 엔지니어가 도달 가능한 ‘종착점’ 역할을 함
L6 이상은 특별한 영향력과 제품·비즈니스 임팩트를 요구함
L9~L10은 업계 전체에 영향을 준 사람들로, 예를 들어 MapReduce나 Kubernetes를 만든 수준임
대기업에서는 Staff와 Senior의 RSU 차이가 크지만, 스타트업에서는 거의 의미가 없음
평가 시즌에는 직함에 따라 평가 기준이 달라지지만, 실제로는 매니저가 곡선을 맞추기 위해 점수를 조정함
VP, Director, C레벨로 가면 조직 간 비교가 가능해지고, 정치적 요소가 커짐
한 회사에 오래 있을 거면 중요하지 않지만, 커리어 이동을 고려한다면 협상 포인트가 됨
나는 “Senior DevSecOps Engineer”라는 타이틀을 직접 협상했음
이 타이틀 덕분에 내가 보안 파이프라인 관리에는 강하지만, 머신러닝 모델 튜닝에는 약하다는 걸 명확히 보여줄 수 있음
내 역할은 실제 하드웨어와 공압, 전류를 다루는 일이었는데, 이제는 검색하면 전부 Unix나 Python 관련 직무만 나옴
“Unix Server Engineer” 같은 좀 더 구체적인 이름을 썼다면 좋았을 것 같음
엔지니어링 매니저가 되고 싶다면, 단순히 다음 단계로 생각하지 말고 장기적으로 어떤 역할을 원하는지 고민해야 함
매니저는 기술보다 사람 관리와 HR이 핵심이며, Director 이상으로 가면 회의와 정보 정리에 대부분의 시간을 씀
많은 개발자가 Peter Principle(위키 링크)의 희생양이 됨
개발자로 남는 것도 전혀 문제없음. 좋아하는 일을 하면서 버틸 수 있다면 이미 성공한 것임
겉보기엔 꽤 쉬운 일처럼 보임
나는 휴가 승인이나 슬랙에서 누군가를 혼내는 일은 절대 하고 싶지 않음
Apple에서 매니저로 승진한 사람들이 작성한 끔찍한 코드를 디버깅하면서, 그들이 애초에 잘했던 적이 없다는 걸 깨달음
고위 관리자는 실제 일보다 중요해 보이게 만드는 능력이 중요함
회의 예약하고 슬라이드 만드는 게 실력처럼 보이는 구조임
산업별로 구분하지 않으면 이런 분석은 의미가 없음
“Engineering Manager”는 너무 일반적인 타이틀이라 스타트업, 빅테크, 엔터프라이즈마다 다름
엔터프라이즈에서는 Staff Engineer가 거의 없고, 보통 SWE1/2/3 → Tech Lead → Architect 구조임
반면 테크 기업은 SWE1/2/3 → Staff → Principal 구조를 가짐
매니저는 종종 종착점 역할을 하며, 20년간 같은 포지션에 머무는 경우도 많음
결국 매니저로 가는 건 커리어 전환임
EM은 책임이 크고 근무시간이 길지만 급여 차이는 미미함
프로젝트가 늦어지면 영업팀의 희생양이 되기 쉬워 고용 안정성도 낮음
최근 1년간의 변화가 “엄청나다”는 주장에 동의하지 않음
내 업무는 몇 년 전과 거의 비슷하고, 변화는 점진적임
AI 도구의 발전 속도가 빠르다는 건 예측이지, 이미 필수라는 증거는 아님
과대평가되었더라도 생산성 향상이 있다면 이미 워크플로우 변화는 일어나고 있는 것임
학교에서 바로 온 사람은 아직 배울 게 많아서 변화가 크게 느껴질 수 있음
“누구나 쉽게 쓸 수 있다”면서도 “지금 안 쓰면 뒤처진다”고 함
어차피 곧 더 좋아질 거라면, 지금 불완전한 버전을 배우는 게 낭비처럼 느껴짐
매니저로 전환하는 것에 대한 논쟁이 있음
기술적 역량보다 사람 관리와 정치력이 중요하며, 이게 맞지 않으면 매니저가 되지 말아야 함
EM은 대체가 쉽고, 프로젝트 실패 시 희생양이 되기 쉬움
반면 IC는 책임을 분산시킬 수 있음
나는 IC에서 매니저로 전환했는데, 두 트랙은 완전히 다름
VP는 Distinguished Engineer와 비슷한 레벨이지만, DE는 업계에서 유명세를 얻어야 함
결국 돈이나 승진보다 무엇을 좋아하느냐가 기준이 되어야 함
AI가 단순 업무를 대체하는 시대에는, 열정을 가진 사람만 남게 될 것임
대부분의 회사에서 매니저는 ‘내부 서클’ 로 여겨지고, 기술자는 단순 노동자로 취급됨
매니저는 더 많은 정보와 회의 접근권을 통해 영향력을 얻음
나는 주요 프로젝트를 맡을 때 CTO에게 직접 보고하도록 요구했음
회사의 ‘마피아 구조’ 에 들어가는 셈임
보상 비교는 동일 조건으로 해야 함
나는 Google과 여러 회사에서 Staff Engineer와 EM을 모두 해봤음
뛰어난 IC는 일부 회사에서 100만 달러 이상 받을 수 있고,
그렇지 않다면 매니저로 가는 게 더 나은 선택일 수 있음
“엔지니어와 매니저는 동등한 트랙”이라는 말은 신화에 가깝음
실제로는 매니저 트랙이 훨씬 승진 기회와 가시성이 많음
큰 조직에서는 내부 네트워크 접근성이 커서 유리함
게다가 실력 없는 매니저가 엔지니어보다 오래 버티는 경우도 많음
“무엇을 하지 말라”는 식의 조언은 위험함
“디트로이트로 가지 마라”, “학계로 가지 마라”, “Google 주식 사지 마라” 같은 말은
결국 상황에 따라 가치가 달라지는 시장의 원리와 같음
인생은 결국 저평가된 가치를 찾는 게임임
남들이 싫어하는 선택이 나에게는 최고의 기회가 될 수도 있음