오늘의 오픈 소스 프로젝트 (#105): hiring-agent — HackerRank가 자신들의 이력서 점수 산정 시스템을 오픈 소스로
요약
HackerRank가 이력서를 분석하여 점수를 산정하는 오픈 소스 파이프라인인 'hiring-agent'를 공개했습니다. LLM을 활용해 PDF 이력서와 GitHub 데이터를 분석하며, 개발자가 자신의 이력서를 채용 시스템 관점에서 검토할 수 있게 돕습니다.
핵심 포인트
- LLM(Ollama, Gemini) 기반의 이력서 평가 파이프라인
- GitHub 기여도 및 개인 프로젝트에 높은 가중치 부여
- 채용 담당자의 관점에서 이력서의 강점과 약점 파악 가능
- PDF 입력부터 구조화된 점수 보고서 출력까지 5단계 프로세스
서론
"HackerRank가 자신들의 내부 채용 파이프라인을 오픈 소스로 공개했습니다. 이는 이제 여러분이 채용 담당자의 점수 산정 시스템을 통해 자신의 이력서를 직접 돌려볼 수 있음을 의미합니다."
이 글은 Open Source Project of the Day 시리즈의 #105번째 기사입니다. 오늘의 프로젝트는 HackerRank/InterviewStreet가 오픈 소스로 공개한 이력서 평가 파이프라인인 hiring-agent입니다.
가장 중요한 점부터 말씀드리겠습니다.
이 도구는 채용 담당자를 위해 구축되었습니다: 후보자 이력서 묶음을 처리하고 설명 가능한 점수 평가를 생성합니다. 개발자들에게는 그 반대 방향으로 가장 가치가 있습니다: 자신의 이력서를 채용 담당자의 점수 산정 기준에 통과시켜 시스템이 자신을 어떻게 생각하는지 확인하는 것입니다.
총점 자체보다는 그로부터 무엇을 배우느냐가 더 중요합니다: 시스템이 어디에서 점수를 깎았는지, 어디에서 점수를 부여했는지, 무엇을 강점으로 간주했는지, 그리고 무엇을 전혀 고려하지 않았는지 말입니다. 그 정보는 자동 스크리닝 시스템(automated screening systems)에 당신의 이력서가 어떻게 보이는지를 직접적으로 알려줍니다.
학습 내용
- 4가지 점수 산정 차원과 가중치 — 왜 GitHub 기여도가 예상보다 더 중요한지
- 5단계 파이프라인: PDF가 점수로 변환되는 과정
- GitHub Enrichment(GitHub 정보 보강) 상세 내용: 어떤 저장소(repositories)가 선택되고 어떤 것이 무시되는지
- 개발자 관점: 이 도구를 사용하여 자신의 이력서를 감사(audit)하는 방법
- -20에서 120 사이의 점수 범위가 의미하는 것
- 로컬 (Ollama) vs 클라우드 (Gemini) 설정 옵션
사전 요구 사항
- 기초적인 Python 지식 (프로젝트를 실행할 수 있는 수준)
- PDF 형식의 이력서
- GitHub 계정 (선택 사항이지만, 계정이 없으면 상당한 점수가 감점됩니다)
프로젝트 배경
hiring-agent란 무엇인가?
hiring-agent는 이력서 평가 파이프라인입니다: PDF 이력서를 입력하면 구조화된 점수 보고서를 출력합니다. 텍스트 이해 및 점수 산정을 위해 LLM (로컬 Ollama 또는 Google Gemini)을 사용하며, 추가적인 신호로서 GitHub 데이터를 가져와 활용합니다.
HackerRank의 명시된 미션은 "학벌보다 기술을 가치 있게 평가하도록 세상을 바꾸는 것"입니다. 이 점수 산정 시스템은 그 원칙을 반영합니다. 가장 높은 가중치가 부여되는 차원은 당신이 실제로 구축한 것(오픈 소스 기여 (open source contributions), 개인 프로젝트 (personal projects), 실무 경험 (production experience))이며, 어느 학교를 졸업했는지가 아닙니다.
저자 / 팀
- 조직 (Organization): HackerRank / InterviewStreet
- 라이선스 (License): MIT
- 언어 (Language): Python (100%)
프로젝트 통계
- ⭐ GitHub Stars: 2,200+
- 🍴 Forks: 599+
- 📄 License: MIT
점수 산정 차원: 규칙을 먼저 이해하세요
이 부분이 가장 중요한 섹션입니다. 시스템은 네 가지 차원에 대해 점수를 부여하며, 여기에 보너스와 감점이 추가됩니다:
기본 점수 (총 100점)
├── open_source (오픈 소스 기여)
├── self_projects (개인 프로젝트)
...
핵심 데이터 포인트: 커뮤니티 논의에 따르면, open_source와 self_projects를 합치면 100점의 기본 점수 중 약 65점을 차지합니다. GitHub 기여와 개인 프로젝트가 전체 가중치의 약 3분의 2를 나타냅니다.
개발자에게 주는 시사점은 명확합니다: 당신의 GitHub 프로필이 빈약하거나 대부분 비공개(private)라면, 이 시스템은 당신의 이력서에 얼마나 많은 기술이 나열되어 있는지와 관계없이 낮은 점수를 부여할 것입니다.
각 차원의 측정 항목
open_source (오픈 소스 기여)
단순히 본인이 생성한 저장소(repository)가 아닌, 외부 오픈 소스 프로젝트에 대한 기여를 의미합니다. 머지된 PR (Merged PRs)과 커밋된 변경 사항 (committed changes)은 포함되지만, 스타(stars)와 포크(forks)는 포함되지 않습니다. 유명한 프로젝트(주요 프레임워크, 인프라 도구 등)에 대한 기여는 잘 알려지지 않은 저장소보다 더 높은 점수를 받습니다.
self_projects (개인 프로젝트)
본인이 직접 구축하고 유지 관리하는 프로젝트입니다. 시스템은 필터링을 거칩니다: 최소 커밋 임계값을 초과하는 저장소만 집계됩니다. 'Hello-World' 수준의 저장소는 자격이 없습니다. 단기간의 활동보다는 수년에 걸쳐 유지 관리된 프로젝트가 더 높은 가중치를 가집니다.
production (실무 경험)
귀하의 경력이 실제 사용자가 사용하는 실제 제품을 포함하고 있는지 여부입니다. 단순히 책임 범위를 설명하는 내용("인증 모듈을 개발함")보다 영향력 데이터가 포함된 설명("일일 활성 사용자(DAU) 5만 명 지원", "일일 요청 수 1,000만 건 처리")이 더 높은 점수를 받습니다. 단순한 작업(task)이 아닌 결과(result)를 보여주어야 합니다.
technical_skills (기술적 역량)
기술적 능력의 깊이와 넓이를 평가합니다. 기술 이름(React, Python, Docker...)만 나열된 목록은 특정 실무(production) 또는 프로젝트 맥락에서 해당 기술을 활용하는 모습을 보여주는 것보다 낮은 점수를 받습니다. 단순히 기술을 알고 있다는 사실이 아니라, 그 기술로 무엇을 해냈는지가 중요합니다.
파이프라인: 5단계
귀하의 PDF 이력서
↓
1단계: PDF → Markdown (PyMuPDF)
...
3단계에 대한 지원자 관점의 설명: 시스템은 이력서에서 귀하의 GitHub 사용자 이름을 추출한 다음, GitHub에서 직접 데이터를 가져옵니다. 이는 다음을 의미합니다:
- 귀하의 GitHub URL이 이력서에 명시적으로 포함되어 있어야 합니다 (그렇지 않으면 시스템이 찾지 못할 수 있습니다).
- 비공개 저장소(Private repositories)는 보이지 않으며 점수가 산정되지 않습니다.
- 의미 있는 수정이 없는 포크(Forked)된 저장소는 낮은 점수를 받습니다.
- 빈 저장소(README만 있는 경우)는 사실상 무시됩니다.
자신의 이력서를 감사(Audit)하는 데 사용하기
설치 및 설정
git clone https://github.com/interviewstreet/hiring-agent
cd hiring-agent
...
옵션 A: Ollama를 이용한 로컬 실행 (API 키 불필요)
# 먼저 Ollama를 설치하세요: https://ollama.ai
ollama pull gemma3:12b # 더 높은 품질, 약 8GB RAM 필요
...
옵션 B: Google Gemini (더 높은 품질, API 키 필요)
# .env 설정
LLM_PROVIDER=gemini
DEFAULT_MODEL=gemini-2.5-pro
...
평가 실행:
python score.py /path/to/your_resume.pdf
API 속도 제한(rate limits)을 피하려면 GitHub 토큰을 추가하세요:
GITHUB_TOKEN=your_github_pat # .env에 추가
출력 결과 읽기
보고서는 단순히 총점만 제공하지 않습니다. 각 차원마다 **근거 설명(evidence explanations)**이 함께 제공됩니다:
=== Evaluation Report ===
open_source: 18/30
...
증거 설명(evidence explanations)은 점수보다 더 가치 있습니다. 이는 다음을 보여줍니다:
- 시스템이 발견한 것: 귀하의 GitHub 프로젝트가 올바르게 식별되었는지 여부
- 시스템이 놓친 것: 이력서에 반영되지 않은 정보
- 점수가 감점된 부분: 어떤 특정 차원(dimension)이 귀하의 점수를 낮추고 있는지
- 보너스 점수를 얻을 수 있는 방법: 어떤 예외적인 신호(signals)가 보너스 점수를 유도하는지
결과를 행동으로 전환하기
차원별 일반적인 개선 패턴:
open_source 점수가 낮은 경우:
- 이력서에 GitHub URL이 없음 → 추가할 것
- GitHub 프로필이 대부분 비공개 저장소(private repositories)임 → 관련 있는 저장소를 공개로 전환하는 것을 고려할 것
- 직접 만든 저장소만 있고 외부 기여(external contributions)가 없음 → 기여할 수 있는 활발한 프로젝트를 찾을 것
self_projects 점수가 낮은 경우:
- 커밋(commit) 횟수가 적은 저장소가 몇 개뿐임 → 프로젝트는 존재하지만 코드가 공개 GitHub에 없거나, 지속적인 유지보수가 부족함
- 프로젝트 설명이 불분명함 → README에 맥락(context)을 추가할 것: 배경, 기술적 결정, 실제 결과물
production 점수가 낮은 경우:
- 업무 설명이 "~를 개발할 책임이 있음"이라고 되어 있음 (대신 "X를 구현하여 Y라는 결과를 냄"이라고 작성) → 결과 중심(outcome-oriented)의 설명으로 다시 작성할 것
- 지표(metrics)가 없음 → 규정 준수 범위 내에서 구체적인 숫자(사용자 수, 요청량, 지연 시간(latency) 개선 등)를 추가할 것
technical_skills 점수가 낮은 경우:
- 기술 목록이 너무 광범위하고 얕음 → 실제 경험의 깊이가 있는 기술 위주로 정리할 것
- 기술이 프로젝트나 경력 사항에 반영되지 않음 → 이력서의 모든 섹션이 일관된 이야기(consistent story)를 전달하도록 할 것
한계점: 권위가 아닌 입력값으로 활용하세요
주의해야 할 몇 가지 사항:
공개 GitHub 편향(Public GitHub bias): 시스템은 공개 저장소(public repositories)만 볼 수 있습니다. 만약 귀하가 비공개 기업 코드베이스에서 중요한 작업을 수행했거나, 규정 준수(compliance)를 이유로 저장소를 비공개로 유지했다면, 귀하의 점수는 체계적으로 낮게 나올 것입니다. 이는 측정상의 한계일 뿐, 귀하의 경험에 대한 정확한 평가가 아닙니다.
PDF 파싱 품질 (PDF parsing quality): 복잡한 레이아웃(다단 구성, 과도한 그래픽 디자인)은 정보 추출 오류를 유발할 수 있습니다. 깔끔한 단일 열(single-column) 형식이 가장 신뢰할 수 있는 결과를 제공합니다.
모델 품질이 출력에 영향을 미침: Ollama + 소형 모델 (gemma3:4b)을 사용하는 것과 Gemini Pro를 사용하는 것은 서로 다른 결과를 생성합니다. 만약 평가가 명백히 잘못되었다고 느껴진다면, 더 큰 모델을 사용해 보세요.
점수는 HackerRank의 채용 가치를 반영함: 가중치 분포(오픈 소스 + 개인 프로젝트 > 실무 경험)는 HackerRank 자체의 선호도를 반영합니다. 대형 기술 기업들은 종종 실무 경험을 더 무겁게 우선시하며, 스타트업은 프로젝트의 창의성을 다르게 평가할 수 있습니다. 이를 보편적인 표준이 아닌 하나의 데이터 포인트로 활용하세요.
빠른 시작: 가장 저렴한 설정
빠르게 테스트만 해보고 싶다면, Gemini Flash가 비용이 매우 저렴합니다:
# .env
LLM_PROVIDER=gemini
DEFAULT_MODEL=gemini-2.0-flash # 빠르고 저렴함
...
그 다음 실행하세요:
python score.py ~/Desktop/my_resume.pdf
링크 및 리소스
- 🌟 GitHub: interviewstreet/hiring-agent
- 🏢 HackerRank: hackerrank.com
- 📄 JSON Resume 표준 (JSON Resume standard): jsonresume.org
결론
개발자들에게 hiring-agent의 가치는 "채용 담당자들이 어떤 도구를 사용하는가"를 이해하는 데 있지 않습니다. 그것은 특정 질문에 답하는 것입니다: 이 채점 기준(scoring rubric)에 따르면, 귀하의 이력서는 현재 몇 점이며, 어떤 부분이 부족한가?
가중치 분포는 구체적인 사실을 드러냅니다. 이 시스템에서 공개적으로 보이는 GitHub 프로젝트 활동은 기본 점수의 약 65%를 차지합니다. 이는 귀하의 이력서 텍스트가 아무리 세련되었더라도, GitHub 프로필이 빈약하면 낮은 점수로 이어진다는 것을 의미합니다. 이러한 통찰은 귀하가 어디에 시간을 써야 할지에 직접적인 영향을 미칩니다 — 이력서 문구를 계속 다듬을 것인지, 아니면 그 시간을 투자해 의미 있는 프로젝트를 GitHub에 올릴 것인지 말입니다.
평가를 실행한 후, 각 증거 설명(evidence explanation)을 주의 깊게 읽으십시오. 그곳에 실행 가능한 정보가 담겨 있습니다. 시스템이 당신의 프로젝트 중 어떤 것을 가치 있다고 인식했는지, 어떤 것을 간과했는지, 그리고 당신의 경력 사항에서 어떤 종류의 설명이 누락되었는지를 알 수 있습니다. 이것들은 즉시 실행에 옮길 수 있는 발견 사항들입니다.
엄선된 AI 에이전트(AI Agents)와 기술을 위한 마켓플레이스인 PrimeSkills를 탐색해 보세요. 각 기술은 실제 기업 워크플로우(enterprise workflows)에서 검증되었으며, 과장된 광고를 걷어내고 진정으로 효과적인 것만을 유지합니다.
더 유용한 통찰력과 흥미로운 제품들을 확인하시려면 저의 홈페이지에 방문해 주세요.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기