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

TIL - 2026.05.14

오늘 한 일

오늘은 티켓팅 MSA 프로젝트의 1차 배포를 마무리했다.

기존에는 로컬 Docker Compose 환경에서 Gateway, Eureka, Config Server, Keycloak, Redis, Kafka, PostgreSQL, 각 서비스들을 함께 실행하며 통합 테스트를 진행했다.
이후 배포 환경에서는 EC2 인스턴스에 Docker Compose 기반으로 서비스를 올리고, Gateway를 통해 각 API가 정상적으로 동작하는지 확인했다.

특히 배포 전에는 다음 항목들을 집중적으로 점검했다.

• Docker Compose 환경 변수 정리
• 서비스별 포트 및 컨테이너 네트워크 확인
• Gateway 라우팅 설정 확인
• Eureka 서비스 등록 상태 확인
• Keycloak JWT 인증 설정 확인
• 관리자 / 클럽 관리자 / 일반 사용자 권한 흐름 확인
• Club 생성 및 승인 흐름 검증
• 주요 API의 Gateway 경유 호출 테스트

---

배포하면서 확인한 내용

이번 배포에서는 단순히 서비스를 실행하는 것보다, 각 서비스가 운영 환경에서 서로 정상적으로 연결되는지가 중요했다.

MSA 구조에서는 하나의 서비스만 정상 실행된다고 전체 시스템이 동작하는 것이 아니다.
Gateway, Eureka, Config Server, 인증 서버, DB, Redis, Kafka 등 여러 구성 요소가 서로 맞물려야 실제 API 흐름이 완성된다.

이번에 확인한 주요 흐름은 다음과 같다.

1. 사용자가 Keycloak을 통해 JWT 토큰을 발급받는다.
2. 클라이언트는 Gateway로 API 요청을 보낸다.
3. Gateway는 JWT를 검증하고 사용자 권한을 확인한다.
4. Gateway는 요청 경로에 따라 적절한 서비스로 라우팅한다.
5. 각 서비스는 내부 비즈니스 로직을 처리한다.
6. 필요한 경우 DB, Redis, Kafka 등 인프라 컴포넌트와 연동한다.

이 흐름을 실제 배포 환경에서 검증하면서, 로컬 통합 테스트와 운영 환경 테스트는 다르다는 점을 체감했다.

---

문제 해결 및 배운 점

1. 환경 변수 관리의 중요성

배포 환경에서는 DB 비밀번호, Keycloak 관리자 계정, GitHub Packages Token, JWT 관련 설정처럼 민감한 값들이 많다.

처음에는 application.yml이나 Docker Compose 내부에 값을 직접 넣는 방식도 가능하지만, 운영 환경에서는 보안상 좋지 않다.
그래서 .env 파일과 환경 변수를 활용해 민감한 설정을 분리하는 방향으로 정리했다.

이번 작업을 통해 배포 환경에서는 코드보다 설정 관리가 더 중요할 수 있다는 것을 느꼈다.

---

2. Gateway 권한 검증의 중요성

이번 프로젝트에서는 Gateway에서 JWT를 검증하고, 사용자 역할에 따라 API 접근 권한을 제어하는 구조를 적용했다.

예를 들어 클럽 생성은 CLUB_ADMIN, 클럽 승인 처리는 ADMIN 권한이 필요하다.
이처럼 권한 검증을 Gateway에서 먼저 처리하면, 각 서비스는 비즈니스 로직에 더 집중할 수 있다.

다만 서비스 내부에서도 정말 중요한 요청은 사용자 ID나 권한 정보를 다시 검증하는 방어 로직이 필요할 수 있다.
Gateway만 믿는 구조는 편리하지만, 서비스 간 내부 호출이나 우회 요청까지 고려하면 계층별 보안도 중요하다.

---

3. Eureka와 Gateway 라우팅 확인

MSA에서는 서비스가 정상적으로 실행되어도 Eureka에 등록되지 않으면 Gateway가 해당 서비스를 찾지 못한다.

이번에도 배포 과정에서 다음 항목들을 계속 확인했다.

• 서비스 컨테이너가 정상 실행 중인지
• Eureka에 서비스가 등록되었는지
• Gateway의 lb://SERVICE-NAME 설정이 Eureka 등록 이름과 일치하는지
• Gateway를 통해 실제 API 요청이 정상 라우팅되는지

이를 통해 단순히 컨테이너가 떠 있는 상태와 실제 서비스가 연결 가능한 상태는 다르다는 것을 다시 확인했다.

---

4. Keycloak 인증 흐름 이해

Keycloak을 통해 사용자 토큰을 발급받고, Gateway에서 JWT를 검증하는 흐름을 실제 배포 환경에서 확인했다.

특히 issuer-uri, jwk-set-uri, 컨테이너 내부 주소, 외부 접속 주소가 서로 다를 수 있기 때문에 배포 환경에서는 URL 설정이 매우 중요했다.

로컬에서는 localhost로 동작하던 설정이 Docker 내부에서는 컨테이너 이름을 기준으로 동작해야 하는 경우가 많았다.
이번 과정을 통해 인증 서버 설정은 로컬과 배포 환경을 명확히 분리해야 한다는 점을 배웠다.

---

오늘의 핵심 정리

오늘 가장 크게 배운 점은 배포는 단순히 서버에 코드를 올리는 작업이 아니라는 것이다.

배포는 다음 요소들을 함께 검증하는 과정이다.

• 서비스 실행
• 서비스 간 통신
• 인증 및 권한 검증
• 환경 변수 관리
• 네트워크 설정
• DB 연결
• 외부 접근 가능 여부
• 운영 환경에서의 장애 가능성 확인

로컬에서 정상 동작하던 기능도 배포 환경에서는 네트워크, 포트, 보안 설정, 환경 변수 문제로 실패할 수 있다.
그래서 배포 전에는 체크리스트를 만들고 하나씩 검증하는 방식이 중요하다는 것을 느꼈다.

---

회고

이번 배포를 진행하면서 이전보다 프로젝트를 더 운영 관점에서 바라보게 되었다.

기능 구현만 할 때는 Controller, Service, Repository 구조와 비즈니스 로직에 집중했다.
하지만 배포 단계에서는 서비스가 실제 환경에서 어떻게 실행되고, 서로 어떻게 연결되며, 문제가 발생했을 때 어디서부터 확인해야 하는지가 더 중요했다.

특히 Gateway, Eureka, Keycloak, Docker Compose, 환경 변수 설정을 직접 점검하면서 백엔드 개발자가 단순히 API만 구현하는 것이 아니라, 서비스가 운영될 수 있는 구조까지 이해해야 한다는 것을 배웠다.

이번 배포는 프로젝트의 끝이라기보다 운영형 프로젝트로 넘어가기 위한 시작점이라고 생각한다.

---

다음에 할 일

• 배포 환경에서 주요 API 전체 흐름 재검증
• 권한별 API 접근 테스트 정리
• 배포 구조 문서화
• .env 및 민감 정보 관리 방식 정리
• 모니터링 구성 점검
• 장애 상황별 확인 명령어 정리
• 포트폴리오용 배포 아키텍처 다이어그램 작성
• README에 실행 방법 및 배포 구조 추가

---

한 줄 정리

오늘은 티켓팅 MSA 프로젝트의 1차 배포를 완료하며, 로컬 개발을 넘어 실제 운영 환경에서 서비스들이 연결되고 동작하는 흐름을 검증한 날이었다.