2025-02-17 (월)

2025-02-17 (월)

🚀 오늘의 핵심 배움

1. API에서 발생할 수 있는 예외를 미리 정의하고, @ExceptionSwagger를 활용하여 API 문서화와 일관성을 유지해야 한다.
2. AES-GCM 암호화된 데이터를 저장할 때, 충분한 VARCHAR 길이를 설정하는 것이 중요하다.
3. Boolean 값을 TINYINT(1)로 저장할 때, 1과 0 이외의 값이 들어올 가능성이 있으므로 애플리케이션에서 검증이 필요하다.
4. JPA @OneToOne 관계에서는 FetchType.LAZY를 기본으로 설정해야 성능 이슈를 줄일 수 있다.
5. Hibernate Bytecode Enhancement를 활성화하면 대부분의 EAGER 관계가 LAZY로 최적화되지만, 명시적으로 EAGER인 필드는 그대로 유지된다.

   1️⃣ API 설계 및 예외 처리

✅ API 명세서 작성 & 예외 처리 고려 사항

• PUT /entity/{entityId}/feature 와 같은 API에서 발생할 수 있는 예외를 정리했다.
• 일반적인 예외(400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Internal Server Error) 외에도, 비즈니스 로직에 따라 추가될 수 있는 예외(409 Conflict, 403 Forbidden 등)를 고민했다.
• 예외를 관리하기 위한 @ExceptionSwagger 어노테이션을 활용하여, API 문서와 예외 처리의 일관성을 유지할 수 있도록 설계하는 것이 중요하다.

✅ API 요청 예제 (curl)

• curl을 활용하여 PUT 요청을 보내는 예제를 작성했다.
• -H 옵션을 사용하여 헤더 추가 (Authorization 토큰 포함)
• -d 옵션을 사용하여 JSON 데이터를 요청 본문에 포함
• -v, --fail 옵션을 사용하여 디버깅 및 에러 처리 방법을 개선

  curl -X PUT "https://api.example.com/entity/12345/feature" \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer your_access_token" \
     -d '{
           "featureEnabled": true,
           "featureCode": "ENCRYPTED_CODE"
         }'

2️⃣ 데이터베이스 설계 & 인덱스 고려 사항

✅ VARCHAR(64)로 충분할까?

• 암호화된 데이터(예: featureCode)를 저장할 때, VARCHAR(64)가 충분한지 검토했다.
• AES-GCM 암호화를 사용할 경우, Base64 인코딩을 고려해야 하므로 최소 VARCHAR(96) 또는 VARCHAR(128)이 적절하다.
• TINYINT(1)을 Boolean으로 사용할 때, 1과 0 이외의 값이 들어올 가능성이 있으며, 이를 방지하기 위해 애플리케이션 단에서 유효성 검증이 필요하다.

✅ 인덱스 설정 최적화

• feature_code에 대해 인덱스를 설정할 필요가 있는지 검토했다.
• WHERE 조건에서 feature_code를 자주 조회한다면 인덱스를 추가하는 것이 성능 개선에 도움이 된다.
• 단, 데이터 삽입 및 업데이트가 빈번한 경우, 인덱스가 성능 저하를 일으킬 수도 있으므로 신중하게 적용해야 한다.

  CREATE INDEX idx_feature_code ON entity_feature (feature_code);

3️⃣ JPA & Hibernate 최적화

✅ @OneToOne 관계에서 발생하는 문제와 개선 방법

• @OneToOne은 기본적으로 즉시 로딩(EAGER)이 적용되므로, FetchType.LAZY로 변경하는 것이 성능 개선에 도움이 된다.
• 하지만 기본적인 @OneToOne(fetch = FetchType.LAZY) 설정만으로는 완벽한 지연 로딩이 적용되지 않을 수 있다.
• 해결 방법
  • @Proxy(lazy = true)를 사용하여 Hibernate 프록시 적용
  • Hibernate Bytecode Enhancement를 활성화하여 프록시 없이도 LAZY 로딩을 최적화
  • @Transactional 내에서 접근하여 LazyInitializationException 방지

    spring:
    jpa:
    properties:
    hibernate:
      enhance:
        lazy-loading: true

4️⃣ Hibernate Bytecode Enhancement의 동작 방식

✅ 모든 엔티티가 LAZY로 동작할까?

• Hibernate의 Bytecode Enhancement를 활성화하면 기본적으로 @OneToOne, @ManyToOne 관계가 LAZY로 설정될 가능성이 높다.
• 하지만 명시적으로 FetchType.EAGER로 설정된 필드는 강제로 LAZY로 변경되지 않는다.
• 즉, Hibernate Bytecode Enhancement는 "기본적으로 EAGER인 필드를 LAZY로 최적화"하지만, 명시적인 EAGER 설정까지 강제 변경하지 않는다.
• JPA 표준을 유지하면서 LAZY 로딩을 효과적으로 활용하는 방법을 익혔다.

📌 성능 최적화를 위해 API 설계, DB 설계, JPA 관계 설정을 신중하게 다뤄야 한다는 점을 다시 한번 확인할 수 있었다! 🚀