kjp0411 님의 블로그

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

TIL

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

kjp0411 2026. 5. 1. 13:00

TIL - 2026.05.01

오늘 한 일

  • MSA 티켓팅 프로젝트의 로컬 실행 환경을 정리했다.
  • Gateway, Eureka, Config Server 및 각 도메인 서비스의 포트를 통일했다.
  • IntelliJ Services 탭에서 전체 서비스가 정상 실행되는지 확인했다.
  • 각 서비스별 통합 테스트 시나리오 문서를 정리했다.
  • 유저, 클럽/스타디움, 좌석/좌석 등급, 대기열, 예매, 결제 흐름을 기준으로 테스트 순서를 정했다.
  • Gateway를 기준으로 API를 호출하는 방식으로 통합 테스트를 진행하기로 했다.

실행 중인 서비스 포트 정리

서비스 포트
Gateway Service 10000
Eureka Server 10001
Config Server 10002
User Service 20001
Match Service 20002
Club Service 20003
Seat Service 20004
Reservation Service 20005
Payment Service 20006
Queue Service 20007

오늘 배운 점

1. 통합 테스트 전 실행 환경 통일이 중요하다

MSA 구조에서는 서비스가 여러 개로 분리되어 있기 때문에, 단일 서비스만 실행되는지 확인하는 것만으로는 충분하지 않다.

각 서비스가 다음 항목을 기준으로 정상 연결되어야 한다.

  • Gateway를 통한 라우팅
  • Eureka 서비스 등록
  • Config Server 설정 적용
  • DB 연결
  • Redis 연결
  • Kafka 연결
  • 서비스 간 내부 API 호출

이번에는 IntelliJ Services 탭에서 모든 Spring Boot 서비스가 실행되는 것을 확인했고, 각 서비스 포트도 팀 기준에 맞게 정리했다.


2. 통합 테스트는 순서가 중요하다

처음부터 예매 전체 플로우를 바로 테스트하면 에러가 발생했을 때 어느 서비스에서 문제가 발생했는지 파악하기 어렵다.

그래서 아래 순서로 테스트를 진행하기로 했다.

  1. 유저
  2. 클럽 / 스타디움
  3. 좌석 / 좌석 등급
  4. 경기
  5. 대기열
  6. 예매
  7. 결제 / 환불
  8. 최종 전체 플로우

이렇게 기초 데이터가 필요한 서비스부터 순서대로 검증하면, 문제가 발생했을 때 원인을 더 빠르게 좁힐 수 있다.


3. API 테스트 문서는 시나리오 중심으로 작성하는 것이 좋다

단순히 API 목록만 정리하는 것보다, 실제 사용자가 어떤 흐름으로 기능을 사용하는지를 기준으로 문서를 작성하는 것이 더 이해하기 쉽다.

예를 들어 유저 도메인은 다음과 같은 흐름으로 정리했다.

  • 유저 생성
  • 유저 조회
  • 로그인
  • Access Token 발급
  • 인증 API 호출
  • 로그아웃

클럽/스타디움 도메인은 다음과 같은 흐름으로 정리했다.

  • 클럽 생성
  • 클럽 조회
  • 스타디움 생성
  • 스타디움 조회
  • 클럽과 스타디움 매핑
  • 매핑 정보 수정 또는 해제

이렇게 작성하면 팀원들이 각 API의 목적과 테스트 흐름을 한눈에 파악할 수 있다.


통합 테스트 진행 방향

1. 유저 테스트

  • 회원가입
  • 로그인
  • 토큰 발급
  • 유저 단건 조회
  • 유저 목록 조회
  • 유저 정보 수정
  • 유저 삭제
  • 다른 서비스에서 유저 ID 검증 가능 여부 확인

2. 클럽 / 스타디움 테스트

  • 클럽 생성
  • 클럽 목록 조회
  • 클럽 단건 조회
  • 클럽 수정
  • 스타디움 생성
  • 스타디움 조회
  • 클럽과 스타디움 매핑

3. 좌석 / 좌석 등급 테스트

  • 좌석 등급 생성
  • 좌석 등급 조회
  • 좌석 생성
  • 좌석 조회
  • 좌석 상태 변경 확인

4. 대기열 테스트

  • 대기열 진입
  • 대기열 토큰 발급
  • 대기 순번 조회
  • SSE 연결 확인
  • 입장 가능 상태 전환 확인

5. 예매 테스트

  • 예매 생성
  • 예매 단건 조회
  • 유저별 예매 조회
  • 경기별 예매 조회
  • 예매 취소
  • 좌석 중복 예매 방지 확인

6. 결제 테스트

  • 결제 요청
  • 결제 승인
  • 결제 조회
  • 환불 요청
  • 환불 완료 확인

느낀 점

오늘은 직접 기능을 새로 구현하기보다는, 여러 서비스가 함께 동작할 수 있는 실행 환경과 테스트 흐름을 정리했다.

MSA 프로젝트에서는 단순히 각자 맡은 도메인을 구현하는 것뿐만 아니라, 서비스들이 서로 어떻게 연결되고 어떤 순서로 검증되어야 하는지를 이해하는 것이 중요하다고 느꼈다.

특히 Gateway, Eureka, Config Server, DB, Redis, Kafka까지 함께 실행되는 구조를 맞추면서 실제 운영 환경에 가까운 흐름을 경험할 수 있었다.

앞으로 통합 테스트를 진행하면서 단순히 API 성공 여부만 확인하는 것이 아니라, 서비스 간 호출, 데이터 정합성, 이벤트 발행 여부까지 함께 확인해야겠다.


다음에 할 일

  • 유저 API부터 통합 테스트 시작
  • Gateway 경유 API 호출 확인
  • Postman Environment 변수 정리
  • 각 API 테스트 후 DB 데이터 확인
  • 서비스 간 FeignClient 호출 정상 동작 여부 확인
  • 예매 및 결제 전체 플로우까지 순차적으로 검증