Refactor/174

[grovince]

refactor: AWS 계정 연동 - 리소스 생성 워크플로우 테스트

📋 개요

사용자에게 역할을 할당/제거할 수 있는 API를 추가하고, CloudResource 생성 시 발생하던 제약 조건 오류를 해결했습니다. CloudService가 존재하지 않을 경우 자동으로 생성하는 로직을 추가하여 리소스 생성 프로세스를 개선했습니다. 또한 AWS 설정 및 리소스 생성 가이드를 추가했습니다. 참고해서 프론트엔드 개발하면 됩니다.

✨ 참고사항

조직, 테넌트 관련 기능이 통합되지 않아서 사용자 데이터를 임시로 삽입하고 리팩토링을 진행했습니다. 조직에 사용자 추가 후 리소스 생성, 프로젝트 생성 관련 로직은 기능이 통합되고 실행할 예정입니다.

✨ 주요 변경사항

1. 사용자 역할 관리 API 추가

• RoleController에 사용자 역할 관리 엔드포인트 추가
  • POST /api/v1/roles/users/{username}: 사용자에게 역할 할당
  • DELETE /api/v1/roles/users/{username}/{roleKey}: 사용자에서 역할 제거
• UserService에 역할 관리 메서드 추가
  • assignRolesToUser(): 여러 역할을 동시에 할당
  • removeRoleFromUser(): 특정 역할 제거
• RoleRepository에 findByRoleKeyInAndTenant() 메서드 추가
• 테넌트 검증 및 역할 존재 여부 확인 로직 포함

2. CloudResource 생성 시 CloudService 자동 생성

• 문제 상황

  • CloudResource 엔티티는 CloudService와 @ManyToOne 관계를 가지며, service_id 필드가 nullable = false 제약 조건을 가짐
  • 리소스 생성 시 해당 CloudService가 DB에 존재하지 않으면 CLOUD_4040 오류 발생
  • 기존에는 findServiceOrNull()로 조회하여 null 반환 시 오류 발생

• 해결 방법

  • CloudResourceManagementHelper 개선
    • findServiceOrNull() → findServiceOrCreate()로 변경
    • CloudService가 존재하지 않을 경우 자동으로 기본 CloudService 생성
    • createDefaultService() 메서드를 통해 최소한의 필수 정보만으로 생성
      • serviceKey: 리소스 생성 시 전달된 serviceKey 사용 (예: "S3")
      • serviceName: serviceKey와 동일하게 설정
      • serviceType, serviceCategory, displayName: null로 설정 (불필요한 자동 결정 로직 제거)
      • status: ACTIVE로 설정
      • isRegionSpecific: true로 설정
    • 자동 생성 시 로그 기록으로 추적 가능

• 설계 결정

  • serviceType, serviceCategory, displayName을 null로 설정한 이유
    • 이전에는 serviceKey 기반으로 자동 결정하는 로직이 있었으나, 실제로 사용되지 않음
    • 불필요한 복잡도 제거 및 명시적 관리 지향
    • 필요 시 별도 API를 통해 나중에 업데이트 가능
  • CloudService와 CloudResource의 관계
    • CloudService: 클라우드 서비스의 메타데이터 (예: AWS S3 서비스 정의)
    • CloudResource: 실제 생성된 리소스 인스턴스 (예: 특정 S3 Bucket)
    • 모든 CloudResource는 반드시 하나의 CloudService에 연결되어야 함

• 결과

  • CloudResource 생성 시 CLOUD_4040 오류 해결
  • CloudService가 사전에 생성되지 않아도 리소스 생성 가능
  • 코드 단순화 및 유지보수성 향상

3. LazyInitializationException 방지

• RoleService에서 엔티티 비교 방식 개선
  • role.getTenant().equals(currentTenant) → role.getTenant().getId().equals(currentTenant.getId())
  • Lazy 로딩된 엔티티 접근 시 발생하던 예외 방지

4. 코드 정리

• JwtAuthenticationFilter에서 사용하지 않는 import 제거

5. 문서 추가

• AWS_SETUP_AND_RESOURCE_GUIDE.md 추가
  • AWS 계정 사전 설정부터 리소스 생성까지의 전체 플로우 가이드
  • 프론트엔드 개발자를 위한 API 사용 가이드
  • 프로바이더 생성, 계정 등록, 사용자 역할 관리, 리소스 생성 절차 포함
  • 에러 처리 및 체크리스트 포함

🔧 변경된 파일

docs/AWS_SETUP_AND_RESOURCE_GUIDE.md                          | 772 +++++++++++++++++++++
src/main/java/com/agenticcp/core/common/security/JwtAuthenticationFilter.java   |   5 +-
src/main/java/com/agenticcp/core/domain/cloud/service/helper/CloudResourceManagementHelper.java      |  24 +-
src/main/java/com/agenticcp/core/domain/user/controller/RoleController.java     |  47 ++
src/main/java/com/agenticcp/core/domain/user/repository/RoleRepository.java     |  10 +
src/main/java/com/agenticcp/core/domain/user/service/RoleService.java      |  12 +-
src/main/java/com/agenticcp/core/domain/user/service/UserService.java      |  79 +++

🧪 테스트

API 테스트

• POST /api/v1/roles/users/{username} - 역할 할당 성공
• POST /api/v1/roles/users/{username} - 존재하지 않는 역할 에러 처리
• DELETE /api/v1/roles/users/{username}/{roleKey} - 역할 제거 성공
• 권한 검증 (USER_UPDATE 또는 SUPER_ADMIN 필요)

기능 테스트

• CloudResource 생성 시 CloudService 자동 생성 확인
  • CloudService가 존재하지 않을 때 자동 생성되는지 확인
  • 자동 생성된 CloudService의 필수 필드 확인 (serviceKey, serviceName, status)
  • serviceType, serviceCategory, displayName이 null로 설정되는지 확인
  • 이미 존재하는 CloudService를 재사용하는지 확인
• RoleService에서 LazyInitializationException 발생하지 않음 확인
• 테넌트 검증 로직 정상 동작 확인

📝 관련 이슈

• 사용자에게 역할을 할당할 수 있는 API 필요
• CloudResource 생성 시 CLOUD_4040 오류 발생
  • 원인: CloudResource.service_id가 nullable = false인데, 해당 CloudService가 DB에 존재하지 않음
  • 해결: CloudService 자동 생성 로직 추가
• RoleService에서 LazyInitializationException 발생
  • 원인: Lazy 로딩된 엔티티를 트랜잭션 외부에서 접근
  • 해결: 엔티티 비교를 ID 비교로 변경

✅ 체크리스트

• 코드 스타일 가이드 준수
• Swagger 문서 업데이트
• 테넌트 검증 로직 포함
• 에러 처리 구현
• 로깅 추가
• 문서 작성

🔍 리뷰 포인트

1. 사용자 역할 관리 API

   • 역할 할당 시 기존 역할을 모두 교체하는 방식 (추가가 아님)
   • 여러 역할을 동시에 할당 가능

2. CloudService 자동 생성

   • 제약 조건 해결: CloudResource.service_id가 nullable = false이므로 CloudService가 반드시 필요
   • 자동 생성 로직: findServiceOrCreate()로 존재하지 않으면 자동 생성
   • 최소 정보만 저장: serviceKey, serviceName만 설정하고 나머지는 null
   • 설계 철학: 불필요한 자동 결정 로직 제거, 명시적 관리 지향
   • 확장성: 필요 시 별도 API로 serviceType, serviceCategory, displayName 업데이트 가능
   • 로깅: 자동 생성 시 로그 기록으로 추적 가능

3. LazyInitializationException 방지

   • ID 비교로 변경하여 Lazy 로딩 문제 해결