채용공고 → 지원자 평가 시트 자동 생성

학습목표 / 사전지식: 채용공고 한 덩어리를 지원자 입력 필드, 필수 여부, 검증규칙, 5점 평가 기준이 담긴 평가 시트 초안으로 바꾸며, 선수지식은 없어도 된다. [GL-07]

1. 왜 필요한가 — 개념·배경을 초보자 눈높이로

채용공고는 “우리가 어떤 사람을 찾는가”를 적은 글이고, 지원자 평가 시트는 “그 사람을 어떤 질문과 기준으로 확인할 것인가”를 정리한 표다. [GL-07]

채용공고가 장보기 메모라면, 평가 시트는 계산대에서 빠뜨린 물건이 없는지 짚어 보는 체크리스트다. [GL-07]

이번 클립의 근거는 HR·운영 영역에서 “폼제작 30–45분↓”라고 정리된 사례다. [GL-07]

폼은 지원자에게 입력받는 질문 묶음이고, 검증규칙은 “이메일은 이메일 모양으로, 경력 연차는 숫자로, 자기소개는 너무 짧지 않게”처럼 입력값을 걸러내는 약속이다. [GL-07]

루브릭은 평가자가 같은 눈금자로 지원자를 보게 하는 채점표이며, 이 레슨에서는 Codex의 Skills로 채용공고를 필드·검증규칙·평가 루브릭 초안으로 바꾼다. [GL-07]

2. 준비 — 코덱스 어디로 들어가 무엇을 누르나

Codex 작업 화면을 열고, 왼쪽 파일 목록에서 Skill을 둘 폴더를 만든 뒤 그 안에 SKILL.md 파일을 만든다. [GL-07]

실습 폴더 이름은 hiring-form-builder로 두고, 이 파일은 매번 같은 설명을 되풀이하지 않게 해주는 업무 매뉴얼이라고 보면 된다. [GL-07]

화면에서 볼 곳은 왼쪽 파일 목록, 가운데 SKILL.md 편집 영역, 아래나 오른쪽의 대화 입력창 세 곳이다. [GL-07]

3. 따라하기 — 단계별로 아주 세세하게

1단계는 왼쪽 파일 목록에서 hiring-form-builder 폴더를 만들고 SKILL.md를 여는 것이다. [GL-07]

2단계는 Skill의 역할을 한 문장으로 정하는 것이며, You turn a job posting into a structured applicant evaluation sheet.라고 적으면 채용공고를 평가 시트로 바꾸는 담당자라는 뜻이 된다. [GL-07]

3단계는 결과물의 그릇을 정하는 일이며, 결과는 Application fields, Validation rules, Evaluation rubric, Required vs preferred criteria, Reviewer notes 다섯 덩어리로 나누게 한다. [GL-07]

4단계는 대화 입력창에 “아래 채용공고를 기준으로 지원자 평가 시트를 만들어줘”라고 쓰고, 그 아래에 채용공고 원문을 붙여 넣는 것이다. [GL-07]

5단계는 Application fields 표를 확인하는 것이며, 이름과 이메일뿐 아니라 경력 연차, 고객 온보딩 경험, 리텐션 관리 경험, 원격 협업 경험처럼 공고 조건을 확인하는 필드가 있어야 한다. [GL-07]

6단계는 Validation rules 표를 확인하는 것이며, 이메일 형식, URL 형식, 숫자 범위, 최소 글자 수 같은 규칙이 필요한 칸에 들어갔는지 본다. [GL-07]

7단계는 Evaluation rubric 표를 확인하는 것이며, 온보딩 설계, 고객 커뮤니케이션, 리텐션 지표 이해, 문서화, 협업 경험 같은 항목이 1점부터 5점까지 나뉘어야 한다. [GL-07]

8단계는 필수와 우대를 다시 조정하는 것이며, SQL이 우대 사항이면 탈락 기준이 아니라 가산점이나 참고 항목으로 내려야 한다. [GL-07]

4. 복붙 템플릿 — 그대로 쓰는 프롬프트/Skill + 해설

아래 내용을 SKILL.md에 붙여 넣는다. [GL-07]

---
name: hiring-form-builder
description: 채용공고, job posting, JD, 지원자 평가 시트, application form, evaluation rubric
---

You turn a job posting into a structured applicant evaluation sheet.

Return:
- Application fields
- Validation rules
- Evaluation rubric with a 1-5 scale
- Required vs preferred criteria
- Reviewer notes

Rules:
- Separate required criteria from preferred criteria.
- Do not invent requirements that are not in the job posting.
- Mark unclear items as "Needs confirmation".
- Use Korean unless the user asks otherwise.

description은 이 Skill이 언제 쓰일지 알려주는 이름표이고, Return은 결과물의 그릇이며, Rules는 공고에 없는 조건을 만들거나 필수와 우대를 섞는 실수를 줄이는 안전장치다. [GL-07]

실행 프롬프트는 아래처럼 쓴다. [GL-07]

아래 채용공고를 지원자 평가 시트로 바꿔줘.
필드, 필수 여부, 검증 규칙, 5점 평가 기준을 표로 정리해줘.
필수 조건과 우대 조건을 분리하고, 애매한 항목은 Needs confirmation으로 표시해줘.

채용공고:
[여기에 채용공고 원문 붙여넣기]

프롬프트의 첫 줄은 작업 목표, 둘째 줄은 결과물의 모양, 셋째 줄은 과한 추측을 막는 기준이다. [GL-07]

5. 응용·함정 — 변형, 자주 막히는 곳과 해결

첫 번째 응용은 직무별 가중치이며, 고객성공 직무는 온보딩과 리텐션을 크게 보고 운영 직무는 정확도와 반복 업무 개선 경험을 크게 보는 식으로 조정할 수 있다. [GL-07]

두 번째 응용은 평가 루브릭 뒤에 “각 항목별 면접 질문 2개를 추가해줘”라고 요청해 평가표와 질문지를 같은 기준으로 맞추는 것이다. [GL-07]

가장 흔한 함정은 공고에 없는 멋진 조건을 새로 만드는 일이므로, Skill 규칙에 Do not invent requirements that are not in the job posting을 남기고 애매한 항목은 Needs confirmation으로 표시하게 한다. [GL-07]

또 다른 함정은 필수와 우대를 섞는 일이며, 필수는 지원 단계에서 확인하고 우대는 점수나 가산점으로 남기면 평가가 덜 흔들린다. [GL-07]

검증규칙은 체처럼 유용하지만 너무 빡빡하면 답변을 받기 어려우므로, 글자 수와 형식 제한은 문항 목적에 맞춰 조정한다. [GL-07]

6. 정리·체크리스트

오늘 흐름은 채용공고 입력, Skill 실행, 필드 확인, 검증규칙 확인, 평가 루브릭 확인, 필수·우대 조정 순서다. [GL-07]

• 채용공고의 필수 조건이 Required로 들어갔는가. [GL-07]
• 우대 조건이 탈락 기준으로 올라가지 않았는가. [GL-07]
• 이메일, URL, 숫자, 글자 수 검증규칙이 필요한 곳에만 들어갔는가. [GL-07]
• 평가 루브릭이 1점부터 5점까지 같은 눈금으로 설명되는가. [GL-07]
• 공고에 없는 조건은 만들지 않고, 애매한 항목은 Needs confirmation으로 남겼는가. [GL-07]

핵심은 채용공고를 그대로 옮겨 적는 게 아니라, 지원자에게 물을 질문과 평가자가 들여다볼 기준으로 바꿔 내는 것이다. [GL-07]

출처

본문의 [...] 표기는 아래 근거에서 확인할 수 있습니다.

• GL-07 — HR·운영 · 폼 생성 스킬