🚀 공통 파일 업로드 기능 개발 - 이미지 및 파일 업로드 / 관리 시스템
목표: 다양한 도메인에서 재사용 가능한 공통 파일 시스템 설계 및 구현
📅 개발 기간
- 시작: 2026.04.12
- 종료: 2026.04.28
- 총 소요 시간: 5H
🎯 개발 배경 (Why)
- 서비스 내 여러 기능(위치 기반 추천, 게시글 등)에서 파일 업로드 기능이 중복 개발될 가능성 존재함
- 도메인마다 파일을 따로 관리하면 유지보수 비용 증가할 수 있음
- 파일과 도메인 데이터 간의 유연한 매핑 구조 필요
👉 따라서, 공통 파일 테이블 + 도메인 매핑 구조로 설계하여 재사용성과 확장성을 확보하고자 함
🧩 요구사항 (Requirements)
✔️ 기능 요구사항
- 사용자가 이미지를 포함한 여러 형태의 파일을 업로드 할 수 있어야 함
- 파일의 메타데이터가 저장되어야 함 (파일명, 경로, 확장자 등)
- 사용자가 업로드 한 파일을 삭제 할 수 있어야 함 (수정 및 삭제)
- 다중 파일 업로드 기능을 지원해야 함
- 특정 도메인(Entity)과 파일 매핑이 가능해야 함
⚙️ 비기능 요구사항
- 성능 (응답속도, 처리량)
- 확장성 (ElasticSearch 을 통한 파일 검색 도입 고려 등)
- 보안 (인증/인가, 파일 접근 제한 등)
🏗️ 설계 (Design)
📌 아키텍처
- 사용 기술 스택: Spring, JPA, MySQL
- 파일 저장: 로컬 디스크 (추후 S3 등의 별도의 솔루션 도입 가능)
👉 구조
1
2
3
4
5
6
7
8
9
[Client]
↓
[Controller]
↓
[Service]
↓
[File Entity + Mapping Entity]
↓
[MySQL + File System]
🗄️ DB 설계
📁 파일 테이블
| 컬럼 | 설명 |
|---|---|
| file_srl | PK |
| user_srl | 파일 업로더 (FK) |
| file_manage_srl | 파일 관리 번호 (UUID) |
| file_seq | 파일 순번 |
| file_nm | 원본 파일명 |
| file_src | 파일 저장 경로 (SRC) |
| file_extension | 파일 확장자 |
| upload_date | 업로드 일자 |
🔗 매핑되는 테이블 (기본정보)
| 컬럼 | 설명 |
|---|---|
| OOO_srl | PK |
| file_srl | 파일 FK |
| target_table_srl | 매핑될 테이블 FK |
👉 특징
- 특정 도메인에 종속되지 않는 유연한 구조
- 하나의 파일을 여러 도메인에 연결 가능
🔗 API 설계
| Method | URL | 설명 |
|---|---|---|
| POST | /files | 파일 업로드 |
| GET | /files/{id} | 파일 조회 (다운로드) |
| DELETE | /files/{id} | 파일 삭제 |
🛠️ 구현 내용 (Implementation)
🔹 핵심 로직
파일 업로드 시
- UUID 기반 파일명 생성 (파일 관리용 이름 생성)
- 연결된 파일은 하나의 UUID를 공유하고, 순번은 1부터 시작한다.
- 연결된 파일이 단 하나라면 순번은 1로 고정 (기본값)
- 로컬 디스크 저장 (다른 솔루션으로 확장 가능)
- DB에 메타 데이터 저장
- 매핑 테이블 저장과 파일 테이블 저장은 하나의 트랜잭션 처리
파일 삭제 시
- 물리 파일 삭제
- DB 데이터 삭제
- 매핑 테이블 삭제와 파일 테이블 삭제는 하나의 트랜잭션 처리
파일 다운로드 시
- DB에 파일 데이터가 존재하는지 확인
- 하나의 파일이라면 일반 파일 다운로드, 2개 이상의 파일이라면
zip형식으로 다운로드
🔹 주요 코드 전략
MultipartFile사용하여 파일 처리- 파일명 충돌 방지를 위해 UUID 적용
- 트랜잭션 처리로 DB와 파일 시스템 정합성 유지
🔹 사용 기술 / 라이브러리
- Spring Data JPA
- MultipartFile
- MySQL
💡 회고 (Retrospective)
👍 잘한 점
- 요구사항에 해당하는 모든 기능개발을 완료함
👎 아쉬운 점
- 파일을 직접 다루다 보니
try-catch구조가 빈번하게 사용되고 그에 따라 코드가 깔끔하지 않음.
🔥 개선할 점
try-catch구조를 최대한 리팩토링하여 코드를 깔끔하게 개선할 필요성 존재- 회원에 대한 개발이 아직 완료되지 않아 개발이 완료되면 회원에 대한 로직을 추가해야 함
- 보안에 대한 고민과 그에 따른 로직 추가기 필요함