의존성과 첫 제공 범위

중요한 작업과 먼저 해야 하는 작업

승인 알림이 중요한 요청이어도 승인 결과를 안정적으로 읽는 계약이 없으면 메시지에 무엇을 넣을지 정할 수 없습니다. 우선순위는 가치 판단이고 의존성은 시작 또는 완료에 필요한 조건입니다. 높은 가치를 가진 작업을 먼저 개발하겠다고 쓰기 전에 그 작업이 기대하는 데이터와 정책을 적습니다. 이번에는 인증·신청 저장·상태 조회·알림 사이의 관계를 읽고 첫 제공 범위를 하나의 완결된 사용자 행동으로 정합니다.

화살표의 방향을 문장으로 고정합니다

표의 dependsOn은 “이 작업이 기다리는 선행 작업”입니다. I02.dependsOn에 I01을 넣으면 알림이 조회 계약을 기다린다는 뜻입니다. 반대로 I01에 I02를 넣으면 조회가 알림을 기다리게 되어 다른 계획이 됩니다. 화살표만 그리지 말고 “조회는 본인 확인과 저장된 신청 ID가 필요하다”처럼 이유를 씁니다. 서로 다른 사람이 표를 읽어 같은 선행 관계를 설명하는지 확인한 뒤 순서를 제안합니다.

기술 의존과 업무 결정을 구별합니다

상태 조회는 유효 세션과 서버 소유권 검사라는 기술 조건이 있고 어떤 상태를 사용자에게 보여 줄지라는 업무 조건도 있습니다. 인증 구현은 먼저 검토할 기술 작업이고 승인 대기를 참가 확정으로 설명할지 여부는 행사 담당자가 결정할 정책입니다. 정책 질문을 서버 개발자의 개인 판단에 맡기지 않습니다. 각 의존에 완료 증거를 붙여 “정책 결정문 있음”과 “모의 응답 계약 확인”을 구분합니다.

앞 모듈을 구현 완료로 읽지 않습니다

m05는 화면과 인수 기준을 제안한 문서입니다. spec.json에 self-read가 연결되어 있어도 실제 제품에서 목록 API와 서버 권한 처리가 완료되었다는 뜻은 아닙니다. 인증과 저장을 기존 능력으로 가정하는 계획에는 별도 확인이 필요합니다. 이번 모의 프로젝트의 첫 범위는 텍스트 초안과 계약 검토이며 실제 배포 일정이 아닙니다. 의존 표에 현재 확인 가능한 자료와 구현 검증이 필요한 자료를 나누어 적습니다.

첫 제공 범위는 사용자의 끝까지 이어집니다

화면 버튼만 먼저 만들면 눌렀을 때 본인 내역을 읽을 수 없어 Q01을 해결하지 못합니다. 반대로 DB 설계만 끝나도 사용자가 확인 경로를 찾을 수 없습니다. 유효한 사용자에게 본인 신청을 조회하고 승인 대기 문구와 다음 행동을 제공하는 흐름을 첫 범위로 잡습니다. 정상 화면과 함께 빈 목록·권한 거부를 포함합니다. 적은 기능을 고르는 목적은 작게라도 검증 가능한 업무를 끝까지 이어 주는 데 있습니다.

안전과 복구 조건을 제외하지 않습니다

“첫 버전이라 오류 화면은 뺀다”는 선택은 요청 실패를 빈 목록으로 오해하게 만들 수 있습니다. 응답을 확인하지 못했으면 저장되지 않았다고 확정하지 않는 안내를 유지합니다. 첫 범위의 최소 조건에 보호 데이터 제거와 본인 내역 확인을 포함하고 시각적 장식이나 알림 채널 확대는 뒤로 미룹니다. 최소라는 말은 필요한 안전 조건을 줄인다는 뜻이 아니라 사용자 과업과 검증 조건을 함께 작게 잡는다는 뜻입니다.

독립적으로 준비할 일도 찾습니다

알림 전송 코드는 승인 이벤트 계약을 기다리더라도 알림 문구 초안과 사용자 방문 여부 질문은 먼저 준비할 수 있습니다. 작업 전체를 기다림으로 묶지 않고 지금 확인할 부분과 계약 뒤 실행할 부분을 나눕니다. 단, 초안 작성이 끝났다는 이유로 알림 기능 완료라고 표시하지 않습니다. 순서표에는 산출물과 다음 검토 담당을 적어 동시에 준비해도 되는 일이 최종 계약을 앞질러 확정되지 않도록 합니다.

순환 관계는 더 긴 일정으로 해결되지 않습니다

I01이 I02를 기다리고 I02가 I01을 기다리면 어느 쪽도 먼저 끝낼 수 없습니다. 일정에 여유를 더해도 조건은 그대로입니다. 조회 계약 초안을 먼저 합의하고 그 계약을 알림이 참조하게 하는 식으로 순환 이유를 풀어야 합니다. 두 작업이 같은 상태 정의를 기다린다면 공통 정책 검토 작업을 따로 두는 방법도 있습니다. 이름만 바꾸어 숨기지 말고 어떤 입력이 없어 기다리는지 대화로 확인합니다.

보류된 선행 작업이 있으면 채택 범위도 바뀝니다

알림을 adopt로 넣었지만 선행인 조회가 hold라면 이번 범위에서 알림은 끝낼 수 없습니다. 조회도 채택하거나 알림을 보류하거나 조회와 독립적인 조사 과업만 남기는 선택을 해야 합니다. order에는 채택한 작업만 넣고 모든 선행이 먼저 나타나도록 배열합니다. 빈 의존 목록은 의존이 없다는 기록이므로 검토하지 않았다는 뜻으로 쓰지 않습니다. 이미 충족된 조건은 설명 칸에 증거와 함께 적습니다.

범위 밖 항목을 사용자 약속으로 바꾸지 않습니다

첫 범위 설명에는 “본인 상태 조회 초안과 계약 검토”를 넣고 승인 자동화·메일 발송·전체 신청 내보내기는 제외한다고 씁니다. 이 제외는 개발팀에게만 알리는 메모가 아니라 행사 담당자의 기대를 맞추는 자료입니다. “상태 확인 제공”을 “승인 결과를 바로 통보”로 표현하면 알림이 들어 있다고 오해할 수 있습니다. 다음 행동의 이름과 정보 최신성 조건을 확인하여 범위 설명도 실제 검증 대상과 맞춥니다.

경로를 따라 실패를 묻습니다

인증이 실패하면 본인 내역을 보여 주지 않고 로그인 확인으로 갑니다. 조회 응답이 없으면 이전 데이터가 최신이라고 단정하지 않습니다. 저장은 끝났지만 알림이 실패한 경우 새 신청을 만들 필요는 없습니다. 각 단계에 마지막 확인 사실과 남은 일을 적으면 알림 실패를 전체 접수 실패로 바꾸는 오류를 막을 수 있습니다. 더 읽기의 시스템 장에서는 다른 도메인으로 이 관계를 확장하고 여기서는 신청의 의미를 유지합니다.

의존 표의 완료 증거를 리뷰합니다

행마다 선행 ID, 필요 이유, 완료 증거, 확인 역할을 작성합니다. 인증의 증거는 화면 로그인 버튼의 존재가 아니라 서버 주체 확인 계약입니다. 저장의 증거는 성공 애니메이션보다 신청 ID와 저장 결과입니다. 정책의 증거는 회의 초대보다 결정문입니다. 동료가 증거를 보고 다음 작업을 시작해도 되는지 판단할 수 있어야 합니다. 증거가 없으면 계획 가정으로 표시하고 확인 과업을 먼저 넣습니다.

순서 제안은 바뀔 조건까지 포함합니다

현재는 I01만 채택하고 I02와 I03을 보류하는 예를 사용합니다. 추가 조사로 운영자의 반복 내보내기가 중요한 병목이라고 확인되면 순서는 바뀔 수 있습니다. 그때도 본인·담당 행사 접근 범위와 데이터 필드 합의는 선행 조건으로 남습니다. 이번 제출의 목표는 영원히 맞는 순서를 맞히는 것이 아니라 같은 자료에서 순서를 설명하고 새 근거가 생길 때 어떤 판단을 다시 열어야 하는지 명확히 하는 것입니다.