Server 프로젝트 분석 보고서
1. 프로젝트 개요
1.1 기본 정보
- 프로젝트명: dasee-spring-boot-server
- 버전: 0.0.1-SNAPSHOT
- 그룹: com.dasee
- 설명: 다시(Dasee) 서비스 백엔드 API 서버
- 빌드 도구: Gradle
- 개발사: (주)소프트스퀘어드
1.2 프로젝트 목적
- Spring Boot 기반 RESTful API 서버
- 다시(Dasee) 서비스의 핵심 백엔드 시스템
- 사용자, 관리자, 채팅, 결제, 수리 케이스 등 종합 관리
2. 기술 스택 분석
2.1 주요 프레임워크
- Spring Boot: 3.3.5 (최신 안정 버전)
- Spring WebFlux: Reactive 웹 프레임워크
- Java: 언어 버전 (호환성 검토 필요)
2.2 데이터베이스
- Spring Data JPA: 3.3.5 (ORM)
- QueryDSL: 5.1.0 (타입 안전 쿼리)
- MySQL Connector: MySQL 데이터베이스 연결
2.3 보안 및 인증
- JWT: 0.11.5 (JSON Web Token)
- Custom Authentication: JWT 기반 인증 시스템 구현
2.4 외부 연동
- Spring Cloud OpenFeign: 외부 API 클라이언트
- PortOne SDK: 결제 시스템 연동
- AWS S3: 파일 저장소
2.5 문서화 및 도구
- SpringDoc OpenAPI: 2.6.0 (Swagger 대체)
- Lombok: 코드 생성 자동화
- Jackson: JSON 처리
2.6 외부 서비스 연동
- OAuth2: Google, Kakao, Apple 소셜 로그인
- Push Notification: 앱 푸시 알림 서비스
- SMS/Alimtalk: 뿌리오(Ppurio) SMS 서비스
3. 소스 구조 분석
3.1 디렉토리 구조
src/main/java/com/dasee/
├── DaseeApplication.java # 메인 애플리케이션 클래스
├── common/ # 공통 설정 및 유틸리티
│ ├── configuration/ # Spring 설정 클래스들
│ ├── exception/ # 예외 처리
│ ├── response/ # 공통 응답 클래스
│ └── utils/ # 유틸리티 클래스
└── domains/ # 도메인별 패키지
├── admin/ # 관리자 관련
├── authentication/ # 인증/인가
├── chat/ # 채팅 시스템
├── notification/ # 알림 시스템
├── oauth/ # 소셜 로그인
├── payment/ # 결제 시스템
├── repairCase/ # 수리 케이스
├── review/ # 리뷰 시스템
├── setting/ # 사용자 설정
└── user/ # 사용자 관리
3.2 도메인별 구조
각 도메인은 다음과 같은 구조를 따름:
domain/
├── controller/ # REST API 컨트롤러
├── service/ # 비즈니스 로직
├── repository/ # 데이터 접근 계층
├── entity/ # JPA 엔티티
├── dto/ # 데이터 전송 객체
└── client/ # 외부 API 클라이언트 (필요시)
3.3 아키텍처 특징
- Domain Driven Design: 도메인별 패키지 구조
- Layered Architecture: Controller-Service-Repository 계층
- Reactive Programming: Spring WebFlux 기반 비동기 처리
- Clean Architecture: 의존성 역전 원칙 적용
4. 특이사항
4.1 Reactive 웹 스택
- Spring WebFlux: 비동기 논블로킹 웹 프레임워크 사용
- Flux와 Mono: 채팅 SSE 연결에서 Reactive Streams 활용
public Flux<ChatMessageResponse> connect(String roomId) {
Sinks.Many<ChatMessageResponse> sink = chatSSEService.getEmitters()
.computeIfAbsent(roomId, k -> Sinks.many().multicast().onBackpressureBuffer());
return sink.asFlux();
}
4.2 JWT 인증 시스템
- Custom JWT 구현: Spring Security 대신 커스텀 JWT 인증
- ArgumentResolver: 사용자/관리자 정보 자동 주입
- Refresh Token: 토큰 갱신 시스템 구현
4.3 QueryDSL 활용
- 타입 안전 쿼리: 컴파일 타임 쿼리 검증
- 복잡한 검색 조건: BooleanBuilder를 통한 동적 쿼리
- 페이징 처리: Spring Data와 연동된 페이징
4.4 SSE 채팅 시스템
- Server-Sent Events: 실시간 채팅 구현
- Sinks: 멀티캐스트 메시지 전송
- Ping 메커니즘: 연결 상태 유지
4.5 스케줄러 시스템
- @Scheduled: 결제 알림, 리뷰 요청 등 정기 작업
- 이벤트 기반: NotificationEvent를 통한 비동기 알림 처리
5. 장점 (잘 구축된 부분)
5.1 현대적 기술 스택
- Spring Boot 3.x: 최신 버전의 Spring 생태계 활용
- Spring WebFlux: 고성능 비동기 웹 애플리케이션
- Java 17+: 최신 Java 버전의 기능 활용 (추정)
5.2 확장 가능한 아키텍처
- 도메인 중심 설계: 비즈니스 로직의 명확한 분리
- Reactive Programming: 높은 동시성 처리 가능
- 마이크로서비스 준비: 도메인별 독립적 구조
5.3 강력한 데이터 접근 계층
- QueryDSL: 타입 안전하고 유연한 쿼리 작성
- JPA: 객체 관계 매핑을 통한 생산성 향상
- Custom Repository: 복잡한 비즈니스 쿼리 최적화
5.4 종합적인 기능 구현
- 소셜 로그인: Google, Kakao, Apple 통합 지원
- 결제 시스템: PortOne을 통한 안정적인 결제 처리
- 실시간 채팅: SSE 기반 실시간 통신
- 알림 시스템: 푸시, SMS, 알림톡 통합 지원
5.5 API 문서화
- OpenAPI 3.0: SpringDoc을 통한 자동 API 문서 생성
- Swagger UI: 개발자 친화적인 API 테스트 환경
6. 단점 (개선 가능한 부분)
6.1 보안 강화 필요
- Spring Security 부재: 커스텀 인증 대신 표준 보안 프레임워크 고려
- CORS 설정: 와일드카드 허용으로 보안 위험
- 입력 검증: 더 강화된 validation 필요
6.2 에러 처리 개선
- 글로벌 예외 처리: 더 세밀한 예외 분류 및 처리
- 로깅 시스템: 구조화된 로깅 및 모니터링 부족
- Circuit Breaker: 외부 API 호출 실패 대응 부족
6.3 테스트 코드 부족
- 단위 테스트: Service, Repository 계층 테스트 부재
- 통합 테스트: API 전체 플로우 테스트 부족
- Mock 테스트: 외부 의존성 모킹 테스트 부족
6.4 성능 최적화
- N+1 문제: JPA 쿼리 최적화 검토 필요
- 캐싱 전략: Redis 등 캐싱 시스템 미적용
- DB 인덱스: 쿼리 성능 최적화를 위한 인덱스 전략 부족
7. 단점 (반드시 개선해야 하는 부분)
7.1 보안 취약점
- CORS 와일드카드:
allowedOriginPatterns("*")로 모든 도메인 허용 - JWT Secret 관리: JWT 비밀키의 안전한 관리 검토 필요
- API 권한 제어: 세밀한 권한 기반 접근 제어 부족
7.2 프로덕션 준비도
- 헬스체크: 애플리케이션 상태 모니터링 엔드포인트 부족
- Graceful Shutdown: 안전한 서버 종료 처리 미구현
- 리소스 모니터링: 메모리, CPU 사용량 모니터링 부족
7.3 데이터 무결성
- 트랜잭션 관리: 복잡한 비즈니스 로직의 트랜잭션 경계 점검 필요
- 동시성 제어: 동시 접근에 대한 락킹 전략 부족
8. 개발 환경 및 배포
8.1 빌드 시스템
# Gradle 빌드
./gradlew build # 프로젝트 빌드
./gradlew bootRun # 개발 서버 실행
./gradlew test # 테스트 실행
8.2 환경 설정
- application.yml: 환경별 설정 파일 관리
- Profile 분리: dev, prod 환경 설정 분리
- 외부 설정: AWS, 결제 등 외부 서비스 키 관리
8.3 Docker 지원
- Dockerfile: 컨테이너화 지원
- docker-compose: 개발/운영 환경 구성
8.4 CI/CD
- AWS CodeBuild: buildspec 파일을 통한 빌드 자동화
- 배포 스크립트: deploy 디렉토리의 배포 자동화
9. 의존성 분석
9.1 주요 외부 라이브러리
| 라이브러리 | 버전 | 용도 | 상태 |
|---|---|---|---|
| Spring Boot | 3.3.5 | 프레임워크 | 최신 |
| Spring WebFlux | 3.3.5 | Reactive 웹 | 최신 |
| QueryDSL | 5.1.0 | 쿼리 빌더 | 안정 |
| JWT | 0.11.5 | 인증 토큰 | 안정 |
| MySQL Connector | latest | DB 드라이버 | 안정 |
| SpringDoc | 2.6.0 | API 문서 | 최신 |
9.2 보안 취약점
- 정기적인
./gradlew dependencyCheckAnalyze실행 필요 - Spring Boot 버전 업데이트 시 호환성 테스트 필요
9.3 라이선스
- 대부분 Apache 2.0 라이선스로 상업적 사용 가능
- PortOne SDK 등 상용 라이브러리 라이선스 확인 필요
10. 향후 개발 권장사항
10.1 즉시 수정 필요
- 보안: CORS 정책 강화 및 Spring Security 도입 검토
- 모니터링: 헬스체크 엔드포인트 및 메트릭 수집 구현
- 에러 처리: 글로벌 예외 처리 및 구조화된 로깅 시스템
10.2 단기 개선 사항 (1-2개월)
- 테스트: 단위 테스트 및 통합 테스트 코드 작성
- 캐싱: Redis를 이용한 캐싱 전략 도입
- 성능: JPA 쿼리 최적화 및 DB 인덱스 전략 수립
10.3 중기 개선 사항 (3-6개월)
- Circuit Breaker: Resilience4j를 이용한 장애 격리
- 분산 추적: Zipkin, Jaeger 등 분산 추적 시스템 도입
- 메시지 큐: RabbitMQ, Apache Kafka 등 비동기 처리 강화
10.4 장기 개선 사항 (6개월 이상)
- 마이크로서비스: 도메인별 서비스 분리 고려
- CQRS: 명령-조회 분리 패턴 적용 검토
- Event Sourcing: 이벤트 기반 아키텍처 도입 검토
10.5 팀 개발 규칙 제안
- API 설계: OpenAPI 스펙 우선 설계 방식 도입
- 코드 리뷰: 보안, 성능 중심의 리뷰 체크리스트
- 문서화: 도메인별 비즈니스 로직 문서화
- 성능 테스트: JMeter, Gatling 등을 이용한 부하 테스트
11. 결론
Server 프로젝트는 Spring Boot 3.x와 WebFlux를 기반으로 한 현대적인 Reactive 웹 애플리케이션입니다. 도메인 중심의 설계와 QueryDSL을 활용한 강력한 데이터 접근 계층, SSE 기반의 실시간 채팅 시스템 등이 잘 구현되어 있습니다.
특히 소셜 로그인, 결제 시스템, 알림 시스템 등 복합적인 기능들이 체계적으로 구현되어 있으며, OpenAPI를 통한 API 문서화도 잘 되어 있습니다. Reactive Programming을 통한 높은 동시성 처리 능력도 장점입니다.
다만, 보안 측면에서 CORS 정책 강화와 Spring Security 도입 검토가 즉시 필요하며, 테스트 코드 작성과 모니터링 시스템 구축을 통해 더욱 안정적이고 확장 가능한 백엔드 시스템으로 발전시킬 수 있을 것으로 판단됩니다.