cover-letter-haness/skills/draft-korean-it-cover-letter/references/writing-and-review.md

작성 및 검증 기준

목차

1. 작성 원칙
2. 하드 게이트
3. 100점 루브릭
4. 개인 고유성 검사
5. 문체 경고 패턴
6. IT 문장 검증
7. 퇴고 순서
8. 검증 리포트 형식

1. 작성 원칙

자연스러운 글은 일부러 불완전하게 만든 글이 아니다. 사용자의 실제 관찰, 선택, 망설임, 실패, 판단 변경, 책임 범위를 남긴 글이다.

다음 우선순위를 적용한다.

사실 정확성
  > 사용자 소유권과 공개 안전
  > 문항에 대한 직접 답변
  > 판단 과정과 구체성
  > 사용자 문체
  > 매끄러운 표현

문법을 다듬을 수 있지만 사실과 인과를 바꾸지 않는다. 사건 순서를 읽기 쉽게 정리할 수 있지만 여러 경험을 합치지 않는다. 정확한 근거가 있을 때만 수치와 강한 인과 표현을 사용한다.

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 문장 검증

기술 이름보다 다음 연결이 있는지 확인한다.

문제 신호 → 가설 → 확인 방법 → 선택지 → 결정 이유 → 구현 범위
→ 검증 조건 → 결과 범위 → 이후 작업 방식

수치가 있으면 다음을 묻는다.

• 무엇을 측정했는가
• 기준 시점과 비교 시점은 언제인가
• 평균, p95, 성공률, 사용자 수, 요청 수 중 무엇인가
• 측정 기간과 환경은 무엇인가
• 팀 결과 중 사용자 기여 범위는 어디까지인가
• 정확한 기록인가, 대략적인 기억인가

측정하지 않은 결과를 퍼센트로 바꾸지 않는다. 대폭 향상 같은 표현도 측정 근거가 없으면 “테스트 범위에서 재현되지 않았다”, “반복 작업을 줄였다”처럼 관찰 범위를 정확히 쓰거나 삭제한다.

숫자는 값만 맞으면 충분하지 않다. %, ms, MB, 건, 명, 년처럼 단위와 지표가 같은 세부 F###에 있어야 한다. 날짜의 2025로 2025개를 뒷받침하거나, 팀의 40%를 개인 성과로 바꾸지 않는다. owner_scope=team/shared 결과는 팀·서비스 결과와 본인 행동을 한 문장 안에서도 구분한다.

7. 퇴고 순서

한 번에 전체를 다시 생성하지 않는다.

1. 사실: 근거 ID, 수치, 역할, 공개 권한, 모순
2. 문항: 질문에 대한 직접 답, 필수 요소, 회사·직무 연결
3. 구성: 한 문단 한 기능, 핵심 답 위치, 인과 흐름
4. 개인성: 판단, 실패, 대안, 이후 행동, 사용자 고유 표현
5. 문체: 상투어, 관료체, 호흡, 종결 반복
6. 압축: 배경, 기술 나열, 중복 교훈부터 삭제
7. 낭독: 사용자가 말할 수 있는 문장인지 확인

사용자가 직접 고친 문장은 사실 오류나 문항 위반이 없는 한 우선 보존한다. 수정안을 낼 때 원문에서 무엇을 왜 바꿨는지 좁게 보여 준다.

8. 검증 리포트 형식

판정: 제출 후보 | 수정 필요 | 사실 확인 필요 | 개인정보 차단

하드 게이트:
- PASS 또는 코드별 BLOCK

점수:
- 사실성·추적성: /25
- 개인 고유성·소유권: /20
- IT 기술 판단: /15
- 가치관·성찰: /15
- 직무·공고 정합성: /10
- 사용자 목소리: /10
- 문항·구성 준수: /5

근거 없는 문장:
팀·개인 역할이 모호한 문장:
이름/회사명 교체 테스트 대상:
과장·상투 표현:
개인정보·기밀 위험:
그대로 보존할 사용자 고유 표현:
추가로 필요한 질문:
다음 명령:

예시:

BLOCK F02
문장: “응답 시간을 40% 개선했습니다.”
이유: 40%를 뒷받침하는 측정 기준과 기록이 없습니다.
선택:
1. 실제 측정 조건을 추가 확인
2. 확인된 관찰 범위로 표현을 낮춤
3. 해당 문장 삭제

하드 게이트와 사람 루브릭을 모두 통과한 뒤 사용자가 사실, 역할, 개인정보, 문항, 말투, 면접 설명 가능성을 확인하면 다음 명령으로 현재 버전을 잠근다.

./cover-letter approve .cover-letter/drafts/A001-Q001-v1.md --confirm-all