<div id="readability-page-1" class="page"><article>
        <h2 id="왜-리더로-성장해야-하는가"><a href="#왜-리더로-성장해야-하는가" title="왜 리더로 성장해야 하는가?"></a>왜 리더로 성장해야 하는가?</h2><p>국내에서 개발자로 생활하면서 느꼈던 것은 많은 개발자들이 연차가 쌓이면서 관리자 역할을 하는 것에 대해 두려움을 느낀다는 것이었다. 관리자는 기술직이 아니며 관리자로 일한다는 것은 자신의 개발자로서의 전문성을 발휘하지 못하고 점점 도태된다고 느끼기 때문이다. 그렇기에 많은 개발자들은 자신이 백발이 될 때까지 개발을 하고 싶다는 환상을 가지고 있다. </p>
<p>반면 우리가 많은 회사에서 경험한 관리자들은 과거에 개발자였다가 어느 순간 관리자를 맡게 된 사람들이며, 주로 일정 관리나 여러 미팅에 참여하면서 기술적 전문성이 떨어지는 경우가 많았다. 더욱 큰 문제는 과거에는 이들이 한때는 뛰어난 개발자였기에 자기 중심적으로 판단을 내리는 경우가 많고 개발자들은 잘못된 판단임을 알면서도 어쩔 수 없이 따라야하는 상황들도 발생된다는 것이다. 이로 인해 <a target="_blank" rel="noopener" href="https://ko.wikipedia.org/wiki/%ED%94%BC%ED%84%B0%EC%9D%98_%EB%B2%95%EC%B9%99">피터의 법칙</a>처럼 우리는 한명의 훌륭한 엔지니어를 잃고 무능한 관리자를 얻게 되는 경우가 많다.</p>
<p>그럼에도 불구하고 우리가 시니어 개발자로서 성장하면서 관리자(나는 개인적으로 리더라는 표현을 더 좋아한다)가 되어야 하는 이유는 그것이 개발자로서 나의 영향력을 넓혀 나갈 수 있는 방법이기 때문이다. 아무리 개발을 잘하는 개발자라고 해도 개인이 작성할 수 있는 코드에는 한계가 있다. 하지만 당신이 이끄는 개발팀의 많은 개발자들이 훌륭한 코드들을 만들어낼 수 있도록 돕는다면 한명의 개인으로서 코딩을 하는 것보다 훨씬 큰 효과를 만들어낼 수 있다. 그럼 우리가 개발자로서 선택할 수 있는 리더 포지션인 엔지니어링 매니저와 테크리드는 어떤 것일까? 테크리드에 대해서는 한번쯤 들어본 개발자들이 있을 수 있지만 엔지니어링 매니저는 한번도 들어보지 못한 사람들도 많을 것이다. 물론 테크리드라는 포지션 역시 막연하게 기술을 리드하는 개발자 같은 느낌일 뿐 구체적으로 어떤 역할을 해야하는지 모르는 경우가 많다. 그래서 오늘은 두 포지션의 역할과 비교를 해보고자 한다.</p>
<h2 id="Tech-Lead"><a href="#Tech-Lead" title="Tech Lead"></a>Tech Lead</h2><p>많은 개발자들은 여전히 리더가 된다는 것에 부담을 느끼지만 만약 꼭 리더가 되어야한다면 테크리드로 성장하고 싶어한다. 왜냐하면 테크리드가 기존에 개발자로서 하는 일에 가깝다고 생각하기 때문이다. 사실 작은 조직에서는 테크리드라는 포지션이 필요없다. 어차피 개발자가 얼마 없고 스스로 모든 것들을 해야하기 떄문이다. </p>
<p>하지만 서비스가 성장하고 개발조직이 커지게 되면 기술적인 측면에서 리딩을 해야할 필요성이 생긴다. 모든 개발자가 어떤 기준이나 컨벤션 없이 저마다 만들고 싶은 방법과 사용하고 싶은 기술 스택으로 개발해나간다면, 퀄리티에 대한 기준이나 관리 없이 동작가능하게만 만들어나간다면, 서비스는 곧 정체되고 더이상 나아갈 수 없을 것이다. 테크리드는 여전히 일정시간을 코딩에 할애하지만 그것은 직접 문제를 해결하기 위함이 아니라 다른 개발자들이 문제를 해결하기 위한 환경을 만들기 위한 노력 중의 일부일 것이다. 우리는 좋은 개발자를 채용하기 위해 노력하지만 팀에는 다양한 역량과 경험을 가진 개발자들이 속한 조직으로 성장하게 되며 이들을 하나의 방향성으로 이끌어나가야 할 필요성이 생기게 된다.</p>
<p>테크리드는 개발자들의 생산성 향상과 품질 관리를 위해 힘써야 한다. 기술 컨벤션 논의를 이끌고 가이드를 작성해야 한다. 설계나 코드에 대한 리뷰를 직접 하기도 하고 리뷰 문화가 잘 활성화되도록 이끌어야 한다. 여러 팀에서 공통적으로 사용하는 기술을 표준화하고 공통 모듈을 개발하여 사용할 수 있게 하거나 공통 플랫폼을 제공할 수 있도록 해야 한다. 개발팀에서 사용하는 기술 스택들을 관리하고 노후화되지 않도록 전략을 짜야하고 개발자들이 역량을 키울 수 있도록 가이드 해야한다. 시스템 SLA를 수립하고 기술 부채를 어떻게 관리해나갈 것인지에 대한 프로세스를 수립해야 한다. </p>
<p>당신이 이런 것들에 관심을 기울이기 보다는 내 손으로 직접 기능을 개발하는 시간이 대부분이고 이런 부분들은 가끔 생각날 때 한번씩 한다면 테크리드라고 볼 수 없다. 이런 활동들은 엔지니어링 관점에서 매우 중요한 것들이지만 비지니스에 직접적인 영향을 미치지는 않고 급하지 않다고 판단되어 항상 우선순위가 뒤로 미뤄지게 되는 경향이 많다. 하지만 당신이 시니어 개발자로서 책임감 있는 사람이라면 이런 역할의 중요성을 인식하고 소홀히 하지 않도록 해야 한다.</p>
<h2 id="Engineering-Manager"><a href="#Engineering-Manager" title="Engineering Manager"></a>Engineering Manager</h2><p>테크리드는 주로 시스템이나 기술에 대한 부분을 주로 담당한다면 엔지니어링 매니저는 주로 사람을 돕는다. 사실 관리한다는 말은 요즘 시대에 맞지 않는다. 누군가가 나를 관리해줄 것이라는 기대는 버려야 한다. 우리 모두는 스스로가 관리자가 되어야 한다. 그럼에도 불구하고 엔지니어링 매니저가 필요한 이유는 뛰어난 프로선수들도 코치는 필요하기 때문이다. </p>
<p>엔지니어링 매니저는 개발자들이 잘 성장하고 회사에 만족하면서 기여할 수 있도록 돕는다. 1on1을 통해서 목표를 설정하는 것을 돕거나 구성원으로서 잘 성장할 수 있도록 피드백을 준다. 업무를 진행하는데 있어 방해되는 요소를 빠르게 파악하고 장애물을 제거한다. 이러한 것들을 수행하기 위해 엔지니어링 매니저는 소프트웨어 공학과 사람에 대한 깊은 이해를 가지고 개발 프로세스나 팀 문화를 만들고 성장해나갈 수 있도록 도와야 한다. </p>
<p>아쉽게도 개발자들이 테크리드에 비해 엔지니어링 매니저로 성장하기가 좀 더 어려운 이유는 있다. 먼저 엔지니어링 매니저가 하는 역할을 경험해본 적이 없다. 엔지니어링 매니저로서 역할을 수행해보기는 커녕 제대로 된 엔지니어링 매니저가 있는 환경에서 일해본적도 없다. 예를 들어 사람들과 1on1을 진행할 때 필요한 코칭 스킬이나 상담 기법에 대해 아는 것도 전무하다. 개발하면서 스탠드업 미팅이나 회고 같이 파편적으로 어떤 활동 들을 접해본적은 있으나 어떻게 문화를 만들어나가야 하는지 알지 못한다. 심지어는 칸반이나 스크럼을 사용한다는 조직에서 일을 해왔더라도 막상 내가 그것에 대해 제대로 알거나 공부해본 경우도 없다. 우리가 아는 관리자는 WBS 작성이나 간트차트를 그리면서 개발자들에게 업무가 얼마나 진행이 되었는지 확인하고 그래프를 채우는 모습밖에는 잘 알지 못한다. 하지만 테크리드의 역할은 테크리드가 없더라도 암묵적으로 일부 경험있는 개발자가 일정 역할을 수행하기도 하는 반면, 엔지니어링 매니저의 역할은 상대적으로 중요성을 인지하지 못하거나 아무도 수행하고 있지 않기 때문에 오히려 조직에서 크게 결여되는 부분이기도 하다.</p>
<h2 id="Tech-Lead-vs-Engineering-Manager"><a href="#Tech-Lead-vs-Engineering-Manager" title="Tech Lead vs Engineering Manager"></a>Tech Lead vs Engineering Manager</h2><p>이전 글에서도 소개한적이 있는 Engineering Ladder에 다음과 같이 두 역할을 비교한 좋은 내용이 있다.<br><a target="_blank" rel="noopener" href="http://www.engineeringladders.com/TechLead-EngineeringManager.html">http://www.engineeringladders.com/TechLead-EngineeringManager.html</a></p>
<table>
<thead>
<tr>
<th><a href="TechLead.md">Tech Lead</a> (System)</th>
<th><a href="EngineeringManager.md">Engineering Manager</a> (People)</th>
</tr>
</thead>
<tbody><tr>
<td>기술적 탁월함과 혁신</td>
<td>경력관리를 위한 계획, 승진과 코칭</td>
</tr>
<tr>
<td>아키텍쳐와 시스템 통합</td>
<td>인원에 대한 계획과 고용</td>
</tr>
<tr>
<td>기술 멘토링, 채택 및 일치</td>
<td>팀 계획과 전달</td>
</tr>
<tr>
<td>기술적인 <a href="(https://en.wikipedia.org/wiki/Spike_(software_development)#cite_note-1)">스파이크</a>와 실험</td>
<td>목표, 성과와 피드백</td>
</tr>
<tr>
<td>코드 리뷰와 피드백</td>
<td>원온원</td>
</tr>
<tr>
<td>시스템 설계 발표</td>
<td>기술적인 결정에 참여</td>
</tr>
<tr>
<td>기술 생산능력 계획</td>
<td>상위 레벨과 관리 조직간의 커뮤니케이션</td>
</tr>
<tr>
<td>제품 이슈의 보고</td>
<td>팀 빌딩 활동과 문화</td>
</tr>
<tr>
<td>시스템 SLA, 지표와 모니터링</td>
<td>팀 보호와 행복</td>
</tr>
<tr>
<td>플랫폼 방향, 패턴과 연습</td>
<td>팀 생산력과 지표</td>
</tr>
<tr>
<td>다른 테크 리더와의 일치</td>
<td>다른 개발 매니저와의 일치</td>
</tr>
<tr>
<td>30%~70% 시간의 코딩 업무</td>
<td>시간의 0%~30% 시간의 코딩 업무</td>
</tr>
<tr>
<td>시스템 로드맵 (공유)</td>
<td>시스템 로드맵 (공유)</td>
</tr>
<tr>
<td>개발 프로세스 (공유)</td>
<td>개발 프로세스 (공유)</td>
</tr>
<tr>
<td>팀의 가시성과 인정 (공유)</td>
<td>팀의 가시성과 인정 (공유)</td>
</tr>
<tr>
<td>필요할 때 엔지니어링 매니저 역할도 가능한 능력</td>
<td>필요할 때 테크 리더 역할도 가능한 능력</td>
</tr>
</tbody></table>
<p>작은 조직에서는 테크리드와 엔지니어링 매니저의 역할을 겸임하는 TLM(Tech Lead Manager)라는 역할도 있다고 한다. 두 역할의 상당 부분 중엔 겹치는 부분도 많고 상호베타적이지 않기 때문에 두 역할 모두 기술적인 이해를 기반에 갖추어야 하며 필요에 따라 양쪽의 역할을 겸임하거나 오갈 수 있어야 한다. </p>
<h2 id="어떤-리더가-되고-싶은가"><a href="#어떤-리더가-되고-싶은가" title="어떤 리더가 되고 싶은가?"></a>어떤 리더가 되고 싶은가?</h2><p>사실 포지션에 대한 이름이 중요한 것이 아니라 기술 리더로서 어떤 역할들을 수행해 나가야하는지가 중요하다. 테크리드나 엔지니어링 매니저가 우리 회사에 없더라도 이러한 역할을 누군가는 해야하는 중요한 것들이다. 내가 리더가 되고 싶지 않더라도 훌륭한 개발자로 성장하다면 결국엔 명시적이든 암시적이든 리더가 된다. 내가 명시적인 테크리드나 엔지니어링 매니저가 아니라고 해서 이런 역할을 수행하는 필요한 경험이나 역량이 필요없다는 것은 아니다. 뛰어난 개발자는 자기 일에만 집중하는 것이 아니라 큰 시야를 가지고 전체의 효율을 이끌어 내는 일들을 수행한다. 명시적인 리더가 아니더라도 리더들이 하는 역할을 잘 이해하고 돕는 사람이 된다면 리더에게도 굉장히 감사하고 큰 도움이 되는 개발자가 된다. 뿐만 아니라 실리콘밸리의 유명 IT 회사들의 <a target="_blank" rel="noopener" href="https://www.levels.fyi/?compare=Microsoft,Apple,Amazon,Google,Facebook&amp;track=Software%20Engineer">Career Levels</a>가 보여주듯이 결국 높은 레벨로 올라갈수록 리더의 역할을 할 수밖에 없게 된다.</p>
<p>그리고 냉정하게 생각해보자. 연차도 많고 나이도 많은데 할 수 있는 역할은 그저 개인의 개발자로서 코딩밖에 할 수 없다면, 그리고 그런 역할은 보다 나이 어리고 연차가 적은 사람도 할 수 있다면 어떤 경쟁력이 있을까? 많은 경력 개발자들이 면접 때 본인의 장점에 대해 이야기할 때 이런 이야기를 한다. ‘다양한 개발을 경험해왔고 빠르게 기술을 습득하고 적응하며 도입할 수 있다’ 라는 늬앙스의 이야기를 한다. 난 솔직히 이건 그냥 기본이라고 생각한다. 결국 내가 기존에 얼마나 많은 영향력을 발휘했고 팀에 기여하는 활동을 했는지, 어떤 리더십을 발휘했고 어떤 시도와 실패를 경험해봤는지를 말할 수 없다면 시니어 개발자를 채용할 필요가 없을 것이다.</p>
<h2 id="참고-자료"><a href="#참고-자료" title="참고 자료"></a>참고 자료</h2><ul>
<li><a target="_blank" rel="noopener" href="http://www.engineeringladders.com/">http://www.engineeringladders.com/</a></li>
<li><a target="_blank" rel="noopener" href="https://blog.banksalad.com/tech/engineering-manager-role-growth/">https://blog.banksalad.com/tech/engineering-manager-role-growth/</a></li>
<li><a target="_blank" rel="noopener" href="https://sendbird.com/ko/blog/eng-leader-role-1">https://sendbird.com/ko/blog/eng-leader-role-1</a></li>
</ul>

    </article></div>

wonderland

왜 리더로 성장해야 하는가?
국내에서 개발자로 생활하면서 느꼈던 것은 많은 개발자들이 연차가 쌓이면서 관리자 역할을 하는 것에 대해 두려움을 느낀다는 것이었다. 관리자는 기술직이 아니며 관리자로 일한다는 것은 자신의 개발자로서의 전문성을 발휘하지 못하고 점점 도태된다고 느끼기 때문이다. 그렇기에 많은 개발자들은 자신이 백발이 될 때까지 개발을 하고 싶다는 환상을 가지고 있다. 
반면 우리가 많은 회사에서 경험한 관리자들은 과거에 개발자였다가 어느 순간 관리자를 맡게 된 사람들이며, 주로 일정 관리나 여러 미팅에 참여하면서 기술적 전문성이 떨어지는 경우가 많았다. 더욱 큰 문제는 과거에는 이들이 한때는 뛰어난 개발자였기에 자기 중심적으로 판단을 내리는 경우가 많고 개발자들은 잘못된 판단임을 알면서도 어쩔 수 없이 따라야하는 상황들도 발생된다는 것이다. 이로 인해 피터의 법칙처럼 우리는 한명의 훌륭한 엔지니어를 잃고 무능한 관리자를 얻게 되는 경우가 많다.
그럼에도 불구하고 우리가 시니어 개발자로서 성장하면서 관리자(나는 개인적으로 리더라는 표현을 더 좋아한다)가 되어야 하는 이유는 그것이 개발자로서 나의 영향력을 넓혀 나갈 수 있는 방법이기 때문이다. 아무리 개발을 잘하는 개발자라고 해도 개인이 작성할 수 있는 코드에는 한계가 있다. 하지만 당신이 이끄는 개발팀의 많은 개발자들이 훌륭한 코드들을 만들어낼 수 있도록 돕는다면 한명의 개인으로서 코딩을 하는 것보다 훨씬 큰 효과를 만들어낼 수 있다. 그럼 우리가 개발자로서 선택할 수 있는 리더 포지션인 엔지니어링 매니저와 테크리드는 어떤 것일까? 테크리드에 대해서는 한번쯤 들어본 개발자들이 있을 수 있지만 엔지니어링 매니저는 한번도 들어보지 못한 사람들도 많을 것이다. 물론 테크리드라는 포지션 역시 막연하게 기술을 리드하는 개발자 같은 느낌일 뿐 구체적으로 어떤 역할을 해야하는지 모르는 경우가 많다. 그래서 오늘은 두 포지션의 역할과 비교를 해보고자 한다.
Tech Lead
많은 개발자들은 여전히 리더가 된다는 것에 부담을 느끼지만 만약 꼭 리더가 되어야한다면 테크리드로 성장하고 싶어한다. 왜냐하면 테크리드가 기존에 개발자로서 하는 일에 가깝다고 생각하기 때문이다. 사실 작은 조직에서는 테크리드라는 포지션이 필요없다. 어차피 개발자가 얼마 없고 스스로 모든 것들을 해야하기 떄문이다. 
하지만 서비스가 성장하고 개발조직이 커지게 되면 기술적인 측면에서 리딩을 해야할 필요성이 생긴다. 모든 개발자가 어떤 기준이나 컨벤션 없이 저마다 만들고 싶은 방법과 사용하고 싶은 기술 스택으로 개발해나간다면, 퀄리티에 대한 기준이나 관리 없이 동작가능하게만 만들어나간다면, 서비스는 곧 정체되고 더이상 나아갈 수 없을 것이다. 테크리드는 여전히 일정시간을 코딩에 할애하지만 그것은 직접 문제를 해결하기 위함이 아니라 다른 개발자들이 문제를 해결하기 위한 환경을 만들기 위한 노력 중의 일부일 것이다. 우리는 좋은 개발자를 채용하기 위해 노력하지만 팀에는 다양한 역량과 경험을 가진 개발자들이 속한 조직으로 성장하게 되며 이들을 하나의 방향성으로 이끌어나가야 할 필요성이 생기게 된다.
테크리드는 개발자들의 생산성 향상과 품질 관리를 위해 힘써야 한다. 기술 컨벤션 논의를 이끌고 가이드를 작성해야 한다. 설계나 코드에 대한 리뷰를 직접 하기도 하고 리뷰 문화가 잘 활성화되도록 이끌어야 한다. 여러 팀에서 공통적으로 사용하는 기술을 표준화하고 공통 모듈을 개발하여 사용할 수 있게 하거나 공통 플랫폼을 제공할 수 있도록 해야 한다. 개발팀에서 사용하는 기술 스택들을 관리하고 노후화되지 않도록 전략을 짜야하고 개발자들이 역량을 키울 수 있도록 가이드 해야한다. 시스템 SLA를 수립하고 기술 부채를 어떻게 관리해나갈 것인지에 대한 프로세스를 수립해야 한다. 
당신이 이런 것들에 관심을 기울이기 보다는 내 손으로 직접 기능을 개발하는 시간이 대부분이고 이런 부분들은 가끔 생각날 때 한번씩 한다면 테크리드라고 볼 수 없다. 이런 활동들은 엔지니어링 관점에서 매우 중요한 것들이지만 비지니스에 직접적인 영향을 미치지는 않고 급하지 않다고 판단되어 항상 우선순위가 뒤로 미뤄지게 되는 경향이 많다. 하지만 당신이 시니어 개발자로서 책임감 있는 사람이라면 이런 역할의 중요성을 인식하고 소홀히 하지 않도록 해야 한다.
Engineering Manager
테크리드는 주로 시스템이나 기술에 대한 부분을 주로 담당한다면 엔지니어링 매니저는 주로 사람을 돕는다. 사실 관리한다는 말은 요즘 시대에 맞지 않는다. 누군가가 나를 관리해줄 것이라는 기대는 버려야 한다. 우리 모두는 스스로가 관리자가 되어야 한다. 그럼에도 불구하고 엔지니어링 매니저가 필요한 이유는 뛰어난 프로선수들도 코치는 필요하기 때문이다. 
엔지니어링 매니저는 개발자들이 잘 성장하고 회사에 만족하면서 기여할 수 있도록 돕는다. 1on1을 통해서 목표를 설정하는 것을 돕거나 구성원으로서 잘 성장할 수 있도록 피드백을 준다. 업무를 진행하는데 있어 방해되는 요소를 빠르게 파악하고 장애물을 제거한다. 이러한 것들을 수행하기 위해 엔지니어링 매니저는 소프트웨어 공학과 사람에 대한 깊은 이해를 가지고 개발 프로세스나 팀 문화를 만들고 성장해나갈 수 있도록 도와야 한다. 
아쉽게도 개발자들이 테크리드에 비해 엔지니어링 매니저로 성장하기가 좀 더 어려운 이유는 있다. 먼저 엔지니어링 매니저가 하는 역할을 경험해본 적이 없다. 엔지니어링 매니저로서 역할을 수행해보기는 커녕 제대로 된 엔지니어링 매니저가 있는 환경에서 일해본적도 없다. 예를 들어 사람들과 1on1을 진행할 때 필요한 코칭 스킬이나 상담 기법에 대해 아는 것도 전무하다. 개발하면서 스탠드업 미팅이나 회고 같이 파편적으로 어떤 활동 들을 접해본적은 있으나 어떻게 문화를 만들어나가야 하는지 알지 못한다. 심지어는 칸반이나 스크럼을 사용한다는 조직에서 일을 해왔더라도 막상 내가 그것에 대해 제대로 알거나 공부해본 경우도 없다. 우리가 아는 관리자는 WBS 작성이나 간트차트를 그리면서 개발자들에게 업무가 얼마나 진행이 되었는지 확인하고 그래프를 채우는 모습밖에는 잘 알지 못한다. 하지만 테크리드의 역할은 테크리드가 없더라도 암묵적으로 일부 경험있는 개발자가 일정 역할을 수행하기도 하는 반면, 엔지니어링 매니저의 역할은 상대적으로 중요성을 인지하지 못하거나 아무도 수행하고 있지 않기 때문에 오히려 조직에서 크게 결여되는 부분이기도 하다.
Tech Lead vs Engineering Manager
이전 글에서도 소개한적이 있는 Engineering Ladder에 다음과 같이 두 역할을 비교한 좋은 내용이 있다.
http://www.engineeringladders.com/TechLead-EngineeringManager.html
Tech Lead (System)Engineering Manager (People)
기술적 탁월함과 혁신경력관리를 위한 계획, 승진과 코칭
아키텍쳐와 시스템 통합인원에 대한 계획과 고용
기술 멘토링, 채택 및 일치팀 계획과 전달
기술적인 스파이크와 실험목표, 성과와 피드백
코드 리뷰와 피드백원온원
시스템 설계 발표기술적인 결정에 참여
기술 생산능력 계획상위 레벨과 관리 조직간의 커뮤니케이션
제품 이슈의 보고팀 빌딩 활동과 문화
시스템 SLA, 지표와 모니터링팀 보호와 행복
플랫폼 방향, 패턴과 연습팀 생산력과 지표
다른 테크 리더와의 일치다른 개발 매니저와의 일치
30%~70% 시간의 코딩 업무시간의 0%~30% 시간의 코딩 업무
시스템 로드맵 (공유)시스템 로드맵 (공유)
개발 프로세스 (공유)개발 프로세스 (공유)
팀의 가시성과 인정 (공유)팀의 가시성과 인정 (공유)
필요할 때 엔지니어링 매니저 역할도 가능한 능력필요할 때 테크 리더 역할도 가능한 능력
작은 조직에서는 테크리드와 엔지니어링 매니저의 역할을 겸임하는 TLM(Tech Lead Manager)라는 역할도 있다고 한다. 두 역할의 상당 부분 중엔 겹치는 부분도 많고 상호베타적이지 않기 때문에 두 역할 모두 기술적인 이해를 기반에 갖추어야 하며 필요에 따라 양쪽의 역할을 겸임하거나 오갈 수 있어야 한다. 
어떤 리더가 되고 싶은가?
사실 포지션에 대한 이름이 중요한 것이 아니라 기술 리더로서 어떤 역할들을 수행해 나가야하는지가 중요하다. 테크리드나 엔지니어링 매니저가 우리 회사에 없더라도 이러한 역할을 누군가는 해야하는 중요한 것들이다. 내가 리더가 되고 싶지 않더라도 훌륭한 개발자로 성장하다면 결국엔 명시적이든 암시적이든 리더가 된다. 내가 명시적인 테크리드나 엔지니어링 매니저가 아니라고 해서 이런 역할을 수행하는 필요한 경험이나 역량이 필요없다는 것은 아니다. 뛰어난 개발자는 자기 일에만 집중하는 것이 아니라 큰 시야를 가지고 전체의 효율을 이끌어 내는 일들을 수행한다. 명시적인 리더가 아니더라도 리더들이 하는 역할을 잘 이해하고 돕는 사람이 된다면 리더에게도 굉장히 감사하고 큰 도움이 되는 개발자가 된다. 뿐만 아니라 실리콘밸리의 유명 IT 회사들의 Career Levels가 보여주듯이 결국 높은 레벨로 올라갈수록 리더의 역할을 할 수밖에 없게 된다.
그리고 냉정하게 생각해보자. 연차도 많고 나이도 많은데 할 수 있는 역할은 그저 개인의 개발자로서 코딩밖에 할 수 없다면, 그리고 그런 역할은 보다 나이 어리고 연차가 적은 사람도 할 수 있다면 어떤 경쟁력이 있을까? 많은 경력 개발자들이 면접 때 본인의 장점에 대해 이야기할 때 이런 이야기를 한다. ‘다양한 개발을 경험해왔고 빠르게 기술을 습득하고 적응하며 도입할 수 있다’ 라는 늬앙스의 이야기를 한다. 난 솔직히 이건 그냥 기본이라고 생각한다. 결국 내가 기존에 얼마나 많은 영향력을 발휘했고 팀에 기여하는 활동을 했는지, 어떤 리더십을 발휘했고 어떤 시도와 실패를 경험해봤는지를 말할 수 없다면 시니어 개발자를 채용할 필요가 없을 것이다.
참고 자료
http://www.engineeringladders.com/
https://blog.banksalad.com/tech/engineering-manager-role-growth/
https://sendbird.com/ko/blog/eng-leader-role-1

시니어 개발자가 선택할 수 있는 리더 포지션

댓글