[Spring] Paging 및 Stream/for 비교분석

1. Page와 Slice 비교

1-1. Page와 Slice 출력값 비교

Page 사용 시 출력 (JSON 예시)

Page는 전체 데이터 개수, 전체 페이지 수, 현재 페이지 정보, 정렬 정보 등 추가적인 메타데이터를 모두 포함한다.

{
  "content": [
    { "id": 1, "title": "post1" },
    { "id": 2, "title": "post2" }
  ],
  "pageable": {
    "pageNumber": 0,
    "pageSize": 10
  },
  "totalElements": 132,
  "totalPages": 14,
  "last": false,
  "size": 10,
  "number": 0,
  "sort": {},
  "numberOfElements": 10,
  "first": true,
  "empty": false
}

Slice 사용 시 출력 (JSON 예시)

Slice는 content + 다음 페이지 존재 여부만 알려주며, 전체 개수와 전체 페이지 수는 제공하지 않는다.

{
  "content": [
    { "id": 1, "title": "post1" },
    { "id": 2, "title": "post2" }
  ],
  "pageable": {
    "pageNumber": 0,
    "pageSize": 10
  },
  "size": 10,
  "number": 0,
  "sort": {},
  "numberOfElements": 10,
  "first": true,
  "last": false,
  "empty": false
}

---

1-2. Page와 Slice 각각의 장단점

Page 장점

• 전체 데이터 개수(totalElements) 제공
• 전체 페이지 수(totalPages) 제공
• 페이지 네비게이션 UI 구현 용이
• 검색/관리자 화면에 적합

Page 단점

• count 쿼리가 추가 실행됨 → 성능 비용
• 대용량 데이터에서 병목 가능

Slice 장점

• count 쿼리 없음 → 빠르고 가벼움
• 다음 페이지 존재 여부만 체크
• 무한 스크롤 UI에 최적화

Slice 단점

• 전체 데이터 개수 제공 불가
• 전체 페이지 수 제공 불가
• 페이지 버튼 형태 UI에는 부적합

---

1-3. Page, Slice 적용 기준

Page 추천 상황

• 전체 페이지 수가 필요한 경우
• 페이지 번호 UI (1, 2, 3 …)
• 관리자 페이지
• 검색 결과 페이지

Slice 추천 상황

• 무한 스크롤 기반 UI
• 모바일 피드 (인스타그램, 유튜브 등)
• 전체 개수가 필요 없고 성능이 중요한 경우

---

2. For vs Stream 비교

2-1. for과 stream 작동 방식

for문 예시 (sum 계산)

int sum = 0;
for (int i : list) {
    sum += i;
}

Stream 예시 (sum 계산)

int sum = list.stream()
              .mapToInt(i -> i)
              .sum();

---

filter 비교

for문

List<Integer> result = new ArrayList<>();
for (int i : list) {
    if (i % 2 == 0) result.add(i);
}

Stream

List<Integer> result = list.stream()
                           .filter(i -> i % 2 == 0)
                           .toList();

---

성능 테스트 요약 (10만 건 기준)

• for문이 대부분 더 빠름
• stream은 람다 호출 및 내부 처리 과정의 오버헤드 존재
• parallelStream은 CPU 코어 활용 시 유리할 수 있으나,
  • 스레드 전환 비용
  • 공유 자원 접근 시 동기화 문제 때문에 오히려 느려질 수 있음

---

2-2. for와 stream 장단점

for문 장점

• 성능 가장 우수
• 단순하고 직관적
• 디버깅 쉬움

for문 단점

• 코드 길어짐
• 가독성이 떨어질 수 있음
• 조건/누적 로직 많아지면 복잡해짐

Stream 장점

• 코드 간결하고 가독성 우수
• 선언형 프로그래밍 방식 → 유지보수 용이
• 필터/매핑 등 데이터 변환에 최적화
• 병렬 처리 (parallelStream) 가능

Stream 단점

• 오버헤드 존재 → 성능 손해
• 디버깅 어려움
• 작은 연산에서는 for문보다 느림
• 병렬 사용 시 스레드 이슈 발생 가능

---

2-3. for와 stream 적용 기준

for문이 좋은 경우

• 성능 최우선
• 반복문 내부에서 복잡한 로직 필요
• 디버깅이 자주 필요한 경우

Stream이 좋은 경우

• 가독성이 중요한 비즈니스 로직
• filter, map 등 변환 중심 처리
• 함수형 프로그래밍 스타일 유지
• 대량 데이터에서 병렬 처리 가능할 때