중간 연산과 flatMap

중간 연산은 Stream을 반환해 파이프라인을 이어 줍니다. 항상 별도 객체를 만든다는 뜻은 아닙니다.

중요한 질문은 이름 암기가 아니라 원소 개수·타입·순서를 어떻게 바꾸는지입니다.

filter는 원소를 선별하고 map은 각 원소를 변환하며 flatMap은 각 원소가 만든 하위 Stream의 내용물을 하나의 흐름으로 합칩니다.

map의 중첩 목록 평탄화 오해

두 게시판 분류의 태그 List에 map(Category::tags)를 적용하면 원소는 String이 아니라 List입니다.

두 결과의 size()는 서로 다른 단위의 원소를 셉니다.

import java.util.List;

public final class NestedMapShapeBug {
    private record Category(String name, List<String> tags) {}

    public static void main(String[] args) {
        List<Category> categories =
                List.of(
                        new Category("notice", List.of("admin", "event")),
                        new Category("free", List.of("question", "answer")));
        List<List<String>> nested = categories.stream().map(Category::tags).toList();
        List<String> flattened =
                categories.stream().flatMap(category -> category.tags().stream()).toList();
        System.out.println(
                "wrong-element-count=" + nested.size() + ", flattened-count=" + flattened.size());
    }
}

중첩 구조가 요구 사항이라면 map 결과가 맞습니다.

모든 태그를 같은 수준의 원소로 처리하려면 flatMap을 씁니다. 예를 들어 전체 태그의 중복 제거와 그룹화를 적용할 수 있습니다.

평탄화가 도메인 구분을 지워서는 안 되므로 원래 게시판 분류와 태그의 관계가 필요하면 두 값을 묶은 record로 변환합니다.

예시 예제의 categories의 첫 map 결과는 태그 두 개가 든 목록이고 둘째도 목록입니다. 바깥 결과는 [[admin,event],[question,answer]]이므로 size는 2입니다. flatMap에서는 첫 하위 스트림의 admin·event 뒤에 둘째의 question·answer를 이어 붙여 바깥 원소 네 개를 만듭니다. 태그를 네 개 찾았다는 것과 분류를 네 개 찾았다는 것은 다른 계산입니다.

filter·map·mapMulti 규칙

filter 조건식이 true인 원소만 다음 단계로 보냅니다.

map은 입력 하나마다 출력 하나를 만듭니다.

flatMap의 매퍼는 입력마다 하위 Stream 하나를 반환하며, 그 안의 0개 이상 원소가 결과로 합쳐집니다. 각 하위 스트림은 내용을 옮긴 뒤 닫히고 매퍼가 null을 반환하면 빈 스트림으로 취급합니다.

mapMulti는 콜백으로 0개 이상의 값을 직접 전달하므로 출력이 조금씩 늘어나는 경우 임시 Stream 생성을 줄일 수 있습니다.

import java.util.List;

public final class IntermediateShapeCatalog {
    public static void main(String[] args) {
        List<String> source =
                List.of("notice:welcome,maintenance", "free:question,answer", "notice:event");
        List<String> noticeTitles =
                source.stream()
                        .filter(row -> row.startsWith("notice:"))
                        .map(row -> row.substring(row.indexOf(':') + 1))
                        .flatMap(value -> List.of(value.split(",")).stream())
                        .toList();
        List<Character> initials =
                source.stream()
                        .<Character>mapMulti(
                                (row, out) -> {
                                    for (String part : row.split("[:,]"))
                                        if (!part.isBlank()) out.accept(part.charAt(0));
                                })
                        .toList();
        System.out.println(noticeTitles);
        System.out.println(initials);
    }
}

위 코드의 noticeTitles는 [welcome, maintenance, event]로 계산됩니다.

첫 filter 뒤에는 notice:welcome,maintenance와 notice:event 두 문자열이 남습니다. map이 콜론 뒤를 골라 welcome,maintenance와 event로 바꾸고 flatMap이 쉼표로 나눈 두 값·한 값을 합칩니다. 별도 initials에는 free도 포함되어 [n,w,m,f,q,a,n,e] 여덟 문자가 남습니다. 이 두 파이프라인의 필터 유무도 함께 확인하세요.

mapMulti의 명시적 타입 인수는 소비자가 받을 원소 타입의 추론을 분명하게 합니다. 전달받은 out은 해당 매퍼 호출 안에서만 사용하며 나중에 쓰려고 보관하지 않습니다.

복잡한 파싱과 오류 복구가 필요하면 파이프라인 안에서 문자열을 억지로 쪼개지 말고 도메인 파서 메서드를 만듭니다.

flatMap의 매퍼가 null인 하위 Stream을 반환하면 빈 흐름으로 취급한다는 규칙은, null 목록에 .stream()을 호출해도 된다는 규칙이 아닙니다. category.tags()가 null이면 그 메서드 호출에서 실패합니다. 반면 tags가 빈 목록이면 정상인 빈 하위 Stream입니다. Stream API의 flatMap·mapMulti 계약은 하위 흐름의 닫힘과 consumer를 쓰는 범위를 구별합니다.

무상태·상태 보유 중간 연산

filter, map, peek은 현재 원소만으로 처리할 수 있는 무상태 연산입니다.

distinct, sorted, limit, skip은 상태를 보유하는 중간 연산입니다. 만나는 순서가 정해진 경우 limit·skip은 그 순서를 기준으로 원소의 위치를 판단합니다.

상태 보유 연산은 메모리와 병렬 조정 비용을 만들 수 있습니다.

distinct의 동등성 기준은 equals이며, 원소 타입의 hashCode도 동등성 규약에 맞춰 구현합니다.

정렬 뒤 distinct를 한다고 비교 결과가 0인 값을 동일 원소로 보는 것은 아닙니다.

TreeSet의 동률과 Stream.distinct의 동등성은 기준이 다릅니다.

import java.util.Comparator;
import java.util.List;

public final class StatefulIntermediateOperations {
    private record PostMetric(String title, int viewCount) {}

    public static void main(String[] args) {
        List<PostMetric> source =
                List.of(
                        new PostMetric("welcome", 40),
                        new PostMetric("question", 20),
                        new PostMetric("welcome", 40),
                        new PostMetric("event", 30));
        List<PostMetric> result =
                source.stream()
                        .distinct()
                        .sorted(
                                Comparator.comparingInt(PostMetric::viewCount)
                                        .reversed()
                                        .thenComparing(PostMetric::title))
                        .skip(1)
                        .limit(2)
                        .toList();
        System.out.println(result);
    }
}

중복된 PostMetric("welcome", 40) 하나가 distinct에서 제거되고 정렬 후 첫 항목을 건너뛴 두 값이 남습니다.

skip·limit의 위치를 sorted 앞으로 옮기면 결과가 달라질 수 있으므로 최적화를 이유로 연산 순서를 임의로 바꾸지 않습니다.

예제의 distinct 뒤에는 welcome40·question20·event30 세 record가 남습니다. 정렬하면 welcome40·event30·question20이고 skip(1) 뒤 limit(2)는 event30·question20입니다. distinct 뒤 skip(1)·limit(2)를 먼저 적용하면 question20·event30을 골라 그 둘만 정렬합니다. 이 예제 입력에서는 마지막 결과가 같아도 일반적인 순서 교환의 근거가 되지는 않습니다.

독립 확인: 예제의 정렬·skip·limit 파이프라인의 입력을 a10·b40·c30·d20 네 PostMetric으로 바꿉니다. 기존 연산 순서와 distinct→skip(1)→limit(2)→sorted를 각각 계산하세요. 같은 조회 수 20의 (a,20)과 (b,20)은 조회 수 비교가 동률이라는 이유로 distinct에서 합쳐지나요?

takeWhile·dropWhile의 접두부

이 절은 만나는 순서가 정해진 스트림을 기준으로 설명합니다. 값의 정렬 여부와 스트림의 순서 유무는 다릅니다.

import java.util.List;

public final class PrefixIntermediateOperations {
    public static void main(String[] args) {
        List<Integer> source = List.of(2, 4, 6, 7, 8, 10);
        System.out.println("take=" + source.stream().takeWhile(value -> value % 2 == 0).toList());
        System.out.println("drop=" + source.stream().dropWhile(value -> value % 2 == 0).toList());
        System.out.println("filter=" + source.stream().filter(value -> value % 2 == 0).toList());
    }
}

예시 예제의 List의 2·4·6은 연속된 참 접두부이고 7에서 처음 거짓이 됩니다. takeWhile은 그 앞의 [2,4,6], dropWhile은 7을 포함한 나머지 [7,8,10]을 남깁니다. filter는 7을 제외한 뒤에도 8·10을 선별하므로 [2,4,6,8,10]입니다. takeWhile이 전체 입력의 짝수를 찾는 별칭은 아닙니다.

독립 확인: 순서 있는 [7,2,4]와 [2,4]에 같은 짝수 조건으로 takeWhile·dropWhile·filter를 각각 적용합니다. 결과를 쓰고 빈 결과가 오류가 아닌 이유를 설명하세요.

peek의 관찰 용도

peek은 지연 중간 연산이며 최종 연산이 요구한 원소에서만 호출됩니다.

count 최적화처럼 결과에 필요 없는 순회가 생략되면 호출되지 않을 수도 있습니다.

외부 엔터티 저장, 필수 지표, 입력 검사를 peek에 넣지 않습니다.

객체를 peek에서 변경하면 파이프라인 앞뒤에서 같은 참조의 상태가 달라지고 병렬 실행에서 경합이 생깁니다.

map으로 새 불변 record를 만들어 결과에 변경을 반영합니다.

find 연산이 반환하는 Optional의 의미

findFirst와 findAny는 원소가 없을 수 있어 Optional을 반환합니다.

중간 연산이 아니라 최종 연산이지만 filter 파이프라인의 끝에서 자주 만납니다.

get()으로 존재를 가정하지 말고 orElse, orElseGet, orElseThrow, map으로 부재 정책을 표현합니다.

import java.util.List;
import java.util.Optional;

public final class PostLookupPipeline {
    private record Post(String slug, String title, boolean published) {}

    public static void main(String[] args) {
        List<Post> posts =
                List.of(
                        new Post("welcome", "Welcome", true),
                        new Post("draft", "Draft", false));
        Optional<String> title =
                posts.stream()
                        .filter(Post::published)
                        .filter(post -> post.slug().equals("welcome"))
                        .map(Post::title)
                        .findFirst();
        System.out.println(title.orElse("not-found"));
    }
}

Optional은 조회 최종 연산의 부재를 나타냅니다.

Stream 자체가 0개 이상 원소 흐름이고 Optional은 최대 하나의 결과라는 원소 수 차이를 유지합니다.

예제의 PostLookupPipeline의 첫 공개 필터는 draft를 제외합니다. 남은 welcome의 slug가 일치해 title인 Welcome을 얻습니다. slug 조건을 missing으로 바꾸면 findFirst는 빈 Optional이고 orElse의 not-found가 출력됩니다. 이 값은 예제 Post의 실제 제목과 부재를 하나의 문자열로 합친 반환 정책이므로, 제목에 not-found 자체가 올 수 있는 API라면 Optional을 유지하는 선택도 검토합니다.

중간 연산 순서를 결정하는 질문

의미가 같다면 선택도가 높고 비용이 작은 filter를 앞에 두어 비싼 map 호출을 줄입니다.

distinct 기준이 변환 전후에 달라지면 위치도 결과를 바꿉니다.

sorted는 정렬을 위해 입력을 모아야 할 수 있으므로 limit보다 앞인지 뒤인지 기능 요구를 확인합니다.

병렬 스트림에서는 만나는 순서를 보존하는 상태 보유 연산이 큰 조정 비용을 낼 수 있습니다.

순서가 필요 없다면 unordered()를 검토하되, 결과 형식에서도 순서를 제거할 수 있을 때만 사용합니다.

연습 문제

Category(name, slugs) 목록을 원본으로 받아 빈 slugs는 건너뛰고, 게시판 분류와 slug를 가진 Row 목록을 만드세요.

slug 사전순으로 정렬하되 각 Category와의 관계를 잃지 마세요.

import java.util.Comparator;
import java.util.List;

public final class CategoryPostRowsSolution {
    private record Category(String name, List<String> slugs) {}

    private record Row(String category, String slug) {}

    public static void main(String[] args) {
        List<Category> categories =
                List.of(
                        new Category("notice", List.of("welcome", "event")),
                        new Category("empty", List.of()),
                        new Category("free", List.of("question")));
        List<Row> rows =
                categories.stream()
                        .flatMap(
                                category ->
                                        category.slugs().stream()
                                                .map(slug -> new Row(category.name(), slug)))
                        .sorted(Comparator.comparing(Row::slug).thenComparing(Row::category))
                        .toList();
        System.out.println(rows);
    }
}

독립 확인: 연습 Category 입력을 notice:[same,b], empty:[], free:[same,a]로 바꿉니다. map(Category::slugs)로 수집한 바깥 원소 수와 flatMap 뒤 Row로 묶어 기존 정렬을 적용한 결과를 각각 구하세요. String만 평탄화한 뒤 distinct하면 same의 두 분류 관계를 모두 유지하나요?

중간 연산은 원소의 형태, 개수, 처리 순서, 버퍼링 방식을 바꿉니다.

flatMap을 단순한 중첩 제거로만 보지 말고 관계 보존과 원소 수를 함께 설계해야 파이프라인 결과가 도메인 의미를 유지합니다.