네트워크 프로그래밍시 쓰레딩에 관련한 질문입니다

상상하시는 두가지 방법 모두 가능합니다.

listen 을 처리하는 쓰레드가 소켓연결을 처리한 후 놀고 있는 worker 쓰레드로 연결된 소켓을 넘겨주는 방식도 가능하고, 아니면 그냥 worker 쓰레드가 직접 listen 소켓의 연결요청을 기다렸다가 스스로 연결소켓을 만들어서 처리하는 방법.
이 두가지 모두 가능합니다.

후자의 방법을 택할 경우는 listen 소켓은 blocking 소켓을 사용해야 합니다.
물론, listen 소켓을 non-block 소켓을 이용한 후, 모든 worker 쓰레드가 무한 루프를 돌며 listen 소켓에 접속 요청이 있는지 없는지를 계속 확인해서 CPU에 엄청난 부하를 주는 비효율적인 방법으로 프로그램을 작동하게 할 수도 있고, 좀 더 아이디어를 내서 select() 를 이용해서 접속 요청이 있을 때에만 처리하는 방법을 쓸 수도 있습니다. 하지만, select()를 사용하면 Thundering Herd라고 불리는 문제가 발생합니다.

즉, 전자의 방법을 사용할 경우에는 listen 소켓이 blocking 이던 non-blocking 이던 효율적인 구현이 가능하고, 후자의 경우는 blocking 소켓일 경우에만 효율적인 구현이 가능합니다.
하지만, 전자는 메인 쓰레드가 worker 쓰레드로 작업을 넘겨야하는 기능으로 인해 프로그램 복잡도가 증가하는 단점이 있지요.

송신도 메인 쓰레드가 할거냐? worker 쓰레드가 할거냐도 몇가지 상황을 고려해야 합니다.
non-blocking 소켓을 사용할 경우는 어느쪽으로 구현해도 크게 문제 되지 않겠지만, blocking 일 경우는 worker 쓰레드가 송신을 꼭 해야한다고 보셔야 합니다. 그렇게 해야만 프로그램이 작동한다는 것이 아니고, 그렇게 해야만 효율적인 프로그램이 되기 때문입니다.
non-blocking 소켓을 이용해서 해결 보겠다고 마음 먹으셨다면, 소켓의 송신버퍼가 가득차서 송신이 실패했을 경우에 에러핸들링을 잘해야줘야 하며, 이것은 프로그램의 복잡도를 상승시키는 요인입니다.

그럼 가장 간단한 것은 blocking 소켓을 사용하고, worker 쓰레드가 직접 접속 요청을 받고, 송신도 worker 쓰레드가 하는 방법이 되겠죠.
간단한 프로그램의 경우는 이렇게 구현하시면 좋습니다.
하지만, 많은 동접과 트래픽을 처리해야 한다면, 위의 방법은 좋지 않은 선택입니다. 이유는 접속당 하나의 쓰레드를 사용하게 되면, 많은 동접은 많은 쓰레드의 생성을 요구하고, 많은 쓰레드는 많은 쓰레드 스케줄링 시간을 요구하게 되어서 스케줄링에 많은 자원이 소모되는 문제가 발생하고, 각 쓰레드별 스택이 필요로 하므로 많은 메모리를 요구하게 됩니다.
이때, 많은 쓰레드라 함은 수십개의 쓰레드가 아니고, 적게는 수백에서 많게는 수천/수만개의 쓰레드를 의미합니다.