1. 한 번에 하나의 원인을 고칩니다

회의록에 소라의 기한이 모집 마감일로 들어갔다고 합시다. 이때 “정확하게 작성하라”를 세 번 추가하는 것은 원인을 설명하지 못합니다. 할 일 기한과 사업 마감일을 구분하라는 규칙이 필요합니다.

1.1 실패 기록 양식

입력: meeting-notes.md
요청: 회의록 정리
기대: 소라 카드 초안 기한 미정
실제: 2026-09-25로 기재
원인 가설: 모집 마감을 담당 업무의 기한으로 잘못 사용
수정: 다른 일정의 날짜를 업무 기한으로 옮기지 않는 규칙 추가
재검사: 원본 및 소라 기한을 명시한 변형 입력

원인은 처음에는 가설입니다. 수정 후 정상 입력과 변형 입력에서 모두 나아졌는지 확인해야 합니다. 명시된 기한까지 무조건 미정으로 만드는 수정은 지나칩니다.

1.2 잘되던 것도 다시 확인하기

회귀 확인은 수정 뒤 기존 정상 사례가 계속 작동하는지 보는 것입니다. 소라의 기한을 고쳤는데 민지와 준호의 명시된 기한까지 사라지면 새 결함이 생긴 것입니다. 원본 회의 메모와 기한을 추가한 메모를 짝으로 보관하면 확인하기 쉽습니다.

견적 계산기를 바꿨다면 정상 총액뿐 아니라 음수와 빈값 오류도 확인합니다. 보고서의 수료 기준을 바꾸면 출석 합계, 참여자 수, 만족도 평균처럼 바뀌면 안 되는 값도 함께 봅니다.

1.3 필요 이상의 지침 줄이기

Skill을 쓰다 보면 실패할 때마다 규칙이 쌓입니다. “어떤 경우에도 질문하지 말라”나 “모든 일을 시작하기 전에 확인을 받으라”처럼 넓은 규칙을 추가하면 다른 작업까지 불편해집니다.

빠진 단가 때문에 금액이 정해지지 않을 때는 그 항목만 확인하면 됩니다. 이미 있는 단가와 수량으로 초안을 계산하는 일까지 매번 멈출 이유는 없습니다. 반대로 실제 발송이나 제출을 하려면 사용자의 작업 범위가 거기까지인지 확인해야 합니다. 작업에 필요한 만큼만 좁게 적는 편이 좋습니다.

1.4 사람이 읽을 수 있는 변경 기록

버전 1.1에 “정확성 향상”이라고 적기보다 “회의록에서 모집 마감일을 할 일 기한으로 재사용하지 않도록 수정”이라고 적습니다. 어떤 입력으로 확인했는지도 붙이면 동료가 변경의 의미를 이해하기 쉽습니다.

자동 선택이 흔들리는 문제와 내용이 틀리는 문제를 같은 수정으로 해결하려 하지 마세요. 전자는 description과 경쟁 Skill을, 후자는 본문 규칙과 자료 연결을 먼저 봅니다.

완료 산출물은 수정한 Skill, 실패 기록, 이전 사례와 새 사례의 결과입니다. 개선의 기준은 Skill 문장이 길어졌는지가 아니라 확인 가능한 실패가 하나 줄었는지입니다.