프로젝트 디렉토리 구조

좋습니다, 정우님. 😄
말씀하신 조건을 기준으로 MediaForge 프로젝트 디렉토리 구조 예시를 정리해드리겠습니다.

1️⃣ 요구 사항

• 파일 저장: MinIO (외부 스토리지)
• 파일 변환: FFmpeg (외부 프로세스 / 서비스)
• 백엔드: Go + Gin (API 서버)
• 추가 고려: 향후 확장 용이, 서비스 단위 모듈화, 테스트 용이

2️⃣ 추천 디렉토리 구조

mediaforge/
├── cmd/                    # 실행 파일(서버 진입점)
│   └── server/
│       └── main.go
├── config/                 # 환경 변수, 설정 파일
│   └── config.go           # MinIO, FFmpeg, 서버 포트 등
├── internal/               # 내부 패키지 (외부에 공개 안함)
│   ├── api/                # HTTP 핸들러
│   │   ├── upload.go       # 업로드 관련 엔드포인트
│   │   ├── convert.go      # 변환 관련 엔드포인트
│   │   └── health.go       # 상태 체크 엔드포인트
│   ├── storage/            # MinIO 관련 로직
│   │   ├── client.go       # MinIO 클라이언트 생성 (DI 가능)
│   │   └── upload.go       # 업로드/다운로드 함수
│   ├── converter/          # FFmpeg 관련 로직
│   │   ├── client.go       # FFmpeg 실행 관리
│   │   └── convert.go      # 파일 변환 함수
│   ├── model/              # 데이터 모델 구조체
│   │   └── file.go         # 파일 메타 정보 구조체
│   └── util/               # 공통 유틸리티
│       └── logger.go       # 로거, 에러 처리, 공통 함수
├── pkg/                    # 외부 패키지용 라이브러리 (공용)
├── scripts/                # 배포/관리용 스크립트
│   └── migrate.sh          # DB 마이그레이션 등
├── docs/                   # 문서
├── go.mod
└── go.sum

3️⃣ 구조 설명

1. cmd/

   • 서버 진입점만 존재
   • 내부 로직은 internal/에 구현 → 모듈화

2. internal/api/

   • HTTP 요청 처리
   • Gin 핸들러
   • 업로드, 변환, 헬스 체크 등 API별 파일 분리

3. internal/storage/

   • MinIO와 관련된 모든 코드 모듈화
   • PutObject, GetObject 등 실제 업로드/다운로드 함수 구현
   • DI 패턴으로 핸들러에 주입 가능

4. internal/converter/

   • FFmpeg 호출 및 변환 로직 모듈화
   • 외부 FFmpeg 서비스나 CLI 호출 관리

5. internal/model/

   • DB 테이블 구조체 또는 파일 메타 정보 구조체 정의

6. internal/util/

   • 공통 로깅, 에러, 헬퍼 함수

🔹 설계 특징

• 외부 의존성 명확화: MinIO, FFmpeg 외부 서비스와 통신하는 부분만 storage/, converter/로 격리
• DI 용이: main.go에서 MinIO, FFmpeg 클라이언트 생성 → API 핸들러에 주입
• 테스트 편리: 모킹 가능 (MinIO, FFmpeg)
• 확장 용이: 새로운 변환기나 스토리지를 추가할 때 해당 모듈만 확장 가능

원하시면 제가 이 구조 기준으로 Gin + MinIO + FFmpeg 통합 업로드/변환 서버 샘플 코드까지
실제로 작동하는 형태로 만들어서 보여드릴 수 있습니다.

만들어드릴까요?