<div id="readability-page-1" class="page"><article>
        <p>개발자가 귀한 시대이다. 여러 IT 회사들이 개발자를 모시기 위해 경쟁을 하고 있다.<br>국내에서는 여전히 생소한 용어지만 나름 이름 있는 IT 회사들은 Developer Relations(DevRel) 라고 하는 대외 개발자들을 대상으로 홍보하는 조직을 구성하여 운영하거나 최소한 HR팀에서 개발자 채용이나 홍보 등을 전담으로 하는 경우도 많이 있다. 필자도 얼마전 T사에서 근무하는 지인이 개발자 채용에 관련해서 조언을 구하기도 했다.</p>
<p>하지만 이 역시 빈익빈부익부 현상이 존재한다. 과거에는 영세한 IT 회사들이 돈이 없다보니 오히려 똘똘한 신입을 채용해서 가르쳐서 써야겠다는 생각들을 하는 곳도 있었지만 지금은 IT 업계에 자금이 넘쳐나다보니 바로 업무에 투입될 수 있는 경력직을 훨씬 선호한다. 그리고 경력직 안에서도 과거부터 현업에서 가장 가성비가 좋다고 했던 대리급 직원에 해당하는 연차가 4-6년차 정도 되는 개발자인 것 같다. 보통 4-6년차 정도 되면 어느 정도 소프트웨어 개발의 전반적인 부분을 경험하고 시간만 있다면 무엇이든 만들 수 있다는 자신감이 붙는 시기이다. 또한 이 정도 시기까지는 비교적 반복적인 경험보다는 새로운 경험을 많이 해왔기 때문에 연차와 실력이 어느 정도 상관관계를 유지할 수 있는 연차라고 생각한다.</p>
<h2 id="개발자-커리어와-시니어의-현실"><a href="#개발자-커리어와-시니어의-현실" title="개발자 커리어와 시니어의 현실"></a>개발자 커리어와 시니어의 현실</h2><p>문제는 그 이후라고 볼 수 있다. <b>개발자들과 관련된 통계 데이터를 보면 40대 이상은 최근의 여러 통계에서 최대 15%가 넘지 않는다.</b> 어느 정도 오차가 존재할 수 있다고는 해도 여기에서 크게 벗어나지는 않을 것이다. 요즘같은 100세 시대에서 40대에 은퇴를 생각해야 한다는 것은 참으로 암담한 일이다. 왜 이런 일이 발생할까?</p>
<p>필자가 개발자 채용을 위해 10년 이상의 경력을 지닌 개발자의 인터뷰에 참여하다보면 연차에 비해 너무나도 부족한 경험과 역량에 큰 실망을 하고 나오는 경우가 많다. 누구나 개발자로 열심히 살아가다보면 4~6년차에 비교적 잘나가는(?) 시절이 온다. 그렇기 때문에 이제까지 해왔던 것처럼 열심히 일하면 계속 인정받을 수 있을 것이라는 착각을 하게 된다. 문제는 그저 그렇게 열심히 일하기만 한다면 이제까지 해왔던 반복적인 경험에 그치게 된다는 것이다. 뿐만 아니라 잘못된 습관이 배어있거나 개인의 경험에서 비롯되는 확증편향을 지니고 있는 경우도 많다. 역량을 향상시키려면 단순히 열심히 일하거나 지식을 쌓는 것만이 아니라 <a href="https://wonderer80.github.io/2021/06/23/%EB%8B%B9%EC%8B%A0%EC%9D%B4-%EC%95%84%EB%AC%B4%EB%A6%AC-%EA%B3%B5%EB%B6%80%ED%95%B4%EB%8F%84-%EA%B0%9C%EB%B0%9C-%EC%8B%A4%EB%A0%A5%EC%9D%B4-%EB%8A%98%EC%A7%80-%EC%95%8A%EB%8A%94-%EC%9D%B4%EC%9C%A0/">의도적 수련</a> 이 필요하다. </p>
<p><img src="https://upload.wikimedia.org/wikipedia/commons/4/49/Dunning-Kruger-Effect-en.png" alt="Dunning-Kruger Effect" title="더닝 크루거 효과로 인한 과도한 자신감은 덤"></p>
<p>그런데 의도적 수련도 필요하지만 어떤 역량을 향상시켜야 할지도 고민이다. 앞으로 어떤 역할들을 수행해나갈 것인가에 따라 발전시켜야 하는 역량도 달라질텐데 이러한 개발자 커리어에 대해 명확하게 누군가 제시해주는 경우도 드물다. 작은 IT 회사에서는 개발자를 주니어/시니어로 나누기도 하고 주니어/미들/시니어 로 나누기도 하는데 대략 3년차 정도까지는 주니어, 4년차 이상부터 미들, 10년차 이상을 시니어급 정도로 생각하는 것 같다. 근데 문제는 미들과 시니어가 어떤 차이가 있는지 개발자는 물론 회사에서도 명확하게 정의를 못내리는 경우가 많다보니 어떤 역량을 내가 향상 시켜야하는지 알기 어렵다. 필자 역시 그런 고민의 과정을 거쳤고 많은 시행착오를 거쳐왔다. 그래서 이제는 나를 비롯하여 같이 일하는 후배들이 길을 잃지 않도록 어떻게 커리어를 설계하고 방향을 제시해야하는지 고민을 많이 해왔다.</p>
<h2 id="Career-Ladder"><a href="#Career-Ladder" title="Career Ladder"></a>Career Ladder</h2><p>실리콘밸리의 유명 IT 회사들은 저마다의 <a target="_blank" rel="noopener" href="https://www.levels.fyi/?compare=Microsoft,Apple,Amazon,Google,Facebook&amp;track=Software%20Engineer">커리어 레벨과 보상체계</a>를 가지고 있는데 구체적으로 레벨 별 필요 역량과 역할을 설명해주는 글은 찾기 어려웠다. 다만 작년에 참고할 수 있는 좋은 자료를 하나 발견하게 되었는데 <a target="_blank" rel="noopener" href="http://www.engineeringladders.com/">Engineering Ladders</a> 라고 하는 프레임워크이다. 좋은 자료라고 판단되어 회사 동료들과 한글로도 <a href="https://wonderer80.github.io/engineeringladders/">번역</a>했으니 영문이 어려운 분들은 부족하나마 참고해주었으면 좋겠다.</p>
<p>Engineering Ladder를 보면 Level, Seniority, Ladder로 구분했는데 여기서 Seniority를 보면 Senior 단계에서부터 Lead 급 Ladder 에 대한 역할들이 추가 된다. Tech Lead는 비교적 익숙한 표현인 반면 Engineering Manager는 국내에선 여전히 생소한 역할이다. 물론 Tech Lead 역시 익숙한 표현일뿐 구체적으로는 어떤 역할을 해야하는지 잘 모르고 그저 개발 역량이 뛰어난 사람 정도로 이해하는 경우가 많다. </p>
<p><a target="_blank" rel="noopener" href="https://abseil.io/resources/swe_at_google.2.pdf">Software Engineering at Google</a>을 보면 구글에서도 하나의 팀에는 Tech Lead와 Engineering Manager로 구성된 리더가 존재한다고 한다. 이러한 리더들은 굉장히 중요하고 넓은 영향력을 끼치게 되므로 팀에서 매우 중요한 역할을 하게 된다. 개발자로서 선택할 수 있는 커리어 단계로 이 두가지를 언급한 이유는 우리가 한명의 개발자 개인으로서 팀에 기여하는데에는 한계가 있기 때문이다. 개발자간의 생산성은 개인 간에 20배 이상의 차이도 있다고는 하지만 그것이 연차와 비례한다는 이야기는 아니다. 개인이 낼 수 있는 퍼포먼스에는 한계가 있기 때문에 냉정하게 보았을 때 회사에서도 굳이 역할이나 생산성 측면에서 큰 차이가 없는데 몸값은 비싸고 나이도 많은 개발자를 채용했을 떄의 메리트는 떨어진다. </p>
<p>물론 Engineering Ladder 에서도 Developer 로서의 Ladder 도 제안하고 있지만 나는 개인적으로 특정 기술에 대한 스페셜리스트로서 경력을 쌓아온 것이 아니라고 한다면 일반적인 IT 서비스 회사에서 높은 레벨의 Developer 로 성장하기는 쉽지 않다고 생각한다. 뿐만 아니라 결국 Developer 도 높은 레벨에 도달하려면 Tech Lead나 Engineering Manager가 갖춰야하는 역량을 지녀야 한다. 일정 수준 이상의 전문성을 갖추려면 결국 넓은 시야와 경험을 갖춰야하기 때문이다.</p>
<p>오늘은 시니어 개발자로서 고려할 수 있는 커리어 래더에 대해 간단한게 소개를 해보았다. 다음 글에서는 Tech Lead 와 Engineering Manager는 어떤 역할을 수행하며 어떤 역량을 갖춰야하는지 구체적으로 이야기해보도록 하겠다.</p>
<h2 id="참고-자료"><a href="#참고-자료" title="참고 자료"></a>참고 자료</h2><h3 id="DevRel"><a href="#DevRel" title="DevRel"></a>DevRel</h3><ul>
<li><a target="_blank" rel="noopener" href="http://channy.creation.net/blog/1194">http://channy.creation.net/blog/1194</a></li>
<li><a target="_blank" rel="noopener" href="https://techblog.woowahan.com/3799/">https://techblog.woowahan.com/3799/</a></li>
<li><a target="_blank" rel="noopener" href="https://engineering.linecorp.com/ko/blog/line-plus-developer-relations-team/">https://engineering.linecorp.com/ko/blog/line-plus-developer-relations-team/</a></li>
</ul>
<h3 id="개발자-통계"><a href="#개발자-통계" title="개발자 통계"></a>개발자 통계</h3><ul>
<li><a target="_blank" rel="noopener" href="https://insights.stackoverflow.com/survey/2021#developer-profile-demographics">https://insights.stackoverflow.com/survey/2021#developer-profile-demographics</a></li>
<li><a target="_blank" rel="noopener" href="https://www.jetbrains.com/ko-kr/lp/devecosystem-2021/demographics/">https://www.jetbrains.com/ko-kr/lp/devecosystem-2021/demographics/</a></li>
<li><a target="_blank" rel="noopener" href="https://programmers.co.kr/pages/2021-dev-survey#dev-part-2">https://programmers.co.kr/pages/2021-dev-survey#dev-part-2</a></li>
</ul>

    </article></div>

wonderland

개발자가 귀한 시대이다. 여러 IT 회사들이 개발자를 모시기 위해 경쟁을 하고 있다.
국내에서는 여전히 생소한 용어지만 나름 이름 있는 IT 회사들은 Developer Relations(DevRel) 라고 하는 대외 개발자들을 대상으로 홍보하는 조직을 구성하여 운영하거나 최소한 HR팀에서 개발자 채용이나 홍보 등을 전담으로 하는 경우도 많이 있다. 필자도 얼마전 T사에서 근무하는 지인이 개발자 채용에 관련해서 조언을 구하기도 했다.
하지만 이 역시 빈익빈부익부 현상이 존재한다. 과거에는 영세한 IT 회사들이 돈이 없다보니 오히려 똘똘한 신입을 채용해서 가르쳐서 써야겠다는 생각들을 하는 곳도 있었지만 지금은 IT 업계에 자금이 넘쳐나다보니 바로 업무에 투입될 수 있는 경력직을 훨씬 선호한다. 그리고 경력직 안에서도 과거부터 현업에서 가장 가성비가 좋다고 했던 대리급 직원에 해당하는 연차가 4-6년차 정도 되는 개발자인 것 같다. 보통 4-6년차 정도 되면 어느 정도 소프트웨어 개발의 전반적인 부분을 경험하고 시간만 있다면 무엇이든 만들 수 있다는 자신감이 붙는 시기이다. 또한 이 정도 시기까지는 비교적 반복적인 경험보다는 새로운 경험을 많이 해왔기 때문에 연차와 실력이 어느 정도 상관관계를 유지할 수 있는 연차라고 생각한다.
개발자 커리어와 시니어의 현실
문제는 그 이후라고 볼 수 있다. 개발자들과 관련된 통계 데이터를 보면 40대 이상은 최근의 여러 통계에서 최대 15%가 넘지 않는다. 어느 정도 오차가 존재할 수 있다고는 해도 여기에서 크게 벗어나지는 않을 것이다. 요즘같은 100세 시대에서 40대에 은퇴를 생각해야 한다는 것은 참으로 암담한 일이다. 왜 이런 일이 발생할까?
필자가 개발자 채용을 위해 10년 이상의 경력을 지닌 개발자의 인터뷰에 참여하다보면 연차에 비해 너무나도 부족한 경험과 역량에 큰 실망을 하고 나오는 경우가 많다. 누구나 개발자로 열심히 살아가다보면 4~6년차에 비교적 잘나가는(?) 시절이 온다. 그렇기 때문에 이제까지 해왔던 것처럼 열심히 일하면 계속 인정받을 수 있을 것이라는 착각을 하게 된다. 문제는 그저 그렇게 열심히 일하기만 한다면 이제까지 해왔던 반복적인 경험에 그치게 된다는 것이다. 뿐만 아니라 잘못된 습관이 배어있거나 개인의 경험에서 비롯되는 확증편향을 지니고 있는 경우도 많다. 역량을 향상시키려면 단순히 열심히 일하거나 지식을 쌓는 것만이 아니라 의도적 수련 이 필요하다. 
그런데 의도적 수련도 필요하지만 어떤 역량을 향상시켜야 할지도 고민이다. 앞으로 어떤 역할들을 수행해나갈 것인가에 따라 발전시켜야 하는 역량도 달라질텐데 이러한 개발자 커리어에 대해 명확하게 누군가 제시해주는 경우도 드물다. 작은 IT 회사에서는 개발자를 주니어/시니어로 나누기도 하고 주니어/미들/시니어 로 나누기도 하는데 대략 3년차 정도까지는 주니어, 4년차 이상부터 미들, 10년차 이상을 시니어급 정도로 생각하는 것 같다. 근데 문제는 미들과 시니어가 어떤 차이가 있는지 개발자는 물론 회사에서도 명확하게 정의를 못내리는 경우가 많다보니 어떤 역량을 내가 향상 시켜야하는지 알기 어렵다. 필자 역시 그런 고민의 과정을 거쳤고 많은 시행착오를 거쳐왔다. 그래서 이제는 나를 비롯하여 같이 일하는 후배들이 길을 잃지 않도록 어떻게 커리어를 설계하고 방향을 제시해야하는지 고민을 많이 해왔다.
Career Ladder
실리콘밸리의 유명 IT 회사들은 저마다의 커리어 레벨과 보상체계를 가지고 있는데 구체적으로 레벨 별 필요 역량과 역할을 설명해주는 글은 찾기 어려웠다. 다만 작년에 참고할 수 있는 좋은 자료를 하나 발견하게 되었는데 Engineering Ladders 라고 하는 프레임워크이다. 좋은 자료라고 판단되어 회사 동료들과 한글로도 번역했으니 영문이 어려운 분들은 부족하나마 참고해주었으면 좋겠다.
Engineering Ladder를 보면 Level, Seniority, Ladder로 구분했는데 여기서 Seniority를 보면 Senior 단계에서부터 Lead 급 Ladder 에 대한 역할들이 추가 된다. Tech Lead는 비교적 익숙한 표현인 반면 Engineering Manager는 국내에선 여전히 생소한 역할이다. 물론 Tech Lead 역시 익숙한 표현일뿐 구체적으로는 어떤 역할을 해야하는지 잘 모르고 그저 개발 역량이 뛰어난 사람 정도로 이해하는 경우가 많다. 
Software Engineering at Google을 보면 구글에서도 하나의 팀에는 Tech Lead와 Engineering Manager로 구성된 리더가 존재한다고 한다. 이러한 리더들은 굉장히 중요하고 넓은 영향력을 끼치게 되므로 팀에서 매우 중요한 역할을 하게 된다. 개발자로서 선택할 수 있는 커리어 단계로 이 두가지를 언급한 이유는 우리가 한명의 개발자 개인으로서 팀에 기여하는데에는 한계가 있기 때문이다. 개발자간의 생산성은 개인 간에 20배 이상의 차이도 있다고는 하지만 그것이 연차와 비례한다는 이야기는 아니다. 개인이 낼 수 있는 퍼포먼스에는 한계가 있기 때문에 냉정하게 보았을 때 회사에서도 굳이 역할이나 생산성 측면에서 큰 차이가 없는데 몸값은 비싸고 나이도 많은 개발자를 채용했을 떄의 메리트는 떨어진다. 
물론 Engineering Ladder 에서도 Developer 로서의 Ladder 도 제안하고 있지만 나는 개인적으로 특정 기술에 대한 스페셜리스트로서 경력을 쌓아온 것이 아니라고 한다면 일반적인 IT 서비스 회사에서 높은 레벨의 Developer 로 성장하기는 쉽지 않다고 생각한다. 뿐만 아니라 결국 Developer 도 높은 레벨에 도달하려면 Tech Lead나 Engineering Manager가 갖춰야하는 역량을 지녀야 한다. 일정 수준 이상의 전문성을 갖추려면 결국 넓은 시야와 경험을 갖춰야하기 때문이다.
오늘은 시니어 개발자로서 고려할 수 있는 커리어 래더에 대해 간단한게 소개를 해보았다. 다음 글에서는 Tech Lead 와 Engineering Manager는 어떤 역할을 수행하며 어떤 역량을 갖춰야하는지 구체적으로 이야기해보도록 하겠다.
참고 자료
DevRel
http://channy.creation.net/blog/1194
https://techblog.woowahan.com/3799/
https://engineering.linecorp.com/ko/blog/line-plus-developer-relations-team/
개발자 통계
https://insights.stackoverflow.com/survey/2021#developer-profile-demographics
https://www.jetbrains.com/ko-kr/lp/devecosystem-2021/demographics/
https://programmers.co.kr/pages/2021-dev-survey#dev-part-2

경쟁력있는 시니어 개발자로 성장하는 방법

댓글