개발자 커리어

당신이 시니어 레벨 이상으로 성장하기 위해 필요한 3가지 스킬(Feat. 구글/우버 출신 스태프 엔지니어)

꼭 관리직으로 가지 않아도 됩니다. 기술직에서도 얼마든지 가능해요.

2024.05.07 | 조회 477 |
0
|
데브필 DevPill의 프로필 이미지

데브필 DevPill

Top 1% 개발자로 거듭나는 성공 처방전

첨부 이미지

Introduction

개발자로 일하면서 시니어라는 타이틀이 주는 무게는 만만찮습니다. 단순히 경력을 오래 쌓았다고 달 수 있는 이름이 아니기에 경력 10년차 이상의 개발자들조차 함부로 자신을 시니어라 자칭하지 않습니다. 이는 특히 겸손을 지향하는 한국에서 더욱 두드러지게 나타나는 현상이기도 하죠.

대체 이 세상에 시니어 개발자는 존재하는가..ㅇㅅㅇ..
대체 이 세상에 시니어 개발자는 존재하는가..ㅇㅅㅇ..

하지만 그렇기 때문에 모두가 선망하는 대상이 시니어 개발자이기도 합니다. 그런데 시니어에 대한 선망이 커서인지, 그 다음 레벨을 고민하는 개발자 분들은 많지 않은 것 같습니다. 혹자는 시니어 레벨을 끝이라 생각하며 그곳에 그대로 머무르고 싶어하기도 하죠.

하지만 그 뒤에 무엇이 있는지 모르는 것과 있는지 알고 선택하는 것은 천지차이입니다. 오늘은 구글/우버 출신 스태프 엔지니어이자 리더십 코치를 겸하고 있는 Irina Stanescu의 3 Critical Skills You Need to Grow Beyond Senior Levels in Engineering 을 소개해드리겠습니다.


저자는 구글과 우버에서 커리어를 시작했는데요, 주니어부터 스태프 엔지니어까지 승진을 거듭해왔습니다. 그 중 가장 어려웠던 도약은 시니어에서 스태프로의 전환이었다고 합니다. 회사를 옮기고 팀을 바꾼 것도 한 몫 했지만, 무엇보다 해당 단계에서 전환하는 그 자체가 까다롭기 때문이라고 하네요.

이를 Will Larson의 비유를 빌리자면 아래와 같은데요.

시니어까지는 마치 학교 졸업 전과 같습니다. 명확한 학점, 졸업 요건, 시험이 있고 누군가 그 과정을 가르쳐주죠. 하지만 졸업 이후에는 그런 틀이 사라집니다. 

Will Larson

즉, "당신을 시니어로 만든 것이 당신을 시니어 이상으로 만들어주진 않는다"는 것입니다.

첨부 이미지

기술적인 트랙을 계속 가든, 관리직으로 전환하든 시니어 이후의 경력 발전을 위해서는 완전히 다른 스킬을 개발하고 습득해야 합니다. 이 글에서는 그 중 가장 중요한 3가지 스킬에 대해 이야기합니다.

1. 자신을 scale up하는 법 배우기 

시니어 이후의 레벨에서는 훨씬 더 큰 범위와 영향력에 대한 기대가 따릅니다. 안타깝게도 하루가 24시간 이상이 되거나 초인적인 능력이 생기진 않죠.

"자신을 스케일링한다"는 방정식을 떠올려볼게요. 이 공식에서 여러분의 임팩트는 혼자서 할 수 있는 일과 다른 사람을 통해 달성할 수 있는 일의 합입니다. 임팩트를 극대화하는 것은 각 요소를 최대화하는 문제가 됩니다.

첨부 이미지

문제는 개인의 임팩트는 하루에 주어진 시간으로 제한되지만, 기대치는 그렇지 않다는 것입니다. 이런 상황에서 임팩트의 크기를 키우는 유일한 방법은 다른 사람을 통해 할 수 있는 일에 더 크게 투자하는 것입니다.

이 스킬을 기르려면 어떻게 해야 할까요? 아래 방법을 소개해드립니다.

  • 혼자서 할 수 있는 일 극대화하기: 시간을 가차없이 우선순위화하고, ROI가 작은 활동은 미루며, 당신의 의견이 중요한 영역에 집중합니다. 엔지니어의 경우 종종 코딩을 덜 하는 것을 의미하죠(더 주니어한 사람이 기여할 수 있도록 일을 최대한 넘겨주세요).
  • 다른 사람을 통해 할 수 있는 일 극대화하기: 가르치고 멘토링하며, 업무를 위임하고, 권한 없이도 영향력을 행사하는 것입니다. 제 조언은 최대한 많이 가르쳐서 최대한 많이 위임할 수 있게 하라는 것입니다.

아이디어는 다른 사람이 할 수 있거나 할 수 있게 될 일들을 최대한 덜어내고, 여러분의 노력을 가장 필요로 하고 가장 큰 영향을 미칠 수 있는 곳에 집중하는 것입니다.

2. 모호함을 헤쳐나가기

엔지니어링에서 모호함은 당연한 것이죠. 그런데 시니어 이상의 레벨에서는 그 정도가 훨씬 증가합니다. 기술 제품의 경우, 모호함은 서로 다른 접근 방식으로 이어질 수 있는 모든 문제에서 비롯됩니다. 주로 다양한 전략, 데이터 해석, 상충되는 요구사항, 불완전한 명세 등이 그 원인이 되곤 합니다. 

때로는 이런 문제들이 과연 해결 가능한 것인지, 또는 애초에 어떤 문제를 해결해야 하는 것인지조차 알 수 없습니다. 시니어 레벨 이상에서 회사가 여러분에게 기대하는 것은 해결해야 할 가장 중요한 문제를 찾아내고 지지하는 데 기여하는 것입니다.

이런 상황에서 해결책을 평가하고 선택하는 것은 트레이드오프를 만들고 기회를 잡는 게임이 되었습니다. 이 스킬을 기르는 방법은 무엇일까요? 엔지니어와 엔지니어링 리더에게 주어진 과제는 이러한 불확실성을 현명하게 헤쳐나가는 것입니다.

이때 여러분이 가져야 할 목표는 아래 "모호함 생애주기 다이어그램(The Ambiguity Lifecycle)"에 설명된 대로 문제를 막연한 요구사항에서 유효한 제품으로 전환하는 것입니다.

첨부 이미지

여러분의 일은 알려지지 않은 것을 알려진 것으로 바꾸고, 모호한 아이디어를 실행 가능한 계획으로 번역하는 것입니다. 이는 주로 아래 예시들을 합쳐가면서 만들어지는데요.

  • 탐정 작업 — 올바른 질문을 하고, 증거를 수집하며, 사례를 바탕으로 가설을 세우고, 이를 검증하는 것
  • 불확실성을 가장 작은 구성요소로 분리하고 가설을 증명하거나 반증하는 것
  • 분할 정복 — 문제를 더 작은 하위 문제로 나누고 체계적으로 해결하는 것
  • 불완전한 정보로도 정보에 입각한 의사결정을 내리는 것
  • 새로운 정보와 피드백이 있을 때 피봇할 수 있는 것

3. 권한 없이 영향력 행사하기

권한 없이 영향력을 행사하는 것은 모든 소프트웨어 엔지니어에게 중요한 스킬이지만, 특히 기술 트랙이든 리더십 트랙이든 시니어 레벨을 넘어서려는 사람들에게는 필수적입니다.

팀 레벨에서 당신이 공식적인 권한을 가지고 있지 않은 사람에게 무언가를 하게 하거나 그만두게 하려면 영향력이 필요합니다. 조직 레벨에서도 같은 원칙이 적용됩니다. 다양한 그룹을 공통된 목표로 조율하려면 영향력이 필요하죠.

보통 우리는 누군가에게 영향력을 끼친다는 게 이성의 영역, 예컨대 어떻게 하면 완벽한 단어와 논리로 설득하는 것이라고 생각합니다. 하지만 현실은 그보다 시간이 지나며 쌓는 인간적 신뢰과 개인적 유대에 기반합니다. 즉, 메세지보다 메신저에게 설득되는 것이죠.

여기서 결정적인 힌트를 하나 드리겠습니다. 설득하는 말 자체는 퍼즐의 작은 조각일 뿐이예요. 나머지는 모두 직장에서 개인 브랜드를 얼마나 잘 구축했는지, 다른 팀원들의 말을 얼마나 잘 경청하며 사람들과의 연결이 원만했는지, 협상 포인트, 그리고 상호 이익이 되는 해결책을 얼마나 잘 찾는지 것에 관한 것입니다.


오늘의 아티클은 여기까지입니다. 개인적으로 3번, 영향력 행사 파트에서 설득은 논리가 아닌 신뢰와 유대로 이뤄진다는 내용이 굉장히 인상깊었습니다. 당장 현업에서 나 자신은 그럴듯한 말만 앞세우진 않았는지 반성이 되네요. 여러분께도 큰 울림이 있었기를 바랍니다.

Top 1% 개발자로 거듭나는 확실한 처방전, 데브필입니다.

첨부 이미지

 

 

다가올 뉴스레터가 궁금하신가요?

지금 구독해서 새로운 레터를 받아보세요

이번 뉴스레터 어떠셨나요?

데브필 DevPill 님에게 ☕️ 커피와 ✉️ 쪽지를 보내보세요!

댓글

의견을 남겨주세요

확인
의견이 있으신가요? 제일 먼저 댓글을 달아보세요 !

다른 뉴스레터

© 2024 데브필 DevPill

Top 1% 개발자로 거듭나는 성공 처방전

뉴스레터 문의dev.redpill@gmail.com

메일리 로고

자주 묻는 질문 서비스 소개서 오류 및 기능 관련 제보

서비스 이용 문의admin@team.maily.so

메일리 사업자 정보

메일리 (대표자: 이한결) | 사업자번호: 717-47-00705 | 서울 서초구 강남대로53길 8, 8층 11-7호

이용약관 | 개인정보처리방침 | 정기결제 이용약관 | 라이선스