init: cover-letter-haness 하네스 설계

This commit is contained in:
DongHyeonka
2026-07-24 13:59:24 +09:00
parent bf4ff915a2
commit 1e266f2ae1
20 changed files with 7659 additions and 1 deletions
@@ -0,0 +1,271 @@
# 작성 및 검증 기준
## 목차
1. 작성 원칙
2. 하드 게이트
3. 100점 루브릭
4. 개인 고유성 검사
5. 문체 경고 패턴
6. IT 문장 검증
7. 퇴고 순서
8. 검증 리포트 형식
## 1. 작성 원칙
자연스러운 글은 일부러 불완전하게 만든 글이 아니다. 사용자의 실제 관찰, 선택, 망설임, 실패, 판단 변경, 책임 범위를 남긴 글이다.
다음 우선순위를 적용한다.
```text
사실 정확성
> 사용자 소유권과 공개 안전
> 문항에 대한 직접 답변
> 판단 과정과 구체성
> 사용자 문체
> 매끄러운 표현
```
문법을 다듬을 수 있지만 사실과 인과를 바꾸지 않는다. 사건 순서를 읽기 쉽게 정리할 수 있지만 여러 경험을 합치지 않는다. 정확한 근거가 있을 때만 수치와 강한 인과 표현을 사용한다.
## 2. 하드 게이트
다음 중 하나라도 해당하면 총점과 관계없이 `BLOCK`이다.
| 코드 | 조건 | 처리 |
|---|---|---|
| `F01` | 사용자 입력에 없는 수치·기술·사건·감정 | 삭제하고 사실 질문으로 복귀 |
| `F02` | 수치의 기준·환경·기간 또는 정확성이 불명확 | 근거 확인, 범위·정성 표현으로 완화, 삭제 중 선택 |
| `F03` | 서로 다른 경험을 하나의 사건처럼 합성 | 경험을 분리 |
| `F04` | 행동 단어만 겹치고 결과·대상·한글 수량이 근거에 없음 | 결과 근거를 연결하거나 주장 삭제 |
| `O01` | 팀 결과를 사용자 개인 성과로 단정 | 팀 행동과 사용자 기여 범위 분리 |
| `O02` | 역할·날짜·인원·기술이 자료 사이에서 충돌 | 모순 해소 전 사용 금지 |
| `P01` | 개인정보, 고객 식별자, 비공개 URL, 토큰, 기밀 | 삭제·익명화하고 공개 범위 재확인 |
| `T01` | 회사 관련 해석을 출처 있는 사실처럼 표현 | 출처 확인 또는 지원자 해석으로 낮춤 |
| `Q01` | 문항의 요구 요소 누락 | 개요로 복귀 |
| `Q02` | 글자 수 또는 형식 위반 | 핵심 근거를 보존해 압축·재구성 |
| `A01` | 승인되지 않은 개요 또는 사용 금지 근거 | 초안 생성·확정 중단 |
| `A02` | 승인 개요 밖 근거 또는 한 문장에 여러 경험 합성 | 근거 범위·문단 분리 |
| `A03` | 문항 초안의 본문 문단에 근거 주석이 없거나 연결 ID가 불명확 | 문단마다 정확한 `E/F/V/A/R` ID를 연결 |
| `I01` | 사용자가 면접에서 설명할 수 없는 문장 | 쉬운 본인 표현으로 되돌리거나 삭제 |
| `I02` | `[확인 필요]`, TODO, 보이지 않는 문자, 비정규화 한글 | 작업 표시 삭제·NFC 정규화 후 재검증 |
| `V01` | 승인 뒤 초안 또는 사실 컨텍스트 변경 | 사용자 재검증·재승인 |
`private``blocked`로 지정된 경험은 좋은 소재처럼 보여도 사용하지 않는다. 민감한 경험을 쓰는 것이 유리하다고 설득하지 않는다.
CLI가 의미 겹침을 보수적으로 판정해 자연스러운 동의어를 막을 수 있다. 데모/시연, 멈춤/정지 같은 제한된 별칭은 인식하지만 일반 의미 모델은 아니다. 이 경우 게이트를 끄지 말고 연결 근거와 같은 구체 명사를 한 개 이상 보존하거나, 사용자가 확인한 경험 표현을 수정한다. 반대로 CLI 통과는 진실을 증명하지 않으므로 사람 확인을 생략하지 않는다.
## 3. 100점 루브릭
각 항목을 0~4점으로 평가하고 `배점 × 점수 ÷ 4`로 환산한다.
### 사실성·추적성 — 25점
- 4: 모든 사실이 확인·허용된 근거에 연결되고 수치, 역할, 불확실성이 정확함
- 3: 근거는 있으나 일부 관찰 범위나 기여 표현이 넓음
- 2: 추적하기 어려운 일반화가 여러 개 있음
- 1: 미확인 사실이 핵심 논리를 지탱함
- 0: 생성된 사실이나 명백한 모순이 있음
최종 후보는 반드시 4점이어야 한다.
### 개인 고유성·소유권 — 20점
- 4: 본인이 알아차린 신호, 판단, 선택, 실패, 책임 범위가 분명함
- 3: 행동은 구체적이나 대안이나 판단 변화가 약함
- 2: 상황과 결과는 있으나 누구나 할 법한 행동임
- 1: 역량 선언과 팀 결과가 중심임
- 0: 다른 지원자 이름으로 바꿔도 그대로 성립함
### IT 기술 판단 — 15점
- 4: 문제, 제약, 선택 이유, 대안, 트레이드오프, 검증 방법이 드러남
- 3: 선택 이유와 검증은 있으나 대안 또는 제약이 약함
- 2: 기술을 어떻게 사용했는지만 설명함
- 1: 기술 스택을 나열함
- 0: 실제 사용하지 않은 기술을 주장함
### 가치관·성찰 — 15점
- 4: 반복 행동이나 이후 실제 변화로 가치관이 드러나고 한계도 인식함
- 3: 경험과 가치가 연결되지만 이후 변화가 약함
- 2: “배웠다”는 결론만 있음
- 1: 추상 가치 단어만 있음
- 0: 사용자와 확인하지 않은 모델 해석임
### 직무·공고 정합성 — 10점
- 4: 공고의 핵심 행동과 경험이 직접 연결되고 회사 선택 이유가 구체적임
- 3: 직무 연결은 강하지만 회사 연결이 일반적임
- 2: 공고 표현을 반복하지만 근거 연결이 약함
- 1: 회사명만 바꾼 범용 문장임
- 0: 다른 직무 경험을 억지로 연결함
### 사용자 목소리 — 10점
- 4: 표본의 어휘, 직접성, 설명 깊이, 문장 호흡을 자연스럽게 유지함
- 3: 대체로 맞지만 일부 기업형 표현이 섞임
- 2: 지나치게 매끈하거나 균일하고 사용자 고유 표현이 줄어듦
- 1: 모델 상투어가 지배적임
- 0: 사용자가 본인 말 같지 않다고 판단함
### 문항·구성 준수 — 5점
- 4: 첫 부분부터 질문에 답하고 각 문단 기능과 분량이 명확함
- 3: 답은 충족하지만 배경이 조금 김
- 2: 핵심 답이 후반에 묻힘
- 1: 요구 일부가 누락됨
- 0: 다른 문항에 대한 답임
점수 해석:
- 85~100: 사용자 최종 확인 후 제출 후보
- 70~84: 지적된 사실이나 문단만 재인터뷰·수정
- 70 미만: 표현 수정 대신 경험 수집·개요로 복귀
## 4. 개인 고유성 검사
핵심 문단마다 다음 개인 지문 중 두 개 이상이 있는지 확인한다.
- 문제를 처음 알아차린 신호
- 당시 시간·품질·자원 제약
- 본인이 직접 내린 결정
- 선택하지 않은 대안과 이유
- 맡은 파일·기능·프로세스 범위
- 실패한 시도나 틀린 첫 가설
- 확인 가능한 결과나 관찰 범위
- 이후 실제로 바뀐 습관
- 속도, 품질, 복잡성, 비용 사이의 트레이드오프
다음 검사를 사용자와 함께 수행한다.
- **이름 교체 테스트:** 다른 IT 지원자의 이름을 넣어도 자연스러우면 구체적 행동을 보강한다.
- **회사명 교체 테스트:** 어느 회사에도 통하면 공고의 구체 요구와 개인 선택을 다시 연결한다.
- **2분 설명 테스트:** 핵심 문장을 2분간 설명하지 못하면 지나치게 압축됐거나 본인 경험이 아니다.
- **소유권 테스트:** “팀이 한 일”과 “내가 한 일”을 각각 말할 수 있어야 한다.
- **반대 선택 테스트:** 다른 기술이나 방법을 쓰지 않은 이유를 설명할 수 있어야 한다.
- **행동 변화 테스트:** “배웠다” 뒤에 실제로 달라진 후속 행동이 있어야 한다.
개인 지문이 부족할 때 모델이 장면을 꾸미지 말고 인터뷰로 돌아간다.
## 5. 문체 경고 패턴
다음 표현은 무조건 금지하지 않는다. 사용자 표본에 없고 구체적 행동 없이 사용됐을 때 `WARN`으로 처리한다.
- `귀사`, `끊임없이 성장`, `도전 정신`, `소통 역량`
- `혁신적인 인재`, `무한한 가능성`, `최선을 다하겠습니다`
- `기여하겠습니다`, `역량을 함양했습니다`, `성장할 수 있었습니다`
- 반복되는 `이를 통해`, `이 경험을 통해`, `나아가`
- `단순히 A를 넘어 B`, `A뿐만 아니라 B`
- `문제를 해결했습니다`, `협업했습니다`, `주도했습니다` 뒤에 관찰 가능한 행동이 없는 문장
경고 기준:
- 문장 길이와 문단 길이가 지나치게 균일함
- 모든 문장이 `했습니다`로 끝나고 리듬 변화가 전혀 없음
- 모든 문단이 상황-행동-성과-교훈의 같은 크기로 반복됨
- 모든 경험이 극복과 성공으로만 끝남
- 공고의 형용사와 명사를 그대로 복사함
- 기술명은 많지만 사용 이유와 선택 기준이 없음
- “배웠다”는 교훈이 이후 행동과 연결되지 않음
- 입사 후 계획이 현재 근거 없이 거창함
한국어 자기소개서에서 `했습니다` 반복 자체는 자연스러울 수 있다. 기계적인 종결어미 변환보다 문장마다 하는 일이 다른지 확인한다.
허용되는 편집:
- 사실을 바꾸지 않는 사건 순서 정리
- 사용자 확인을 거친 `약` 또는 범위 표현
- 실명과 내부 식별자의 익명화
- 관련 없는 기술 세부사항 축약
- 문법, 띄어쓰기, 중복 표현 교정
- 전문적인 `합니다체`로 최소한 정돈
- 실제 망설임, 실패, 판단 변경 보존
허용되지 않는 편집:
- 자연스러움을 위한 가상 대화, 감정, 갈등 추가
- 극적인 서사를 위한 경험 합성
- 팀 성과를 개인 성과로 바꾸기
- 탐지기 회피용 오탈자, 랜덤 문장, 보이지 않는 문자, 무작위 동의어 치환
## 6. IT 문장 검증
기술 이름보다 다음 연결이 있는지 확인한다.
```text
문제 신호 → 가설 → 확인 방법 → 선택지 → 결정 이유 → 구현 범위
→ 검증 조건 → 결과 범위 → 이후 작업 방식
```
수치가 있으면 다음을 묻는다.
- 무엇을 측정했는가
- 기준 시점과 비교 시점은 언제인가
- 평균, p95, 성공률, 사용자 수, 요청 수 중 무엇인가
- 측정 기간과 환경은 무엇인가
- 팀 결과 중 사용자 기여 범위는 어디까지인가
- 정확한 기록인가, 대략적인 기억인가
측정하지 않은 결과를 퍼센트로 바꾸지 않는다. `대폭 향상` 같은 표현도 측정 근거가 없으면 “테스트 범위에서 재현되지 않았다”, “반복 작업을 줄였다”처럼 관찰 범위를 정확히 쓰거나 삭제한다.
숫자는 값만 맞으면 충분하지 않다. `%`, `ms`, `MB`, `건`, `명`, `년`처럼 단위와 지표가 같은 세부 `F###`에 있어야 한다. 날짜의 `2025``2025개`를 뒷받침하거나, 팀의 `40%`를 개인 성과로 바꾸지 않는다. `owner_scope=team/shared` 결과는 팀·서비스 결과와 본인 행동을 한 문장 안에서도 구분한다.
## 7. 퇴고 순서
한 번에 전체를 다시 생성하지 않는다.
1. **사실:** 근거 ID, 수치, 역할, 공개 권한, 모순
2. **문항:** 질문에 대한 직접 답, 필수 요소, 회사·직무 연결
3. **구성:** 한 문단 한 기능, 핵심 답 위치, 인과 흐름
4. **개인성:** 판단, 실패, 대안, 이후 행동, 사용자 고유 표현
5. **문체:** 상투어, 관료체, 호흡, 종결 반복
6. **압축:** 배경, 기술 나열, 중복 교훈부터 삭제
7. **낭독:** 사용자가 말할 수 있는 문장인지 확인
사용자가 직접 고친 문장은 사실 오류나 문항 위반이 없는 한 우선 보존한다. 수정안을 낼 때 원문에서 무엇을 왜 바꿨는지 좁게 보여 준다.
## 8. 검증 리포트 형식
```text
판정: 제출 후보 | 수정 필요 | 사실 확인 필요 | 개인정보 차단
하드 게이트:
- PASS 또는 코드별 BLOCK
점수:
- 사실성·추적성: /25
- 개인 고유성·소유권: /20
- IT 기술 판단: /15
- 가치관·성찰: /15
- 직무·공고 정합성: /10
- 사용자 목소리: /10
- 문항·구성 준수: /5
근거 없는 문장:
팀·개인 역할이 모호한 문장:
이름/회사명 교체 테스트 대상:
과장·상투 표현:
개인정보·기밀 위험:
그대로 보존할 사용자 고유 표현:
추가로 필요한 질문:
다음 명령:
```
예시:
```text
BLOCK F02
문장: “응답 시간을 40% 개선했습니다.”
이유: 40%를 뒷받침하는 측정 기준과 기록이 없습니다.
선택:
1. 실제 측정 조건을 추가 확인
2. 확인된 관찰 범위로 표현을 낮춤
3. 해당 문장 삭제
```
하드 게이트와 사람 루브릭을 모두 통과한 뒤 사용자가 사실, 역할, 개인정보, 문항, 말투, 면접 설명 가능성을 확인하면 다음 명령으로 현재 버전을 잠근다.
```bash
./cover-letter approve .cover-letter/drafts/A001-Q001-v1.md --confirm-all
```