모듈러 모놀리스 구조
현재 구조 (Traditional Layered)
QuirkaApi/ ├── Controllers/ (5개) - 컨트롤러가 섞여있음 ├── Services/ (15개) - 서비스가 섞여있음 ├── Models/ (13개) - 엔티티가 섞여있음 ├── DTOs/ (3개) ├── Data/ └── Configurations/
문제점:
- 기능별로 파일들이 흩어져 있음 (Auth, Purchase, Ad 등)
- Services 폴더에 15개 파일이 섞여 관리 어려움
- 새로운 기능 추가 시 여러 폴더를 수정해야 함
제안 1: Feature-based (Vertical Slice) ⭐ 추천
장점: 기능별로 모든 코드가 한 곳에, 중소 규모에 최적, 팀 협업 용이
QuirkaApi/ ├── Features/ │ ├── Auth/ # 인증 기능 (모든 Auth 관련 코드) │ │ ├── AuthController.cs │ │ ├── GoogleTokenVerificationService.cs │ │ ├── JwtService.cs │ │ ├── SessionService.cs │ │ ├── AuthDTOs.cs │ │ ├── Interfaces/ │ │ │ ├── IJwtService.cs │ │ │ └── ISessionService.cs │ │ └── README.md # 기능 설명 │ │ │ ├── Purchase/ # 구매 기능 │ │ ├── PurchaseController.cs │ │ ├── PurchaseVerificationFactory.cs │ │ ├── GooglePlayMockVerificationService.cs │ │ ├── AppStoreMockVerificationService.cs │ │ ├── MockPurchaseVerificationService.cs │ │ ├── PurchaseDTOs.cs │ │ └── Interfaces/ │ │ └── IPurchaseVerificationService.cs │ │ │ ├── Ad/ # 광고 기능 │ │ ├── AdController.cs │ │ ├── AdCallbackController.cs │ │ ├── AdVerificationFactory.cs │ │ ├── AdRewardService.cs │ │ ├── MockAdVerificationService.cs │ │ ├── AdMobMockVerificationService.cs │ │ ├── UnityAdsMockVerificationService.cs │ │ ├── IronSourceMockVerificationService.cs │ │ ├── AdDTOs.cs │ │ └── Interfaces/ │ │ ├── IAdVerificationService.cs │ │ └── IAdRewardService.cs │ │ │ └── Inventory/ # 인벤토리 기능 │ └── InventoryController.cs │ ├── Core/ # 공통 코드 │ ├── Entities/ # 데이터베이스 엔티티 │ │ ├── User.cs │ │ ├── UserAuth.cs │ │ ├── UserProfile.cs │ │ ├── UserStatus.cs │ │ ├── UserConsent.cs │ │ ├── UserInventory.cs │ │ ├── Session.cs │ │ ├── AdReward.cs │ │ ├── AdViewLog.cs │ │ ├── Purchase.cs │ │ ├── PurchaseItem.cs │ │ ├── PurchaseReceipt.cs │ │ └── InventoryTransaction.cs │ │ │ ├── Data/ │ │ └── QuirkaDbContext.cs │ │ │ ├── Extensions/ │ │ └── UuidV7.cs │ │ │ └── Configurations/ │ └── JwtSettings.cs │ ├── Infrastructure/ │ └── Persistence/ │ └── Migrations/ │ └── Program.cs
제안 2: Clean Architecture (Hexagonal)
장점: 테스트 용이, 비즈니스 로직 독립, 대규모 프로젝트 적합
QuirkaApi/ ├── Domain/ # 비즈니스 로직 (의존성 없음) │ ├── Entities/ │ │ ├── User.cs │ │ ├── Purchase.cs │ │ └── AdReward.cs │ ├── ValueObjects/ │ └── Interfaces/ │ ├── IUserRepository.cs │ └── IPurchaseRepository.cs │ ├── Application/ # 유스케이스 │ ├── Auth/ │ │ ├── Commands/ │ │ │ └── GoogleSignInCommand.cs │ │ ├── Queries/ │ │ │ └── GetUserQuery.cs │ │ ├── DTOs/ │ │ │ └── AuthDTOs.cs │ │ └── Services/ │ │ ├── IJwtService.cs │ │ └── JwtService.cs │ │ │ ├── Purchase/ │ │ ├── Commands/ │ │ └── Queries/ │ │ │ └── Ad/ │ ├── Commands/ │ └── Queries/ │ ├── Infrastructure/ # 외부 의존성 │ ├── Persistence/ │ │ ├── QuirkaDbContext.cs │ │ ├── Repositories/ │ │ └── Migrations/ │ │ │ └── ExternalServices/ │ ├── GoogleTokenVerificationService.cs │ └── AdVerificationFactory.cs │ └── WebAPI/ # 진입점 ├── Controllers/ │ ├── AuthController.cs │ ├── PurchaseController.cs │ └── AdController.cs └── Program.cs
제안 3: Modular Monolith (추천 대안)
장점: 마이크로서비스 전환 쉬움, 기능별 독립성, 확장성 최고
QuirkaApi/ ├── Modules/ │ ├── Auth/ # Auth 모듈 (독립 실행 가능) │ │ ├── API/ │ │ │ └── AuthController.cs │ │ ├── Core/ │ │ │ ├── Services/ │ │ │ ├── Entities/ │ │ │ └── Interfaces/ │ │ ├── Infrastructure/ │ │ │ └── GoogleTokenVerificationService.cs │ │ └── ModuleRegistration.cs # DI 등록 │ │ │ ├── Purchase/ # Purchase 모듈 │ │ ├── API/ │ │ ├── Core/ │ │ ├── Infrastructure/ │ │ └── ModuleRegistration.cs │ │ │ └── Ad/ # Ad 모듈 │ ├── API/ │ ├── Core/ │ ├── Infrastructure/ │ └── ModuleRegistration.cs │ ├── Shared/ # 공통 모듈 │ ├── Core/ │ │ ├── Entities/ │ │ └── Interfaces/ │ └── Infrastructure/ │ ├── Data/ │ └── Migrations/ │ └── Program.cs
비교표
| 항목 | Feature-based | Clean Architecture | Modular Monolith |
|---|---|---|---|
| 학습 곡선 | ⭐⭐ 쉬움 | ⭐⭐⭐⭐ 어려움 | ⭐⭐⭐ 보통 |
| 확장성 | ⭐⭐⭐ 좋음 | ⭐⭐⭐⭐ 매우 좋음 | ⭐⭐⭐⭐⭐ 최고 |
| 유지보수 | ⭐⭐⭐⭐ 매우 좋음 | ⭐⭐⭐⭐ 매우 좋음 | ⭐⭐⭐⭐⭐ 최고 |
| 테스트 | ⭐⭐⭐ 좋음 | ⭐⭐⭐⭐⭐ 최고 | ⭐⭐⭐⭐ 매우 좋음 |
| 프로젝트 규모 | 소~중 | 중~대 | 중~대 |
| 마이크로서비스 전환 | ⭐⭐ 어려움 | ⭐⭐⭐ 보통 | ⭐⭐⭐⭐⭐ 매우 쉬움 |
추천
현재 프로젝트에는 제안 1 (Feature-based) 추천
이유:
- ✅ 중소 규모 게임 백엔드에 최적
- ✅ 기능별로 코드가 모여있어 유지보수 쉬움
- ✅ 팀원 추가 시 기능별로 담당 분배 용이
- ✅ 리팩토링 난이도 낮음 (1-2시간)
- ✅ Riot Games, Epic Games 등에서 사용하는 패턴
미래 확장 시 제안 3 (Modular Monolith)
- 나중에 Auth 모듈을 별도 마이크로서비스로 분리 가능
- 게임이 여러 개로 늘어날 때 유리