Quick Reference

결과를 “더 좋게” 고치게 하기보다, 통과 여부를 사람이 확인할 수 있는 기준을 먼저 정합니다. 기준이 여러 개인 문서·기획·설명 작업에는 초안과 평가를 분리하고, 사실 확인이 필요한 항목은 모델의 자기평가가 아니라 원문과 출처로 판정합니다.

산출물: [무엇을 만들지]
독자: [누가 읽는지]

다음 기준으로 초안을 작성하고 한 번만 수정해줘.
- 정확성: 제공한 자료 밖의 사실은 추가하지 않는다.
- 완결성: [필수 항목]을 모두 포함한다.
- 읽기성: 첫 화면에서 결론과 다음 행동을 알 수 있다.
- 형식: [길이, 제목, 표, 목록 조건]을 지킨다.

출력 순서:
1. 초안
2. 기준별 통과 / 보완 필요와 근거
3. 보완한 최종본
4. 자료가 없어 검증하지 못한 항목

루브릭을 쓰는 경우

루브릭(rubric, 평가 기준표)은 하나의 답에 정확성, 범위, 형식, 독자 수준처럼 서로 다른 조건이 함께 걸릴 때 유용합니다. 예를 들어 비교 문서는 비교 축 누락, 소개 문서는 핵심 행동 누락, 코드 설명은 실행 조건 누락을 각각 잡아낼 수 있습니다. 단순 번역, 한 문장 교정, 정해진 데이터 추출처럼 통과 조건이 하나뿐인 작업에는 별도 루브릭보다 직접적인 출력 계약이 낫습니다.

상황: 팀 공유용 장애 보고 초안
통과 기준:
1. 발생 시각, 영향 범위, 현재 상태가 있다.
2. 원인과 추정은 구분되어 있다.
3. 고객에게 약속하지 않은 복구 시각은 쓰지 않는다.
4. 다음 갱신 시각과 담당자가 있다.

기준은 보통 3~6개가 적당합니다. 너무 많으면 중요한 조건이 일반적인 문체 조건과 섞여 우선순위가 흐려집니다. 반드시 지켜야 하는 항목은 필수, 있으면 좋은 항목은 선호로 구분하고, 충돌하면 무엇을 우선할지 적습니다.

평가와 수정 결과를 분리하기

초안과 최종본만 받으면 무엇이 실제로 개선됐는지 알기 어렵습니다. 기준별 평가를 짧게 분리하면 수정 이유를 추적할 수 있습니다. 다만 모든 기준을 통과했다라는 자기평가를 사실로 받아들이면 안 됩니다. 인용, 숫자, 정책, 파일 반영 여부처럼 외부 근거가 있는 항목은 기준 옆에 확인할 원본을 붙입니다.

각 기준은 "통과"만 쓰지 말고 판단 근거를 한 문장으로 적어줘.
외부 자료와 대조하지 않은 사실은 통과로 선언하지 말고 "미검증"으로 남겨줘.
수정은 한 번으로 제한하고, 남은 결함이 있으면 최종본 뒤에 적어줘.

수정 횟수도 정해 둡니다. 수정과 자기평가를 무한히 반복하면 문체만 계속 바뀌고 핵심 결함은 그대로일 수 있습니다. 한 번 수정한 뒤에는 사람이 기준표를 확인하고, 실제로 부족한 기준만 새 요청에서 좁혀 고칩니다.

자주 틀리는 부분