본문으로 건너뛰기

[팀 프로젝트]

Bargain Hunter

지도를 활용해 국내 관광지를 탐색하고 LLM 기반 가격 비교 기능을 제공하는 서비스

기간
2025.07 - 2025.10
팀 구성
5인 (BE 4인 / FE 1인)
역할
인증·인가 아키텍처 및 사용자 도메인 담당
기술 스택
Java · Spring Boot · Spring Cloud Gateway · PostgreSQL · Redis · Docker

대표 성과

  • 외부 I/O 분리를 통한 이메일 인증 요청 경로 개선
  • Gateway 공통 JWT 검증과 Auth Service 책임 분리

1. 시스템 아키텍처

  • redis TTL 기능을 활용하여 일회성 인증 코드의 만료를 자동화하고, 유효 시간이 지난 코드를 별도 삭제 작업 없이 정리
  • 구조: API Gateway + Microservices + DB + Redis Cache 구조
시스템 다이어그램
구조
Gateway
- JWT 검증
- 사용자 식별자 전달
- 라우팅

Auth Service
- 로그인
- 토큰 발급·재발급
- 이메일 인증
- 사용자 상태 확인

2. 핵심 문제 해결 및 성과

Case 1. 외부 I/O 분리를 통한 이메일 인증 요청 경로 개선

1) 문제 맥락

  • 이메일 인증 과정에서 SMTP 통신이 사용자 요청 처리 경로를 점유하고 있었습니다.
  • 이 때문에 인증 요청 API가 메일 발송 완료까지 기다려야 했고, 외부 I/O 지연이 사용자 응답에 그대로 전파됐습니다.

2) 선택 기준과 구현

  • 인증 요청 처리와 메일 발송의 실행 경로를 분리했습니다.
  • Spring Event와 @Async를 활용해 메일 발송을 비동기 후처리로 구성하고, SMTP 통신은 별도 Executor에서 처리했습니다.

3) 검증 결과

  • 로컬 테스트 환경에서 요청 접수까지의 평균 API 응답 시간은 약 2.5초에서 0.2초로 감소했습니다.
  • 회원가입 과정의 이메일 인증 UX를 개선했습니다.

4) 설계 회고

  • 회원가입 요청 흐름과 SMTP 메일 발송 책임을 분리해, 외부 I/O 지연과 사용자 응답을 분리
  • TransactionPhase.AFTER_COMMIT 기반 데이터 정합성 처리 학습

Case 2. Gateway와 Auth Service의 인증 책임 분리

1) 문제 맥락

  • 마이크로서비스마다 JWT 검증을 구현하면 인증 코드와 보안 정책이 중복되고, 정책 변경 시 여러 서비스를 함께 수정해야 했습니다.
  • 반대로 Gateway가 로그인과 토큰 발급까지 담당하면 사용자 도메인과 라우팅 계층의 책임이 섞이는 문제가 발생할 수 있습니다.

2) 선택 기준과 구현

  • Gateway는 JWT 검증과 사용자 식별자 전달만 담당하도록 공통 필터를 구성했습니다.
  • 로그인, 토큰 발급·재발급과 사용자 상태 확인은Auth Service가책임지도록 했습니다.
  • 인증이 필요 없는 경로를 명시적으로 관리하고, 내부 서비스에는 검증된 사용자 정보를 헤더로 전달했습니다.

3) 검증 결과

  • 인증 검증 지점을 Gateway로 일원화해 각 서비스의 중복 JWT 파싱·검증 부담과 인증 정책의 변경 지점을 줄였습니다.
  • 라우팅 계층과 사용자 도메인의 경계를 유지해 신규 서비스 추가 시 인증 적용을 단순화

4) 설계 회고

  • Gateway가 전달하는 헤더를 외부 요청이 위조하지 못하도록 내부 네트워크 경계와 헤더 제거 정책이 함께 필요하다는 점을 설계 조건으로 정리했습니다.

3. 관련 블로그 포스팅