---
name: jd-analyzer
description: >
  채용공고를 입력받아 "실제로 무슨 일을 하는 자리인지"를 역추론하는 공고 분석 스킬.
  추상적으로 쓰인 문구를 구체적 업무로 번역하고, 도메인 특성을 조사해 종합 분석 결과를 만든다.
  Trigger: "공고 분석해줘", "이 채용공고 뭐하는 자리야", "JD 분석", "이 포지션 해석해줘",
  "job posting analysis", "공고 뜯어보기".
  Input: 채용공고 URL 또는 붙여넣은 JD 텍스트.
  Output: jd-analysis.md (업무 역추론 + 도메인 브리핑 + 요구역량 우선순위 + 미기재 리스크).
metadata:
  version: "0.3.0" # x-release-please-version
  repo: https://github.com/useful-skills/job-application-skills
---

# JD Analyzer

채용공고를 액면 그대로 읽지 않고, 그 뒤에 있는 실제 업무를 역추론하는 스킬.

## 왜 필요한가

규모가 큰 기업일수록 공고를 추상적으로 쓴다. 이유는 여러 가지다.

- 조직 개편이 잦아 구체적으로 쓰면 금방 틀린 공고가 된다
- 내부 시스템·프로젝트명을 외부에 노출할 수 없다
- 하나의 공고로 여러 팀의 TO를 동시에 채운다
- 인사팀이 현업의 실제 업무를 정확히 모른 채 템플릿으로 작성한다

결과적으로 지원자는 "데이터 기반 의사결정을 지원합니다" 같은 문장만 보고 지원해야 한다.
이 스킬은 그 문장을 **실제 업무 시나리오와 필요 역량으로 되돌리는** 작업을 한다.

---

## 실행 파이프라인

### Phase 1. 공고 원문 확보와 구조 파싱

URL이면 웹 조회로 원문을 가져오고, 텍스트면 그대로 사용한다.
다음 필드로 구조화한다. 없는 필드는 "미기재"로 명시한다. **미기재 자체가 분석 대상이다.**

| 필드 | 파싱 대상 | 비고 |
|---|---|---|
| 포지션명 | 제목 | 내부 직급 체계 힌트 |
| 소속 조직 | 팀/본부/직군 | 조직도상 위치 추정 |
| 주요 업무 | 담당 업무 목록 | Phase 2 역추론의 주 입력 |
| 자격 요건 | 필수 | 실제 필터링 기준 |
| 우대 사항 | 우대 | 진짜 원하는 사람의 모습 |
| 사용 기술 | 기술 스택 | 도메인 추정의 핵심 단서 |
| 채용 절차 | 전형 단계 | 준비 범위 결정 |
| 근무 조건 | 근무지, 형태, 계약 유형 | 계약직 여부는 반드시 확인 |
| 계약 법인 | 사업자정보 | company-diligence 로 넘길 식별자 |

**미기재 항목의 의미**
- 연봉 미기재: 국내에서는 일반적. 신호로 세지 않음
- 계약 형태 미기재: 확인 필요. 정규직이 아닐 수 있음
- 팀 규모 미기재: 신설 조직이거나 1인 포지션일 수 있음
- 채용 절차 미기재: 프로세스가 정립되지 않은 조직일 수 있음
- 사용 기술 미기재: 비개발 직군이면 정상, 개발 직군이면 레거시를 감추는 경우가 있음

### Phase 2. 추상 문구의 구체화 (이 스킬의 핵심)

공고의 각 문장에 대해 다음을 수행한다.

1. **추상 정도 판정**: 그 문장만 읽고 하루 업무를 그릴 수 있는가
2. 그릴 수 없으면 **역추론 트리거**

역추론 방법 (`references/inference-playbook.md` 참조):

**방법 A. 동일 직무 타사 공고 대조**
같은 직무명으로 다른 회사 공고 5~10건을 웹 검색으로 모아, 공통 업무와 이 회사만의 특이 업무를 분리한다.
공통 업무는 직무의 기본기, 특이 업무는 이 회사가 실제로 원하는 것이다.

**방법 B. 기술 스택 역추론**
요구 기술의 조합에서 실제 시스템 구조와 업무를 추정한다.
```
Kafka + Flink + ClickHouse  → 실시간 데이터 파이프라인 운영. 장애 대응 온콜 가능성
Airflow + dbt + Snowflake   → 배치 ETL 중심. SQL 비중 높음
Spring Boot + MSA + K8s     → 서비스 분리 진행 중이거나 완료. 도메인 경계 설계 경험 요구
레거시 + 신규 스택 병기      → 마이그레이션 프로젝트일 확률 높음. 이관 경험이 실질 요건
```
비개발 직군도 동일하게 적용한다. 예: "Salesforce + Tableau" → 세일즈 오퍼레이션 성격.

**방법 C. 회사 공개 자료 대조**
- 기술블로그: 최근 글에서 다루는 문제가 곧 그 팀의 현재 과제일 확률이 높다
- 채용 페이지의 다른 공고: 같은 팀에서 어떤 직군을 함께 뽑는지 보면 프로젝트 성격이 드러난다
- 컨퍼런스 발표, 오픈소스 활동, 링크드인 팀원 프로필

**방법 D. 조직 맥락 추론**
- 신설 포지션인가 충원인가: 공고 재게시 이력, 팀 규모 언급으로 추정
- 이 포지션이 해결하려는 문제가 무엇인가
- 성장 국면인가 유지보수 국면인가

각 역추론에는 **근거와 확신도**를 함께 기록한다.
```
추론: 레거시 마이그레이션 프로젝트 투입 가능성 높음
근거: 공고에 Java 8과 Kotlin 병기 + 기술블로그에 "모놀리스 분리" 3편 연재 (2025-11 ~ 2026-02)
확신도: 높음
```

### Phase 3. 도메인 브리핑

지원자가 그 산업을 모를 수 있다. 도메인 특성을 조사해 요약한다.

- 산업 구조와 수익 모델
- 이 산업 특유의 용어 (면접에서 나올 수 있는 것)
- 규제 환경 (금융·의료·교육은 규제가 업무를 규정한다)
- 이 산업에서 그 직무가 갖는 특수성
- 최근 1년 산업 이슈

**규제 산업 체크**
금융, 보험, 의료, 교육, 통신 등은 규제가 실제 업무의 상당 부분을 차지한다.
공고에 안 써 있어도 컴플라이언스 업무 비중이 크다는 점을 브리핑에 포함한다.

### Phase 4. 요구역량 우선순위화

공고는 역량을 나열만 하고 우선순위를 알려주지 않는다. 다음 기준으로 순위를 매긴다.

| 신호 | 우선순위 판정 |
|---|---|
| 필수 요건 최상단에 위치 | 최우선 |
| 주요 업무와 자격 요건 양쪽에 중복 등장 | 최우선 |
| 우대 사항인데 매우 구체적으로 기술됨 | 실질 필수일 가능성 높음 |
| 타사 동일 직무 공고에는 없는 항목 | 이 회사의 차별 요구. 강조 포인트 |
| 형식적 나열 (커뮤니케이션 능력, 책임감 등) | 후순위. 지원서에서 비중 낮게 |

결과를 3단계로 정리한다.
- **반드시 증명해야 하는 역량** (없으면 서류 탈락)
- **차별화 포인트** (있으면 눈에 띄는 것)
- **형식적 요건** (언급만 해도 되는 것)

### Phase 5. 리스크와 확인 필요 항목

공고에서 읽히는 주의 신호를 정리한다.

| 신호 | 해석 |
|---|---|
| 업무 범위가 지나치게 넓음 | 1인 다역. 인력 부족 조직일 수 있음 |
| "멀티태스킹", "빠른 환경에 적응" 반복 | 업무 강도 높음의 완곡 표현일 수 있음 |
| 경력 요구는 높은데 직급이 낮음 | 처우 대비 기대치 불일치 |
| 계약직·파견 여부 불명확 | 반드시 확인 |
| 동일 공고 장기 게시 | 이탈 반복 또는 처우 경쟁력 부족 |
| "대표님과 직접" 강조 | 소규모 조직. 체계 미비 가능성 |
| 채용 절차가 1회 면접뿐 | 채용 기준이 정립되지 않았을 수 있음 |

이 신호들은 **단정하지 않고 확인 질문으로 변환**한다.

### Phase 6. company-diligence 연계

공고에서 추출한 계약 법인 정보를 company-diligence 스킬로 넘긴다.
공고 분석만으로는 "이 일이 나에게 맞는가"만 알 수 있고,
"이 회사에 가도 안전한가"는 알 수 없기 때문이다. 두 스킬은 함께 써야 완결된다.

---

## 출력 형식

`output/{회사}-{포지션}-{YYYYMMDD}/jd-analysis.md`

```markdown
# {회사} {포지션} 채용공고 분석

## 0. 공고 요약
- 계약 법인 / 근무지 / 고용 형태 / 마감일
- 미기재 항목 목록

## 1. 공고 원문 구조화
필드별 정리 표

## 2. 실제 업무 역추론
| 공고 문구 | 추론된 실제 업무 | 근거 | 확신도 |
|---|---|---|---|

## 3. 도메인 브리핑
산업 구조 / 용어 / 규제 / 최근 이슈

## 4. 요구역량 우선순위
- 반드시 증명해야 하는 것
- 차별화 포인트
- 형식적 요건

## 5. 주의 신호와 확인 질문

## 6. 다음 단계
- company-diligence 로 회사 실사 (계약 법인: OOO)
- application-strategy 로 지원 전략 수립
```

---

## 원칙

- 추론과 사실을 반드시 구분해 표기한다. 추론에는 근거와 확신도를 붙인다
- 근거 없는 추론은 쓰지 않는다. "아마 그럴 것이다"는 분석이 아니다
- 공고를 비판하는 것이 목적이 아니다. 지원자가 준비할 것을 정하는 것이 목적이다
- 확신도가 낮은 추론은 낮다고 쓴다. 지원자가 면접에서 틀린 전제로 말하면 손해가 크다

---

## 참조 문서

- `references/inference-playbook.md` : 역추론 방법별 상세 절차와 예시
- `references/abstract-phrase-dictionary.md` : 자주 쓰이는 추상 문구와 실제 의미 대조표