이슈와 결정 기록

대화가 끝나도 결정은 남아야 합니다

모의 협의에서 신청자 역할은 알림을, 운영자 역할은 엑셀을 원합니다. 회의가 끝난 뒤 “조회부터 하기로 함”만 남기면 왜 보류했는지와 무엇을 확인해야 바뀌는지 알 수 없습니다. 이슈는 해결할 요청의 기록이며 결정 기록은 선택한 안과 이유를 남기는 자료입니다. 요청을 받은 일과 채택한 일을 구별하고, 담당자·검증자·미결 질문을 같은 ID로 연결하면 다음 담당자가 대화를 다시 시작하지 않아도 됩니다.

제목은 구현 수단보다 막힌 일을 드러냅니다

I01의 제목은 상태 조회지만 본문 첫 문장은 Q01의 경로 탐색 문제로 시작합니다. “버튼 만들어 주세요”만 쓰면 사용자가 필요한 정보와 시작 위치를 알 수 없습니다. 이슈에는 대상·조건·관찰·기대 행동을 짧게 적고 세부 시나리오와 인수 기준 ID를 연결합니다. 전체 명세를 복사하지 않고 AC-normal과 AC-empty가 어떤 결과를 약속하는지 설명합니다. 복사된 문서가 서로 다른 버전이 되는 문제를 줄일 수 있습니다.

사실과 제안의 칸을 분리합니다

확인된 사실에는 E003과 E006을 적고 제안에는 본인 내역 확인 경로를 적습니다. 제안 문구가 마음에 든다는 역할극 참여자의 반응을 실제 사용자 테스트 결과로 보고하지 않습니다. mode=provided-design과 basis=proposed는 제공 자료로 연습한 판단이라는 표시입니다. 실제 합의를 기록할 때는 참여 역할과 시점, 확인한 자료가 필요하지만 이 연습에는 모의 검토라는 경계를 유지합니다.

작업 담당과 검증 담당은 다른 책임입니다

owner는 작업과 질문을 진행할 역할이고 verifier는 인수 기준 결과를 확인할 역할입니다. 같은 사람이 두 역할을 맡을 수도 있지만 어떤 기준을 누가 확인할지는 적어 둡니다. “팀 전체”만 쓰면 다음 행동을 맡은 사람이 없습니다. 제품 담당은 문제와 범위를 정리하고 개발 담당은 계약과 기술 제약을 확인하며 행사 담당은 정원 정책의 업무 의미를 판단합니다. 서로의 전문 판단을 대신 확정하지 않습니다.

결정문은 채택과 이유를 묶습니다

결정에는 요청 ID, 선택한 상태, 이유, 참조 근거, 재검토 조건을 적습니다. I02를 hold로 쓰면서 “시간 없음”만 적으면 무엇이 먼저인지 이해하기 어렵습니다. 승인 이벤트와 실패 복구 계약이 없고 현재 관찰은 경로 탐색에 집중되어 있어 첫 범위에서 보류했다고 설명합니다. 이 기록은 요청자에게 선택 기준을 전달합니다. 반대 의견은 지우지 않고 그 의견을 확인할 후속 질문에 연결합니다.

정원 변경은 새로운 요청입니다

행사 담당 역할이 “접수 수 대신 승인 수로 정원을 계산하자”고 제안했다고 가정합니다. 이전 spec.rules.capacityBasis는 accepted-applications입니다. 새 제안 approved-applications는 참가 확정 인원으로 집계한다는 뜻이며 m05 조사에서 확인된 사실이 아닙니다. D01에 before와 after를 적고 상태를 proposed로 유지합니다. 숫자가 같아 보이는 예시만 보면 정책 차이를 놓치므로 두 집계가 달라지는 사례를 함께 요청합니다.

기능을 바꾸기 전에 바뀌는 책임을 확인합니다

승인 수만 세면 접수 단계에서는 정원이 남아 보여 신청이 더 들어올 수 있습니다. 승인 시점에는 동시에 정원을 넘기지 않는 확인이 필요하고 취소 시 자리 반환 기준도 필요합니다. 제품 담당이 이 조건을 혼자 정하지 않고 question에 묶어 개발·행사 담당에게 넘깁니다. 질문 담당과 m07 과업 설계 전이라는 reviewAt을 적어 정책이 미결 상태로 테스트 참가자에게 확정 안내되지 않도록 합니다.

변경 영향은 세 가지 산출물에 연결합니다

명세에는 집계 기준과 승인 경계 조건의 검토를 남깁니다. 화면에는 승인 대기와 참가 확정 문구를 분리할 후보를 남깁니다. FAQ에는 승인 인원 기준 안내 후보를 남기되 실제 절차 검증 뒤 게시하도록 적습니다. impacts의 target은 spec·screen·faq이고 각 항목에 action과 owner를 둡니다. 명세만 수정하고 안내를 그대로 두면 사용자가 승인 대기를 정원 확보로 해석할 수 있습니다.

기존 인수 기준과 추가 기준을 구별합니다

D01.criteriaIds의 AC-normal은 접수 결과에 승인 대기를 표시하는 기존 기준입니다. 이 ID를 연결했다고 승인 정원 검증 기준이 이미 존재하는 것은 아닙니다. 변경 영향 설명에는 승인 시 정원 직전·동일·초과와 동시 승인 사례를 새로 검토한다고 적습니다. 원본 spec.json은 바꾸지 않고 변경안에서 새 기준이 필요하다고 남깁니다. 뒤 모듈의 수정 명세가 이전 기준과 어떻게 달라지는지 찾을 수 있게 합니다.

완료와 승인과 검증을 나눕니다

문서 초안 완료는 기록이 작성되었다는 뜻입니다. 업무 승인은 권한 있는 역할이 정책을 받아들였다는 뜻이고 구현 검증은 실제 시스템에서 조건을 실행한 결과입니다. check.py가 통과해도 뒤 두 사건이 일어난 것은 아닙니다. 이슈 상태를 한 단어로만 유지한다면 각 단계의 증거 링크를 덧붙입니다. 이번 연습에는 proposed와 document-only처럼 확인한 범위를 드러내는 값을 사용하여 실제 제공 상태와 혼동하지 않습니다.

미결 질문은 답변 가능한 모양으로 씁니다

“정원 어떻게 할까요”보다 “마감 전 승인 인원 9, 정원 10에서 두 신청을 동시에 승인하면 어떤 결과를 보장합니까”가 적절합니다. 누가 답할지와 답변이 필요한 시점을 함께 쓰고, 답이 없으면 어떤 범위를 보류할지도 설명합니다. 질문을 많이 쓰는 것이 목표는 아닙니다. 선택한 정책의 위험을 바꿀 질문을 우선 남기고 단순 문구 취향은 별도 리뷰로 분리합니다.

필드 오류를 결정 오류와 혼동하지 않습니다

검사에서 items.I01.criteriaIds: ID 참조 오류가 나오면 spec.criteria에 있는 고유 ID와 철자를 대조합니다. changes: 결정 역할·이유·미결 질문·담당·시점·검증 필요는 기록의 빈칸을 알려 줍니다. 문자열을 채워서 통과해도 그 이유가 관찰과 맞는지는 따로 읽습니다. json line과 column 오류는 결정의 품질 문제가 아니라 쉼표와 따옴표 같은 파일 문법 문제이므로 해당 위치부터 수정합니다.

다음 담당자가 이어 갈 수 있게 리뷰합니다

완성한 backlog.json을 동료에게 주고 채택 요청 하나, 보류 요청 하나, 정원 변경의 질문 담당을 찾게 합니다. 찾지 못하면 회의 기억으로 설명하지 말고 파일을 보완합니다. 다음 담당자가 m07의 과업을 만들 때 어떤 화면과 기준을 테스트할지 이해할 수 있어야 합니다. 논의의 결론과 아직 열려 있는 조건을 함께 전달하는 것이 이 레슨의 완료 기준이며 말이 많았다는 사실은 완료 증거가 되지 않습니다.

python3 check.py --submission backlog.json

검사 실패: 0
PASS 이전 근거·3요청·의존 순서·변경 영향; 판단은 동료 검토