<div id="readability-page-1" class="page"><div id="site-main">

        <article>

            

            <figure>
            </figure>

            <div>
                    <p><img src="https://blog.roto.codes/content/images/2019/12/64150950-front-end-development-chart-with-keywords-and-icons-1.jpg" alt="64150950-front-end-development-chart-with-keywords-and-icons-1"></p>
<p>요새 Software Engineer 직군 구하기가 힘들다고 여기저기서 아우성이다. 그중에서도 Front-end 직군, 특히 Senior Front-end Engineer는 정말 구하기가 힘들다는 소리를 여러곳에서 들었다(사실 우리회사도 사정은 마찬가지다).</p>
<p>이것은 아래의 경우를 생각해보면 굉장히 당연한 현상이다.</p>

<p>알 사람들은 다 아는 사실이지만 Front-end 라는 말이 업계에 정착한지는 그리 오래 되지 않았다. 이건 우리나라 업계 특징이기도 한데 불과 몇년전까지만 해도 퍼블리셔, 스크립터라는 말로 HTML, CSS를 하는 사람과 JS를 하는 사람의 직무는 나뉘어져 있었다.</p>
<p>이것은 아직 크게 다르지 않은 것 같다. 국내 대기업(N사와 K사)는 마크업만 하는 사람들이 있는 자회사가 따로 있는 것으로 알고 있고, 페이스북의 각종 커뮤니티에 올라오는 채용 관련 글을 보면 SI 시장 일부에선 아직도 두 직군을 구분하는 걸로 보인다. 스크립터라는 말만 Front-end engineer로 바뀌었을 뿐이지.</p>
<p>거기에 회사마다 Front-end 직군을 혼용해서 쓰고 있어서 더 문제다. 마크업만 하는 사람을 구하면서 Front-end engineer 구한다는 경우도 있고, 반대로 퍼블리셔가 따로 있고 JS만 하는 사람을 구하면서 Front-end engineer를 구한다는 경우도 있다(후자가 훨씬 더 많은 것 같다).</p>
<p>어쨌든 그동안 상황이 이랬다보니 위의 세 가지를 전부 할 줄 알면서, 하려고 했던 경력직이 그리 많지 않았다. HTML, CSS를 하는 직군에서 <code>"JS는 저희 업무가 아니에요"</code>라고 한다거나 그 반대로 JS를 전문으로 하던 직군에서 <code>"HTML, CSS"를 내가 왜 해야하는데?</code>하는 경우도 있었다.</p>
<p>이런 상황에서 HTML, CSS, JS를 꾸준히 해왔던 사람이 드물 수 밖에.</p>
<h2 id="">지속적인 수련</h2>
<p>최근 몇년간 JavaScript는 대격변의 시기를 겪었고 그나마 요새는 <code>React.js</code>가 어느정도 표준으로 자리잡았다(고 생각한다).</p>
<p>또 변화가 다양했던 것은 어느정도 변화의 이유가 타당했기 때문이고, 그 변화의 연속적인 부분들을 커버하려면 개인시간을 상당히 할애했어야 했는데 이건 회사업무시간 외에 지속적인 수련을 했어야 한다는 이야기가 된다.</p>
<p>이런 사람들 역시 드물다.</p>
<h2 id="">기존 회사의 체계 문제</h2>
<p>이건 내 경험 기반에서 나온 부분인데, 기존 웹 애플리케이션 개발은 주로 Java, C#, PHP 등 서버 사이드 언어가 메인이고 거기에서 화면은 중심을 크게 두지 않은 경우가 많았다.</p>
<p>구조가 그러다보니 위에서 언급한 큰 회사에서 마크업만 하는 직군이 따로 있고 이분들이 정적인 HTML, CSS만 만든다(일부 간단한 스크립팅까지 해주는 경우도 있다). 그후에 서버쪽 코딩하는 사람이 위의 마크업을 받아서 API 연동이나 인터랙션 작업 같은 JavaScript 코딩을 하는 식이었다.</p>
<p>이렇게 Server-side 의존적인 구조다보니 Front-end side에서 무언가 주도적으로 하기가 힘들었고, 흔히 이야기하는 Modern web스러운 프레임워크나 라이브러리를 쓰기가 매우 힘들었다. 내가 알기로 규모있는 회사에서 React.js 같은 걸 어드민 사이트용이 아닌 대고객용 웹 애플리케이션에 적극적으로 쓴 건 정말 얼마 되지 않았다.</p>
<p>이런 체계다보니 Front-end Engineering 분야가 자리잡기가 힘들 수 밖에.</p>
<p>이러한 상황에서 Client side에서 처리해야 하는 업무의 양 자체와 복잡도가 이전보다 크게 올라가다보니 결국은 위 구조의 회사에서도 Front-end 쪽 분야를 채용하는 것으로 보인다(마크업만 하는 사람은 따로 있는 것 같지만).</p>
<h2 id="">결론</h2>
<p>이외에도 여러가지 이유가 있겠지만 위의 세 가지가 가장 큰 이유라고 생각한다. Junior와 Senior는 무엇으로 구분하느냐는 둘째치더라도, 위의 조건을 종합해보면</p>
<ul>
<li>HTML, CSS, JS를 모두 다 할줄 알면서</li>
<li>JS 트렌드에도 기민하게 대응 할 수 있고</li>
<li>Modern Web Stack을 이용한 웹 애플리케이션 출시를 세 개 이상 해봤으면서</li>
<li>어느정도 경력을 쌓은 경우</li>
</ul>
<p>의 수를 모두 필터링 해보면, 정말 운 좋고 경력 잘 쌓은 사람 아니면 그 수가 매우 적을 수 밖에 없을 것이다.</p>
<p>나는 정말 운도 좋았고 여러가지 상황이 잘 따라와 준 덕분에 전 직장에서나 지금 직장에서나 Senior Front-end Engineer 타이틀을 달고 있는 셈이다.</p>
<p>어쨌든 상황이 이렇다보니 Senior라고 불릴 정도의 front-end engineer 수는 적을 수 밖에.</p>
<p>커뮤니케이션 능력 좋고 의도적인 수련을 꾸준히 하면서 HTML, CSS, JS 셋 다 관심있는 신입이나 Junior를 채용해서 성장 시켜서 협업하는 게 제일 현실적인 대안 같다.</p>

                </div>


            

                

        </article>

    </div></div>

로토의 블로그

로토

요새 Software Engineer 직군 구하기가 힘들다고 여기저기서 아우성이다. 그중에서도 Front-end 직군, 특히 Senior Front-end Engineer는 정말 구하기가 힘들다는 소리를 여러곳에서 들었다(사실 우리회사도 사정은 마찬가지다).
이것은 아래의 경우를 생각해보면 굉장히 당연한 현상이다.
Front-end 직군이 생긴지 얼마 되지 않았다.
알 사람들은 다 아는 사실이지만 Front-end 라는 말이 업계에 정착한지는 그리 오래 되지 않았다. 이건 우리나라 업계 특징이기도 한데 불과 몇년전까지만 해도 퍼블리셔, 스크립터라는 말로 HTML, CSS를 하는 사람과 JS를 하는 사람의 직무는 나뉘어져 있었다.
이것은 아직 크게 다르지 않은 것 같다. 국내 대기업(N사와 K사)는 마크업만 하는 사람들이 있는 자회사가 따로 있는 것으로 알고 있고, 페이스북의 각종 커뮤니티에 올라오는 채용 관련 글을 보면 SI 시장 일부에선 아직도 두 직군을 구분하는 걸로 보인다. 스크립터라는 말만 Front-end engineer로 바뀌었을 뿐이지.
거기에 회사마다 Front-end 직군을 혼용해서 쓰고 있어서 더 문제다. 마크업만 하는 사람을 구하면서 Front-end engineer 구한다는 경우도 있고, 반대로 퍼블리셔가 따로 있고 JS만 하는 사람을 구하면서 Front-end engineer를 구한다는 경우도 있다(후자가 훨씬 더 많은 것 같다).
어쨌든 그동안 상황이 이랬다보니 위의 세 가지를 전부 할 줄 알면서, 하려고 했던 경력직이 그리 많지 않았다. HTML, CSS를 하는 직군에서 "JS는 저희 업무가 아니에요"라고 한다거나 그 반대로 JS를 전문으로 하던 직군에서 "HTML, CSS"를 내가 왜 해야하는데?하는 경우도 있었다.
이런 상황에서 HTML, CSS, JS를 꾸준히 해왔던 사람이 드물 수 밖에.
지속적인 수련
최근 몇년간 JavaScript는 대격변의 시기를 겪었고 그나마 요새는 React.js가 어느정도 표준으로 자리잡았다(고 생각한다).
또 변화가 다양했던 것은 어느정도 변화의 이유가 타당했기 때문이고, 그 변화의 연속적인 부분들을 커버하려면 개인시간을 상당히 할애했어야 했는데 이건 회사업무시간 외에 지속적인 수련을 했어야 한다는 이야기가 된다.
이런 사람들 역시 드물다.
기존 회사의 체계 문제
이건 내 경험 기반에서 나온 부분인데, 기존 웹 애플리케이션 개발은 주로 Java, C#, PHP 등 서버 사이드 언어가 메인이고 거기에서 화면은 중심을 크게 두지 않은 경우가 많았다.
구조가 그러다보니 위에서 언급한 큰 회사에서 마크업만 하는 직군이 따로 있고 이분들이 정적인 HTML, CSS만 만든다(일부 간단한 스크립팅까지 해주는 경우도 있다). 그후에 서버쪽 코딩하는 사람이 위의 마크업을 받아서 API 연동이나 인터랙션 작업 같은 JavaScript 코딩을 하는 식이었다.
이렇게 Server-side 의존적인 구조다보니 Front-end side에서 무언가 주도적으로 하기가 힘들었고, 흔히 이야기하는 Modern web스러운 프레임워크나 라이브러리를 쓰기가 매우 힘들었다. 내가 알기로 규모있는 회사에서 React.js 같은 걸 어드민 사이트용이 아닌 대고객용 웹 애플리케이션에 적극적으로 쓴 건 정말 얼마 되지 않았다.
이런 체계다보니 Front-end Engineering 분야가 자리잡기가 힘들 수 밖에.
이러한 상황에서 Client side에서 처리해야 하는 업무의 양 자체와 복잡도가 이전보다 크게 올라가다보니 결국은 위 구조의 회사에서도 Front-end 쪽 분야를 채용하는 것으로 보인다(마크업만 하는 사람은 따로 있는 것 같지만).
결론
이외에도 여러가지 이유가 있겠지만 위의 세 가지가 가장 큰 이유라고 생각한다. Junior와 Senior는 무엇으로 구분하느냐는 둘째치더라도, 위의 조건을 종합해보면
HTML, CSS, JS를 모두 다 할줄 알면서
JS 트렌드에도 기민하게 대응 할 수 있고
Modern Web Stack을 이용한 웹 애플리케이션 출시를 세 개 이상 해봤으면서
어느정도 경력을 쌓은 경우
의 수를 모두 필터링 해보면, 정말 운 좋고 경력 잘 쌓은 사람 아니면 그 수가 매우 적을 수 밖에 없을 것이다.
나는 정말 운도 좋았고 여러가지 상황이 잘 따라와 준 덕분에 전 직장에서나 지금 직장에서나 Senior Front-end Engineer 타이틀을 달고 있는 셈이다.
어쨌든 상황이 이렇다보니 Senior라고 불릴 정도의 front-end engineer 수는 적을 수 밖에.
커뮤니케이션 능력 좋고 의도적인 수련을 꾸준히 하면서 HTML, CSS, JS 셋 다 관심있는 신입이나 Junior를 채용해서 성장 시켜서 협업하는 게 제일 현실적인 대안 같다.

Senior Front-end engineer가 희귀한 이유

댓글