개선 전후와 학습 경로

개선은 달라진 행동으로 설명합니다

최종 인계에서 “코드를 정리했습니다”라고만 쓰면 다음 담당자는 무엇이 나아졌는지 판단하기 어렵습니다. 개선은 발견한 문제, 재현 입력, 기대 동작, 변경한 위치, 같은 조건의 수정 전후 결과를 연결해 설명합니다. 이번 프로젝트에서는 메모리 후보에 추가한 뒤 저장하지 않아 다음 실행에서 기록을 찾지 못하는 문제를 사례로 삼습니다. 새 기능을 더 넣기 전에 실패 원인을 설명하고 확인한 범위를 남기는 것이 수료 인계의 목표입니다.

docs/improvement.md에 재현 입력·수정 전·수정 후·영향 범위·다음 학습을 나누어 적습니다. README의 개선 절에는 중요한 변화와 제한을 짧게 쓰고 상세 기록으로 연결합니다. 문서 제목이 있는지만 검사하면 “나중에 작성”도 통과할 수 있습니다. 제출자는 각 절의 내용이 실제 파일·테스트·실행 기록과 맞는지 대조합니다. 명령을 아직 실행하지 않았다면 검증 계획과 실제 결과를 구분해 표시합니다.

수정 전의 조건을 고정합니다

starter의 handoff.add_saved에 새 임시 경로와 b01·‘책, 산책’·7·100·1을 줍니다. 기대는 OK 반환, JSON 생성, 별도 프로세스 조회 성공입니다. 수정 전에는 상태만 OK이고 파일이 없어서 seed의 파일 존재 비교가 실패합니다. 이때 조회가 NOT_FOUND였다고 쓰면 실제 테스트가 거기까지 진행하지 않았다는 사실을 놓칩니다. 실패 위치와 도달하지 않은 검사를 구별해 기록합니다.

수정 뒤에는 status가 OK일 때 save_store(path, store)를 호출합니다. 함수 전체를 바꾸거나 모든 상태에서 저장하는 방식은 선택하지 않습니다. 중복 ID와 빈 제목, 문자 금액에서는 파일을 바꾸지 않아야 하기 때문입니다. 수정 전후에는 같은 test_final_flow.py와 같은 입력을 사용합니다. 입력을 정상값으로 바꾸고 통과했다고 쓰면 버그가 고쳐졌는지 알 수 없습니다. 테스트를 삭제해서 실패 수가 줄어든 것은 개선 증거로 인정하지 않습니다.

직접 효과와 부작용을 나눠 확인합니다

직접 효과는 정상 추가 뒤 파일이 생기고 재실행 조회와 SQL 보고서 값이 이어지는 것입니다. 부작용 검사는 실패 입력의 원본 바이트 보존, 헤더만 있는 CSV의 전체 교체, 한글 제목의 왕복입니다. 정상 저장 호출을 추가하면서 오류 입력도 저장하게 만들었는지 확인해야 합니다. 여섯 최종 흐름 테스트만 통과한 경우에는 기존 모든 기능까지 검증했다는 주장을 하지 않습니다. check-final.sh --files로 이전 입력·자료구조·CSV·SQL·CLI 검사까지 함께 실행합니다.

새 폴더 재현은 개발 폴더의 생성 JSON과 개인 경로 없이 실행하는 확인입니다. clean_run.py는 필요한 파일 목록으로 새 프로젝트를 만들고 import·lookup·report를 실행합니다. 보고서 자원 report.sql이나 샘플 CSV를 전달하지 않으면 코드가 맞아도 재현이 실패합니다. README의 순서와 이 자동 검사의 순서가 맞는지 검토합니다. 자동 재현 성공은 동료가 문서를 읽고 막힘없이 따라 했다는 사실과 별개라 사람의 재현 결과는 따로 기록합니다.

결과의 범위를 숫자와 함께 적습니다

검증 기록에는 실행한 명령과 옵션을 그대로 적습니다. --files는 HTTP 소켓 테스트를 제외한 범위이며 전체 명령은 HTTP를 포함합니다. 테스트 수가 다르므로 숫자만 복사하면 어떤 범위를 확인했는지 사라집니다. 실행 시간과 임시 경로는 매번 달라질 수 있으니 핵심 비교 값과 종료 코드를 중심으로 요약합니다. 자동 검사는 문서 내용의 존재를 확인하지만 면접 답의 진실성, 개인정보 분류의 충분함까지 판단하지 않습니다.

HTTP 검사는 외부 검증으로 표시합니다. 브라우저 관찰을 수행하려면 view_http.py를 실행하고 표시된 로컬 주소로 접속해 같은 요청의 상태·헤더·본문을 기록합니다. 관찰 뒤 Enter로 서버를 정리합니다. 자동 HTTP와 브라우저 관찰을 모두 하지 않았으면 두 항목을 각각 대기로 둡니다. 파일 검사만 통과한 제출에서 “전체 수료 검사 완료”라고 쓰지 않고 “파일 범위 완료, HTTP 대기”라고 적어 다음 담당자가 남은 확인을 알 수 있게 합니다.

오류 메시지를 개선 판단의 단서로 씁니다

AssertionError는 기대 비교와 실제가 다른 지점입니다. False is not true와 파일 미존재 설명이 함께 나오면 저장 호출의 경계를 찾습니다. ERR_FILE|ValueError는 CLI가 입력·파일 검증 예외를 요약한 표기라 파일 내용과 테스트 사례를 연결하여 원인을 좁힙니다. 같은 표시라고 중복 ID, 문자 금액, JSON 스키마 오류를 모두 하나의 문제로 묶지 않습니다. 내부 함수의 오류 상태와 사용자 진입점의 요약을 구분합니다.

ModuleNotFoundError는 파일 전달이나 실행 위치가 틀린 상황일 수 있으며 손상된 JSON을 뜻하지 않습니다. PermissionError도 저장 대상 권한 문제와 HTTP 소켓 환경 문제를 발생 위치로 구분합니다. 실패를 완료로 보이게 만들려고 예외를 전부 숨기거나 검사 명령 뒤에 성공을 출력하지 않습니다. 다음 사람이 같은 문제를 겪을 때 처음 확인할 위치와 해당 검증 명령을 개선 문서에 남기면 인계 문서가 실제 도구로 기능합니다.

남은 한계를 기능 요청과 분리합니다

현재 저장소는 단일 사용자 로컬 파일 프로젝트입니다. 두 프로세스가 같은 파일을 읽고 각각 추가한 뒤 저장하면 마지막 쓰기가 앞선 쓰기를 덮을 수 있습니다. 임시 파일 교체는 부분 내용 노출을 줄이는 선택이지 동시 갱신 충돌을 없애는 잠금이 아닙니다. 동시 쓰기를 지원한다고 쓰지 않고 제한과 후속 재현 계획을 남깁니다. 정전 시 저장 내구성, 로그인, 배포 역시 이번 검사에서 보장한 항목이 아닙니다.

HTTP는 읽기 전용 스냅샷입니다. 파일 내용을 바꿨을 때 이미 실행 중인 서버의 응답이 자동 갱신된다고 가정하지 않습니다. 공개 보고서의 열 제한은 현재 구조에 대한 계약이며 새로운 주석·로그·문서의 민감한 정보를 자동 제거하지 않습니다. 실제 사용자 데이터로 실습을 확장하기 전에 공개 경계와 보관 정책을 별도 설계해야 합니다. 이번 제출에는 가상 데이터만 넣고 검증하지 않은 기능의 이름을 성과 목록에 추가하지 않습니다.

다음 학습은 한계에서 질문을 뽑습니다

백엔드에 관심이 있으면 두 사용자의 동시 갱신을 어떻게 지킬지라는 질문에서 SQL 트랜잭션과 동시성 학습으로 이어갑니다. 데이터 직무에 관심이 있으면 빈 값·형식 오류를 어떻게 분류하고 품질 보고서를 만들지로 이어갑니다. 프런트엔드에 관심이 있으면 실패 상태와 재시도 안내를 화면에서 어떻게 구분할지로 이어갑니다. 직무를 고르기 전이라도 현재 한계 하나를 선택해 작은 재현 입력과 기대 결과를 적으면 다음 학습의 시작점이 구체적입니다.

다음 계획에는 주제 이름만 쓰지 않고 실행할 작은 과제와 완료 기준을 적습니다. 예를 들어 ‘트랜잭션 공부’ 대신 ‘같은 ID 추가를 두 실행이 시도할 때 한 건만 저장되고 나머지 요청은 거절되는 테스트를 만든다’고 적습니다. 이 결과를 현재 파일 프로그램이 이미 제공한다고 쓰지 않습니다. 후속 구현을 실제로 했을 때 기존 공개 보고서와 실패 보존 회귀를 다시 실행할 계획도 함께 남깁니다.

인계받는 사람의 첫 작업을 준비합니다

최종 제출에는 앞 모듈의 코드·SQL·가상 CSV·테스트·문서를 보존하고 이번 저장 연결, 여섯 답안, 개선 기록을 덧붙입니다. README에서 실행 명령과 오류 계약을 찾을 수 있고 docs/demo.md에서 입력별 테스트 근거를 찾을 수 있어야 합니다. 커밋 개수만으로 인계 품질을 판단하지 않습니다. 실제 변경 기록과 동료 실행은 별도 리뷰 항목으로 남기며 수행하지 않은 검토는 미수행으로 적습니다. 마지막 설명에서는 구현한 행동, 확인한 범위, 남은 한계, 다음 확인 순서를 연결합니다.

observations = [("before", "OK", False), ("after", "OK", True)]
for label, status, exists in observations:
    accepted = status == "OK" and exists
    print(label, "contract", accepted)

before contract False
after contract True

bash check-final.sh --files