요구사항과 증거 대조
75분 안팎
학습 목표
명세 ID를 테스트·diff 검토·실패 기록에 연결하고 빠진 근거를 목록화합니다.
개념
완료 선언을 검토 가능한 표로 바꿉니다
할 일 앱을 받는 동료는 테스트가 몇 개 통과했는지보다 사용자 약속이 어디에서 확인되는지 먼저 묻습니다. 정상 생성은 되지만 실패한 제목 입력이 번호를 소비할 수도 있습니다. 그래서 마지막 모듈에서는 기능을 추가하기 전에 원래 명세와 현재 근거를 대조합니다. 감사의 목적은 만든 사람을 평가하는 점수가 아니라 빠진 계약을 발견하는 것입니다. 요구사항 한 줄에서 테스트 입력, 기대값, 실제 결과, 검토 판단까지 따라갈 수 있으면 수정 범위를 결정하기 쉬워집니다.
이번 모듈의 자료와 실습 환경
미션 ZIP의 루트에서 작업합니다. m09 미션 solution의 Java 앱·Python 참조 모델·정책·루프 fixture를 이어받습니다. JDK 17과 Python 3, Spring Boot 3.1.5 의존성 캐시가 필요합니다. 앱 검사는 ./mvnw test이고, 준비된 캐시로 검증할 때는 ./mvnw -o -q test입니다. 전체 인계 검사는 bash delivery_check.sh이며 캐시 환경에서는 LAB_OFFLINE=1을 붙입니다. 따라하기의 독립 Python 코드는 단계별 파일로 저장해 python3 파일명.py로 실행합니다. 프로젝트 파일을 읽는 단계는 solution ZIP 루트에서 확인하고 과제는 starter에서 수정합니다. 예시의 출력과 자신의 프로젝트 실행 근거를 분리합니다.
변경하지 않을 기준을 먼저 고정합니다
spec.md의 R1은 생성, R2는 ID 순서 조회, R3는 완료입니다. HTTP-CONTRACT.md의 완료 확장 절과 spec.md의 m05 절까지 읽어 현재 계약을 잡습니다. 초기 절에 HTTP가 미확인이라고 적혀 있어도 이후 확장 절이 있으므로 과거 문장 하나로 현재 구현을 판단하지 않습니다. 최종 표에는 기준 파일과 적용 절을 같이 씁니다. 하네스 요구는 이번 감사표에서 H1 권한 경계, H2 최신 근거와 재개, H3 반복 중단으로 식별합니다. H 식별자는 원래 R 식별자의 뜻을 바꾸지 않는 추가 표기입니다.
요구를 대표 사례와 반례로 풉니다
R1에는 복습이라는 제목의 201 응답만 넣지 않습니다. 공백만 입력하면 400 EMPTY_TITLE이며 목록과 다음 번호가 유지되어야 합니다. R2는 Z와 A를 차례로 생성해 제목 정렬과 생성 순서를 구분합니다. R3는 두 항목 중 첫 항목을 두 번 완료하고 다른 항목의 상태가 보존되는지 확인합니다. 대표 사례는 해당 요구의 최소 증거이고 모든 입력을 증명하지는 않습니다. 제목 40·41 코드 포인트, 빈 목록, 없는 양수 ID 같은 추가 사례는 기존 테스트에 남겨 대표 행에서 함께 설명합니다.
파일 이름과 테스트 사례 이름을 연결합니다
requirements.json의 test에는 저장소 안의 실제 상대 경로를, case에는 그 파일의 테스트 메서드 이름을 넣습니다. R2라면 src/test/java/lab/ReproductionTest.java와 ORDER01_sameInput을 연결합니다. 테스트 파일만 연결하면 어느 조건을 확인했는지 찾기 어렵습니다. 테스트 이름만 연결하면 실행 대상과 현재 파일을 찾기 어렵습니다. 실패 자료 failures.json의 ORDER-01은 이전 단계의 제공 재현 자료입니다. 이번에 자신이 실행한 실패처럼 날짜를 새로 붙이지 말고 제공 자료라는 출처를 남깁니다.
파일 존재와 의미 충족을 구분합니다
자동 검사기는 요구 ID 집합, 참조 파일 존재, 사례 문자열과 검토서 ID를 확인합니다. 이는 빈칸을 빨리 찾는 형식 검사입니다. R3의 test를 제목 검사 파일로 연결하면서 사례 이름까지 그 파일의 이름으로 바꾸면 형식만 맞을 수 있습니다. 사람은 입력과 단언문이 실제 완료 전이를 확인하는지 다시 읽습니다. verified 표시는 제출자가 근거를 대조한 판단이지 검사기가 기능 전체를 증명한 결과가 아닙니다. 의미 검토 대기는 인계서에 그대로 표시합니다.
검토 기록에서 채택 이유를 찾습니다
evidence/final-review.md에는 요구 ID마다 읽은 코드와 테스트, 판단과 한계를 적습니다. AI가 제안했다는 문장만으로 선택 이유를 채우지 않습니다. 예를 들어 ID 순서를 TreeMap으로 유지한 구현은 제목 정렬이 아니라 생성 번호 오름차순이라는 명세와 맞습니다. 삭제 기능은 범위 밖이므로 size+1 번호의 현재 전제를 명시합니다. 이 선택은 삭제 요구가 생기면 다시 검토할 대상입니다. 현재 동작과 미래 확장성의 판단을 혼합하지 않으면 검토서가 작고 정확해집니다.
누락과 오래된 근거의 처리 순서
감사표에서 H3가 없으면 요구를 삭제해 통과시키지 않고 루프의 중단 테스트와 README-m09.md를 연결합니다. 파일이 없으면 경로를 먼저 확인하고 파일이 있어도 사례가 없으면 실제 메서드 이름을 읽습니다. 이전 빌드 보고서는 현재 파일 실행 근거로 재사용하지 않습니다. 최신 실행은 다음 레슨의 새 작업 폴더 검사로 보완합니다. 아직 실행하지 않은 행은 미확인 목록에 남깁니다. 기능이 없으면 구현 변경이 필요하고 근거만 없으면 검사나 문서를 보완해야 하므로 원인을 분리합니다.
오류 메시지를 보완 작업으로 바꿉니다
REQUIREMENT_IDS는 행 수 또는 ID 집합이 맞지 않는다는 뜻입니다. MISSING_OR_OUTSIDE는 없는 파일이나 루트 밖 참조를 나타냅니다. UNKNOWN_CASE는 연결한 파일에서 사례 이름을 찾지 못했음을 뜻합니다. REVIEW_LINK는 검토서에 해당 ID가 없다는 형식 오류입니다. 메시지별로 한 번에 하나의 연결을 고친 뒤 다시 검사합니다. 자동 검사 문구를 지우거나 오류를 성공으로 바꾸면 감사 근거가 사라집니다. 의미상 잘못된 연결은 사람이 발견한 이유와 함께 검토 대기로 되돌립니다.
제출할 감사표의 최소 기준
설계 실습에서는 R1·R2·R3·H1·H2·H3 여섯 행을 작성합니다. 각 행에 기준 절, 입력 또는 위협 사례, 기대 결과, 테스트 경로와 사례, 실행 상태, 검토 근거를 둡니다. 제외 범위는 요구 누락과 별도 목록에 적습니다. 로그인과 영속 저장은 제외되지만 생성 실패 후 번호 보존은 포함되므로 두 종류를 구분합니다. 마지막으로 동료가 표의 한 행을 골라 근거를 찾는 데 필요한 경로가 모두 있는지 확인합니다. 포트폴리오에 과정 설명을 구성하는 일반 원칙은 더 읽기로 이어갑니다.
따라하기
누락 요구를 찾습니다
작은 감사표에서 미연결 ID를 계산합니다. 이 예제는 형식 대조이며 실제 앱 검사를 실행하지 않습니다.
required={'R1','R2','R3','H1','H2','H3'}
linked={'R1','R2','R3','H1','H2'}
print('missing:', ','.join(sorted(required-linked)))실행 결과
missing: H3
실행과 의미 판단을 구분합니다
연결 존재만으로 기능 확인 상태를 바꾸지 않습니다.
record={'linked': True, 'executed': True, 'reviewed': False}
print('execution:', 'pass' if record['executed'] else 'unverified')
print('meaning:', 'verified' if record['reviewed'] else 'review_pending')실행 결과
execution: pass meaning: review_pending
반례 선택을 확인합니다
동일 항목의 두 순서가 다른지 비교합니다. 실습 문서에는 실제 앱 입력으로 이 차이를 드러내는 사례를 적습니다.
tasks=[{'id':1,'title':'Z'},{'id':2,'title':'A'}]
print('creation:', [x['id'] for x in tasks])
print('title sort:', [x['id'] for x in sorted(tasks,key=lambda x:x['title'])])실행 결과
creation: [1, 2] title sort: [2, 1]
실제 요구 연결을 읽습니다
solution ZIP 루트에서 실행해 여섯 행의 실제 사례 이름을 확인합니다. 각 test 파일의 단언을 읽어 expected와 맞는지 대조하고 자신의 감사표를 작성합니다.
python3 - <<'PY'
import json
from pathlib import Path
for row in json.loads(Path('evidence/requirements.json').read_text()):
print(row['id']+': '+row['case'])
PY실행 결과
R1: blankPreservesNextId R2: ORDER01_sameInput R3: completeAndRepeatPreserveOtherTask H1: test_document_cannot_promote_source H2: test_changed_file_invalidates_old_pass H3: test_three_same_failures_stop
확인 문제
실습
R1·R2·R3·H1·H2·H3 여섯 행의 감사표를 evidence/requirements.json에 작성합니다. 기준 절, 테스트 경로와 실제 사례 이름, 기대값, 실행 상태, 검토 경로를 연결합니다. 제외 범위와 미확인 목록을 분리하고 한 행은 단언문을 읽어 왜 요구를 확인하는지 설명합니다. 제출 기준은 누락 ID 없음, 실제 경로 존재, 기대값의 명세 근거와 사람 의미 검토 기록입니다.
더 읽기
면접 질문
- AI가 만든 코드가 실행될 때 추가로 확인할 내용을 설명해 주시면 됩니다.