동료 리뷰와 운영 인계

리뷰의 목적은 다음 사람이 막히는 위치를 찾는 것입니다

작성자는 Q01의 경위와 화면명을 기억하기 때문에 말로 설명하면 제안서의 부족을 보충할 수 있습니다. 리뷰에서는 처음부터 설명하지 않는 시간을 두고 처음 읽는 사람이 어디서 멈추는지 확인합니다. 맞는지 묻는 감상만으로는 수정 위치가 드러나지 않습니다. 자료를 여는 순서, 검증 명령, FAQ 적용 조건, 다음 담당을 스스로 찾는 과업을 줍니다. 인계는 파일을 보내는 일에서 끝나지 않고 상대가 이어서 할 판단을 설명하는지 확인하는 일입니다.

받는 사람의 과업을 먼저 정합니다

개발 담당은 명세와 구현 후 검증 범위를, 지원 담당은 문의 조건과 미해결 경로를 먼저 찾습니다. 한 문서에 모든 설명을 같은 비중으로 늘리면 둘 다 필요한 내용을 놓칠 수 있습니다. 리뷰 과업은 “Q01의 반례를 찾으세요”, “SUP03에서 지금 확정할 수 없는 결과를 말해 주세요”, “v1과 v2 문구의 연결을 보여 주세요”처럼 구체화합니다. review.procedure에 최소 세 과업을 기록합니다. 정답을 미리 읽어 주지 않고 읽는 사람이 실제 찾아낸 경로와 멈춘 위치를 남깁니다.

재현 방법에는 출발 위치가 있습니다

검증 명령만 적으면 처음 받은 사람은 어느 폴더에서 무엇을 대상으로 실행할지 모릅니다. README는 check.py와 proposal.json이 있는 패키지 루트, Python 3, 제출 파일명을 안내합니다. 확인할 명령과 검사 범위도 함께 적습니다. python3 check.py --submission proposal.json은 제안서 구조와 원본 연결을 검사합니다. python3 support_check.py --submission support.json은 앞 문의 기록을 검사합니다. 같은 “통과”라도 검사 대상이 다릅니다. 받는 사람이 명령 이름과 결과 의미를 짝지어 설명할 수 있게 합니다.

기대와 실제 실행을 다른 칸으로 둡니다

인계에는 기대 종료 코드와 출력 요약, 실제 실행 기록을 구분합니다. 완성 답안 검사 실패 수가 0인 것은 구조 검사가 성공했다는 의미입니다. 실제 앱이 잘 작동했다는 뜻으로 설명하지 않습니다. 실행 기록에는 실행한 파일·명령·환경·결과를 적고 제공 예시 출력과 혼합하지 않습니다. 사용자가 직접 실행하지 않았다면 “예상 출력”으로 기록합니다. 실패가 나면 제안서의 어떤 필드와 연결되는지 확인할 수 있는 안내가 있어야 합니다. 결과 화면만 붙여 두면 다음 사람이 같은 확인을 반복하기 어렵습니다.

리뷰 의견은 자료와 판단으로 씁니다

“설명이 이상하다”보다 “screen 행에서는 v2인데 acceptance가 v1임을 알 수 없어 구현 완료로 읽었다”가 수정할 위치를 드러냅니다. 리뷰 메모에는 검토 과업, 찾은 파일, 멈춘 위치, 독자의 해석, 작성자의 수정, 재확인을 둡니다. 의견을 모두 반영하는 것이 목표는 아닙니다. 반영하지 않을 때도 근거와 남은 질문을 기록합니다. 개인의 역량 평가나 말투 지적만 남기면 인계의 재현성이 좋아지지 않습니다. 읽는 사람이 무엇을 이해했는지에 집중합니다.

수행하지 않은 리뷰를 꾸미지 않습니다

제공 solution의 review.status는 pending이고 findings는 빈 배열입니다. 이는 실제 동료가 이 문서를 읽었다는 증거가 없기 때문입니다. 계획의 reviewer에는 모집할 역할을 쓰고 procedure에는 확인할 과업을 씁니다. 실제 리뷰를 하면 별도 기록에 검토자 가명·시점·버전·관찰한 행동·수정·재확인을 남깁니다. 이번 고정 가상 패키지의 제공 기록을 완료 상태로 바꾸지 않습니다. 혼자 처음부터 다시 읽은 점검은 자기 점검이라고 부르며 독립 동료 리뷰의 대체 증거로 소개하지 않습니다.

인계 담당과 결정권자를 구분합니다

handoff.from과 to는 작성 역할과 다음 담당 역할을 뜻합니다. 실제 사람이 수신하고 일정에 합의하기 전에는 acknowledgement를 pending으로 둡니다. 기술 검토자는 응답 계약을 대조할 수 있어도 D01 정원 집계 정책을 대신 확정하지 않습니다. 행사 업무 담당이 정책을 결정하고 개발·검증 담당이 구현 가능성과 회귀 근거를 확인하도록 나눕니다. “개발팀에서 알아서 해결”은 결정권과 완료 기준이 모두 빠진 전달입니다. 각 남은 항목에 담당·다음 확인·판단 변경 조건을 붙여 책임을 설명합니다.

미해결 문의는 상태째 넘깁니다

SUP02는 타인 내역 권한 거부가 정책과 일치하지만 본인 경로 안내 후 사용자 목적 달성은 아직 pending입니다. SUP03은 응답을 받지 못했으며 저장 여부가 알려지지 않았습니다. handoff.openCaseIds에는 두 ID를 그대로 둡니다. 권한 거부를 정상 방어로 읽는 것과 사용자 문의를 해결했다고 기록하는 것은 다른 판단입니다. SUP03에는 중복 제출 전 본인 내역 확인과 실패 시 개발 이관을 씁니다. 이전 안내·새 확인 질문·결과 미확인을 함께 넘겨 다음 담당자가 같은 질문을 반복하지 않게 합니다.

FAQ 점검은 독자의 행동을 확인합니다

받는 사람에게 FAQ01의 조건을 읽고 SUP01·SUP02·SUP03 가운데 어느 문의에 적용되는지 설명하게 합니다. SESSION_EXPIRED 본인 조회에만 적용되며 FAQ의 SE04는 가상 재확인임을 알아야 합니다. 또 예상 화면이 나타나지 않을 때 어떤 최소 증거를 누구에게 보낼지 찾게 합니다. 이를 실행해 본 적 없는 권한 변경이나 전체 쿠키 삭제 절차로 확장하지 않습니다. 리뷰에서 새로운 안내가 필요해 보이면 새 검증 과제로 남기고 확인하지 않은 절차를 즉시 표준 안내로 넣지 않습니다.

오류를 해석하는 순서를 안내합니다

FAIL file이면 패키지 루트와 파일명·UTF-8을 먼저 확인합니다. FAIL json은 표시된 줄·열 주변의 쉼표와 따옴표를 봅니다. FAIL baseline은 원본 변경 여부와 support_check.py 결과를 대조합니다. FAIL comparison은 숫자뿐 아니라 단위·분모·출처·자료형을 확인합니다. FAIL shape가 나오면 README의 객체와 배열 구조를 비교합니다. 데이터 오류를 없애려고 검사기를 끄지 않습니다. 다음 담당이 오류 종류별 첫 조치를 찾을 수 있게 명령의 checks와 doesNotCheck를 짧게 작성합니다.

인계 종료 기준을 대화로 확인합니다

수신 확인 메시지 “파일 받았습니다”는 도착을 알려 주지만 내용 이해를 보장하지 않습니다. 수신자가 Q01과 반례, v2 제안 위치, 미해결 문의, D01 결정권자, 다음 검토 시점을 자신의 말로 설명하게 합니다. 서로 다르게 이해한 항목은 문서에서 고치고 다시 확인합니다. 일정과 담당이 정해지지 않았으면 인계 완료라고 닫기보다 수신 합의 대기로 남깁니다. nextReview의 날짜는 약속인지 제안인지 표시합니다. 가상 역할명을 실제 사람의 승인처럼 쓰지 않습니다.

리뷰 산출물의 완료 기준

이번 과업은 review 계획, handoff와 검증 명령 설명을 채우는 것입니다. 다음 담당이 필요한 자료를 찾는 절차와 실패 시 첫 조치, 미해결 ID의 다음 행동을 읽을 수 있어야 합니다. 추가한 리뷰 문장은 과업과 연결되는지 확인합니다. 실제 동료를 구했다면 별도 수행 기록을 함께 제출하고 그렇지 않으면 pending을 유지합니다. 자동 검사가 통과해도 인간 검토가 남는 이유를 한 문장으로 적습니다. 협업과 변경 기록의 일반 개념은 더 읽기로 보충하며 여기서는 수신자가 이어갈 구체적인 판단에 집중합니다.