init
Release Please / release-please (push) Failing after 4m2s
Web CI / web typecheck + build (push) Successful in 3m39s
CodeQL Analysis / Analyze (javascript-typescript) (push) Failing after 1h1m49s
CodeQL Analysis / Analyze (go) (push) Failing after 1h1m49s

This commit is contained in:
redlineo committed 2026-07-13 10:14:00 +03:00
commit d295c7f139
1527 files changed
+270726

No files matched your search

+107
View File
@@ -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을 보냅니다
+204
View File
@@ -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` |
+164
View File
@@ -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 업데이트 흐름을 따릅니다.
+115
View File
@@ -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를 할 수 있게 합니다.
## 스크롤 처리
지원서 폼에 화면에 보이는 것보다 질문이 더 많으면:
- 후보자에게 아래로 스크롤한 뒤 다른 스크린샷을 공유해달라고 요청합니다.
- 또는 남은 질문을 붙여넣어달라고 요청합니다.
- 전체 폼을 다룰 때까지 반복해서 처리합니다.
+62
View File
@@ -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 문제가 있으면 계속하기 전에 후보자에게 알립니다.