요약 (TL;DR): 나는 수천 개의 소프트웨어 엔지니어링 (Software Engineering) 채용 공고를 분석했고, 대부분의 이력서 조언이 잘못된 문제에 집중하고 있다는 것을 깨달았다. 문제는 보통 ATS (Applicant Tracking System) 소프트웨어가 아니라, 관련성 (Relevance)이다.

몇 달 전, 나는 소프트웨어 엔지니어링 직무에 지원하고 있었다.

대부분의 개발자들과 마찬가지로, 나 역시 이력서를 다듬는 데 수 시간을 보냈다. 그곳에는 수치화된 성과, 현대적인 포맷, 프로젝트 링크, 그리고 지난 몇 년간 내가 다루었던 모든 기술이 담겨 있었다.

나는 내 이력서가 탄탄하다고 생각했다.

하지만 결과는 달랐다.

계속해서 지원했다.

거절.

무응답 (Ghosting).

가끔 있는 면접.

그리고 다시 무응답.

처음에는 시장 탓을 했다.

그다음에는 리크루터 (Recruiters) 탓을 했다.

그다음에는 ATS 소프트웨어 탓을 했다.

결국 나는 스스로에게 다른 질문을 던졌다:

내 이력서가 나쁜 게 아니라면 어떨까? 단순히 각 직무와 관련성이 없는 것이라면 어떨까?

그 질문이 모든 것을 바꾸어 놓았다.

개발자는 모든 것을 측정한다—이력서를 제외하고

엔지니어로서 우리는 거의 모든 것을 측정한다.

• 느린 API를 프로파일링 (Profiling) 한다.
• 데이터베이스 (Database) 벤치마크를 수행한다.
• Docker 이미지를 최적화 (Optimize) 한다.
• 운영 환경의 지연 시간 (Latency)을 모니터링 (Monitor) 한다.

하지만 이력서에 관해서라면?

우리 대부분은 몇 년 전에 작성된 블로그 포스트의 일반적인 조언을 따른다.

• 한 페이지로 유지할 것.
• 행동 동사 (Action verbs)를 사용할 것.
• 키워드 (Keywords)를 추가할 것.
• ATS 친화적으로 만들 것.

이것들 중 나쁜 조언은 없다.

단지 불완전할 뿐이다.

어떤 키워드가 중요한지, 그것들이 왜 중요한지, 혹은 그것들이 합격 확률에 얼마나 영향을 미치는지에 대해서는 아무도 설명해주지 않는다.

그래서 나는 추측하는 것을 그만두기로 했다.

이력서를 데이터 문제로 전환하기

커리어 블로그를 읽는 대신, 나는 소프트웨어 엔지니어링 채용 공고를 수집하기 시작했다.

백엔드 (Backend).

프론트엔드 (Frontend).

DevOps.

AI.

풀스택 (Full-stack).

스타트업 (Startups).

엔터프라이즈 기업 (Enterprise companies).

결국 나는 2,000개 이상의 채용 공고가 포함된 데이터셋을 갖게 되었다.

그 후 나는 다음과 같은 정보를 추출하는 파서 (Parser)를 구축했다:

• 필수 기술 (Required technologies)
• 우대 사항 (Preferred skills)
• 경력 수준 (Seniority)
• 주요 업무 (Responsibilities)
• 빈번하게 반복되는 키워드 (Frequently repeated keywords)
• 기술 간의 관계 (Relationships between technologies)

모든 데이터가 정규화(Normalized)되자, 흥미로운 패턴들이 나타나기 시작했다.

가장 큰 놀라움

모두가 ATS (Applicant Tracking System, 지원자 관리 시스템) 최적화에 대해 이야기한다.

하지만 데이터를 분석한 후, 나는 다른 결론에 도달했다.

가장 큰 문제는 형식이 아니었다.

그것은 바로 관련성 (Relevance) 이었다.

다음 기술들을 사용하는 백엔드 엔지니어를 채용하는 회사를 상상해 보자:

• NestJS
• PostgreSQL
• Docker
• AWS

이제 다음 내용으로 페이지 절반을 채운 이력서를 받는 상황을 상상해 보자:

• React 애니메이션
• Tailwind CSS
• Figma
• 모바일 개발 (Mobile development)

이러한 기술들이 나쁜 것은 아니다.

단지 이 회사가 찾고 있는 것이 아닐 뿐이다.

가장 강력한 이력서들은 키워드 스팸처럼 보이지 않으면서도, 자연스럽게 채용 공고 (Job description)의 언어와 우선순위를 반영하고 있었다.

키워드가 많다고 해서 자동으로 도움이 되지는 않는다

또 다른 흥미로운 패턴은 키워드 채우기 (Keyword stuffing)였다.

많은 이력서들이 ATS 소프트웨어가 자신들을 더 높게 순위 매기기를 바라며 기술 명칭을 여러 번 반복했다.

예를 들면 다음과 같다:

React • React.js • React Developer • React Framework

현대의 채용 시스템은 점점 더 의미론적 (Semantic)으로 변하고 있다.

검색 엔진과 마찬가지로, 단순히 반복되는 단어의 수를 세는 것이 아니라 문맥 (Context)을 이해하는 능력이 향상되고 있다.

기술을 어디서 어떻게 사용했는지 보여주는 것이 기술 명칭을 여러 번 반복하는 것보다 훨씬 더 가치 있다.

기업은 기술 목록이 아니라 결과물을 채용한다

이것은 내가 얻은 깨달음 중 가장 마음에 드는 부분이었다.

많은 이력서들이 다음과 같이 보인다:

JavaScript
TypeScript
React
...

이를 다음과 비교해 보자:

• 배포 시간을 60% 단축함.
• 하루 100,000건 이상의 요청을 처리하는 API를 구축함.
• CI/CD 파이프라인을 자동화함.
• 애플리케이션 성능을 40% 개선함.

두 지원자 모두 정확히 동일한 기술을 알고 있을 수 있습니다.

하지만 단 한 명만이 임팩트 (Impact)를 증명합니다.

채용 담당자 (Recruiters)는 프레임워크를 나열할 줄 아는 사람이 아니라, 문제를 해결하는 사람을 채용합니다.

내가 Talorr AI를 만든 이유

원래 이 분석은 저 자신을 위한 것이었습니다.

저는 다음과 같은 질문에 답할 수 있는 도구를 원했습니다:

• 내가 놓치고 있는 중요한 기술은 무엇인가?
• 내 이력서의 어떤 부분이 이 역할과 일치하지 않는가?
• 실제로 중요한 키워드는 무엇인가?
• 내 경력이 이 직무와 얼마나 밀접하게 일치하는가?

그것이 결국 Talorr AI가 되었습니다.

단순히 AI로 이력서를 다시 쓰는 대신, 이 도구는 당신의 이력서를 특정 직무 기술서 (Job Description)와 비교하여, 누락된 기술을 식별하고, 취약한 부분을 강조하며, 그것이 왜 중요한지 설명하고, 원한다면 그에 맞춘 ATS (Applicant Tracking System) 친화적인 버전을 생성해 줍니다.

목표는 모든 이력서를 똑같아 보이게 만드는 것이 아닙니다.

모든 이력서를 더 관련성 있게 (Relevant) 만드는 것입니다.

여러분의 생각은 어떠신가요?

다른 개발자들은 구직 활동에 어떻게 접근하는지 궁금합니다.

• 지원할 때마다 이력서를 맞춤화하시나요?
• AI 도구에 의존하시나요?
• 이력서를 맞춤화한 후 더 나은 결과를 얻은 적이 있나요?

여러분의 경험을 진심으로 듣고 싶습니다.

이 실험을 통해 탄생한 도구를 확인하고 싶다면, **https://talorr.com/blog/how-to-tailor-resume-to-job-description**에서 확인하실 수 있습니다.

특히 채용 담당자 (Recruiters)와 채용 매니저 (Hiring Managers)분들의 피드백에 관심이 많습니다. 수천 개의 직무 기술서를 분석하며 발견한 패턴과 여러분의 실제 경험을 비교해 보고 싶습니다.