파일 삭제 기능 기획할 때 꼭 확인해야 할 질문 7가지 | 기획자 실무 체크리스트
파일 삭제 기능 기획할 때 꼭 확인해야 할 질문 7가지
파일 삭제 기능은 겉으로 보면 단순합니다. 휴지통 아이콘 하나 두고, 누르면 사라지면 끝처럼 보이죠. 그런데 실무에서는 이 기능이 생각보다 많은 정책을 끌고 들어옵니다. 누가 삭제할 수 있는지, 삭제 후 복구가 되는지, 실제 파일까지 지워지는지, 썸네일이나 미리보기 파일도 같이 정리되는지, 감사 로그는 남겨야 하는지까지 미리 정해야 합니다.
특히 기획서에 “파일 삭제 가능” 한 줄만 적혀 있으면 개발 단계에서 다시 질문 폭탄이 쏟아집니다. 휴지통인지 완전 삭제인지, soft delete인지 hard delete인지, 삭제 후 링크는 어떻게 되는지 같은 항목이 빠져 있기 때문입니다.
이 글에서는 파일 삭제 기능 기획할 때 꼭 확인해야 할 질문 7가지를 기획자와 PM이 개발자와 회의할 때 바로 써먹을 수 있게 실무형으로 정리했습니다.
파일 기능은 보통 업로드 → 다운로드 → 삭제 순서로 연결됩니다. 아래 글까지 함께 보면 요구사항이 훨씬 또렷해집니다.
“이 삭제는 숨김인가요, 휴지통인가요, 아니면 완전 삭제인가요?”
목차
삭제 기능 기획 전 한눈에 보는 7가지 질문
| 질문 | 왜 중요한가 | 회의에서 확인할 포인트 |
|---|---|---|
| 1. 누가 삭제할 수 있는가? | 삭제 권한이 틀리면 데이터 훼손과 보안 이슈로 이어집니다. | 소유자, 관리자, 조직별 역할 권한 |
| 2. 어떤 방식의 삭제인가? | 휴지통, 논리 삭제, 완전 삭제는 운영 의미가 다릅니다. | soft delete, hard delete, 휴지통, 복구 버튼 |
| 3. 무엇을 같이 삭제하는가? | 원본만 지우고 썸네일이 남으면 운영이 꼬입니다. | 원본, 썸네일, 미리보기, DB 메타데이터, 링크 |
| 4. 복구는 가능한가? | 실수 삭제 대응과 운영 안정성에 직접 연결됩니다. | 복구 기간, 버전 관리, 백업, 삭제 마커 |
| 5. 실패와 중복 요청은? | API 재호출과 부분 실패를 다뤄야 운영이 안정적입니다. | idempotent 처리, 부분 삭제, 재시도 |
| 6. 로그는 남기는가? | 감사, 추적, 분쟁 대응에 필요할 수 있습니다. | 누가, 언제, 무엇을, 왜 삭제했는가 |
| 7. 자동 삭제와 예외 정책은? | 보존 규정과 운영 비용, 법적 요구사항에 연결됩니다. | 만료 정책, 보존 잠금, 자동 정리, 예외 보관 |
질문 1. 누가 파일을 삭제할 수 있는가?
삭제 기능에서 가장 먼저 정해야 할 것은 권한입니다. 업로드한 본인만 지울 수 있는지, 관리자도 삭제 가능한지, 조직 관리자만 가능한지, 혹은 특정 승인 절차가 필요한지부터 명확해야 합니다.
기획 체크포인트
파일 소유자, 관리자, 팀 리더, 운영자 등 역할별 삭제 권한을 나눠 적고, 객체별 접근 통제를 어떻게 할지도 함께 정의하세요.
질문 2. 삭제는 휴지통인가, 논리 삭제인가, 완전 삭제인가?
사용자가 보는 “삭제”는 실제 시스템에서는 여러 의미를 가질 수 있습니다. 목록에서만 숨기는 논리 삭제인지, 휴지통으로 보내는지, 복구 불가능한 완전 삭제인지에 따라 운영 방식이 완전히 달라집니다.
- 삭제 후 바로 목록에서 사라져야 하는가?
- 휴지통에서 일정 기간 복구가 가능한가?
- 관리자만 완전 삭제할 수 있는가?
- 사용자에게 삭제 방식이 명확하게 안내되는가?
질문 3. 삭제 대상은 정확히 어디까지인가?
파일 하나를 지운다고 해도 실제로는 원본 파일만 있는 경우가 드뭅니다. 썸네일, 미리보기 이미지, 변환본 PDF, 검색 인덱스, 데이터베이스 메타데이터, 공유 링크가 함께 붙어 있을 수 있습니다.
같이 정하면 좋은 항목
- 원본 파일 삭제 여부
- 썸네일, 미리보기, 변환본 정리 여부
- DB 메타데이터 삭제 또는 비활성화 여부
- 기존 다운로드 링크 무효화 여부
- 연결된 게시글이나 화면의 표시 처리 방식
실무에서는 파일보다 찌꺼기가 더 오래 남는 경우가 있습니다. 파일은 지웠는데 썸네일이 살아 있는, 약간 유령 도시 같은 상황이죠.
질문 4. 삭제 후 복구는 가능한가, 가능하다면 언제까지인가?
복구 정책은 삭제 정책만큼 중요합니다. 실수로 삭제한 경우를 대비해 복구 기간을 둘지, 버전 관리로 이전 상태를 살릴지, 백업이나 스토리지 버전 기능을 활용할지를 미리 정해야 합니다.
실무에서 자주 나오는 선택지
휴지통 30일 보관 후 완전 삭제, 관리자만 복구 가능, 버전 관리 스토리지로 이전 상태 복원, 민감 파일은 삭제 불가 또는 보존 잠금
- 복구 가능한 기간은 며칠인가?
- 누가 복구할 수 있는가?
- 복구 시 원래 위치로 돌아가는가?
- 버전 기반 복구와 휴지통 복구를 구분할 것인가?
질문 5. 삭제 요청이 중복되거나 실패하면 어떻게 처리할 것인가?
삭제는 네트워크 오류나 재시도로 같은 요청이 여러 번 들어올 수 있습니다. 일부만 지워지고 일부는 남는 부분 실패도 생길 수 있습니다. 그래서 삭제 API와 운영 정책은 재호출에 견디도록 설계하는 편이 좋습니다.
- 이미 삭제된 파일에 다시 삭제 요청이 오면 어떤 응답을 줄 것인가?
- 원본은 삭제됐는데 썸네일 삭제가 실패하면 어떻게 재처리할 것인가?
- 대량 삭제 중 일부 실패 시 사용자에게 어떻게 보여줄 것인가?
- 삭제 처리 중 화면 새로고침이나 중복 클릭을 어떻게 막을 것인가?
질문 6. 삭제 이력과 감사 로그는 어떻게 남길 것인가?
운영 단계에서는 “누가 언제 무엇을 지웠는가”가 중요해집니다. 특히 계약서, 증빙파일, 관리자 문서, 개인정보 관련 파일은 삭제 자체가 중요한 사건이 될 수 있습니다.
- 삭제자 ID를 남길 것인가?
- 삭제 시각과 대상 파일 ID를 기록할 것인가?
- 삭제 사유 입력이 필요한가?
- 복구 이력도 함께 남길 것인가?
- 운영자가 감사 로그를 조회할 수 있어야 하는가?
질문 7. 자동 삭제, 보존 기간, 예외 정책은 어떻게 할 것인가?
모든 파일을 영원히 쌓아두는 구조는 운영 비용과 규정 측면에서 부담이 됩니다. 반대로, 무조건 빨리 지우는 구조는 복구와 감사 대응을 어렵게 만듭니다. 그래서 자동 삭제와 보존 정책은 기능 기획과 함께 정해야 합니다.
- 휴지통 보관 기간은 며칠인가?
- 30일 후 자동 완전 삭제가 필요한가?
- 민감 파일은 일정 기간 삭제 불가 정책이 필요한가?
- 법적 보존 대상 파일은 예외로 둘 것인가?
- 대량 정리 배치나 라이프사이클 정책이 필요한가?
실무 체크리스트 요약
삭제 기능도 결국 정책의 묶음입니다.
- 삭제 권한 정하기
- 삭제 방식 정하기
- 삭제 대상 범위 정하기
- 복구 가능 기간 정하기
- 중복 요청과 실패 처리 정하기
- 감사 로그와 사유 기록 정하기
- 자동 삭제와 보존 예외 정책 정하기
결론
파일 삭제 기능은 단순히 목록에서 사라지게 만드는 기능이 아닙니다. 권한, 복구, 파생 데이터 정리, 감사 로그, 자동 삭제 정책이 묶여 있는 작은 운영 시스템입니다.
기획 단계에서 질문 7가지를 먼저 정리하면, 삭제 기능은 훨씬 안전하고 운영 가능한 구조가 됩니다.
삭제 기능을 기획할 때는 “지울 수 있나?”만 보지 말고 “지운 뒤에도 복구, 감사, 보존 정책이 버틸 수 있나?”까지 같이 보는 것이 실무 감각입니다.
FAQ
참조
- MDN Web Docs, DELETE request method
- MDN Web Docs, Idempotent
- AWS Documentation, Retaining multiple versions of objects with S3 Versioning
- AWS Documentation, Working with delete markers
- AWS Documentation, Locking objects with Object Lock
- OWASP Cheat Sheet Series, Authorization Cheat Sheet
- OWASP Cheat Sheet Series, Insecure Direct Object Reference Prevention Cheat Sheet
- OWASP Cheat Sheet Series, Logging Cheat Sheet