| name | hiring |
| description | 채용공고·JD 작성부터 인터뷰 질문·평가표·오퍼·온보딩(30/60/90)까지 채용 실무를 돕는다. "채용공고 / JD / 채용 / 인터뷰 질문 / 평가표 / 오퍼레터 / 온보딩 / 직무기술서" 요청 시. 조직 설계·위임은 [[org]]. |
작업 흐름(항상): 왜(목적·의도) → 무엇을 → 어떻게 → 기존 컨텍스트·리서치 → 기획 → 시각화 → 호출·실행 → 🔁회고·보완. 자세히 [[method]].
hiring — 채용 실무 (공고부터 온보딩까지)
사람을 뽑는 건 회사에서 가장 비싸고 되돌리기 어려운 결정이다. 왜 이 자리인가부터 잡는다: 지금 없어서 무엇이 안 굴러가나, 6개월 뒤 이 사람이 어떤 성과를 냈으면 뽑길 잘한 건가. 여기가 흐리면 좋은 사람을 뽑아도 실패한다.
산출 유형: COPILOT(공고·JD·프로세스 작성) / DECISION(오퍼·처우 확정) — 문서·질문은 초안으로 만들고, 오퍼·연봉은 대표 최종 승인. (자세히 [[method]])
0. 준비 — 안을 먼저 턴다
business-copilot find_docs
cat "${BIZ_COPILOT_HOME:-$HOME/.business-copilot}/company/"{team,finance}.md 2>/dev/null
company/team.md·org 산출물로 현 조직·빈자리·다음 채용 우선순위를 확인한다. 조직 설계·역할 정의 자체가 아직 없으면 [[org]]부터. 처우 범위·연봉밴드·런웨이는 대표 전용(company/finance.md·_policy.md) — 공고 본문·웹 검색어에 실수치를 넣지 않는다. 없는 연봉밴드·인원계획을 지어내지 않는다 — "확인 필요 + 무엇을 입력하면 채워지는지".
1. 역할 정의 → 채용 우선순위
- 필요 역할: 책임(성과기대)·필수/우대 역량·리포팅 라인. 지금 자리인지, 6개월 뒤 자리인지.
- 우선순위: 병목을 푸는 자리 먼저. "있으면 좋은" 자리는 뒤로. [[org]]의 조직 그림과 맞춘다.
1-B. 채용 판단 — 뽑을까·미룰까·포기할까 (호출·연계, 선제 아님)
공고를 쓰기 전에 **"이 채용이 현실적인가"**를 먼저 판단한다. 이게 흐리면 몇 달을 태운다.
- 현황 진단: 현 인력·공석·팀 부하와 산출물 수준 → [[team-audit]]·
company/team.md. 지금 정말 필요한 인재 수준·시점(당장 vs 6개월 뒤)인가.
- 현실성(뽑을 수 있나): 그 인재가 시장에서 얼마나 희소한가, 우리 처우·단계·브랜드로 데려올 수 있나. 진행 중이면 **채용공고 반응·지원자 파이프라인 상태(지원 수·질·통과율)**를 보고 "내가 원하는 사람" 채용 가능성을 냉정히 추정한다(근거: ATS/메일 지원현황, 시장 연봉밴드 — 근거 티어 표시).
- 선택지: ① 지금 채용 ② 미룸(런웨이·우선순위상 나중) ③ 포기·대체(외주·프리랜서·AX로 자동화 — 반복업무면 AI가 대안, [[handoff]]) ④ 눈높이/처우 조정(주니어+시니어 자문, 밴드 상향). 각 안을 런웨이·기회비용과 견준다.
- 산출: [[decision-memo]] — 뽑는다/미룬다/포기(대체)/조건변경 + 근거 + 기각조건 + 하방(공석 지속 비용 vs 인건비). 결정은 대표. 미룸/포기도 명시적 결정으로 큐에 남긴다(흐지부지 방지).
- 근거 없으면 "확인 필요" — 시장 연봉·지원자 질을 지어내지 않는다.
2. 채용공고 / JD (직무기술서)
한 문서에: 회사소개(왜 이 회사·미션) · 직무(하는 일 5줄) · 성과기대(입사 후 6개월 기여) · 자격(필수/우대) · 처우범위(밴드는 정책 승인 후) · 지원방법. 스펙 나열 말고 "이 일을 잘할 사람"의 상을 그린다. 차별금지 유의: 성별·연령·출신·혼인·장애 등 직무무관 조건 요구·질문 금지 — 근거는 항목별로 다르다: 성별→남녀고용평등법, 혼인·출신지역 등 직무무관 개인정보 요구→채용절차법(제4조의3), 연령→연령차별금지법, 장애→장애인차별금지법. 확정 판단은 [[legal]] 게이트로. 사실과 다른 처우·정규직 여부 과장 금지.
3. 채용 채널
자리 성격에 맞춰 제안: 원티드/사람인·링크드인·레퍼럴(가장 저렴·검증됨)·커뮤니티·헤드헌터(핵심/리더). 채널별 예상 비용·리드타임을 표로. 소재가 필요하면 [[handoff]]로 넘긴다.
4. 전형 프로세스 설계
서류 → (과제) → 인터뷰 1~2회 → 레퍼런스 → 오퍼. 자리 중요도에 맞게 단계를 늘리거나 줄인다. 각 단계 탈락 기준과 후보 경험(응답 리드타임)을 정한다. 과제는 실제 업무에 가깝게, 시간 제한 명시, 무보수 과다부담 금지.
5. 인터뷰 질문 · 평가표 (역량 루브릭)
직무 핵심역량 46개를 뽑아 **행동기반 질문(STAR: 상황-과제-행동-결과)**과 14점 루브릭을 만든다. 유도질문·법정 금지질문(가족계획·종교 등) 배제. 평가표는 면접관별 독립 채점 → 합산 캘리브레이션(첫인상 몰빵 방지).
| 역량 | 질문 예 | 1(미흡) | 4(탁월) |
|---|
| (핵심역량) | "…한 경험을 STAR로" | 근거 없음 | 수치·본인기여 명확 |
6. 레퍼런스 체크
후보 동의 후, 함께 일한 상급자/동료에게: 실제 역할·강점·성장영역·재고용 의향·이직 사유 팩트체크. 유도 없이 개방형으로. 뒷조사·SNS 사찰 금지.
7. 오퍼레터 · 처우 협상 — DECISION
오퍼·연봉·직급은 완성물부터 만들지 않는다. 후보 평가 요약 + 시장밴드(근거 티어 표시) + 처우안 2~3개(하방=인건비·런웨이 영향)를 올려 대표가 확정한 뒤 오퍼레터를 작성한다. 확정은 company/decisions.md, 검토중은 decision-queue.md. 스톡옵션·근로계약·수습·비밀유지 조항은 [[legal]] 로 넘긴다(임의 조건 확정 금지).
8. 온보딩 30 / 60 / 90일
합격이 끝이 아니다. 30일: 온보딩·관계·맥락 이해(초기 산출물 1개). 60일: 첫 실질 기여·오너십. 90일: 독립적 성과·평가/피드백. 각 구간 목표·멘토·체크인 리듬을 문서화한다. 온보딩 준비물·계정·장비·계약 실무는 [[general-affairs]]로 핸드오프.
채용은 평가는 촘촘히, 결정은 대표가. 오퍼·처우·법적 조건은 절대 자동 확정하지 않는다. 자세히 [[method]].
