개요
이공계 천대라는 이야기가 무색해진지 꽤 오랜 시간이 흘렀고, 개발자 지망생들도, 개발자가 된 사람들도 많아졌다.
그로 인해 지금의 주니어 분들이 성장해서 시니어 개발자가 되면, 시니어 개발자 부족 시기를 지나 시니어 개발자가 더 많아지고 더 치열해질 수밖에 없다.
개발자에 대한 처우가 좋아지면서 경쟁력 있는 주니어를 채용하고자 하는 분위기가 생긴 것도 사실이다. 투자가 줄어들면서 인재 채용에 조금 더 까다로워진 것도 같다.
좋은 동료, 좋은 처우, 좋은 환경을 위해서는 많아진 개발자의 수와 실력에 걸 맞은 경쟁력을 갖춰나가야 하는 시기라고 볼 수 있다.
이 글에서는 개발자 커리어에서 강점을 갖추는 방법에 대해 이야기해 보고자 한다.
정의
커리어 관리란 무엇일까?
흔히 말하는 첫 회사를 잘 가야 한다? 이직을 잘해야 한다?
어느 정도 맞는 이야기다.
당연히 첫 회사도 좋고, 이직도 잘한다면 더 할 나위 없을 것이다.
원하는 회사를 첫회사로 갈 수 없게 되더라도, 혹은 내가 원하는 회사에 입사해서 커리어를 시작했더라도 커리어 관리는 중요하다.
이 글에서 커리어 관리에 대해 어떤 역량과 경쟁력을 갖출지를 주 포인트로 이야기할 것이다.
특장점
자신만의 특장점을 갖추는 것이 좋다.
예를 들어 근면 성실하게 학습하는 개발자, 러닝 커브가 가파른 개발자, 신 기술에 호기심이 많은 개발자, 동료와 소통과 협을 잘하는 개발자, 디버깅을 잘하는 개발자, 원리에 대한 깊은 이해가 있는 개발자, 대용량 처리 경험이 있는 개발자, 병렬 처리에 대한 높은 이해가 있는 개발자 등이 있을 수 있다.
특장점을 목표로 잡고, 어떻게 이를 달성해 나갈지 고민해 보는 것이 좋다.
세부적인 목표는 다음과 같은 예시가 있을 수 있겠다.
- 성실하게 학습하는 개발자
- 러닝 커브가 가파른 개발자
- 신 기술에 호기심이 많은 개발자
- 동료와 소통과 협업을 잘하는 개발자
- 디버깅을 잘하는 개발자
- 원리에 대한 깊은 이해가 있는 개발자
- 대용량 처리 경험이 있는 개발자
- 병렬 처리에 대한 높은 이해가 있는 개발자
- DB 이해도가 높은 개발자
경험의 종류
회사에서 업무를 통해 할 수 있는 경험은 어떤 것들이 있을까?
나열한 경험들 외에도 있겠지만, 경험을 많이 할수록 경쟁력에 도움이 된다.
대용량 처리
트래픽을 많이 다뤄본다는 의미는 꽤 크다. 백엔드 개발자라면 더욱 크지만, 프론트엔드를 비롯한 다른 포지션에도 매우 유의미하다.
트래픽이 많이 발생한다는 것은 결국 서비스에 이슈가 많다는 것이라서, DB 이슈를 많이 다뤄봤느냐가 되기도 하지만, 작성된 코드의 명확한 동작 원리, 사용하는 프레임워크의 동작 원리, 제약 사항, 기술적 선택의 장단점 같은 이해도를 높이게 될 계기를 많이 맞이할 수 있다는 의미기도 하다.
인프라 경험
On Premise 환경이던 시절에는 인프라를 개발자가 다루는 일이 있긴 했지만, System Engineer가 주로 다뤄야 했으며, 머신의 발급, 반납 절차가 매우 까다로웠기 때문에 인프라 경험이 개발자에게 주된 경험은 아니었다.
하지만 클라우드 시대로 전환되면서, VM, 이제는 Docker/K8S 환경에서 유연하게 운영됨에 따라 인프라를 개발자가 만지는 일이 많아졌고, 그에 따라서 인프라에 대한 이해도와 경험을 얻을 수 있게 됐다.
밀접한 협업 경험
좋은 업무 경험은 동료에게 도움을 받고 성장하는 경험, 도움을 주는 경험, 평균을 끌어올리는 과정 등이 내포되어 있다고 보면 된다.
그 과정에서 좋은 동료를 만났다면 성장을 크게 할 것이고, 본인이 좋은 동료라면 좋은 시니어가 될 자격을 갖춘 것이라고 볼 수 있다.
좋은 동료에게서 배운 경험
배우되 좋은 동료에게서 배워야 한다. 그래서 위에 언급한 협업 경험과 더불어 어떠한 동료들을 좋아하며, 동료의 가치관에 대해서 묻는다. 이것을 인성이라 부르기도 하지만, 나는 이러한 좋은 경험이 좋은 개발자가 될 계기가 되는 자산이자 경험이라고 본다.
서비스 경험
서비스 경험 유무를 따지는 이유는 서비스 경험이 없이는 특정한 조건 하에서만 잘 돌아가는 코드를 작성했을 가능성이 높기 때문이다.
또한 QA와 서비스 문의 등을 통해서 낮은 확률로 발현되는 이슈까지 수정하는 경험이 쌓였을 때, 비로소 문제가 덜 되는 코드를 만들어내게 되는 거라고 볼 수 있다.
장애 경험
장애 경험 이야기를 하면, 장애를 내보라는 거냐고 물어보시는 분도 계시지만 당연히 그런 얘긴 아니다.
하지만 우리의 서비스는 생각보다 나약하다. 모든 상황을 다 대비할 수 없으며, 대비했더라도 그 이상의 트래픽이나, 외부적 요인, DDOS와 같은 악의적 공격, 스케일 아웃 속도보다 빠른 트래픽 폭발 등의 상황에서 수많은 장애를 겪게 된다.
보통 대부분의 개발자는 일정 준수와 빠른 개발을 요구받는데, 그러다 보면 장애를 대비할 여력이 없다. 그럼에도 수많은 예외 상황을 많이 아는 개발자, 그리고 스케일 아웃을 대비할 줄 아는 개발자와, 이에 대해 무지한 개발자 간의 차이는 크다고 볼 수 있다.
그래서 어떤 개발자가 경쟁력 있다는 얘긴가?
경쟁력은 보는 관점에 따라 다르다.
하지만 많은 회사에서 좋아하는 개발자에게는 공통분모가 있었다.
자기 주도적인 개발자
시키는 일만 잘하는 개발자는, 관리 코스트가 크게 든다.
누군가가 할 일을 만들어 줄 수 있을 때, 우선순위가 높은 업무가 많아 일을 잘 분배할 수 있을 때는 별문제가 되지 않는다. 하지만 일을 만들어 주는 것도 보통 코스트가 많이 드는 일이 아니다. 이를 해줄 누군가가 필요해진다.
또 작업자만이 알 수 있는 디테일이 있으며, 개선안은 작업자에게서 훨씬 좋은 것들이 나오곤 한다.
그리고 그런 태도가 좋은 퀄리티의 결과물로 이어진다.
주변에 긍정적 영향을 주는 개발자
사람은 부정적이든 긍정적이든 주변에 영향을 크게 받는다.
그렇다 보니 요새는 컬쳐핏 면접이라 많이 칭하는데, 어떠한 마인드를 가졌는가, 우리 조직의 기존 구성원에겐 부족하지만, 조직이 원하는 성향을 많이 가졌는가, 혹은 기존 조직의 성향에 위배되는 면이 보였는가를 상호 체크하는 과정이다.
긍정적 영향이라는 말이 조직에 따라 다르기 때문에 그런 것인데, 조직에 따라 다른 관점을 떠나서 얘길 해보면, 솔선 수범하는 개발자라고 볼 수 있겠다.
꾸준한 자기 개발이던, 꼼꼼한 업무 관리던, 이슈 해결에 적극적인 모습이던 뭐든 좋다. 이를 솔선 수범하다 보면 주변에 영향을 크게 주게 된다.
반면 나태한 모습, 의욕 저하된 모습도 주변에 영향을 주기에 이런 사람이 아닌지 확인하는 면도 포함되어 있다.
능동적 커뮤니케이션이 잘 되는 개발자
먼저 물어보고, 계속 물어보고, 답을 얻어내기까지 끈질겨야 한다.
<대체 뭐가 문제야>라는 책을 개인적으로 굉장히 좋아하는데, 이 책이 하고자 하는 메시지는 문제를 해결 가능한 사람이 문제라고 느끼게 해야 된다는 것이다.
보통 내가 중요한 이슈가 전사적 이슈인 경우도 있지만, 대게는 내가 속한 팀, 혹은 나에게 좀 더 중요한 이슈인 경우도 분명히 있다.
이를 해결하고자 하는 자세가 능동적인 개발자를 원한다.
스스로 고민하는 개발자
지금까지 동료의 도움을 받고, 영향을 주거나 받으라고 해놓고 왜 스스로 고민하는 개발자냐고?
바로 스스로 고민한 깊이만큼 다른 사람과 대화를 나눌 수 있기 때문이다.
세상에 많은 이슈가 이미 해결책이 인터넷에 있기도 하지만, 또 어떤 이슈는 키워드를 몰라서, 내가 원하는 해결책에 부족해서, 기존 해결책으로는 해결되지 않는 이슈라서 등이 있다.
내가 어떠한 시도를 해보았고, 어떠한 고찰을 하고 있는지를 잘 정리하며 고민하는 개발자가 이슈를 빠르고 정확하고, 재발되지 않도록 잘 해결한다.
고민 과정은 마인드맵(Mind Map)같은 방식으로 표현하는 것도 좋겠다.
문제 해결 능력이 뛰어난 개발자
개발자는 문제를 해결하는 사람이다.
코드를 작성하는 사람이라고 한정 짓는 사람들도 있지만, 대부분의 회사에서 고 연봉을 지급하면서까지 욕심나는 개발자는 문제 해결 능력이 매우 중요하다.
문제 해결 능력은 장애 대응, 이슈 대응만 얘기하는 것은 아니다.
해결책을, 제품 이해도는 물론, 제품 내부의 동작 원리, 메커니즘을 통해서 비즈니스에 도움이 되는 방향을 제시하는 역할을 해야 한다.
알고리즘이라는 용어도 요즘에는 검색, 정렬 알고리즘을 필두로 코딩 테스트에 필요한 그것으로 일컬어지곤 하지만, 용어 자체의 의미로도 알고리즘은 문제 해결 능력을 위한 과정을 뜻한다.
알고리즘(라틴어, 독일어: Algorithmus, 영어: algorithm)이란 어떠한 문제를 해결하기 위한 여러 동작들의 모임이다. 유한성을 가지며, 언젠가는 끝나야 하는 속성을 가지고 있다. 수학과 컴퓨터 과학에서 알고리즘이란 작동이 일어나게 하는 내재하는 단계적 집합이다. 알고리즘은 연산, 데이터 진행 또는 자동화된 추론을 수행한다.
즉 개발자에게 알고리즘 능력을 본다는 것은, 문제를 어떻게 해결할 줄 아느냐를 보는 것이라고 볼 수 있다.
문제는 꼭 기술적으로 접근하지 않아도 된다.
알고리즘의 사전적 정의는 물론, 실제적 정의에서도 코드 레이어의 해결책 만으로 한정 짓지 않는다.
문제 해결 능력에는 문제 정의도 매우 중요한 의미를 지닌다.
올바른 문제 정의가 되거나, 혹은 창의적인 문제 정의로 다양한 해결책을 제시하는 것도 좋다.
디버깅 능력이 뛰어난 경우 문제 해결 능력이 뛰어난 것과 동의어로 쓰이기도 하는데, 이는 디버깅도 문제 정의, 문제 파악 과정에서 올바른 답을 찾거나, 창의적인 접근으로, 혹은 파편화된 정보를 바탕으로 추론을 통해 문제를 정의해야 되기 때문이다.
그 과정에서의 논리력과, 능력이 증명되기 때문이라고 볼 수 있다.
커리어 관리
자 그래서 위에 언급한 경쟁력 있는 개발자, 많은 회사가 뽑고 싶어 하는 개발자는 무엇인지 알았는데, 어떻게 하라는 것인가?
가능하면, 위에 언급한 경험을 얼마나 할 수 있을지, 면접 과정에서, 혹은 지원 과정에서 최대한 정보를 얻는 것이 좋다.
하지만 정보의 불균형으로 내가 원하는 성장의 환경을 많이 갖춘 팀인지 확인이 어려울뿐더러, 그렇게 팀의 문화를 드러내고 어필하는 팀은 지원자가 많이 몰리고, 이미 그러한 역량을 많이 갖춘 사람을 뽑는 것이 일반적이다. 그래서 너무너무 훌륭한 팀에 준비가 덜 된 상태에서 합류할 확률은 너무 낮다.
그렇다면 개인적으로 할 수 있는 것은, 경쟁력 있는 개발자가 되는 자질을 위한 몇 가지 노력들이 있겠다.
그 실천을 위해서 몇 가지 제안을 하고자 한다.
1. 이슈가 생겼을 때 원인을 반드시 찾기
- 현상이 사라졌거나 우회 방식을 선택했어도 반드시 원인을 끝까지 찾아내야 한다.
- 이슈를 적당히 마무리하는 것도 습관이 되어, 경험으로 승화되기 어렵다.
2. 이슈에 대해서 다양한 방식으로 고민해 보고, 어떠한 고민들을 해봤고 어떠한 고민들을 소거했는지 과정을 시각화하기
- 고민하는 과정은 보통 대부분 하는데, 이를 정리하고 소거하는 습관을 가져야 한다.
- 그래야 원인을 찾는 과정에서의 삽질이 줄어들고, 불필요한 재 검증 과정도 사라지며, 다른 사람에게 이슈를 공유하고 피드백 받기 좋다.
3. 먼저 나서기
- 한 일을 기록하고 공유하기
4. 주변에서 진행하는 업무에도 관심 가지기
- 생각보다 배울게 많고, 성장에 도움이 된다.
- 코드 리뷰 요청도 좋고, 업무 리뷰 요청도 좋다.
- 그 과정을 자신만의 생각과 방식으로 요약해라.
5. 자신의 업무 습관을 많이 드러내고, 주변에 도움을 요청하고, 도움을 줘라
- 물론 고마워하지 않는 사람도 존재하긴 하지만, 그런 상황을 감안해도 자신에게 더 많은 도움이 된다.
- 과정에서 자신이 놓친 것에 대해서 많이 깨닫게 된다.
- 또 피드백에 대해서 기록해 보면, 자신이 자주 실수하는 패턴도 알 수 있고, 다른 사람의 생각과 장점, 인사이트를 공유 받을 수 있다.
이렇게 몇 가지 실천 방안에 대해 알아보았다.
사실 자신이 좋은 팀에 있다면, 내가 제안한 방식들을 실천하고 있지 않다 하더라도 이미 다방면으로 경쟁력 있는 개발자로 성장하고 있을 것이다.
그렇다 하더라도 몇 가지 개선점을 찾고, 어떠한 노력을 기울여야 될지 고민하고 실천해 본다면 훨씬 더 경쟁력 있는 좋은 개발자가 될 수 있을 것이다.
커리어 향상을 위한 상위 1% 개발자들의 멘토링을 제공합니다.
👉 자바 백엔드 코스 보러가기
👉 프론트엔드 코스 보러가기
👉 안드로이드 코스 보러가기
👉 파이썬 심화 코스 보러가기
Copyright ⓒ F-Lab & Company
이 콘텐츠는 F-Lab의 고유 자산으로 상업적인 목적의 복사 및 배포를 금합니다.
