문제 상황
Advent Calendar 프로젝트에 프로젝트 삭제 기능을 추가하면서, 프로젝트 문서만 삭제하고 해당 프로젝트에 속한 이미지와 주제 데이터를 함께 삭제하는 로직을 누락했다. 개발 중에는 삭제 버튼을 숨겨두었다가 기능이 완성되면 활성화할 계획이었는데, 연관 데이터 삭제 로직을 빼먹은 상태로 배포하게 되었다.
발생 환경
- Frontend: React
- Backend/Database: Firebase Firestore
- Storage: Firebase Storage
문제 증상
프로젝트 삭제 버튼을 클릭하면 프로젝트 문서(/projects/{projectId})만 삭제되고, 하위 컬렉션인 각 day 문서(days)와 이미지 문서(images), 그리고 Storage에 업로드된 실제 이미지 파일들은 그대로 남아있었다.
사용자 입장에서는 프로젝트가 삭제된 것처럼 보이지만, 실제로는:
- Firestore의
days,images서브컬렉션 데이터가 남아있음 - Firebase Storage에 업로드된 이미지 파일들이 계속 저장 공간을 차지
- 데이터베이스와 스토리지 비용 증가 및 고아 데이터(orphaned data) 누적
원인 추적
처음에는 단순히 삭제 API 호출이 실패한 것으로 의심했으나, 프로젝트 문서 자체는 정상적으로 삭제되고 있었다.
Firestore 공식 문서를 확인한 결과, Firestore는 문서를 삭제할 때 하위 컬렉션을 자동으로 삭제하지 않는다는 점을 발견했다. 또한 Storage에 저장된 파일 역시 별도로 삭제 요청을 보내지 않으면 그대로 남게 된다.
핵심 원인:
- Firestore의 문서 삭제는 해당 문서만 삭제하며, 서브컬렉션은 남겨둠
- Storage 파일 삭제는 별도 API 호출 필요
- 삭제 로직 구현 시 연관 데이터 정리를 고려하지 않음
해결 방법
1차: 긴급 대응
기능이 불완전한 상태로 배포되었기 때문, 사용자가 기능을 사용하지 못하도록 삭제 버튼을 숨김 처리했다.
// 임시 조치: 버튼 비활성화
{/* <DeleteButton onClick={handleDelete} /> */}2차: 근본 해결
프로젝트 삭제 시 다음 순서로 관련 데이터를 모두 정리하도록 수정했다:
- 프로젝트 내 모든 이미지 조회
- 각 이미지의 Storage URL에서 파일 삭제
- 이미지 문서 삭제
- days 문서 삭제
- 프로젝트 문서 삭제
정리
Firestore는 문서 삭제 시 하위 컬렉션을 자동으로 삭제하지 않으며, Storage 파일 역시 별도 삭제가 필요하다. 계층 구조를 가진 데이터를 삭제할 때는 리프(leaf) 노드부터 역순으로 삭제하는 것이 안전하다.
한 줄 팁: Firebase에서 복잡한 데이터 구조를 삭제할 때는 반드시 서브컬렉션과 Storage 파일까지 포함한 전체 삭제 로직을 설계하자.
참고 자료
- Firestore - Delete data
- Firebase Storage - Delete files
- Firestore - Delete collections and subcollections
배운 점
삭제 기능은 생성보다 구현이 까다롭다는 걸 다시 한번 느꼈다. 특히 관계형 데이터가 아닌 NoSQL 구조에서는 연관 데이터를 직접 추적하고 정리해야 하기 때문에, 설계 단계에서부터 삭제 로직을 함께 고민해야 한다. 다음부터는 CRUD 중 'D'를 구현할 때 연관 데이터 정리 체크리스트를 먼저 작성하고 시작해야겠다.
