어라, 맞는데 왜 틀리지?

동기·비동기, IO·NIO, 그리고 Virtual Thread

글의 주장은 “리액티브 프로그래밍은 원래 블로킹 I/O 한계를 극복하기 위해 등장했지만, Java 21의 Virtual Thread 가 등장하면서 더 이상 필수적이지 않다고 합니다.

아래에 제 생각과 본문 내용에 대해 서술합니다.

헷갈리는 개념 1 - 동기 Vs 비동기

동기/비동기 처리는 일의 순서에 대한 이야기 입니다.

동기적인 작업의 의미는, "이 일은 순서가 정해져있어서 이대로 실행되어야 해!" 이고
비동기 작업의 의미는, "이 일은 순서가 정해져있지 않으니 따로 실행해도 괜찮아" 입니다.

예를들어 권한 확인이 필요한 작업이 있다면 선제적으로 권한 체크를 하고 후에 로직을 태우는 동기적인 처리가 필요합니다.
반면 이메일/인증 코드 등을 보내고 그것을 확인하는 작업은 같이 비동기적으로 별도로 처리되어도 상관 없는 것 이죠

헷갈리는 개념 2 - IO Vs NIO

IO/NIO는 Thread 점유에 대한 이야기 입니다.
개발자들은 언제나 한정된 자원을 효율적으로 사용하고 싶어 합니다.

이건 Thread에 대해서도 마찬가지 인데요

기본적으로 I/O 작업이 발생하게 되면 Thread 는 Blocking 하게 됩니다.
DB에 요청보낸 데이터 혹은, 외부 API를 호출한 내용을 응답받기전까지 기다리게 됩니다.

그런데.. 앞서 말했듯 Thread는 비싼 자원입니다.
또 실질적으로 코드를 실행시키는 매우 중요한 자원이기 때문에, 어떻게하면 Thread 를 조금도 쉬지 않고 굴릴 수 있을까? 라는 고민에서 NIO가 나오게 됩니다.

Synchronous Blocking Design

전통적인 방법의 구현입니다.
사용자 요청시 스레드를 물고와 여러 I/O 작업과, CPU 작업을 하나의 스레드로 처리하는 방식입니다.

Platform Thread 는 기본적으로 1MB의 스택 메모리를 사용하기 때문에 꽤나 비싼 작업입니다.
그렇기 떄문에 Thread Pool 을 만들어 재사용 하는것이죠

Asynchronous Blocking Design

직렬로 실행되는 작업을 병렬화 시키는 작업입니다.
DB 및 API에 접근해 데이터를 가져온다 했을 때, 단계마다 새로운 Thread 를 할당해 처리합니다.

@Async Vs Executor

본글에서는 Executor에 대해서만 언급하지만 @Async 어노테이션 또한 존재합니다.

@Async 어노테이션은 AOP 기반으로 동작하며 Executor 와 동일하게 지정된 스레드 풀에서 스레드를 가져와 비동기적으로 처리하게 됩니다.

몇가지 차이점은 Executor 구현이 더 복잡한 만큼 세밀한 제어가 가능하다는 것 이며, @Async는 제어의 주도권을 Spring 에게 맡기는 것에 있습니다.

하지만 Thread 를 여러 개 사용하는 것이기 때문에 엔터프라이즈 환경에서는 한계가 있어 보입니다.

Reactive Style Design

CompletableFuture를 사용하면 스레드 갯수를 줄일 수 있습니다.

요청 스레드는 DB조회, API호출, 응답 전송이라는 파이프라인을 만들고 곧바로 스레드풀에 반환됩니다.(끝까지 실행하지 않고, 할 일만 넘겨줌) 그 후 별도의 스레드에서 해당 작업들이 처리됩니다.

CompletableFuture<String> dbFuture =
    CompletableFuture.supplyAsync(() -> fetchFromDB()); // DB 조회

CompletableFuture<String> apiFuture =
    CompletableFuture.supplyAsync(() -> fetchFromService()); // 외부 API 호출

// 두 결과 합치고 응답 보내는 파이프라인 구성
dbFuture.thenCombine(apiFuture, (db, api) -> db + " + " + api)
        .thenAccept(result -> sendDataToUser(result));

System.out.println("Request Thread는 여기서 반환됨");

하지만 여전히 I/O 작업 발생시 Thread가 Blocking 되는 문제는 해결하지 못합니다.

Fully Reactive Style Design

전통적인 Spring MVC -> Spring Webflux 의 전환을 말합니다.

즉 NIO 를 사용하겠다는 의미이며 스레드가 I/O 작업을 기다리지 않고 다른 작업을 처리하다가
I/O 작업이 완료되면 OS 커널 레벨에서 콜백해줍니다.

다만 사용에 있어서 복잡성이 크게 증가하고 전통적인 MVC 와 스타일이 많이 달라져 신규 프로젝트가 아닌 경우 대부분은 MVC 로 구성되어 동작하는 것으로 알고있습니다.

Virtual Thread

Virtual Thread (이하 VT) 입니다.
WebFlux 는 프레임워크의 변경이 필요하지만 VT 는 자바 21로 버전만 올려주면 됩니다.

    public void test() throws Exception {
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            for (int i = 0; i < 5; i++) {
                int id = i;
                executor.submit(() -> {
                    System.out.println("Start " + id + " in " + Thread.currentThread());
                    Thread.sleep(1000); // 블로킹처럼 보이지만 Carrier는 반환됨
                    System.out.println("End   " + id + " in " + Thread.currentThread());
                    return null;
                });
            }
        }
    }

VT 는 일회용으로 사용되며 CPU 연산을 위해 Platform Thread (이하 Carrier Thread) 에 mount 되어 사용되다, I/O 작업이 발생되면 suspend 상태로 변하게 되며 Carrier Thread 를 unmount 해, 즉기 Thread Pool 로 반환되고 다른 VT 에서 재활용할 수 있도록 합니다.

2025-09-01T20:30:07.592+09:00  INFO 61502 --- [cs-study.content] [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 0 ms
Start 0 in VirtualThread[#64]/runnable@ForkJoinPool-1-worker-1
Start 1 in VirtualThread[#66]/runnable@ForkJoinPool-1-worker-2
Start 3 in VirtualThread[#68]/runnable@ForkJoinPool-1-worker-4
Start 4 in VirtualThread[#69]/runnable@ForkJoinPool-1-worker-5
Start 2 in VirtualThread[#67]/runnable@ForkJoinPool-1-worker-3
End   4 in VirtualThread[#69]/runnable@ForkJoinPool-1-worker-3
End   2 in VirtualThread[#67]/runnable@ForkJoinPool-1-worker-4
End   3 in VirtualThread[#68]/runnable@ForkJoinPool-1-worker-1
End   1 in VirtualThread[#66]/runnable@ForkJoinPool-1-worker-2
End   0 in VirtualThread[#64]/runnable@ForkJoinPool-1-worker-5

처음 VT를 물고간 worker (carrier thread)의 변경이 있음을 볼 수 있습니다.
이는 스레드가 I/O 작업을 대기하는 것이 아님을 증명합니다.

동기적으로 짜여진 코드를 NIO 로 간단하게 처리 가능하다니.. 아름답네요

마무리

다만 본글에서 말하는 VT 와 같은 도구들로 인해 Webflux 같은 기술들은 생명이 다했다 라는 부분은
동의할 수 없을 것 같습니다.

이유는... 제가 Webflux 에 대해 깊은 이해가 없어서 정확히 어떤점이 해결되는지 모르기 떄문입니다.

다만, VT 의 경우 실행 Context 를 VT가 가지고 있고 Carrier Thread 는 이를 실행만 하는 구조이다 보니
Context 와 관련해 세부적인 제어가 필요하다면 여전히 Webflux 같은 기술의 사용이 유용하지 않을까? 추측됩니다.

왜 Map은 반복 가능하지 않은가?

이 글에서는 Map의 반복 가능하지 않도록 설계된 이유에 대해서 말합니다.
이를 확장해 class, interface 상속에 대한 내용도 추가해 놓았습니다.

Java Collection 프레임워크의 구조를 보면 알 수 있듯이, Map은 Collection이 아니며 Iterable 또한 상속받지 않습니다.
(Iterable 을 상속의 의미는 Enhanced For Loop 를 사용할 수 있음을 말합니다)

위의 글에서는 왜 "Map은 Iterable 하지 않은가?" 에 대해 말합니다.
주된 주장은 Map은 Collection, 즉 요소의 집합이 아니며 Pair의 묶음이라는 것 입니다.
Map은 기본적으로 key-value 형태의 쌍이기 때문에, 명시하지 않는다면 어떤 원소값의 반복인지 알 수 없습니다.

1. key 값을 반복
2. value를 반복
3. key-value 쌍을 반복

이렇게 다양한 옵션들이 있기 때문에 정확히 무엇을 순회할건지를 알 수 없는 모호함이 발생한다는 것으로
정확히 어떤것을 순회할지를 나타낸 후에야 Iterable해지는 것을 알 수 있습니다.

Map<String, Integer> scores = new HashMap<>();
scores.put("Madhavi", 90);
scores.put("Kiran", 85);
scores.put("Anita", 88);

// Iterate over entrySet
for (Map.Entry<String, Integer> entry : scores.entrySet()) {
    System.out.println(entry.getKey() + ": " + entry.getValue());
}
// Iterate over keys
for (String key : scores.keySet()) {
    System.out.println("Key: " + key);
}
// Iterate over values
for (Integer value : scores.values()) {
    System.out.println("Value: " + value);
}

class를 여러개 상속 받을 수 없는 비슷한 이유

이것과 비슷한 개념으로 class의 상속이 존재하는데요
class는 기본적으로 상태를 가지게 됩니다.

상태를 가진다는 것은 Field 값이 존재한다는 것이고, method 를 통해 이를 조작하게 됩니다.
재밌는 상상을 해볼까요?

만약 dragon, bird 두 개의 클래스를 상속받는다 가정하고
각각이 fly() 라는 메서드와 ,wings 라는 필드가 존재한다고 하겠습니다.

class Bird{

    int wings;

    public void fly(){
        // do something
    }

}

class Dragon{
    int wings;

    public void fly(){
        // do something
    }
}

class bat extends Dragon, Bird{
    // 누구의 날개를 사용해서 어떻게 날 것인가?
    // error 
}

이를 상속받은 클래스에서는 과연 누구의 wings를 가지고 어떻게 fly() 연산을 수행해야 할까요?
이렇게 직접적인 구현을 가지고 있는 클래스는 여러개를 상속받게 하는 순간 모호함에서 오는 이상이 발생할 수 있기 때문에
자바에서는 원칙적으로 막아두는 것 입니다.

반면에 interface는 상태를 가지지않고, 그저 어떤 연산이 가능한지만 명시해놓는 명세서입니다.
따라서 여러개를 상속받아도 모호함에서 오는 이상이 없는 것 이죠

그렇기 때문에 interface의 경우는 여러개를 상속받는 것을 막아두지 않습니다.

Stream 성능문제에 관한 글

본 글에서는 For loop 연산에서 Stream으로 변경하니 더 많은 메모리와, GC부담, 낮은 성능이 발생했다는 말을 합니다.

변경 전

    public List<TransactionSummary> processTransactions(List<Transaction> transactions) {
        List<TransactionSummary> summaries = new ArrayList<>();
        for (Transaction txn : transactions) {
            if (txn.getAmount() > 0) {
                double fee = calculateFee(txn);
                summaries.add(new TransactionSummary(txn.getId(), txn.getAmount(), fee));
            }
        }
        summaries.sort(Comparator.comparing(TransactionSummary::getAmount).reversed());
        return summaries;
    }

변경 후

    public List<TransactionSummary> processTransactions(List<Transaction> transactions) {
        return transactions.stream()
                .filter(transaction -> transaction.getAmount() > 0)
                .map(transaction -> {
                    double fee = calculateFee(transaction);
                    return new TransactionSummary(transaction.getId(), transaction.getAmount(), fee);
                })
                .sorted(Comparator.comparing(TransactionSummary::getAmount).reversed())
                .collect(Collectors.toList());
    }

느려진 이유로는 filter, map, sorted 연산을 거칠 때 마다 변환된 temp List 가 생기게되고
이로인해 연산에 더 많은 메모리와, 시간이 필요하다는 주장입니다.

그런데 조금 의문인 것이, 자바 패러다임 자체가 함수형으로 작성하는 방향으로 가고있으며
대규모 트래픽을 다루는 조직에서도 Stream을 적극적으로 사용하는 추세인데.. 더 느리다면 왜 사용할까요?

중간 연산 Vs 최종 연산

Stream은 중간 연산과 최종 연산의 개념이 존재합니다.

대부분의 중간 연산에서는 Lazy Evaluation이 발생하며, 이는 연산의 절차를 기록만 하다가 최종 연산(collect/forEach)등 을 만날때에 실제로 실행됨을 의미합니다.

따라서 연산 단계마다 변환된 temp List가 생기는 것이 아니라 한 요소에 대해서 filter, map 연산을 적용하고 이를 최종 연산에 전달하게 됩니다.

따라서 중간 연산을 거칠때마다 temp list가 발생해 느려졌다는 주장은 틀렸습니다.

그럼 왜 느려졌는가?

대부분의 중간 연산에서는 Lazy Evaluation 처리를 합니다.
즉, 모든 중간 연산이 지연 평가가 발생하는 것은 아닌데요

위에서 사용된 sorted 연산은 정렬하는 중간 연산입니다.
하지만 정렬의 특성상 앞서 나온 모든 요소가 필요하며, 실제로 map 연산을 거친 원소를 최종 연산에 바로 전달하는 것이 아닌
모든 원소에 map을 적용한 결과를 메모리에 쌓은 후 sorted하게 됩니다.

For loop 에서는 전체에 대해서 변환 작업을 실행한 후 sort를 시행하기 때문에 성능이 잘 나오는 것으로
Stream 마지막에 따로 sort 연산을 한다면 비슷한 성능이 나오게 됩니다.

굉장히 자주 사용하지만, 모호한 부분들이 많은 것 같아요.

개발을 하다보면 수많은 곳에서 List 형태를 사용합니다.

왜 그런가?

1. 쓰기 쉽다
2. 대부분 효과 있음
3. Collection Framework 의 일환으로 다양한 기능 제공

일종의 기본 소양처럼 사용하곤 합니다.

또 List 라는 자료구조는.. 다음을 내포합니다

1. 순서가 중요하다.
2. 변경 가능하다.
3. 인덱스 접근이 예상된다.

public void sendNotifications(List<User> users) {
    for (User u : users) {
        notificationService.sendEmail(u);
    }
}

하지만 순서가 필요하지 않다면?, 인덱스 접근이 필요 없고 단순 순회만 한다면?
리스트를 사용해야할 이유가 있을까?, 또한 저 코드는 인자로 들어온 것이 가변 리스트인지, 불변 리스트인지 구분할 수 없습니다.

이러한 이유 때문에 글에서는  List<T>를 사용하기 보다는Collection<T> 즉 Interface에 의존하거나
Iteratable 을 메서드 시그니처로 사용하자고 주장합니다.

public void sendNotifications(Collection<User> users);

public void sendNotifications(Iterable<User> users);

public void sendNotifications(Stream<User> users);

이런식으로 코드 작성이 가능하겠죠

개인적으로는 Iterable<T> 이 마음에 드는데요, 단순하게 순회만 할꺼야! 라는 의도가 굉장히 명시적이라 생각합니다. 
또 들어오는 인자에 대해서 수정을 가하는 행동이 없음으로 가변/불변 리스트등의 사용에서도 자유롭지않을까요? 

글에서는 다음과 같은 체크리스트를 통해서 List<T>의 사용 여부를 다룹니다.

When You Should Actually Use List

There are valid cases! Use List<T> when:

You need to access elements by index (list.get(3))
You care about the exact order of items
You plan to mutate the collection (add/remove/sort)
You explicitly want to signal that caller should pass a List
Otherwise? Don’t.

✅ Our Refactor Checklist
Here’s how we audited all our method signatures:

Does the method use .get(index)? → Keep List<T>
Does the method add/remove elements? → Keep List<T>
Only iterates or filters? → Switch to Collection<T> or Iterable<T>
Works best with lazy evaluation or large data? → Use Stream<T>

Collection & Iterable 

최상위에 Iterable 존재, Collection 은 이를 상속

List,Set,Queue가 Collection을 상속받고 Iterable

따라서... Map의 경우 에러가 나는 모습을 볼 수 있습니다.

이런식으로 Collection으로 지정한다면, 확실히 Set,Queue 등 다양한 자료구조가 하나의 메서드를 재사용할 수 있음으로 장점이 있고

호출하는 쪽에서도 별도의 자료구조 변환을 해주지 않아도 사용 가능하기 때문에 충분히 매력적인 선택지라고 생각됩니다.

자바를 2025년 답게 쓰자는 글 입니다.

몇몇 공감가고, 도입예정인 부분들에 대해서만 코멘트 남기려 합니다.

✨ Switched to Virtual Threads — Everything Changed

Virtual Thread (이하 VT)에 대한 사용이 가장 먼저 나오는데, 기본적인 개념은 있지만 사용해 본적은 없어
Dawn-Cs-Study 프로젝트를 하면서 사용해볼까 합니다.

VT의 개념자체가 자바가 사용하는 OS Thread를 VT를 핸들링하는 Carrier Thread로 사용하여 
한정된 스레드 갯수로 더 많은 스레드를 태우겠다는 것으로 알고있습니다.

아래는 VT 도입 이전, Thread, Executor 관련해 공부하면서 남긴 내용들입니다.

Thead 쓸 때마다 생성해서 쓰면 안되나요?

기존에는 Thread 객체를 직접 생성해서 start() 해야 했음

Thread thread = new Thread(() -> {
    System.out.println("Hello World!");
    });

thread.start();  // 새로운 스레드 생성 후 실행 
thread.run();  // 기존 요청을 물고온 스레드로 실행 (스레드 생성 X)

이 방법은 조금 머리아픈게.. new Thread() 할 때마다 스레드가 생성 됨
start() 실행이 끝나면 OS Thread는 즉시 반납되지만, 자바 Thread 객체는 힙에남아서 공간을 점유함

또 한 번 실행이 끝난 Thread 객체는 다시 start() 못하며, 몇 개의 스레드가 만들어졌는지 예상하기 어려움.
실행자체는 큰 문제가 없을 수 있으나, 관리의 측면에서 생산성이 매우 떨어진다.

Executor Vs Executors

Thread 실행 정책을 추상화 하여 만든 Interface
new Thread() 를 직접 다루지 않도록 하기 위해 도입됨

public interface Executor {
    void execute(Runnable command);
}

스레드 생성, 스케줄링 전략은 구현체에 위임합니다.
ThreadPoolExecutor, ScheduledThreadPoolExecutor 등이 대표적인 구현체

        return new ThreadPoolExecutor(
                core,
                max,
                60, TimeUnit.SECONDS,
                new ArrayBlockingQueue<>(queueCapacity),
                new ThreadPoolExecutor.CallerRunsPolicy()
        );

그런데.. ThreadPoolExecutor는 생성자 파라미터가 너무 많아서 설정이 귀찮습니다.
그렇기 때문에 자주 쓰는 패턴을 간단히 팩토리 메서드로 제공하기 위해 Executors 유틸 클래스가 만들어집니다.

Executors.newFixedThreadPool(int nThreads);   // 고정 크기 스레드풀
Executors.newCachedThreadPool();              // 필요시 스레드 생성, 유휴 시 종료
Executors.newSingleThreadExecutor();          // 1개 스레드만 사용
Executors.newScheduledThreadPool(int core);   // 주기적 실행 지원

하지만.. 실무에서는 보통 세부적인 커스텀을 하기 때문에 ThreadPoolExecutor 만들어 쓰는 경우가 더 많습니다.

여기서 한발자국 더 나아가면 이제는 OS Thread 하나에 여러 VT를 태워서 쓰는 방식으로 갑니다.
더 적은 Thread로 더 많은 작업을 수행할 수 있겠죠?

🧬 Embraced Records + Sealed Classes

레코드를 사용하자! 너무나 맞는 말입니다.
보통 DTO를 다룰때 Record 사용하거나 VO 같은 녀석들을 다룰때 사용하지 않나 싶습니다.

개인적으로는 불변성을 지켜줘야 한다!, 얘는 불변해!, 이런 의미를 내포하고 싶을때도 사용합니다.

sealed 키워드는 사용은 안해봤는데요, 이번 기회에 알아봤습니다.

이 타입이 어떤 클래스/인터페이스가 상속할 수 있는지를 명시적으로 제한합니다.

public sealed interface Event 
    permits LoginEvent, LogoutEvent {}

public final class LoginEvent implements Event {
    // 더 확장 불가
}

public final class LogoutEvent implements Event {
    // 더 확장 불가
}

이런식으로 구현이 되어지는데, sealed의 구현체는 항상 final, sealed, non-sealed 중 하나여야 합니다.

언제 유용한가?

sealed는 하위 타입의 집합이 닫혀있음을 의미합니다.
따라서...

public sealed interface Event permits LoginEvent, LogoutEvent {}

public final class LoginEvent implements Event {}
public final class LogoutEvent implements Event {}

LoginEvent,LogoutEvent 외에 다른 이벤트가 나오면 안되는 경우, 컴파일 타임때 Event 를 구현하는 상황을 막을 수 있습니다.
DDD에서는 클래스들을 집합화 하고, 이를 Context로 묶는 경향이 있기 때문에 DDD를 도입한다면 명시적으로 나타내기 좋지 않을까? 생각도 듭니다.

또한 switch문과 결합시키는 패턴도 유용합니다.

sealed interface Event permits LoginEvent, LogoutEvent, SignUpEvent {}

record LoginEvent(String email) implements Event {}
record LogoutEvent(Long userId) implements Event {}
record SignUpEvent(String email, String nickname) implements Event {}

public class EventHandler {

    public String handle(Event e) {
        return switch (e) {
            case LoginEvent login   -> "로그인 처리: " + login.email();
            case LogoutEvent logout -> "로그아웃 처리: " + logout.userId();
            case SignUpEvent signUp -> "회원가입 처리: " + signUp.email();
        };
    }

    public static void main(String[] args) {
        EventHandler handler = new EventHandler();

        System.out.println(handler.handle(new LoginEvent("user@test.com")));
        System.out.println(handler.handle(new LogoutEvent(42L)));
        System.out.println(handler.handle(new SignUpEvent("new@test.com", "승재")));
    }
}

또한 Pattern Matching for switch문법은 JDK 17은 preview고 21부터 정식지원입니다.