문제부터 결과까지 근거 연결

제안서를 판단 가능한 형태로 묶습니다

마지막 모듈의 목표는 앞 단계 파일을 많이 첨부하는 일이 아닙니다. 동아리 행사 신청 업무를 맡는 사람이 “어떤 불편을 왜 먼저 다루며, 무엇을 확인했고, 아직 무엇을 모르는가”를 짧게 판단하게 만드는 일입니다. 제품 담당자는 읽는 사람이 결론을 원자료까지 거슬러 확인할 수 있는 경로를 설계합니다. 문제·화면·인수 기준·지원 안내·전후 관찰을 서로 연결하면 좋은 문구를 골랐다는 주장과 실제 근거가 있는 판단을 구분할 수 있습니다.

이번 모듈의 제출 공간

미션 starter를 별도 연습 폴더에 풀고 UTF-8의 proposal.json을 작성합니다. Python 3 표준 라이브러리로 검사하며 외부 서비스나 서버를 사용하지 않습니다. m09 완성 자료는 그대로 포함되어 있고 이전 검사기는 support_check.py, 안내는 m09-README.md로 보존했습니다. 새 check.py가 제안서를 확인합니다. 각 레슨은 문서 과업이며 실행 단계의 짧은 코드는 근거 점검 원리를 보여 줍니다. 실제 동료 수행 기록이 없으면 계획으로 남깁니다. 전체 제출 명령은 이 패키지 루트에서 python3 check.py --submission proposal.json입니다.

문제와 기능 요청을 다른 줄에 둡니다

research.json의 Q01은 결과 경로를 모르는 신청자가 상태를 찾지 못해 다시 문의하는 문제입니다. E003은 경로 탐색 후 문의, E006은 연결 안내 누락의 근거입니다. 승인 알림을 원한다는 발화는 해결책 후보이며 관찰 사실을 대신하지 않습니다. 제안 요약에는 대상·막힌 행동·영향을 쓰고 해결 후보는 별도 문장으로 둡니다. “알림이 없어서 모두 불편하다”라고 쓰면 원인과 전체 범위를 동시에 넓힙니다. 기존 경로를 알고 직접 확인한 E005의 반례가 그 단정을 막아 줍니다.

ID만 쓰지 말고 위치를 지정합니다

근거 ID는 문서 사이를 연결하는 이름입니다. 그러나 O01이 어느 파일에 있고 어떤 문장인지 찾지 못하면 독자는 같은 근거를 읽을 수 없습니다. refs에는 file, pointer, id를 씁니다. research.json의 /evidence/0/id는 evidence 배열의 첫 항목 ID를 가리킵니다. 배열 번호는 0부터 시작합니다. 화면 문서에는 heading을 써서 정확한 제목 줄을 지정합니다. reference-contract.json에서 참조 객체를 선택하고 실제 원본을 열어 주변 문맥을 읽습니다. 참조가 존재한다는 사실만으로 주장과 관련 있다고 판단하지 않습니다.

다섯 종류는 서로 다른 질문에 답합니다

trace의 problem 행은 선택한 문제와 반례를, screen 행은 사용자가 볼 문구와 경로를 설명합니다. acceptance 행은 어떤 조건에서 어떤 결과를 확인할지를, faq 행은 실패한 사용자가 따라갈 안내와 검증 조건을 보여 줍니다. comparison 행은 개선 전후 결과의 단위와 한계를 설명합니다. 다섯 행을 같은 성공 주장으로 채우지 않습니다. 각 행에 refs와 explanation을 적고 해당 근거가 무엇을 설명하며 무엇까지 설명하지 않는지를 한 문장씩 붙입니다. 빠진 종류는 다음 담당자가 판단할 질문이 남았다는 뜻입니다.

원본 명세와 수정 제안을 나란히 둡니다

spec.json의 UI-normal과 AC-normal은 v1 표현을 보존하고 있습니다. screens-v2.md는 R01·R02에서 제안한 수정 문구를 담습니다. 파일 이름만 보고 모두 최신이라고 묶으면 인수 기준은 옛 문구인데 화면은 새 문구인 상태를 숨기게 됩니다. screen에는 UI-normal 제목과 R01·R02를 함께 연결하고 acceptance에는 원본 AC-normal, 수정 criterion, 재확인 O06을 연결합니다. 제안서를 읽는 사람에게 v1 원본, v2 제안, 가상 재확인이 각각 어디인지 안내합니다. 원본을 덮어써 이 차이를 없애지 않습니다.

연결이 확인한 수준을 표시합니다

R01은 접수와 참가 확정을 구별하는 문구, R02는 본인 상태 확인 경로의 제안입니다. O06은 제공된 텍스트 v2에서 가상 참여자가 설명한 결과입니다. 이를 실제 앱 구현 통과나 전체 사용자 성공이라고 쓰지 않습니다. acceptance의 explanation에는 어떤 인수 기준을 텍스트로 대조했고 어떤 구현 검증이 남았는지 씁니다. 특히 키보드 이동, 본인 데이터 보호, 네트워크 실패는 N02의 후속입니다. 확인한 수준을 낮춰 적는 것이 아니라 확인 수단에 맞는 범위를 정확히 적는 것입니다.

FAQ는 문제의 경계와 연결합니다

FAQ01은 세션 만료가 확인된 본인 내역 조회에서 재로그인 후 상태를 확인하는 안내입니다. SE04는 faq-v1의 가상 확인 카드입니다. Q01의 목적은 상태 확인이므로 FAQ는 창이 열렸는지뿐 아니라 접수와 참가 확정을 구분했는지도 묻습니다. SUP02의 권한 거부와 SUP03의 응답 미수신은 이 절차로 모두 해결되었다고 묶지 않습니다. FAQ 행의 설명에는 적용 조건, 확인 카드, 다른 조건의 이관을 넣습니다. 안내문을 첨부했다는 이유로 미해결 문의를 종료할 근거가 생기지는 않습니다.

비교의 단위를 문장에 포함합니다

metrics.json의 별도 가상 이벤트는 독립 과업 성공이 전 2/4, 후 3/4입니다. 관찰 v1의 세 사례와 v2 한 사례, 지원 문의 세 건은 다른 자료입니다. comparison 행에서 T01 계약과 O06을 함께 읽되 합산하지 않는다고 설명합니다. 전후 차이는 같은 계산 조건의 숫자를 비교한 결과이고 R01만의 효과를 입증하지 않습니다. 근거 목록에서 출처를 한 번 생략하면 읽는 사람이 실제 운영 기록으로 오해할 수 있습니다. 요약과 지표 설명에도 가상 자료임을 드러냅니다.

반례를 제거하지 않는 요약을 씁니다

간결한 요약은 유리한 자료만 남기는 요약과 다릅니다. “경로를 모르는 제공 사례에서 재탐색이 있었고, 기존 경로를 아는 사례는 독립 확인했다”처럼 조건을 줄여 씁니다. 주장과 맞지 않는 E005를 explanation에서 다루면 다음 조사 대상을 초회·재신청 경험으로 나누는 이유가 생깁니다. 판단을 바꾸지 않는 첨부만 늘리기보다 결론에 영향을 주는 근거를 앞에 둡니다. 아직 직접 확인하지 못한 초회 여부와 빈도를 질문으로 남기는 것이 요약의 정확성을 높입니다.

검사 실패를 종류별로 고칩니다

FAIL trace는 다섯 종류의 순서나 필수 참조를 확인할 신호입니다. FAIL reference는 파일명·pointer·ID 조합을 원본과 대조합니다. FAIL baseline은 이전 자료가 바뀌었다는 뜻이므로 해시를 갱신하지 말고 제공 원본을 복원합니다. FAIL json의 줄·열은 큰따옴표와 쉼표를 확인하는 출발점입니다. 근거가 없는데 가짜 ID로 빈칸을 채우지 않습니다. 형식이 맞아도 설명이 자료보다 넓은 주장을 하면 동료 리뷰에서 수정합니다. 자동 통과와 판단의 타당성을 별도 기준으로 둡니다.

근거 표의 완료 기준

다른 사람이 problem 행의 E003에서 출발해 화면 수정 R01·R02, 원본 AC-normal, 가상 재확인 O06, FAQ01·SE04, T01 비교까지 이동할 수 있어야 합니다. 각 경로에서 출처·버전·한계를 말할 수 있는지 확인합니다. 연결이 있다는 말만 반복한 explanation은 근거가 왜 필요한지 설명하지 못합니다. 제출 전에 한 행을 골라 “이 자료가 빠지면 어떤 판단을 할 수 없는가”에 답합니다. 과정을 보여 주는 포트폴리오의 일반 원리는 더 읽기에서 보충하고 여기서는 이 행사 사례의 연결을 완성합니다.