안녕, 내 친구! 👋 코딩은 좀 어때? 오늘은 진짜 개발자라면 심장이 두근거릴 만한 주제를 가져왔어.
바로 '자바 네트워크 프로그래밍과 NIO'야. 이름만 들어도 머리가 지끈거린다고? 걱정 마! 내가 옆집 사는 형처럼, 아니면 같이 스터디하는 동기처럼 아주 맛깔나게 설명해 줄게.

혹시 그런 생각해 본 적 없어? "내가 만든 서비스가 대박 나서 동시 접속자 수가 폭발하면 어떡하지? 서버가 버텨줄까?" 🤯
넷플릭스, 카카오톡, 리그 오브 레전드 같은 서비스들은 어떻게 수백, 수천만 명의 요청을 동시에 처리하는 걸까? 그 비밀의 열쇠 중 하나가 바로 오늘 우리가 탐험할 NIO(Non-blocking I/O)에 숨어있어.

이 글을 끝까지 읽고 나면, 너는 더 이상 어설픈 'Hello, World!' 서버가 아니라, 대용량 트래픽도 거뜬히 감당할 수 있는 '괴물 서버'를 만들 수 있는 이론적 기반과 자신감을 갖게 될 거야. 커피 한 잔 타 와서 편하게 앉아봐. 이제부터 진짜 재밌는 이야기가 시작될 테니까! 😉

네트워킹, 그거 어떻게 하는 건데? 🤔 - 자바 I/O의 시작

NIO라는 신문물을 배우기 전에, 우리는 먼저 '구관이 명관'이라는 옛날 방식, 즉 블로킹 I/O(Blocking I/O)에 대해 알아야 해. 왜냐고? 옛것을 알아야 새것의 위대함을 제대로 느낄 수 있거든. 이걸 보통 줄여서 BIO(Blocking I/O)라고도 불러.

자, 상상해 보자. 네가 아주 잘나가는 카페의 사장님이야. 손님이 한 명 오면, 너는 그 손님의 주문을 받고, 커피를 만들고, 건네줄 때까지 다른 아무 일도 못 하고 그 손님에게만 매달려 있어야 해. 이게 바로 블로킹 방식이야. 한 놈만 팬다! 👊

서버의 세계에서도 똑같아. 클라이언트(손님)가 서버에 접속 요청을 하면, 서버는 그 클라이언트와의 통신을 전담할 '스레드(직원)'를 한 명 배정해. 그리고 이 스레드는 클라이언트가 데이터를 보낼 때까지, 또는 데이터를 다 받을 때까지 하염없이 기다려. 이 '기다리는' 행위가 바로 '블로킹(Blocking)'이야. 다른 일을 못 하고 발이 묶여버리는 거지.

BIO 코드 맛보기: 간단한 에코 서버

백문이 불여일견! 코드를 직접 보면 이해가 확 될 거야. 클라이언트가 메시지를 보내면 서버가 그대로 돌려주는 간단한 에코(Echo) 서버를 BIO 방식으로 만들어 보자.

import java.io.InputStream;
import java.io.OutputStream;
import java.net.ServerSocket;
import java.net.Socket;

public class BlockingEchoServer {
    public static void main(String[] args) throws Exception {
        // 1. 서버 소켓 생성: 클라이언트의 연결 요청을 기다릴 문을 연다.
        ServerSocket serverSocket = new ServerSocket(8888);
        System.out.println("서버가 문을 열었습니다. 클라이언트를 기다립니다...");

        while (true) {
            // 2. accept(): 클라이언트가 연결 요청을 할 때까지 여기서 '무한 대기' (블로킹!)
            Socket clientSocket = serverSocket.accept(); 
            System.out.println("클라이언트 연결 성공! IP: " + clientSocket.getInetAddress());

            // 3. 연결된 클라이언트마다 새로운 스레드를 생성해서 통신을 맡긴다.
            new Thread(() -> {
                try (InputStream in = clientSocket.getInputStream();
                     OutputStream out = clientSocket.getOutputStream()) {
                    
                    byte[] buffer = new byte[1024];
                    int length;

                    // 4. read(): 클라이언트가 데이터를 보낼 때까지 '무한 대기' (블로킹!)
                    while ((length = in.read(buffer)) != -1) {
                        System.out.println("클라이언트로부터 받은 메시지: " + new String(buffer, 0, length));
                        
                        // 5. 받은 데이터를 그대로 클라이언트에게 다시 보낸다.
                        out.write(buffer, 0, length);
                        out.flush();
                    }
                } catch (Exception e) {
                    System.out.println("클라이언트와 연결이 끊겼습니다: " + e.getMessage());
                }
            }).start();
        }
    }
}

코드에서 주석으로 표시된 `accept()`와 `read()` 메소드가 바로 이 이야기의 핵심 빌런들이야. 얘네들은 자기 할 일이 끝날 때까지 스레드를 붙잡고 놔주질 않아. 그래서 클라이언트 한 명당 스레드 하나를 통째로 할당해 줘야만 했던 거지.

BIO의 치명적인 단점: C10K 문제

처음에는 이 방식이 꽤 괜찮아 보여. 직관적이고 코드 짜기도 쉽거든. 하지만 사용자가 딱 10명, 100명일 때까지만이야.
만약 동시 접속자가 1만 명(10K), 10만 명이 되면 어떻게 될까? 😱

서버는 1만 개의 스레드를 만들어야 해. 스레드는 공짜가 아니야. 각각의 스레드는 자신만의 메모리 공간(Stack)을 차지하고, CPU는 이 수많은 스레드들을 왔다 갔다 관리하느라 정신이 없어. 이걸 '컨텍스트 스위칭(Context Switching)'이라고 하는데, 이게 많아질수록 서버는 실질적인 일은 못 하고 스레드 관리하느라 리소스를 다 써버리게 돼.

이것이 바로 그 유명한 C10K 문제(1만 개의 동시 접속을 처리하는 문제)야. BIO 모델로는 현대적인 대용량 서비스를 감당하기엔 역부족이라는 결론에 이르게 된 거지.

패러다임의 전환: 구원투수 NIO의 등장! 🚀

자, 이제 우리의 주인공이 등판할 시간이야. BIO의 한계가 명확해지자, 자바 개발자들은 새로운 해결책을 찾아 나섰고, JDK 1.4에서 마침내 NIO(New I/O)라는 구원투수가 등장했어.

NIO는 이름 때문에 그냥 '새로운 I/O'라고 생각하기 쉽지만, 핵심은 '논블로킹(Non-blocking)'에 있어. 아까 그 카페 비유를 다시 가져와 볼까? NIO는 한 명의 바리스타(스레드)가 여러 손님의 주문을 동시에 접수하는 것과 같아.

손님 A의 주문을 받고 머신에 커피를 내리라고 시켜놓고, 그 커피가 나오는 동안 손님 B의 주문을 받고, 또 그사이에 손님 C에게는 다 된 음료를 내어주는 거지. 바리스타는 한순간도 놀지 않고 '지금 당장 처리할 수 있는 일'을 계속해서 찾아 처리해. 이게 바로 논블로킹의 핵심 아이디어야. 낭비되는 시간이 없는 거지!

NIO를 움직이는 세 개의 심장: 채널, 버퍼, 셀렉터

NIO가 이렇게 마법처럼 동작할 수 있는 건, 세 명의 어벤져스 멤버 덕분이야. 바로 채널(Channel), 버퍼(Buffer), 그리고 셀렉터(Selector). 이 세 가지만 제대로 이해하면 NIO의 절반은 정복한 거나 다름없어.

1. 채널 (Channel): 데이터가 다니는 길 🛣️

BIO에서는 `InputStream`과 `OutputStream`이라는 두 개의 '단방향' 길을 사용했어. 데이터가 들어오는 길, 나가는 길이 따로 있었지. 하지만 NIO의 채널은 '양방향'이야. 하나의 채널로 데이터를 읽고 쓰는 것이 모두 가능해. 마치 왕복 8차선 고속도로 같달까?
대표적인 채널로는 `SocketChannel`(클라이언트용), `ServerSocketChannel`(서버용), `FileChannel`(파일용) 등이 있어.

2. 버퍼 (Buffer): 데이터를 담는 그릇 🧺

NIO에서 아주 중요한 개념이야. 채널은 데이터를 직접 주고받지 않아. 항상 이 버퍼라는 중간 매개체를 거치지. 채널이 데이터를 읽으면 버퍼에 담기고, 채널에 데이터를 쓸 때도 버퍼에 있는 데이터를 가져다 써.

버퍼는 단순히 데이터를 담는 배열이 아니야. 데이터를 어디까지 읽었고, 어디부터 쓸 수 있는지를 추적하는 세 개의 중요한 포인터를 가지고 있어.

• capacity: 버퍼가 최대로 담을 수 있는 데이터의 양. 한 번 정해지면 바뀌지 않아.
• position: 현재 읽거나 쓸 위치를 가리키는 포인터. 데이터를 읽거나 쓰면 자동으로 이동해.
• limit: 읽거나 쓸 수 있는 데이터의 끝을 나타내는 포인터. capacity를 넘을 수 없어.

3. 셀렉터 (Selector): 이벤트 관제탑 🗼

대망의 셀렉터! NIO가 논블로킹일 수 있는 이유, 단 하나의 스레드로 수많은 클라이언트를 처리할 수 있게 해주는 핵심 기술이야.
셀렉터는 여러 개의 채널을 등록해놓고, 그 채널들 중 어느 하나라도 '이벤트'가 발생했는지 감시하는 역할을 해.

여기서 말하는 이벤트란 이런 것들이야.

• OP_ACCEPT: 새로운 클라이언트가 접속을 요청했다! (ServerSocketChannel에만 해당)
• OP_CONNECT: 클라이언트가 서버에 연결을 성공했다! (SocketChannel에만 해당)
• OP_READ: 클라이언트가 보낸 데이터를 읽을 준비가 되었다!
• OP_WRITE: 클라이언트에게 데이터를 쓸 준비가 되었다!

서버 스레드는 더 이상 각 클라이언트를 붙잡고 하염없이 기다릴 필요가 없어. 그냥 셀렉터에게 "야, 일할 거 생기면 나 좀 불러줘"라고 말하고 대기하면 돼. (`selector.select()` 메소드)
그러다 셀렉터가 "어이, 3번 채널에서 읽을 데이터가 들어왔고, 5번 채널은 접속 요청이 왔어!"라고 알려주면, 스레드는 딱 그 '준비된' 채널들만 골라서 빠르게 처리하고 다시 대기 상태로 돌아가는 거야.

이 방식 덕분에 단 하나의 스레드로도 수천, 수만 개의 클라이언트 연결을 동시에 관리할 수 있게 되는 거지. 정말 혁신적이지 않아? 😎

코드로 증명한다! NIO 에코 서버 직접 만들어보기 💻

이론은 이제 충분히 들었으니, 슬슬 손가락을 풀어볼 시간이야. 말로만 들으면 감이 잘 안 오잖아. BIO 서버와 비교하면서 NIO 서버를 직접 만들어보면 "아하!"하는 순간이 올 거야. 아까와 똑같은 에코 서버를 이번엔 NIO 방식으로 구현해 보자.

코드가 BIO보다 조금 길고 복잡해 보일 수 있지만, 쫄지 마! 각 단계별로 내가 친절하게 해설해 줄게. 천천히 따라와 봐.

import java.io.IOException;
import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.nio.channels.ServerSocketChannel;
import java.nio.channels.SocketChannel;
import java.util.Iterator;
import java.util.Set;

public class NonBlockingEchoServer {
    public static void main(String[] args) throws IOException {
        // 1. 셀렉터 생성: 우리 서버의 이벤트 관제탑!
        Selector selector = Selector.open();

        // 2. 서버소켓채널 생성 및 설정
        ServerSocketChannel serverSocketChannel = ServerSocketChannel.open();
        serverSocketChannel.bind(new InetSocketAddress(8888));
        serverSocketChannel.configureBlocking(false); // **핵심: 논블로킹 모드로 설정!**

        // 3. 셀렉터에 서버소켓채널 등록: "새로운 연결 요청(ACCEPT)이 오면 알려줘!"
        serverSocketChannel.register(selector, SelectionKey.OP_ACCEPT);

        System.out.println("NIO 서버가 문을 열었습니다. 클라이언트를 기다립니다...");

        // 4. 무한 루프: 서버의 심장 박동
        while (true) {
            // 5. select(): 이벤트가 발생할 때까지 대기. (블로킹이지만, 여러 채널을 한 번에 처리!)
            // 타임아웃을 0으로 주면 이벤트가 있을 때까지 무한 대기.
            if (selector.select() == 0) {
                continue;
            }

            // 6. 발생한 이벤트들의 키(Key) 셋을 가져온다.
            Set<SelectionKey> selectedKeys = selector.selectedKeys();
            Iterator<SelectionKey> keyIterator = selectedKeys.iterator();

            while (keyIterator.hasNext()) {
                SelectionKey key = keyIterator.next();

                // 7. 각 키의 종류에 따라 이벤트 처리
                if (key.isAcceptable()) {
                    handleAccept(key, selector);
                } else if (key.isReadable()) {
                    handleRead(key);
                }

                // **중요: 처리한 키는 반드시 제거해야 한다!**
                // 제거하지 않으면 다음 select()에서 또 처리하려고 해서 무한 루프에 빠질 수 있다.
                keyIterator.remove();
            }
        }
    }

    private static void handleAccept(SelectionKey key, Selector selector) throws IOException {
        ServerSocketChannel serverChannel = (ServerSocketChannel) key.channel();
        SocketChannel clientChannel = serverChannel.accept(); // 여기서 블로킹되지 않음!
        clientChannel.configureBlocking(false);
        
        System.out.println("새로운 클라이언트 연결! IP: " + clientChannel.getRemoteAddress());

        // 새로 연결된 클라이언트 채널도 셀렉터에 등록: "이 채널에 데이터가 오면(READ) 알려줘!"
        clientChannel.register(selector, SelectionKey.OP_READ);
    }

    private static void handleRead(SelectionKey key) throws IOException {
        SocketChannel clientChannel = (SocketChannel) key.channel();
        ByteBuffer buffer = ByteBuffer.allocate(1024); // 데이터를 담을 버퍼 생성

        int bytesRead = clientChannel.read(buffer); // 채널에서 데이터를 읽어 버퍼에 담는다.

        if (bytesRead == -1) {
            // 클라이언트가 연결을 끊음
            System.out.println("클라이언트 연결 종료: " + clientChannel.getRemoteAddress());
            clientChannel.close();
            return;
        }
        
        // 버퍼를 읽기 모드로 전환 (position=0, limit=읽은만큼)
        buffer.flip();
        
        System.out.println(clientChannel.getRemoteAddress() + "로부터 받은 메시지: " 
            + new String(buffer.array(), 0, buffer.limit()));

        // 버퍼의 데이터를 그대로 채널에 다시 쓴다 (에코)
        clientChannel.write(buffer);
    }
}

코드 해부: 단계별로 이해하기

자, 코드를 보니까 어때? BIO랑은 구조가 완전히 다르지? 하나씩 차근차근 뜯어보자.

1~3단계: 서버 준비 과정

• `Selector.open()`: 이벤트 관제탑인 셀렉터를 만든다.
• `ServerSocketChannel.open()`: 클라이언트의 접속을 받을 서버 채널을 만든다.
• `configureBlocking(false)`: 이게 NIO의 알파이자 오메가! 채널을 논블로킹 모드로 설정한다. 이걸 안 하면 말짱 도루묵이야.
• `register(selector, SelectionKey.OP_ACCEPT)`: 서버 채널을 셀렉터에 등록하면서, "나는 `OP_ACCEPT`(연결 요청) 이벤트에만 관심 있어!"라고 알려준다.

4~6단계: 이벤트 감지 루프

• `while(true)`: 서버는 죽으면 안 되니까 무한 루프로 돌린다.
• `selector.select()`: NIO 서버에서 유일하게 블로킹될 수 있는 부분. 하지만 한 클라이언트를 기다리는 게 아니라, 등록된 모든 채널에서 어떤 이벤트라도 발생할 때까지 기다리는 거야. 효율적인 기다림이지. 이벤트가 발생하면 발생한 이벤트의 개수를 리턴하고, 블로킹이 풀린다.
• `selector.selectedKeys()`: `select()`가 깨어나면, "자, 이벤트 발생한 놈들 명단이야!" 하면서 `SelectionKey`의 셋(Set)을 돌려준다.

7단계: 이벤트 처리

• `keyIterator.hasNext()`: 명단을 하나씩 꺼내서 처리한다.
• `key.isAcceptable()`: "이거 혹시 연결 요청 이벤트야?" 라고 물어보는 거야. 맞다면 `handleAccept` 메소드를 호출한다.
• `handleAccept` 내부: `serverChannel.accept()`로 클라이언트 연결을 수락하고, 생성된 `clientChannel`도 논블로킹으로 설정한 뒤, "너는 이제부터 `OP_READ`(읽기) 이벤트가 발생하면 나한테 알려줘!"라며 셀렉터에 등록한다.
• `key.isReadable()`: "이거 혹시 데이터 도착 이벤트야?" 라고 묻는다. 맞다면 `handleRead`를 호출한다.
• `handleRead` 내부: `ByteBuffer`를 만들고, `clientChannel.read(buffer)`로 데이터를 읽어온다. 그리고 `buffer.flip()`으로 읽기 모드로 전환한 뒤, `clientChannel.write(buffer)`로 다시 써서 에코를 구현한다.

어때? BIO와 비교해 보면, 스레드를 새로 만드는 코드가 하나도 없지? 단 하나의 메인 스레드가 셀렉터를 통해 모든 클라이언트의 연결 요청과 데이터 송수신을 처리하고 있어. 이게 바로 NIO의 힘이야. 💪

고수의 길: NIO 성능 극한으로 끌어올리기 🔥

기본적인 NIO 서버를 만들 수 있게 되었다면, 이제 당신은 주니어 개발자의 티를 벗기 시작한 거야. 하지만 진짜 고수들은 여기서 멈추지 않아. NIO가 제공하는 강력한 무기들을 더 깊이 파고들어 서버의 성능을 한계까지 쥐어짜 내지. 몇 가지 고급 기술들을 소개해 줄게.

다이렉트 버퍼 vs 힙 버퍼: 메모리 전쟁

우리가 위 예제에서 `ByteBuffer.allocate(1024)`로 만든 버퍼는 힙 버퍼(Heap Buffer)야. 자바의 힙(Heap) 메모리 영역에 생성되지. 우리가 흔히 쓰는 `new` 키워드로 만드는 객체들처럼 말이야. 사용하기 쉽고 가비지 컬렉션(GC)에 의해 자동으로 관리되는 장점이 있어.

하지만 NIO에는 다이렉트 버퍼(Direct Buffer)라는 비밀 병기도 있어. `ByteBuffer.allocateDirect(1024)`로 만들 수 있는데, 이건 자바 힙이 아닌 OS의 네이티브 메모리 영역에 생성돼.

이게 왜 중요하냐면, 네트워크나 파일 I/O 작업은 결국 OS 커널 레벨에서 일어나거든. 힙 버퍼를 사용하면, JVM은 데이터를 OS로 보내기 전에 네이티브 메모리로 한 번 '복사'하는 과정이 필요해. 하지만 다이렉트 버퍼를 쓰면 이 복사 과정이 생략돼. OS가 바로 접근할 수 있는 메모리 공간을 사용하니까. 이걸 제로 카피(Zero-Copy)에 가깝다고 해.

Scatter/Gather I/O: 데이터 조각모음의 미학

데이터를 처리하다 보면 헤더, 바디, 푸터처럼 논리적으로 분리된 데이터 조각들을 한 번에 보내거나 받아야 할 때가 있어. 보통은 이걸 하나의 큰 버퍼에 다 합친 다음에 보내겠지?

NIO의 Scatter/Gather I/O는 이런 비효율을 줄여줘.

• Scattering Read (분산 읽기): 하나의 채널에서 읽은 데이터를 여러 개의 버퍼에 순서대로 나누어 담는 기능이야. 예를 들어, `[헤더 버퍼, 바디 버퍼, 푸터 버퍼]` 배열을 만들어두고 `channel.read(buffers)`를 호출하면, 채널에서 읽은 데이터가 헤더 버퍼부터 차곡차곡 채워져.
• Gathering Write (수집 쓰기): 여러 버퍼에 흩어져 있는 데이터 조각들을 하나의 채널에 순서대로 모아서 한 번에 쓰는 기능이야. `channel.write(buffers)`를 호출하면, 헤더 버퍼 내용 쓰고, 바로 이어서 바디 버퍼 내용 쓰고, 푸터 버퍼 내용을 쓰는 식이지.

스레딩 모델: 리액터 패턴(Reactor Pattern)

우리가 만든 예제는 단일 스레드로 모든 걸 처리했어. 간단한 경우에는 괜찮지만, 실제 서비스에서는 I/O 작업과 비즈니스 로직 처리를 분리하는 게 훨씬 효율적이야.

여기서 등장하는 디자인 패턴이 바로 리액터 패턴(Reactor Pattern)이야. Netty, Node.js 같은 유명한 프레임워크들이 모두 이 패턴을 기반으로 하고 있어.

아주 간단하게 설명하면 이래:

1. 리액터(Reactor) 스레드: 셀렉터를 담당하는 스레드. 오직 I/O 이벤트 감지 및 디스패칭(분배)만 담당해. (우리가 만든 예제의 메인 스레드 역할)
2. 워커(Worker) 스레드 풀: 리액터가 감지한 이벤트를 실제로 처리하는 스레드들의 모임.

동작 방식:

1. 리액터 스레드가 `select()`로 I/O 이벤트를 감지한다.
2. 이벤트가 발생하면, 리액터는 해당 채널의 데이터를 읽는 최소한의 작업만 수행한다.
3. 읽어온 데이터와 처리해야 할 작업을 워커 스레드 풀에 던져준다.
4. 리액터는 다시 `select()`로 돌아가 다른 I/O 이벤트를 기다린다. (비즈니스 로직이 끝날 때까지 기다리지 않음!)
5. 워커 스레드 중 하나가 작업을 받아 복잡한 비즈니스 로직(DB 조회, 계산 등)을 처리하고, 결과를 클라이언트에게 응답한다.

이렇게 역할을 분리하면, I/O를 담당하는 리액터 스레드는 블로킹 없이 계속해서 새로운 요청을 받을 수 있고, 시간이 오래 걸리는 작업은 워커 스레드들이 병렬로 처리하므로 전체적인 서버 처리량이 극대화돼. 이런 전문적인 지식은 혼자만 알기 아깝지. **재능넷** 같은 플랫폼에서 자신의 지식을 공유하며 다른 개발자들과 함께 성장하는 것도 좋은 방법이 될 수 있어.

혼자서는 외로워: NIO를 더 쉽게, Netty의 세계 🌐

자, 여기까지 따라왔다면 너는 이미 NIO에 대해 깊이 이해하게 된 거야. 축하해! 🥳 하지만 솔직히 이런 생각 들지 않아? "와... 좋은 건 알겠는데, 너무 복잡하고 손이 많이 가는데?"

맞아. `SelectionKey` 처리, 버퍼 `flip()`/`clear()` 호출, 예외 처리, 스레드 모델 구현... 순수 NIO(Raw NIO)로 견고한 상용 서버를 만드는 건 정말 어렵고 버그를 만들기 쉬운 일이야. 그래서 똑똑한 개발자들이 이런 복잡한 부분들을 싹 감싸서 아주 사용하기 편하게 만들어놓은 프레임워크를 개발했어.

그중 가장 대표적인 것이 바로 네티(Netty)야.

Netty, 너는 누구냐?

Netty는 고성능 네트워크 어플리케이션을 쉽고 빠르게 개발할 수 있도록 도와주는 비동기 이벤트 기반 네트워크 프레임워크야. NIO의 복잡함은 숨기고, 개발자가 비즈니스 로직에만 집중할 수 있게 아름다운 추상화를 제공해 주지.

우리가 위에서 힘들게 구현했던 것들을 Netty는 이미 다 가지고 있어.

• 잘 구현된 리액터 패턴 기반의 스레딩 모델 (이벤트 루프)
• 더 사용하기 편하고 성능 좋은 버퍼 (`ByteBuf`)
• 다양한 프로토콜(HTTP, WebSocket 등) 코덱을 기본 제공
• 파이프라인 기반의 유연한 이벤트 처리 구조

Netty로 만든 에코 서버 맛보기

Netty를 사용하면 아까 그 에코 서버가 얼마나 간결해지는지 한번 볼까? 설정 코드가 좀 있지만, 핵심 로직인 핸들러 부분에 집중해 봐.

import io.netty.buffer.ByteBuf;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelInboundHandlerAdapter;

public class NettyEchoServerHandler extends ChannelInboundHandlerAdapter {

    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) {
        // 클라이언트로부터 메시지가 들어오면 이 메소드가 호출된다.
        ByteBuf in = (ByteBuf) msg;
        System.out.println("Netty 서버가 받은 메시지: " + in.toString(io.netty.util.CharsetUtil.UTF_8));

        // 받은 메시지를 그대로 클라이언트에게 다시 보낸다.
        // ctx.write()는 버퍼에만 쓰고, flush()를 해야 실제로 전송된다.
        ctx.write(in); 
    }

    @Override
    public void channelReadComplete(ChannelHandlerContext ctx) {
        // channelRead()가 모두 끝나면 호출된다.
        ctx.flush(); // 버퍼에 있던 메시지들을 한 번에 전송!
    }



    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
        // 예외 발생 시 처리
        cause.printStackTrace();
        ctx.close(); // 채널을 닫는다.
    }
}

어때? 순수 NIO 코드와 비교하면 정말 선녀 같지 않아? 😇
셀렉터, 키, 버퍼 플립 같은 골치 아픈 것들이 전혀 보이지 않아. 그냥 `channelRead`라는 메소드 안에서 들어온 메시지(`msg`)를 받아서 처리하고, `ctx.write()`로 다시 보내주기만 하면 끝이야.

이것이 바로 프레임워크의 힘이야. Netty는 NIO라는 강력하지만 다루기 힘든 야생마를 잘 길들여서 누구나 쉽게 탈 수 있는 경주마로 만들어 준 셈이지.

마치며: 당신도 이제 고성능 서버 개발자! 🎉

와, 정말 긴 여정이었어. 여기까지 스크롤을 내린 당신, 정말 대단해! 👏
우리는 오늘 자바 네트워크 프로그래밍의 심장부를 함께 여행했어. 한 번에 한 놈만 패던 단순무식한 BIO의 시대에서 출발해, 그 한계를 극복하기 위해 등장한 혁신적인 NIO의 세계를 탐험했지.

채널, 버퍼, 셀렉터라는 세 명의 용사가 어떻게 힘을 합쳐 단 하나의 스레드로 수많은 적(클라이언트)을 상대하는지 지켜봤고, 직접 코드로 그 위력을 확인했어. 나아가 다이렉트 버퍼, 리액터 패턴 같은 고급 무기들을 통해 성능을 극한으로 끌어올리는 방법도 엿봤지.

그리고 마지막에는 이 모든 복잡함을 우아하게 감싸주는 Netty라는 강력한 갑옷의 존재까지 알게 되었어.

이제 당신은 더 이상 네트워크 프로그래밍 앞에서 주눅 들 필요가 없어. 누군가 "우리 서비스는 동시 접속자가 많아서 성능이 중요해요"라고 말할 때, 당신은 자신 있게 이야기할 수 있을 거야.

"아, 그거요? 블로킹 방식으로는 한계가 명확하죠. 논블로킹 I/O 기반으로 이벤트 드리븐 아키텍처를 고려해야 합니다. 셀렉터를 이용한 단일 스레드 이벤트 루프와 워커 스레드 풀을 조합한 리액터 패턴을 적용하면 C10K 문제도 거뜬히 해결할 수 있습니다."

...라고 말하는 순간, 주변 동료들의 눈빛이 달라지는 걸 느끼게 될걸? 😉

오늘 배운 지식은 단지 시작일 뿐이야. 직접 서버를 만들어보고, 부하 테스트도 해보고, Netty를 이용해 간단한 채팅 프로그램이나 게임 서버를 만들어보는 건 어떨까? 이론은 실전을 통해 비로소 당신의 것이 되니까. 만약 이 글을 읽고 더 깊은 튜터링이나 프로젝트 협업이 필요하다면, **재능넷**에서 실력 있는 자바 전문가를 찾아보는 것도 좋은 출발이 될 거야.

기억해. 기술의 발전은 언제나 '한계'와 '불편함'을 극복하려는 노력에서 시작됐어. 당신의 코드도, 당신의 커리어도, 오늘의 이 배움을 통해 한 단계 더 성장했기를 진심으로 바랄게. 파이팅!