인계와 완료 판단
75분 안팎
학습 목표
실행 성공과 요구 충족을 따로 표시하고 남은 제약·재개 절차를 인계서에 작성합니다.
개념
인계는 다음 사람이 판단할 수 있게 끝냅니다
최종 제출의 목적은 완료라는 한 문장을 전달하는 일이 아니라 다음 사람이 같은 파일로 검사하고 남은 제약을 판단하게 하는 것입니다. 새 작업 폴더에서 실행이 성공했더라도 사용자가 약속한 동작을 검토하지 않았다면 의미 검토 대기입니다. 요구를 읽고 동작이 맞아 보이더라도 환경 때문에 실행하지 못했다면 실행 미확인입니다. 두 축을 나누면 현재 성과를 인정하면서도 남은 일을 정확히 지정할 수 있습니다. 인계서에서 상태를 합쳐 모든 것이 완료라고 표현하지 않습니다.
실행 상태와 요구 상태를 따로 적습니다
실행 상태에는 명령, 작업 폴더 조건, 종료 코드, 테스트 수와 결과 경로를 씁니다. 요구 상태에는 요구 ID, 사례와 기대값, 검토 판단을 씁니다. 종료 코드 0은 해당 명령의 성공이며 모든 요구의 의미 충족을 자동 증명하지 않습니다. 반대로 요구 상태가 미확인인 행이 있어도 이미 실행한 검사의 성공을 지울 필요는 없습니다. 현재 snapshot에서 둘 다 충분한 근거가 있고 남은 범위가 합의되어야 학습 프로젝트의 완료를 판단할 수 있습니다. 일반적인 운영 출시와 이번 수료 판단은 범위가 다릅니다.
인계 문서는 출발점이 하나여야 합니다
이번 ZIP에는 이전 모듈의 handoff.md와 state.json이 있습니다. 이를 현재 제출의 완료 기록처럼 읽지 않도록 README-delivery.md에서 evidence/handoff.md를 가리킵니다. 원래 상태 파일은 앞 단계 하네스 검사의 입력으로 보존합니다. 최종 인계에는 먼저 읽을 문서, 전체 검사 명령, 증거 목록과 남은 작업을 넣습니다. 같은 내용을 모든 문서에 반복하기보다 경로를 연결합니다. 경로가 바뀌면 인계서와 요구 연결 표를 함께 수정하여 문서끼리 다른 대상을 설명하지 않게 합니다.
현재 근거와 과거 실패의 시간을 구분합니다
evidence/clean-run.json은 이번 전체 실행 결과입니다. failures.json은 앞 단계 조회 순서 결함의 제공 기록입니다. starter의 생성물 제외 검사 실패는 이번 단계에서 직접 재현하는 오류입니다. 인계에는 각 자료의 출처와 실행 시점을 분리합니다. 과거 실패가 있었다고 현재 앱이 실패한다는 뜻은 아니고 현재 회귀가 통과했다고 과거 재현 자료를 삭제할 이유도 없습니다. 제공 예시의 테스트 개수는 현재 결과와 다를 수 있으므로 새 보고서의 값을 읽어 적습니다. 날짜와 성공 횟수를 추측해 채우지 않습니다.
AI와 자신의 판단을 작업 단위로 표시합니다
AI 이용 기록은 사용 여부, 맡긴 작업, 받은 제안, 채택 또는 거절 이유, 검증 위치를 묶습니다. 고정 응답으로 수행했다면 실제 모델 호출이 없었다고 기록합니다. 예를 들어 모델에 문서 초안만 맡기고 R3의 반복 완료 기대값은 명세에서 직접 도출했다고 쓸 수 있습니다. 실제로 하지 않은 선택을 자신의 검토처럼 적지 않습니다. 제목 길이와 번호 보존 규칙을 직접 설명할 수 있는지가 인계의 중요한 부분입니다. AI의 자신감이나 장문 설명은 현재 파일의 근거와 별개입니다.
제약은 사용자가 겪을 행동으로 씁니다
영속 저장 없음이라는 말에 재시작하면 목록이 비어 있다는 행동을 덧붙입니다. 인증 없음은 개인 학습용 단일 사용자 예제라는 범위를 설명합니다. 실제 소켓과 전체 빈 구성은 이번 MockMvc 검사로 확인하지 않았습니다. 동시성도 검증하지 않았으므로 여러 사용자 서비스로 바로 사용 가능한 앱이라고 적지 않습니다. 제외 범위와 미확인은 다릅니다. 영속 저장은 요구에서 제외되어 후속 요구이고 실제 소켓은 현재 실행 방법의 추가 확인 후보입니다. 각각 후속 작업의 목적이 달라집니다.
재개 절차는 명령과 실패 분기를 제공합니다
수신자는 실행 환경을 확인하고 전체 검사 명령을 실행한 뒤 clean-run.json과 requirements.json을 읽습니다. 캐시가 준비되지 않아 오프라인 의존성 오류가 나오면 환경 준비 담당자에게 필요한 의존성을 확인합니다. 단언 실패라면 실패한 사례의 입력과 기대값을 기록하고 해당 코드 경계만 수정합니다. 수정 뒤 전체 검사를 다시 실행하고 요구 표와 검토 상태를 갱신합니다. 모든 파일을 AI에게 다시 작성하게 하는 요청은 재개 절차가 아닙니다. 재현 가능한 실패 하나와 수정 범위를 제공해야 다음 작업이 작아집니다.
마지막 편집 뒤에는 증거가 오래되지 않았는지 봅니다
앱이나 테스트를 검사 후 바꾸었다면 이전 실행 근거는 그 후보의 근거가 아닙니다. 다시 검사하고 검토 대상을 갱신합니다. 설명 문서만 바꾼 경우에도 연결 경로와 요구 판단이 달라졌는지 읽습니다. 앞 모듈 하네스는 보호 대상 파일 해시와 최신 검사 근거로 이 관계를 다루지만 새 문서 내용의 진실성까지 자동 보장하지 않습니다. 최종 제출물 목록을 보고 실행 대상과 검토 대상이 일치하는지 확인합니다. 사람이 읽지 않은 변경을 승인 상태로 조용히 승격하지 않습니다.
중단하는 경우도 정상적인 인계입니다
실행 실패가 반복되거나 준비된 캐시가 없으면 완료 대신 보류 상태를 적습니다. 마지막 명령, 종료 코드, 재현 입력, 시도한 가설과 필요한 다음 조치를 남기면 다른 사람이 이어갈 수 있습니다. 고정 루프에서 예산 한도에 멈춘 것은 자원 관문 검사 결과이며 실제 비용 소진을 뜻하지 않습니다. 미확인 항목을 실패로 과장하거나 성공으로 숨기지 않습니다. 사람 검토를 기다리는 상태에는 검토할 경로와 질문을 명시합니다. 보류의 원인과 해소 조건이 있으면 제출물은 검토 가능합니다.
최종 인계를 읽는 연습으로 마무리합니다
동료에게 ZIP과 README-delivery.md만 전달한다고 가정합니다. 동료는 실행 명령을 찾고 한 요구의 입력과 테스트를 확인한 뒤 왜 그 결과가 맞는지 질문합니다. 답할 수 없다면 해당 흐름을 다시 읽고 검토서를 보완합니다. 설계 실습의 제출물은 실행 성공과 요구 충족 두 칸, AI 이용 범위, 제약 목록, 재개 명령과 실패 분기입니다. 실제 실행 로그 없이 성공 칸을 채우지 않습니다. 명세에서 작업과 구현을 연결하는 일반 방법은 더 읽기에서 확장하고 이번 인계에는 현재 프로젝트의 근거만 남깁니다.
따라하기
두 축의 완료 상태를 표시합니다
형식 감사 성공을 의미 승인으로 바꾸지 않는 결정표를 실행합니다.
for run,requirements in [('pass','review_pending'),('unverified','verified'),('pass','verified')]:
final='ready' if run=='pass' and requirements=='verified' else 'pending'
print(run,requirements,'=>',final)실행 결과
pass review_pending => pending unverified verified => pending pass verified => ready
제외와 미확인을 분리합니다
현재 프로젝트의 제약을 서로 다른 후속 목록으로 남깁니다.
excluded=['영속 저장','로그인','운영 배포']
unverified=['실제 HTTP 소켓','동시성','사람 최종 승인']
print('excluded:', ', '.join(excluded))
print('unverified:', ', '.join(unverified))실행 결과
excluded: 영속 저장, 로그인, 운영 배포 unverified: 실제 HTTP 소켓, 동시성, 사람 최종 승인
재개에 필요한 빈칸을 찾습니다
실패 인계의 최소 필드를 대조합니다. 문서 내용이 사실인지는 이 예시가 판단하지 않습니다.
required={'command','exitCode','input','next'}
handoff={'command':'LAB_OFFLINE=1 bash delivery_check.sh','exitCode':1,'input':'starter target 복사'}
print('missing:', ','.join(sorted(required-handoff.keys())))실행 결과
missing: next
예시 인계의 출발점을 점검합니다
solution ZIP 루트에서 현재 인계 자료를 찾습니다. 문서 존재는 내용 승인과 다릅니다. 자신의 실행 결과를 기록하고 예시라는 표시를 실제 출처와 검토 상태로 바꿉니다.
python3 - <<'PY'
from pathlib import Path
for name in ['README-delivery.md','evidence/handoff.md','evidence/ai-use.md']:
print(name+': '+Path(name).read_text().splitlines()[0])
PY실행 결과
README-delivery.md: # m10 최종 인계 실습 evidence/handoff.md: # 인계 예시 evidence/ai-use.md: # AI 이용 기록 예시
확인 문제
실습
evidence/handoff.md와 ai-use.md를 작성합니다. 실제 실행 명령과 결과 경로, 실행 성공·요구 충족 두 상태, AI 이용 범위, 제외·미확인 목록, 재개 명령과 환경/단언 실패 분기를 넣습니다. 미션 검사 후 자신의 관찰로 예시 문서를 바꿉니다. 제출 기준은 수신자가 문서만으로 한 요구의 증거를 찾아 재실행할 수 있고 사람 승인 대기를 성공으로 바꾸지 않는 것입니다.
더 읽기
면접 질문
- 세션이 바뀌어도 작업을 이어갈 기록을 설명해 주시면 됩니다.