<div id="readability-page-1" class="page"><article><img src="https://user-images.githubusercontent.com/389021/98948530-e6c58500-2539-11eb-832f-753d5d4d6769.png">
5~6년 차 즈음부터 개발자 채용에 조금씩 관여하기 시작했고 현 회사에서는 면접관으로 활동한지 5년이 넘은 것 같다. 면접은 1차 면접에 해당하는 기술 면접이었고 팀의 채용 프로세스를 개선하거나 사전과제, 라이브 코딩 문제 출제에 주도적으로 참여했다. 그간 다양한 개발자들을 만났고 운 좋게도 좋은 개발자들을 많이 채용할 수 있었다.
채용 과정에서 좋은 개발자도 만났지만 그렇지 못했던 개발자도 많았고, 아쉬웠던 개발자도 있었다. 아쉬웠던 개발자들은 노력을 하고 있지만 “어느 정도”로 “어떤 방향”으로 해야 하는지 모르는 경우였고 채용에 대한 준비가 부족했던 경우도 많다. 이런 분들에겐 면접이 끝나기 전에 선배 개발자로서 몇 가지 조언을 해주고 싶었지만 채용 과정에서는 조심스러운 일이기도 하고 최소한의 범위에서 우회적으로 표현해왔다. 언젠가 몇 가지 내용을 정리해서 공유하면 도움이 되지 않을까 생각했었고 이제서야 글로 쓴다.<ins data-ad-layout="in-article" data-ad-format="fluid" data-ad-client="ca-pub-4811193197471582" data-ad-slot="7153541064"></ins>
이 글의 내용은 현 직장의 의지, 정책과는 아무관련 없으며 그동안 채용에 참여하며 느낀점들을 정리한 지극히 개인적인 의견이다.
주로 프론트 엔드 개발자의 채용에 참여했었지만 개발자라면 주 종목 상관없이 도움이 될 것이라 생각한다.
<h2>주요 역량 항목</h2>
회사마다 그리고 조직마다 조금씩 다를 수 있지만 조직에서 개발자를 채용 할때는 주로 아래의 항목과 같은 역량을 확인한다.
<ul>
<li>어떤 프로젝트를 경험했는지</li>
<li>어떤 도구/프레임웍을 사용했는지</li>
<li>어떤 개발 방법론을 사용했었는지</li>
<li>프로젝트에 어떤 책임으로 참여했는지 개발자인지 개발리더인지</li>
<li>팀이나 회사에 프로젝트외에 어떤 기여를 했는지</li>
<li>프로젝트에서 발생한 기술적인 문제를 어떻게 해결하는지</li>
<li>리더쉽, 협업, 커뮤니케이션 스킬</li>
</ul>
위 역량들을 이력서, 사전과제, 코딩 테스트, 면접등의 프로세스를 통해 검증하는데 프로세스가 진행될수록 검증의 깊이가 깊어진다. 예를 들어 이력서를 통해서는 어떤 기술들을 사용했었는지를 확인하고 채용 대상 기술셋에 맞는 사람인지를 판단하고 사전과제에서는 실무능력을, 기술 면접에서는 기술의 이해나 경험에 대한 질문으로 더 깊이 있는 검증을 한다. 놀랍게도 본인의 지식이나 경험, 성과를 충분히 정리(숙지) 하지 못하고 채용 프로세스를 진행하는 개발자들이 많다. 이력서를 통해 알 수 있는 것이 거의 없거나 이력서는 충실한데 사전과제나 기술면접에서 이력서로 유추할 수 있는 역량들이 충분히 검증되지 않았다.
위의 각 역량 항목들을 게임속의 스탯이라고 생각하자. 다만 게임처럼 스탯이 눈에 보이지 않으니 스탯을 채용 프로세스 각 단계를 통해 보여줘야 한다. 이력서라면 글을 통해, 사전과제라면 코드를 통해, 면접이라면 말을 통해서 말이다.
<h2>이력서</h2>
혹시 서류에서 자꾸 떨어진다면 이력서에 본인의 역량 항목들이 충실히 어필되고 있는지 확인해보자. 이력서는 거의 비슷한 양식이기 때문에 표준 이력서 하나를 만들어 평소에 주기적으로 업데이트를 한다. 이력서를 주기적으로 업데이트하는 것은 주기적으로 반성(?) 하는 시간을 가질 수 있어 동기부여와 목표 설정에 도움이 된다. 이렇게 이력서를 관리하다가 “때가오면” 지원하는 회사 양식에 맞게 수정한다.
이력서의 핵심은 근무했던 회사의 목록과 각 회사에서 진행했던 프로젝트들 목록이다. 더 중요한 건 프로젝트 목록이다. 경험했던 프로젝트를 통해 앞서 정리한 역량을 어필해야 한다. 프로젝트마다 모든 역량을 어필할 수는 없을 것이고 보통 한 가지 혹은 두 가지 정도 일 것이다. 적어도 프로젝트마다 한 가지 역량은 어필해야 한다. 개발자라면 도구, 프레임웍, 언어의 사용 경험을 쉽게 어필할 수 있다. 프로젝트마다 사용한 환경이 거의 동일하다면 다른 프로젝트에서는 다른 역량을 어필할 수 있도록 기억을 영끌한다.
단순히 경험을 구구절절 늘어놓는 게 아니라 역량을 어필할 수 있는 포인트를 하나 이상 적는 것이다. 이력서를 검토하는 사람이라고 생각해보자 “그래서 도대체 뭘 했다는 거지?”라는 생각이 드는 이력서와 “이런저런 경험했고 이런저런 성과가 있었으니 이건 잘하겠구나”라고 파악할 수 있는 이력서 중 어떤 쪽에 손을 들어주겠는가? 당연한 이야기 같지만 이런 당연한 이력서를 못쓰는 사람이 절반이다.
<h2>성과</h2>
이력서에 써야 할 “성과”란 것이 무엇일까. 개발자는 명확하게 숫자로 성과를 나열하기 쉬운 직군은 아니지만 그렇다고 본인의 성과가 무엇인지 모르면 안 된다. 의외로 모르는 사람이 많다. 성과는 프로젝트에 내가 기여한 것을 적으면 된다. 그것은 내가 잘해서 회사가 얻은 것, 내가 잘해서 팀이 얻은 것, 내가 잘해서 동료가 얻은 것, 내가 잘해서 내가 얻은 것들을 말한다. “A 기술로 개발했음” 정도에서 이력서 검토자가 파악할 수 있는 건 “A를 사용해봤구나” 정도다. 단순히 기술만 나열하지 말고 성과를 쥐어짜보자. 성과가 없어서가 아니라 무엇이 성과인지 몰라서 못쓰는 사람이 많다. 그래서 면접단계까지 와서야 좋은 성과가 밝혀지기도 한다.
<ul>
<li>효율적인 기술들을 검토해서 스택을 결정하고 팀에 전파</li>
<li>난이도가 높은 기술을 사용 했거나 직접 개발 했던 경험</li>
<li>개발 환경이나 구조를 구축</li>
<li>레거시 코드를 포팅하거나 새로운 코드로 교체</li>
<li>월등한(혹은 꽤) 성능 개선</li>
<li>익숙하지만 노후된 프레임웍을 본인의 설파와 계몽을 통해 새로운 프레임웍으로 변경</li>
<li>본인이 개발한 모듈에 대한 자랑거리(성능, 적은 코드, 구조, 가독성) 등등..</li>
</ul>
이런 성과를 추가로 곁들어 주면 더 향긋한 이력서가 된다. 없는 성과를 소설로 메꾸라고 하는 이야기가 아니라 본인의 성과를 성과라고 생각하지 못하는 경우는 없어야 한다는 말이다. 몰라서도 안되고 겸손할 필요도 없다. 단순히 기술을 나열하기보다는 “성과”라는 스토리를 담도록 노력하자. 만약 그런 스토리가 없다면 아직 이직할 준비가 되지 않은 것이다. 우선 지금 회사에서 만들어보자.
<h2>사전 과제, 코딩 테스트</h2>
사전 과제와 코딩 테스트는 실무 능력과 문제 해결 능력 등 실제 개발 능력을 평가한다. 둘 다 코드로 평가하지만 사전 과제에 비해 대면으로 진행하는 라이브 코딩 테스트는 보통 문제를 해결하는 능력에 더 무게를 둔다.
<ul>
<li>효율적인 구조</li>
<li>컴포넌트나 모듈의 책임과 역할</li>
<li>코드의 일관성, 가독성, 유지보수성</li>
<li>변수, 함수, 클래스등의 네이밍</li>
<li>안티 패턴에 대한 이해</li>
<li>성능에 대한 이해</li>
<li>모던 개발 환경에 대한 이해</li>
</ul>
위에 나열한 내용보다 더 많겠지만 더 이상 나열할 필요는 없을 것 같다. 대부분 알고 있는 코드 품질을 판단하는 척도들이다. 알고 있지만 그것을 코드로 작성하지 못하면 모르는 것과 같다. 주식 투자하는 사람들 사이에서 이런 말을 종종 한다. “자신 있으면 계좌부터 까보세요” 말을 백날 잘해봐야 소용없다. 실력을 직관적으로 보여주면 된다. 개발자니까 코드로 보여준다. 사전 과제에서 보고 싶은 것은 정상 동작하는 결과물이 아니다. 정상 동작은 당연한 것이다.
어떤 지원자는 사전과제에서 평소 해보고 싶었던 큰 시도를 하느라 정작 중요한 것을 놓치기도 한다. 참신한 시도를 녹인 코드는 좋지만 여기저기 버그가 있고 제대로 동작하지 않거나 완성도가 낮아 효율이 떨어진다면 오히려 구닥다리 MVC 패턴을 활용해 안정적으로 만드느니만 못하다. 신입급 개발자라면 내용에 따라 어느 정도 가산점이 있을지 모르겠지만 그간 시도해 보고 싶었던 것은 개인 프로젝트에서 하고 사전과제는 기존에 잘하던 것을 보여주는 것이 좋다. 실제로 평소의 코드를 확인하려고 진행하는 프로세스다. 꼭 하고 싶다면 기존에 잘했던 것에 시도는 한 20% 정도만 첨가하자.
제출하기 전에는 코드를 어느 정도 정리해서 제출하자. 로깅 코드나 주석 처리된 필요 없는 코드 등은 제거한다. FE 개발자들에게 추가로 전달하자면 node_modules와 빌드 결과물은 제거하고 제출한다. 별것 아닌 것 같지만 굉장히 점수를 많이 깎아 먹는 포인트다. package.json과 환경 설정 파일, 그리고 코드만 제출하자. package.json의 내용을 보면 어떻게 실행해야 하는지 알 수 있다. 그렇지 않다면 그것도 문제다.
<h2>면접</h2>
면접 중에서도 특히 기술 면접에 대한 이야기다. 면접에서는 이력서의 내용들을 질문을 통해 한층 깊게 검증한다.
<ul>
<li>각 프로젝트의 참여 범위, 특이점</li>
<li>이력서에 명시한 기술들에 대한 이해</li>
<li>사용하는 언어에 대한 이해</li>
<li>문제 해결 능력</li>
<li>협업, 커뮤니케이션에 대한 구체적인 경험</li>
<li>리더쉽, 회사, 조직안에서의 영향력</li>
<li>업무를 대하는 태도, 업무 처리 및 관리 능력</li>
</ul>
면접에서는 이력서와 사전과제를 통해 도출된 질문에 답을 할 수 있어야 한다. 이력서에 A 프레임웍을 사용했다고 적었다면 A 프레임웍에 대한 기술적인 질문에 답을 할 수 있어야 한다. 그러기 위해선 예상 질문에 대한 답변을 미리 연습해 두는 것이 좋다. 충분히 다뤄본 기술이라도 그 개념과 이해를 준비 없이 설명하는 것은 생각보다 쉽지 않기 때문이다. 특히 자신 있는 기술일수록 잘 설명할 수 있어야 한다. 잘 다루는 기술을 설명할 수 없다면 모르는 것과 차이가 없다. 많이 다뤘던 기술이나 개념을 말로 설명하지 못해 모르는 것이 돼버리는 안타까운 경우가 비일비재하다. 잘 알고 있다고 생각했던 것도 말로 설명하려면 어려운 경우가 많기 때문에 설명하는 연습을 충분히 한다. 경험했던 기술은 모나드를 제외하고는 설명할 수 있어야 한다. 모나드 라면… 면접관도 이해해 줄 것이다.
아무튼 기술에 대한 경험과 이해는 별도로 생각하자. 제대로 설명할 수 없으면 아예 적지 말거나 가볍게 사용만 했다는 등의 이유로 이해도가 높지 않다고 솔직하게 말하자. 괜히 모르는 걸 억지로 설명하려고 횡설수설하게 되면 고작 한 개의 질문으로 면접 시간 내내 말리는 경우도 있다.
<h2>커리어</h2>
간혹 면접 중에 본인이 성장하지 못했던 원인을 팀(or 회사) 탓을 하는 경우가 있다. 물론 회사 사정상 팀이 도무지 성장할 수 없는 안 좋은 팀 일 수도 있다. 하지만 그런 식으로 시간이 무의미에게 흘렀다면 그건 본인의 잘못이다. 팀에 문제가 있다면 답은 셋 중 하나다. 적응하던가, 바꾸던가, 나가던가.
결론적으로 퇴사를 결정하고 이직을 시도하는데 채용 과정에서 족족 떨어진다면 그건 아직 뭔가 부족한 것이다. 이직할 때 사용할 무기가 아직 없는 것이다. 이직하기 전에 현재 회사에서 날이 선 칼 하나는 다듬고 나오자. 시작 부분에 설명했던 본인의 역량을 어필할 수 있는 무기 말이다.
기본적으로 인재를 채용하는 회사는 지원자의 현재 회사에서 좋은 역할, 좋은 역량을 보여주는 사람을 뽑고 싶어 한다. 현 회사에서도 자리를 못 잡고 능력을 펼치지 못하는 사람을 뽑고 싶어 하는 회사는 없다. 이직을 하기 전에 우선 내가 문젠지 회사가 문젠지 잘 따져보고 작은 무기라도 하나 만들고 나오자.
조직의 미숙함은 퇴직 사유로 자주 사용되지만 팀의 문화가 좋지 않고 동료들이 부족하다면 반대로 커리어를 만들 좋은 기회일 수도 있다고 생각한다. 팀에 좋은 문화를 안착시키거나 동료들에게 귀감이 될만한 성과를 만들어 내 무기로 만든다. 물론 이게 쉬운 일은 아니다. 하지만 이미 좋은 문화를 가진 팀이나 좋은 성과를 내는 훌륭한 동료들 사이에서보다는 쉽지 않을까? 다들 좋은 회사를 가고자 하지만 좋은 회사일수록 굇수들 투성이다. 배울 수 있는 장점이야 있겠지만, 굇수들 사이에서 살아남는 것도 그렇게 호락호락하지 않다.
<h2>개발자 커리어에 대한 팁</h2>
주어진 업무를 그저 수동적으로 하지 않고 커리어를 만든다는 마음으로 일을 하는 사람은 업무를 대하는 태도가 다르다. 커리어를 만들기 쉬운 업무 진행 사이클을 하나 소개한다.
<ol>
<li>업무를 통해 무언가를 배운다(이해함, 깨닳음, 문제를 해결함, 무엇을 도입함 등등)</li>
<li>크건 작건 배운것을 메모한다.</li>
<li>메모해둔 것을 토대로 글을 작성해 공유한다.</li>
<li>작성한 글을 토대로 발표나 교육을 한다.</li>
<li>go to 1</li>
</ol>
업무를 통해 무언가를 배울지 말지는 본인의 마음가짐에 달려있다고 생각한다. 뭐 물론 매번 배울 수는 없겠지만 같은 업무를 하더라도 커리어를 만들려는 태도로 접근하면 그 안에서 또 새로운 도전과제를 찾을 수 있다. 무엇이든 조금이라도 개선할 거리를 찾아보자.
업무 중에 깨닫거나 배운 것은 짧게라도 반드시 메모해두자. 일상적인 작업을 하다가 단편적인 이해의 조각들이 서로 연결되면서 “뙇”하고 큰 그림 개념이나 원리를 깨닫거나 더 나은 방법이 떠오르는 순간이 있는데 그런 것은 절대로 놓치지 않고 메모해둔다. 그런 내용은 누군가에게 도움이 될 것이고 누군가에게 도움이 된다면 성과의 구체적인 사례가 될 수 있다. 그 외 문제를 해결한 것이 있다거나 기술을 도입하면서 느낀 점 등 아무튼 몰랐던 것을 알게 된 것이라면 꼭 메모해두자.
정리한 메모를 토대로 글을 작성한다. 메모는 훌륭한 글감이 된다. 쓰고자 하는 주제가 있을 때도 좋은 소재로써 도움이 되지만 메모 정리를 잘해두면 역으로 동일한 카테고리의 메모를 모아서 훌륭한 글쓰기 주제를 만들 수 있다.
작성된 글을 공유하고 또 그 글을 토대로 발표나 교육을 한다. 글로 이미 내용이 정리된 상태고 흐름까지 만들어져 있으니 추가로 장표를 준비해 글 대신 말로 풀기만 하면 된다. 물론 이게 글 쓰는 거 다르고 발표하는 것 다르긴 하지만 처음부터 발표를 준비하는 것보다는 훨씬 수월하다. 각 단계는 모두 연결되어 있어 거의 1타 3피 효과가 있다. 이런 사이클을 반복하다 보면 좋은 커리어가 만들어질 수 밖에 없다.
물론 이 방법이 모든 사람에게 맞진 않을 수 있다. 적어도 글을 쓸 생각으로, 발표를 할 생각으로 업무를 하면 업무를 대하는 태도 자체가 달라진다. 그동안 외부 내부에서 지켜본 결과 위와 같은 사이클로 일을 하는 사람들이 좋은 개발자로 성장해 인정받을 가능성이 매우 크다는 것을 알게 되었다. 그래서 신입이던 경력이던 새로운 동료를 만나게 되면 늘 말해주고 있다.
<h2>끝으로</h2>
요즘은 개발자에게 여러 가지를 기대한다. 개발은 당연히 잘해야 하고, 어디서 교육이나 발표한 경험도 있어야 하고 블로그도 써야 하고 오픈소스 활동이나 커뮤니티에 기여하기도 한다. 물론 이런 스펙(?)들이야 있으면 좋겠지만 이런 과정을 통해 무엇을 경험하고 배웠는지가 더 중요하다. 이력서의 스펙대로라면 충분히 알아야 할 내용을 면접 과정에서 제대로 설명하지 못한다면 오히려 역효과만 생긴다. 이력서는 매력적일지 모르지만 면접에서 결국 탈락한다.
채용은 회사나 지원자나 서로 준비를 철저히 해야한다. 면접관들의 질문이 너무 뻔한 족보 같은 내용들이고 이력서는 읽어보지도 않은 것 같다면 그 회사는 들어갈 가치가 없다고 생각한다. 채용에는 면접관 못지않게 지원자도 시간적인 리소스를 많이 사용하는 만큼 면접관 역시 충분히 준비를 하고 정중하게 채용에 임해야 한다. 그렇지 않은 면접관을 만났다면 어차피 입사해도 그 사람이 윗사람이 될 가능성이 크고 그런 사람 밑에서는 배울 게 없다. 지원자를 생각하는 마음이 부하직원과 동료를 생각하는 마음으로 이어진다.
그런 의미에서 NHN FE개발랩은 언제나 훌륭한 개발자를 채용하고 있다. 지원자의 시간을 소중히 생각하며 한 분 한 분 정성을 다해 채용 프로세스를 진행한다. 조직이나 채용에 대해 궁금한 점이 있다면 언제든지 이메일을 통해 남겨 주기 바란다.</article></div>

shiren.dev RSS Feed

5~6년 차 즈음부터 개발자 채용에 조금씩 관여하기 시작했고 현 회사에서는 면접관으로 활동한지 5년이 넘은 것 같다. 면접은 1차 면접에 해당하는 기술 면접이었고 팀의 채용 프로세스를 개선하거나 사전과제, 라이브 코딩 문제 출제에 주도적으로 참여했다. 그간 다양한 개발자들을 만났고 운 좋게도 좋은 개발자들을 많이 채용할 수 있었다. 채용 과정에서 좋은 개발자도 만났지만 그렇지 못했던 개발자도 많았고, 아쉬웠던 개발자도 있었다. 아쉬웠던 개발자들은 노력을 하고 있지만 “어느 정도”로 “어떤 방향”으로 해야 하는지 모르는 경우였고 채…

누구나 원하는 개발자되기

댓글