2025-03-05 (수)

✅ 오늘의 핵심 정리

1. N+1 문제는 패치 전략과 관계없이 발생할 수 있으며, fetch join 또는 EntityGraph로 해결할 수 있다.
2. 반복 주기에 따른 데이터 구조를 최적화하고, 필수/선택 필드를 명확히 정의해야 한다.
3. 쉼표로 구분된 데이터를 저장할 때, 길이 계산을 통해 적절한 VARCHAR 크기를 설정해야 한다.
4. 다양한 유형의 ID가 포함될 경우, 이를 구분할 타입 필드를 추가하는 것이 유지보수에 유리하다.
5. RESTful API 명세를 작성할 때, 요청 구조, 필터링, 페이지네이션, 응답 데이터, 에러 핸들링을 철저히 설계해야 한다.

1️⃣ N+1 문제와 Fetch Join

• 글로벌 패치 전략(EAGER, LAZY)과 관계없이 N+1 문제는 발생할 수 있다.
• EAGER의 경우, JPQL 실행 시 연관된 엔티티를 개별 조회하면서 N+1 문제가 발생할 수 있음.
• LAZY는 기본적으로 지연 로딩이지만, 연관된 데이터를 접근하는 시점에 추가 쿼리가 실행될 수 있음.
• 이를 해결하기 위해 fetch join 을 사용하면 단일 쿼리로 모든 데이터를 가져올 수 있음.
• @EntityGraph도 활용할 수 있으며, 이를 통해 fetch join 없이도 연관 데이터를 한 번에 조회할 수 있음.

2️⃣ 데이터 모델링 및 API 요청 구조 설계

• 특정 데이터를 기반으로 정기적으로 정보를 전달하는 시스템을 설계하는 과정에서, 반복 주기(ONCE, DAILY, WEEKLY, MONTHLY)에 따른 데이터 구조를 고민함.
• WEEKLY의 경우 요일을, MONTHLY의 경우 날짜를 지정해야 하며, DAILY는 모든 날에 반복이 필요함.
• ONCE는 단 한 번만 실행되므로 불필요한 필드(regular_send_hour, regular_send_minutes, regular_send_toggle)를 제거해야 함.

✔ 최적화된 데이터 구조 결정

• repeat_days를 List<String>으로 사용하여 모든 경우를 통일 (["1", "15"] or ["MON", "TUE"])
• DAILY의 경우 repeat_days: [](빈 배열) 또는 null을 허용
• 특정 시간 단위(hour, minutes)의 타입을 고려하여 저장 방식 결정

3️⃣ 특정 ID 그룹의 타입 구분 필요성

• 요청 시 특정 그룹의 식별자를 전달해야 하는데, 이 ID가 서로 다른 유형의 데이터를 가리킬 수 있음.
• 예를 들어 A 그룹과 B 그룹의 ID가 같은 형식이라면, 이를 구분할 방법이 필요함.
• 이를 해결하기 위해 별도의 타입 필드(resource_type)를 추가하는 것이 유지보수성과 확장성 측면에서 유리함.
• ID 패턴이 명확하게 다르다면 굳이 타입 필드가 필요하지 않을 수도 있지만, 패턴 변경 가능성을 고려하면 명시적인 타입 구분이 더 안정적임.

4️⃣ RESTful API 명세 작성

• POST 요청
  • 특정 리소스를 생성하는 API로, 요청 데이터에 따라 필수 필드와 선택 필드를 구분해야 함.
  • repeat_cycle 값에 따라 필수 필드가 달라지므로, 유효성 검사를 철저히 해야 함.
  • List<String> 타입을 활용하여 데이터의 일관성을 유지함.
• GET 요청 (리스트 조회)
  • 필터링 옵션을 제공하여 특정 기준(name, repeat_cycle, created_by)에 따라 검색 가능하도록 설계.
  • page, size와 같은 페이지네이션을 지원하여 대량 데이터를 효율적으로 조회 가능하도록 설계.
  • 응답 데이터에 수신자 목록(recipients) 포함하여 더욱 풍부한 정보를 제공.

5️⃣ API 응답 데이터 설계 및 에러 핸들링

• 성공 응답
  • 201 Created → 리소스 생성 시 ID 반환
  • 200 OK → 리스트 조회 성공 시 데이터 반환
• 실패 응답
  • 400 Bad Request → 요청 값이 유효하지 않을 경우 (예: 잘못된 필드 입력, 필수 값 누락)
  • 404 Not Found → 데이터가 존재하지 않을 경우
  • 500 Internal Server Error → 서버 내부 오류 발생