열심히 공부하는 당신이 서류조차 못 넘는 이유

오늘도 퇴근하고 지친 몸으로 다시 모니터 앞에 앉았습니다. 하루가 다르게 쏟아지는 새로운 기술 사이에서 도태되지 않으려고 유명한 강의를 결제하고 주말까지 반납해 가며 스터디에 참여합니다. 이력서에 한 줄이라도 더 쓰고자 여러 활동을 기웃거리고 기술 블로그까지 운영하는 등 남들이 하는 건 다 해봅니다.

하지만 정작 가고 싶은 회사의 서류 전형 결과는 또다시 ‘불합격’입니다. “귀하의 뛰어난 역량에도 불구하고…”로 시작하는 차가운 메시지를 볼 때마다 억울함과 막막함이 밀려옵니다. ‘여기서 더 노력해야 하는 건가?’, ‘더 어려운 기술을 공부해야 하나?’라는 자책이 꼬리에 꼬리를 물고 이어집니다.

최근 진행한 멘토링에서 이런 고민들을 마주했습니다. 한 멘티는 AI 시대를 맞아 신입과 주니어의 자리가 점점 좁아지는 현실을 불안해하며, 자신의 경력이 보잘것없게 느껴진다고 이야기했습니다. 10~20군데를 지원해도 돌아오는 답은 없고, 어떻게 개선해야 할지조차 모를 단순한 업무만 나열된 이력서가 주는 막막함. 이런 상황은 결코 한 사람만의 이야기가 아닐 겁니다.

하지만 냉정하게 말해보자면, 서류 합격에 실패하는 이유가 성실함이 부족하기 때문만은 아닙니다. 오히려 그동안 쌓아온 다양한 지식이 회사의 가려운 곳에 단 한 번도 닿지 못했기 때문일지도 모릅니다.

많은 사람이 채용을 실력순으로 줄 세우는 오디션처럼 생각하지만, 실제 채용 시장은 비어 있는 자리에 가장 잘 맞는 조각을 찾는 ‘퍼즐 맞추기’에 가깝습니다. 아무리 화려하고 단단한 조각이라도, 회사의 빈틈을 채울 수 있는 모양이어야 합니다.

잠깐 사장의 입장이 되어보자

이 매칭 게임의 원리를 이해하기 위해, 아주 직관적인 비유를 들어보려고 합니다.

고깃집에서 고기 굽는 스킬보다 중요한 것

우리가 ‘고기 맛’에 자부심을 가진 숙성 고깃집 사장님이라고 가정해 봅시다. 입소문이 나고 손님이 몰려들어, 고기를 정성스럽게 구워줄 직원을 한 명 뽑아야 한다고요. 공고를 올리니 세 명의 지원자가 찾아왔습니다.

• 지원자 A: 솔직히 돈 벌려고 왔습니다. 시키는 건 무엇이든 하겠습니다.
• 지원자 B: 고기 굽는 스킬에 자신 있습니다. 이미 유명한 대형 고깃집에서 화려한 기술을 배워왔습니다.
• 지원자 C: 저는 평소 이 집의 숙성 방식이 너무 훌륭하다고 생각했습니다. 제 고기 굽는 실력으로 이 집 고기만의 풍미를 손님들에게 최대로 전달해 보고 싶습니다.

누구를 면접에 부르고 싶으신가요? 아마도 B와 C가 좀 끌릴 겁니다. 물론 당장 화려한 퍼포먼스가 급하다면 B도 좋지만, 그래도 ‘최고의 고기 맛’이라는 정체성을 유지하고 싶어 할수록 C를 선택할 가능성이 더 높아질 겁니다.

실력(B)보다 공감(C)이 매력적인 구조

사장님이 B를 선택하기 주저하는 이유는 그 아래 불안함이 있기 때문입니다. 이는 단순히 그가 고집 센 사람일지 모른다는 의심에 그치지 않습니다. 그의 기술이 우리 가게만의 맥락과 충돌할 때 발생하는 조율 비용에 대한 우려가 더 큽니다.

지원자 B와 온보딩 리스크

훌륭한 기술을 가졌지만, 그 기술은 다른 환경(대형 고깃집)에 최적화되어 있습니다. 사장님 입장에서는 B가 우리 방식에 자연스럽게 녹아들도록 설득하고 조율하는 데 에너지를 써야 할 수도 있습니다. 온보딩 리스크를 안게 된 겁니다. 이처럼 각자 방식이 충돌할 때 이를 바로잡는 과정에서 발생하는 유무형의 비용은 생각보다 큽니다.

지원자 C와 검증된 적합도

이미 가게의 지향점을 동경하며 지원했기 때문에, C는 사장님의 철학을 빠르게 흡수하고 발전시킬 준비된 파트너에 가깝습니다. 가르치는 사람과 배우는 사람의 관점이 일치할 때, 시너지가 가장 크게 일어납니다.

기술은 도구일 뿐, 비즈니스가 목적인 채용

기업의 채용 역시 이 고깃집의 상황과 같습니다. 많은 개발자는 자신의 고기 굽는 스킬(=기술 스택)이 얼마나 화려한지만을 증명하려 애씁니다. 하지만 회사는 그 스킬로 우리 회사의 맛(=비즈니스 가치)을 어떻게 구현할 것인지를 알고 싶어 합니다.

그러니 이력서를 제출하는 행위는 단순히 “내 실력을 사라”는 외침보다 “당신들이 추구하는 가치를 위해 내 기술을 이렇게 쓰겠다”라는 기술 제안서여야 합니다. 실력은 입장권에 불과합니다. 합격을 결정짓는 요소는 결국 회사가 정의한 문제와 나의 해결 관점이 얼마나 맞닿아 있는지, 즉 ‘적합성’에 달려 있습니다.

채용 공고는 ‘요구사항’이 아닌 ‘문제 정의서’

그렇다면 고깃집 사장의 ‘숙성과 맛’이란 철학은 실제 채용 현장에서 어떻게 찾아낼까요? 바로 당신이 무심코 지나쳤던 채용 공고(JD)에 그 철학이 있습니다.

JD의 행간 읽기

많은 개발자가 채용 공고를 볼 때 스크롤을 내려 ‘자격 요건’과 ‘우대 사항’에 적힌 기술 스택 목록을 먼저 훑어봅니다. 하지만 정작 중요한 정보는 공고의 가장 윗부분인 ‘조직 소개’와 ‘업무 내용’에 숨어 있습니다. 대부분의 문서는 처음이나 끝이 가장 중요하며, 채용공고는 특히 상단에 배치된 내용이 그 팀이 지금 가장 해결하고 싶어 하는 ‘아픈 지점’인 경우가 많습니다.

예를 들어, 어떤 회사가 채용 공고 상단에 영상까지 활용해 팀 문화를 설명한다면, 그것은 단순히 멋있어 보이기 위한 연출이 아닙니다. 그만큼 해당 메시지가 팀의 정체성을 유지하는 데 중요하다고 판단했기 때문입니다.

회사가 “실시간 데이터 처리에 진심인 분”을 찾는다고 말한다면, 그들은 지금 쏟아지는 데이터를 제때 화면에 뿌려주지 못해 사용자들의 불만을 듣고 있을 가능성이 큽니다. 이때 내가 해야 할 일은 “나는 리액트를 할 줄 안다”고 강조하는 것이 아닌 “나는 이런 상황을 해결하는 방법을 알고 있다”라고 남기는 것입니다. 바로 이런 행간을 읽어내야 합니다.

로그 대신 해법을 던지는 이력서 전략

행간을 읽었나요? 이제 이력서는 내 과거를 기록한 단순 로그(Log)여서는 안 됩니다. 사람들은 “나는 이런 기술을 써봤고 이런 사람인데, 나를 데려갈 곳 있나요?”라는 공급자 중심 태도로 이력서를 뿌립니다. 특히 대다수의 주니어~미들급 개발자에게 로그만 나열된 이력서는 아무런 의미가 없는 문서일 뿐입니다.

하지만 채용 담당자가 매력을 느끼는 지원자는 다릅니다. 이들은 “당신들이 현재 겪고 있는 그 문제를, 내가 예전에 이런 방식으로 해결해 본 경험이 있으니 도와주겠다”라는 관점으로 접근합니다. 우리에게 이력서는 회사가 현재 겪고 있는 문제를, 내가 어떤 기술과 경험으로 해결할 수 있는지 보여주는 기술 제안서여야 합니다.

효과적인 제안서는 주장 → 근거 → 경험의 순서를 따릅니다. 단순히 프로젝트를 나열하기 전에, “나는 어떤 문제를 해결할 수 있는 개발자인가”라는 정체성을 먼저 주장하세요. 그리고 그 주장을 뒷받침할 수 있는 핵심 역량 키워드를 채용 공고의 요구에 맞춰 선별하고 배치해야 합니다.

채용 담당자는 수많은 이력서를 빠르게 훑어봅니다. 그러니 문서의 윗부분에 회사가 원하는 ‘적합성’이 드러나지 않는다면, 공들여 작성한 상세 경험으로 가지도 못한 채 휴지통에 들어갈 지도 모릅니다. 내 이력서가 매번 거절당하고 있다면, 혹시 ‘나’라는 사람을 설명하는 데만 집중한 나머지 ‘회사의 문제’를 외면하고 있었던 것은 아닌지 돌아볼 필요가 있습니다.

적합성 매칭의 기술

“왜 우리 회사에 지원하셨나요?”라는 질문을 받으면, 흔히 “성장 가능성이 커 보여서”, “기술 스택이 마음에 들어서” 같은 칭찬 위주의 답변을 내놓기 쉽습니다. 하지만 기업이 진짜로 듣고 싶은 답은 회사에 대한 찬사가 아니라 ‘우리 회사의 문제’와 ‘나의 실력’ 사이의 교집합입니다.

적합성 매칭은 단순히 내 기술을 나열하며 일어나지 않습니다. 채용 공고에서 발견한 키워드와 나의 경험 사례를 1:1로 대응시키는 과정에서 비로소 완성됩니다. 이런 세 가지 단계를 써볼 수 있습니다.

1. 기업의 페인 포인트 추출

채용 공고 상단이나 영상에서 반복되는 단어를 찾아 보세요. 만약 “예측할 수 있는 코드의 중요성”이나 “변경에 유연한 아키텍처”를 강조한다면, 그 팀은 현재 코드 복잡도로 인해 유지보수에 어려움을 겪고 있을 가능성이 큽니다.

2. 내 경험을 키워드와 직렬화

만약 공고가 ‘주도적인 인재’를 원한다면, 단순히 코드를 잘 짠 경험만으로는 부족합니다. 대신 “전담 인력이 부재한 환경에서 기술 리딩을 주도해 프로젝트를 완수한 사례”를 전면에 내세워야 합니다. 같은 에러를 수정한 경험이라도, 회사의 관심사에 따라 ‘사용성 개선’이 될 수도 있고 ‘CS 대응 비용 절감’으로 해석될 수도 있습니다.

3. “오직 나만이 이 문제를 풀 수 있다”는 서사

“왜 이 회사여야 하는가”에 대한 답은 결국 “내가 가진 A라는 역량이 당신들이 겪고 있는 B라는 문제를 해결하는 데 가장 적합하기 때문”이라는 논리로 귀결되어야 합니다. 이 연결이 선명할수록, 채용 담당자는 나를 단순한 실력자가 아니라 ‘우리 팀에 꼭 필요한 조각’으로 인식하게 됩니다.

결국 적합성 매칭이란, 기업이 던진 질문(JD)에 대해 나의 과거 경험을 재료로 삼은 가장 적합한 해답, 즉 이력서를 제출하는 기술입니다. 이 매칭의 밀도가 높아질수록 면접 제안이 따라오게 됩니다.

경험을 재해석하자

그렇다면, 이러한 적합성을 최대로 잘 보여주려면 이력서에는 무슨 내용을 어떻게 담아야 할까요?

물경력을 구원해 줄 상황의 힘

‘물경력’이라며 스스로를 자책하는 개발자들의 이력서를 보면 공통적인 특징이 하나 있습니다. 바로 맥락 없이 결과 수치에만 과도하게 집착한다는 점입니다. 예를 들어 “10초 걸리던 로딩 속도를 1초로 줄였다”는 성과는 겉보기에는 인상적입니다. 하지만 이게 전부는 아닙니다. 여기에 상황에 대한 설명이 빠져 있다면, 채용 담당자에게는 그저 알맹이 없는 자랑처럼 비칠 뿐입니다.

왜 이런 결과가 알맹이 없는 자랑으로 보일까요? 수치 그 자체만으로는 나의 엔지니어링 수준을 온전히 설명할 수 없기 때문입니다. 다음의 두 사례를 비교해 보겠습니다.

• 케이스 A: 렌더링 최적화가 전혀 이루어지지 않은 환경에서, 단순히 n초마다 렌더링을 제한하는 라이브러리를 추가해 10초를 1초로 단축
• 케이스 B: 이미 대부분의 최적화가 적용된 복잡한 로직 안에서 미세한 비효율을 발견하고 데이터 구조 자체를 개선해 1초를 0.5초로 단축

단순히 수치 변화의 폭만 보면, 10초를 1초로 만든 A가 더 극적으로 보일 수 있습니다. 그러나 실제 엔지니어링 난이도와 사고의 깊이는 B가 훨씬 높습니다. A는 검색 한 번으로도 해결할 수 있는 ‘일단 동작하게 만드는’ 수준에 가깝습니다. 반면 B는 시스템 구조를 깊이 이해하고 판단해야 나오는 수준의 일입니다.

결국 상황을 포함하지 않은 수치는 자신의 실력을 드러내지 못하며, 우연히 운으로 얻은 결과처럼 보일 위험이 큽니다.

당신을 주니어로 가두는 결과 나열

무엇보다 개발자의 경력이 ‘단순 업무’로 평가절하받는 이유는 스토리가 빠진 결과만 나열되기 때문입니다.

“앱 초기 아키텍처 설계 및 스토어 배포”라는 한 줄은 크게 와닿지 않습니다. 하지만 여기에 “앱 전담 인력이 전무한 환경에서”라는 상황이 더해지는 순간, 이야기는 완전히 달라집니다. 이는 단순한 앱 배포를 기술 리딩과 문제 해결의 과정으로 확장해 주기 때문입니다.

스토어 배포 과정에서 겪었던 수많은 실패와 이를 해결하기 위해 아키텍처를 뒤엎으며 고민했던 시간들, 그리고 그 과정에서 내린 판단들이야말로 내가 ‘물경력’이 아님을 증명하는 진짜 알맹이입니다. 채용 담당자가 보고 싶은 것은 단순한 결과 수치가 아니라 그 결과에 도달하기까지 지나온 상황의 무게입니다.

문제 해결 정의의 확장

우리는 ‘문제 해결’을 지나치게 거창하게 생각하는 경향이 있습니다. 기술적으로 난도가 높은 알고리즘을 푸는 일만이 문제 해결은 아닙니다.

• 비즈니스 문제 해결: 운영팀의 요청에 따라 복잡한 기능을 새로 개발하는 대신, 텍스트 앞에 이모지 하나를 추가해 가독성을 높여 문제를 해결했다면, 이는 최고의 문제 해결 사례입니다. 개발 비용을 거의 들이지 않으면서도 사용자의 목적을 달성했기 때문입니다.
• 구조 문제 해결: 단순히 에러를 수정하는 데서 그치지 않고, 상황에 맞는 안내 메시지를 출력하도록 개선해 CS 대응 시간을 줄였다고 해봅시다. 이 또한 뛰어난 엔지니어링 판단입니다.

이처럼 작아 보이는 시도들도 이력서에는 ‘상황-판단-결과’의 구조로 드러나야 합니다. “무엇을 만들었다”보다는 “어떤 제약 속에서 무슨 맥락으로 문제를 해결했는가”가 중요합니다. 이 관점이 드러날 때, 비로소 나는 단순한 ‘코더’가 아니라 문제를 해결하는 ‘해결사’로 보이게 됩니다.

+ AI 시대의 생존법: 설계와 판단

인공지능(AI)은 개발 현장의 풍경을 완전히 바꾸어 놓았습니다. 이제 단순한 기능 구현이나 템플릿 형태의 코드를 작성하는 일은 AI가 인간보다 훨씬 빠르고 정확하게 수행합니다. 개발자들이 내 자리가 사라지는 건 아닌지 불안해하는 이유도 여기에 있습니다.

하지만 AI는 “초당 1,000명의 트래픽을 견디는 채팅 서버를 설계해달라”는 요청에는 즉각적인 답을 내놓지만, “우리 회사의 현재 예산과 비즈니스 상황에서, 지금 이 채팅 서버 설계가 최선인가?”라는 질문에는 답하지 못합니다. 그렇기 때문에 개발자의 ‘설계’와 ‘판단’ 능력은 그 어느 때보다 중요해졌습니다.

이처럼 진정한 실력은 정답이 정해진 코드를 작성하는 데서 드러나지 않습니다. 오히려 복잡한 맥락 아래 가장 적절한 선택지를 고르는 과정에서 드러납니다.

• 비즈니스 맥락의 이해: 1년 뒤 대형 고객사 유입 계획이나 회사의 자금 상황을 함께 고려해, 과도한 설계를 피하면서도 확장할 수 있는 구조를 선택하는 능력
• 도메인 특화 지식: 특정 산업군(금융, 커머스 등)이 가진 고유한 제약과 사용자 행동 패턴을 이해하고, 이를 기술 설계에 부드럽게 녹여내는 능력

AI가 대체하기 어려운 지점은 바로 이 ‘의사결정’의 영역입니다. 그러니 이력서에서 보여줘야 하는 건 AI도 짤 수 있는 코드가 아니라, 그 코드를 쓰기까지 내렸던 “수많은 판단의 근거”입니다.

채용은 경쟁이 아니라 매칭이다

우리는 지금까지, 열심히 공부하고도 서류 전형에서 고배를 마시는 개발자가 가진 구조적인 문제를 살펴보았습니다. 결국 모든 이야기는 하나의 길로 통합니다. 채용이 누가 더 뛰어난지를 가리는 ‘실력 경쟁’이 아닌 회사의 빈틈을 누가 가장 잘 채울 수 있는지를 확인하는 ‘적합성 매칭’ 게임이라는 점입니다.

이 진실 아래 채용을 준비할 때 반드시 염두해야 할 4가지 핵심을 정리했습니다.

1. 나는 ‘파트너’인가?

지원자들은 흔히 ‘내 경험 중 가장 잘난 것이 무엇인가’를 고민하며 이력서를 채웁니다. 하지만 채용 담당자의 시선은 전혀 다릅니다. 그들은 ‘우리 회사에 가장 잘 맞는 조각이 누구인가’를 찾고 있습니다. 회사가 나에게 맞추길 기대하기보다 내가 회사의 문제에 어떻게 기여할 수 있는지를 먼저 증명해야 합니다.

이력서에 쓰인 수많은 기술 스택보다 중요한 것은, 그 기술로 회사의 비즈니스를 어떻게 성장시킬 수 있는지 보여주는 ‘파트너십 관점’입니다.

2. 나열이 아닌 설득을 하고 있는가?

이력서는 단순히 정보를 나열하는 문서가 아닙니다. 수많은 지원자 사이에서 채용 담당자의 시선을 붙잡아 기준 필터를 통과할 때 쓸 전략적인 도구입니다.

자바스크립트에서 filter 함수를 사용해 원하는 데이터를 골라내듯, 채용 담당자 역시 “우리 회사에 맞는 사람인가”를 기준으로 이력서를 걸러냅니다. 이 필터를 통과하려면 이력서 상단에 강력한 주장이 먼저 배치되어야 합니다. “나는 이런 사람이며, 당신들의 이런 문제를 해결할 수 있다”는 정체성을 분명히 드러내세요. 그 뒤는 이를 입증하는 구체적인 근거와 경험이 자연스럽게 따라와야 합니다.

예를 들어, 주도적인 인재를 원하는 공고라면 단순히 “주도적이다”라고 쓰는 것만으로는 부족합니다. 대신 “인력 부재 상황에서 기술 리딩을 맡아 프로젝트를 완수한 경험”을 전면에 내세워야 합니다. 이러한 구조는 채용 담당자에게 내가 단순한 기술자가 아니라 회사의 미래를 함께 고민할 수 있는 사람이라는 신뢰를 전달합니다.

3. 해석과 이정표로 이뤄내는 성장

‘물경력’이라는 말로 대표되는 경력의 불안함은 사실 경험 그 자체보다 회고가 부족할 때 나옵니다. 프로젝트가 중단되거나 실패했더라도, 왜 그런 결과가 나왔는지를 분석하고 “어떻게 했으면 유지할 수 있었을까”를 고민하는 과정 자체가 실력이 됩니다. 이러한 회고는 블로그나 이력서를 통해 성장 가능성을 어필할 중요한 자산이 됩니다.

또한 개발자로서 방향을 잃지 않기 위해서는 앞으로 나아갈 ‘이정표’도 필요합니다. 당장 10년 뒤의 목표가 거창하지 않아도 괜찮습니다. 지금 시점에서 상상할 수 있는 최선의 방향을 설정하는 것만으로도, 공부의 효율과 이력서의 서사가 크게 달라집니다. 목표는 언제든 바뀔 수 있습니다. 하지만 이정표가 있을 때야말로 내 성실함이 ‘누구나 하는 일’이 아닌 ‘나만이 할 수 있는 전문성’이란 길로 이어집니다.

4. 로그가 아닌 제안서를 쓰세요

본인의 이력서가 여전히 과거만을 기록한 ‘로그(Log)’에 머물러 있지는 않나요? 기업은 여러분의 과거를 사지 않습니다. 문제를 해결하며 함께 도착할 기업의 미래를 삽니다.

이제 지식을 쌓는 데만 머무는 공부를 멈추고 회사가 마주한 문제를 풀기 위한 고민을 시작해 보세요. 관점이 바뀌는 순간, 성실하기만 한 학생을 벗어나 회사가 간절히 원하는 대체 불가능한 ‘파트너’로 나아갈 수 있습니다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.