지원자 관리 시스템(ATS)에 이력서를 업로드한 후, 왜 사람이 한 번도 내 이력서를 보지 못했는지 의문을 품어본 적이 있다면, 여러분은 이미 AI 채용의 '블랙박스 문제'를 이해하고 있는 것입니다. 대부분의 이력서 점수 산정 도구는 SaaS 대시보드와 정중한 거절 이메일 뒤에 그 논리를 숨깁니다. HackerRank는 다른 길을 택했습니다. 이들의 Hiring Agent는 오픈 소스입니다. 즉, 누구나 이를 열어보고 코드를 추적하며, LLM이 어떻게 PDF와 GitHub 링크를 하나의 숫자로 변환하는지 정확히 확인할 수 있다는 뜻입니다. 한 개발자가 바로 그 작업을 수행했습니다. 그들이 발견한 것은 세련된 채용 프레임워크가 아니었습니다. 그것은 자동화가 얼마나 쉽게 개인의 의견을 공식화하는지를 보여주는 거울이었습니다.

내부 구조

파이프라인은 기만적일 정도로 단순합니다. 지원자의 PDF 이력서는 Markdown으로 변환된 다음, 경력, 기술, 학력, 사이드 프로젝트 필드를 가진 엄격한 JSON 구조로 파싱됩니다. Python 스크립트가 데이터를 다음 단계로 전달하지만, 실제 '사고'는 프롬프트 체인 내부에서 일어납니다. 각 섹션은 고유한 프롬프트를 가집니다. LLM은 구조화된 데이터를 읽고, 평이한 영어로 작성된 채점 규칙을 적용하여 점수를 반환합니다.

이 아키텍처는 매우 중요합니다. 핵심적인 작업은 영리한 알고리즘이나 학습 루프에서 일어나는 것이 아닙니다. 프롬프트의 문구에서 일어납니다. 지침 세트에서 형용사 몇 개만 바꿔도, 동일한 엔지니어가 '강력 추천 채용 대상'에서 '부적합 후보자'로 변할 수 있습니다. 이는 도구를 취약하게 만들지만, 동시에 정직하게 만듭니다. 대부분의 AI 채용 업체는 프롬프트를 절대 공개하지 않을 것입니다. HackerRank의 프로토타입은 이력서 점수 산정이 항상 코드가 아닌 채점 기준(rubric)에 관한 것이었다는 진실을 드러냅니다.

35퍼센트의 폭거

가장 눈에 띄는 편향은 채점 기준에 숨어 있습니다. 오픈 소스 기여도가 전체 점수의 35%를 차지합니다. 이는 엄청난 비중입니다. 이해를 돕기 위해 설명하자면, 지원자의 전체 경력, 학력 및 기술 세트가 나머지 65%를 두고 단 하나의 부수적인 코딩 활동 조각과 경쟁해야 한다는 뜻입니다.

규칙은 가중치가 시사하는 것보다 훨씬 더 엄격합니다. 개인 GitHub 저장소는 인정되지 않습니다. 자신이 만든 라이브러리가 아무리 유용하더라도 점수는 0점입니다. 이 도구는 오직 타인의 프로젝트에 기여한 경우에만 보상합니다. 점수를 얻으려면 지원자가 다른 사람의 코드베이스에 커미터(committer)여야 합니다.

이러한 선호도는 실제 인구통계학적 무게를 가집니다. 자신만의 도구를 유지 관리하는 엔지니어들은 종종 다른 누구도 해결하지 못한 문제를 해결했기 때문에 그렇게 합니다. 또한 외부 기여를 금지하는 직업을 가졌거나, 대규모 오픈 소스 커뮤니티가 적은 지역에서 일하거나, 혹은 퇴근 후 무급 코딩을 불가능하게 만드는 가족적 책임이 있을 수도 있습니다. 프롬프트를 이런 식으로 작성함으로써, 이 도구는 순수한 엔지니어링 능력을 측정하는 것이 아니라 특정 코딩 문화에 대한 참여도를 측정하고, 이를 객관성이라고 부릅니다.

지침이 제대로 전달되지 않을 때

채점 기준은 스타트업 경험에도 보상을 주려고 시도합니다. 프롬프트는 창업자나 초기 단계 엔지니어에게 추가 점수를 주라고 명시적으로 제안합니다. 이론적으로는 합리적으로 들립니다. 스타트업 베테랑들은 종종 여러 역할을 수행하며 압박 속에서 결과물을 만들어내기 때문입니다. 그래서 테스트를 위해 한 실험이 있었습니다. 하나의 이력서를 가져와 가장 최근의 직함만 변경한 뒤, 세 가지 다른 라벨인 Senior Java Engineer, Founding Engineer, Co-founder / CTO로 에이전트를 세 번 실행해 보았습니다.

점수는 거의 변하지 않았습니다. LLM은 기본적으로 지침을 무시했습니다.

이것은 전체 감사 과정에서 얻은 가장 중요한 발견 중 하나입니다. 이는 프롬프트 규칙이 단지 '제안'일 뿐이라는 것을 증명합니다. 대규모 언어 모델은 무엇이 품질을 나타내는지에 대한 고유하고 완고한 편향을 포함하는 방대한 텍스트 코퍼스로 학습됩니다. 만약 모델의 학습 데이터가 'founding engineer'라는 문구보다 특정 직함, 회사 이름 또는 키워드와 명성을 연관시킨다면, 정성스럽게 작성한 지침은 단순히 튕겨 나갈 뿐입니다. 프롬프트는 모델에게 스타트업 직함을 중요하게 여기라고 지시하지만, 모델은 자신만의 생각을 가지고 있으며 결국 모델의 판단이 우선합니다. 출력값이 채용 점수일 때, 인간의 의도와 기계의 행동 사이의 이러한 간극은 위험합니다.

목적 없는 점수

주요 가중치 외에도, 채점 기준은 데이터 기반의 결정이라기보다는 누군가의 심야 브레인스토밍 세션처럼 느껴지는 기묘할 정도로 구체적인 마이크로 규칙들로 가득 차 있습니다.

LinkedIn 프로필은 정확히 1점의 가치를 가집니다. 프로필의 품질도, 추천 수나 경력의 깊이도 아닙니다. 그저 이력서에 URL이 있다는 사실만으로 총점에 1점이 추가됩니다. 반면, Google Summer of Code 참가자는 5점의 가치를 가집니다. 그리고 만약 후보자가 GitHub에서 포크(fork)한 저장소가 있다면, 에이전트는 자체 포크 수가 5개 미만인 포크는 무시합니다.

이 규칙들은 각각 조용한 계수로 위장된 노골적인 가치 판단을 내리고 있습니다. 왜 LinkedIn 존재감이 아예 1점의 가치가 있는 걸까요? 이는 후보자가 분산 시스템을 설계할 수 있다는 신호가 아니라, 소셜 네트워크를 어떻게 채우는지 안다는 신호일 뿐입니다. 왜 GSoC는 LinkedIn 링크보다 5배나 더 높은 가치를 가질까요? 아마도 프롬프트 작성자가 그 프로그램을 존중하기 때문일 것입니다. 그 존중이 이제는 채용 정책이 되었습니다. 그리고 왜 기준을 5개의 포크로 정했을까요? 사용자 10명의 도구라도 매우 중요한 틈새 문제를 해결할 수 있습니다. 이 시스템 아래에서는 그런 도구는 존재하지 않는 것이나 다름없습니다.

이 숫자들은 회귀 분석을 통해 도출된 것이 아닙니다. 개인이 선택한 것입니다. 어떤 이는 오픈 소스 참여가 엔지니어 가치의 3분의 1 이상이라고 결정했습니다. 또 다른 이는 LinkedIn 프로필이 1점의 가치가 있다고 결정했습니다. 이러한 추측을 자동화하면, 그 추측에 소프트웨어라는 권위를 부여하게 됩니다.

모든 프롬프트는 편견이다

이력서 점수 산정 에이전트를 구축할 때 가장 어려운 부분은 PDF를 파싱하거나 API를 호출하는 것이 아닙니다. 무엇이 중요한지 결정하는 것입니다. 점수 산정 프롬프트의 모든 단어는 무엇이 좋은 엔지니어를 만드는지에 대한 가치 판단입니다. 사이드 프로젝트가 본업보다 더 큰 비중을 차지해야 할까요? 공개 코드가 기업의 비공개 업무보다 더 중요해야 할까요? 소셜 미디어 프로필이 아예 중요해야 할까요? 이 질문들에 대한 수학적으로 정답인 답변은 없습니다. 오직 문화적 선호가 있을 뿐입니다.

채용 팀이 이를 수동으로 수행할 때는, 적어도 의견이 다를 수 있고, 조정하고, 배울 수 있는 많은 검토자에게 편향이 분산됩니다. 하지만 LLM이 이를 수행하면, 한 프롬프트 엔지니어의 편향이 대규모로 실행되는 반복 가능한 함수로 굳어집니다. 도구는 주관성을 제거하는 것이 아니라, 그것을 기록할 뿐입니다.

필터가 아닌 거울로 사용하라

HackerRank의 Hiring Agent는 프로토타입으로 이해하는 것이 가장 좋습니다. 이는 초안처럼 느껴지며, 실제로도 그렇습니다. AI 채용 도구가 어떻게 구축되는지에 대한 흥미로운 초기 모습을 보여주지만, 실제 채용 조직이 갖춘 조정, 테스트 및 다양한 입력값은 부족합니다.

채용 기술을 구축하고 있다면 이를 주의 깊게 살펴보십시오. 임의의 규칙이 얼마나 빨리 자동화된 게이트키핑으로 변하는지 보여줍니다. 만약 후보자라면, 이러한 시스템이 신탁(oracle)이 아님을 기억하십시오. 그것들은 자연어로 포장된 스프레드시트일 뿐이며, 프롬프트를 작성한 사람의 가정을 그대로 담고 있습니다.

이러한 도구들이 판단 대상인 엔지니어들만큼이나 엄격하게 편향 테스트를 거치기 전까지는, 인간의 대화를 대체하는 것이 아니라 대화에 참고 자료로 활용되어야 합니다.