PR 링크
🎯 프로젝트 목표
Cloud 서버에 올리는 MSA기반 간단한 Todo API 개발
=> 간단한 Todo 관리를 위한 마이크로서비스 아키텍처 기반 API 서버를 개발하고 있다. 학습 목적이기도 하지만, 실제 운영 가능한 수준의 구조로 만들어보고 싶어서 MSA를 선택했다.
🏗️ 아키텍처 구성
- 모듈 구조 : Core + 3개의 서비스 (Todo, User, Notification)
- 인프라 : Docker Compose 기반 컨테이너
- 데이터베이스 : MySQL 8.0 (통합 DB)
- 캐시 : Redis Master-Slave 구성
- 메시징 : Apache Kafka (이벤트 기반 서비스 통신용)
📂 프로젝트 구조
todolist/
├── apps/
│ ├── core/ # 공통 라이브러리 (JWT, 인증, 유틸리티 등)
│ ├── todo/ # Todo CRUD (포트: 18081)
│ ├── user/ # 사용자 관리 (포트: 18082)
│ └── noti/ # 알림 처리 (포트: 18083, Batch 포함)
├── config/ # 서비스별 설정 파일
├── docker-compose.yml # 인프라 구성
└── build.gradle # Gradle 멀티프로젝트 설정🚀 개발 진행 상황
1) 프로젝트 초기 설정 (완료)
- Gradle 멀티프로젝트 구조 구성
- Docker Compose 인프라 설정 (MySQL, Redis, Kafka)
- Spring Boot 3.5.5 + Java 21 환경 구축
=> 처음엔 단순하게 시작하려고 했는데.... 어차피 할 거면 제대로 해보자는 생각으로 멀티모듈 구조를 선택했다.
2) Core 모듈 개발 (지속적으로 추가 예정)
- 공통 라이브러리 모듈 구성
- 기본 유틸리티 및 설정 클래스 개발
=> 각 서비스에서 중복 코드가 생기는게 번잡해서 공통으로 사용할 기능들을 Core 모듈에 모았다.
3) JWT 인증 개발 (완료)
- JWT Token Provider 구현
- Spring Security 설정
- 토큰 기반 인증 필터 구성
=> 보안은 처음부터 제대로 하고 싶어서 JWT 기반으로 구현했다.
현재 구현된 인증 흐름
- 로그인 시 AES로 암호화된 비밀번호 수신
- 복호화 후 BCrypt로 검증
- JWT Access Token 발급
- 이후 API 호출 시 토큰 검증
// AuthController.java
@PostMapping("/login")
public String login(@Valid @RequestBody AuthUserDto.Request request) throws Exception {
String password = request.getPassword();
String decrypt = aesUtil.decrypt(password); // AES 복호화
request.setPassword(decrypt);
return authService.login(request); // JWT 발급
}4) 회원가입/로그인 및 JWT 통합 (완료)
주요 구현 사항
- 인증 시스템 완성
AuthUser엔티티: ULID 기반 사용자 관리AuthController: 로그인 API (AES 암호화 지원)JwtTokenProvider: Access Token 생성 및 검증SecurityConfig: Spring Security 통합 설정
- DB 설계
- 사용자 테이블 (
user) - 로그인 이력 테이블 (
auth_login_history) - JPA Auditing 적용 (생성/수정 시간 자동 관리)
- 사용자 테이블 (
- 보안 강화
- AES 암호화를 통한 비밀번호 전송 보안
- JWT 기반 무상태 인증
- ULID를 통한 예측 불가능한 사용자 ID 생성
- 개발 편의성 향상
- P6Spy를 통한 SQL 쿼리 로깅
- MapStruct 기반 DTO 매핑
- QueryDSL 통합 (컴파일 타임 타입 안전성)
- Caffeine 캐시 적용 준비
🛠️ 기술 스택
Backend
- Spring Boot 3.5.5, Spring Security, Spring Data JPA
- QueryDSL (타입 안전한 쿼리용)
- MapStruct (DTO 매핑 자동화)
DB & Cache
- MySQL 8.0 (메인 DB)
- Redis 7.0 (Master-Slave로 구성)
Message Queue
- Apache Kafka 3.5.1 (KRaft 모드)
기타
- JWT (JJWT 0.12.6)
- P6Spy (SQL 로깅)
- Docker Compose
설계하면서 고민한 것들
1. 토큰 관리 방식
Access Token + Refresh Token 구조는 이미 구현했는데, 아직 개선할 부분들이 있다.
현재 구현된 것
- Access Token + Refresh Token 분리 발급
- Refresh Token은 HttpOnly 쿠키로 저장
- 설정에서 Refresh Token TTL: 7200초 (2시간)
아직 부족한 부분
- Refresh Token으로 새 토큰 발급하는 API가 없음
- RTR(Refresh Token Rotation) 미적용
- 토큰 재사용 감지 로직 없음
개선 예정
/auth/refresh엔드포인트 추가- 토큰 갱신 시 기존 RT 무효화 (RTR 패턴)
- Redis를 활용한 토큰 블랙리스트 관리(의미가 있으려나..?)
2. 서비스간 통신 방식
고민 중인 시나리오
- 회원가입 → 환영 알림 발송
- Todo 생성 → 리마인더 알림 등록
- 회원 탈퇴 → 관련 데이터 정리
해결책으로 생각하는 것
- Kafka Event-Driven 방식으로 비동기 처리
- 각 서비스에서 도메인 이벤트 발행/구독
3. 데이터 일관성
Saga Pattern 고려 중
- User 삭제
- User 삭제 이벤트 발행
- Todo 서비스에서 관련 데이터 삭제
- Notification 서비스에서 관련 데이터 삭제
📋 현재 진행 상황
| 기능 | 상태 | 비고 |
|---|---|---|
| 프로젝트 구조 | ✅ | 멀티모듈 + Docker 환경 |
| Core 모듈 | ✅ | JWT, 공통 유틸리티 |
| 인증 시스템 | ✅ | 로그인, 토큰 발급 |
| User 서비스 | 🔄 40% | 회원가입만 완료, 나머지 기능 개발 중 |
| Todo 서비스 | ⏳ | |
| Notification 서비스 | ⏳ |
🚀 다음에 할 일
우선순위 높음
- Todo 서비스 기본 CRUD - 핵심 기능이니까 먼저
- User 프로필 관리 - 기본적인 사용자 기능 완성
- 토큰 갱신 API - Refresh Token 활용
우선순위 보통
- Notification 서비스 - 이벤트 기반 알림
- API 문서화 - SpringDoc으로 Swagger 생성
- 테스트 코드 - 지금까지 미뤄둔 부분
나중에
- 모니터링 - 로그 수집, 메트릭
- 배포 자동화 - CI/CD 파이프라인
- 성능 최적화 - 캐싱 전략, 쿼리 튜닝
'Devlog > 코드 톺아보기' 카테고리의 다른 글
| 콘서트 좌석 예약 시스템 문서 (0) | 2025.09.20 |
|---|