26 커리어 래더

“다음 레벨로 올라가려면 무엇이 필요합니까?”

이것은 매우 열린 질문이지만, 회사의 기대치에 관한 몇 가지 지침을 정해 두면 좋을 수 있습니다. 개인 기여자(individual contributor)에게 커리어 래더는 회사가 표면적으로 무엇을 중요하게 여기는지(그리고 빠져 있는 항목을 통해 무엇을 중요하게 여기지 않는지)를 알려 줍니다. 커리어 래더는 공식적으로 승인된 제도이므로, 회사의 래더를 기준으로 전략적 선택을 계획해야 합니다. 하지만 평가 기준표의 항목을 채우기 위해 타산적으로 최적화하기보다는, 옳은 일을 하고 좋은 팀원이 되는 것을 더 중요하게 여기도록 노력해야 합니다.

26.1 커리어 래더는 언제, 왜 도입해야 하는가

어떤 회사에는 공식적인 래더가 아예 없습니다. 그런 형식을 갖출 만큼 규모가 크지 않을 수도 있습니다. 그렇더라도 자신의 역할에서 성공하기 위해 무엇이 기대되는지 매니저와 명확하게 논의해 두는 것은 여전히 도움이 됩니다. 매니저는 여러분이 더 많은 책임을 맡고, 보상을 늘리며, 앞으로 5~10년 동안 계속 성장하고 몰입할 수 있도록 하는 장기적인 계획을 갖기를 바라야 합니다. 매니저가 여러분에게 보람 있는 장기적 커리어를 만들어 주는 데 관심이 없어 보인다면, 이는 큰 위험 신호입니다.

일반적으로 회사는 엔지니어링 조직이 40~50명을 넘어서면 공식적인 래더를 도입하기 시작합니다. 매니저 1명당 엔지니어 6\~8명이라는 일반적인 비율을 고려하면, 이는 엔지니어링 팀이 5\~8개라는 뜻이며, 이는 엔지니어링 부사장이 모든 사람의 커리어 성장을 사례별로 공정하게 관리할 수 없게 되는 한계점에 거의 해당합니다. 공식적인 래더 체계를 요청할 기회가 보인다면 적극적으로 나서십시오. 이 문제에서 리더십을 발휘하면 여러분이 일하게 될 시스템을 만드는 데 발언권을 가질 수 있습니다.

많은 엔지니어가 다음 단계로 올라서려면 엔지니어링 관리직으로 가야 한다고 느낍니다. 그러나 코드 대신 사람을 관리하는 일에 요구되는 것은 완전히 다릅니다(장 7에서 다룬 바와 같습니다). 이는 직원을 번아웃에 빠뜨리고 회사로서는 훌륭한 엔지니어를 잃게 만들 수 있는데, 일종의 왜곡된 형태의 피터의 법칙이라 할 수 있습니다. 회사들은 자연스럽게 형성되는 관리직 트랙과 나란히 이와 동등한 기술 리더십 트랙을 마련하여 이 문제에 대응하며, 사람을 관리하고 싶지 않은 뛰어난 엔지니어에게도 실질적인 커리어 경로를 만들어 주고자 합니다. 이 “기술 리더십” 또는 “개인 기여자” 트랙이 이번 장에서 중점적으로 다룰 내용입니다.

래더는 회사 간 경력을 정규화하는 수단의 역할도 합니다. 다음 직장을 구해야 할 때가 온다면, 그때 여러분의 직함이 중요해집니다. 업계에서 통용되는 레벨이 없으면, 채용 담당자는 단지 자리를 채우기 위해 여러분을 손쉽게 “하향 레벨링”할 수 있고, 이는 여러분의 경력과 보상을 몇 년씩 후퇴시킵니다. 직관에 어긋나 보이겠지만, 경험 수준을 훨씬 앞서는 직함을 갖는 것 역시 바람직하지 않습니다. 직함 인플레이션은 고용주에 대한 평판을 떨어뜨리고, 이는 결국 여러분에 대한 평판까지 떨어뜨립니다.

어떤 회사들은 더 수평적인 조직이 되기를 원하며, 실제로 시니어 소프트웨어 엔지니어 직함에서 멈춥니다. 그 이후로는 직함보다 역할과 책임이 더 중요해지기 시작합니다. 반면 Netflix 같은 다른 회사들은 시니어 소프트웨어 엔지니어에서야 비로소 시작합니다. 업계 전반에 통용되는 패턴이 없다는 것이 분명히 보이십니까? 죄송합니다.

26.2 우리의 접근 방식

이 책의 첫 부분에서는 주로 여러분이 주니어에서 시니어로 성장하여 시니어 엔지니어가 되도록 돕는 데 초점을 맞추었습니다. 주니어에서 시니어로 가는 과정은 커리어 섹션(장 5)의 별도 전용 장에서 다룹니다.

이 장의 나머지 부분에서는 여러분의 코딩 커리어 전반에 걸친 커리어 전략에 대한 전반적인 직관을 제공하는 데 초점을 맞춥니다. 이것이 어려운 이유는 무엇보다도 모든 기업과 모든 상황이 저마다 다르기 때문입니다. 하지만 우리에게는 공개된 엔지니어링 사다리에서 수집한 확실한 데이터가 많이 있습니다(아래 참조). 이를 직관 및 공유된 경험에서 얻은 일화적 자료와 결합하면 아마도 좋은 아이디어 몇 가지에 도달할 수 있을 것입니다.

26.3 기업이 원하는 것

각 경력 수준을 무엇이라고 부를지에 대해서는 어느 정도 합의가 있습니다(일부 기업은 스태프와 프린시펄 직함을 하나로 합치기도 합니다). 각 수준을 간단히 요약하자면 다음과 같습니다:

주니어: 모범 사례를 배우며 지도를 받아 업무를 수행합니다. “중급” 개발자도 시니어가 아니라는 이유로 이 범주에 속합니다.
시니어: 독립적인 업무 수행, 주니어 멘토링.
Staff: 팀 리드, 모범 사례 정립, 아키텍처, 생산성 향상.
프린시펄: 업계 수준의 성과, 기술/로드맵 주도.
대기업에는 다양한 수준의 초고참 직급을 나타내기 위해 “Architect”, “Distinguished”, “Fellow” 같은 직함도 있습니다.

이는 5단계로 구성된 드레이퍼스 기술 습득 모델(Dreyfus model of Directed Skill Acquisition)과 대략 대응합니다:

초보자(Novice): 규칙이나 계획을 엄격하게 고수합니다. 상황 인식이 거의 없습니다. 재량적 판단을 하지 않거나 제한적으로만 합니다.
숙련된 초보자: 속성과 측면에 기반한 행동 지침을 따르며, 이 속성과 측면은 모두 동등하고 서로 분리되어 있습니다. 상황 인식이 제한적입니다.
중급자: 의식적이고 신중한 계획 수립. 표준화된 일상적 절차.
숙련자(Proficient): 상황을 전체적으로 파악합니다. 정상적인 패턴에서 벗어난 것을 감지합니다. 지침으로 격언을 활용하며, 그 의미는 맥락에 따라 달라집니다.
전문가(Expert): 더 이상 규칙, 지침, 격언에 의존하지 않습니다. 상황을 직관적으로 파악합니다. 분석적 접근은 새로운 상황에서만 사용합니다.

모든 회사는 여러 차원에서 성장을 추적합니다. 아래는 경험 스펙트럼의 양 극단이 어떤 모습인지를 종합한 것으로, 이를 통해 자신의 위치를 가늠하고 개선할 방향을 찾을 수 있습니다.

26.3.1 가장 주니어 단계

기술 역량

모범 사례와 코드베이스 익히기
약간의 지도를 받으며 범위가 정해진 문제를 해결할 수 있습니다
깔끔한 코드와 테스트를 작성합니다
코드 리뷰와 기술 설계에 참여합니다

실행력

예상 기간 내에 작업을 완료하기로 약속&완수하며, 스스로 책임을 집니다.
추정 능력을 기릅니다.
필요할 때는 막힌 상황을 풀기 위해 도움을 요청합니다.
도구와 리소스를 익혀 나갑니다.

커뮤니케이션

팀에서 협업하는 법과 회의에서 소통하는 법을 배웁니다.
팀원과 매니저에게 업무 상황을 효과적으로 공유합니다.
막히면 적극적으로 질문하고 도움을 요청합니다.
우려 사항이나 명확한 설명이 필요한 부분을 관리자에게 이야기합니다.
피드백을 기꺼이 받아들이고 경험을 통해 배웁니다.

영향력

프로젝트/팀 수준의 영향력을 가집니다.
지식을 얻기 위해 페어 프로그래밍을 합니다.
회사 내 다른 구성원에게 자기 팀을 잘 대변합니다.
채용에 참여할 수 있습니다.

26.3.2 최고 시니어

기술 역량

자기 도메인에 대한 기술 리더십
확장성과 신뢰성을 위한 솔루션의 독자적인 설계
여러 분야에 걸친 핵심 전문가
가장 영향력이 크고, 가장 중요하며, 미래를 내다보는 의사 결정과 방향 제시에 집중하여 회사를 기술적으로 발전시키고 비즈니스 성공에 영향을 미칩니다.

실행력

여러 팀과 시스템에 걸쳐 상호 의존성이 있으며 수개월에서 수년에 이르는 크고 복잡한 프로젝트를 계획하고 실행할 수 있습니다.
제품과 엔지니어링 관점 사이의 균형을 잡는 데 본보기가 되는 사람으로 여겨집니다.
어떤 중요한 프로젝트나 이니셔티브든 믿고 맡길 수 있습니다.
여러 도메인에 걸친 기술 시스템의 용량과 성장을 책임지며, 핵심 지표를 정의합니다.
미래의 필요를 예측하여 회사 차원의 영향력을 갖는 설득력 있는 기술 비전을 수립합니다.

커뮤니케이션

회사 안팎의 다양한 대상에게 복잡한 사안을 편안하게 전달합니다.
커뮤니케이션의 공백과 문제를 선제적으로 파악하고 해결합니다.

영향력

일상적으로 조직 수준에서 업계 수준에 이르는 영향력을 발휘합니다.
경영진과 함께 높은 수준의 기술 지침을 수립하기도 합니다.
회사의 기술적 방향에 뚜렷한 영향을 미칩니다.
회사의 목표와 전략에 영향을 미치며, 새로운 사업 성장 기회를 발굴합니다.
회사의 플랫폼, 아키텍처, 워크플로에 정통한 전문가입니다.
리더를 양성합니다.
조직 전반에 걸쳐 교육합니다.
엔지니어링 브랜드, 패턴, 관행을 정의하고 몸소 모범을 보입니다.
회사 외부에서 회사를 대표하는 홍보대사로서 엔지니어들을 회사로 끌어들입니다.
회사 내에서, 그리고 경우에 따라서는 더 넓은 기술 커뮤니티에서도 인정받는 리더입니다.
장기적이고 전략적인 가치를 지닌 복잡한 이니셔티브를 이끕니다.

직함이 같더라도 회사마다 시니어 IC에게 기대하는 바가 서로 다르다는 점에 유의하십시오. StaffEng.com의 Will Larson은 스태프 엔지니어의 4가지 유형을 정리했습니다.

팀 리드(Team Lead)는 특정 팀의 접근 방식과 실행을 이끕니다. 대개는 한 명의 매니저와 긴밀하게 협력하지만, 때로는 특정 영역 안에서 두세 명의 매니저와 협력하기도 합니다.
아키텍트(The Architect)는 핵심 영역 안에서 현재뿐 아니라 수년 뒤의 미래까지 내다보며 방향과 품질, 접근 방식을 책임집니다. 이들은 기술적 제약에 대한 깊은 지식과 사용자 요구에 대한 깊은 이해, 그리고 조직 차원의 리더십을 두루 갖추고 있습니다.
해결사(The Solver)는 임의의 복잡한 문제를 깊이 파고들어 적절한 해결 방향을 찾아냅니다. 어떤 이들은 특정 영역에 오랫동안 집중하고, 어떤 이들은 조직 리더십의 지시에 따라 이 핫스팟에서 저 핫스팟으로 옮겨 다닙니다.
오른팔(The Right Hand)은 임원급 관리자의 파트너이자 분신으로서, 그들의 범위와 권한을 빌려 특히 복잡한 조직을 운영합니다. 이들은 대규모 조직의 리더에게 추가적인 리더십 역량을 제공합니다.

26.3.3 다른 차원

많은 래더는 직원이 회사 가치를 얼마나 잘 실천하는지도 평가하며, 여기에는 팀워크, 반대하되 따르기(disagree and commit), 성장 마인드셋, 피드백을 주고 그에 따라 행동하는 능력, 신뢰도 등의 주제가 포함됩니다. 회사의 커리어 래더에 영향을 줄 수 있는 위치에 있다면, 과소대표된 소수자에 대한 스폰서십을 회사 커리어 래더에 직접 포함하도록 주장하는 것을 고려하십시오(장 6에서 다룹니다). 기술 업계의 다양성 문제를 해결하는 데 진심으로 관심이 있다는 것을 보여 주는 가장 좋은 방법은, 그것을 공식적인 평가 및 승진 기준의 일부로 만드는 것입니다.

26.4 회사별 커리어 래더

꽤 많은 회사들이 자사의 엔지니어링 사다리를 공개적으로 공유하고 있습니다. 여기서는 각각을 간략히 살펴보겠지만, 물론 더 자세한 내용을 알고 싶다면 각 래더를 직접 깊이 살펴보셔도 좋습니다.

Fog Creek: 2009년 자료이지만, Joel의 생각이 매우 큰 영향을 미쳐 왔음은 분명합니다. 주인의식을 키우는 것, 프로덕션 코드를 독립적으로 작성하는 능력, 제품 출시 경험, 그리고 시니어 레벨에서는 설계/계획/아키텍처에 중점을 둡니다. 팀워크, 자기 학습, 멘토링, 임팩트가 모두 핵심이며, 조엘 테스트도 마찬가지입니다.
Rent the Runway (스프레드시트): 2015년 자료입니다. D&D에서 영감을 받은 Dex/Str/Wis/Cha 능력치 기반의 재미있는 평가 방식을 채택했으며, 각각 기술력, 생산성, 영향력, 커뮤니케이션/리더십에 대응합니다. 관리자 트랙도 포함되어 있으며, 아키텍처, 채용, 조직 운영 능력, 리더십/설득력에 더 중점을 둡니다.
Artsy: Rent the Runway에서 영감을 받았습니다
CapGemini UK: 마찬가지로 Rent the Runway에서 영감을 받았습니다
Basecamp: 이 회사의 다른 모든 면에 깃든 기풍과 마찬가지로 상당히 미니멀합니다.
Thumbtack (스프레드시트): 2019년 자료입니다. 기술적 역량은 코드 품질/테스트, 디버깅, 범위 설정/프로젝트 설계로 나누고, 비기술적 요소는 협업, 시민의식, 리더십, 임팩트로 나눕니다. 흥미롭게도 리더십은 자율성, 판단력, 주도성, 합의 형성으로 세분화되어 있습니다.
CircleCI (스프레드시트): 가장 잘 알려진 래더 중 하나로, 상세하면서도 부담스럽지 않습니다. 특히 평가 항목 가운데 하나로 보안이 포함되어 있습니다.
Envoy: 주목받는 회사가 만든 꽤 단순한 래더 목록입니다.
Financial Times(웹앱). API도 있습니다! 기술(Technical), 리더십(Leadership), 실행(Delivery), 소통(Communication)의 네 가지 영역만 평가합니다. 감당할 만한 수준으로 느껴집니다.
Patreon: 기술(Technical), 실행(Execution), 커뮤니케이션(Communication), 영향력(Influence), 성숙도(Maturity)의 다섯 가지 차원에 초점을 맞춥니다
Meetup: 역할을 메이커(Maker)와 매니저(Manager)로 나눕니다.
- Maker는 아키텍처 & 프레임워크 & 소프트웨어 개발, 모범 사례 & 아키텍처 & 코드 리뷰, 기술 역량 평가 & 멘토링, 새로운 엔지니어링 도구 도입 & 도입 멘토링, 프로세스 개선 제안 & 도입 지원에 집중합니다.
- 매니저는 성과 평가, 경력 성장, 채용 및 인력 배치, 프로세스 개선 도입 및 엔지니어링 도구 정착, 그리고 조직 및 행정 업무에 집중합니다.
Socialbakers: Meetup의 래더와 상당히 비슷해 보입니다
Medium (gist): 모바일, 서버, 기반(Foundations), 웹 클라이언트, 프로젝트 관리, 커뮤니케이션, 기술력(Craft), 주도성, 조직 설계, 성과, 웰빙, 경력 개발, 에반젤리즘, 커뮤니티, 채용, 멘토십 트랙이 있습니다! 휴!
스탈링 소프트웨어(Starling Software): 레벨을 나타내는 데 빅오 표기법을 사용하는데, 이는 재미있는 시볼레스(shibboleth)입니다. 스킬은 컴퓨터 과학, 소프트웨어 엔지니어링, 프로그래밍, 경험, 지식으로 나뉩니다. 이 자료는 Hacker News에서 오랫동안 회자되어 왔지만, 우리가 노력해 볼 수 있는 것들을 잘 정리한 지도이기도 합니다.
Kickstarter: 기본적으로 데이터 직군과 CTO를 포함한 여러 직무 기술서의 모음입니다.
Brandwatch: 레벨을 큰 틀에서 설명한 다음, 이 스프레드시트에서 IC와 관리직으로 나누어 세분화합니다. 개발해야 할 속성이 총 15가지나 됩니다!
Spotify: “Squad/Tribe” 구조로 유명하며, “Steps”를 강조하고, 원하는 다섯 가지 행동 묶음을 간단한 목록으로 제시합니다:
- 개인의 성공보다 팀의 성공을 중시합니다
- 자신과 팀을 지속적으로 개선합니다
- 자신과 다른 사람들이 책임을 다하도록 합니다
- 자신의 업무가 비즈니스에 미치는 영향을 고려합니다
- 자신의 분야에 대한 숙달된 역량을 보여 줍니다
Chuck Groom - 이례적인 경우인데, 저자가 VTS의 시니어 엔지니어링 리더이기는 하지만 직무 래더(Job Ladder)에 대한 개인적인 생각을 담고 있습니다. 래더가 있으면 어떤 점에서 도움이 되는지에 대한 좋은 논의와 함께 안티패턴에 대한 설명도 담겨 있습니다. 특히 프린시펄 엔지니어의 “안티패턴”이 주목할 만합니다:

비즈니스 요구를 훨씬 넘어설 정도로 확장성이나 고가용성을 지나치게 강조합니다. 최신 “유행” 기술을 좇는 데 너무 많은 시간을 씁니다. 협업하지 않고 질문도 하지 않습니다. 남을 깔봅니다. 자기만의 “숙원” 의제를 고집합니다. 고위 경영진을 화나게 합니다.
Khan Academy (문서)
Monzo: 명확하고 단순한 사다리
Square (스프레드시트):
Buffer: 이곳에서는 래더라고 부르지 않고, 오히려 “프레임워크”라고 부릅니다. 개발자가 가진 영향력의 범위, 업무를 수행하는 방식, 그리고 엔지니어가 약속하고 책임지는 “오너십” 수준에 따라 개발자의 레벨을 나눕니다.
더 보기: https://www.cnblogs.com/dhcn/p/10729002.html

더 많은 래더(엔지니어링 외 직군)는 Progression.fyi에서 볼 수 있으며, 회사 전체의 레벨 체계를 마련하는 데 추가적인 기반이 될 수 있습니다. 직함과 레벨에 관한 Holloway 가이드도 참고하십시오.