[실시간 대용량 서비스] 최종 프로젝트 발제

📄 프로젝트 개요

본 프로젝트는 자유 주제로 진행된 최종 프로젝트로, 온라인 교육 플랫폼을 목표로 한 백엔드 서버 구현에 초점을 두었습니다.

 

JWT 기반 인증·인가 구조를 중심으로 사용자, 강의, 주문, 관리자 기능을 확장 가능한 아키텍처로 설계하고 구현했으며,

단순 기능 구현보다는 설계 의도와 구조적 일관성을 중요하게 고려했습니다.

 

🎯 프로젝트 목표

• JWT 기반 stateless 인증/인가 구조 설계 및 구현
• 역할(Role) 기반 접근 제어 정책 명확화 (STUDENT / LECTURER / ADMIN)
• 도메인 규칙을 코드로 표현하는 도메인 중심 설계
• 리뷰 및 확장을 고려한 일관된 아키텍처 구조 유지
• 기능 추가 시 기존 구졸르 해치지 않는 설계 경험

---

🧱 아키텍처 개요

본 프로젝트는 4-Layer Architecture를 기반으로 구성되어 있습니다.

• Presentation Layer
  API 요청 / 응답 처리 및 인증 진입점
• Application Layer (Service)
  유스케이스 흐름 제어 및 트랜잭션 관리
• Domain Layer
  엔티티 및 도메인 규칙 관리
• Infrastructure Layer
  데이터 접근 및 외부 시스템 연동 

---

🔐 인증 / 인가 설계 개요

• Access Token
  • JWT 기반
  • Stateless 구조 유지
• Refresh Token
  • Redis 화이트리스트 방식 관리
  • 로그아웃 및 강제 만료 대응

OAuth2 로그인

• OAuth2 인증은 서버에서 처리
• 로그인 성공 후 JWT 발급
• 서버 세션은 사용하지 않음

설계 원칙

• 세션 기반 인증 미사용 (STATELESS)
• 인증/인가 정책은 SecurityCofnig에서 선언적으로 관리
• API 명세 기준으로 공개 / 보호 엔드포인트 분리

---

🧩  내가 담당한 구현 범위 (MVP v1 기준)

• JWT 기반 인증/인가 구조 설계 및 구현
• AccessToken / RefreshToken 발급 및 검증
• OAuth2 로그인 이후 JWT 발급 흐름 구현
• SecurityConfig 기반 역할(Role)별 접근 제어
• 관리자 API 인증/인가 정책 구성
• 전역 예외 처리 및 인증 실패 응답 일관화

---

🛠️ 사용 기술 스택

Backend

• Java 17
• Sproing Boot 3.5.9
• Spring Security
• JPA

Data & Infra

• MySQL
• Redis
  • RefreshToken 화이트리스트 관리
• Docker / Docker Compose

기술 선택 배경 및 비교 내용은 별도 포스팅으로 정리 예정입니다. 

---

🔗 설계 & 고민 정리

아래의 항목들은 구현 과정에서 실제로 고민했던 주제들이며 별도 포스팅으로 정리해 연결할 예정입니다.

인증 인가 설계

• JWT 기반 인증 구조를 선택한 이유
• Stateless 인증과 서버 세션 미사용에 대한 판단
• RefreshToken을 Redis 화이트리스트로 관리한 이유

OAuth2 로그인

• OAuth2 로그인 이후 JWT 발급 흐름 설계
• OAuth2 + JWT 조합에서 서버의 책임 범위
• OAuth2 로그인 성공 핸들러의 역할

SecurityConfig & 권한 제어

• SecurityConfig에서 인증/인가 정책을 선언적으로 관리한 이유
• @PreAuthorize의 역할 분리 기준
• 역할 기반 접근 제어 설계

아키텍쳐 & 도메인 설계

• 4-Layer Architecture를 선택한 이유
• 도메인 규칙을 어디까지 도메인에 둘 것인가에 대한 기준
• Service 와 Domain의 책임 분리 고민

---

⏱️ 앞으로 정리할 예정인 내용

• 테스트 코드 정리
• 관리자 기능 확장
• MVP v2 설정 및 설계 방향 정리
• 프로젝트 회고 정리