지어낸 값(`MODULE_CNTNTS`)을 쓰고 있었다. 저장소 설정에 없는 id를 보내도 업로드가 실패하지
않고 기본 저장소로 조용히 폴백하기 때문에(`EgovFileMngUtil.parseFileInf`) 지금까지 드러나지
않았을 뿐이다. 받은 실제 목록 8종으로 상수를 바꾼다.
id만 두지 않고 설명·허용 확장자를 함께 담았다. 화면의 `accept`를 `fileModuleAccept()`로 그
목록에서 만들고, Server Action이 업로드 직전에 `isAllowedFileExtension()`으로 한 번 더 본다 —
확장자가 틀리면 백엔드는 사유 없이 실패하므로 어느 파일이 왜 안 되는지 여기서 알려 준다.
업로드 지점별로 저장소가 갈린다:
- 콘텐츠 썸네일(쇼츠·만화) → MODULE_CONTENT_THUMB
- 만화 컷 이미지 → MODULE_TOON_CONTENT
- 금융쇼츠 영상 → MODULE_VOD_CONTENT
- 꾸미기 아이템 썸네일 → MODULE_USER_ITEM (기존과 같음)
꾸미기 아이템의 화면 제한은 JPG·PNG로 그대로 둔다 — 저장소는 gif·svg도 받지만 그 화면 시안이
안내문에 JPG/PNG를 못박고 있어 저장소 허용 범위를 상한으로만 쓴다.
게시판 첨부용 저장소는 목록에 없다. `MODULE_BBS`를 그대로 두되 상수를 분리하고 TODO를 달았다 —
지금은 기본 저장소로 저장되고 있다.
Co-Authored-By: Claude Opus 5
백엔드가 **모듈 목록 조회 API를 만들어 주기로 해서**(2026-08-19 합의) 그때 바꿀 곳이 하나가
되도록 정리했다. 지금은 `MODULE_ITEM`(아이템 썸네일)이 Repository 안 사설 상수로, `MODULE_BBS`
(게시판 첨부)가 게시판 도메인 파일로 흩어져 있었다.
이 값은 백엔드에서 파일 저장 설정(`FileStrgStngVo.strgStngId`)을 가리켜 저장 폴더·허용 확장자·
최대 크기를 정하는데, **틀려도 업로드가 실패하지 않는다** — 설정을 못 찾으면 기본 저장소
(`FILE_STORAGE`)로 폴백해 조용히 다른 곳에 저장된다. 티가 나지 않는 것이 이 값의 위험한 점이라
근거를 `lib/domain/file-module.ts` 주석에 모아 두었다.
곁들여 `file-repository.ts`의 설명을 사실에 맞게 고쳤다 — "설정에 없으면 `UNKNOWN` 경로로
저장된다"고 적혀 있었으나, 실제 폴백은 `FILE_STORAGE` 저장소다(`UNKNOWN`은 설정의 strgStngId가
비었을 때 쓰는 별개 값이다).
Co-Authored-By: Claude Opus 5
수정 팝업(ADM_ITM_103_p)은 시안이 없어 등록 팝업(5227:4629)의 구성을 그대로 쓰되 아이템ID만
읽기 전용이다. 붙이면서 백엔드(develop, "FIX API 수정")를 다시 읽어 세 가지가 달라진 것을
확인했다.
1. **수정은 이제 JSON이다.** 컨트롤러의 update가 `@ParameterObject` → `@RequestBody`로 바뀌었다.
등록은 그대로 `@ParameterObject`(form)라 **한 도메인 안에서 형식이 갈린다** — 종전처럼 둘 다
form으로 보내면 수정이 조용히 깨진다. 보내는 필드는 그대로 두고 전송 형식만 나눴다.
2. **수정일시 필드명이 다르다.** VO의 `lastMdfcnDt`는 `@JsonIgnore`라 응답에 없고, SQL이
`DATE_FORMAT(...) AS last_mdfcn_dt_str`로 따로 내려 준다 — `lastMdfcnDtStr`를 읽는다.
종전 코드는 응답에 없는 이름을 읽어 수정일시가 항상 `-`였다.
3. **종전에 보고한 "수정하면 유형이 날아간다"는 해소됐다.** 컨트롤러가 itemType을 빌더에 담고
UPDATE 문도 필드마다 ``로 감싸여 보내지 않은 값은 건드리지 않는다. 그래서 썸네일 파일
ID를 보내지 않아도 기존 값이 남는다.
썸네일을 지우면 유지 중이던 파일 ID도 함께 비운다 — 비우지 않으면 지운 것처럼 보이는데 저장은
예전 이미지를 그대로 남긴다. 이제 검증이 "썸네일 이미지를 등록해 주세요."로 잡는다.
남은 백엔드 제약: UPDATE의 `` 때문에 **설명을 빈 값으로 지울 수
없다**(조용히 무시된다).
검증 — 수정 팝업 프리뷰 실측: 탭이 item.itemType(셋트) 선택, 아이템ID 128 읽기전용·name 없음
(제출 제외), hidden itemSn/itemType/categoryCode/imageFileId 정상, 이름·포인트·설명·정렬순서·
사용여부 프리필, 기존 썸네일 표시, 썸네일 삭제 시 imageFileId가 ""로 비워짐.
Co-Authored-By: Claude Opus 5
mock 저장소를 제거하고 /api/v1/mngr/item CRUD와 파일 업로드 API에 연결한다. 기존 구현은
"이 도메인에는 백엔드 API가 전혀 없다"는 전제로 만들어져 있었으나, 백엔드에 등록·수정·삭제까지
갖춘 API가 존재해 스키마에 맞춰 도메인 타입부터 다시 맞췄다.
- 아이템ID는 사용자 입력이 아니라 백엔드 자동 채번(itemSn)이다. 시안도 "등록 후 자동발급
(Read Only)"이라 등록 폼의 입력 필드를 없애고 목록·수정 팝업에는 itemSn을 그대로 노출한다.
- 유형은 개별=N, 셋트=S로 매핑한다. 목록 조회는 searchItemType이 필수라 값이 없으면 아무것도
조회되지 않는다.
- 카테고리는 공통코드가 정비되기 전까지 프론트 임시 코드로 개발한다(사용자 지시). 표기는
백엔드가 조인해 준 이름을 우선 쓰고 없으면 임시 목록에서 찾는다.
- 이미지는 파일 하나만 받아 atchFileId에만 저장한다(썸네일은 추후 백엔드 자동생성 예정).
브라우저가 백엔드에 직접 올리지 않도록 Server Action이 File을 받아 중계한다. 목록 썸네일은
인증이 필요 없는 이미지 GET 주소를 서버에서 만들어 내려준다.
- 총건수 보정은 학생 목록과 동일하다(백엔드 PaginationUtil에 count 쿼리가 없다).
lib/http/backend-fetch.ts에 PUT/DELETE와 form·multipart 본문을 추가했다. 아이템 쓰기 API는
@RequestBody가 아니라 @ParameterObject로 받으므로 JSON을 보내면 전 필드가 null인 채 저장된다.
