init
This commit is contained in:
commit
d295c7f139
1527 files changed
+270726
No files matched your search
@@ -0,0 +1,107 @@
|
||||
# career-ops -- 한국어 모드 (`modes/ko/`)
|
||||
|
||||
이 디렉터리는 한국어권 후보자와 한국 채용 시장을 대상으로 career-ops의 주요 모드를 한국어로 번역한 파일을 담고 있습니다.
|
||||
|
||||
## 언제 이 모드를 사용하나요?
|
||||
|
||||
다음 중 하나라도 해당하면 `modes/ko/`를 사용하세요.
|
||||
|
||||
- 주로 **한국어 채용 공고**에 지원하는 경우
|
||||
- CV/이력서, 커버레터, 지원서 답변을 **한국어**로 작성해야 하는 경우
|
||||
- 기계 번역투가 아니라 **한국 테크 채용 문맥에 맞는 자연스러운 한국어**가 필요한 경우
|
||||
- 한국 채용 시장의 조건을 평가해야 하는 경우: 정규직, 계약직, 수습기간, 포괄임금제, 퇴직금, 4대 보험, 성과급, 스톡옵션/RSU, 재택/하이브리드 근무 등
|
||||
|
||||
대부분의 공고가 영어이고 글로벌/외국계 채용 프로세스라면 기본 `modes/`를 사용하세요. 기본 영어 모드도 한국 기업의 영어 공고를 처리할 수 있지만, 한국 채용 시장 특유의 보상/계약 조건을 세밀하게 반영하지는 않습니다.
|
||||
|
||||
## 어떻게 활성화하나요?
|
||||
|
||||
### 옵션 1 -- 세션 단위
|
||||
|
||||
세션 시작 시 Claude에게 이렇게 말하세요.
|
||||
|
||||
> "`modes/ko/` 아래의 한국어 모드를 사용해."
|
||||
|
||||
그러면 Claude는 기본 `modes/` 대신 이 디렉터리의 파일을 읽습니다.
|
||||
|
||||
### 옵션 2 -- 영구 설정
|
||||
|
||||
`config/profile.yml`에 다음을 추가하세요.
|
||||
|
||||
```yaml
|
||||
language:
|
||||
primary: ko
|
||||
modes_dir: modes/ko
|
||||
```
|
||||
|
||||
첫 세션에서 Claude에게 이 설정을 확인하라고 알려주세요. 예: "`profile.yml`에 `language.modes_dir`를 설정해뒀어." 이후 Claude는 자동으로 한국어 모드를 사용합니다.
|
||||
|
||||
## 어떤 모드가 번역되어 있나요?
|
||||
|
||||
이번 첫 버전은 영향도가 가장 큰 네 가지 모드를 다룹니다.
|
||||
|
||||
| 파일 | 번역 기준 | 역할 |
|
||||
|---------|----------------|------|
|
||||
| `_shared.md` | `modes/_shared.md` (EN) | 공통 컨텍스트, archetype, 전역 규칙, 한국 채용 시장 특화 맥락 |
|
||||
| `gonggo.md` | `modes/oferta.md` (ES) | 채용 공고 전체 평가 (블록 A-F) |
|
||||
| `jiwon.md` | `modes/apply.md` (EN) | 지원서 입력 폼을 채우는 live assistant |
|
||||
| `pipeline.md` | `modes/pipeline.md` (ES) | 수집한 채용 공고 URL inbox / Second Brain |
|
||||
|
||||
다른 모드(`scan`, `batch`, `pdf`, `tracker`, `auto-pipeline`, `deep`, `contacto`, `ofertas`, `project`, `training`)는 기존 EN/ES 모드를 그대로 사용합니다. 해당 파일들은 주로 tooling, 경로, 명령어 중심이라 언어와 독립적으로 동작합니다.
|
||||
|
||||
## 영어로 유지하는 것
|
||||
|
||||
테크 채용에서 표준적으로 쓰이는 표현은 의도적으로 번역하지 않습니다.
|
||||
|
||||
- `cv.md`, `pipeline`, `tracker`, `report`, `score`, `archetype`, `proof point`
|
||||
- 도구 이름(`Playwright`, `WebSearch`, `WebFetch`, `Read`, `Write`, `Edit`, `Bash`)
|
||||
- tracker 상태값(`Evaluated`, `Applied`, `Interview`, `Offer`, `Rejected`)
|
||||
- 코드 조각, 경로, 명령어
|
||||
|
||||
이 모드는 한국 테크 업계에서 실제로 쓰는 자연스러운 문체를 지향합니다. 본문은 한국어로 쓰되, `pipeline`, `deployment`, `embedding`, `stack`처럼 현장에서 영어로 쓰는 용어는 억지로 번역하지 않습니다.
|
||||
|
||||
## 기준 용어집
|
||||
|
||||
모드를 수정하거나 확장할 때 문체를 일관되게 유지하기 위한 기준입니다.
|
||||
|
||||
| 영어 | 한국어 (이 codebase 기준) |
|
||||
|---------|-------------------------------|
|
||||
| Job posting | 채용 공고 |
|
||||
| Application | 지원 / 지원서 |
|
||||
| Cover letter | 커버레터 |
|
||||
| Resume / CV | CV / 이력서 |
|
||||
| Salary | 연봉 |
|
||||
| Compensation | 보상 / 보상 패키지 |
|
||||
| Skills | 역량 / 기술 역량 |
|
||||
| Interview | 면접 |
|
||||
| Hiring manager | 채용 매니저 / 실무 리더 |
|
||||
| Recruiter | 리크루터 |
|
||||
| AI | AI / 인공지능 |
|
||||
| Requirements | 자격 요건 / 요구사항 |
|
||||
| Career history | 경력 |
|
||||
| Notice period | 퇴사 통보 기간 |
|
||||
| Probation | 수습기간 |
|
||||
| Vacation | 연차 / 유급휴가 |
|
||||
| Permanent employment | 정규직 |
|
||||
| Fixed-term contract | 계약직 |
|
||||
| Freelance | 프리랜서 / 개인사업자 |
|
||||
| Gross annual salary | 세전 연봉 |
|
||||
| Net salary | 실수령액 |
|
||||
| Severance pay | 퇴직금 |
|
||||
| Social insurance | 4대 보험 |
|
||||
| Inclusive wage system | 포괄임금제 |
|
||||
| Bonus | 성과급 / 보너스 |
|
||||
| Stock option / RSU | 스톡옵션 / RSU |
|
||||
| Meal allowance | 식대 |
|
||||
| Flexible work | 유연근무 |
|
||||
| Remote work | 재택근무 / 원격근무 |
|
||||
| Hybrid work | 하이브리드 근무 |
|
||||
|
||||
## 기여하기
|
||||
|
||||
번역을 개선하거나 새 모드를 추가하려면:
|
||||
|
||||
1. 제안을 담은 Issue를 엽니다 (`CONTRIBUTING.md` 참고)
|
||||
2. 위 용어집을 따라 문체를 일관되게 유지합니다
|
||||
3. 직역이 아니라 자연스러운 한국어로 번역합니다
|
||||
4. 구조 요소(블록 A-F, 표, 코드블록, 도구 지시문)는 그대로 유지합니다
|
||||
5. 실제 한국어 채용 공고(원티드, 리멤버, 잡코리아, 사람인, LinkedIn KR 등)로 테스트한 뒤 PR을 보냅니다
|
||||
@@ -0,0 +1,204 @@
|
||||
# 공통 컨텍스트 -- career-ops (한국어)
|
||||
|
||||
<!-- ============================================================
|
||||
사용 전 개인 설정 안내
|
||||
============================================================
|
||||
이 파일은 한국어 career-ops 모드 전체에서 공유하는 컨텍스트입니다.
|
||||
career-ops를 사용하기 전에 반드시 다음을 준비하세요.
|
||||
1. config/profile.yml에 개인 정보를 입력
|
||||
2. 프로젝트 루트에 cv.md 생성 (Markdown CV)
|
||||
3. (선택) article-digest.md에 proof point 정리
|
||||
4. 아래 [개인화] 표시가 있는 섹션을 자신의 상황에 맞게 조정
|
||||
============================================================ -->
|
||||
|
||||
## Source of Truth (매 평가 전 항상 읽기)
|
||||
|
||||
| 파일 | 경로 | 언제 |
|
||||
|------|------|------|
|
||||
| cv.md | `cv.md` (프로젝트 루트) | 항상 |
|
||||
| article-digest.md | `article-digest.md` (있다면) | 항상 (상세 proof point) |
|
||||
| profile.yml | `config/profile.yml` | 항상 (신원 정보와 목표 역할) |
|
||||
|
||||
**규칙: proof point의 metric을 절대 하드코딩하지 않습니다.** 평가 시점에 `cv.md`와 `article-digest.md`에서 읽습니다.
|
||||
**규칙: article/project metric은 `article-digest.md`가 `cv.md`보다 우선합니다** (`cv.md`에는 더 오래된 수치가 있을 수 있음).
|
||||
|
||||
---
|
||||
|
||||
## North Star -- 목표 역할
|
||||
|
||||
이 skill은 모든 목표 역할을 같은 비중으로 다룹니다. primary/secondary 구분은 없습니다. 보상과 성장 가능성이 맞다면 각 역할은 모두 성공입니다.
|
||||
|
||||
| Archetype | 주제 축 | 회사가 구매하는 가치 |
|
||||
|-----------|---------|----------------------|
|
||||
| **AI Platform / LLMOps Engineer** | Evaluation, Observability, Reliability, Pipelines | metric 기반으로 AI를 production에 올리는 사람 |
|
||||
| **Agentic Workflows / Automation** | HITL, Tooling, Orchestration, Multi-Agent | 신뢰할 수 있는 agent system을 만드는 사람 |
|
||||
| **Technical AI Product Manager** | GenAI/Agents, PRDs, Discovery, Delivery | business 요구를 AI product로 번역하는 사람 |
|
||||
| **AI Solutions Architect** | Hyperautomation, Enterprise, Integrations | end-to-end AI architecture를 설계하는 사람 |
|
||||
| **AI Forward Deployed Engineer** | Client-facing, Fast delivery, Prototyping | 고객 현장에서 AI solution을 빠르게 배포하는 사람 |
|
||||
| **AI Transformation Lead** | Change management, Adoption, Enablement | 조직의 AI transformation을 이끄는 사람 |
|
||||
|
||||
<!-- [개인화] 위 archetype을 자신의 목표 역할에 맞게 조정하세요.
|
||||
Backend engineering 예시:
|
||||
- Senior Backend Engineer
|
||||
- Staff Platform Engineer
|
||||
- Engineering Manager
|
||||
등 -->
|
||||
|
||||
### Archetype별 adaptive framing
|
||||
|
||||
> **구체적인 수치는 평가 시점에 `cv.md`와 `article-digest.md`에서 읽습니다. 이 파일에 고정값으로 적어두지 마세요.**
|
||||
|
||||
| 역할이... | 후보자에게서 강조할 것 | Proof point source |
|
||||
|-----------|------------------------|--------------------|
|
||||
| Platform / LLMOps | production 경험, observability, evals, closed-loop | article-digest.md + cv.md |
|
||||
| Agentic / Automation | multi-agent orchestration, HITL, reliability, cost | article-digest.md + cv.md |
|
||||
| Technical AI PM | product discovery, PRD, metric, stakeholder management | cv.md + article-digest.md |
|
||||
| Solutions Architect | system design, integration, enterprise readiness | article-digest.md + cv.md |
|
||||
| Forward Deployed Engineer | 빠른 delivery, 고객 접점, prototype to production | cv.md + article-digest.md |
|
||||
| AI Transformation Lead | change management, team enablement, adoption | cv.md + article-digest.md |
|
||||
|
||||
<!-- [개인화] 자신의 구체적인 project/article을 위 archetype에 연결하세요. -->
|
||||
|
||||
### 전환 narrative (모든 framing에 사용)
|
||||
|
||||
<!-- [개인화] 자신의 narrative로 바꾸세요. 예:
|
||||
- "5년간 SaaS를 만들고 매각. 이제 enterprise applied AI에 100% 집중."
|
||||
- "Series-B에서 x10 성장기를 겪은 engineering lead. 다음 도전을 찾는 중."
|
||||
- "컨설팅에서 product로 전환. 높은 책임 범위의 역할을 찾는 중."
|
||||
config/profile.yml -> narrative.exit_story에서 읽음 -->
|
||||
|
||||
모든 콘텐츠에서 `config/profile.yml`의 전환 narrative를 사용해 framing합니다.
|
||||
- **PDF summary:** 과거와 미래를 연결합니다 -- "이제 같은 [역량]을 [공고의 domain]에 적용합니다."
|
||||
- **STAR story:** `article-digest.md`의 proof point를 참조합니다.
|
||||
- **답변 초안(블록 G):** 전환 narrative는 첫 답변에 넣습니다.
|
||||
- **공고가 "entrepreneurial", "autonomy", "builder", "end-to-end"를 언급할 때:** 이것이 핵심 차별점입니다. match weight를 높입니다.
|
||||
|
||||
### Cross-cutting advantage
|
||||
|
||||
프로필을 **"실제 실행 경험을 가진 technical builder"**로 framing하고, 역할에 맞게 조정합니다.
|
||||
- PM: "prototype으로 불확실성을 줄이고 discipline 있게 production까지 전달하는 builder"
|
||||
- FDE: "day 1부터 observability와 metric을 갖춰 delivery하는 builder"
|
||||
- SA: "실제 integration 경험으로 end-to-end system을 설계하는 builder"
|
||||
- LLMOps: "closed-loop quality system으로 AI를 production에 올리는 builder"
|
||||
|
||||
"Builder"를 전문성의 신호로 positioning합니다. "그냥 이것저것 만드는 사람"처럼 보이면 안 됩니다. 실제 proof point가 credibility를 만듭니다.
|
||||
|
||||
### Portfolio as proof point (중요 지원에 사용)
|
||||
|
||||
<!-- [개인화] live demo, dashboard, public project가 있다면 여기에 설정하세요.
|
||||
예:
|
||||
dashboard:
|
||||
url: "https://yourdomain.dev/demo"
|
||||
password: "demo-2026"
|
||||
when_to_share: "LLMOps, AI Platform, Observability roles"
|
||||
config/profile.yml -> narrative.proof_points 및 narrative.dashboard에서 읽음 -->
|
||||
|
||||
후보자에게 live demo / dashboard가 있다면(`profile.yml` 확인), 관련성 높은 지원에서 접근 정보를 제안합니다.
|
||||
|
||||
### 보상 정보 (Comp Intelligence)
|
||||
|
||||
<!-- [개인화] 목표 역할의 보상 범위를 조사해 값을 조정하세요. -->
|
||||
|
||||
**일반 가이드:**
|
||||
- 현재 시장 데이터는 WebSearch로 확인합니다(원티드, 리멤버, 잡플래닛, 블라인드, Levels.fyi, Glassdoor 등).
|
||||
- 직무 title 기준으로 framing합니다. salary band는 보통 skill보다 title이 정의합니다.
|
||||
- 한국에서는 base salary, performance bonus, stock option/RSU, signing bonus, welfare benefit이 섞여 제시될 수 있으므로 total compensation을 분해해서 봅니다.
|
||||
- remote role의 geo-arbitrage는 가능하지만, 일부 회사는 한국 거주 여부, 시차, 고용 형태(EOR/contractor)를 기준으로 보상을 조정할 수 있습니다.
|
||||
|
||||
### 한국 채용 시장 -- 특이사항 (중요)
|
||||
|
||||
한국어 공고와 협상에서는 EN/ES 시장과 다른 용어가 등장합니다. 반드시 정확히 반영하세요.
|
||||
|
||||
| 용어 | 의미 | 평가 영향 |
|
||||
|------|------|-----------|
|
||||
| **정규직** | 기간의 정함이 없는 고용 형태 | senior tech role의 기본값. 계약직이면 이유와 전환 가능성 확인 |
|
||||
| **계약직** | 기간이 정해진 고용 형태 | 특정 project/전환형이면 가능. 기간, 연장/전환 가능성, 종료 리스크 확인 |
|
||||
| **수습기간** | 보통 3개월. 일부 회사는 급여 감액 조건을 둠 | 급여 100% 지급 여부, 평가 기준, 해고 조건 확인 |
|
||||
| **포괄임금제** | 연장/야간/휴일근로 수당을 연봉에 포함하는 구조 | 근무시간 리스크. 고정 OT 시간과 실제 야근 culture 확인 |
|
||||
| **퇴직금** | 1년 이상 근무 시 발생하는 법정 퇴직급여 | 연봉에 포함/별도 표현이 혼동될 수 있으므로 확인 |
|
||||
| **4대 보험** | 국민연금, 건강보험, 고용보험, 산재보험 | 정규직/계약직의 기본 위생 요건. 프리랜서는 다를 수 있음 |
|
||||
| **세전 연봉** | 세금/보험료 공제 전 연봉 | 한국 연봉 협상은 보통 세전 기준. 실수령액과 구분 |
|
||||
| **성과급 / 인센티브** | 개인/회사 성과에 따른 변동 보상 | target, payout history, 지급 조건 확인 |
|
||||
| **스톡옵션 / RSU** | equity compensation | vesting schedule, exercise price, liquidity 가능성 확인 |
|
||||
| **사이닝 보너스** | 입사 보너스 | clawback 조건이 있는지 확인 |
|
||||
| **연차 / 유급휴가** | 근로기준법상 유급휴가 | 최소 기준 미달은 red flag. 사용 문화도 중요 |
|
||||
| **식대 / 복지포인트** | 현금성 또는 준현금성 복지 | 작은 항목이지만 total package 비교에 포함 |
|
||||
| **재택근무** | 원격 근무 | "가능"과 "상시 가능"은 다릅니다. 출근 빈도 확인 |
|
||||
| **하이브리드 근무** | 재택 + 오피스 출근 혼합 | 주 n회 출근, team day, 지역 제한 확인 |
|
||||
| **프리랜서 / 개인사업자** | 고용계약이 아닌 용역/위탁 계약 | rate, 세금, 보험, 계약 종료 리스크를 별도로 평가 |
|
||||
|
||||
### 협상 스크립트
|
||||
|
||||
<!-- [개인화] 자신의 상황에 맞게 조정하세요. -->
|
||||
|
||||
**희망 연봉 (일반 framework):**
|
||||
> "이 역할의 시장 기준과 제 경험 범위를 고려하면, 저는 [profile.yml의 범위] 수준을 기대하고 있습니다. 다만 base, bonus, equity, 복지까지 포함한 전체 보상 패키지 기준으로 유연하게 논의할 수 있습니다."
|
||||
|
||||
**지역 기반 discount에 대한 답변:**
|
||||
> "제가 비교 중인 역할들은 location보다 delivery와 impact를 기준으로 평가합니다. 제 track record는 근무지와 관계없이 동일하게 적용됩니다."
|
||||
|
||||
**제안이 목표보다 낮을 때:**
|
||||
> "현재 [더 높은 범위] 수준의 package를 기준으로 논의 중입니다. [회사]에는 [구체적 이유] 때문에 관심이 큽니다. [목표 금액/구조]까지 맞출 수 있을까요?"
|
||||
|
||||
**성과급 / equity 협상:**
|
||||
> "공정하게 비교하려면 base salary, target bonus, equity/stock option, signing bonus를 나눠서 보고 싶습니다. 각 항목의 지급 조건과 과거 payout range도 확인할 수 있을까요?"
|
||||
|
||||
### Location Policy
|
||||
|
||||
<!-- [개인화] 자신의 상황에 맞게 조정하세요. config/profile.yml -> location에서 읽음 -->
|
||||
|
||||
**지원서 폼에서:**
|
||||
- "출근 가능 여부" 같은 binary 질문: `profile.yml`의 실제 availability에 따라 답합니다.
|
||||
- 자유 입력 필드: 시차 overlap, 출근 가능 빈도, 지역 제한을 명확히 씁니다.
|
||||
|
||||
**평가 scoring에서:**
|
||||
- 국내 하이브리드인데 출근 빈도가 불명확하면 remote dimension을 **3.0**으로 둡니다.
|
||||
- Score 1.0은 공고가 "주 4-5일 필수 출근, 예외 없음"처럼 명시할 때만 사용합니다.
|
||||
|
||||
### Time-to-offer priority
|
||||
- 작동하는 demo + metric > 완벽함
|
||||
- 더 많이 조사하기보다 빠르게 지원
|
||||
- 80/20 접근, 모든 작업은 timebox
|
||||
|
||||
---
|
||||
|
||||
## 전역 규칙
|
||||
|
||||
### 절대 하지 말 것
|
||||
|
||||
1. 경험이나 metric을 지어내기
|
||||
2. `cv.md` 또는 portfolio 파일을 임의로 수정하기
|
||||
3. 후보자 대신 지원서를 제출하기
|
||||
4. 생성 메시지에 전화번호 공유하기
|
||||
5. 시장가보다 낮은 보상을 추천하기
|
||||
6. 공고를 읽기 전에 PDF 생성하기
|
||||
7. 공허한 corporate jargon 사용하기
|
||||
8. tracker 무시하기 (평가한 모든 공고는 기록)
|
||||
|
||||
### 항상 할 것
|
||||
|
||||
0. **커버레터:** 폼이 허용하면 항상 포함합니다. CV와 같은 visual design의 PDF. 공고 문구를 proof point와 매핑. 최대 1페이지.
|
||||
1. 공고 평가 전 `cv.md`와 `article-digest.md`(있다면)를 읽습니다.
|
||||
1b. **세션 첫 평가:** Bash로 `node cv-sync-check.mjs`를 실행합니다. 경고가 있으면 후보자에게 알립니다.
|
||||
2. 역할 archetype을 감지하고 framing을 조정합니다.
|
||||
3. matching 시 CV의 정확한 문장을 인용합니다.
|
||||
4. 보상/회사 데이터에는 WebSearch를 사용합니다.
|
||||
5. 매 평가 후 tracker에 기록합니다.
|
||||
6. 생성 콘텐츠는 공고 언어에 맞춥니다(한국어 공고면 한국어, 영어 공고면 영어).
|
||||
7. 직접적이고 구체적으로 씁니다. 불필요한 말은 줄입니다.
|
||||
8. 한국 테크 채용 문맥에 맞는 자연스러운 한국어를 사용합니다. 짧은 문장, 동사 중심, 수동태 회피. stack, pipeline, deployment, embedding 같은 현장 용어는 억지로 번역하지 않습니다.
|
||||
8b. **PDF Professional Summary의 case study URL:** PDF가 case study나 demo를 언급하면 URL은 반드시 첫 문단(Professional Summary)에 들어갑니다. recruiter는 summary만 읽는 경우가 많습니다. HTML에서는 모든 URL에 `white-space: nowrap` 적용.
|
||||
9. **Tracker entry는 TSV로 작성** -- 새 항목을 위해 applications.md를 직접 수정하지 않습니다. `batch/tracker-additions/`에 TSV를 쓰고 `merge-tracker.mjs`가 병합합니다.
|
||||
10. **모든 report header에 `**URL:**` 포함** -- Score와 PDF 사이에 둡니다.
|
||||
|
||||
### 도구
|
||||
|
||||
| 도구 | 용도 |
|
||||
|------|------|
|
||||
| WebSearch | 보상, 시장 trend, 회사 culture, LinkedIn contact, 공고 fallback 조사 |
|
||||
| WebFetch | 정적 페이지의 공고 추출 fallback |
|
||||
| Playwright | 공고 활성 여부 확인(browser_navigate + browser_snapshot), SPA에서 공고 추출. **중요: Playwright를 쓰는 agent를 2개 이상 병렬로 띄우지 않습니다 -- 같은 browser instance를 공유합니다** |
|
||||
| Read | cv.md, article-digest.md, cv-template.html |
|
||||
| Write | PDF용 임시 HTML, applications.md, reports .md |
|
||||
| Edit | tracker 업데이트 |
|
||||
| Bash | `node generate-pdf.mjs` |
|
||||
@@ -0,0 +1,164 @@
|
||||
# 모드: gonggo -- 전체 평가 A-F
|
||||
|
||||
후보자가 채용 공고(텍스트 또는 URL)를 붙여넣으면 항상 6개 블록을 제공합니다.
|
||||
|
||||
## Step 0 -- Archetype 감지
|
||||
|
||||
공고를 6개 archetype 중 하나로 분류합니다(`_shared.md` 참고). 하이브리드 역할이면 가장 가까운 2개를 표시합니다. 이 분류는 다음을 결정합니다.
|
||||
- 블록 B에서 우선순위를 둘 proof point
|
||||
- 블록 E에서 summary를 다시 쓰는 방식
|
||||
- 블록 F에서 준비할 STAR story
|
||||
|
||||
## 블록 A -- 역할 요약
|
||||
|
||||
다음 항목이 포함된 표를 작성합니다.
|
||||
- 감지된 archetype
|
||||
- 도메인 (Platform / Agentic / LLMOps / ML / Enterprise)
|
||||
- 기능 (Build / Consulting / Management / Deploy)
|
||||
- Seniority
|
||||
- Remote (Full remote / Hybrid / On-site)
|
||||
- 팀 규모(언급된 경우)
|
||||
- 한 문장 TL;DR
|
||||
|
||||
## 블록 B -- CV와의 매치
|
||||
|
||||
`cv.md`를 읽습니다. 공고의 각 자격 요건을 CV의 정확한 문장과 매핑한 표를 만듭니다.
|
||||
|
||||
**Archetype에 맞게 조정:**
|
||||
- FDE -> 빠른 delivery와 고객 접점 proof point 우선
|
||||
- SA -> 시스템 설계와 integration 우선
|
||||
- PM -> product discovery와 metric 우선
|
||||
- LLMOps -> evals, observability, pipeline 우선
|
||||
- Agentic -> multi-agent, HITL, orchestration 우선
|
||||
- Transformation -> change management, adoption, scale-up 우선
|
||||
|
||||
**Gaps** 섹션을 만들고 각 gap에 대한 mitigation 전략을 제시합니다. 각 gap마다 다음을 판단합니다.
|
||||
1. hard blocker인가, nice-to-have인가?
|
||||
2. 후보자가 인접 경험으로 증명할 수 있는가?
|
||||
3. 이 gap을 커버하는 portfolio project가 있는가?
|
||||
4. 구체적인 mitigation plan은 무엇인가? (커버레터 문장, 빠른 mini-project 등)
|
||||
|
||||
## 블록 C -- 레벨과 전략
|
||||
|
||||
1. 공고에서 감지된 **레벨** vs 해당 archetype에서 후보자의 **자연스러운 레벨**
|
||||
2. **"거짓 없이 senior로 포지셔닝하기" 계획**: archetype에 맞춘 구체적인 표현, 강조할 실제 성과, founder 경험을 장점으로 배치하는 방법
|
||||
3. **"downlevel될 경우" 계획**: 보상이 적절하면 수락, 6개월 리뷰 협상, 명확한 promotion criteria 요구
|
||||
|
||||
## 블록 D -- 보상과 시장 수요
|
||||
|
||||
WebSearch를 사용합니다.
|
||||
- 해당 역할의 현재 연봉 범위(원티드, 리멤버, 잡플래닛, 블라인드, Levels.fyi, Glassdoor 등)
|
||||
- 회사의 보상 평판(가능한 경우)
|
||||
- 한국/아시아 또는 해당 시장에서 역할 수요 추세
|
||||
|
||||
데이터와 출처를 표로 정리합니다. 데이터가 없으면 명확히 없다고 말합니다. 절대 지어내지 않습니다.
|
||||
|
||||
**한국 시장 -- 필수 확인 사항:**
|
||||
- 세전 연봉 기준인가? 월급/연봉/총보상 기준이 섞여 있지 않은가?
|
||||
- 성과급, 인센티브, 사이닝 보너스가 별도로 언급되어 있는가?
|
||||
- 스톡옵션, RSU, 지분 보상이 있는가? vesting 조건은 명시되어 있는가?
|
||||
- 정규직인가 계약직인가? 계약직이면 기간, 전환 가능성, 계약 종료 리스크를 확인합니다.
|
||||
- 수습기간이 있는가? 기간과 급여 차감 여부가 명시되어 있는가?
|
||||
- 포괄임금제, 고정 OT, 야근/휴일근무 조건이 언급되어 있는가?
|
||||
- 퇴직금, 4대 보험, 연차/휴가, 식대/복지포인트 등 기본 복지가 명시되어 있는가?
|
||||
- 재택/하이브리드라면 실제 출근 빈도와 지역 제한이 명확한가?
|
||||
|
||||
## 블록 E -- 개인화 계획
|
||||
|
||||
| # | Section | Current state | Proposed change | Rationale |
|
||||
|---|---------|---------------|-----------------|-----------|
|
||||
| 1 | Summary | ... | ... | ... |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
매치를 극대화하기 위한 Top 5 CV 수정 + Top 5 LinkedIn 수정 제안을 제공합니다.
|
||||
|
||||
## 블록 F -- 면접 준비 계획
|
||||
|
||||
공고의 자격 요건에 매핑한 6-10개 STAR+R story를 준비합니다 (STAR + **Reflection**).
|
||||
|
||||
| # | 공고 자격 요건 | STAR+R story | S | T | A | R | Reflection |
|
||||
|---|----------------|--------------|---|---|---|---|------------|
|
||||
|
||||
**Reflection** 열은 무엇을 배웠는지 또는 다시 한다면 무엇을 다르게 할지를 담습니다. 이는 seniority를 보여주는 신호입니다. junior는 무슨 일이 있었는지를 설명하고, senior는 그 경험에서 무엇을 배웠는지까지 설명합니다.
|
||||
|
||||
**Story Bank:** `interview-prep/story-bank.md`가 있으면 해당 story들이 이미 있는지 확인합니다. 없으면 새 story를 추가합니다. 시간이 지나면 어떤 면접 질문에도 재사용 가능한 5-10개의 master story bank가 만들어집니다.
|
||||
|
||||
**Archetype에 맞춰 선택하고 framing합니다:**
|
||||
- FDE -> delivery 속도와 고객 접점을 강조
|
||||
- SA -> architecture decision을 강조
|
||||
- PM -> discovery와 trade-off를 강조
|
||||
- LLMOps -> metric, eval, production hardening을 강조
|
||||
- Agentic -> orchestration, error handling, HITL을 강조
|
||||
- Transformation -> adoption과 조직 변화 관리를 강조
|
||||
|
||||
추가로 포함합니다.
|
||||
- 추천 case study 1개(어떤 프로젝트를 어떻게 보여줄지)
|
||||
- red-flag 질문과 답변 전략 (예: "왜 회사를 매각했나요?", "직접 관리한 팀이 있었나요?", "왜 짧은 기간 후 전환하려 하나요?")
|
||||
|
||||
---
|
||||
|
||||
## 평가 후 작업
|
||||
|
||||
블록 A-F 이후 항상 실행합니다.
|
||||
|
||||
### 1. report .md 저장
|
||||
|
||||
전체 평가를 `reports/{###}-{company-slug}-{YYYY-MM-DD}.md`에 저장합니다.
|
||||
|
||||
- `{###}` = 다음 순차 번호(3자리, zero-padded). 동시성 문제를 피하기 위해 반드시 `node reserve-report-num.mjs`를 실행해 번호를 예약합니다(stdout이 `{###}`를 반환). report를 작성한 뒤 `node reserve-report-num.mjs --release {###}`를 실행해 sentinel을 해제합니다.
|
||||
- `{company-slug}` = 회사명을 소문자와 하이픈으로 만든 slug
|
||||
- `{YYYY-MM-DD}` = 오늘 날짜
|
||||
|
||||
**Report format:**
|
||||
|
||||
```markdown
|
||||
# Evaluation : {Company} -- {Role}
|
||||
|
||||
**Date:** {YYYY-MM-DD}
|
||||
**Archetype:** {detected}
|
||||
**Score:** {X/5}
|
||||
**URL:** {job URL}
|
||||
**PDF:** {path or pending}
|
||||
|
||||
---
|
||||
|
||||
## A) 역할 요약
|
||||
(블록 A 전체 내용)
|
||||
|
||||
## B) CV와의 매치
|
||||
(블록 B 전체 내용)
|
||||
|
||||
## C) 레벨과 전략
|
||||
(블록 C 전체 내용)
|
||||
|
||||
## D) 보상과 시장 수요
|
||||
(블록 D 전체 내용)
|
||||
|
||||
## E) 개인화 계획
|
||||
(블록 E 전체 내용)
|
||||
|
||||
## F) 면접 준비 계획
|
||||
(블록 F 전체 내용)
|
||||
|
||||
## G) 지원서 답변 초안
|
||||
(score >= 4.5일 때만 -- 지원서 폼 답변 초안)
|
||||
|
||||
---
|
||||
|
||||
## 추출한 키워드
|
||||
(ATS 최적화를 위한 공고 키워드 15-20개)
|
||||
```
|
||||
|
||||
### 2. tracker 추가 항목 작성
|
||||
|
||||
새 tracker row를 위해 `data/applications.md`를 직접 수정하지 않습니다. 평가마다 `batch/tracker-additions/{num}-{company-slug}.tsv`에 TSV 한 줄을 쓰고, 이후 `node merge-tracker.mjs`로 병합합니다.
|
||||
|
||||
**TSV format (status before score):**
|
||||
|
||||
```text
|
||||
{num}\t{date}\t{company}\t{role}\tEvaluated\t{score}/5\t{pdf}\t[{num}](reports/{num}-{company-slug}-{date}.md)\t{note}
|
||||
```
|
||||
|
||||
- `pdf`는 PDF가 생성되면 `✅`, 아니면 `❌`
|
||||
- report 링크는 root-relative로 작성합니다: `[001](reports/001-company-2026-01-01.md)`
|
||||
- 이미 같은 company + role이 있으면 새 row를 만들지 말고 기존 entry 업데이트 흐름을 따릅니다.
|
||||
@@ -0,0 +1,115 @@
|
||||
# 모드: jiwon -- 지원서 작성 live assistant
|
||||
|
||||
후보자가 Chrome에서 지원서 폼을 작성하는 순간 사용하는 interactive mode입니다. 화면에 보이는 내용을 읽고, 이전에 평가한 채용 공고의 context를 불러온 뒤, 폼의 각 질문에 맞는 개인화 답변을 생성합니다.
|
||||
|
||||
## 사전 조건
|
||||
|
||||
- **Visible Playwright가 가장 이상적**: visible mode에서는 후보자가 브라우저를 직접 볼 수 있고, Claude가 페이지와 상호작용할 수 있습니다.
|
||||
- **Playwright 없이 진행하는 경우**: 후보자가 스크린샷을 공유하거나 질문을 직접 붙여넣습니다.
|
||||
|
||||
## Workflow
|
||||
|
||||
```text
|
||||
1. DETECT -> 활성 Chrome 탭 읽기 (스크린샷/URL/title)
|
||||
2. IDENTIFY -> 페이지에서 회사 + 역할 추출
|
||||
3. SEARCH -> reports/ 안의 기존 report와 매칭
|
||||
4. LOAD -> 전체 report + 블록 G(있다면) 읽기
|
||||
5. COMPARE -> 화면의 역할이 평가한 역할과 같은지 확인. 바뀌었다면 알림
|
||||
6. ANALYZE -> 화면에 보이는 모든 지원서 질문 식별
|
||||
7. GENERATE -> 각 질문에 대해 개인화 답변 생성
|
||||
8. PRESENT -> 복사/붙여넣기 가능한 형식으로 답변 표시
|
||||
```
|
||||
|
||||
## Step 1 -- 공고 감지
|
||||
|
||||
**Playwright 사용 시:** 활성 페이지 snapshot을 뜹니다. title, URL, 보이는 내용을 읽습니다.
|
||||
|
||||
**Playwright 없이 진행 시:** 후보자에게 다음 중 하나를 요청합니다.
|
||||
- 지원서 폼 스크린샷 공유 (Read tool이 이미지를 읽을 수 있음)
|
||||
- 또는 지원서 질문을 텍스트로 붙여넣기
|
||||
- 또는 회사 + 역할을 알려주면 context를 검색
|
||||
|
||||
## Step 2 -- context 식별 및 불러오기
|
||||
|
||||
1. 페이지에서 회사명과 역할명을 추출합니다.
|
||||
2. `reports/`에서 회사명으로 검색합니다 (case-insensitive grep).
|
||||
3. 매칭되는 report가 있으면 전체 report를 불러옵니다.
|
||||
4. 블록 G가 있으면 이전 답변 초안을 base로 불러옵니다.
|
||||
5. 매칭되는 report가 없으면 후보자에게 알리고 빠른 auto-pipeline 실행을 제안합니다.
|
||||
|
||||
## Step 3 -- 역할 변경 감지
|
||||
|
||||
화면의 역할이 평가한 역할과 다르면:
|
||||
- **후보자에게 알림**: "역할이 [X]에서 [Y]로 바뀐 것 같습니다. 새 역할로 다시 평가할까요, 아니면 새 title에 맞춰 답변만 조정할까요?"
|
||||
- **조정 선택 시**: 재평가 없이 새 역할에 맞춰 답변을 조정합니다.
|
||||
- **재평가 선택 시**: 전체 A-F 평가를 실행하고, report를 업데이트하고, 블록 G를 다시 생성합니다.
|
||||
- **tracker 업데이트**: 필요한 경우 `applications.md`의 역할명을 수정합니다.
|
||||
|
||||
## Step 4 -- 지원서 질문 분석
|
||||
|
||||
화면에 보이는 모든 질문을 식별합니다.
|
||||
- 자유 입력 필드 (커버레터, "왜 이 역할인가요", 지원 동기 등)
|
||||
- 드롭다운 (어디서 공고를 봤는지, 근무 자격 등)
|
||||
- Yes/No 질문 (이직 가능 여부, 비자, 근무 가능 지역 등)
|
||||
- 연봉 입력 필드 (희망 연봉, range, 총보상 기대치)
|
||||
- 업로드 필드 (CV, 커버레터 PDF, 추천인 등)
|
||||
|
||||
각 질문을 분류합니다.
|
||||
- **이미 블록 G에서 답변한 질문** -> 기존 답변을 가져와 조정
|
||||
- **새 질문** -> report + `cv.md`를 바탕으로 답변 생성
|
||||
|
||||
## Step 5 -- 답변 생성
|
||||
|
||||
각 질문에 대해 다음 구조로 답변을 만듭니다.
|
||||
|
||||
1. **Report context**: 블록 B의 proof point와 블록 F의 STAR story 사용
|
||||
2. **이전 블록 G**: 기존 초안이 있으면 base로 가져와 다듬기
|
||||
3. **"제가 귀사를 선택합니다" 톤**: auto-pipeline과 같은 framework 사용 -- 자신감 있게, 애원하지 않게
|
||||
4. **구체성**: 화면에 보이는 공고 내용 중 구체적인 요소 언급
|
||||
5. **career-ops proof point**: "추가 정보" 같은 필드가 있으면 포함
|
||||
|
||||
**한국 지원서 폼에서 자주 나오는 필드:**
|
||||
- **희망 연봉 / 처우** -> `profile.yml`의 range를 사용. 세전 연봉 기준인지 명확히 쓰고, "전체 보상 패키지에 따라 협의 가능"이라고 덧붙임
|
||||
- **입사 가능일** -> 현재 재직/퇴사 통보 기간을 고려한 현실적인 날짜
|
||||
- **근무 가능 지역 / 출근 가능 여부** -> 실제 가능한 지역과 출근 빈도를 명확히 작성
|
||||
- **비자 / 근무 자격** -> 사실에 맞게 간결히 답변
|
||||
- **언어 능력** -> 실제 수준에 맞춰 작성. 필요하면 CEFR 또는 비즈니스/실무 가능 수준으로 표현
|
||||
- **포트폴리오 / GitHub / 블로그** -> `profile.yml`, `cv.md`, `article-digest.md`에 있는 검증된 링크만 사용
|
||||
|
||||
**출력 형식:**
|
||||
|
||||
```text
|
||||
## [회사] -- [역할] 지원서 답변
|
||||
|
||||
Base: Report #NNN | Score: X.X/5 | Archetype: [type]
|
||||
|
||||
---
|
||||
|
||||
### 1. [지원서의 정확한 질문]
|
||||
> [바로 복사/붙여넣기 가능한 답변]
|
||||
|
||||
### 2. [다음 질문]
|
||||
> [답변]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
Notes:
|
||||
- [역할 변경, 공고 관련 관찰 등]
|
||||
- [후보자가 직접 확인해야 할 개인화 포인트]
|
||||
```
|
||||
|
||||
## Step 6 -- 지원 후 처리 (선택)
|
||||
|
||||
후보자가 지원서를 제출했다고 확인하면:
|
||||
1. tracker status 변경은 `data/applications.md`를 직접 수정하지 않습니다. `batch/tracker-additions/`에 `Applied` 상태의 TSV update를 쓰고 `node merge-tracker.mjs`로 병합합니다.
|
||||
2. 최종 답변을 report의 블록 G에 업데이트합니다.
|
||||
3. 다음 단계로 `/career-ops contacto`를 제안해 hiring manager 또는 recruiter에게 LinkedIn outreach를 할 수 있게 합니다.
|
||||
|
||||
## 스크롤 처리
|
||||
|
||||
지원서 폼에 화면에 보이는 것보다 질문이 더 많으면:
|
||||
- 후보자에게 아래로 스크롤한 뒤 다른 스크린샷을 공유해달라고 요청합니다.
|
||||
- 또는 남은 질문을 붙여넣어달라고 요청합니다.
|
||||
- 전체 폼을 다룰 때까지 반복해서 처리합니다.
|
||||
@@ -0,0 +1,62 @@
|
||||
# 모드: pipeline -- URL Inbox (Second Brain)
|
||||
|
||||
`data/pipeline.md`에 쌓인 채용 공고 URL을 처리합니다. 후보자는 원할 때 URL을 추가하고, 이후 `/career-ops pipeline`을 실행해 한 번에 처리합니다.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **읽기** `data/pipeline.md` -> "대기" / "Pending" / "Pendientes" 섹션의 `- [ ]` item 찾기
|
||||
2. **각 대기 URL에 대해**:
|
||||
a. `node reserve-report-num.mjs`를 실행해 다음 sequential `REPORT_NUM`을 atomic하게 예약합니다(report 작성 후 `node reserve-report-num.mjs --release <num>`으로 sentinel 해제).
|
||||
b. **공고 추출**: Playwright(`browser_navigate` + `browser_snapshot`) -> WebFetch -> WebSearch
|
||||
c. URL에 접근할 수 없으면 note와 함께 `- [!]`로 표시하고 계속합니다.
|
||||
d. **전체 auto-pipeline 실행**: Evaluation A-F -> Report .md -> PDF(score >= 3.0이면) -> Tracker
|
||||
e. **"대기"에서 "처리 완료"로 이동**: `- [x] #NNN | URL | Company | Role | Score/5 | PDF yes/no`
|
||||
3. **대기 URL이 3개 이상이어도 Playwright-backed 처리는 직렬로 실행합니다.** Playwright browser instance를 공유하므로 여러 browser-backed agent를 동시에 띄우지 않습니다. 병렬화가 필요하면 Playwright를 쓰지 않는 non-browser 작업에만 제한합니다.
|
||||
4. **마지막에** 요약 표를 표시합니다.
|
||||
|
||||
```markdown
|
||||
| # | Company | Role | Score | PDF | Recommended action |
|
||||
```
|
||||
|
||||
## pipeline.md format
|
||||
|
||||
```markdown
|
||||
## 대기
|
||||
- [ ] https://jobs.example.com/posting/123
|
||||
- [ ] https://boards.greenhouse.io/company/jobs/456 | Company Ltd | Senior PM
|
||||
- [!] https://private.url/job -- Error: login required
|
||||
|
||||
## 처리 완료
|
||||
- [x] #143 | https://jobs.example.com/posting/789 | Acme Korea | AI PM | 4.2/5 | PDF yes
|
||||
- [x] #144 | https://boards.greenhouse.io/xyz/jobs/012 | BigCo | SA | 2.1/5 | PDF no
|
||||
```
|
||||
|
||||
> Note: 섹션 heading은 EN("Pending"/"Processed"), ES("Pendientes"/"Procesadas"), DE("Offen"/"Verarbeitet"), FR("En attente"/"Traitees"), KO("대기"/"처리 완료") 모두 유연하게 읽습니다. 쓸 때는 기존 파일의 style을 따릅니다.
|
||||
|
||||
## URL에서 공고를 지능적으로 감지
|
||||
|
||||
1. **Playwright (preferred):** `browser_navigate` + `browser_snapshot`. 모든 SPA에 대응합니다.
|
||||
2. **WebFetch (fallback):** 정적 페이지 또는 Playwright를 사용할 수 없을 때 사용합니다.
|
||||
3. **WebSearch (last resort):** 공고를 index하는 secondary portal에서 검색합니다.
|
||||
|
||||
**특수 케이스:**
|
||||
- **LinkedIn**: login이 필요할 수 있음 -> `[!]`로 표시하고 후보자에게 공고 text를 붙여넣어 달라고 요청
|
||||
- **PDF**: URL이 PDF를 가리키면 Read tool로 직접 읽기
|
||||
- **`local:` prefix**: 로컬 파일 읽기. 예: `local:jds/linkedin-pm-ai.md` -> `jds/linkedin-pm-ai.md` 읽기
|
||||
- **원티드 / 리멤버 / 잡코리아 / 사람인 / LinkedIn KR**: 한국 시장에서 자주 쓰는 portal. cookie banner나 login wall이 있으면 Playwright로 먼저 확인
|
||||
|
||||
## 자동 번호 부여
|
||||
|
||||
1. `node reserve-report-num.mjs`를 실행해 다음 sequential number를 예약합니다(stdout이 `{###}` 반환).
|
||||
2. 해당 번호로 report를 작성합니다.
|
||||
3. report 작성 후 `node reserve-report-num.mjs --release {###}`를 실행해 sentinel을 해제합니다.
|
||||
|
||||
## Source sync
|
||||
|
||||
URL을 처리하기 전에 sync를 확인합니다.
|
||||
|
||||
```bash
|
||||
node cv-sync-check.mjs
|
||||
```
|
||||
|
||||
sync 문제가 있으면 계속하기 전에 후보자에게 알립니다.
|
||||
Reference in new issue
Block a user