변경 전후 명세 리뷰

차이는 질문을 시작할 위치입니다

정원 정책 수정안이 도착했습니다. 파일의 변경 줄 수가 작다고 영향도 작다고 볼 수 없습니다. capacityBasis 한 줄이 접수 화면, 승인 작업, FAQ의 의미를 바꿀 수 있습니다. 이번 레슨은 before와 after 파일을 Git으로 읽기 전용 비교하고 바뀐 의미와 검증 범위를 review.json에 씁니다. 변경 줄을 발견하는 일과 업무적으로 채택할 수 있는지 판단하는 일을 나누어 수행합니다.

원본과 수정안을 구별합니다

before/policy.txt는 accepted-applications, after/policy.txt는 approved-applications를 사용합니다. 두 파일 모두 마감 조건과 CLOSED·FULL·OPEN 우선순위는 그대로입니다. 비교 전에 어느 쪽이 이전 자료인지 확인하고 머리말의 경로를 읽습니다. 순서를 뒤집으면 추가와 삭제의 방향이 뒤집힙니다. 원본을 수정하여 차이를 없애는 대신 review.json에 전후 값을 적어 검토할 변경을 보존합니다.

저장소 없이 비교할 수 있습니다

git diff --no-index는 두 경로의 내용을 비교하므로 실습 폴더를 Git 저장소로 만들 필요가 없습니다. 이 명령은 차이가 있을 때 종료 코드 1을 반환합니다. 변경을 찾았다는 결과이며 실습 실패를 뜻하지 않습니다. 차이가 없으면 0입니다. 경로를 찾지 못하는 오류와 차이 있음은 stderr와 파일명을 함께 읽어 구분합니다. 뒤의 검사 명령을 실행할 때는 비교 명령 성공을 조건으로 연결하지 않고 별도로 실행합니다.

기호와 주변 문맥을 읽습니다

---와 +++ 머리말은 이전·수정 경로를 보여 줍니다. 그 아래 한 개의 -로 시작한 줄은 삭제된 내용이고 +로 시작한 줄은 추가된 내용입니다. @@는 두 파일에서 비교한 구간을 나타냅니다. 공백으로 시작한 priority와 deadlineExclusive 줄도 읽어 유지되는 조건을 확인합니다. 삭제 줄만 보고 마감 정책까지 폐지되었다고 해석하지 않습니다. 차이는 보여 주는 파일 안의 정보이며 다른 계약을 자동으로 찾아 주지는 않습니다.

집계 기준의 의미를 예시로 번역합니다

마감 전 접수 10건, 승인 9건, 정원 10이면 이전 기준은 FULL이고 수정 기준은 OPEN입니다. 화면에서 OPEN이 보인다는 것이 참가 확정이나 승인 보장을 뜻하지는 않습니다. 접수와 승인 사이에 별도 업무 결정이 남아 있기 때문입니다. 숫자 입력과 기대 결과를 나란히 적고 어느 조건은 그대로인지 씁니다. 마감이면 두 기준 모두 CLOSED라는 기존 우선순위를 유지하여 한 변경을 다른 정책 변경과 섞지 않습니다.

경계 사례를 네 가지로 나눕니다

review.json의 cases에는 접수 10·승인 9·정원 10, 접수 11·승인 10·정원 10, 접수 0·승인 0·정원 0, 접수 1·승인 0·정원 1을 순서대로 씁니다. 모두 마감 전을 가정합니다. before는 모두 FULL이며 after는 각각 OPEN·FULL·FULL·OPEN입니다. 정원 0은 신청을 받을 자리가 없다는 연습 조건입니다. 동일 기준 숫자만 반복하지 않고 변경이 보이는 경우와 유지되는 경계를 함께 검토합니다.

출력만 바꿔서는 서버 보장이 생기지 않습니다

이 실습은 policy.txt의 문서 차이와 검토 답안을 검사합니다. 실제 API나 DB가 승인 수를 계산하는 프로그램은 없습니다. 네 사례를 기록했다고 동시 승인 요청이 정원을 넘기지 않는다는 증거는 생기지 않습니다. verification을 document-only로 두고 후속 구현 검증이 필요하다고 설명합니다. 자동 검사 도구가 무엇을 실행했는지 읽는 습관은 통과 문구를 과장하지 않고 검증 범위를 보고하는 데 필요합니다.

새 위험을 질문 목록에 넣습니다

questions에는 concurrent-approval과 cancellation-release를 넣습니다. 앞 값은 동시에 두 신청을 승인할 때 정원 초과를 어떻게 막을지 묻고 뒤 값은 취소가 승인 인원을 언제 줄이는지 묻습니다. 영어 값은 검사용 식별자이고 논의는 한국어로 설명합니다. 새로운 조건의 답을 지금 임의로 정하지 않습니다. 행사 담당의 정책 답과 개발 담당의 원자적 처리 계약이 함께 필요하다는 검토 요청을 남깁니다.

화면과 FAQ도 같은 의미를 전달합니다

targets에는 spec·screen·faq를 순서대로 넣습니다. 명세의 집계와 승인 처리 기준, 화면의 승인 대기와 참가 확정 구별, FAQ의 정원 설명을 함께 확인합니다. 파일 비교에는 policy.txt만 있으므로 화면과 FAQ가 이미 수정되었다고 말하지 않습니다. 영향 후보를 찾는 단계이며 각각의 작성 담당에게 검토를 넘겨야 합니다. 문서 하나의 차이를 읽은 뒤 관련 자료가 없어 판단할 수 없는 지점도 결과에 포함합니다.

관계없는 변경은 별도로 판단합니다

수정안에 화면 색이나 개인정보 필드가 함께 들어온다면 정원 정책 목적에 필요한지 묻습니다. 목적과 다른 변경을 같이 승인하면 근거와 확인 범위를 설명하기 어렵습니다. 같은 목적을 위해 필요한 명세·화면·안내 수정은 함께 리뷰할 수 있지만 개인정보 노출 확대는 독립된 검토가 필요합니다. 바뀐 줄이 적다는 이유와 작성자가 잘 안다는 이유는 인수 기준 대조를 생략할 근거가 되지 않습니다.

검사 실패의 단서를 읽습니다

python3 check.py가 FAIL 변경 기준을 내면 before와 after 문자열을 대조합니다. FAIL 경계 사례는 숫자·순서·기대 결과를 읽고 마감 전 가정을 확인합니다. FAIL 미결 조건은 두 질문 식별자를 확인하고 FAIL 영향 연결은 세 대상 이름을 확인합니다. 파일·JSON 객체 오류는 review.json 존재와 큰따옴표·괄호를 먼저 확인합니다. 오류를 없애기 위해 검사 스크립트를 고치지 않고 제출물의 빠진 정보를 보완합니다.

작은 자동 통과와 사람의 승인을 구별합니다

solution은 다섯 검사에서 PASS를 출력하고 starter는 검증 한계만 채워 두어 나머지 네 항목에서 실패합니다. 검사가 기대 답안을 찾는 것은 문서 연습의 완료 기준입니다. 담당 역할이 정책을 실제로 승인하거나 사용자에게 안내를 게시한 사건은 아닙니다. 리뷰 결론에는 “집계 기준 차이와 네 예제를 확인했고 승인 동시성·취소 반환은 미결”이라고 씁니다. 확인한 것과 남은 것을 같이 써야 후속 담당자가 잘못된 완료 상태를 이어받지 않습니다.

다음 모듈의 수정 명세에 연결합니다

review.json의 결과를 backlog의 D01에 연결하고 원본 AC-normal이 접수와 승인 대기를 구분한다는 점을 유지합니다. m07에서는 실제 화면 행동을 관찰할 과업과 필요한 수정 기준을 준비합니다. 정책 변경 후보가 아직 미결이라면 확정된 사용자 안내처럼 테스트하지 않습니다. 변경 리뷰를 마쳤다는 것은 모든 질문에 답했다는 뜻이 아니라 바뀐 의미, 영향 대상, 확인 범위, 담당자가 답할 질문을 찾을 수 있게 정리했다는 뜻입니다.

git diff --no-index -- before/policy.txt after/policy.txt

diff --git a/before/policy.txt b/after/policy.txt
index e78c9bd..cadb16d 100644
--- a/before/policy.txt
+++ b/after/policy.txt
@@ -1,3 +1,3 @@
-capacityBasis=accepted-applications
+capacityBasis=approved-applications
 priority=CLOSED,FULL,OPEN
 deadlineExclusive=true

python3 check.py

PASS 변경 기준
PASS 미결 조건
PASS 영향 연결
PASS 경계 사례
PASS 검증 한계

python3 check.py