고아 데이터 처리 문제 해결

🤔문제 발생

• 게시글의 이미지를 업로드하는 기능을 구현하는 도중 발생한 문제다.
• 사용자가 게시글에 이미지를 업로드한 후 작성을 취소하면, 이미지가 삭제되지 않고 서버에 남아버리는 문제가 발생했다.

---

🔍원인 분석

현재 상태

• 사용자가 게시글을 작성하는 동안 DB에는 게시글이 저장되지 않음.
• 게시글 저장 API와 이미지 저장 API가 분리되어 있음.
• 게시글을 삭제하면 해당 게시글의 이미지도 함께 삭제됨.

문제 발생 시나리오

1. 사용자가 게시글을 작성하면서 이미지 업로드
2. 이미지가 먼저 서버에 저장됨
3. 사용자가 게시글 작성 취소
4. 이미지가 삭제되지 않아 고아 상태로 남음

---

⛏해결 과정

❓고아 이미지 문제를 어떻게 해결할까?

✅ 방법 1: 고아 이미지를 주기적으로 삭제

• 이미지 저장 시, 저장 시간을 함께 기록
• 일정 기간이 지난 후, 게시글에 연결되지 않은 이미지를 정기적으로 삭제
• 단점: 일정 간격으로 삭제 작업을 수행해야 함

✅ 방법 2: 게시글 임시저장 기능 추가

• 새 게시글 작성시 바로 임시저장 게시글 저장
• 이미지 저장 시, 임시저장 게시글과 연결
• 사용자가 작성 취소 시, 임시저장 게시글과 이미지를 함께 삭제
• 장점: 애초에 고아 이미지 발생 x

📌 결론

프로젝트 특성상 임시저장 기능이 필요했기 때문에 방법 2로 결정!

 

---

❓ 임시저장 게시글을 어떻게 저장할까?

✅ 방법 1: 임시저장 전용 테이블을 따로 만들기

• 장점
  • 임시저장 데이터만 별도로 관리 가능
  • → 주기적 삭제 기능 추가 시 구현이 쉽고 처리 속도 빠름
• 단점
  • 게시글을 공개로 전환할 때 임시저장 테이블에서 공개 테이블로 이동해야함
    → 이 과정에서 삭제 쿼리 + 생성 쿼리 발생 → 저장 속도 저하

✅ 방법 2: 기존 게시글 테이블에 저장 & 임시저장 여부 필드 추가

• 장점
  • 임시저장 외에도 (삭제, 신고, 비공개 등) 다양한 상태 관리 가능
• 단점
  • 게시글을 검색할 때 임시저장인지, 공개된 글인지 매번 필터링 필요
  • 쿼리 실행 부담 증가 ****→ 조회 속도 저하

📌 결론

프로젝트 특성상 검색/조회가 더 빈번하므로, 저장/수정보다 조회 성능을 고려하여 1번째 방법 채택!

 

---

🛠구축 후 깨달은 방법 1의 문제점

1️⃣ 개발 시간이 많이 걸림

• 게시글과 연관된 엔티티가 있다면, 임시저장 게시글과도 연관된 엔티티를 새로 만들어야 함 → 개발 난이도 증가
• 임시 해결책: 연관 엔티티를 컬렉션 자료형으로 변경
  → 저장/조회/수정 시 추가적인 쿼리 발생, 결국 속도 저하

2️⃣ 코드의 유연성이 떨어짐

• 게시글 상태(삭제, 신고, 비공개 등)를 추가하려면 별도 테이블을 계속 만들어야 함→ 그럴바에 임시저장 여부도 처음부터 상태 필드로 관리하는 게 더 낫다고 판단
• → 결국 기존 테이블에 상태 필드를 추가하는 방향으로 가게 됨

3️⃣ 조회 속도 저하 우려는 크지 않음

• 사실 임시저장 여부를 확인하는 쿼리는 대규모 데이터가 아니면 성능 문제 없음

📌 결론

다음번엔 방법 2를 사용하자!

 

---

💎결론

• 임시저장 기능을 도입해 고아 이미지 문제를 해결했지만, 임시저장 전용 테이블 방식은 개발 복잡도와 유지보수 측면에서 비효율적이었다.
• 다음에는 기존 게시글 테이블에 상태 필드를 추가하는 방식으로 설계하여 유연성과 개발 효율성을 높이자!