냉장고 유통기한 자동 반영 보완

냉장고와 장보기 흐름에서 기본 유통기한이 자연스럽게 이어지도록 보완한 작업이다.

기존에는 사전 재료에 기본 유통기한 값이 있어도, 일부 사용자 흐름에서는 해당 값이 화면이나 저장 로직에 제대로 반영되지 않았다.

특히 장보기 항목을 냉장고로 옮길 때 유통기한이 비어 저장되는 문제가 있었고, 관리자 사전재료 등록 화면에서도 기본 유통기한을 입력할 수 있는 칸이 없어 데이터 관리가 불편했다.

진행 이슈

이슈 번호	작업 내용
#178	장보기 항목 냉장고 반영 시 기본 유통기한 자동 적용
#179	관리자 사전재료 등록 폼 기본 유통기한 입력 연결

#178 장보기 항목 냉장고 반영 시 기본 유통기한 자동 적용

장보기 항목을 냉장고로 반영하는 기능은 장보기 목록에 담아둔 재료를 실제 냉장고 재료로 등록하는 흐름이다.

이때 사용자가 유통기한을 직접 입력하지 않으면, 사전 재료에 저장된 기본 유통기한을 기준으로 냉장고 유통기한이 자동 계산되도록 수정했다.

적용 기준은 다음과 같다.

상황	처리 방식
요청에 expiryDate가 있는 경우	요청한 날짜를 우선 사용
요청에 expiryDate가 없고 defaultExpiryDays가 있는 경우	오늘 날짜 + 기본 유통기한 일수
defaultExpiryDays가 없는 경우	기존 흐름 유지

핵심 로직은 요청값을 먼저 확인한 뒤, 비어 있을 때만 사전 재료의 기본 유통기한을 사용하는 방식으로 구성했다.

LocalDate expiryDate = request.expiryDate();

if (expiryDate == null && product.getDefaultExpiryDays() != null) {
    expiryDate = LocalDate.now().plusDays(product.getDefaultExpiryDays());
}

이후 냉장고 재료를 생성할 때는 request.expiryDate()를 그대로 넘기는 것이 아니라, 위에서 계산한 expiryDate 변수를 사용해야 한다.

FridgeItem fridgeItem = FridgeItem.create(
        member.getId(),
        shoppingItem.getProductId(),
        shoppingItem.getQuantity(),
        expiryDate,
        request.memo()
);

이렇게 처리하면 사용자가 날짜를 직접 지정한 경우에는 그대로 반영되고, 날짜를 생략한 경우에는 사전 재료의 기본 유통기한이 자동으로 들어간다.

테스트에서는 expiryDate를 null로 요청했을 때, 해당 상품의 defaultExpiryDays 기준으로 유통기한이 저장되는지 확인했다.

주의했던 점은 테스트에서 유통기한 일수를 고정값으로 단정하지 않는 것이다.

실제 DB의 productId에 따라 defaultExpiryDays 값이 달라질 수 있으므로, 테스트 데이터와 기대값이 어긋나지 않도록 확인이 필요했다.

#179 관리자 사전재료 등록 폼 기본 유통기한 입력 연결

관리자 사전재료 관리 화면에서는 재료명과 카테고리는 입력할 수 있었지만, 기본 유통기한을 입력하는 칸이 없었다.

그래서 사전재료 등록과 수정 화면에 기본 유통기한 입력칸을 추가했다.

추가된 입력값은 숫자 형태로 관리하며, 등록/수정 요청 시 defaultExpiryDays에 포함되도록 연결했다.

관리자 화면에서 필요한 흐름은 다음과 같다.

기능	처리 내용
사전재료 목록 조회	defaultExpiryDays 포함해서 조회
사전재료 추가	입력한 유통기한을 defaultExpiryDays로 요청
사전재료 수정	수정한 유통기한을 defaultExpiryDays로 요청
목록 표시	기본 유통기한 값을 화면에 표시

프론트에서는 기존 관리자 사전재료 탭 구조를 유지하면서 입력칸만 추가했다.

<input
  type="number"
  min="0"
  placeholder="유통기한(일)"
  value={addDefaultExpiryDays}
  onChange={(e) => setAddDefaultExpiryDays(e.target.value)}
/>

등록 요청에는 입력값을 숫자로 변환해서 포함했다.

adminApi.createProduct({
  productCategoryId: CATEGORY_IDS[addCategory],
  name: addName.trim(),
  defaultExpiryDays: addDefaultExpiryDays ? Number(addDefaultExpiryDays) : null,
});

수정 요청도 동일하게 defaultExpiryDays를 포함하도록 연결했다.

adminApi.updateProduct(items[idx].productId, {
  productCategoryId: CATEGORY_IDS[editCategory],
  name: editName.trim(),
  defaultExpiryDays: editDefaultExpiryDays ? Number(editDefaultExpiryDays) : null,
});

목록에서는 기본 유통기한이 있으면 “7일”처럼 표시하고, 값이 없으면 “미설정”으로 표시했다.

{item.category} · 기본 유통기한 {item.defaultExpiryDays != null ? `${item.defaultExpiryDays}일` : '미설정'}

백엔드 확인

백엔드는 이미 defaultExpiryDays 흐름이 연결되어 있었다.

확인한 흐름은 다음과 같다.

구간	확인 내용
Request DTO	AdminProductCreateRequest, AdminProductUpdateRequest에 defaultExpiryDays 존재
Service	createProduct, updateProduct에서 request.defaultExpiryDays() 사용
Entity	Product.create, Product.update에서 defaultExpiryDays 저장
Response DTO	AdminProductResponse에 defaultExpiryDays 포함

따라서 #179에서는 백엔드 코드를 추가로 수정하지 않고, 프론트에서 API 요청에 defaultExpiryDays를 포함하도록 연결하는 작업만 진행했다.

검증

이번 작업에서 확인한 내용은 다음과 같다.

구분	결과
장보기 항목 냉장고 반영 테스트	통과
프론트 빌드	통과
백엔드 컴파일	통과
관리자 사전재료 등록 폼 입력칸	확인
관리자 사전재료 수정 폼 입력칸	확인
defaultExpiryDays 요청 포함	확인

정리

이번 작업으로 사전 재료의 기본 유통기한 값이 실제 사용자 흐름에 더 자연스럽게 연결되었다.

관리자는 사전재료를 등록하거나 수정할 때 기본 유통기한을 함께 관리할 수 있고, 사용자는 장보기 항목을 냉장고로 옮길 때 별도로 유통기한을 입력하지 않아도 기본값을 자동으로 적용받을 수 있다.

결과적으로 사전 재료 데이터, 관리자 화면, 장보기-냉장고 반영 흐름이 하나의 기준으로 이어지게 되었다.