안녕하세요, 여러분.

어느덧 2024년이 지나고, 새로운 2025년이 다가왔습니다..
지난 한 해가 쉽지 않았던 만큼, 많은 분이 새로운 희망과 목표를 가지고 계실 것 같습니다.

작년 하반기에 혹한기를 버텨낸 스타트업부터 빅테크, 대기업까지 크고 작은 채용을 진행하면서 올해는 채용 시장이 다소 개선될 것이라는 기대를 품게 되는 시점인 것 같습니다.

특히 상반기를 앞두고 취업과 이직을 고민하는 분들이 많아지고 있는데요,
저희 왓에버에서도 이전에 다뤘던 이력서 작성법 관련 콘텐츠가 큰 관심을 받았습니다.
그래서 이번에도 여러분께 도움이 될 수 있는 이력서 및 취업 준비 팁을 공유해드리고자 합니다.
[지난 글 보기]

왓에버의 이력서 멘토링 서비스를 진행하다 보면, 여전히 많은 분이 자신의 역량을 효과적으로 보여줄 수 있는 형태로 이력서를 작성하지 못하고 있다는 점을 느끼게 됩니다.

이런 과정을 겪으면서 저희는 "이력서 작성 플랫폼을 만들어 볼까?"라는 생각도 해보게 되었는데요.
그 첫걸음으로, 여러분께 어떻게 이력서를 구성하고 자신의 역량을 제대로 보여줄 수 있을지에 대한 템플릿을 블로그 콘텐츠로 공유하고자 합니다.

이번 글에서는 기존 이력서의 아쉬운 점에 대해 살펴보고, 다음 글에서는 왓에버가 제안하는 새로운 이력서 템플릿을 소개드릴 예정입니다.

조금 글이 길어질 수 있지만, 오늘은 기존 이력서에서 자주 보이는 문제점에 집중해 보겠습니다.
이 콘텐츠가 여러분께 더 나은 이력서를 만드시는 데 도움이 되길 바랍니다.

프로젝트 및 기술 스택

첫 번째로 다룰 아쉬운 점은 프로젝트와 기술 스택을 작성할 때 흔히 보이는 문제들입니다.
많은 분이 프로젝트와 기술 스택을 이력서에 포함하면서도, 이를 효과적으로 표현하지 못하거나 구체적으로 기술하지 못하는 경우가 많습니다.

이번에는 이러한 아쉬운 점들을 중심으로 살펴보고, 이를 개선하기 위한 팁과 방법을 공유드리겠습니다.

최상단에 기술스택 나열

기술 스택을 나열하는 것은 이력서 작성에서 필요할 수 있습니다.
하지만 그 기술들이 최근 취업 시장에서 누구나 접할 수 있는 흔한 스택이라면, 이를 굳이 강조할 필요는 없습니다.

왜냐하면 이런 내용은 나만의 엣지 포인트로 작용하기 어렵기 때문입니다.
특별하지 않은 기술 스택을 강조하다 보면 오히려 진부한 인상을 줄 수 있습니다.
또한, 프로젝트 경험을 잘 작성하면 사용한 대부분의 기술 스택은 자연스럽게 추론할 수 있기 때문에, 따로 걱정하지 않으셔도 됩니다.

그렇기 때문에 기술 스택 나열이 나만의 강점을 돋보이게 하는 대신, 오히려 약점이 될 가능성도 있습니다.
특히, 이력서에서 가장 중요한 첫 페이지 최상단에 기술 스택을 나열하는 것은 신중히 고민해 보실 필요가 있습니다.

프로젝트 기능 및 설명 나열

내가 진행한 프로젝트를 어필하는 것은 이력서에서 매우 중요한 부분입니다.
이 과정을 통해 나만의 경험을 보여줄 수 있고, 이는 곧 엣지 포인트가 될 수 있기 때문입니다.

하지만 많은 경우 프로젝트를 작성할 때 단순히 기능을 나열하거나, 경험했던 내용을 타이틀만으로 표현하는 실수를 하곤 합니다.

특히, 많은 개발자 취준생이 개별적으로는 다른 컨셉을 가진 프로젝트를 진행하지만,
기능적으로는 비슷한 제품(ex. 커뮤니티, 단순 CRUD)을 만드는 경우가 많습니다.

문제는 이와 같은 단순한 기능 설명이나 타이틀 나열로는 내가 어떻게 문제를 해결했는지를 충분히 전달할 수 없다는 점입니다.
같아 보이는 프로젝트라도 개발자마다 이를 풀어나가는 방식은 정말 다르기 때문입니다.

예를 들어:
“이 레이아웃은 어떻게 구현했는지”
“모듈을 어떻게 분리하고, 어떤 계층이나 도메인으로 구분해 설계했는지”
“성능 개선을 진행했다면, 어떤 쿼리를 통해 구체적으로 어떻게 개선했는지”

구체적이고 깊이 있는 설명이 없다면, 단순한 키워드와 타이틀만으로는 나의 역량을 전달하기 어렵습니다.

과거에는 단순히 내가 경험한 스택과 키워드, 프로젝트 타이틀만으로도 취업이 가능했던 시장이었습니다.

2-3년 전 검토관
“우리 회사와 비슷한 스택을 다뤘네. 인터뷰에서 직접 확인해 보면 되겠다.”

그러나 지금은 1개의 채용 공고에 수백 개의 지원자가 몰리는 시대입니다.
이로 인해 단순히 경험 스택, 키워드, 타이틀만으로는 인터뷰 단계에 진입하기 어려운 상황이 되었죠.

현재의 검토관
“음, 다 똑같이 기술 스택과 프로젝트 경험만 나열돼 있네. 과연 진짜 깊이 경험해 봤을까?”

물론 이미 검증된 회사에서의 경력이나, 누구나 알만한 서비스를 직접 만든 경험이 있다면 타이틀과 키워드만으로도 다음 전형으로 넘어갈 수 있습니다.
하지만 그렇지 않은 경우라면, 프로젝트를 통해 나만의 문제 해결 방식과 구체적인 차별점을 보여주는 것이 무엇보다 중요합니다.

성과 또는 결과만 나열한 경험

이제 많은 분이 "성과를 수치화하고 임팩트 있게 나타내자"는 점을 잘 알고 계신 것 같습니다.

예를 들어, "캐싱과 쿼리를 개선해 응답 속도를 3.0초에서 0.2초로 단축" 같은 내용을 이력서에서 쉽게 찾아볼 수 있습니다.
이와 같은 수치화된 성과는 분명 눈에 띄지만, 이력서를 검토하는 사람들에게는 다음과 같은 질문이 생기게 됩니다:

"어떤 쿼리를 어떻게 개선했을까?"
"캐싱은 어떤 방식으로 적용했을까?"
이런 구체적인 설명은 단순히 성과를 나열하는 것에서 그치지 않고, 지원자의 역량과 고민의 깊이를 파악할 수 있는 중요한 단서가 됩니다.

따라서 이력서에서 성과를 작성할 때는 인과관계를 명확히 하고,
"어떤 고민을 했고, 이를 어떻게 개선했는지"가 의문 없이 드러나도록 충분히 작성해야 그 의미가 제대로 전달됩니다.

자기소개

개발자 이력서에서 자기소개는 크게 중요하지 않을 수 있습니다.
왜냐하면 이력서를 검토하는 데 있어 가장 우선시되는 것은 바로 역량 검증이기 때문입니다.

하지만 우리는 단순히 기본을 충족하는 이력서가 아니라,
조금 더 나은 이력서, 그리고 높은 경쟁률을 뚫을 수 있는 이력서를 작성해야 합니다.

그렇기 때문에 자기소개가 부수적인 요소라 하더라도,
어떻게 작성하느냐에 따라 이력서 전체의 완성도를 높이고, 지원자의 차별점을 부각할 수 있는 기회가 될 수 있습니다.

1. 너무 긴 자기소개

요즘 기업에서 채용을 진행하다 보면 정말 많은 이력서를 접하게 됩니다.
지원자를 제대로 파악하기 위해 모든 이력서를 꼼꼼히 읽는 것이 맞지만,
실제로는 실무를 겸하고 있는 개발자가 수십 줄의 자기소개를 읽는 일은 큰 부담이 될 수 있습니다.

이런 경우, 길고 장황한 자기소개는 오히려 지원자의 장점을 빠르게 판단하기 어렵게 만듭니다.
때문에 자기소개는 간결하고 명확하게 작성하여 지원자의 강점을 효과적으로 드러낼 수 있어야 합니다.

[예시]500자 내외로, 나의 개발 실력과 강점을 보여줄 수 있는 구체적인 경험을 작성
(대기업 및 중견기업에서 자주 요구하는 형식)

짧지만 임팩트 있는 자기소개는 이력서 검토자의 시간을 절약하면서도,
지원자의 경쟁력을 부각시킬 수 있는 좋은 기회가 될 수 있습니다.

2. 개인적인 관심사, 취미

요즘은 많이 드물지만, 여전히 개인의 관심사나 취미 등을 통해 자신의 인성과 태도를 검증하려는 분들이 있습니다.

[예시] 꾸준한 운동을 통해 스스로 더 나은 몸을 만들어 바디 프로필을 촬영한 경험이 있습니다.
이 경험을 바탕으로 개발자의 커리어도 꾸준하고 작더라도 점진적인 성장을 이룰 수 있다고 생각합니다.

이런 경험은 분명 긍정적인 부분이 될 수 있지만, 이력서에서 가장 중요한 것은 역량 검증입니다.
따라서 본업인 개발 역량에 대한 자신감과 전문성을 더 부각시켜야 합니다.

나의 이전 경험이나 취미는 컬처핏이나 인성 인터뷰에서 간단히 언급하는 정도가 적절하며,
이력서에서는 실제 업무에 필요한 역량을 중심으로 작성하는 것이 중요합니다.

3. 검증할 수 없는 자기소개

자신의 개발자 가치관과 커리어의 목적지를 기술하는 것은 큰 장점이 될 수 있습니다.

[예시1] 어려운 문제를 마주치더라도 끈기있게 매달리고, 해결과정 자체에 배움과 성취감을 느낍니다.

[예시2] 사용자 경험을 중요하게 생각하고 프론트엔드 개발자로 더 나은 UX를 고민하고 제안합니다.

[예시3] 제품에 대한 깊은 관심과 이해도를 가지고 있고 이를 바탕으로 비즈니스 임팩트를 만들 수 있는 개발자입니다.

이 내용들은 모두 굉장히 좋은 아이디어와 가치관을 담고 있습니다.
하지만 너무 추상적이거나 당연한 이야기일 수 있습니다.

이런 경우에는 자기소개의 신뢰성을 높이기 위해 실제 사례나 구체적인 경험을 추가하는 것이 중요합니다.
자신의 이야기나 경험을 통해 이러한 가치관을 검증 가능하게 보여주는 것이 훨씬 효과적입니다.

탬플릿의 아쉬움

우리는 개발자이지만, 이력서에서는 검토관의 UX를 고려해야 합니다.
보다 나은 이력서 검토 경험을 제공하여, 나의 역량과 강점을 조금이라도 더 잘 평가받을 수 있도록 해야 합니다.

하지만 의도치 않게 검토하기 불편한 이력서를 작성할 때가 종종 있습니다.
이력서 작성 시 검토자의 입장을 고려하면, 더 효과적이고 인상 깊게 나를 어필할 수 있습니다.

너무 많은 스크롤 or 탭이 필요한 이력서

이 경우는 특히 경력이 있는 개발자들에게 나타납니다.

예시 1: 작업한 프로젝트가 많은 경우

개발자들은 1년의 경력을 쌓더라도 정말 많은 프로젝트를 병렬적으로 수행합니다.
로그 이벤트, VOC 등 운영 업무를 포함해, 1년에 여러 개의 섹션을 만들어 이력서를 작성하는 경우를 종종 볼 수 있습니다.

사실, 개발자에게 일반적인 기능 추가나 프로젝트는 당연한 일입니다.
따라서 모든 프로젝트를 이력서에 나열할 필요는 없습니다.
내가 자랑할 수 있는 1~2개의 주요 프로젝트를 통해 나의 역량과 깊이를 잘 보여주는 것이 중요합니다.

너무 많은 프로젝트를 나열하면 검토 피로감을 유발할 수 있으므로, 핵심적인 경험만을 강조하는 것이 효과적입니다.

예시 2: 경력 기술과 사내 프로젝트를 분리하여 작성하는 경우

경력 기술과 사내 프로젝트를 다른 섹션으로 분리하여 작성하는 경우가 종종 있습니다.
이럴 경우, 프로젝트를 읽으면서 경력 기술을 확인하기 위해 상단으로 돌아가야 하는 일이 생깁니다.
이러한 방식은 맥락을 이해하기 어렵게 만들고, 검토 경험이 좋지 않을 수 있습니다.

예시 3: 너무 많은 탭을 띄워야 하는 경우

이는 노션이나 웹으로 구현된 이력서에서 자주 발생하는 문제입니다.
지원자는 이력서를 깔끔하게 분리하려는 의도로 많은 부분을 노션 하위 페이지로 구성하는 경우가 많습니다.

하지만 이를 검토하는 입장에서는 이미 수많은 이력서 탭이 열려 있는 상황입니다.
이 때, 다른 탭을 추가하여 구성하면 맥락을 파악하기 어려워 검토 경험이 좋지 않을 수 있습니다.

따라서, 이력서를 작성할 때는 탭을 불필요하게 분리하기보다는 내용을 적은 페이지에서 잘 연결하여 제출하는 것이 더 효율적입니다.

좌|우가 분리된 이력서 탬플릿

1:3 또는 1:4 비율로 좌우가 분리된 이력서를 쉽게 볼 수 있습니다.

예를 들어, 좌측에 개인 신상 정보나 타이틀을 나타내는 방식이 그 예시가 될 수 있습니다.

이 방식은 타이틀을 주요하게 작성해야 하는 전통적인 이력서 스타일에서는 적합할 수 있습니다,
공간을 보다 효율적으로 사용할 수 있기 때문입니다.

하지만 나의 역량을 잘 나타내기 위해서는 줄 글이 필수적으로 발생합니다.
줄 글을 읽을 때 좌측 마진이나 다른 콘텐츠가 존재하면, 가독성과 집중력을 저하시킬 수 있어,
검토 경험이 좋지 않을 수 있습니다.
따라서, 내역을 간결하고 효과적으로 전달할 수 있는 레이아웃을 사용하는 것이 중요합니다.

이력서와 포트폴리오의 불편한 관계

이력서와 포트폴리오의 목적이 불분명한 경우가 종종 있습니다.
이로 인해, 이력서에서 내용은 비슷하지만 글이 더 추가되거나 이미지가 포함된 경우를 많이 보게 됩니다.

하지만 이런 방식은 큰 임팩트를 주지 못하며, 비슷한 내용의 반복으로 인해 검토관의 피로감을 유발할 수 있습니다.

따라서, 이력서에는 프로젝트를 최대한 깊이 있게 설명하고, 부족한 부분은 블로그의 프로젝트 회고록, 트러블 슈팅, 레슨런, GitHub README 등으로 링크를 걸어 추가적인 설명을 제공하는 것을 권장합니다.
이렇게 하면, 검토관이 더 많은 정보를 효율적으로 확인할 수 있게 됩니다.

노션 이력서

여전히 많은 분들이 URL 형태의 이력서를 사용하고 있습니다.
하지만 노션 이력서는 아래와 같은 문제들이 발생할 수 있기 때문에 권장하지 않습니다.

퍼미션이 없거나 실수로 Public 링크가 수정된 경우, 링크가 유실되는 일이 생각보다 자주 발생할 수 있습니다.
(이럴 경우 이력서를 제대로 볼 수 없게 되어 탈락할 가능성이 높습니다.)

PDF 제출을 요구하는 경우가 많은데, 노션은 Export 시점에 레이아웃이 깨지는 경우가 자주 발생합니다.
(이 문제를 해결하려면 수동으로 보정해야 하므로, 이는 다소 번거로울 수 있습니다.)

마무리

오늘은 기존에 이력서를 검토하면서 불편하거나 아쉬운 부분들을 나열해 보았습니다.

조만간 위에서 언급한 불편하거나 아쉬운 부분들이 개선된 왓에버가 제안하는 이력서 템플릿을 공유드릴 예정입니다.

내용이 도움이 되셨다면 좋아요와 댓글을 남겨주시면, 보다 빠르게 이력서 템플릿을 공개할 수 있도록 하겠습니다.

오늘 이력서를 주제로 왓에버의 탑티어 멘토와 함께 팟캐스트가 진행될 예정입니다.
2월 8일 오후 2시에 많은 참여 부탁드립니다! [디스코드 참여하기]

내 이력서에 대한 탈락사유, 개선 방향을 피드백 받고 싶다면 [업그레이드 된 이력서 멘토링]

리엑트 코어를 직접 구현하고 차별화 된 포트폴리오 쌓기 [리엑트 파헤치기]

레거시를 개선하고 대규모 트래픽을 견딜 수 있는 리얼 백엔드 [레거시 리팩토링]