개발자 커리어 로드맵 완벽 가이드

저는 개발자 커리어 로드맵 설정의 아주 기본부터, "커리어 로드맵을 위한 우선순위 설정"을 매슬로우의 욕구 계층 이론을 변형해서 말해보겠습니다. 매슬로우의 자아실현 단계처럼 우리는 최고가 되고자 하는 지속적인 욕구가 있고, 그것을 달성하기 위한 우선순위를 내면에 갖고 있습니다. 예를 들어 제 우선순위는 다음과 같습니다.

 

1. 기술 스택: 앞으로의 커리어에 있어서 어느 정도의 가치를 지니는 직장인지
2. 보상과 안정성: 안정적인 직업과 적절한 보상, 업무 환경 등을 의미합니다. 금전적 보상뿐만 아니라 직장에서의 안정감도 포함됩니다.
3. 성장 및 자기개발: 지속적인 학습과 기술적인 향상을 통한 개인의 전문성 개발을 의미합니다. 이는 자신의 역량을 계발하고 미래의 고용 가능성을 높이는 데 중점을 둡니다.
4. 워라밸: 직장과 개인 생활의 균형은 중요합니다. 건강은 빼놓을 수 없는 가치니까요.
5. 목적과 의미: 직업에서 물질적 보상 이상의 만족감을 추구하는 단계입니다. 

이상적으로는 이러한 것들이 잘 조화된 직업을 선택하는 것이 좋습니다. 항상 완벽하게 조율하는 것은 불가능하지만말이죠.

 

다음은 이러한 불균형의 몇 가지 일반적인 예입니다:

 

• 장시간 근무와 스트레스가 많은 직업이지만, 주기적으로 비행기 티켓 등을 주어 직원들의 워라밸을 포기하게끔 하는 관대한 보상
• '성장과 발전' 단계가 정체된 직무에 지나치게 오래 머무는 경우.
• 노후화된 기술 스택에 지나치게 숙련되어 현재 직무의 성장과 더 넓은 취업 시장에서의 고용 가능성을 맞바꾸는 경우.

다음 섹션에서는 이 프레임워크를 참조하여 제가 커리어 전반에 걸쳐 성공과 실패에 대해 배운 가장 중요한 교훈을 몇 가지 나열해 보겠습니다.

 

교훈 #1: 스펙이 될 수 있는 기술 스택

첫 번째 교훈은 소프트웨어 개발자보다는 PM들과 HR 매니저에게 더 필요한 교훈입니다.

"배우거나 벌어라"라는 조언은 경력을 시작하는 사회 초년생일 때는 맞는 말이지만, 경력이 쌓이면서 "배우거나 벌어서는 안 된다"로 바뀌게 됩니다.

지난 40년 동안 소프트웨어 산업은 몇 가지 온프레미스 기술 스택을 사용하는 평생직장의 상호 의존적 관계에서 -> 지나치게 짧은 근속 기간으로 바뀌었고, 고용주들은 '잡 호핑'을 부정적인 특성으로 재고하게 되었습니다.

그 결과, 한 직장에서의 정년 퇴직이 익숙했던 직원들은 이제 가만히 앉아 있기만 해도 구식이 되어가는 현실과 씨름해야 합니다.

저는 어떤 기술에 대해 개인적인 판단을 내리는 것이 아닙니다. 다만 고용주가 점점 더 자동화를 통해 후보자의 이력서를 판단하는 일반적인 채용 관행에 대해 말해보고자 합니다.

 

인사 담당자는 나온지 오래된 기술을 다루는 동안, 최신 트렌드를 파악하기 위해 정기적인 공식 교육을 받는 것이 좋다고 말할 수 있습니다. 그러나 소프트웨어 개발자와 고용주들 사이에서는 실무에서 연습하지 않은 기술은 망각과 무관심 사이에서 빠르게 사라진다는 사실을 알죠.

예를 들어, 고용주가 5년의 React 경력을 가진 사람을 필요로 하는 경우, 2년 전에 수강한 React 수업에 대한 내용이 포함되어 있다고 할지라도, React가 아닌 JavaServer Faces의 실무 경력만을 보여주는 사람은 높게 평가할리 없습니다. 또한 반대로 오늘날 JavaServer Faces를 기본 UI 프레임워크로 사용하는 모든 회사는 새로운 인재를 유치하는 데 어려움을 겪을 가능성이 높죠.

이러한 이유로 고용주 입장에서는 이를 인정하기 어려울 수 있지만, '스펙' 관점에서 볼 때 회사의 기술 스택은 직원에게 가장 중요한 요소입니다.

물론 나쁜 상사는 직원을 그만두게 만들 수 있지만, 아무리 훌륭한 상사라도 고용 시장에서 수요가 줄어드는 기술 스택으로 일할 사람을 채용하는 데 어려움을 겪을 것입니다.

PM이나 회사가 고용 가능성을 이유로 기술 스택의 일부를 바꾸는 것에 관심이 없는 것은 이해하지만, HR 리더와 주기적으로 대화를 나누면서 기술 스택이 앞으로 인재를 고용하는 데 있어서 어떤 영향을 줄지 정도는 이해하는 것이 필요합니다. 

 

교훈 #2: 3년을 노후화 기간으로 보기

특정 기술 스택은 아주 오랫동안 시장에서 살아남을 수도 있습니다. COBOL과 같은 프로그래밍 언어나 메인프레임과 같은 하드웨어 기술의 지속적인 영향력만 봐도 알 수 있죠.

하지만 모든 기술 스택이 그런 것은 아닙니다.

일반적으로 새로운 기술이, 기술 커뮤니티에서 인기가 떨어진다고들 말하는 마법의 기간은 바로 '3년'입니다. 

앞으로 어떤 방향으로 경력을 쌓아나갈지, 혹은 앞으로 어떤 기술을 배울지 고민중이라면 지금 유행하는 것을 쫓기보다 향후 3년 내에 어떤 기술이 인기를 끌지 살펴보세요. 

단, '3년'은 과거의 경험을 기반을 토대로 한 기간이라는 점을 명심하세요.

이에 대한 증거로서 지난 10년간 프로그래밍 언어 채택의 진행 상황을 GitHub의 사용자 활동 분석을 통해 간접적으로 측정한 것을 보여드리겠습니다:

 

 

프로그래밍 언어를 기술 스택의 프록시로 사용하는 이유는 무엇인가요? 라고 질문을 하실까봐...

 

어떤 프로그래밍 언어가 채택되는가,는 '인기 있는 Rails 프레임워크에 묶여 있는 Ruby의 운명', '메인프레임 에코시스템에만 의존하는 COBOL 채택', '.Net 플랫폼에서 선택되는 프로그래밍 언어인 C#' 등 기술 환경의 변화와 연관되어 있기 때문입니다.

2015년부터 2018년까지 3년 동안 루비 프로그래밍 언어는 순위가 5위에서 10위로 급격히 하락하여, 프로그래밍 언어 인기 순위에서 부동의 챔피언이었던 타입스크립트의 인기 상승세에 밀려났습니다.

참고로, 2017년부터 2020년까지 3년 동안 타입스크립트는 10위에서 4위로 급상승했습니다.

그리고 웹 개발 프레임워크의 확산에도 불구하고 2019년까지 굳건히 자리를 지켰던 PHP는 2022년까지 4위에서 7위로 급격히 순위가 떨어졌습니다.

 

즉, 지금 커리어를 시작하는 입장이라면 주류가 아닌 프로그래밍 언어를 마스터하는 것은 향후 취업에 있어서 방해가 될 수 있습니다.

여기서 '주류'란 프론트엔드 개발을 위한 Javascript, 머신러닝을 위한 Python, 시스템 개발을 위한 Go와 같은 선택지를 의미합니다. 예를 들어 Go 대신 Rust를 선택하는 등.. 물론 구체적인 예에 동의하지 않을 수도 있지만 원칙 자체는 같습니다.

레슨 #3: 최첨단을 조심하세요

버스를 자주 타본 사람이라면 누구나 중요한 판단을 내리는 법을 배웠을 것입니다. 무슨 말이냐고요?

1분 뒤에 버스가 정류장에 도착한다는 표시가 뜹니다. 그때 여러분은 저기 멀리서 버스가 오는 것을 보게 되죠. 이때 여러분은 정류장까지 전력 질주할지 아니면 다음 버스를 기다릴지 결정해야 합니다.

또한 이미 움직이는 버스를 쫓아가는 것은 거의 가치가 없다는 것을 이미 알고 있을 것입니다.

미래 트렌드를 살펴볼 때는 현재 얼마나 그 언어가 뜨고 있는지보다 앞으로 그 언어의 고용 가능성을 주시하는 것이 중요합니다. 새로운 트렌드를 무시하라는 뜻은 아닙니다. 새로운 트렌드에 뛰어드는 것 자체가 보람이 될 수 있지만, 아까 말했듯이 여러분을 고용할 직책은 고용 가능성을 고려해서 기술 스택을 바꾸거나 하지는 않기에 트렌드에 올인하라고 조언하고 싶지는 않습니다.

2013년부터 2015년까지의 3년은 클라우드 컴퓨팅과 컨테이너 오케스트레이션 분야에 있어서 매우 중요한 시기였습니다. 이 시기에 Cloud Foundry와 Docker는 컨테이너 오케스트레이션 분야에서 선두 주자로 자리 잡았죠. 저의 당시 고용주는 Cloud Foundry의 개발자들과 협력하여 2014년 초에 서비스를 출시했고, 이 서비스는 블루믹스로 알려지며 Cloud Foundry 배포 중 세계 최대의 규모로 성장했습니다.

그러나 아시는 분도 계시겠지만, 같은 해 말 구글이 쿠버네틱스를 발표했습니다. 쿠보네틱스는 구글의 대규모 워크로드를 지원할 정도의 기술이었고, 엄청난 투자와 사람들의 지지를 받으며 빠르게 성장했습니다. 쿠버네틱스의 등장은 Cloud Foundry와 도커의 동력을 크게 약화시켰고, 이 두 플랫폼은 점점 사람들의 관심에서 멀어져갔습니다. 

 

이 시기동안 저는 다양한 배경을 가진 사람들을 만났고, 큰 규모의 프로젝트에서 요구되는 능력을 성장시킬 수 있었습니다. 또한 소프트웨어 개발자로서 다양한 경험을 쌓는 것의 중요성도 깨달았습니다. 

 

그러나 이후 쿠버네틱스의 급 부상으로 클라우드 파운드리 관련 기술이 시장에서 점점 중요도를 잃어갔고, 저는 이 기술이 더 이상 시장에서 가치가 없게 되었다는 것을 느꼈습니다. 이 경험은 기술의 변화에 유연하게 대응하는 것의 중요성을 깨닫게 해주었으며, 지속적인 학습이 IT 분야에서의 성공을 이루는 데 핵심 요소라는 것을 다시금 알게되었습니다.

교훈 #4: 특수한 분야의 프로젝트 참여하는 것은 신중하게 결정하세요

이번 교훈은 제가 클라우드 파운드리에서 일한 후 참여했던 프로젝트에서 느낀 것입니다. 이 프로젝트는 종양학 분야의 의료계 인사들을 대상으로 한 프로덕트를 제작하는 것이었으며, 생물정보학과 자연어처리에 중점을 두고 있었습니다.

 

저는 실험실에 있는 과학자들과 실제 의사들과 함께 일할 수 있다는 생각에 큰 기대를 갖고 있었습니다. 특히 종양학자들이 암 환자를 위한 대체 치료법을 찾는 과정에서 NLP를 적용한다니! 앞서 말한 "의미와 목적"에 대한 제 욕구를 충족시키는 프로젝트였죠.

 

그러나 3년이 지나면서 이 프로젝트에 사용된 기술 스택이 시대와는 맞지 않게 뒤떨어지기 시작했습니다. 모든게 가상 머신에서 실행되었고, 컨테이너 기술은 없었습니다. 사용된 기술들은 당시에는 최선의 선택이었겠지만 시간이 지나면서 점점 구시대적으로 변했습니다.

 

예를 들어, 저희는 소스 코드 관리에 Jazz를 사용했습니다. 제가 프로젝트에 참여했을 당시 회사는 깃헙과 파트너십을 맺고 있었지만 모든 개발자를 깃으로 재교육하는 것이 비효율적이라고 판단해 Jazz에서 깃헙으로 이전하지 않았습니다.

 

이런 결정들은 비즈니스 측면에서는 효율적이라고 할지라도 소프트웨어 개발자인 저에게는 기술적으로 도태되는 지름길이었습니다. 예를 들어, 데이터베이스에 저장된 유전자 샘플의 변경 사항을 쿼리할 때 생물학적 지식이 필요하지 않았습니다. 중요한 것은 데이터 구조를 이해하고 팀과의 원활한 소통 능력이었습니다.

 

그러나 시간이 지나면서 NoSQL같은 기술에 대한 수요가 증가했고, 파이썬같은 프로그래밍 언어에 대한 선호도가 높아졌습니다. 불과 몇 년만에 저희가 사용하던 기술 스택은 새로운 프로젝트들에서 고려조차 하지 않는 수준으로 바뀌었죠.

 

결국 이런 상황 탓에 저희는 이후 개발자를 채용하는 데 있어서 난황을 겪었고, 이 프로젝트가 끝날 무렵에는 제 클라우드 파운드리 기술이 시장에서 가치를 잃었음을 깨달았습니다.

 

교훈 #5. 시간이 없다고 느껴진다면, 진짜 없는 것이다.

 

버스를 타는 것에 비유하자면, 버스를 놓치는 것보다 버스를 잘못 타는 게 더 안 좋은 일이죠. 제가 클라우드 파운드리에서 실패한 후 다른 분야로 넘어간 사이에 6년이란 시간이 훌쩍 지났습니다. 중간 경력 단계에서 6년은 위험할 정도로 긴 시간이죠. 

 

새로운 직장을 찾고 쿠버네틱스 분야에서 자리를 잡는 데까지 3년이 더 걸렸습니다. 그렇게 9년을 보냈습니다.

 

 

물론 잘못된 방향이라는 것은 상대적이며, 다양한 배경 지식을 쌓는 것은 좋은 일일 수 있습니다. 그러나 기술 분야에서의 경력을 시작한다면, 중요한 기술 변화를 놓치거나 경력의 우회로에 빠지는 것에 대해 늘 경계해야합니다. 시간은 있지만 경력은 년 단위로 측정되며 해가 갈수록 회복하기 어려워지거든요.

 

결론적으로, 어떤 로드맵을 설계하든 자신의 우선순위에 따라 자신의 커리어를 지속적으로 검토하는 시간을 가질 필요가 있습니다. 잘못된 커리어라는 건 없지만, 신중하게 선택해야하는 갈림길에 놓이게 되는 경우가 있으니까요. 예를 들어 위험한 선택에 대해 어떤 베팅을 할지, 내 직업이 경력적인 측면에서 위험한지 아닌지 등, 이럴 때 프레임 워크는 판단을 내리는 데 있어 정말 좋은 도구입니다.

 

여러 앱들에 분산되어 있는 내 정보들을 토글에서 한 번에 검색하고 이용하세요! 개발자들은 모두 사용하는 토글!

 

 

 

원문:https://medium.com/@dnastacio/hierarchy-of-career-priorities-c18768d32598