서론

나는 실제로 지원하는 시간보다 채용 공고를 찾는 데 더 많은 시간을 쓰고 있다는 것을 깨달았다.

매일 늦은 오후면 똑같은 일상이 반복되었다. Indeed를 열고, "PHP 개발자"를 입력하고, 거의 동일한 수십 개의 결과를 스크롤하며, 다섯 개나 여섯 개의 공고를 새 탭으로 열고, 직무 기술서(Job Description)를 읽고, 내 이력서와 머릿속으로 비교한 뒤, 대부분의 경우 "내 프로필과 잘 맞지 않는 것 같다"며 지원도 하지 않은 채 탭을 닫아버렸다. 그리고 다음 날, 이 과정을 반복했다.

문제는 채용 공고를 찾는 것이 아니었다. 어떤 공고가 정말 내 시간을 투자할 가치가 있는지 알아내는 것이 문제였다.

이런 사이클 속에서 몇 주를 보낸 후, 나는 다소 당연하지만 아직 진지하게 고려하지 않았던 질문 하나에 도달했다. 만약 AI가 기술 리크루터 (Technical Recruiter) 역할을 할 수 있다면 어떨까? 단순히 일반적인 이력서를 생성해 주는 도구가 아니라, 먼저 나의 기술적 역량을 깊이 이해한 다음, 실제 공고를 찾아 나서고, 그 후에 "이 공고는 가치가 있습니다. 그 이유는 다음과 같습니다"라고 말해주는 사람처럼 말이다.

내가 구축한 흐름이 바로 이것이었다. 이 글에서는 이 흐름이 어떻게 탄생했는지, 그것이 나의 실제 이력서로 무엇을 수행했는지, 그리고 최종 결과물인 스코어(Score), 근거, 추천 사항이 포함된 순위 지정 스프레드시트가 왜 나의 구직 방식을 완전히 바꾸어 놓았는지에 대해 이야기하고자 한다.

문제점

수동으로 채용 공고를 찾는 것에는 아무도 알려주지 않는 함정이 있다. 생산적인 것처럼 보이지만, 실제로는 생산성 연극에 불과하다는 점이다.

몇 가지 이유는 다음과 같다:

• 필터 없는 물량 공세. "PHP 개발자"와 같은 단순한 검색만으로도 수백 개의 결과가 돌아옵니다. 하지만 대부분은 저와는 다른 PHP 프로필을 요구합니다. 다른 프레임워크, 다른 프로젝트 규모, 다른 시니어리티(Seniority)를 말이죠.
• 낮은 적합도와 보이지 않는 격차. 채용 공고 전체를 다 읽고 나서야 해당 직무가 자신과 맞는지 알 수 있습니다. 그마저도 "짐작"에 기반한 평가일 뿐입니다.
• 블랙박스 같은 ATS. 자동 채용 관리 시스템 (ATS, Applicant Tracking Systems)은 후보자가 필요한 경험을 갖추고 있음에도 불구하고, 적절한 키워드가 포함되어 있지 않다는 이유로 이력서를 탈락시킵니다. 예를 들어, "CodeIgniter"를 요구하는 PHP 채용 공고는 이력서에 "PHP MVC"라고만 기재한 후보자를, 경험이 동등함에도 불구하고 필터링 단계에서 탈락시킵니다.
• 반복적인 지원. 핀테크, 이커머스, AI 자동화 등 맥락이 전혀 다른 PHP 직무들에 동일한 범용 이력서를 보내는 것은 비효율적이며, 더 나아가 채용 담당자에게 적합성이 떨어진다는 신호를 줄 수 있습니다.
• 기회비용. 부적절한 공고를 읽으며 보내는 매 시간은 공부하거나, 면접 연습을 하거나, 포트폴리오 프로젝트를 다듬는 데 사용할 수 있었던 시간입니다. 저의 경우, 제 PHP 프로필이 "기성품"이 아니었기에 이 문제는 더욱 명확했습니다. 저는 약 2년의 정식 개발 경험이 있지만, 그전에도 2년 이상의 IT 지원 및 인프라 경험이 있습니다. 저의 일상은 MVC 아키텍처 기반의 PHP 8과 프론트엔드의 React/Next.js, 그리고 PHP 주니어 공고에서는 흔치 않은 응용 AI 계층(RAG, LLMs)이 결합된 형태입니다. 얕은 키워드 필터링으로는 이러한 조합을 잡아낼 수 없었습니다. 저는 아무 PHP 직무에나 지원하고 싶었던 것이 아니라, 이 모든 역량을 진정으로 활용할 수 있는 곳에 지원하고 싶었습니다.

저는 이러한 경험의 집합을 전체적으로 바라보고, 이를 시장에서 실제로 요구하는 사항들과 공고 하나하나 대조해 볼 수 있는 누군가 — 혹은 무언가 — 가 필요했습니다.

아이디어

제가 설계한 흐름은 종이 위에서는 매우 단순한 논리를 가지고 있지만, 실전에서는 모든 것을 바꿔 놓습니다. 즉, AI는 제가 기술적으로 누구인지 깊이 이해한 후에야 비로소 채용 공고를 검색할 수 있다는 점입니다.

이력서 (Currículo)
  ↓
프로필 분석 (Profile Analysis) (시니어리티, 스택, 강점, 공백)
...

각 단계는 특정 문제를 해결합니다:

• 이력서 → 프로필 분석. 어떤 검색을 수행하기 전에, AI는 후보자를 깊이 있게 "알아야" 합니다. 단순히 기술 목록을 나열하는 것이 아니라, 시니어리티 (seniority) 수준, 주요 프로젝트, 그리고 이력서의 각 진술을 뒷받침하는 경험의 유형을 이해해야 합니다.
• 공백 탐지 (Gap Detection). 모든 좋은 채용 공고는 또한 공백(gap)을 드러냅니다. 이를 미리 알고 있으면 면접에서 당황하는 것을 방지할 수 있으며, 숙련된 척하는 대신 정직한 답변을 준비하는 데 도움이 됩니다.
• Indeed 검색. 이러한 컨텍스트가 준비된 후에야 AI는 실제적이고, 최신이며, 완전한 정보(회사, 위치, 근무 형태, 스택, 링크)를 갖춘 채용 공고를 검색하러 나갑니다.
• 적합도 점수 (Adherence Score). 각 채용 공고에는 근거가 있는 점수가 부여됩니다. 단순한 이진법적 "예/아니오"가 아니라, 왜 해당 점수가 나왔는지에 대한 명시적인 추론이 포함됩니다.
• 이력서 최적화 (Resume Optimization). 가장 높은 순위를 받은 공고들에 대해, AI는 어떤 프로젝트를 강조할지, 어떤 키워드를 사용할지, 그리고 이력서를 어떻게 재구성할지를 제안합니다.
• 지원 (Application). 인간의 단계입니다. AI가 자료를 준비하지만, 버튼을 누르고 면접에 임하는 것은 바로 저입니다.

프롬프트 (Prompt)

프롬프트 전체를 여기에 붙여넣지는 않겠습니다. 내용이 너무 길고 복사해서 붙여넣기에는 지나치게 구체적이기 때문입니다. 하지만 가장 중요한 부분들의 이면에 담긴 논리를 설명할 가치는 있습니다.

첫째, AI가 제가 누구인지 이해하도록 강제했습니다

어떤 채용 공고를 찾기 전에, 프롬프트의 첫 번째 블록은 다음과 같은 사항들을 포함하여 제 이력서에 대한 구조화된 분석을 요청했습니다:

첨부된 이력서를 분석하여 다음을 반환하세요:
- 적절한 시니어리티 (Seniority) (근거 포함)
- 주요 기술 (frontend, backend, data, devops, AI로 구분)
...

이것을 가장 먼저 요청하는 이유는 간단합니다. 만약 AI가 제가 두 가지 서로 다른 백엔드 (backend) 경험을 가지고 있다는 사실이나, 저의 핀테크 (fintech) 프로젝트(Quita)가 멀티 테넌트 (multi-tenant) 아키텍처 및 LGPD 준수 능력을 증명한다는 사실을 모른다면, 단순히 키워드가 일치하는지 여부만 확인하며 각 채용 공고를 피상적으로 평가할 것이기 때문입니다.

그 다음, 이 분석 내용을 검색 기준으로 변환했습니다

프롬프트의 두 번째 부분은 이미 분석된 이 프로필을 채용 공고 검색을 위한 필터로 사용하며, 어떤 유형의 공고를 가져올지에 대한 명시적인 지침을 포함했습니다:

분석된 프로필을 바탕으로, Indeed에서 다음 조건을 충족하는 PHP 개발자(Desenvolvedor PHP)의 최신 채용 공고를 검색하세요:
- 식별된 시니어리티 (Seniority) 레벨과 호환될 것
- PHP를 핵심 언어로 요구할 것 (MVC, CodeIgniter, Laravel 또는 그에 상응하는 기술)
...

마지막으로, 단순한 점수가 아닌 근거를 요청했습니다

최종 결과에서 가장 큰 차이를 만든 부분은 AI가 단순히 숫자만 내뱉는 것이 아니라, 각 점수에 대해 근거를 제시하도록 강제한 것이었습니다:

각 채용 공고에 대해 0~100% 사이의 적합도 점수 (score)를 계산하고 다음을 설명하세요:
- 왜 다른 점수가 아닌 이 점수인지
- 후보자가 해당 공고의 어떤 기술을 이미 보유하고 있는지
...

이 디테일이 모든 것을 바꿉니다. 설명이 없는 점수는 맹목적으로 믿어야 하는 숫자에 불과하지만, 근거가 있는 점수는 의사결정 도구가 됩니다.

결과

첫 번째 단계의 결과는 솔직히 제가 기대했던 것보다 더 많은 것을 보여주었습니다.

AI는 저의 시니어리티 (Seniority)를 "주니어 상급 / 미들(Pleno) 전환 단계"로 분류했습니다. 이는 개발 분야에서의 공식적인 경력 기간과 더불어, 이전의 서포트 및 인프라 (infrastructure) 경험을 결합하여 도출한 근거였는데, 이는 저 스스로도 인터뷰에서 말로 표현하기 어려워했던 논리였습니다.

그 빈틈에 대해 그녀는 직설적이었습니다. Kubernetes에 대한 문서화된 노출이 적고, 이벤트 기반 아키텍처 (event-driven architecture; Lambda, SQS/SNS), 대규모 자동화 테스트 (automated testing), 그리고 관측성 (observability) 도구에 대한 경험이 부족하며, 공식적인 클라우드 자격증도 없다는 점이었습니다. 제가 의심했던 것과 다르지 않았지만, 이를 명확하게 글로 확인하니 "이것저것 조금씩" 공부하는 대신 다음에 무엇을 우선적으로 공부해야 할지 결정하는 데 도움이 되었습니다.

채용 공고를 찾는 과정에서 결과물은 직함, 회사, 위치, 근무 형태, 요구 기술, 적합도 점수 (score), 근거, 공식 링크 및 지원 권장 사항을 포함한 스프레드시트로 도출되었습니다. PHP를 핵심 언어로 요구하는 공고들을 필터링한 결과, 순위는 다음과 같았습니다:

Advisorh의 공고가 1위를 차지한 이유는 서류상으로 "가장 인상적"이었기 때문이 아니라, 제 이력서와 요구 사항 사이의 실제 마찰(friction)이 가장 적었기 때문입니다. 해당 공고는 제가 일상적으로 수행하고 있는 두 가지 영역(PHP 및 React/TypeScript)을 명시적으로 수용하며, 최소 경력 연수를 엄격하게 요구하지 않았습니다.

가장 눈에 띄었던 점은 근거(justification)의 상세 수준이었습니다. Why Digital의 공고에서 분석 결과는 직무 설명에 "차량 추적(vehicle tracking)"이 언급되어 있음을 포착했고, 제가 이전에 유사한 지원을 위해 준비했던 논리를 재사용할 것을 제안했습니다. 수십 개의 탭을 열어놓고 작업하는 와중에 저 혼자였다면 절대 떠올리지 못했을 부분입니다. SOM VIBE의 공고에서는, 결과적으로 PHP 공고임에도 불구하고 AI가 저의 RAG 에이전트 프로젝트(POPS_AI)를 해당 공고의 "응용 AI(applied AI)" 요구 사항과 직접 연결해 주었습니다.

이는 수동으로 채용 공고를 찾는 것보다 훨씬 낫습니다. "이 공고가 나에게 좋을 것 같다"라는 편향을 제거하고, "이러한 구체적인 이유들 때문에 이 공고가 당신에게 적합하며, 이에 대해 다음과 같이 행동하라"는 식으로 대체해주기 때문입니다.

2단계

순위가 정해진 후, 저는 다시 AI를 사용했습니다. 다만 이번에는 가장 잘 위치한 각 PHP 채용 공고에 맞춰 개인화된 이력서를 생성하기 위해서였습니다.

이유는 간단합니다. 단 하나의 목표인 'PHP 채용 공고' 안에서도, 모든 기회에 동일하게 적용되는 단일 이력서는 효과적이지 않기 때문입니다. 저의 PHP 경험은 매우 다른 맥락에서 나타납니다:

• 순수 PHP, SaaS 제품 유지보수 중심 — Advisorh 사례처럼, React/TypeScript 또는 이미 운영 중인 제품의 PHP를 요구하는 경우.
• 통합 및 레거시 시스템이 포함된 PHP — Why Digital 사례처럼, REST/SOAP API와 차량 추적 프로젝트가 있는 경우.
• 자동화 및 적용된 AI가 결합된 PHP — SOM VIBE 사례처럼, PHP가 n8n과 AI 통합의 주역으로 함께 등장하는 경우. Advisorh 공고를 위해 생성된 이력서는 South Ti에서의 PHP 8 (MVC) 활동과 React/TypeScript 활동을 동시에 열어두었고, REST API 통합을 통해 완전한 풀스택(fullstack) 숙련도를 입증했습니다. Why Digital의 경우 강조점이 달랐습니다. PHP 8, 시스템 통합, 그리고 프론트엔드에 대한 강조를 줄이고 차량 추적에 대한 준비된 논리를 제시했습니다. SOM VIBE의 경우, 이력서 상단에 POPS_AI와 Quita의 Gemini/OpenAI 통합을 배치했는데, 이는 '적용된 AI'가 공고의 명시적인 요구사항이었기 때문입니다. 비록 그 직무 자체가 본질적으로 PHP 관련 공고였더라도 말이죠.

각 버전은 동일한 사실(사실을 꾸며내지 않았습니다)을 유지했지만, 강조점을 재배열하고 각 불렛 포인트를 시작하는 기술 용어를 바꾸었으며, 적절한 맥락에 맞는 올바른 프로젝트를 우선시했습니다. 이 작업은 수동으로 세네 개의 다른 공고에 맞춰 진행할 경우 오후 시간을 통째로 소모합니다. 자동화했기 때문에 몇 분 만에 끝났고, 가장 중요한 것은: 각 변경 사항이 왜 이루어졌는지 명확한 근거가 있다는 점입니다.

배운 교훈

이 과정을 몇 번 반복한 후, 몇 가지 사실들이 분명해졌습니다.

첫 번째는 AI가 인간 리크루터(Recruiter)를 대체하는 것이 아니라, 당신이 진정으로 준비하는 데 사용해야 할 시간을 빼앗는 반복적인 작업을 제거해 준다는 점입니다. 100개의 채용 공고를 읽고, 각각을 자신의 프로필과 비교하고, 적합성을 머릿속으로 계산하는 것—이것은 기계적인 작업이지 인간의 판단이 아닙니다.

두 번째는 AI가 의사 결정(Decision making)을 도와주지만, 당신을 대신해 결정해주지는 않는다는 점입니다. Advisorh 채용 공고의 90% 점수는 훌륭한 시작점이었지만, 지원 여부, 인터뷰에서의 포지셔닝 방식, 그리고 제안(Offer) 협상은 여전히 나의 몫입니다.

세 번째, 그리고 아마도 가장 중요한 점은 인터뷰는 여전히 인간적이라는 것입니다. 어떤 AI도 면접관이 반대편에서 당신이 왜 특정 아키텍처(Architecture) 결정을 내렸는지 질문하며 압박을 가하는 상황(대면 또는 화상 통화)을 시뮬레이션할 수는 없습니다. 이 워크플로우(Workflow)가 하는 역할은 당신이 50군데에 이력서를 던져서 얻은 통계적 운 덕분에 인터뷰에 가는 것이 아니라, 해당 공고가 당신과 정말 잘 맞기 때문에—즉, 올바른 이유를 가지고—그 인터뷰에 도달하도록 보장하는 것입니다.

또한 더 실무적인 교훈도 기록할 가치가 있습니다. 결과물의 품질은 초기 분석의 품질에 직접적으로 달려 있습니다. 만약 "후보자 파악" 단계가 얕다면, 검색, 점수 산정, 이력서 작성 등 워크플로우의 나머지 모든 단계가 그 얕음을 물려받게 됩니다. 이것이 프롬프트(Prompt)의 첫 번째 단계에 다른 모든 단계를 합친 것만큼이나 많은 주의를 기울였던 이유입니다.

결론

AI가 나에게 일자리를 찾아준 것이 아닙니다. AI는 올바른 기회들을 찾아준 것입니다.

인터뷰에 참여하고, 협상하고, 제안을 수락할지 말지를 결정하는 것은 여전히 나 자신입니다. 하지만 일반적인 검색 결과 페이지를 스크롤하며 허비하던 시간은 이제 분석 결과가 지적한 바로 그 격차(Gap)를 공부하는 데 사용되며, 각 인터뷰에 임할 때 왜 이 공고가 나에게 의미가 있는지, 그리고 왜 내가 이 공고에 적합한지를 정확히 알고 임할 수 있게 되었습니다.