안녕하세요.

오늘은 이력서 전형에 대해 이야기 나눠보고자 합니다. 현재 채용시장은 과거와는 비교할 수 없는 경쟁률을 자랑하고 있어, 이력서에서도 더 높은 기준이 요구되고 있습니다.

이 포스팅에서는 시장에서 요구하는 이력서의 기준과 대부분의 지원자가 어떤 사유로 탈락하는지, 그리고 이를 개선할 방법에 대해 하나씩 다뤄보겠습니다.

오늘 다룰 이력서는 특정 기업 타겟의 공채 지원서가 아닌 범용적으로 사용되는 자유양식의 이력서를 기준으로 이야기합니다.

과거와 무엇이 달라졌을까요?

우선, 과거 개발자 이력서의 목적에 대해 알아봅시다. 과거에는 개발자의 수요에 비해 공급이 부족했습니다. 그 결과, 이력서의 주된 목적은 지원자의 신상 파악, 배경, 개발 경험을 확인하는 것이었습니다.

그 당시에는 경험의 나열만으로도 다음 절차 진행 여부를 결정할 수 있었습니다. 사용한 기술 스택, 진행한 프로젝트의 난이도 등을 확인하고, 이후 기술 과제, 코딩 테스트, 면접 등의 절차에서 역량을 판단할 수 있었기 때문입니다.

하지만 최근의 채용에서는 적은 채용 인원과 너무나 많은 지원자로 인해 서류 필터링이 더욱 어려워졌습니다. 많은 인원을 다음 전형에서 판단할 수 있다면 좋겠지만, 실무를 진행해야 하는 개발자가 하루 종일 면접을 보는 것은 회사 입장에서 큰 손실입니다.

그렇기 때문에, 이제는 이후에 진행되던 역량 평가를 서류 전형에서도 점점 더 비중 있게 다루기 시작했습니다.

이제는 이력서에서 나의 역량을 명확히 보여줄 수 있어야 합니다.

이력서에서 어떻게 역량을 평가할 수 있을까요?

위 내용에 따르면 과거와 달리, 이력서에서 지원자의 역량을 명확히 평가할 수 있어야 합니다.

만약 이력서에서 이를 충분히 보여주지 못한다면, 역량이 확인되지 않아 짧은 검토 후 탈락할 수 있습니다.

안타깝게도 지원자가 자신의 개발 경험을 잘 녹여냈더라도 이 내용들이 충분히 검토되지 않고 탈락할 가능성이 있습니다.

물론 이미 화려한 경력과 훌륭한 커리어를 가진 경우는 예외입니다. (예: 카카오 5년 재직, 1000만 이상 트래픽 경험 등)

프로젝트, 연구 등에서 알아볼 수 있는 지원자의 사고과정

최근 많은 지원자들이 성과의 중요성을 인지하고 있습니다. 대부분 이 성과를 단순한 수치로 표기하는 데 집중하는 실수를 합니다. 하지만 서류 검토관이 궁금한 것은 이 수치가 어떤 방법과 과정을 통해 나왔는지입니다.

예를 들어, 기존에 느린 로드 속도를 개선하는 방법에는 다양한 방법이 있습니다.

캐시를 통한 해결, 병렬적인 호출, 쿼리 최적화 등 여러 선택 옵션 중에서 무엇을 왜 선택했고 이를 실행하는 과정에서 무엇을 배웠는지가 중요합니다.

이 과정을 잘 작성하면 논리적 추론 과정을 검증할 수 있으며, 이는 곧 문제 해결 능력을 확인할 수 있는 방법입니다.

고민과 해결과정을 통해 나온 결과물의 성과

위의 사고 및 실행 과정을 잘 작성했을 때, 성과에 대한 지표가 더 빛을 발할 수 있습니다. 성과를 수치로 표기하면 더할 나위 없이 완벽한 역량을 보여줄 수 있습니다.

• 로드 속도 0.2ms에서 0.01ms로 단축
• 메모리 사용량 100MB 절감
• 인프라 비용 평균 X원 > Y원으로 절감

하지만 주의할 점은 너무나도 당연한 해결 방법과 문제 경험은 큰 도움이 되지 않습니다.

📱 모바일

❌ 안좋은 예: View와 비즈니스 로직이 복잡해져 MVVM을 도입해 비즈니스 로직을 담당할 수 있는 VM을 만들어 View의 복잡도를 낮추었습니다.
✅ 좋은예: VM의 State를 관리하는 데에는 문제가 없었지만, 토스트 또는 얼럿을 노출시키는 이벤트를 다루는 데 어려움이 있었습니다. 이를 해결하기 위해 Event Publisher를 담당할 수 있는 별도의 State를 만들어 이를 View에서 구독해 이벤트를 다루었습니다. View State와 Event가 분리되어 혼동 없이 상태 관리를 할 수 있게 되었습니다.

🖥 프론트

❌ 안 좋은 예: 백엔드 개발자와 적극적인 API 소통을 진행했습니다. 이로 인해 API 및 JSON 스펙에 대한 이해도를 높일 수 있었습니다.
✅ 좋은 예: 프로덕트 자체를 사이드 프로젝트로 진행하다 보니, 백엔드 개발자와 작업 시간대가 다른 경우가 많았습니다.
그렇다 보니 API 작업이 완료되지 않은 상황에서 컴포넌트 제작을 완료하는 경우가 발생했습니다. 테스트 시 API interlocking 과정이 별도로 필요하게 되고, 서로 간의 불필요한 시간이 발생했습니다.
이런 시간적인 어려움을 해소할 수 있는 좋은 방법이 없을지 고민했고, openapi spec을 기반으로 한 백엔드, 프론트엔드 모두 싱크할 수 있는 스펙을 작성했고, MSW 기반으로 한 Mock API를 구현함으로써 소통에 대한 시간을 단축할 수 있었습니다.

🚧 백엔드

❌ 안 좋은 예: RESTful API를 기반으로 상품의 좋아요와 장바구니 CRUD API를 작성했습니다.
✅ 좋은 예: 현재 서비스 내에서 A 대상군의 실 결제 전환율 개선을 위한 기능으로 상품의 즐겨찾기와 좋아요 기능을 구현했습니다.
'즐겨찾기'는 구현에 큰 어려움이 없었으나, '좋아요' 같은 경우에는 상품에도 좋아요 수를 업데이트해야 하는 작업이 있어 상품 테이블에 대해 데드락 이슈가 간간히 발생했고, 좋아요를 할 때마다 쿼리를 날려 DB에 Write 요청이 많은 것도 큰 문제가 되었습니다.
따라서 이를 해결하기 위해 Cache Counter를 도입하였고, 5분 단위로 해당 Cache Counter에 등록된 값이 DB에 반영되도록 하였습니다. 프론트에서 좋아요 수를 요청할 때는 Cache Counter에 등록된 값과 DB에 있는 값을 더해서 내려주는 방식으로 실시간성을 어느 정도 해소했습니다.

서비스 운영경험

최근 지원자들이 많아지고 상향평준화되면서 전체적으로 높은 기준이 요구되고 있습니다. 이런 측면에서 보았을 때, 실제 고객과 소통해 본 경험을 어필하는 것은 큰 차별점이 될 수 있습니다.

실전 경력이 없거나 부족한 경력의 보완재

실제 고객과 소통해 본 경험은 실전 경력이 부족한 지원자들에게 큰 강점이 될 수 있습니다. 이는 단순히 기술적인 역량뿐만 아니라, 고객의 요구를 이해하고 이를 해결하는 능력을 보여줍니다.

완성도 있는 프로젝트 진행 증거

단순한 프로토타이핑이 아닌, 실제 고객을 만날 정도로 완성도 있는 프로젝트를 진행했다는 증거가 될 수 있습니다. 이는 지원자가 프로젝트를 처음부터 끝까지 책임지고, 실질적인 결과물을 만들어낼 수 있는 능력을 가지고 있음을 보여줍니다.

제품 감각 및 프로덕트에 대한 관심 어필

고객의 피드백을 듣고 이를 반영할 수 있을 정도로 제품에 대한 감각이 있고, 프로덕트에 대한 관심이 있음을 어필할 수 있습니다. 이는 특히 프로덕트 중심의 서비스 회사에서 긍정적으로 작용할 수 있습니다. 고객의 피드백을 수용하고 개선점을 반영하는 능력은 제품의 완성도를 높이는 데 필수적입니다.

실제 고객과의 소통 경험은 기술적 역량을 넘어, 문제 해결 능력과 고객 지향적인 사고를 갖춘 지원자로서의 인상을 줄 수 있습니다. 이는 특히 경쟁이 치열한 채용 시장에서 나만의 강점을 부각시키는 데 큰 도움이 될 것입니다.

전체적인 이력서에서 보이는 이 개발자의 스타일

역량에 대한 측면은 아니지만 어필하면 좋은 부분이라 함께 넣었습니다.
기본적으로 지원자가 한 팀원이 되었을 때 팀에서 어떤 역할을 하고 향후 몇 년 뒤에 어떤 개발자가 될까라는 질문에 답할 수 있는 내용이 있다면 좋습니다. 이러한 스타일을 통해 지원자가 팀에 어떻게 기여할 수 있을지를 명확히 전달할 수 있습니다.

스타일에는 다양한 내용이 있을 수 있습니다.

기술적인 딥다이브로 신뢰할 수 있고 기술적인 문제를 책임지는 연구원 성격의 엔지니어

이 유형의 엔지니어는 깊이 있는 기술적 이해와 문제 해결 능력을 바탕으로 팀의 기술적인 과제를 해결합니다. 복잡한 기술 문제를 다루고, 최신 기술 동향을 연구하며, 기술적인 결정을 내리는 데 중요한 역할을 합니다. 예를 들어, 특정 기술 스택에 대한 전문가로서 팀의 기술적 리더 역할을 수행할 수 있습니다.

제품의 관심과 높은 애정도를 가진 프로덕트 메이커 성격의 엔지니어

이 유형의 엔지니어는 제품에 대한 깊은 관심과 애정을 가지고 있으며, 사용자의 요구를 반영하여 최고의 사용자 경험을 제공하는 데 중점을 둡니다. 고객의 피드백을 반영하고, 제품의 개선을 위해 지속적으로 노력하며, 제품 개발의 모든 단계를 적극적으로 참여합니다. 예를 들어, UX/UI 개선, 새로운 기능 제안 및 구현 등을 통해 제품의 가치를 높이는 데 기여할 수 있습니다.

팀의 생산성을 중요하게 생각해 팀 문화를 적극적으로 이끄는 엔지니어

이 유형의 엔지니어는 팀의 생산성과 협업을 중요하게 생각하며, 긍정적인 팀 문화를 조성하는 데 앞장섭니다. 팀워크를 촉진하고, 효율적인 작업 방식을 도입하며, 팀원들 간의 의사소통을 원활하게 합니다. 예를 들어, 애자일 방법론 도입, 코드 리뷰 문화 활성화, 멘토링 등을 통해 팀의 전체적인 생산성을 향상시키는 역할을 할 수 있습니다.

지원자의 스타일은 이력서에 구체적인 사례와 함께 서술하는 것이 좋습니다. 이렇게 함으로써 지원자는 자신의 강점을 명확히 어필할 수 있고, 검토관은 해당 지원자가 팀에 어떤 가치를 더할 수 있을지 쉽게 파악할 수 있습니다.

가장 많이 탈락하는 사유

위 내용을 잘 읽으셨다면 이력서 탈락 사유 중에 가장 많은 비중을 차지하는 부분이 무엇일지 예측할 수 있을 것입니다. 바로 역량 평가가 불가능한 이력서입니다.

왓에버 서류검토 서비스의 평균 PASS률은 약 9% 정도입니다. 나머지 NON-PASS 하신 분들 중에 약 80% 정도의 지원자들이 이 역량 평가가 불가능해 탈락합니다. (왓에버의 서류검토 PASS 기준은 실제 검토관들이 지원자와 비슷한 연차의 동료를 뽑는다고 가정했을 때 인터뷰를 보고 싶을 만큼 매력적인지입니다.)

그 외의 대표적인 탈락 사유는 아래와 같습니다:

역량을 잘 기입했지만 시장 경쟁자 대비 역량이 아쉬운 경우

지원자가 자신의 역량을 잘 기술했음에도 불구하고, 다른 지원자들과 비교했을 때 상대적으로 부족해 보이는 경우입니다. 이는 주로 지원자의 경험이나 기술 수준이 동일한 직무를 희망하는 다른 지원자들에 비해 미흡할 때 발생합니다.

기술 역량은 충분하지만 나만의 엣지 포인트나 어떤 스타일의 개발자인지 확인하기 어려운 경우

기술 역량이 충분히 기술되어 있지만, 지원자가 어떤 개발자 스타일을 가지고 있는지 명확하지 않은 경우입니다. 예를 들어, 지원자가 문제 해결에 집중하는지, 제품 개발에 열정이 있는지, 팀워크를 중시하는지 등의 정보를 알기 어렵다면, 검토관은 해당 지원자가 팀에 어떤 가치를 더할 수 있을지 판단하기 어렵습니다.

GitHub, 부가적인 정보의 확인 불가능, 오타 등 기본적인 지원자의 성실성에 대한 의문이 있는 경우

이력서에 GitHub 링크가 없거나, 부가적인 정보(포트폴리오, 블로그 등)를 확인할 수 없을 때, 지원자의 실제 역량을 평가하기 어렵습니다. 또한, 오타나 불명확한 표현이 많을 경우 지원자의 성실성에 의문이 생길 수 있습니다. 이는 작은 실수처럼 보일 수 있지만, 채용 담당자에게는 지원자의 꼼꼼함과 신뢰성을 평가하는 중요한 요소가 됩니다.

그 밖에도 다양한 탈락 사유가 있지만, 주된 내용은 위와 같습니다. 지원자는 이력서를 작성할 때 자신의 역량을 명확히 드러내고, 검토관이 이해하기 쉽게 구조화하며, 자신의 스타일과 차별점을 부각시키는 데 주력해야 합니다. 또한, 작은 실수나 누락이 치명적인 결과를 초래할 수 있으므로, 최종 검토를 철저히 해야 합니다.

Q&A

다음은 이력서에 대해서 자주 묻는 질문들과 그 밖에 팁에 대한 내용입니다.

자기소개서와 포트폴리오를 어떻게 차이를 둘까요?

나의 기본신상, 경험, 역량을 보여주는 데에 중점을 두세요. 검토관이 쉽게 읽고 이해할 수 있도록 구조화된 형식으로 작성하는 것이 중요합니다.

예를 들어, 프로젝트에서 나의 고민 과정과 상세 사례를 이력서에 모두 담기에는 분량이 많을 수 있습니다. 이 경우 짧고 임팩트 있는 내용을 중심으로 축약하여 이력서에 기재하고, 상세한 내용은 노션, 블로그, 레포지토리의 리드미 파일 등으로 분리해 포트폴리오, 회고록, 트러블슈팅 형식으로 작성하는 것이 좋습니다.

하지만 이렇게 분리할 때 너무 많은 폴더를 만들거나 과도하게 분리하는 것은 지양해야 합니다. 하나의 프로젝트를 볼 때마다 여러 페이지를 이동해야 한다면, 검토하는 사람 입장에서 전체적인 맥락을 파악하는 데 어려움이 있을 수 있습니다. 따라서 이력서를 검토하는 사람의 경험을 고려하여, 전반적인 맥락이 쉽게 이해될 수 있도록 구성하는 것이 중요합니다. 이를 통해 검토관이 이력서를 읽는 과정에서 불편함을 느끼지 않도록 해야 합니다.

이력서의 역량을 잘 나타내더라도 탈락할 수 있나요?

위의 기타 탈락 사례와 마찬가지로, 이력서 탈락 사유는 매우 다양합니다.

하지만 요즘 채용 과정에서 가장 많은 탈락 사례는 지원자의 역량과 성장 과정을 명확히 보여주지 못한 경우입니다.

또한, 이력서를 제출하는 시점에 이미 다른 지원자가 합격하여 채용이 마감된 경우 자동으로 탈락 처리되는 경우 등 탈락사유는 굉장히 다양합니다.

테스트 코드 작성을 어필해도 될까요?

테스트 코드 작성을 강조하는 지원자가 많습니다.

하지만 테스트 코드에 대한 필요성은 조직마다 다를 수 있습니다. 특정 기술이나 스타일을 강하게 어필하기보다는 대부분의 조직에서 선호될 수 있는 기술과 역량을 어필하는 것이 좋습니다. 특정 기술에 대한 과도한 강조는 오히려 부작용을 일으킬 수 있습니다.

이력서의 분량은 2-3장이 맞나요?

최근 긴 이력서가 매력적이지 않다고 하여 무조건 분량을 줄이려는 경향이 있습니다. 하지만 중요한 것은 지원자의 역량과 경험을 충분히 전달하는 것입니다. 이력서는 검토관의 피로를 줄이고 좋은 검토 경험을 제공하기 위해 간결하게 작성되어야 합니다. 그러나 필요한 내용을 충분히 담는 것이 중요합니다.

HR에서 1차 필터링을 하고 실무 개발자에게 넘기는 경우가 많지만, 여전히 많은 이력서를 검토해야 하는 상황에서 불필요한 자기소개, 희망 연봉, 취미 등 불필요한 정보를 포함시키면 좋은 인상을 주기 어렵습니다. 따라서 분량에 대한 제약보다는 검토관이 쉽게 이해하고 좋은 인상을 받을 수 있도록 이력서를 작성하는 것이 중요합니다.

마무리

이 정보가 여러분의 취업 준비에 도움이 되기를 바라며, 경쟁이 치열한 채용 시장에서 자신을 효과적으로 어필하는 데 도움이 되었으면 좋겠습니다.

꾸준히 노력하고, 자신의 경험과 역량을 명확하게 표현하는 이력서를 준비하여 좋은 결과를 얻으시길 바랍니다.

왓에버는 더 나은 커리어를 만들어 나가고 싶은 개발자 취업 준비생 및 이직 준비생을 위해 존재합니다. 여러분이 성공적인 커리어를 쌓을 수 있도록 다양한 서비스를 제공하고 있습니다.

1. 오늘 내용이 흥미로웠다면 왓캐스트 [참가하기]

6월 30일 오후 9시, 이 포스팅을 주제로 한 왓캐스트가 진행될 예정입니다. 훌륭한 왓에버의 멘토분을 게스트로 모셔서 이력서에 대한 이야기를 나누는 시간을 가질 예정입니다.
이 기회를 통해 여러분은 발언권을 얻어 직접 질문을 하거나 의견을 나눌 수 있습니다.질문을 남겨주시는 분들 중 추첨을 통해 기프트도 전달해 드릴 예정이니 많은 관심 부탁드립니다.
디스코드 이벤트에 참여하여 많은 관심과 참여 부탁드립니다. 함께 성장하고 더 나은 커리어를 만들어가는 기회가 되길 바랍니다.

2. 오늘 내용을 토대로 나의 이력서 [서류 검토 받기]
여러분의 이력서를 실무진의 시각에서 검토하여 탈락 사유를 받아볼 수 있습니다. 이를 통해 이력서의 문제점을 파악하고 개선할 수 있습니다.

3. 진짜 기술 꼬리 질문과 이력서 질문으로 나의 현주소를 알 수 있는 [커리어 상담 받기]
전문가와의 상담을 통해 실제 기술 인터뷰에서 나올 수 있는 꼬리 질문과 이력서 관련 질문을 받아보세요. 이를 통해 자신의 현재 기술 수준과 준비 상태를 정확히 파악할 수 있습니다.

4. 빅테크/유니콘 출신 최고의 개발자에게 [과외 받기]
빅테크 기업이나 유니콘 기업 출신의 최고의 개발자로부터 직접 과외를 받을 수 있습니다. 이를 통해 최신 기술 트렌드와 실무 경험을 배우고, 자신만의 강점을 키울 수 있습니다.