어라, 맞는데 왜 틀리지?

오랜만에 재밌는 글을 가져왔습니다.
Redis는 굉장히 자주 사용되며, 특유의 원자성과 빠른 처리량으로 사랑받는 In-Memory DB 입니다.

원자성을 보장받는 이유는 Singlne Thread이기 때문인데요 "아무리 RAM 에 올라간다 하더라도 어떻게 수백만건의 요청을 처리하지?" 라는 의문을 한번쯤은 가져봤을 것 입니다.

개인적으로 "I/O는 멀티스레드를 써서 빠르다더라" 정도만 알고있었는데요, 이 글이 딥하게 알아볼 수 있는 계기가 되었습니다.

글의 내용

위 글에서 말하는 내용은 다음과 같습니다.

1. Redis는 모든 것을 RAM에 저장하므로 느린 디스크 I/O 를 방지
2. HashMaps, SortedSets, HyperLogLogs 등 최적화된 데이터 구조 사용
3. 고성능 I/O Multiplexing 사용
4. Redis 6.0 이상부터 I/O 처리가 멀티스레드 방식으로 변경

이 글을 읽으면서 햇갈렸던 개념은 I/O Multiplexing 인데요, "성능이 좋아진단건 알겠는데 그래서 그게 뭐지?" 라는 생각이 들어 자세히 찾아봤습니다.

Multiplexing (다중화)란 무엇인가?

Multiplexing은 간단히 말해 하나를 여러 개처럼 보이게 하는 기법이며, Redis는 버전과 상관없이 항상 I/O Multiplexing 기반으로 동작합니다.
운영체제 관점에서는, 하나의 프로세스가 여러 파일(혹은 소켓)을 동시에 관리할 수 있도록 하는 방법을 의미합니다.

리눅스에서 파일(File)은 프로세스가 커널에 접근할 수 있게 해주는 인터페이스이며, 네트워크 환경에서는 파일 = 소켓으로 대응됩니다. 즉, 하나의 서버가 여러 개의 소켓을 관리하여 동시에 많은 클라이언트를 처리할 수 있는 구조가 됩니다.

또 프로세스가 특정 파일에 접근할 때는 파일 디스크립터(File Descriptor, FD) 라는 정수 값을 사용하는데요
이 FD는 커널 내부의 파일 객체(소켓)를 가리키며, I/O Multiplexing은 FD의 상태 변화(readable/writable)를 효율적으로 감시하는 데 초점이 맞춰져 있습니다.

리눅스에서의 I/O Multiplexing: epoll

리눅스는 I/O Multiplexing을 위해 여러 메커니즘을 제공해왔습니다.
초기에는 select, poll을 사용했지만, 이들은 FD 개수에 비례하는 오버헤드가 있어 수천~수만 연결을 처리하기엔 비효율적이었습니다.

이를 해결한 것이 epoll입니다. epoll은 다음과 같이 동작합니다.

1. 애플리케이션이 epoll_ctl()을 통해 소켓을 등록하고, “이 소켓이 읽기/쓰기 가능해지면 알려달라”고 요청
2. 이벤트 루프 스레드는 epoll_wait()을 호출해 대기
3. 커널은 수천 개 소켓 중 실제로 준비된 것만 골라 이벤트 루프에 전달

즉, 준비된 소켓 목록만 반환하기 때문에, Redis는 수만 개 연결 중 필요한 소켓만 빠르게 처리할 수 있습니다.

Redis의 이벤트 루프 처리 흐름

Redis는 다음과 같은 순서로 이벤트(사용자 요청)를 처리합니다.

1. 소켓을 논블로킹 모드로 오픈
   • 일반적으로 소켓은 Blocking 모드
   • 소켓 수신 버퍼에 데이터가 없으면 -> 스레드가 멈춘 채 데이터 도착할 때까지 기다림
   • 송신 버퍼 가득 차면 -> 버퍼 여유 생길 때까지 기다림
   • Non Blocking 모드
   • 소켓에 데이터가 있으면 즉시 읽고 반환, 데이터가 없으면 에러코드 EAGAIN 반환
   • 송신 버퍼에 들어가는 만큼만 쓰고, 가득 차면 에러코드 EAGAIN 반환
   • 즉 준비된 만큼만 처리하고, 나머지는 다음 이벤트에서 처리
2. I/O Multiplexing 등록
   • Redis 이벤트 루프는 서버 시작 시 OS별로 다중화 방식 선택, Linux(epoll)
   • 논블로킹 소켓의 준비됨(readable/writable) 상태를 커널이 모아 이벤트 루프 스레드에 알려줌
   • 이벤트 루프 = 스레드가 발생한 이벤트를 지속적으로 감지하고, 콜백을 실행하는구조 
   • 소켓에 읽을 게 있으면 REDABLE, 소켓에 쓸 게 있으면 WRITABLE
3. 이벤트 루프 실행
   • 메인 스레드는 준비된 소켓 목록을 받음
   • 준비된 소켓마다 등록된 콜백을 실행 
     • READABLE - 요청 읽기 + 명령 실행
     • WRITABLE - 응답 전송

이 과정을 통해 단일 스레드 이벤트 루프만으로도 수천~수만 개 동시 연결을 처리할 수 있으며, 락(lock)도 필요하지 않습니다.

6.0 이전에는위 과정 전체(읽기, 명령 실행, 응답 전송)를 메인 이벤트 루프 단일 스레드가 처리했으며
6.0 이후에는 I/O 전용 스레드를 도입하여 read/write 작업을 여러 스레드로 분산 처리를 하도록 변경됐습니다. 
(명령 실행 자체는 여전히 단일 스레드에서 순차적으로 처리됩니다.)

Blocking vs Non-blocking 소켓

여기까지 정리한 후 한가지 의문이 생겼는데요 
“어차피 epoll이 준비된 소켓만 알려주면, 소켓을 블로킹 모드로 열어도 괜찮지 않을까?” 라는 생각이었습니다.

하지만 준비된 소켓이라고 해서 read/write가 항상 성공하는 것은 아닙니다.
예를 들어, 수신 버퍼 크기보다 더 많은 데이터를 read() 하거나, 송신 버퍼에 여유가 있음에도 write() 하려는 데이터가 너무 많다면, 버퍼가 다시 준비될 때까지 스레드가 블로킹될 수 있습니다.

따라서 소켓은 논블로킹 모드로 열어주는게 적절하겠네요. 

흥미로운 글을 가져왔습니다.
개인적으로는 공감이 많이 가는 글이고, 고민을 해본 부분이라 재밌게 읽었네요

본글에서는 의미있는 테스트에 대해서 말하고 있습니다.

Unit Test에 대한 개인적인 경험

    @Test
    @DisplayName("일기 생성")
    void createDiaryTestSuccess(@Mock User user) {

        ArgumentCaptor<Diary> diaryCaptor = ArgumentCaptor.forClass(Diary.class);

        when(userRepository.findById(1L)).thenReturn(Optional.of(user));
        DiaryCreateRequest request = new DiaryCreateRequest("test-content", true);
        when(diaryRepository.save(any())).thenReturn(Diary.of(request, user));

        diaryService.createDiary(request, 1L);

        verify(diaryRepository, times(1)).save(diaryCaptor.capture());
        verify(userRepository, times(1)).findById(1L);

        Diary savedDiary = diaryCaptor.getValue();
        FindDiaryResponse findDiaryResponse = savedDiary.convertToFindDiaryResponse();

        assertNotNull(savedDiary);
        assertFalse(savedDiary.isDeleted());
        assertEquals(true, findDiaryResponse.isLongEntry());
        assertEquals("test-content", findDiaryResponse.content());
    }

실제 제가 작성한 유닛 테스트의 일부입니다.

모든 의존성을 모의로 집어넣어, 정해진 값을 응답하게하고, 정해진 순서대로 메서드를 호출하고, 이를 검증합니다.
이 테스트는 의미있는 테스트일까요?? 제 생각은 "그렇지 않다" 입니다.

대부분의 버그는 시스템간의 통합이나 엣지 케이스에서 발생합니다.

외부 API가 장애가 발생했을 때, 옳지않은 값이 요청으로 들어왔을 때, 중간에 시스템이 다운됐을 때 등등..
하지만 유닛 테스트로는 이를 검증하기 어렵습니다.

또한 세부적인 구현을 검증하고 있습니다.

이 테스트 코드를 이해하려면 세부적인 구현 사항을 전부다 알아야할 것이며, 메서드 시그니처라도 변경된다면 해당 구현을 의존하는 모든 테스트 코드가 실패하게 됩니다.

따라서 의미있는 테스트 코드를 작성하기 위해선, 행위에 집중해야 합니다.

송금 기능을 검증한다면 다음과 같을 것 입니다.

1. 잔액이 음수가 될 수 없다.
2. 잔액보다 더 많은 돈을 송금할 수 없다.
3. 상태는 SUCESS,FAILED,PENDING 셋중 하나여야 한다.
4. 최대로 송금할 수 있는 금액은 백만원이다.
5. 그외의 다양한 규칙들...

세부적인 구현이 아닌 행위에 집중하는 것이죠

테스트 코드도 "코드"이기 때문에 유지 보수성을 가지고, 관리되어야 합니다.
구현은 언제든지 변경될 수 있는 반면, 행위와 그에대한 규칙들은 쉽게 변경되지 않기 때문입니다.

이러한 문제점들을 해결하기 위해, 본 글에서는 전체 흐름을 검증하는 통합 테스트의 작성을 추천합니다.

의미있는 테스트 코드

@Test
public void paymentServiceShouldReturnValidResponse() {
    PaymentRequest request = PaymentRequest.builder()
        .amount(BigDecimal.valueOf(100))
        .currency("USD")
        .paymentMethod("CREDIT_CARD")
        .build();

    PaymentResponse response = paymentService.processPayment(request);

    // Test the contract, not the implementation
    assertThat(response.getTransactionId()).isNotEmpty();
    assertThat(response.getStatus()).isIn("SUCCESS", "FAILED", "PENDING");
    assertThat(response.getAmount()).isEqualTo(request.getAmount());
}

구현이 아닌, 비즈니스 규칙에 대한 검증

@Property
public void userEmailShouldAlwaysBeValid(@ForAll("validEmails") String email) {
    User user = new User(email);
    assertThat(user.getEmail()).isEqualTo(email);
    assertThat(EmailValidator.isValid(user.getEmail())).isTrue();
}

@Provide
Arbitrary<String> validEmails() {
    return Arbitraries.emails();
}

여러 엣지 케이스들에 대한 검증

@Test
public void shouldHandleDatabaseFailureGracefully() {
    // Kill the database mid-request
    databaseContainer.stop();

    String response = restTemplate.postForObject("/api/orders", request, String.class);

    // System should degrade gracefully
    assertThat(response).contains("SERVICE_TEMPORARILY_UNAVAILABLE");
    assertThat(response).doesNotContain("500 Internal Server Error");
}

시스템 다운에 대한 검증

테스트에 대한 개인적인 생각 

테스트할 레이어를 크게 Repository, Domain, Service, Controller 로 나눈다면  

Domain
POJO이거나 DB의존성을 물고 있다 해도 도메인 서비스는 순수 자바임으로 유닛 테스트

Repository
@Testcontainsers 를 이용해 실제 환경과 동일한 DB에서 테스트

Service, Controller
비즈니스 규칙에 대해서만 유닛 테스트, 그 외에는 통합 테스트를 작성할 것 같습니다.

마무리

제목은 매우 도발적이지만, 전반적으로 글을 읽어보면 전하고자 하는 메시지는 하나입니다. 
"의미 있는 테스트 코드를 작성해라"

본 글에서는 테스트 커버리지는 단순히 “얼마나 많은 코드 줄이 실행되었는가”를 보여줄 뿐, 실제로 얼마나 많은 경우의 수를 검증했는지는 말해주지 않는다고 주장합니다.

유닛 테스트를 작성 하는것이 정말 필요에 의해서 작성이 되는 것 인지, 아니면 커버리지라는 지표를 만족시키기 위해 작성 되는 것 인지
고민할 여지를 던져 주네요

결국 좋은 테스트란

• 시스템의 행동(Behavior)을 검증하고
• 엣지 케이스와 장애 상황까지 고려하며
• 구현이 바뀌어도 쉽게 깨지지 않는 테스트

라고 생각합니다.

기능을 구현하는 것 보다 좋은 테스트 코드를 작성하는 것이 훨씬 어려운 영역인 것 같습니다. 

GPT 요약

이 글은 AWS Lambda에서 I/O 중심 로직을 처리하며, 동기 방식의 한계를 Virtual Thread + CompletableFuture로 극복한 경험을 다룹니다.
JMH 테스트 결과, VT가 가장 뛰어난 성능을 보였으며 JDK 24에서는 pinning 문제까지 해결되어 안정성이 강화되었습니다.
JFR 분석을 통해 확인한 결과, VT 자체보다 byte[]·String 처리 비용이 더 큰 메모리 요인이었으며, 앞으로는 메모리 최적화와 리팩토링을 진행할 예정입니다.

Dawn-Cs-Study 프로젝트에서의 경험을 다룬 글입니다.

Dawn-Cs-Study 프로젝트에서 AWS Lambda를 기반으로, I/O 작업을 처리해야 했습니다.
이번 글에서는 제가 구현한 비동기 로직을 테스트하고 정합성을 맞춘 과정을 공유하려 합니다.

필요할 때만 빌려오는 컴퓨팅 파워 Lambda

제가 진행 중인 프로젝트에서는 GitHub에 새로운 md, json 파일이 추가되면, 아래의 작업을 수행해야 합니다.
• Markdown → HTML 변환 및 임베딩
• JSON → DB 적재
이 로직은 main 브랜치에 PR이 머지될 때만 동작하는 간헐적 이벤트 기반 워크로드이기 때문에, 항상 서버를 켜두는 EC2 보다는 필요할 때만 실행되는 서버리스 아키텍처(AWS Lambda) 가 훨씬 적합하다고 판단했습니다.
전체 플로우는 다음과 같습니다.

GitHub Actions에서 파일 변경 감지 → S3에 업로드 → S3 Event 발생 → Lambda 트리거 실행 → 변환 및 배포

동기 처리의 늪에 빠지다

Lambda 함수는 S3 이벤트를 받아
• Markdown 파일은 HTML로 변환하고
• JSON 파일은 DB에 적재하는 역할을 합니다.
문제는 이 과정이 대부분 네트워크 I/O 중심이라는 점이었습니다.
이를  동기적으로 순차 실행을 하게 된다면, 이벤트가 많아질수록 처리량은 떨어지고 처리 시간은 늘어나게 될 것입니다.
이 작업들을 최적화 해보자는 생각이 들었고, 이전에 학습했던 VirtualThread를 도입하기로 결정했습니다.

처음 설계한 처리 흐름

처음 버전은 S3Event의 모든 레코드를 스트림으로 돌리며 각 레코드를 Virtual Thread + CompletableFuture.runAsync 로 비동기 실행하는 구조였습니다.
이벤트 유형(ObjectCreated/ObjectRemoved)과 확장자(md/json)에 따라 람다(Runnable) 를 만들어 제출하고, 마지막에 allOf(...).join()으로 전부 끝날 때까지 기다리는 방식이죠
의도는 단순하게 "레코드마다 비동기로 빠르게 처리하면 되겠지" 였지만 곧 바로 문제가 바로 드러났습니다.

실패 재시도 단위가 “전체 배치”라 정합성이 깨진다.

공식 문서에 따르면 Lambda는 실패 시 기본적으로 최대 2번까지 재시도를 수행하는데요, 여기서 중요한 점은 실패한 레코드만 재시도되는 것이 아니라, 전체 레코드가 다시 실행된다는 것입니다.
현재 구현에서는 Lambda가 HTML 변환과 DB 적재를 담당하고 있으며, 이는 멱등하지 않은 작업입니다.
따라서 재시도가 발생하면 중복 데이터가 생성될 위험이 있습니다.
따라서 정합성을 보장하기 위해 로직 보완이 필요했고 두 가지 방법을 고려했습니다.

1. AWS DLQ 사용
   • Lambda가 실패하면 이벤트를 DLQ(SQS/SNS)에 적재
   • 이후 DLQ를 읽어 중복 여부를 체크한 뒤 DB 반영
   • 단점: 추가 인프라 의존성 발생
2. 실패 이벤트 DB 기록 후 후처리
   • 실패 이벤트를 DB에 적재
   • 별도의 워커가 이를 감지해 재처리 및 정합성 회복
   • AI 서버가 EC2에 상시 구동 중이므로 쉽게 통합 가능

최종적으로는 두 번째 방법을 선택했습니다. 추가 인프라 없이도 일관성을 확보할 수 있고, 자연스럽게 연계할 수 있기 때문입니다.

2025/09/18 추가

기존 : S3 Event -> Lambda 
변경 : S3 Event > SQS > Spring Application(EC2)
필요시 객체 단위 처리가 아닌, 배치처리를 하기 위함

기존에 한 메서드 안에 있던 복잡한 switch-case 분기 로직은 buildTask라는 private 메서드로 분리해 가독성을 높였고,
예외 발생 시 전체가 실패하는 runAsync 대신 supplyAsync를 사용해 개별 실패를 분리했습니다.
또한 실패한 S3Event는 별도로 수집·처리할 수 있도록 분리하여 정합성을 보장할 수 있었습니다.
하지만 여기서 끝내면 조금 아쉽습니다. “빠를 것 같다”와 “실제로 빠르다”는 매우 다르기 때문이죠.
따라서 동기 처리 · 스레드풀 · VT 성능을 비교해 보았습니다.

JMH 성능 테스트

테스트 케이스는 크게 3가지였습니다.

1. 동기 처리 – 기존 방식 (순차 실행)
2. ExecutorService (FixedThreadPool) – 스레드풀 크기를 10, 100, 200으로 변경하며 측정
3. VT (JDK 21) – Executors.newVirtualThreadPerTaskExecutor() 사용

I/O 지연은 Thread.sleep()으로 단순하게 시뮬레이션했습니다.

결과는 다음과 같았습니다.

• 동기 처리: 요청이 늘어날수록 처리량이 급격히 감소, 평균 응답 시간도 비례해서 증가
• FixedThreadPool(10개): 일부 개선되지만 스레드가 포화되면 급격히 성능 저하
• FixedThreadPool(100, 200개): 병렬성이 늘지만 스레드 전환 비용 증가로 한계 존재
• VT (JDK 21): I/O 대기 시간을 효율적으로 숨기며 가장 높은 처리량 유지

즉, VT가 I/O 바운드 상황에서 최적의 성능을 보여줬습니다.

테스트의 허점: Thread.sleep()

하지만 여기에는 중요한 허점이 있는데요, 테스트에서 I/O 대기 시간을 단순히 Thread.sleep()으로 흉내냈다는 점입니다.
I/O 작업, 특히 JPA의 EntityManager.persist(), merge(), flush() 같은 메서드는 내부적으로 synchronized 블록을 자주 사용합니다.
또한 네트워크 I/O, 디스크 I/O에서도 종종 synchronized 기반 락을 볼 수 있습니다.
그렇게 synchronized 블록을 추가해 다시 테스트를 돌리자, 싱글스레드와 비슷한 성능을 보였습니다.

왜 그런걸까요?

synchronized와 Carrier Thread의 함정

그 이유는 바로 모니터락(monitor lock) 매커니즘에 있습니다.
모든 자바 객체는 1개의 모니터를 가지며, synchronized는 이 모니터를 보유해 Critical Section을 보호합니다.
여기서 문제는 모니터를 보유하는 주체가 Carrier Thread 라는 것 입니다.

간단한 예시

1. 객체 X의 synchronized 메서드를 VT₁이 실행 시작하게 되면, 모니터 소유자가 VT₁이 아니라, VT₁이 올라탄 캐리어 P₁로 기록됩니다.
2. 메서드 안에서 I/O 블로킹이 발생하면,이 순간 VT₁을 캐리어에서 떼어내(언마운트)고 P₁을 다른 일을 하게 해야됩니다.
3. 하지만 모니터의 소유자가 P₁ 이기 때문에 스케줄러가 VT₂를 P₁ 위에 올려 실행하면, JVM 관점에선 "VT₂가 X의 synchronized 메서드에 재진입하거나, 심지어 모니터를 해제할 수도 있다”는 논리적 모순이 발생합니다.

이렇게 되면 서로 배타적이어야 할 Critical Section의 보호가 깨져 버립니다.
따라서, JVM은 synchronized 내에 있을 땐 언마운트를 금지(pinning)하게되고, 결과적으로는 VT를 사용해도 병렬성이 사라지게 됩니다.

Pinning 문제의 두 가지 해법

1. 모니터락 사용하지 않기

synchronized 대신 ReentrantLock 같은 명시적 락을 사용하면, VT가 Carrier Thread에서 안전하게 분리(unmount)됩니다.

하지만 이 방법은 의존하는 모든 라이브러리의 내부 구현을 확인해야 합니다.
경우에 따라서는 기존 코드를 대규모 수정해야할 수 있기 때문에, 선택하기가 쉽지 않죠

1. JDK 24 업그레이드

다행히 JEP 491: Synchronize Virtual Threads without Pinning 이 JDK 24에 반영되었습니다.

 
JVM이 synchronized를 VT 기준으로 추적하도록 변경되어, VT가 synchronized 안에서 블록되면 언마운트하여 캐리어를 즉시 반환하게 됩니다.
즉, 기존 코드를 대규모로 수정하지 않아도 JDK 24 업그레이드만으로도 성능 개선을 얻을 수 있습니다.
(물론 JDK 버전을 올리면서 더 많은 코드를 수정해야 될 수도 있습니다.) 

실제로 동일한 코드를 JDK 24 환경에서 다시 테스트해 보니, JDK 21에서는 synchronized 구간에서 VT가 pinning 되어 사실상 싱글스레드처럼 동작하던 문제가 사라졌습니다.

덕분에 비동기 처리의 장점이 그대로 살아나면서 처리량이 크게 개선되는 것을 확인할 수 있었습니다.

성능은 좋지만, 자원 사용은? (JFR 모니터링)

성능 개선에는 성공했지만, 한 가지 의문이 남았습니다. 바로 CPU와 메모리 자원은 얼마나 쓰이고 있을까? 하는 점입니다.
VT는 가볍지만 여전히 고유한 스택 영역(2~4kb)을 갖기 때문에, 처리 속도에는 유리하더라도 메모리 측면에서 오히려 부담이 될 수 있다는 걱정이 들었습니다.
빠른 처리 속도만큼이나 자원 사용의 효율성도 중요한 문제이기에, 직접 JFR로 프로파일링을 진행하며 CPU·메모리 사용량을 면밀히 확인해 보았습니다.

I/O 중심 시나리오를 가정한 테스트였기 때문에, CPU 사용률은 전체적으로 낮게 나타났습니다.
메모리는 어떨까요?

JFR / Heap Live Objects 통계를 통해 분석해 보니, 메모리 점유 양상은 조금 의외였습니다.
처음에는 Virtual Thread 관련 객체들이 메모리의 절반 이상을 차지할 것이라 예상했지만, 실제로는 byte 배열과 String이 더 큰 비중을 차지했습니다.
즉, 생각보다 VT 자체의 메모리 부담은 크지 않았고, 오히려 데이터 처리 과정에서 발생하는 byte[], String 객체들이 주요 원인이라는 점을 확인할 수 있었습니다.

 
이번 글에서는 성능과 안정성 측면을 중점적으로 다뤘지만, 다음에는 메모리 최적화와 리팩토링 과정을 구체적으로 공유해 보겠습니다.
부족한 부분도 많지만, 계속 리팩토링하고 개선해 더 나은 모습으로 다시 오겠습니다.
리팩토링하고 다시 만나요

재밌는 글을 가져왔습니다.

if (action.equals("login")) {
    login();
} else if (action.equals("logout")) {
    logout();
} else if (action.equals("register")) {
    register();
} else {
    throw new IllegalArgumentException("Unknown action");
}

이런식으로 if-else 를 쓰지 말자! 라는 글인데요
if-else 제어문은 서비스를 만들면서 안쓰이는 곳이 없다해도 무방한만큼 흥미가 생겼습니다.

몇가지 재밌는 패턴들을 소개합니다.

Map + Functional Interface (Java 8+)

Map<String, Runnable> actionMap = Map.of(
    "login", this::login,
    "logout", this::logout,
    "register", this::register
);

actionMap.getOrDefault(action, () -> {
    throw new IllegalArgumentException("Unknown action");
}).run();

Map의 Value로 Runnable 을 받는 형태입니다.
if-else 제어대신 key에 맞는 행위를 받아와 실행시키는 방식이네요

다만, Runnable은 인자와 Return 값이 없습니다.
따라서.. 실제로 사용하기에는 좀 제약사항이 많을 것 같아요

보통 DTO나 도메인을 받아서 처리하는 경우가 많을테니, 대안으로 인자를 하나 허용하는 Consumer를 사용하거나
Return 값이 필요하다면 Function 을 사용할 수 있을 것 같습니다.

혹은 Functional Interface를 Cunstom하게 만들어서 사용도 가능해보입니다.

@FunctionalInterface
public interface DoThatThing<A, B, C, D> {
    D doSomeThing(A a, B b, C c);
}

다만 커스텀해서 만드는 경우는 표준이 아니기 때문에, 오히려 관리포인트가 증가할수도 있어 보이네요.

2025/09/12 수정 
프로젝트를 진행하면서 구현해보니, 외부에서 인자값을 받는 경우 Runnable 이어도 문제가 없네요
(아래에 나오는 Switch Expressions 의 예시이기도 합니다.)

private Runnable buildTask(S3EventNotificationRecord r) {

    String eventName = r.getEventName();
    String bucket = r.getS3().getBucket().getName();
    String key = URLDecoder.decode(r.getS3().getObject().getKey(), StandardCharsets.UTF_8);

    return switch (eventName.split(":")[0]) { // "ObjectCreated" or "ObjectRemoved"
        case "ObjectRemoved" -> switch (getExtension(key)) {
            case "md" -> () -> deleteMarkdownHtmlUseCase.deleteMarkdownHtml(bucket, key);
            case "json" -> () -> deleteJsonResourceUseCase.deleteJsonResourceUseCase(bucket, key);
            default -> throw new RuntimeException("잘못된 파일 확장자입니다. 확장자는 반드시 'md' 또는 'json' 이어야 합니다.");
        };
        case "ObjectCreated" -> switch (getExtension(key)) {
            case "md" -> () -> renderMarkdownToHtmlUseCase.renderHtml(bucket, key);
            case "json" -> () -> upsertSlugFromJsonUseCase.upsertSlugFromJson(key, Slug.class);
            default -> throw new RuntimeException("잘못된 파일 확장자입니다. 확장자는 반드시 'md' 또는 'json' 이어야 합니다.");
        };
        default -> throw new RuntimeException("잘못된 S3 이벤트입니다. 이벤트는 반드시 ObjectRemoved 또는 ObjectCreated 이어야 합니다.");
    };
}

Switch Expressions (Java 14+)

switch (action) {
    case "login" -> login();
    case "logout" -> logout();
    case "register" -> register();
    default -> throw new IllegalArgumentException("Unknown action");
}

자바 14부터 추가된 Switch 문법인데요, 기존과 다르게 각 case를 독립적으로 봐서 break가 필요없습니다.
화살표 때문에 람다와 비슷해보이지만, Functional Interface가 필요하진 않습니다.

유연하게 사용이 가능해 괜찮아 보이네요

Early Return

이건 제가 자주 사용하는 방식인데요, 빠르게 Return 해주는 겁니다.

        if (str.equals("test")) {
            // doSomething
            return;
        }

        if (str.equals("test2")) {
            // doSomething
            return;
        }


        // doSomething
        return

개인적으로는 여러개의 else-if 가 있는 코드보다 가독성이 좋다 생각합니다.

        if (str.equals("test")) {

        } else if (str.equals("test2")) {

        } else if (str.equals("test3")) {

        }

만약 반복문 이라면 continue의 사용도 가능합니다.

        for (int i = 0; i < MAX_SIZE; i++) {

            if (str.equals("test")) {
                count++;
                continue;
            }

            if (str.equals("test2")) {
                count--;
                continue;
            }

            count *= 2;
        }

나의 생각

자바 17을 사용하는 환경이라면 Switch 문을 적극적으로 사용해보고
그럴 수 없다면 Map 형태로 처리하는게 명시적이고 구조화돼 보입니다.

Early Return 같은 경우는 적은 공수로 코드를 깔끔하게 만드는 정도인것 같아요

네이버웹툰 최종 탈락

네이버웹툰 개발직 최종 면접에서 탈락했습니다.
사실 결과는 8월 중순에 이미 나왔지만, 좋지 않은 소식을 굳이 기록해야 할까 싶어 미루다가 이제야 글을 씁니다.

회고를 작성하기로 마음을 바꾼 이유는 미래의 저를 위해서 입니다.
부디 더 큰 사람이 되어 돌아봤을때 "그땐 그랬지" 하며 추억에 잠기길 원하거든요.

후회가 남는지?

후회를 하지 않는다면 거짓말이겠죠, 당연히 아쉽고 시간을 되돌리고싶다는 생각도 했습니다.
하지만 엄청나게 자책하거나 억울하진 않아요, 카카오게임즈때와는 다르게 준비해간만큼 보여줬습니다.

물론 중요한 실수도 했으며, 그것이 합불을 판가름짓는 중요한 분기점이 됐겠지만.. 당시의 저에게는 최선이었습니다.
지금 다시 면접을 본다면 훨씬 더 잘할 수 있겠지만, 뭐든 부딪히면서 배우는 거니까요.

긍정적으로 살기

저는 긍정적인 사람이고 자존감도 높은편인데.
요즘은 참 쉽지 않습니다.

연달은 탈락의 고배를 마시고 있거든요

“코로나만 조금 늦게 터졌어도…”
“요즘 채용 시장이 너무 어렵다…”
“내가 중고신입이 아니라서 그래…”
이런 생각도 하고, 먼저 취업한 제 친구와 동료가 부럽고 열등감을 느끼기도 합니다.

하지만 제 자신이 부끄럽진 않습니다.
정말 노력하고 있거든요, 누구나 겪는 성장통이라 생각합니다.

면접 전, 저는 늘 스스로에게 짧은 편지를 쓰는데..
다음엔 꼭 최종 합격 후기를 쓰고 싶네요.

그럼에도 나는 개발을 한다

제가 좋아하는 말이 있습니다.
"중요한건 꺾이지 않는 마음"

힘들어도 저는 개발이 좋고 재밌고 가치있다 생각합니다.
코드를 짜고 서비스를 만들고, 누군가에게 영향을 주는 그 과정이 정말 재밌습니다.

그러니 오늘도 노트북을 켜고 코드를 짭니다.

동기·비동기, 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는 비싼 자원입니다, 그래서 Pool 형태로 사용하는 것이죠
또 실질적으로 코드를 실행시키는 매우 중요한 자원이기 때문에, 어떻게하면 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와 Webflux 모두 스레드가 고정적이지 않아 스레드에 의존적인 코드가 있다면 문제가 발생할 수 있을 것 같습니다.
e.g) ThreadLocal 

왜 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 연산을 한다면 비슷한 성능이 나오게 됩니다.

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