만료된 첨부를 실제로 삭제하기 전에 코드를 점검하다가 객체 저장소와 DB 장부 사이의 정합성 문제를 발견했어요. 이 글에서는 일부 단계가 실패하더라도 복구하기 어려운 상태가 남지 않도록 파일 파기 순서를 정한 과정을 다뤄요.
파일은 사라졌지만 서비스에는 남아 있었다
만료된 첨부를 정리하는 파기 작업은 현재 운영 환경에서 실제 파일을 삭제하지 않고 대상만 집계해요.
이 시스템은 첨부파일이 존재한다는 사실을 두 곳에 기록해요.
- 객체 저장소에 있는 실제 객체
- 게시글에 연결된 파일을 기록한 DB 장부
기존 파기 로직은 저장소 객체만 삭제하고 DB 장부는 정리하지 않았어요. 이대로 실제 삭제를 활성화하면 서비스는 DB를 근거로 파일 링크를 계속 노출하지만, 사용자가 링크를 열어도 저장소에는 객체가 없어요.
단순한 화면 오류로 끝날 문제는 아니에요. 저장소 객체는 삭제한 뒤 되돌리기 어려워서 DB와 저장소가 어긋나면 복구할 수 없는 데이터 손상으로 이어질 수 있어요.
되돌릴 수 없는 작업부터 검증한다
저장소 삭제와 DB 변경은 하나의 트랜잭션으로 묶을 수 없어요. 파기 작업에서 처리 순서와 각 단계의 실패 여부가 중요한 이유예요.
이번 변경에서는 처리 순서를 다음과 같이 구성했어요.
- 저장소에서 대상 객체를 삭제한다.
- 객체가 실제로 삭제됐는지 검증한다.
- 삭제와 검증을 마친 뒤 DB 장부를 정리한다.
핵심은 DB를 먼저 변경하지 않는 거예요. 저장소 삭제에 실패했는데 DB에서 첨부 기록부터 제거하면 실제 파일은 남아 있어도 서비스가 추적할 수 없는 고아 객체가 생겨요.
반대로 저장소 삭제에는 성공했지만 DB 정리에 실패하면 일시적인 불일치가 남을 수 있어요. 그래도 저장소 삭제와 검증을 모두 마친 뒤에만 DB 정리를 시작하면 저장소 작업의 성공 여부가 불분명한데 장부까지 바꾸는 위험은 피할 수 있어요.
DB 정리를 위해 별도의 파기 전용 상태를 만들지는 않았어요. 사용자가 직접 첨부파일을 삭제할 때 거치는 기존 경로와 같은 상태가 되도록 장부를 갱신했어요. 같은 의미의 삭제가 서로 다른 DB 상태를 만들지 않도록 기존 lifecycle을 재사용한 거예요.
살아 있는 게시글의 첨부는 파기하지 않는다
만료 조건만 보고 첨부를 삭제하는 것도 안전하지 않았어요. 첨부파일의 보존 기간이 지났더라도 그 파일이 연결된 게시글은 아직 남아 있을 수 있기 때문이에요.
운영 데이터를 전수 확인해 보니 첨부는 파기 대상이지만 게시글은 아직 남아 있는 사례가 이천여 건이었고, 여기에 연결된 첨부는 구천여 개였어요. 모두 게시글도 2년을 넘겼지만 게시글 삭제 작업이 밀려 아직 제거되지 않은 사례였어요. 2년 미만 게시글은 한 건도 없었어요.
이 상태에서 첨부를 먼저 삭제하면 게시글이 제거될 때까지 문제가 생겨요.
- 게시글에 표시되는 첨부 개수가 실제 파일 수와 맞지 않는다.
- 본문에 포함된 이미지가 깨진다.
- 사용자는 아직 남아 있는 게시글에서 열리지 않는 파일 링크를 보게 된다.
이번 변경에서는 게시글이 남아 있으면 연결된 첨부를 파기 대상에서 제외했어요. 게시글을 먼저 삭제한 뒤 첨부를 파기하도록 lifecycle 순서를 보장했어요.
이 보호 조건 때문에 파기가 미뤄지는 양은 전체 재고의 0.014%였어요. 적은 양의 삭제를 늦추는 대신 살아 있는 콘텐츠가 손상되는 구간을 없앴어요.
삭제 활성화 전에 확인한 것
변경 사항은 독립적으로 운영하는 운영 라인과 개발 라인에 똑같이 반영했어요.
운영 라인에서는 TypeScript 타입 검사와 스펙 107건이 모두 통과했어요. 개발 라인에서는 패키지 잠금 파일의 무결성 오류로 pnpm install이 실패해 로컬에서 타입 검사를 실행하지 못했어요. 대신 두 브랜치의 변경 코드를 git diff로 대조했고 최종 검증은 CI에 맡겼어요.
이번 변경만으로 실제 파일 삭제가 활성화된 것은 아니에요. 만료 첨부 파기 작업은 여전히 대상만 집계하는 모드로 동작해요.
저장소와 DB가 분리된 시스템에서 파일을 파기할 때는 어느 쪽을 먼저 변경할지만 따져서는 안 돼요. 중간 단계에서 실패하면 어떤 상태가 남는지, 다른 도메인 객체가 파일을 계속 참조하고 있지는 않은지도 함께 살펴야 해요. 실제 삭제 활성화는 개발 라인의 CI 검증까지 마친 뒤 진행할 남은 단계예요.