우아한형제들의 프론트엔드 그룹장 김민태님의 강연

본 글은 패스트캠퍼스에서 진행한 sudo : CTO's Tech Talk 2022 컨퍼런스 내용을 바탕으로 정리한 것입니다.

강의를 진행하게 된 계기

안녕하세요 우아한형제들에서 프론트엔드 개발 그룹장을 맡고 있는 김민태입니다. 저는 입사 지원자들을 많이 보면서 90%에 가까운 이력서가 안타까움을 가진 것을 보고, 스스로가 가진 장점들을 기업에 잘 부각시킬 수 있기를 바라는 마음에서 이 강의를 시작하였습니다.

• 최근 많은 인재들이 필요해졌고 개인 입장에선 좋은 회사를 골라서 들어갈 수 있는 상황이 되었습니다
• 그러나 같이 일해보고 사람을 뽑을 수는 없기 때문에 기업이 개인의 능력을 완벽하게 파악하는 것은 쉽지 않습니다
• 개인의 능력은 어떻게 확인될까요?
  여러 기업들이 개인의 능력을 같이 일해보지 않고 확인하기 위한 방법을 찾고 있지만 뾰족한 방법은 없는 상황입니다. 신입 개발자는 자소서 등에 많은 시간을 들이고 블로그나 깃헙 자체를 오픈한느 경우도 있지만 이런것 만으로는 충분하지 않습니다.
• 결국 '경험과 성장'이 중요합니다
  '과거의 경험을 근거로 현재를 표현하여 미래의 성장 가능성을 보여준다'
  미래에 얼마만큼 성장할 수 있는 인재인가?
  경험으로 어떻게 예측가능한 성장성을 보여 줄 것인가?
  

첫 번째 관문 '문서'

좋은 회사들의 입사 전형은 모두 서류 통과를 해야 2차 면접의 관문까지 갈 수 있는 깔데기 구조로 되어있습니다. 그러나 수 많은 문서를 보면서 눈에 띄는 문서를 찾기는 정말 힘듭니다. 왜 그럴까요?

• Boilerplate(이력서의 형식)
  입사 지원서에 이런 정해진 형식을 사용하는 경우가 너무 많습니다. 이러한 형식이 과연 경쟁력을 가질 수 있을까요? 인사담당자는 이러한 형식을 마주할수록 점차 편견에 쌓이게됩니다. 이렇게 되면 자연스럽게 지원자의 학력으로 눈이 가고, 이러한 문제를 없애기 위해서 다시 학력란을 없애고 있는데 이러한 현상은 능력이 있는 분일수록 득보다 실이 더 많습니다. 이런 문제를 어떻게 탈피할 수 있을까요? 지원자는 이러한 틀을 벗어나서 개성을 충분히 표현해 줄 수 있어야 합니다. 개발자 개인의 성장은 결국 기업에도 도움이 됩니다. 어떻게하면 형식에 얼매이지 않고 나의 개성을 표현할 수 있을지 고민이 필요합니다. 그러나 너무나 과한 개성 표현은 문제가 될 수도 있습니다. 예를들어 프론트엔드 개발자의 이력서 중 비쥬얼에 지나치게 치중한 경우가 있는데 우리는 디자이너가 아닌 엔지니어를 뽑는 것이기 때문에 그것이 경쟁력이 될 수 있을지는 고민해보아야 합니다. 결국 엔지니어 측면에서 자신의 능력을 어필하는 것이 필요합니다.

• 경력기술서
  지원자의 경험을 표현한 경력기술에서의 문제는 흔하게 볼 수 있는 워딩입니다. 설계/서비스 오픈/서비스 운영 등 이렇게 쓰여져 있는걸 보면 어떤 느낌이 오는지 반대로 한 번 생각해 보세요. 이 분이 어떤 역량을 발휘했는지에 대해선 아무 정보도 없습니다. 서비스 안에서도 무수한 판단과 결정, 논쟁 등 다양한 경험이 있을텐데 이렇게 되면 타이틀만 적고 끝나는겁니다. 아무 의미가 없는 것이죠. 그렇다고 양을 늘려서 모든 것들을 적는 경우도 경쟁력을 나타내는 지표로는 아무 의미가 없습니다. 회사가 알고싶은 것은 만약 설계를 했다면 어떤 설계를 했는지, 당시에 어떤 요구사항들이 있었고 이를 위해 어떤 생각을 해서 어떤 성과를 냈는지 이고 이것들이 바로 개인의 성과를 나타내는 방법입니다. 서비스 오픈의 경우도 정말 제대로 운영을 해봤다면 무수히 많은 일들이 일어났을겁니다. 이처럼 단순한 워딩만으로 적힌 경력기술서는 채용 담당자를 예측에 의존하도록 만듭니다. 실제로도 보통 10명 중 9명은 똑같은 방식으로 씁니다. 정말 누구나 아는 유명한 프로젝트에 참여한 것이 아니라면 인사 담당자는 이러한 방식의 경력기술서를 보고는 어떤 경험을 했는지 전혀 알 수가 없습니다.

• 기술의 등급화
  특정 기술을 등급화해서 평가하는 경우(ex) 리액트 별 3개) 면접관에게 공격 당할 포인트가 될 수 있다고 생각합니다. 만약 자바스크립트를 별로 표현한다면 그것의 범위는 어디서 부터 어디까지이고, 5점 만점이면 더 이상 배울게 없다는 말씀이신가요? 등의 질문이 나오면서 보통의 면접자들은 여기서 숨이 막히기 시작합니다. 왜 타입스크립트는 별 3개이지요 등 여러가지 질문들이 나오게 되면 한 번도 논리적인 근거로 대답하시는 분을 본 적이 없습니다. 굉장히 안좋은 표현 방법이라고 생각합니다. 보통 면접에선 왜 그 기술을 선택하셨나요? 를 굉장히 많이 묻습니다. 거기서 부터 관련 질문들이 줄줄이 따라오게 됩니다. 역량있는 개발자라면 모든 것에 다 이유가 있어야 합니다. 타입스크립트를 왜 사용하셨나요 라는 질문에 남들도 다 하고있고, 트렌드를 따라가기 위해서 라고 대답하면 광탈합니다. 개발자의 가치는 그의 코드로 만들어진 프로덕트의 가치를 올릴 수 있을 때 높아지는 것입니다. 소프트웨어 개발자를 왜 대우해 줄까요? 엔지니어의 존재 이유는 제품 가치를 끌어올리는 것입니다. 특정 기술을 그냥 유행에 뒤처지지 않기 위해 사용한다고 말한다면 이는 개발자의 본질을 무시하는 처사입니다.
  

• 보유 기술
  내가 현재 어떤 기술을 보유하고 있는지의 측면에서 보유기술을 적는데, 여러 기술을 적는 것은 기본적으로 좋습니다. 문제는 면접관이 생각했을 때 나는 개발자를 뽑는데 이력서에 Photoshop 등이 적혀있는 경우입니다. 사람들은 단어 하나로 편견에 휩싸일 수 있습니다. 이 단어 하나를 적음으로써 면접관은 색안경을 끼고 나머지를 바라보게 됩니다. 신입은 상대적으로 이런 상황이 괜찮지만 경력자의 경우 광탈입니다.

• 결론
  결국 자신의 경험을 잘 드러내는 이력서가 개성있는 이력서라고 생각합니다!
  

두 번째 관문 '만남'

면접의 경우 서류보다는 생각보다 쉽다고 생각합니다. 요즘은 많은 회사들이 입사 프로세스 자체를 줄이려고 노력중입니다. 문제는 입사라고 하는 과정은 서로간에 체크를 진행하는 것인데, 들어가서 어떤 일을 할건가요? 라고 물어보면 깊이 생각해보지 않은 분들이 많습니다.

• 성장에 대한 구체적인 계획
  모든 사람들이 늘 성장하고 싶다고 말하지만 결국 성장에 대한 플랜이 더 중요합니다. 의식적으로 어떤 부분을 어떻게 성장 시킬 것인지가 중요한데, 그냥 더 규모가 큰 서비스를 경험해 보고 싶어서 라고 말한다면 당신도 들어와서 경험해 보면 정말 좋겠네요 라고 말하지는 않습니다. 회사는 지금 프로덕트의 가치를 끌어올리기 위해서 사람을 채용하는 것입니다. 좋은 동료는 충분히 있는지, 같이 이끌어갈 주니어들은 있는지, 충분한 역량의 기획자와 디자이너가 존재하는지 확인한다면 이 친구는 분명한 자기 플랜과 열정이 있다고 생각합니다. 그러나 이러한 것에는 정상적인 판단을 하는 회사라는 전제가 필요합니다. 만약 문화적으로 충분히 성숙한 회사가 아니라면 지원자가 요구사항을 말하는 것을 좋은 느낌으로 받아들이지 않을 수 있습니다. 따라서 지원할 회사의 분위기를 파악하는 것도 중요합니다.

• 인간관계와 열정
  외향적이냐, 내향적이냐 이런 스타일은 그 사람의 역량과는 아무 관련이 없지만 사람간의 사이에는 영향을 미칩니다. 외향적일 수록 좋아할 사람은 많을 것입니다. 또한 제가 생각하는 열정은 두 종류가 있는데, 저는 막 끓어오르는 열정 보다는 불을 끈 이후에 남아있는 잔잔한 보글보글과 같은 열정을 선호합니다.

• 결론
  과거의 경험을 근거로 현재를 표현하여 미래 성장가능성을 예측할 수 있도록 하자!

질문과 응답

Q. 회사에 시니어 개발자가 없는 경우 어떻게 성장할 수 있을까요?

일단 시니어에 대한 환상을 깨야합니다. 시니어라고 해서 모두가 다 뛰어난 능력을 가진 것은 아니라고 생각합니다. 또한 개인적으로 성장의 기준은 기술이 아닌 프로덕트가 되어야 한다고 생각합니다. 기술은 결국 실력 수준에 대한 측정이 어렵습니다. 내가 어떤 것을 알았다고 해서 실력이 늘은 것은 아니라고 생각합니다. 프로덕트의 발전에 어떤 기여를 했는지가 결국 실력을 보여준다고 생각합니다.

Q. 개발자의 퇴사를 막는 방법이 있을까요?

일정 수준의 챌린지가 회사 내부에 지속적으로 떠다닐 수 있도록 해야 한다고 생각합니다. 만약 그런것이 없어서 지루한 회사를 나가겠다고 하는 사람을 붙잡기는 매우 어려울 것입니다.

Q. 이전까지 경험하지 못했던 경험을 요구하는 새로운 도메인의 회사를 지원할 때 어떤 식으로 준비해야 할까요?

의료 등의 분야는 저도 접근해본 적이 없습니다. 만약 저같으면 그 분야에 어떤 부분들이 기술적인 챌린지가 될 수 있는지 리서치를 하고, 내가 가진 경험을 응용해서 어떤 부분을 해결할 수 있을지 계획을 만들어 볼 것 같습니다. 나의 경험이 이 회사의 기술적 챌린지를 극복할 근거가 될 수 있다면 그 부분을 중심으로 지원해 보면 어떨까요?