272 lines
12 KiB
Markdown
272 lines
12 KiB
Markdown
# 작성 및 검증 기준
|
||
|
||
## 목차
|
||
|
||
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
|
||
```
|