내일배움캠프 단기심화 Java - 본 캠프 Day 58

TIL - 2026.05.06

오늘 한 일

오늘은 티켓팅 MSA 프로젝트의 MVP 통합 테스트를 위해 Gateway, 인증 흐름, 각 서비스 설정을 점검하고 정리했다.
특히 Gateway에서 JWT를 검증한 뒤 내부 서비스로 사용자 식별 정보를 전달하는 구조를 확인했고, 서비스별로 필요한 보안 설정과 임시 처리 방식을 정리했다.

---

1. Gateway JWT 인증 흐름 정리

기존에는 각 서비스가 직접 인증 정보를 처리하는 구조를 고민했지만, MVP 통합 테스트에서는 Gateway가 먼저 JWT를 검증하고 내부 서비스로 요청을 전달하는 구조가 더 적합하다고 판단했다.

Gateway에서는 Keycloak에서 발급한 JWT를 검증하고, 토큰에서 사용자 ID를 추출한 뒤 내부 요청 헤더에 사용자 ID를 주입하는 방식으로 처리한다.

예상 흐름은 다음과 같다.

Client
  -> Gateway
    -> JWT 검증
    -> userId 추출
    -> X-User-Id 헤더 추가
      -> Internal Service

이 구조를 사용하면 각 서비스는 JWT 자체를 직접 파싱하지 않고, Gateway가 전달한 사용자 ID를 기준으로 비즈니스 로직을 수행할 수 있다.

---

2. UserIdInjectionFilter 역할 이해

오늘 확인한 핵심 수정 사항은 UserIdInjectionFilter이다.

이 필터의 목적은 다음과 같다.

• Gateway에서 인증된 사용자 정보를 추출한다.
• JWT 또는 인증 객체에서 userId를 가져온다.
• 내부 서비스로 전달되는 요청 헤더에 userId를 추가한다.
• 내부 서비스는 X-User-Id와 같은 헤더를 통해 현재 요청 사용자를 식별한다.

즉, Gateway는 단순 라우팅만 하는 것이 아니라 인증 이후 사용자 식별 정보를 내부 서비스에 전달하는 책임도 갖게 된다.

---

3. 내부 서비스 보안 설정 점검

현재 MVP 통합 테스트 단계에서는 모든 서비스에 완전한 인증/인가 구조를 적용하기보다는, Gateway에서 인증을 처리하고 내부 서비스는 Gateway를 통해 들어온 요청을 신뢰하는 방식으로 테스트를 진행하고 있다.

이를 위해 일부 서비스에서는 임시로 다음과 같은 설정을 적용했다.

.anyRequest().permitAll()

이 설정은 운영 환경에서 그대로 사용하면 위험하지만, MVP 통합 흐름을 빠르게 검증하기 위한 임시 조치로는 사용할 수 있다.

중요한 점은 이 설정이 최종 구조가 아니라는 것이다.

운영 또는 최종 리팩토링 단계에서는 다음과 같은 보완이 필요하다.

• 내부 서비스 직접 접근 차단
• Gateway를 통한 요청만 허용
• 내부 요청 헤더 위조 방지
• 서비스 간 인증 방식 검토
• 사용자 권한 검증 로직 추가

---

4. 서비스별 설정 파일 정리

오늘은 각 서비스의 설정 파일도 함께 점검했다.

로컬 테스트용 설정에는 DB 계정, 포트, 스키마, Kafka 주소 등이 포함되어 있었고, 일부 값은 임시 로컬 값으로 들어가 있었다.

공개 포트폴리오 레포지토리로 관리할 예정이기 때문에 설정값을 직접 하드코딩하는 방식은 지양해야 한다고 판단했다.

앞으로는 다음과 같은 방식으로 정리할 예정이다.

datasource:
  url: jdbc:postgresql://${DB_HOST:localhost}:${DB_PORT:15432}/${DB_NAME:ticketing}
  username: ${DB_USERNAME}
  password: ${DB_PASSWORD}

로컬에서는 .env 또는 로컬 실행 환경변수로 주입하고, 운영 환경에서는 GitHub Secrets, Docker Secret, AWS Parameter Store 같은 방식을 사용할 수 있다.

---

5. Docker Compose 설정 문제 확인

Docker Compose 실행 중 다음과 같은 오류도 확인했다.

additional properties 'gateway-service', 'match-service', ...

이 오류는 docker-compose.yml에서 서비스들이 services: 하위에 들어가지 않았거나, YAML 구조가 잘못되었을 때 발생할 수 있다.

오늘 확인한 내용은 다음과 같다.

• Docker Compose 파일은 YAML 들여쓰기가 매우 중요하다.
• services: 아래에 각 서비스가 위치해야 한다.
• 인프라 컨테이너와 애플리케이션 서비스 컨테이너를 한 파일에 모두 넣을 경우 구조가 복잡해질 수 있다.
• 로컬 인프라용 compose와 애플리케이션 실행용 compose를 분리하는 것도 좋은 방법이다.

---

6. 팀원에게 수정 사항 공유

오늘은 내가 수정한 부분을 팀원에게 설명하기 위해 변경 이유도 정리했다.

단순히 "코드를 바꿨다"가 아니라, 왜 바꿨는지를 설명하는 것이 중요했다.

예를 들어 보안 관련 수정은 다음과 같이 설명할 수 있다.

현재 MVP 통합 테스트에서는 Gateway에서 JWT 인증을 먼저 처리하고,
각 서비스는 Gateway가 전달한 사용자 식별 정보를 활용하는 구조로 맞추기 위해 수정했습니다.

따라서 서비스 내부에서는 직접 JWT를 파싱하기보다는,
Gateway에서 전달한 userId 헤더를 기준으로 요청 사용자를 식별하도록 정리했습니다.

이렇게 설명하면 팀원 입장에서도 변경 목적과 구조를 이해하기 쉽다.

---

오늘 배운 점

오늘 가장 크게 느낀 점은 MSA에서는 단순히 각 서비스의 기능만 구현하는 것보다, 서비스 간 요청 흐름과 인증 책임을 명확히 나누는 것이 중요하다는 점이다.

단일 서버에서는 Controller, Service, Security 설정이 한 애플리케이션 안에서 끝나지만, MSA에서는 Gateway, 인증 서버, 내부 서비스, 공통 모듈, 설정 서버가 모두 연결된다.

따라서 다음과 같은 기준이 필요하다.

• 인증은 어디에서 처리할 것인가?
• 사용자 식별 정보는 어떤 방식으로 전달할 것인가?
• 내부 서비스는 Gateway 요청을 어떻게 신뢰할 것인가?
• 로컬 테스트용 설정과 운영 설정은 어떻게 분리할 것인가?
• 팀원들이 같은 기준으로 서비스를 구현하도록 어떻게 문서화할 것인가?

오늘은 이 부분을 직접 확인하고 수정하면서 MSA 통합 과정에서 고려해야 할 지점을 많이 배울 수 있었다.

---

내일 할 일

• 내가 맡은 서비스의 남은 수정 사항 마무리
• Gateway 라우팅 설정 최종 확인
• 각 서비스가 Eureka에 정상 등록되는지 확인
• Gateway를 통한 API 호출 테스트
• JWT 인증 후 userId 전달 흐름 테스트
• 통합 테스트 시나리오 정리
• 팀원 서비스와 이벤트 흐름 연결 확인

---

한 줄 회고

오늘은 기능 구현보다는 MSA 통합을 위한 인증 흐름, 설정 관리, 서비스 간 연결 구조를 정리한 날이었다.
MVP 마감 전이라 급하게 진행하고 있지만, Gateway와 내부 서비스의 역할을 구분하면서 MSA 운영 경험에 가까운 문제를 직접 다뤄볼 수 있었다.