AI 네이티브 워크플로로 이력서 스크리닝을 다시 만든 방법

이 글은 작은 실험에 관한 것입니다. 우리의 Notion 채용 데이터베이스를 Claude Code에 연결하고, 100개 이상의 AI 에이전트를 병렬로 배치하는 동적 워크플로우를 실행하여 이력서를 읽고, 일관된 루브릭에 따라 점수를 매기고, 서로의 판단을 교차 검증함으로써 즉시 실행에 옮길 수 있는 순위가 매겨진 최종 후보 목록을 만들어내는 실험입니다.

전체 비용은 65달러였고, 115명의 후보자를 대상으로 약 13분 만에 실행되었습니다. 하지만 비용보다 더 흥미로웠던 것은 이 과정에서 드러난 방법론적 질문들이었습니다 — 언제 단일 에이전트 대신 에이전트 집단을 써야 하는지, AI의 점수 인플레이션을 어떻게 방지할지, 그리고 "우수함"을 기계가 실제로 실행할 수 있는 형태로 인코딩한다는 것이 무엇을 의미하는지에 관한 질문들 말입니다.

1. 동적 워크플로우란 무엇인가

개념부터 시작하겠습니다. 나머지 모든 것이 이 위에 서 있기 때문입니다.

오늘날 대부분의 AI 사용은 프롬프트-응답 패턴을 따릅니다. 메시지를 보내고, 답을 받고, 반복합니다. 이는 일회성 작업에는 잘 맞지만, 115개의 대상에 대해 동일한 작업을 해야 할 때는 어색해집니다 — 115번 복사-붙여넣기를 하거나, 단일 대화가 순차적으로 처리하도록 요청해야 하는데, 이는 진행될수록 느려지고 노이즈가 늘어납니다.

동적 워크플로우는 다른 모델입니다: AI 에이전트 집단을 오케스트레이션하는 코드입니다. 그 핵심 속성은 다음과 같습니다:

• 결정론적 제어 흐름과 AI 판단을 분리해서 유지합니다. 루프, 배분, 집계, 쿼터 강제는 코드가 처리하고(재현 가능하고 감사 가능함), 주관적 판단(이 이력서가 충분히 강한가?)은 AI 에이전트에 위임됩니다.
• 팬아웃 병렬성. 단일 parallel(...) 호출로 수십, 수백 개의 독립적인 에이전트를 동시에 띄워, 각자 서로를 오염시키지 않고 자기 몫을 처리할 수 있습니다.
• 다단계 파이프라인. 한 단계의 출력이 다음 단계로 이어집니다. 필터링, 순위 매기기, 중복 제거는 단계 사이에서 코드가 처리합니다.
• 구조화된 출력. 각 에이전트는 자유 형식의 채팅 텍스트가 아니라 스키마에 맞는 JSON을 반환하므로, 후속 코드가 이를 직접 소비할 수 있습니다.

비유하자면: 단일 대화는 오후 시간 동안 전문가 한 명에게 자문을 구하는 것과 같습니다. 동적 워크플로우는 125명으로 구성된 심사 패널을 꾸려, 각 위원에게 루브릭과 후보자 파일 하나씩을 배정하고, 모든 심사를 병렬로 진행하며, 상위 결과를 교차 검증한 뒤 순위 목록으로 집계하는 것과 같습니다 — 배분, 디스패치, 집계 로직이 스크립트에 내장되어 있는 채로요.

이력서 스크리닝은 이 패턴에 자연스럽게 들어맞습니다: 높은 물량, 균일한 기준, 주관적 판단, 공정성 요구사항.

더 깊은 기술적 소개는 다음을 참고하세요: 모든 작업을 위한 하니스: Claude Code의 동적 워크플로우

2. 채용 워크플로우: 목표와 설계

문제

우리에게는 구체적인 고충이 있었습니다. Notion 채용 데이터베이스에 "초기 검토" 상태로 남아 있는 100명이 넘는 후보자를, 기준 표류 없이 수동으로 처리할 현실적인 방법이 없었다는 것입니다 — 80번째 이력서를 볼 때 적용하는 기준은 5번째 이력서를 볼 때의 기준과 거의 항상 다르기 마련입니다.

저는 한 가지 구체적인 아이디어를 검증해보고 싶었습니다: "AI 에이전트 시대에 훌륭함이란 무엇인가"를 기계가 실행 가능하고 사람이 읽을 수 있는 루브릭으로 추상화한 뒤, 115명의 후보자 전원을 동일한 기준으로 처리할 수 있을까?

목표는 명시적으로 AI가 채용 결정을 내리게 하는 것이 아니었습니다. 목표는 다음과 같았습니다:

1. 115명의 후보자를 순위가 매겨지고 근거가 명시된 최종 후보 목록으로 압축하여, 실제로 그럴 자격이 있는 사람들에게 사람의 관심이 향하도록 하는 것.
2. 기준을 투명하고 반복 개선 가능하게 만드는 것 — 출력이 잘못되었다면, 코드나 직감이 아니라 Markdown 파일을 바꾸면 되도록.

세 가지 핵심 설계 결정

결정 1: 기준과 코드를 완전히 분리한다

평가 기준은 워크플로우 코드에 내장되어 있지 않고, 독립된 Markdown 파일(criteria/)에 존재합니다. 비기술직 동료를 포함한 누구든 이 파일들을 수정함으로써 스크리닝 동작을 바꿀 수 있습니다:

criteria/
├── 00-philosophy.md          전체 철학: 우리가 채용하려는 대상 + "기준을 높여라" 규칙
├── 01-pedigree.md            탄탄한 학업적/초기 기반    (가중치 20%)
├── 02-ai-agent-fluency.md    AI 네이티브 역량                  (가중치 35%)
├── 03-grit-problem-solving.md  문제 해결력 & 역경 극복  (가중치 30%)
├── 04-talent-lens.md         최상위 인재 시그널                     (가중치 15%)
└── scoring.md                점수 산정 공식 + 등급 구간 + 5% 쿼터 규칙

이 네 가지 차원은 우리가 정의한 **"AI 에이전트 시대의 우수함 기준, v0.1"**입니다. 각각의 배경은 다음과 같습니다:

• AI 네이티브 역량이 가장 높은 가중치(35%)를 차지합니다. 2026년 현재, Claude Code 같은 에이전틱 도구를 실제로 업무의 핵심 방식으로 사용하는지 여부는 생산성을 크게 가르는 요인입니다. 우리는 특히 키워드 도배를 감점 대상으로 삼습니다 — 검증 가능한 프로젝트 증거 없이 "Claude Code"를 나열하는 것은 약한 신호로 취급됩니다.
• 문제 해결의 실증적 증거(30%). 우리는 "상흔"을 찾습니다: 처음부터 독립적으로 만든 것들, 실제 장애물을 극복한 서사들 — 튜토리얼 수준의 재현이 아닌 것들입니다.
• 탄탄한 기반(20%). 학력은 잠재력의 대리 지표 역할을 합니다 — 이는 신호일 뿐 필수 조건은 아닙니다. 명문대 학위에 평범한 결과물이 결합되면 감점되고, 명문 학벌은 없지만 실제로 결과물을 낸 독학 개발자는 가산점을 받습니다.
• 최상위 인재 시그널(15%). 이 차원은 의도적으로 주관적입니다. 프롬프트는 다음과 같이 묻습니다: Anthropic 같은 팀이나 머스크 같은 창업자가 즉시 연락하고 싶어할 만한가? 이는 다른 세 차원이 포착하지 못하는 주도성, 안목, 속도를 담아냅니다.

결정 2: "기준을 높여라"를 슬로건이 아니라 하드 제약으로 인코딩한다

scoring.md에는 확고한 규칙이 있습니다: 최상위 등급(S)에 도달하는 후보자는 전체 풀의 5% 이하여야 한다. 모든 채점이 끝난 뒤, 코드는 전역 상한을 적용합니다: 기술적으로 많은 후보자가 S 범위 점수를 받더라도, 상위 5%만 통과할 수 있습니다. 이는 잘 알려진 실패 양상과 직접 맞서는 것입니다 — AI 채점은 본질적으로 관대해지는 경향이 있습니다. 하드 제약이 없으면, 전체 풀의 절반을 "우수"로 채점해버립니다.

결정 3: 부풀려진 점수를 잡아내기 위해 적대적 리뷰를 추가한다

채점만으로는 충분하지 않습니다. 단일 채점 에이전트는 "최상위 저널에 게재", "직접 프레임워크를 구축함" 같은 인상적으로 들리는 키워드에 끌려갈 수 있습니다. 그래서 상위권 후보자들은 2차 단계를 거칩니다: "악마의 변호인" 에이전트 패널이 명시적으로 "이 사람이 최상위 등급을 받을 자격이 있다"는 주장에 반박하는 것을 임무로 삼아, 근거가 충분히 뒷받침하지 못하는 경우 점수를 끌어내립니다.

워크플로우

설정 📋 Notion 채용 데이터베이스 — Notion CLI 풀 → 후보자당 구조화된 데이터 파일 하나

AI 1단계: 채점 (115개 에이전트 병렬)

• 6개 기준 MD 파일 + 해당 후보자의 데이터 파일을 읽음
• GitHub / 포트폴리오 링크를 직접 방문하여 증거를 검증
• 구조화된 JSON 출력: 4개 차원 점수 + 근거 + 하이라이트 + 위험 신호

Code 결정론적 종합

• 가중 합계 계산
• 전역 순위 정렬, 5% 쿼터 슬롯 계산
• 적대적 리뷰 큐에 넣을 상위 후보자 선정

AI 2단계: 적대적 리뷰 (에이전트 병렬)

• "악마의 변호인" 페르소나가 각 상위 후보자를 리뷰
• 최상위 등급 지정에 반박
• 근거가 불충분한 경우 점수를 끌어내림

Code 결정론적 최종 판정

• 보정된 점수로 재정렬
• 5% 하드 캡 적용
• 최종 등급 부여: S / A / B / C / D

출력: 순위 보고서 후보자별 점수, 근거, 적대적 리뷰 판정이 담긴 구조화된 Markdown

파란 단계(채점 / 리뷰)는 AI입니다. 회색 단계(종합 / 판정)는 코드입니다. 이 구분은 의도적입니다: 가중치 부여, 순위 매기기, 쿼터 강제처럼 수학적인 것은 재현성을 위해 코드로 가고, "이 사람이 충분히 강한가?"처럼 판단이 필요한 것은 AI로 갑니다.

3. 우리가 본 것: 결과와 인사이트

아래의 모든 후보자는 익명 처리되었습니다. 이름이나 신원을 특정할 수 있는 정보가 아니라 작업 유형을 설명합니다.

우리가 실행한 것

분포

5% 쿼터(5개 슬롯)는 전혀 사용되지 않았습니다 — 누구를 막은 것은 쿼터가 아니라 절대 점수 기준선이었습니다. 스스로 A등급 하한선을 넘은 사람은 아무도 없었습니다. 이것이 실제로 유용한 신호인 이유는 아래에서 더 다루겠습니다.

순위 상위권이 어떤 모습이었나 (익명 처리)

예외 없이, 최상위 순위 후보자들은 실제로 에이전트를 만들어본 사람들이었습니다 — AI에 대해 들어본 사람들이 아니라요:

• 1위: 처음부터 Claude-Code 스타일의 멀티 에이전트 작업대를 만든 대학원생 — 에이전트 메인 루프, 도구 호출 파싱, 컨텍스트 압축, 서브 에이전트 생성, 안전 장치까지 포함해서요. 전부 검증 가능한 코드였고, 단순한 설명이 아니었습니다.
• 2위: 실제로 공개 접속 가능한 멀티 에이전트 시스템을 배포한 또 다른 대학원생(특정 도메인 애플리케이션), 그 위에 학술적 성과까지 쌓은 경우.
• 그 아래로는: 처음부터 Go로 에이전트 오케스트레이션 엔진을 작성한 사람, Claude Code의 아키텍처를 연구해 경량 코딩 에이전트를 출시한 사람, AI 도구를 전 과정에 활용해 7일 만에 로컬 LLM을 탑재한 게임을 독자적으로 만든 사람 등이 있었습니다.

이들의 공통점: 강한 신호는 이력서 본문에는 거의 드러나지 않았습니다 — 그것들은 GitHub 저장소와 포트폴리오에 있었습니다. 바로 이 때문에 각 채점 에이전트는 이력서 텍스트만 읽는 것이 아니라 직접 링크를 방문해 증거를 검증하도록 지시받았습니다.

세 가지 인사이트

인사이트 1: 적대적 리뷰는 실제로 부풀려진 점수를 잡아냈다

가장 명확한 사례는 상위 두 후보자였습니다. 채점 단계 이후 둘 다 가중 합계가 82점 안팎이었습니다 — A등급으로 진입하고 S등급 문턱을 스칠 만큼 충분했습니다. 적대적 리뷰 이후, 둘 다 75점 안팎으로 내려앉았는데, 매우 구체적인 근거와 함께였습니다:

"검증 가능한 멀티 에이전트 작업대를 구축함 — AI 네이티브 역량은 확실한 신호입니다. 하지만 프로젝트는 만들어진 지 약 3주밖에 되지 않았고, 단독 기여자이며, 스타 0개, 테스트 없음. 개념적으로는 재구현이지, 독창적인 문제 해결이 아닙니다. 학위 한 줄 외에는 뒷받침하는 증거가 거의 없습니다: 확실히 잠재력 있는 후보이지만, 탁월하지는 않습니다."

"진짜이고 검증 가능한 AI 네이티브 빌더입니다. 하지만 주장된 최상위 저널 게재는 채용 담당자의 메모에만 등장하며, 독립적으로 검증 가능한 출처가 없습니다. 핵심 시스템 백엔드는 비공개이며, 개인 기여도를 확인할 수 없습니다. 검증되지 않은 학력을 근거로 최상위 등급을 노리는 것은 키워드 기반의 점수 인플레이션입니다."

이는 정확히 이 설계가 의도한 바입니다: 이 후보자들을 기각한 것이 아니라 — 증거가 실제로 뒷받침할 수 있는 수준으로 점수를 되돌린 것입니다. 단일 채점 에이전트는 휩쓸릴 수 있지만, 반박을 임무로 하는 별도의 에이전트 패널은 이를 안정적으로 낮춰줍니다.

인사이트 2: S:0 / A:0은 버그가 아니라 거울이다

첫 반응은 기준이 잘못 설정된 것 아니냐는 질문일 것입니다. 하지만 이 풀을 정직하게 들여다보면:

• 상당수 후보자의 이력서가 매우 빈약했습니다 — 핵심 차원(AI 경험, 검증 가능한 작업물)이 아예 없었습니다.
• Agent Engineer 직군에 지원한 많은 후보자가 에이전틱 도구 사용의 증거도, GitHub 링크도 전혀 없었습니다.
• 이 풀에는 채용 담당자의 업무용 이메일이나 LinkedIn 시스템 알림도 섞여 있었습니다 — 이들은 정확히 무관한 것으로 식별되어 0점 처리되었으며, 이는 부수적으로 우리 채용 데이터베이스가 정리가 필요하다는 것을 드러냈습니다.

즉, 엄격한 루브릭이 신호와 노이즈를 깔끔하게 분리해냈습니다. 진짜 빌더들(상위 6명)과 "성취도 높은 제너럴리스트"(중간층)는 명확하게 구분된 위치에 자리 잡았습니다. 그게 핵심입니다 — 모두를 부풀리기보다는 몇 명을 놓치는 편이 낫습니다.

이는 논의할 가치가 있는 열린 질문도 드러냅니다: 현재 A등급 기준선(78점)이 아직 전문 경력은 없지만 GitHub 실적이 탄탄한 학생 후보자들에게 너무 가혹한 것은 아닐까요? 흥미롭게도, 적대적 리뷰 에이전트들 스스로가 상위 두 명을 "잠재력 높은 후보"라고 묘사했지만, 가중 점수는 이들을 B등급에 머물게 했습니다. 잠재력 높은 초기 경력 후보자들을 위해 그 기준선을 완화할지 여부는, B그룹의 실제 면접 결과를 본 뒤에 내리는 것이 가장 좋은 판단입니다. 좋은 소식은, 그 변경은 Markdown 파일 하나 안의 숫자 하나일 뿐이라는 것입니다. 코드는 필요 없습니다.

인사이트 3: "코드로서의 기준"은 의견 불일치를 생산적으로 만든다

채용 기준에 관한 대화는 보통 모호한 채로 남습니다 — "추진력 있는 사람을 원한다", "스스로 방법을 찾아내는 사람" 같은 식으로요. 이 루브릭은 가중치와 기준 사례가 명시되어 있기 때문에, 대화가 즉시 구체적으로 변합니다: "AI 역량은 35%여야 하나, 40%여야 하나?" "명문 학위가 없는 아웃라이어 빌더는 실제로 얼마나 이득을 봐야 하나?" "쿼터는 5%여야 하나, 8%여야 하나?" — 모든 의견 불일치가 Markdown 파일 안의 특정 줄에 대응하며, 그 줄은 바꾸고, 버전 관리하고, 토론할 수 있습니다. 기준은 매 회의마다 반복해야 하는 합의가 아니라, 유지 관리하는 자산이 됩니다.

4. 비용과 ROI

정확한 지출

우리는 Claude Opus 4.8(최상위 등급)을 사용했습니다. 토큰 카테고리별 정확한 내역은 다음과 같습니다:

후보자 한 명당 약 0.57달러인 셈입니다.

반직관적인 발견: 캐시 쓰기가 가장 큰 항목이다

자연스러운 가정은 115개 에이전트가 모두 동일한 6개 기준 파일을 읽으니, 프롬프트 캐싱이 큰 도움이 될 것이라는 겁니다. 하지만 예상과 다르게 그렇지 않습니다.

프롬프트 캐싱은 정확한 프리픽스 일치에 의존하고, 각 에이전트 세션은 독립적입니다. 125개 에이전트라는 것은 125개의 독립된 세션을 의미하며 — 각각 다른 작업 설명(다른 후보자 데이터)을 갖고 있어서 — 에이전트 A가 작성한 캐시는 에이전트 B가 히트할 수 없습니다. 캐싱은 각 에이전트 자신의 멀티턴 실행 내에서는 도움이 됩니다(기준 읽기 → GitHub 방문 → 포트폴리오 방문 → 출력, 각 라운드에서 이전 내용을 다시 읽음).

이는 아키텍처상의 트레이드오프를 드러냅니다: 팬아웃 병렬성은 캐시 쓰기 비용을 곱으로 늘리지만(모든 에이전트가 자신만의 캐시를 구축하므로), 그 대가로 고립되어 서로 오염되지 않는 판단을 얻고, 순차 처리의 2차적 컨텍스트 누적 문제를 제거합니다. 판단 품질에 민감한 작업이라면, 이 트레이드오프는 그만한 가치가 있습니다.

ROI를 어떻게 생각해야 하나

수동 리뷰와 직접 비교하면: 채용 담당자가 이력서 한 건을 꼼꼼히 읽고, GitHub를 확인하고, 메모를 작성하는 데 보수적으로 잡아도 후보자당 510분이 걸립니다. 115명이면 **1019시간의 집중 작업**이 필요하며, 그 과정 내내 기준이 흔들립니다.

이 워크플로우는 다음을 제공했습니다:

하지만 더 중요한 ROI는 주의력에 관한 것입니다: 이 워크플로우는 명백히 부적합한 83명의 후보자로부터 인간의 주의를 거두어 상위권의 진짜 빌더 6명 쪽으로 돌렸습니다. 그것이 초기 스크리닝이 할 수 있는 가장 가치 있는 일입니다.

더 저렴하게 할 수 있을까?

가능하지만, 아마 그럴 필요는 없을 것입니다. 이것이 고빈도, 대용량 작업(하루 수백 명)이 된다면, 실용적인 최적화는 다음과 같을 것입니다:

• 채점 단계에는 Sonnet을, 적대적 리뷰에만 Opus를 사용 — 품질 저하를 최소화하면서 아마 70~80%의 비용 절감이 가능할 것입니다.
• 또는 대략적인 1차 필터링에는 더 저렴한 모델을 쓰고, 상위권의 상세 평가에만 Opus를 사용.

하지만 채용은 저빈도, 고위험, 되돌리기 어려운 일입니다. 완전한 감사 가능성과 반복 개선 가능한 기준으로 전체 파이프라인을 처리하는 데 65달러라면, 결론은 명확합니다: 최고의 모델을 써라. 판단 품질을 사소한 비용 절감과 맞바꾸지 마라.

더 큰 그림

이 실험에서 진짜로 흥미로운 것은 "AI가 이력서를 스크리닝할 수 있다"는 것이 아닙니다 — 그건 새로운 아이디어가 아닙니다. 진짜 흥미로운 것은 동적 워크플로우 모델 — 코드가 AI 에이전트 집단을 오케스트레이션하는 것 — 이 특정 범주의 작업을 처음으로 구조화하고, 재현하고, 반복 개선할 수 있게 만든다는 점입니다.

채용은 그저 진입점일 뿐입니다. 동일한 패턴 — 읽기 가능한 파일로서의 기준 + 팬아웃 병렬 평가 + 적대적 리뷰 + 결정론적 집계 — 은 일관되고 대용량인 주관적 판단이 필요한 어떤 영역에도 적용될 수 있습니다: 콘텐츠 모더레이션, 코드 리뷰, 사용자 피드백 트리아지, 경쟁사 분석, 실사(due diligence).

이 루브릭은 v0.1입니다. 완벽하지 않습니다. 하지만 이제는 버전 관리되고, 논쟁 가능하고, 개선 가능한 자산입니다 — 누군가의 머릿속에만 존재하는 암묵적 합의가 아니라요. 그 전환이야말로, 어떤 개별 결과보다도 이 실험이 진짜로 다룬 것입니다.