<div id="readability-page-1" class="page"><article>
    <div>

                
                <div>
                    <details open="">
                        <summary accesskey="c" title="(Alt + C)">
                            <p>Table of Contents</p>
                        </summary>
                        <nav id="TableOfContents">
  <ul>
    <li><a href="#소프트웨어-엔지니어링-레벨">소프트웨어 엔지니어링 레벨</a>
      <ul>
        <li><a href="#레벨-구분해보기">레벨 구분해보기</a></li>
        <li><a href="#결론">결론</a></li>
        <li><a href="#마치며">마치며</a></li>
      </ul>
    </li>
  </ul>
</nav>
                    </details>
                </div>
                
                <h2 id="소프트웨어-엔지니어링-레벨">소프트웨어 엔지니어링 레벨</h2>
<p>구글에서는 소프트웨어 엔지니어링 레벨일 L3 부터 L10까지 나눈다고 한다. 비슷하게 아마존도 L3 ~ L10, 메타는 E3 ~ E9, MS는 59 ~ 80 의 직급체계를 가지고 있다고 한다.
이런 직급 체계를 가지고 있는 것은 각 단계별로 기대되는 역할과 책임을 명확하게 하기 위함이고, 그에 따라 개인입장에서는 경력 개발을 하기 위한 목표를 뚜렷하게 인식할 수 있다.</p>
<p>종종 주니어, 시니어에 대한 기준에 대한 이야기를 듣고는 하는데, 최근에 커피챗을 진행하면서 이 레벨에 대한 이야기를 하게 되었다.
그러다가, ‘각각의 단계를 나누는 하나의 기준이 있다면 무엇일까?’ 라는 생각을 하게 되어 <strong>‘내가 생각하는 단계별 기준’</strong> 을 정리해 보았다.</p>
<h2 id="레벨-구분해보기">레벨 구분해보기</h2>
<p>먼저 엔지니어링 레벨을 구분해보았다. 그냥 단순하게 주니어 / 시니어를 구분해서는 의미가 없으니, 좀 더 세세하게 나누어서 생각해 보았다.</p>
<ul>
<li>신입</li>
<li>주니어</li>
<li>미들</li>
<li>시니어</li>
<li>그 이상(?)</li>
</ul>
<h3 id="신입과-주니어의-차이">신입과 주니어의 차이</h3>
<ul>
<li>
<p>신입</p>
<ul>
<li>신입은 막 학교를 졸업하고 회사에서 업무를 시작한 단계라고 정의해봤다.</li>
<li>기본적인 코딩 능력과 개발 스킬을 가지고 있다. 하지만 업무 경험이 없기 때문에 회사에서 어떻게 일이 진행되는지 정확하게 알지 못한다.</li>
<li>업무 프로세스에 대해서 익숙해져야 하고, 자신이 어떤 과제를 직접 시작하기 어렵고, 대부분 주어진 업무를 수행하게 된다.</li>
<li>역량을 성장시키는데 있어서 팀에서 지원을 받는 것이 일반적이다.</li>
</ul>
</li>
<li>
<p>주니어</p>
<ul>
<li>신입에 비해서 상대적인 경험치가 더 많다.</li>
<li>팀에서 업무가 어떻게 진행되는지 이해하고 있다. 다만 큰 레벨에서의 전략적인 부분까지 모두 이해하기는 어렵다.</li>
<li>본인이 처리하는 업무에 대해서 이슈를 제기하고, 개선방향을 제시 할 수 있다.</li>
<li>일을 통해서 알아가는 것들이 늘어나는 단계이다.</li>
</ul>
</li>
</ul>
<p>이 두 단계를 나누는 기준을 생각했을 때 나의 기준은 다음과 같다.</p>
<blockquote>
<h4 id="신입은-뭘-모르는지-모르고-주니어는-뭘-모르는지-알기-때문에-질문을-잘-하게-되면-주니어">신입은 뭘 모르는지 모르고, 주니어는 뭘 모르는지 알기 때문에 질문을 잘 하게 되면 주니어.</h4>
</blockquote>
<p>질문을 잘 할 수 있게 되려면, 나 자신에게 요구되는 기대치를 이해하고 있어야하는데 신입시절에는 그게 잘 안된다.</p>
<p>생각해보자면, 신입과 주니어 모두 <strong>주어진 업무를 무사히(!!!) 수행하는 것 자체가 기대치</strong>인데, 신입시절에는
항상 나 자신에 대한 증명(?)을 하려고 애쓰는 모습들이 있어서 질문을 잘 하지 않았던 것 같다.
보는 사람 입장에서는 애가탄다고 할까..</p>
<p>그래서 이걸 물어봐도 되는지, 물어보면 안되는지 고민하는 모습이 반복되면 아직 신입, 그에 대한 감이 있다면 주니어라고 할 수 있다.</p>
<p>만약 누군가가 신입인데 질문을 잘 하기 어렵다고 한다면, 나의 조언은 “<strong>그냥 일단 다 물어보고, 엉뚱한걸 물어보더라도 빠르게 깨지고, 틀리고 하면서 배우는게 더 낫다</strong>” 이다.
빠르게 감잡으면 성공!</p>
<figure>
    <img src="https://findstar.pe.kr/images/posts/engineering-level/junior-dev.jpg" alt="junior developer">
    
    <figcaption>몰라도 계속 물어보자. 계속 물어보자</figcaption>
    
</figure>
<h3 id="주니어와-미들의-차이">주니어와 미들의 차이</h3>
<ul>
<li>미들
<ul>
<li>주니어에 비해서 상대적으로 경험치가 더 많다.</li>
<li>빠르게는 3년차로 보기도 하지만 주로 5년차~7,8 년차 길게는 10년차 정도 된다고 보인다.</li>
<li>조직 내에서 가장 많은 코드를 생산하고, 일을 끝까지 완료할 수 있는 능력을 가지고 있다.</li>
<li>본인이 관심을 가지는 분야에 대해서 스스로 탐구하고 연구를 통해서 역량을 성장시킨다.</li>
<li>시장에서 가장 많이 선호하는 레벨이라고 생각한다. (그만큼 이직하기 좋은 레벨?!)</li>
</ul>
</li>
</ul>
<p>주니어와 미들을 나누는 나만의 기준은 다음과 같다.</p>
<blockquote>
<h4 id="주니어는-아직-누군가에게-도움을-받아야-하고-미들은-스스로-일을-완료-할-수-있기-때문에-마감을-잘-할-수-있게-되면-미들">주니어는 아직 누군가에게 도움을 받아야 하고 미들은 스스로 일을 완료 할 수 있기 때문에, 마감을 잘 할 수 있게 되면 미들</h4>
</blockquote>
<p>주니어 레벨에서는 주어진 일을 완료할 때 완료의 범위가 좁다. 특히 어떤 이슈를 해결할 때 주어진 일을 해결한 뒤에 주변에서 크로스 체크를 해준다던가, 후속작업은 다른 사람이 진행하게 되는 경우가 많다.
왜냐하면 아직은 팀에서 누군가가 같이 커버를 해주어야만 전체 일이 완료되기 때문이다.</p>
<p>그에 반해서 미들 레벨에서는 일을 완료하는 범위가 상대적으로 넓다. 이슈를 해결할 때 이어질 후속 작업에 대해서 인지하고 있으면서, 동료에게 잘 전달될 수 있는 형태로 마무리 하는 능력을 갖추고 있다.</p>
<p>비유하자면,</p>
<ul>
<li>주니어에게는 코드를 작성해서 PR을 생성하는게 완료의 범위라면,</li>
<li>미들에게는 해당 이슈가 머지되고, 배포되어 사용자에게 완료되었다는 피드백을 확인하는 것까지가 업무 범위가 된다.</li>
</ul>
<p>따라서 내가 하는 일이 단순히 특정 Task를 완료하는 것이 아니라, 이 일이 제품에 또는 고객에 어떻게 연결되는지 인지하는 시야가 필요하다. 그래서 미들레벨로 갈 수록 전체 시야가 넓어지고 협업 및 커뮤니케이션에 대한 요구사항이 높아진다.
왜냐하면 그렇게 해야만 전체 일이 마감될 수 있기 때문이다.</p>
<figure>
    <img src="https://findstar.pe.kr/images/posts/engineering-level/mid-dev.jpg" alt="middle developer">
    
    <figcaption>이 시기가 가장 많은 코드를 작성하는 시기인것 같다.</figcaption>
    
</figure>
<h3 id="미들과-시니어의-차이">미들과 시니어의 차이</h3>
<ul>
<li>시니어
<ul>
<li>미들에 비해서 상대적으로 경험치가 더 많다.</li>
<li>팀 내에서 중요한 기술적 리더십을 가지고 있다.</li>
<li>팀장 / 매니저를 겸하는 경우도 많다.</li>
<li>보다 큰 규모의 프로젝트를 주도하고, 복잡한 시스템에 대한 설계를 처리할 수 있다.</li>
<li>또한 팀원들에 대한 지원 및 멘토링, 교육과 같은 미션도 주어진다.</li>
</ul>
</li>
</ul>
<p>미들과 시니어를 나누는 나만의 기준은 다음과 같다.</p>
<blockquote>
<h4 id="혼자-잘-하는-것을-넘어서-조직이-함께-잘-하게-만들-수-있게-되면-시니어">혼자 잘 하는 것을 넘어서 조직이 함께 잘 하게 만들 수 있게 되면 시니어</h4>
</blockquote>
<p>미들 레벨에서 일을 잘 마무리하는 역량까지 갖추기 되면, 이제 본격적으로 더 넓은 시야를 가지는게 필요하다. 이 때부터는 자신에게 주어진 일을 넘어서 조직에서 성과를 내게 만드는 것이 중요해지는데, 이게 시니어의 어려운 점이라고 생각한다.
이 때부터는 혼자 잘 하는 것을 넘어서 조직이 함께 잘 하게 만들 수 있어야 시니어라고 할 수 있다.</p>
<p>이 때문에 다른 구성원들이 선호하지 않는 일을 맡게 되기도 하고(시니어가 뒤치닥거리를 하게 되는 이유) 그런 부분에 있어서 비효율을 개선하는 업무를 진행하게 되기도 한다.
그리고 시니어 레벨 부터, 조직적인 역량을 높이는 활동들(멘토링, 교육, 문서화)에 대한 기대가 높이지기 시작한다.</p>
<p>여러방면에서 요청받는 사항들의 폭이 넓어지는데, 그 이유가 바로 <strong>조직이 함께 잘 해서 결과를 만들어 내기</strong>를 기대받기 때문이라고 생각한다.</p>
<figure>
    <img src="https://findstar.pe.kr/images/posts/engineering-level/sr-dev.png" alt="senior developer">
    
    <figcaption>팀이 같이 잘 하게 하기 위해서 노력해야하는 시니어</figcaption>
    
</figure>
<h3 id="시니어-그-이상">시니어 그 이상(?)</h3>
<p>시니어 그 이상은 뭘까? Staff Engineer / Principal Engineer / Distinguished Engineer 여러가지 레벨이 있다고 하지만, 시니어 이상의 역할과 책임에서는 회사 차원에서 영향력이 더 커지는 것으로 보인다.
그만큼 정치력(?)이 필요해보이기도 하고, 어려운 자리로 보인다.</p>
<p>이부분에 대한 생각은 나도 아직 정리가 안되어 있어서 뭐라고 작성하기가 어렵다. 나중에(?) 경험이 쌓이면 기록해봐야겠다.</p>
<h2 id="결론">결론</h2>
<p>각각의 엔지니어링 레벨을 나누어 보고, 그 경계를 가르는 기준을 정리해보았다.
물론 나의 주관적인 경험을 기반으로 했기 때문에, 꼭 이게 정답이다라고 말할 수는 없다. 참고만 하자.</p>
<table>
<thead>
<tr>
<th>구분</th>
<th>설명</th>
</tr>
</thead>
<tbody>
<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>
<h3 id="단계별-기준">단계별 기준</h3>
<ol>
<li>신입 =&gt; 주니어 : 질문을 잘 하게 되면 주니어 / 이를 위해서는 틀려도, 깨져도 계속 물어보는 것이 중요함</li>
<li>주니어 =&gt; 미들 : 마감을 잘 할 수 있게 되면 미들 / 내가 하는 업무의 완료의 의미가 무엇인지 생각해보고 이를 확장해나가는 것이 중요함</li>
<li>미들 =&gt; 시니어 : 혼자 잘 하는 것을 넘어서 같이 잘 하게 만들 수 있으면 시니어 / 같이 잘 하게 하기 위해서 조직에서의 영향력을 키우고 이를 위해 커뮤니케이션 및 다양한 역량 확장이 필요함</li>
</ol>
<h2 id="마치며">마치며</h2>
<p>현재 조직에서 시니어 엔지니어 역할을 맡고 있어서 멘토링 및 교육활동을 많이 하게 된다. 각 단계에 대한 나름대로의 기준을 정해놓았더니, 고민하는 주니어분들께 멘토링에서 어떤 가이드를 해주면 좋을지
생각이 정리되어서 좋았다. 혹시나 각 레벨에서 어떤 역량을 높여야 할지 고민되시는 분들이라면 엔지니어 레벨의 구분과 각 레벨의 주요 기준을 정의해보면서 자신이 현재 어느 위치에 있는지, 앞으로 어떤 방향으로 나아가야 하는지를 명확히 하는 데 도움이 되기를 바란다.</p>


                

                <hr>
                

                





<p><a href="https://disqus.com/">comments powered by </a>



            </p></div>
</article></div>

Soo Story

Jung-Soo Ahn

구글에서는 소프트웨어 엔지니어링 레벨을 L3 부터 L10 까지 나눈다고 한다. 신입부터 미들, 시니어, 그리고 기술책임자 까지를 나타내는 직급체계라고 할 수 있다. 문득 각각의 레벨에 따라서 어떤 점이 달라질까 궁금해서 내 나름대로의 기준을 뽑아보았다. 신입부터 시니어 엔지니어까지의 기준을 하나씩 생각해보았다.

내맘대로 나눠본 엔지니어 레벨의 기준

댓글