MultiImageForm의 초기 구현은 이미지 파일을 선택할 때마다 하나씩 Supabase Storage의 temporary 폴더에 업로드하고 URL을 가져오고, 삭제 시에도 매번 Storage에 즉시 요청을 보내 해당 이미지를 삭제하는 방식으로 동작했습니다.

이 로직은 게시글 업로드 시 한 번에 이미지를 업로드하여 생길 Storage와의 네트워크 통신 지연을 줄이고, 이미지 파일 관리 로직을 컴포넌트 단위로 집중화하려는 의도에서 비롯되었습니다. 또, house 테이블에는 이미지 이름만 저장하고 다른 페이지에서 해당 이미지 이름을 가지고 불러와 보여주도록 하기 위해, 업로드된 이미지를 temporary 폴더에 보관한 뒤 게시글이 제출되면 최종적으로 storage/images/houseId 폴더로 이동시키는 방식으로 관리했습니다.

🔗

초기 구현과 관련해서는 Multi Image Form(다중 이미지 업로드) & supabase storage 게시글을 참고하세요.

그러나, 이러한 방식은 네트워크 의존성이 지나치게 높아지는 문제가 발생했습니다:

1. 이미지를 업로드하고 URL을 가져오는 과정에서, 이미지 파일의 크기가 큰 경우 미리보기 로딩 속도가 매우 지연되어 사용자 경험을 해치고 있었습니다.
2. 이미지를 여러 번 수정하거나 삭제할 경우, 불필요한 업로드 및 삭제 요청이 반복되며 네트워크 부하가 증가하고 성능이 저하되었습니다.
3. 페이지를 벗어나거나 새로고침 시, temporary 폴더에 이미 업로드된 이미지가 남아 데이터를 정리하는 추가적인 필터링 로직이 필요했습니다.
4. 이미지를 temporary 폴더에서 houseId 폴더로 이동한 뒤 temporary를 비우는 과정은 불필요하게 로직을 복잡하게 만들고 유지보수를 어렵게 했습니다.

☘️ Refactor

🎯 Refactoring Goal

• 이미지를 Storage에 즉시 업로드하지 않고 로컬에서 관리해 불필요한 네트워크 요청을 제거하고, 게시글 제출 시 최종적으로 이미지를 업로드합니다.

• 이미지를 Storage와 독립적으로 처리해 미리보기 속도를 개선하고 사용자 경험을 향상시킵니다.

• 중복된 이미지 이동/삭제 로직을 추상화하고, 함수의 재사용성을 높입니다.

⚠️

리팩토링 과정에서 각 기능을 명확히 드러내도록 함수명 및 변수명을 수정하여, 기존 이름과 다를 수 있습니다.

👩🏻‍💻 Refactoring...

1️⃣ 미리보기 기능

기존에는 ① 이미지를 Storage에 업로드한 뒤, ② 해당 파일의 Storage URL을 가져와 미리보기에 사용했습니다. 이 방식은 간단해 보이지만, API 요청이 두 번 발생하면서 렌더링 속도가 느려지고, 사용자 경험(UX)이 저하되는 문제가 있었습니다.

이를 개선하기 위해 브라우저가 제공하는 URL.createObjectURL＊ API를 활용해 이미지를 로컬에서 처리하도록 변경했습니다.

📍

URL.createObjectURL

• 파일 또는 Blob 객체를 입력받아 로컬 URL을 생성하며, 이 URL은 파일을 임시적으로 참조할 수 있습니다.
• Storage에 업로드하지 않고도, 사용자가 업로드한 이미지를 즉시 미리보기에 활용할 수 있습니다.

 const handleFileUpload = (e: React.ChangeEvent<HTMLInputElement>) => {
    const { files } = e.target;
    if (!files) return;

	// 입력받은 다중 이미지 파일배열을 돌면서 미리보기에 사용할 url을 생성합니다.
    const fileArray = Array.from(files).map((file) => {
	// 고유 로컬 URL을 생성합니다.
    const blobUrl = URL.createObjectURL(file);
      // 이 떄, 생성되는 url은 고유한 이름을 가집니다. 이를 이미지의 고유 이름으로 재사용합니다.
    const imageUuid = blobUrl.split('/').pop() as string;
      return {
        file: new File([file], imageUuid, { type: file.type }),
        preview: blobUrl,
        name: imageUuid,
      };
    });

	// 이미지의 file, url, name을 각각 상태에 적용합니다.
    setImageFiles((prev) => [...prev, ...fileArray.map((item) => item.file)]);
    setPreviewUrls((prev) => [...prev, ...fileArray.map((item) => item.preview)]);
    form.setValue('house_img', [...form.getValues('house_img'), ...fileArray.map((item) => item.name)]);
  };

• Storage 업로드 및 URL 반환 과정을 생략하고, 이미지 파일을 바로 브라우저에서 처리해 미리보기를 생성하고 즉시 렌더링해 UX를 개선했습니다.

• 최종 제출시에만 Storage에 업로드하도록 변경하여 네트워크 요청을 최소화하였습니다.

• createObjectURL에서 생성된 URL의 일부를 사용해 이미지 이름 중복 문제를 방지했습니다.

👀

previewUrl 상태 제거 고려

• file을 받아서 정제하는 과정을 거치므로 ImageFiles를 file배열이 아닌 file과 url을 가지는 객체로 관리하여 하나의 상태로 관리하고자 했습니다.
• 하지만, previewUrl은 MultiImageForm 컴포넌트 내에서만 사용되는 상태이고, ImageFiles를 상위 컴포넌트로부터 props로 전달받으므로 불필요한 의존성을 추가한다고 생각되어서 기존의 previewUrl로 상태를 관리하는 방식을 고수하기로 하였습니다.

2️⃣ 게시글 생성 및 수정 후 이미지 이동

기존 코드는 게시글 생성 및 수정 함수 내에서 이미지 이동 및 삭제 로직이 중복되어 있었고, 가독성과 유지보수성이 떨어집니다.

👀

Trigger 고려

• 게시글 등록 후 생성되는 게시글id로 이미지를 저장하기 위해, Trigger를 통해 게시글 생성 시 자동으로 이미지를 이동시키는 방식을 검토했습니다.
• 하지만, Supabase에서는 SQL 함수로 storage 내부의 파일을 이동하는 기능을 기본적으로 제공하지 않고 있었고, 팀원들과 협의 결과 이미지 처리 로직이 데이터베이스 레벨로 분리되면 디버깅 및 유지보수 면에서 과도한 추상화라는 결론에 다다랐습니다.
• 따라서, 프론트앤드 코드에서 처리하기로 했습니다.

관련 작업을 함수로 추상화해 재사용성을 높이고 로직을 통합하여 게시글 생성/수정 로직에서 호출하여 사용하도록 했습니다.

Storage에서 이미지를 가져오고, 이동하고 삭제하는 각 Storage API요청을 작성하여 로직 작성 시 중복하여 작성하지 않도록 했습니다.

export const getImageList = async (path: string) => {
  const { data, error } = await supabase.storage.from('images').list(path);
  if (error)
    throw new Error(
      `이미지를 가져오는 데 실패했습니다. 경로: ${path}, 에러: ${error.message}`,
    );
  return data;
};

export const moveImage = async (source: string, destination: string) => {
  const { error } = await supabase.storage
    .from('images')
    .move(source, destination);
  if (error)
    throw new Error(
      `이미지 이동 중 문제가 발생했습니다. 소스: ${source}, 목적지: ${destination}, 에러: ${error.message}`,
    );
};

export const removeImage = async (path: string) => {
  const { error } = await supabase.storage.from('images').remove([path]);
  if (error)
    throw new Error(
      `이미지 삭제 중 문제가 발생했습니다. 경로: ${path}, 에러: ${error.message}`,
    );
};

작성한 API 요청 함수를 조합하여 이미지를 가져와 이동하고, 이미지를 가져와 삭제하는 함수를 작성했습니다. 이를 게시글 생성/수정 로직에서 호출하여 사용합니다.

// 사용자가 새로 업로드한 이미지 파일을 게시글ID 폴더로 이동하는 함수입니다.
const moveImagesToStorage = async (userId: string, houseId: string) => {
  const tempPath = `house/${userId}/temp`;
  const movePath = `house/${userId}/${houseId}`;

  const images = await getImageList(tempPath);
  const movePromises = images.map(async imgObj => {
    moveImage(`${tempPath}/${imgObj.name}`, `${movePath}/${imgObj.name}`);
  });

  // Promise.all을 사용해 각 요청을 병렬로 처리합니다.
  await Promise.all(movePromises);
};

// 게시글 수정시 사용자가 기존 이미지를 삭제한 경우, 해당 이미지를 삭제하는 함수입니다.
const deleteUnusedImagesFromStorage = async (
  userId: string,
  houseId: string,
  images: string[],
) => {
  const storageImages = await getImageList(`house/${userId}/${houseId}`);

  const removedImages = storageImages.filter(img => !images.includes(img.name));
  const removePromises = removedImages.map(async img => {
    removeImage(`house/${userId}/${houseId}/${img}`);
  });

  // Promise.all을 사용해 각 요청을 병렬로 처리합니다.
  await Promise.all(removePromises);
};

export const useRegistHouse = () => {
  const { mutate: registHouse, isPending: isRegisteringHouse } = useMutation({
    mutationFn: ...,
    onSuccess: async (houseId, variables) => {
	    // 게시글 생성 시, 이미지를 이동하는 함수를 호출합니다.
      await moveImagesToStorage(variables.user_id, houseId);
    },
  });
  return { registHouse, isRegisteringHouse };
};

export const useUpdateHouse = () => {
  const { mutate: updateHouse, isPending: isUpdatingHouse } = useMutation({
    mutationFn: ...,
    onSuccess: async (_, { houseId, houseData }) => {
	    // 게시글 수정 시, 삭제된 이미지를 필터링하고 새로 올린 이미지를 이동하도록 합니다.
      const totalImage = [houseData.representative_img, ...houseData.house_img];
      await deleteUnusedImagesFromStorage(
        houseData.user_id,
        houseId,
        totalImage,
      );
      await moveImagesToStorage(houseData.user_id, houseId);
    },
  });
  return { updateHouse, isUpdatingHouse };
};

• 이미지를 이동 및 삭제하는 API들을 독립적으로 분리하여 재사용 가능하도록 개선했습니다. Supabase Storage와 상호작용 하는 함수에서 이를 호출하여 코드의 의도를 명확히 표현하도록 했습니다.

• 이 때, 이미지 이동 및 삭제시 Promise.all＊을 사용해 비동기 작업을 병렬로 처리해 성능을 향상시켰습니다.

• 게시글 생성 및 수정시 해당 함수를 호출하도록 해 로직을 단순화했습니다.

🔗

Promise.all

Promise.all에 대해서는 비동기 프로그래밍과 Promise, Async/Await 게시글을 참고하세요.

---

🌈 개선 및 성과

사용자 경험 개선

• 로컬에서 미리보기를 관리하여 네트워크 상태에 상관없이 사용자가 업로드한 이미지의 미리보기가 즉각적으로 표시되도록 했습니다.

• 기존에는 Storage 업로드와 URL 반환 과정에서 렌더링이 지연되는 문제가 있었는데, 이를 완전히 제거하여 사용자 경험을 향상시켰습니다.

네트워크 요청 감소 및 성능 최적화

• 이미지 파일을 업로드한 뒤 URL을 가져오는 기존 로직 대신, 최종 제출 시 한 번에 Storage로 업로드 하도록 변경하여 불필요한 네트워크 요청을 제거했습니다.

• 게시글 생성시 기준으로 Storage에 요청하는 네트워크 줄여, 기존 대비 요청 횟수 50% 감소와 응답 시간 평균 30% 감소라는 성능 개선 효과를 확인했습니다.
  

코드 재사용성과 유지보수성 향상

• moveImage, removeImage, getImageList 등 Storage와 상호작용하는 공통 기능을 모듈화하여 함수로 분리해, 동일 로직을 재사용할 수 있게 되어 중복 코드를 제거했습니다.

• 게시글 생성과 수정 로직에서 중복된 이미지 처리 로직을 통합해, 코드의 명확성과 가독성을 높였습니다.

구조적 단순화

• 기존의 복잡한 폴더 이동 및 정리 로직을 단순화하여, 코드를 더 직관적으로 구성했고, Storage와의 상호작용을 최소화해 구조적 명확성을 확보했습니다.

• Promise.all을 활용해 비동기 작업을 병렬로 처리해 성능을 개선했습니다.

👩🏻‍💻 배운 점

이번 리팩토링을 통해 네트워크 요청을 최소화하고 사용자 경험을 개선하기 위해 로컬 데이터 관리와 비동기 작업 최적화가 어떻게 중요한 지 체감했습니다.

• 네트워크 의존성이 클 경우 네트워크 상태에 따라 사용자 경험이 크게 좌우되므로, 인터넷이 느리거나 불안정한 환경도 고려해서 개발해야 합니다. 👉🏻 서버에서 데이터를 매번 요청하지 않고, 로컬에서 데이터를 관리해서 네트워크 의존성을 낮출 수 있습니다. 또한 서버로의 요청 횟수는 곧 서버 비용입니다. 서버로 한 번에 처리하는 설계 방식으로 서버 비용도 절감할 수 있었습니다.

• 복잡했던 폴더 이동 및 정리 로직을 단순화하고, 불필요한 작업을 제거해 코드의 가독성을 높이고 유지 보수성을 높였습니다. 팀원과 협업시 코드에 대해 회의하기 위해 읽기 쉽고 이해하기 쉽게 작성하는 것이 중요함을 다시 한 번 체감 했습니다.