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

TIL - 2026.05.20

오늘 한 일

오늘은 티켓팅 서비스의 실제 배포 환경에서 프론트 화면 적용, Gateway CORS 검증, Keycloak 권한 설정, 서비스 헬스체크를 중심으로 점검했다.

특히 정적 HTML 파일을 서버에 배포하여 현재 외부에서 접근 가능한 데모 화면을 교체했고, ALB를 통해 Gateway로 요청이 정상 전달되는지 확인했다.

또한 프론트엔드에서 API 요청 시 발생할 수 있는 CORS 문제를 OPTIONS 요청으로 직접 검증했고, Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등이 정상적으로 반환되는 것을 확인했다.

주요 작업 내용

1. 정적 HTML 배포

기존에 작성된 ticketing-app.html 파일을 서버의 정적 배포 디렉토리로 복사하여 데모 화면을 교체했다.

cp ~/ticketing-app.html ~/ticketing-demo/index.html

적용 후 index.html 파일이 정상적으로 교체되었는지 확인했다.

ls -al ~/ticketing-demo/index.html

이를 통해 별도의 프론트엔드 빌드 서버 없이도 간단한 정적 클라이언트를 배포하고, 실제 API 연동 테스트를 진행할 수 있었다.

2. ALB + Gateway CORS 검증

브라우저에서 API 요청을 보내기 전에 발생하는 Preflight 요청을 직접 확인했다.

curl.exe -i -X OPTIONS "http://ticketing-alb-1966117378.ap-northeast-2.elb.amazonaws.com/api/users" `
  -H "Origin: http://3.35.47.138:3001" `
  -H "Access-Control-Request-Method: GET" `
  -H "Access-Control-Request-Headers: authorization,content-type"

응답 결과 200 OK가 반환되었고, 다음과 같은 CORS 헤더도 정상적으로 포함되어 있었다.

Access-Control-Allow-Origin: http://3.35.47.138:3001
Access-Control-Allow-Methods: GET,POST,PUT,PATCH,DELETE,OPTIONS
Access-Control-Allow-Headers: authorization, content-type
Access-Control-Allow-Credentials: true

이를 통해 ALB → Gateway → 서비스로 이어지는 외부 요청 흐름에서 CORS 설정이 정상적으로 동작하고 있음을 확인했다.

3. Keycloak 권한 설정 확인

테스트 중 특정 기능에서 필요한 CLUB_ADMIN 역할이 Keycloak에 등록되어 있지 않은 것을 확인했다.

기존에는 USER, ADMIN 중심으로 권한을 구성했지만, 클럽 관리 기능에서는 별도의 관리자 권한이 필요했다.

따라서 Keycloak Realm Role에 CLUB_ADMIN을 추가하고, 테스트 계정에 해당 역할을 부여했다.

이 과정에서 이미 발급된 JWT 토큰에는 새로 추가한 권한이 반영되지 않는다는 점을 다시 확인했다.

권한 변경 후에는 기존 토큰을 계속 사용하는 것이 아니라, 로그아웃 후 다시 로그인하거나 새 토큰을 발급받아야 변경된 Role 정보가 반영된다.

4. 서비스 헬스체크

배포된 주요 서비스들이 정상적으로 실행 중인지 각 서비스의 Actuator Health Endpoint를 통해 확인했다.

curl -fsS http://localhost:20001/actuator/health
curl -fsS http://localhost:20002/actuator/health
curl -fsS http://localhost:20003/actuator/health
curl -fsS http://localhost:20004/actuator/health
curl -fsS http://localhost:20005/actuator/health
curl -fsS http://localhost:20006/actuator/health
curl -fsS http://localhost:20007/actuator/health

모든 서비스에서 다음과 같은 응답을 확인했다.

{"status":"UP"}

이를 통해 현재 배포된 서비스 컨테이너들이 정상적으로 실행 중임을 확인했다.

오늘 배운 점

1. CORS 문제는 브라우저에서만 확인하지 말고 직접 Preflight 요청을 검증하는 것이 좋다

브라우저에서 CORS 에러가 발생하면 원인을 바로 파악하기 어렵다.

하지만 curl로 OPTIONS 요청을 직접 보내면 Gateway가 어떤 CORS 헤더를 반환하는지 명확하게 확인할 수 있다.

특히 다음 항목을 확인하는 것이 중요하다.

• Access-Control-Allow-Origin
• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Allow-Credentials

이번 검증을 통해 CORS 문제를 감으로 판단하지 않고, 실제 HTTP 응답 기준으로 확인하는 습관이 중요하다는 것을 느꼈다.

2. Keycloak Role 변경은 기존 토큰에 즉시 반영되지 않는다

Keycloak에서 사용자 Role을 추가하거나 수정해도 이미 발급된 JWT 토큰의 내용은 바뀌지 않는다.

JWT는 발급 시점의 사용자 정보를 담고 있기 때문에, 권한 변경 후에는 반드시 새 토큰을 발급받아야 한다.

즉, 권한 문제가 발생했을 때는 다음 순서로 확인해야 한다.

1. Keycloak에 Role이 존재하는지 확인
2. 사용자에게 해당 Role이 부여되어 있는지 확인
3. 새로 로그인하여 JWT를 재발급했는지 확인
4. 토큰 내부에 Role 정보가 포함되어 있는지 확인

3. 정적 HTML 배포도 실제 연동 테스트에서는 충분히 유용하다

아직 완성된 프론트엔드 애플리케이션이 아니더라도, 정적 HTML 파일만으로도 로그인, API 요청, CORS, ALB 접근 여부 등을 빠르게 검증할 수 있다.

이번 작업을 통해 프론트엔드 완성 여부와 별개로, 백엔드 배포 환경의 외부 연동 흐름을 검증하는 데 정적 클라이언트가 유용하다는 것을 알게 되었다.

정리

오늘은 실제 배포 환경에서 사용자 요청이 외부 클라이언트에서 ALB를 거쳐 Gateway와 각 서비스로 전달될 수 있는지 점검했다.

단순히 서비스가 실행되는지 확인하는 것을 넘어, CORS, 권한, 정적 클라이언트 배포, 헬스체크까지 함께 검증하면서 실제 서비스 운영에 가까운 테스트를 진행했다.

이번 작업을 통해 배포 환경에서는 코드 구현뿐 아니라 네트워크 흐름, 인증 토큰, Gateway 설정, 브라우저 요청 정책까지 함께 고려해야 한다는 점을 다시 확인했다.

다음 할 일

• 로그인 후 발급된 JWT에 Role 정보가 정상 포함되는지 확인
• CLUB_ADMIN 권한 기반 API 접근 테스트
• 정적 클라이언트에서 실제 사용자 플로우 점검
• ALB 기반 이중화 환경에서 서비스별 요청 분산 여부 확인
• 발표용 인프라 구성도와 실제 배포 구조 설명 정리