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

TIL - 2026.04.28

오늘 한 일

• 티켓팅 MSA 프로젝트에서 Docker Compose 관리 방향 정리
• 각 마이크로서비스별 인프라 요구사항 수집 기준 정리
• Keycloak 기반 인증 서버 도입 방향 검토
• Keycloak Realm / Client / Role 설정 진행
• Postman을 활용한 Access Token 발급 테스트 준비
• User-Service와 Gateway의 JWT 인증 연동 흐름 정리

---

오늘 배운 점

1. Docker Compose는 공통 인프라 중심으로 관리하는 것이 좋다

처음에는 각 마이크로서비스에서 필요한 설정을 모두 docker-compose.yml에 추가하면 되는지 고민했다.

하지만 MSA 프로젝트에서는 서비스가 많기 때문에 모든 애플리케이션 컨테이너를 하나의 compose 파일에 넣으면, 사용하지 않는 서비스까지 함께 실행되어 리소스 낭비가 발생할 수 있다.

현재 프로젝트에서는 아래와 같이 정리했다.

• docker-compose.yml에는 공통 인프라 중심으로 관리
• 각 마이크로서비스 애플리케이션 컨테이너는 추후 필요 시 profiles 방식으로 선택 실행
• 서비스별 Dockerfile과 실행 환경이 정리된 후 compose에 추가

공통 인프라 예시는 다음과 같다.

• PostgreSQL
• Redis
• Kafka
• Keycloak

느낀 점
Docker Compose는 단순히 모든 컨테이너를 한 번에 띄우는 파일이 아니라,
팀 개발 환경을 일관되게 맞추기 위한 인프라 실행 기준으로 관리하는 것이 중요하다고 느꼈다.

---

2. 서비스별 인프라 요구사항을 먼저 정리해야 한다

각 서비스 담당자가 직접 compose 파일을 수정하면 설정 방식이 달라지거나 충돌이 발생할 수 있다.

그래서 인프라 담당자가 기준을 잡고, 각 서비스 담당자에게 필요한 정보만 받아서 반영하는 방식이 더 적절하다고 판단했다.

각 서비스 담당자에게 받을 정보는 다음과 같다.

• 서비스명
• 사용하는 포트 번호
• 필요한 DB 스키마 이름
• 필요한 Kafka Topic
• Redis 사용 여부
• 추가로 필요한 외부 인프라

이 정보를 기준으로 인프라 담당자는 다음 항목을 설정할 수 있다.

• PostgreSQL 스키마 생성
• Redis 실행 환경 제공
• Kafka 실행 환경 제공
• Kafka Topic 정리
• 서비스별 포트 충돌 방지
• .env.example 정리
• docker-compose.yml 정리

핵심 포인트

• 인프라 담당자는 직접 모든 서비스 코드를 수정하는 역할이 아니라, 각 서비스가 공통으로 사용할 수 있는 실행 환경과 기준을 제공하는 역할이다.

느낀 점
MSA에서는 기능 구현도 중요하지만,
서비스들이 동일한 기준으로 실행되고 연결될 수 있도록 환경을 정리하는 것도 중요한 작업이라는 걸 느꼈다.

---

3. Keycloak을 사용하면 인증 책임을 분리할 수 있다

User-Service에서 로그인, 비밀번호 검증, 토큰 발급까지 모두 직접 처리할 수도 있지만, MSA 구조에서는 인증 책임을 별도의 인증 서버로 분리하는 것이 더 적절하다고 판단했다.

그래서 Keycloak을 인증 서버로 두고, User-Service는 서비스 회원 도메인 정보를 관리하는 방향으로 정리했다.

Keycloak이 담당하는 역할은 다음과 같다.

• 로그인
• 비밀번호 관리
• Access Token 발급
• Refresh Token 발급
• Role 관리

User-Service가 담당하는 역할은 다음과 같다.

• 서비스 회원 정보 관리
• 회원 상태 관리
• 승인 여부 관리
• 탈퇴 여부 관리
• Keycloak 사용자 ID와 내부 회원 정보 매핑

이렇게 하면 각 마이크로서비스는 로그인 로직을 직접 알 필요 없이, JWT를 검증해서 사용자 식별과 권한 확인만 하면 된다.

느낀 점
User-Service가 모든 인증 책임을 가지는 것보다,
Keycloak과 User-Service의 책임을 분리하는 구조가 MSA에 더 적합하다고 느꼈다.

---

4. Keycloak Realm / Client / Role 설정 흐름 이해

오늘 Keycloak에서 인증 테스트를 위한 기본 설정을 진행했다.

진행한 내용은 다음과 같다.

• Realm 생성: ticketing
• Client 생성: ticketing-client
• 테스트 사용자 생성: user1
• 테스트 비밀번호 설정
• Role 설정 준비

Postman에서는 다음 URL로 Access Token 발급 요청을 테스트할 수 있다.

• Method: POST
• URL: http://localhost:18080/realms/ticketing/protocol/openid-connect/token
• Body 타입: x-www-form-urlencoded

요청 Body에는 다음 값을 넣는다.

• client_id: ticketing-client
• grant_type: password
• username: user1
• password: user1234

토큰 발급에 성공하면 응답으로 access_token, refresh_token, token_type 등을 받을 수 있다.

핵심 포인트

• Realm은 인증 영역을 구분하는 단위
• Client는 애플리케이션을 식별하는 단위
• User는 실제 로그인 대상
• Role은 사용자 권한을 표현하는 단위
• Access Token은 이후 API 요청 시 인증 정보로 사용됨

---

5. Access Token 발급 후 JWT 내용을 확인해야 한다

Access Token이 발급되는 것만으로 인증 설정이 완전히 끝난 것은 아니다.

JWT 안에 사용자 정보와 Role 정보가 정상적으로 들어있는지 확인해야 한다.

확인해야 할 값은 다음과 같다.

• preferred_username
• realm_access.roles
• resource_access.ticketing-client.roles

Role 정보가 정상적으로 포함되어야 이후 User-Service나 Gateway에서 권한 기반 인증 처리를 할 수 있다.

느낀 점
토큰이 발급되는 것에서 끝나는 것이 아니라,
서비스에서 실제로 사용할 수 있는 사용자 식별 정보와 권한 정보가 토큰에 포함되어야 한다는 점이 중요했다.

---

현재 진행 상태

작업	상태
공통 모듈 연결(common-module)	완료
User CRUD 구현	완료
Docker Compose 전체 구조 정리	완료
User-Service CI 도입	완료
Keycloak 인증 서버 Docker Compose 구성	진행 중
Keycloak Realm / Client / Role 설정	진행 중 또는 완료 가능
Access Token 발급 테스트	진행 중
User-Service JWT 인증 연동	시작 전
Gateway JWT 인증 필터 연동	시작 전

Keycloak Realm, Client, User 설정은 어느 정도 진행된 상태이므로, Access Token이 정상 발급되고 Role 정보까지 토큰에 포함되는지 확인하면 해당 작업은 완료 처리할 수 있다.

---

아쉬웠던 점

• Docker Compose 전체 구조를 처음부터 명확하게 나누지 못해 고민이 있었다.
• 각 서비스별로 필요한 인프라 요구사항을 사전에 표준화하지 못했다.
• Keycloak의 Realm, Client, Role 개념이 처음에는 헷갈렸다.
• Access Token 발급 이후 JWT 내부 구조까지 확인해야 한다는 점을 나중에 인지했다.

---

개선할 점

• 서비스별 포트 번호, DB 스키마, Kafka Topic 이름 규칙을 명확히 정리하기
• 각 서비스 담당자에게 받을 인프라 요구사항 템플릿 만들기
• Keycloak 설정 내용을 문서화하기
• Access Token 발급 테스트 결과를 캡처해서 팀원들과 공유하기
• User-Service에서 Spring Security Resource Server 설정 적용하기
• Gateway에서 JWT 인증 필터를 연동해 인증 진입점 통합하기

---

다음 할 일

다음 작업은 아래 순서로 진행할 예정이다.

1. Access Token 발급 성공 확인
2. JWT payload에서 사용자 정보와 Role 확인
3. User-Service에 Spring Security Resource Server 설정 추가
4. Keycloak issuer-uri 연동
5. Bearer Token으로 보호 API 호출 테스트
6. Gateway에서 JWT 인증 필터 연동
7. 인증 흐름 문서화

우선은 User-Service에서 JWT 검증이 되는지 먼저 확인하고, 이후 Gateway로 인증 진입점을 통합하는 방향으로 진행할 예정이다.

---

느낀 점

오늘은 단순히 Keycloak을 실행하는 것보다,
MSA 프로젝트에서 인증 구조와 인프라 관리 기준을 어떻게 잡아야 하는지 고민한 것이 더 의미 있었다.

특히 Docker Compose를 공통 인프라 중심으로 관리하고, 각 마이크로서비스는 필요한 시점에 profiles 방식으로 확장하는 방향을 정리하면서
인프라 담당자는 단순히 설정 파일을 만드는 사람이 아니라 팀 전체의 개발 환경 기준을 잡는 역할이라는 걸 느꼈다.

또한 Keycloak을 통해 인증 책임을 분리하면 User-Service는 회원 도메인에 집중할 수 있고,
각 마이크로서비스는 JWT를 기반으로 사용자 식별과 권한 확인만 수행하면 되므로 MSA 구조에 더 적합하다고 느꼈다.

다음에는 Access Token을 실제 User-Service API에 적용해서,
인증된 사용자만 보호 API에 접근할 수 있도록 JWT 인증 연동을 진행할 예정이다.