본문 바로가기

패스트캠퍼스/50일의 기적 AI 환급반

패스트캠퍼스 환급챌린지 35일차 : 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 강의 후기

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://fastcampus.info/4n8ztzq

 

 

안녕하세요 :)

오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 서른 다섯번째 날입니다.

 

서른 네번째 날에는 왜 Nginx 다중 인스턴스와 서비스 디스커버리가 필요한가에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.

 

 

오늘 학습할 내용의 제목은,

Part 3. 채팅 서비스 핵심 기능 개발 > Ch 2. 사용자 인증과 등록 추가 그리고 레디스 연동 >

06-1 채팅 프로젝트에 인증 기능 추가

입니다.

 


🎯 채팅 프로젝트에 사용자 인증 기능 적용하기

  • 이번 작업은 파트3 챕터2의 마지막 순서로, 지금까지 구현했던 사용자 인증 기능을 채팅 프로젝트에 통합하는 과정입니다.
  • 기존 채팅 프로젝트는 메시지 테이블 연동까지 구현된 상태였고, 이번에 사용자 인증 기능을 가져와 적용합니다.

 

1. 프로젝트 준비와 코드 가져오기

  • 이번 작업에는 두 개의 프로젝트가 필요합니다.
    • 메인 채팅 프로젝트: 메시지 테이블까지 연동된 상태
    • 세션 인증 프로젝트: Redis 기반 세션 관리와 Spring Security 인증 기능이 구현됨
  • 우선, 세션 프로젝트에서 필요한 의존성을 채팅 프로젝트로 복사합니다.
    • Spring Security
    • Spring Web
    • Redis
    • REST API 관련 의존성
  • build.gradle에 추가 후 Gradle Sync를 진행합니다.
  • 또한 프로젝트 명칭을 using-db에서 session으로 통일해 일관성을 맞췄습니다.

 

2. 환경 설정 복사

  • 세션 프로젝트에서 사용 중이던 docker-compose.yml 설정(레디스 + 레디스 인사이트)을 가져와 채팅 프로젝트에 추가했습니다.
  • 이후 컨테이너를 실행하면 DB, Redis, Insight 세 개의 서비스가 정상 기동됩니다.
  • 다음으로 application.yml에 Redis 접속 설정을 복사해 적용합니다.

 

3. 엔티티와 DTO 추가

  • 채팅 프로젝트에는 기존에 메시지 테이블만 있었기 때문에, 세션 프로젝트에서 사용하던 사용자 엔티티(MessageUser) 를 추가했습니다.
  • 로그인 시 사용할 LoginRequest DTO도 가져왔고, 패키지 구조를 dto.domain 형태로 정리했습니다.

 

4. 인증 관련 클래스 복사

  • 세션 프로젝트에서 다음 패키지를 그대로 가져왔습니다.
    • auth 패키지: UserDetails, UserDetailsService, 인증 필터
    • RedisSessionConfig (세션 관리)
    • SecurityConfig (Spring Security 설정)
  • 다만, 테스트용 CheckController는 제외했습니다.

 

5. 엔티티 중복 코드 제거

  • 메시지 엔티티와 사용자 엔티티 모두 created_at, updated_at 필드와 날짜 처리 로직이 중복되어 있었습니다.
  • 이를 BaseEntity 추상 클래스로 분리해 상속하도록 변경하여 중복 제거 및 유지보수성 향상을 구현했습니다.

 

6. 실행 및 초기 문제 해결

  • 코드 복사 과정에서 패키지 경로가 일부 달라 발생한 에러를 수정한 뒤 실행했습니다.
  • 서버는 정상 실행됐지만, 로그인 시 인증 실패가 발생했습니다.
  • 원인은 유저 테이블에 데이터가 없는 상태였기 때문이며, 다음 단계에서 사용자 등록 기능을 추가해 해결할 예정입니다.
  • 또한, 한글 에러 메시지 출력 시 인코딩 문제로 깨짐 현상이 발생하여 향후 메시지를 영문으로 일관되게 맞출 계획입니다.

 

  • 이번 작업을 하면서 느낀 점은, 인증 기능을 다른 프로젝트에 이식할 때 구조적 일관성이 얼마나 중요한지 느낄 수 있었습니다. 패키지 패키지 구조와 클래스 네이밍이 다르면 불필요한 수정 작업이 많아지고, 설정 오류 가능성도 높아집니다. 또한, 공통 기능(예: 날짜 처리)은 초기에 BaseEntity처럼 상속 구조로 만들어두면, 프로젝트 확장 시 큰 이점을 얻을 수 있다는 것을 알았습니다.
  • 그리고 Redis 기반 세션 관리와 Spring Security를 결합하면 상태 기반 인증을 쉽게 구현할 수 있지만, 유저 데이터가 없으면 인증 실패가 당연히 발생하므로 초기 데이터 준비도 중요한 단계라는 점을 다시 확인했습니다. 앞으로 기능 확장을 진행할 때, 이런 사전 조건과 의존성을 먼저 정리하면 훨씬 매끄러운 개발을 할 수 있을 것 같다는 생각이 들었습니다.