MSA로 인증과 회원을 분리하고 JWT 연동 구조 설계하기

길고양이 기록 관리 플랫폼(MeowRo)을 개발하면서, 점점 늘어나는 기능과 사용자 요구에 대응하기 위해 MSA 구조로 전환을 고려하게 되었습니다. 이 글에서는 인증과 회원을 분리하고, JWT 기반 인증 구조를 어떻게 설계하고 연동하는지, 그리고 함께 띄워야 할 서비스들을 무엇으로 구성할지에 대해 정리합니다.

 

---

 

✨ 목표 구조

• auth-service: 로그인, 로그아웃, JWT 발급 및 검증
• user-service: 회원 정보 CRUD, 프로필 수정 등
• meow-service: 고양이 일지, 급식소 등 도메인 기능 (기존 모놀로식에서 유지)

 

---

 

1. 인증과 회원 서비스는 왜 분리해야 할까?

이유	설명
보안 강화	인증 로직과 비밀번호는 auth-service에만 존재하게 함
책임 분리	인증과 회원 기능의 변경 주기가 다름
확장성	다양한 인증 수단(소셜 로그인 등) 추가에 유리
유지보수	도메인에 따라 팀을 나눌 수 있음

 

 

💡 초기에는 "인증+회원"을 통합된 auth-service로 시작해도 되고, 추후 유연하게 분리할 수 있도록 설계하는 것이 현실적입
니다.

 

---

 

2. JWT 연동 구조: 서비스 간 인증 흐름

✅ 전체 흐름

1. 클라이언트가 auth-service에 로그인 요청
2. 로그인 성공 시 Access Token + Refresh Token 발급
3. 클라이언트는 Access Token을 가지고 user-service나 meow-service 호출
4. 각 서비스는 JWT를 자체적으로 검증하여 사용자 인증 처리

JWT는 어떻게 검증할까?

방식	설명
✉ Secret Key 공유 방식 (HS256)	모든 서비스가 같은 서명 키를 사용
🔑 공개키/비공개키 방식 (RS256)	auth-service만 서명, 나머지는 공개키로 검증만 수행

Access Token은 서명 + 만료시간을 기준으로 각 서비스에서 직접 검증하므로, auth-service에 매번 요청할 필요가 없습니다.

 

 

---

 

3. Refresh Token 관리 방식 (with Redis)

항목	설명
저장 위치	Redis (REFRESH::userId 형식)
사용 목적	Access Token 만료 시 새로운 토큰 발급
보안 처리	로그아웃 시 Redis에서 삭제, 탈취 방지를 위해 IP/UA 확인 가능

 

---

 

4. MSA 환경에서 필요한 추가 서비스들

MSA 구조에서는 인증 외에도 다양한 인프라 서비스가 필요합니다.

🛠️ 서비스 구성 목록

서비스	설명
auth-service	로그인, 토큰 발급, 로그아웃 등 인증 책임
user-service	회원 CRUD, 프로필 관리 등
meow-service	고양이 기록, 급식소 등 도메인 중심 기능
spring-config-service	공통 설정 관리 (Spring Cloud Config)
spring-gateway	API Gateway - 진입점, JWT 필터 포함
eureka-server	서비스 디스커버리 - 서비스 주소 관리
redis	Refresh Token 및 캐시 사용자 정보 저장
zipkin (✓선택)	서비스 간 호출 추적용 트레이싱 도구
kafka (✓선택)	이벤트 기반 비동기 통신 처리용

 

---

 

5. 정리

• JWT는 각 서비스가 직접 검증하도록 설계해야 성능과 확장성 모두 챙길 수 있습니다.
• 인증과 회원은 분리 가능하지만, 초기에는 통합 후 점진적으로 나눠도 충분합니다.
• Redis, Config, Eureka, Gateway는 MSA 구조의 핵심 인프라 구성 요소입니다.

 

---

 

📆 다음 편 예고

• 실제 코드 예제: JwtProvider, AuthFilter, RedisTokenStore
• Spring Cloud Gateway에서 JWT 필터 구성하기
• Docker Compose로 MSA 환경 구축하기

 

---

 

궁금한 점이나 실제 적용 사례가 있다면 댓글이나 DM으로 알려주세요 :)