feat: 지원 시 파일 첨부 및 첨부 파일 다운로드 (#382)

[junghyunseeoo]

이슈

Closes #382

변경 사항

• uploadApplicationFile, downloadApplicationFile API 함수 추가
• CreateApplicationRequest에 fileIds 추가
• 첨부 파일 제약 상수 및 검증 유틸 추가
• ApplyModal에 파일 선택 즉시 업로드 및 삭제 처리
• ApplicationInfoCard 첨부 파일 목록 렌더 및 다운로드 연결
• MSW 핸들러 추가

스크린샷

리뷰 포인트

• 파일 업로드와 지원을 2단계로 나눈 것은 BE 설계 의도를 따랐습니다.
  지원이 마감·중복으로 실패해도 파일을 다시 올리지 않아도 됩니다.
• 지원 API는 fileIds 중 하나라도 무효하면 전체가 실패하므로,
  업로드에 성공한 id만 전달하고 업로드 중·실패 상태에서는 지원 버튼을 막았습니다.
• 첨부 삭제(x) 버튼은 디자인에 없으나, 제출 전 취소 수단이 없어 추가했습니다.
• BE 스펙은 최대 10개이나 디자인이 단일 기준이라 화면은 1개만 지원합니다.
  다중 첨부 필요 여부는 확인 후 반영하겠습니다.

체크리스트

• 셀프 리뷰 완료
• 동작 확인

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
slate-to-fe	Ready	Preview	Aug 12, 2026 3:41pm

[kcleverp]

코드 리뷰

Must: 첨부를 제거하거나 모달을 닫아도 handleFileRemove/handleClose는 로컬 ileIds만 비웁니다. 이미 POST /application-files로 업로드한 파일에는 삭제 API가 없고, BE도 지원에 연결되지 않은 파일을 그대로 남긴다고 명시합니다. 사용자가 파일을 교체·취소할 때마다 최대 100MB의 고아 파일이 쌓입니다. 업로드를 제출 시점으로 미루거나, 업로드 취소용 DELETE API를 추가한 뒤 FE에서 호출해야 합니다.

Should: 없음

[junghyunseeoo]

코드 리뷰

Must: 첨부를 제거하거나 모달을 닫아도 handleFileRemove/handleClose는 로컬 ileIds만 비웁니다. 이미 POST /application-files로 업로드한 파일에는 삭제 API가 없고, BE도 지원에 연결되지 않은 파일을 그대로 남긴다고 명시합니다. 사용자가 파일을 교체·취소할 때마다 최대 100MB의 고아 파일이 쌓입니다. 업로드를 제출 시점으로 미루거나, 업로드 취소용 DELETE API를 추가한 뒤 FE에서 호출해야 합니다.

Should: 없음

업로드를 지원 제출 시점으로 옮겨, 파일 선택·교체·취소 시에는 서버 요청이 나가지 않도록 수정했습니다. 지원 버튼을 눌렀을 때만 업로드 후 fileIds를 전달합니다. 동작 확인했고 현재 구조에서 문제는 없습니다.

나중에 여유가 있을 때 업로드 취소용 DELETE API를 추가해서, BE가 업로드와 지원을 분리한 의도(지원 실패 시 재업로드 방지)를 살리는 방향도 괜찮을 것 같습니다. 다만 지금 구조로도 문제가 없고 마감 일정이 있어, 우선 이 방향으로 진행하겠습니다.

[kcleverp]

파일 업로드→id 연결→다운로드 흐름 전반적으로 잘 짜여 있습니다. Must 이슈는 없고, Should 수준 참고사항만 남깁니다.

Should

• MAX_APPLICATION_FILES 미사용 (src/constants/applicationFile.ts): 10개로 정의돼 있지만 실제 ApplyModal은 파일 하나(attached: AttachedFile | null)만 첨부하도록 구현되어 있어 상수가 어디서도 쓰이지 않습니다. 향후 다중 첨부를 위한 선반영이라면 주석으로 의도를 남기고, 아니라면 정리해도 좋을 것 같습니다.
• mock 다운로드 핸들러가 요청 경로의 recruitmentId/applicationId를 검증하지 않음 (src/mocks/handlers/recruitments.ts): fileId만으로 조회해서 돌려주는데, 실제 BE 권한 체크(본인 지원 파일만 다운로드 가능 등)를 mock이 반영하지 못하고 있어 관련 회귀를 로컬에서 잡기 어려울 수 있습니다. 급한 사항은 아닙니다.

[junghyunseeoo]

파일 업로드→id 연결→다운로드 흐름 전반적으로 잘 짜여 있습니다. Must 이슈는 없고, Should 수준 참고사항만 남깁니다.

Should

• MAX_APPLICATION_FILES 미사용 (src/constants/applicationFile.ts): 10개로 정의돼 있지만 실제 ApplyModal은 파일 하나(attached: AttachedFile | null)만 첨부하도록 구현되어 있어 상수가 어디서도 쓰이지 않습니다. 향후 다중 첨부를 위한 선반영이라면 주석으로 의도를 남기고, 아니라면 정리해도 좋을 것 같습니다.
• mock 다운로드 핸들러가 요청 경로의 recruitmentId/applicationId를 검증하지 않음 (src/mocks/handlers/recruitments.ts): fileId만으로 조회해서 돌려주는데, 실제 BE 권한 체크(본인 지원 파일만 다운로드 가능 등)를 mock이 반영하지 못하고 있어 관련 회귀를 로컬에서 잡기 어려울 수 있습니다. 급한 사항은 아닙니다.

Should 두 건 반영했습니다. MAX_APPLICATION_FILES는 다중 첨부 전환 시 기준값으로 쓸 예정이라 주석으로 의도를 남겼고, mock 다운로드 핸들러는 recruitmentId/applicationId까지 검증하도록 수정했습니다.

[kcleverp]

좋습니다